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 5 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 can see this whole packet capture that I'm showing you
only has 19 lines.
Now, 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 1, then 2, then 3,
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 where 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 ten 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,
but I'm hoping you'll be able to figure out
in the next 10 seconds.
Ten,
nine,
eight,
seven,
six,
five,
four,
three,
two,
one.
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 packet 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 these SYN packets happening,
from packet one, all the way through to packet 1002
and continuing,
because 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.
Ten,
nine,
eight,
seven,
six,
five,
four,
three,
two,
one.
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 1000 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 2,500, 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 5 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 of 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.