In this lesson, we're going to take a look
at some packet captures.
Now, a packet capture is used to be able
to capture all the data going to
or from a given network device.
You can also set up a packet capture over a SPAN port,
and capture all the data going to
and from all of the devices on your network depending
on how you can configure your packet capture software.
Now, when we look at a packet capture in this lesson,
we're going to be looking at snippets
because on the exam,
they're not going to give you a full packet capture
of gigabytes and gigabytes of data,
but instead, they're going to give you something
like five lines or 10 lines or 20 lines
inside of a packet capture
and so that's what we're going to be focusing on here.
Now, as we go through these three packet captures,
I'm going to show you three different types of attacks
that a threat actor might use against your network.
Let's take a look at the first one.
Now, in this first one,
you could see this whole packet capture
that I'm showing you only has 19 lines.
And it's actually going to be the longest packet capture
we're going to look at, but it's also one of the easiest.
Now, as we look at these, you can see that we have a couple
of different columns here going across the top.
The first one that we have is what's known as the number,
and this is the packet number in the capture sequence.
So we start out with one, then two, then three,
and we went all the way down to 19.
The second column we have is the time.
When did this happen?
Now, you'll notice this isn't actually a date and time
like you're used to,
but instead, it's actually written as the amount of time
that has elapsed since we started the packet capture.
So it's important to make sure you capture the time
you begin your packet capture
so you can then coordinate this
as you bring this packet capture into your SIEM
or other types of incident response systems
so you'll be able to consolidate this
and correlate it across all of your different logs
and devices because just knowing
that this happened at 0.002 second
after the ability of us starting this packet capture
isn't as helpful if we can't correlate
that across all of our systems.
The next two columns have IP addresses
and you'll see the source and the destination.
Essentially, it's our perspective based on the sensor
of what the data's coming from
and where the data is going to.
In this case, we have two sample IP addresses being used
of 99.88.77.66 as our source,
and we're trying to go to our destination,
which is 11.22.33.44.
Next, you'll see the column for protocol,
and this will either be TCP, UDP or something else.
For example, if we're operating at layer two,
you might see things like ARP being used.
But since we're here at layer three
and layer four, we're going to be talking about TCP and UDP.
Next, we have length, and this is how long
or how big that packet is,
and all of them are only 74 in this case.
And then we have info which will give you some information
that's being captured from the header
of each of these packets.
In this case, you can see the flag that's being set,
and you can see here that that is the SYN flag
and we don't see any ACK flags or SYN-ACKs.
And then we see the sequence, the window, the length,
the MSS, the SPort, which is your source port,
and your DPort, which is your destination port.
So now I'm going to count down from 10 to zero,
and when I get to zero, I'm going to tell you what type
of attack we're seeing inside of this packet capture
that I'm hoping you'll be able
to figure out in the next 10 seconds.
10, 9, 8, 7, 6, 5, 4, 3, 2, 1.
All right. Did you figure it out?
This is actually a port scan.
Now, in fact, this is actually a port scan
of the top 19 ports.
And this scan actually was going on
to the top 100 ports using an Nmap scanner.
But in this packet capture, I only showed you the first 19.
You'll notice the first port being scanned
is the DPort of 80, which is HTTP
or the Hypertext Transfer Protocol.
The second one is port 23, which is Telnet,
which is an insecure version of remote access.
The third one is port 22, which is going to be for SSH,
which is a secure remote shell capability.
The fourth one is FTP at port 21.
The fifth one is port 443 with HTTPS and so on.
As you can see, each time a SYN-ACK was being sent,
it was being sent with a single SYN
and a port going to there to basically see
if that port was open on the remote server,
which in this case was the destination of 11.22.33.44.
And it kept doing that over and over and over again
so that my Nmap software was able
to see are there any ports open as part of my reconnaissance
during a penetration test?
Let's go ahead and move on to our second packet capture.
Now, here's our second packet capture,
and you'll see that we have a couple
of dot, dot, dots in between.
So as we're going down the first column
with the packet numbers,
you'll see I have the first five packets shown.
Then I skip down to packets 100 through 102,
and then I skip down again to packets 1000 to 1002.
All those dot, dots are saying
is there's other packets happening here,
but I'm not showing it to you in this log snippet.
And you'll see this used on the exam as well.
As we go through, you can see
that this whole packet capture happened within 0.1 seconds.
So this is actually a pretty fast packet capture
to get 1000 packets through.
You'll see the source and you'll see the destination.
Now in this case, we're looking at the protocol as TCP.
The length is 74,
and again, we see a whole bunch of SYN packets there,
and we don't actually see the port numbers
associated with them.
So if you are looking at this
and you see all of these SYN packets happening
from packet one all the way through
to packet 1002 and continuing,
'cause there's still three dots there at the bottom,
what do you think this is?
I'm going to go ahead and count down from 10 again
and see if you can guess.
10, 9, 8, 7, 6, 5, 4, 3, 2, 1.
Did you guess it?
This is actually a type of denial-of-service attack
known as a SYN flood.
Notice in this packet capture,
we are not seeing any acknowledgements coming back
from that destination server to our source,
and we're not seeing any SYN-ACKs going
from our source back to our destination.
So what we have here is the first step
in a three-way handshake, but the second
and third steps are not being completed.
Now, the reason I'm showing you this
is because this is another type of attack
that you're going to see commonly used in your logs
where an attacker will use a SYN packet as a way
to start a half open connection
and they won't finish the connection.
When this happens, it eats up resources
on that destination server
and eventually that server can actually crash
if there's too many open requests.
Let's move on to our third packet capture.
Now, our third packet capture
actually has over 3,500 packets,
but again, I'm only showing you about 10 of them here,
and I'm using a bunch of dot, dots to be able
to hide the fact that there are a bunch of things
that are missing.
Now, as we go through here,
you're going to see it looks very similar to the last one,
so you're probably thinking it's some kind of a denial
of service attack, and you'd be right.
Now, as you look through, one of the differences
of this one versus the last packet capture
is that we all have the same destination being targeted,
but we're using different sources.
Notice that the first 1,000 packets
were all being used from 192.168.1.101.
Now, they were trying to do a SYN flood
as a denial-of-service attack,
and it appears that that wasn't successful
because the server was still responding.
So they started bringing in other hosts as well
to start sending traffic.
So you'll see that the first one was 192.168.1.101.
If we drop down to packet 1500, we can see
that the source there is 192.168.1.102.
If we go down to packet 2000,
we see 192.168.1.103.
We go to 2500, we see 192.168.1.104.
And every 500, we're going to another system
and using a different IP address.
So what this is showing us is this is a distributed denial
of service attack where we have multiple systems all going
and attacking the same server.
Now, in the case of this packet capture, we can see
that we had 3,500 packets being sent in about 1.75 seconds
from across multiple different IP addresses.
And so as we went into something at scale,
you might see hundreds or hundreds of thousands
of these packets from various IP addresses
that are all attacking you as part of a botnet inside
of this type of a packet capture.
But what we're trying to demonstrate here is the idea
that you could see a distributed denial of service attack
inside of a packet capture.
Now, for the exam, it is possible
that you would get a packet capture that has 5, 10, 15,
or 20 lines like this.
And often those people
who already work in the field look at this and go,
"I don't have enough information to make a decision."
And you're right.
In the real world,
I wouldn't call this a distributed denial of service attack
just by seeing these 10 or 15 lines,
but again, you have to ask yourself on the exam,
what are they trying to show me in five or 10 or 15 lines?
And the most obvious thing here would be
that we have a distributed denial-of-service attack
because we are doing these half open connections
to eat up resources on the same server,
and all of the destinations are the same server IP,
but the sources are coming from different places.
So this would be a distributed denial-of-service attack.
Whereas when we looked at number two,
all the sources were one computer
and all the destination was one server.
So that was a regular denial-of-service attack.
Keep this in mind as you're taking the exam
and you'll do really well
when you're looking at these packet captures.