9
Packet Analysis for Security
Although the majority of this book focuses on packet analysis as a function for network
troubleshooting, a large amount of packet analysis that is done in real world environments is
done for security purposes. This encompasses many roles including those of an intrusion analyst
reviewing network traffic from potential intruders or for forensic investigators attempting to
ascertain the extent of a malware infection on a compromised host. A completely separate book
could be written on packet analysis for network security but for now this chapter will serve as an
encompassing overview.
In this chapter we will take the viewpoint of a security practitioner and look at different
aspects of a system compromise at the network level. This will include examples of network
reconnaissance, malicious traffic redirection, and system exploitation. After doing that we will
take the role of an intrusion analyst and dissect traffic based upon alerts from an intrusion
detection system. Reading this chapter will provide you with critical insight to network security
even if you are not in a security-focused role.
Reconnaissance
An attacker’s first step in breaking into a target system is to perform in depth research on the
target. This step, commonly referred to as footprinting, is done through various open source
resources such as the public website of the target company and Google. Once this research is
completed the attacker will begin scanning operating on the IP address (or DNS name) of its
target. This scanning serves multiple purposes.
First, it allows the attacker to determine if the target is alive and reachable from the attacker.
Considering a scenario in which a bank robber is planning to steal from the largest bank in the
city located at 123 Main Street. He spends weeks upon weeks planning an elaborate heist only to
find out upon arrival at the bank that they have moved locations to 555 Vine Street. Worse yet,
imagine that same scenario but one in which the robber plans on walking into the bank during
normal business hours and stealing from the vault, only to find upon arrival that the bank is
closed on the day the heist was planned. Ensuring the target is alive and accessible is the first
hurdle that must be crossed.
Secondly (and most importantly), scanning tells the attacker what ports the target is listening
on. Relying once again upon our bank robber analogy, think about what would happen if the
robber showed up to the bank to rob it with absolutely no knowledge of the physical layout of the
building. This means that he would have no idea of how to gain access to the building at all
because he wouldn’t know what the weak points in the buildings physical security are. Simply
put, the results of initial scanning provide the layout that the attack can examine for exploitable
weaknesses in a system.
In this section we will talk about a few of the more common scanning techniques used to
identify hosts, their open ports, and vulnerabilities on the network.
Note: Thus far in this book we’ve typically referred to each side of a connection as a transmitter
and receiver or as a client in server. In this chapter I will once again be using new
terminology in referring to each side of communication as either the attacker or the
victim.
SYN Scan
The type of scanning that is often done first against a system is a TCP SYN scan, also known as a
stealth scan or a half-open scan. This type of scan is the most common type because it is very
fast and reliable, it is accurate on all platforms regardless of TCP stack implementation, and it is
somewhat stealthy.
The TCP SYN scan relies on the three-way handshake process to determine what ports are
open on a target host. In order to do this the attacker sends a TCP SYN packet to a range of ports
on the victim just as though it were trying to establish a channel for normal communication on
the ports. Once this packet is received by the victim then there are a few potential things that
could happen (Figure 9-1).
Figure 9-1: Possible Results of a TCP SYN Scan
If a service on the victim machine is listening on one of the ports that receive the SYN packet
then it will respond back to the attacker with a TCP SYN/ACK packet, the second part of the
TCP handshake. If this happens then the attacker knows that port is open and some service is
listening on it. Under normal circumstances a final TCP ACK would be sent in order to complete
the connection handshake but in this case the attacker doesn’t want that to happen since he will
not be communicating with the host further at this point. For the reason the attacker terminates
the connection by sending a TCP RST packet.
If there is no service listening on a scanned port then the attacker will not receive a
SYN/ACK. Depending upon the operating system and configuration of the victim, the attacker
could receive a RST packet in return indicating that the port is closed. Alternatively, the attacker
might not receive a response at all which indicates that the port may be filtered by an
intermediate device such as a firewall or the host itself, or that the response was simply lost in
transit. This result typically means that the port is closed but is ultimately inconclusive.
The file synscan.pcap provides a great example of a SYN scan performed with the NMAP
tool. NMAP is a very robust network scanning application developed by Fyodor that has the
ability to perform just about any kind of scan you can think of. You can download NMAP for
free at http://www.nmap.com/download.html.
The sample file contains roughly 2000 packets which indicates that this scan is reasonably
sized. One of the best ways to ascertain the scope of a scan of this nature is to view the
conversations window. When you do this you should see that there is only one IPv4 conversation
 between the attacker (172.16.0.8) and the victim (63.13.134.52). You will also see that there
are 1994 TCP conversations between these two hosts , accounting for a new conversation for
every port pairing being communicated on.
Figure 9-2: The conversations dialog shows us the variety of TCP communications taking place
The scanning is occurring very quickly so scrolling through the capture file is not the best
way to find the response associated with each initial SYN packet since several more packets
might be sent out before a response to the original packet is received. We can create filters to
help find the right traffic.
As an example, consider the first packet which is a SYN packet sent to the victim on port 443
(HTTPS). If we want to see if there was a response to this packet we can create a quick filter that
shows all traffic to and from port 443. In order to do this quickly select the first packet in the
capture file, expand the TCP header in the packet details window, right click the Destination
Port field, select Prepare as Filter, and click Selected. This will place a filter in the filter dialog
for all packets with the destination port of 443. We also want all packets from the source port
443 as well, so click in the filter dialog at the top of the screen and erase the dst portion of the
filter.
The resulting filter will yield two packets, both being TCP SYN packets sent from attacker to
victim (Figure 9-3).
Figure 9-3: Two attempts to establish a connection with SYN packets
Since there is no response to either of these packets then it is possible the response is being
filtered by the victim host or an intermediary device, or that the port is closed. Ultimately, the
result of the scan against port 443 is inconclusive.
We can attempt this same technique on a different packet to see if we have different results.
Clear the previously created filter by clicking the Clear button next to the filter area and select
the 9th packet in packet list. This is a SYN packet to port 53, commonly associated with DNS.
Using the same method I outlined in the last paragraph create a filter based upon the destination
port and erase the dst portion of the filter so that it applies to all TCP port 53 traffic. When you
apply this filter you should see five packets (Figure 9-4).
Figure 9-4: Five packets indicating a port is open
The first of these packets is the initial SYN we selected at the beginning of the capture. The
second is an actual response from the victim and is a TCP SYN/ACK which is the response
expected when setting up the three-way handshake. Under normal circumstances the next packet
would be an ACK from the host that sent the initial SYN, but in this case our attacker doesn’t
want to complete the connection establishment process and doesn’t send a response back. As a
result, the victim retransmits the SYN/ACK three more times before giving up. Since a
SYN/ACK response is received when attempting to communicate with the host on port 53then it
is safe to assume that there is some service listening on that port.
Let’s rinse and repeat this process one more time for packet 13, which is a SYN packet sent
to port 113, commonly associate with IRC ident and auth services. If we apply the same type of
filter to the port listed in this packet you will see four packets (Figure 9-5).
Figure 9-5: A SYN followed by a RST indicating the port is closed
The first is the initial SYN and it is followed immediately by a RST from the victim. This is
an indication that the victim host is not accepting connections on the targeted port and that a
service is most likely not running on it.
After understanding the different types of response a SYN scan can elicit the next logical
thought is to find a fast method of identifying which ports are open or closed. The answer to this
lies within the conversations dialog once again. Once open, you can sort the TCP conversations
by packet number with the highest values at the top by clicking the Packet s column twice.
Figure 9-6: Finding open ports with the conversations dialog
There are three ports that were scanned that include 5 packets in each conversation . These
ports 53, 80, and 22 are open, because these five packets represent the initial SYN, the
corresponding SYN/ACK, and the retransmitted SYN/ACKs from the victim. There are also five
ports in which there are two packets involved in the communication . The first packet is the
initial SYN and the second packet is the RST from the victim. This indicates that ports 113, 25,
31337, 113, and 70 are closed. The remaining entries in the conversations dialog only include
one packet meaning that the victim host never responded to the initial SYN. These remaining
ports are most likely closed, but ultimately inconclusive.
Operating System Fingerprinting
An attacker puts a great deal of value on knowing the operating system of his target. Knowledge
of the operating system in use ensures that all of the attack methods employed by the attacker are
configured correctly for the architecture the target operating system uses. This also allows the
attacker to know the location of certain critical files and directories within the target file system
should they actually succeed in access the system.
Operating system fingerprinting is the name given to a grouping of techniques used to
determine the operating system that is running on a system without actually having physical
access to that system. There are two types of OS fingerprinting; passive and active.
Passive Fingerprinting
Passive fingerprinting is a method of OS fingerprinting in which certain fields within packets
sent from the target are examined in order to determine what operating system is in use. The
technique is considered passive because you only listen to the packets the target host is sending
and don’t actively send any packets to the host yourself. This is the most ideal type of OS
fingerprinting for an attacker because it allows them to be stealthy.
That being said, how can we determine what operating system a host is running based upon
nothing but the packets it sends? Well, this is actually pretty easy and is made possible by the
lack of specificity in the protocol specifications as defined by protocol RFCs. Although the
various fields that are contained in TCP, UDP, or IP headers are very specific, there are typically
not default values for these fields defined. This means that the TCP/IP stack implementation in
each different operating system must define its own default value for these fields. Table 9-1
contains a list of some of the more common fields and the default values that can be used to link
them to various operating systems.
Table 9-1: Common Passive Fingerprinting Values
Protocol
Field
Header
IP
Don’t Fragment Flag
IP
Max Segment Size
TCP
TCP
OS
Value
Initial Time to Live
IP
Default
Window Size
SackOK
64
NMap, BSD, Mac OS 10, Linux
128
Novell, Windows
255
Cisco IOS, Palm OS, Solaris
Set
BSD, Mac OS 10, Linux, Novell, Windows, Palm OS, Solaris
Not Set
Nmap, Cisco IOS
0
Nmap
1440
Windows, Novell
1460
BSD, Mac OS 10, Linux, Solaris
1024-4096
Nmap
65535
BSD, Mac OS 10
2920-5840
Linux
16384
Novell
4128
Cisco IOS
24820
Solaris
Variable
Windows
Set
Linux, Windows, OpenBSD
Not Set
Nmap, FreeBSD, Mac OS 10, Novell, Cisco IOS, Solaris
The packets contained in the file passiveosfingerprinting,pcap are great examples of this
technique. In this file there are two packets. Both packets are TCP SYN packets sent to port 80,
but from different hosts. Using only the values contained in these packets and the table above we
should be able to determine the operating system architecture in use on each host. The details of
each packet are shown in Figure 9-7.
Figure 9-7: These packets can tell us which operating system architecture they were sent from
Using table 9-1 as a reference point we can create table 9-2, which is a breakdown of the
relevant fields in these packets.
Table 9-2: Breakdown of the OS fingerprinting packets in this field
Protocol
Field
Packet 1 Value
Packet 2 Value
IP
Initial Time to Live
128
64
IP
Don’t Fragment Flag
Set
Set
IP
Max Segment Size
1440 Bytes
1460 Bytes
TCP
Window Size
64240 Bytes
2920 Bytes
TCP
SackOK
Set
Set
Header
Based upon these values we can conclude that packet 1 was most likely sent by a device
running Windows and packet 2 was most likely sent by a device running Linux. Keep in mind
that the listing of common passive OS identifying fields is by no means exhaustive and that there
are many quirks that may result in deviations from these expected values. Results gained from
passive OS fingerprinting should never be fully relied on as a result of this.
Note: Being able to analyze OS identifying fields in a packet capture manually is a useful skill,
but wouldn’t it be easier if there was a way to automate this? Fortunately somebody else
had this same though, and the p0f tool was created. P0f is a tool that runs on a packet
capture, analyzes relevant fields, and outputs the suspected operating system. Using tools
like p0f you can not only get the OS architecture, but sometimes even get the appropriate
version or patch level. You can download p0f at http://lcamtuf.coredump.cx/p0f.shtml.
Active Fingerprinting
When passively monitoring traffic doesn’t yield the right results then a more direct approach
may be called for. This approach is called active fingerprinting because it involves the attacker
actively sending specially crafted packets to the victim in order to elicit replies which can result
in the identification of the operating system in use on the victim. Of course, this approach
involves directly communicating with the victim so it is not the least bit stealthy, but can be
highly effective.
The file actievosfingerprinting.pcap contains an example of an active OS fingerprinting scan
initiated with the Nmap scanning utility. There are several packets contained here that are a
result of Nmap sending out different probes designed to elicit responses that will allow for OS
identification. Nmap records the responses to these probes and builds a fingerprint that is
compared to a database of values to make an OS determination. The techniques used by Nmap to
actively fingerprint an OS are quite complex and beyond the scope of this book, but I’ve
included this capture file for reference. If you are interested in learning more about how Nmap
does active OS fingerprinting then I recommend reading the definitive source on Nmap, “Nmap
Network Scanning” written by the tools author Gordon “Fyodor” Lyon.
Exploitation
The exploitation phase is what every attacker lives for. At this point the attacker has done his
research, performed adequate reconnaissance on the target, has found a vulnerability, and is
prepared to exploit that vulnerability to gain access to the target system. In this section we will
look at packet captures of various exploitation techniques including a recent Microsoft
vulnerability exploit, a TFTP server vulnerability exploit, data exfiltration via an unconventional
channel, and traffic redirection via ARP cache poisoning.
Operation Aurora
Unless you were living under a rock during the entire month of January 2010 then you most
likely have heard of the term Aurora as it pertains to network security. Operation Aurora refers
to the computer network attacks used against Google and various other companies that exploited
an unknown vulnerability in Internet Explorer allowing attackers to gain remote root level
control of the targeted machines.
In order to execute this malicious code all that a user needed to do is visit a website with a
vulnerable version of Internet Explorer and the attacker then has access to the machine with
administrative privileges. Spear phishing was utilized against the targets in order to get them to
click links that led to the site hosting the malicious code. Spear phishing is a form of e-mail fraud
in which an attacker sends an e-mail to a victim that appears to be legitimate and is targeted
directly at that victim. Since spear phishing messages appear to come from trusted sources, they
will often be successful in getting the victim to clink links within the body of the message.
We pick up this story as soon as the targeted user clicks the link provided in the spear
phishing e-mail. The packets resulting in this are contained in the file aurora.pcap.
This capture begins with a three way handshake between the victim (192.168.100.206) and
the attacker (192.168.100.202). This initial connection is to port 80 which would lead us to
believe this is HTTP traffic. That assumption is confirmed in the fourth packet which is an HTTP
GET request for /info  (Figure 9-8).
Figure 9-8: The victim makes a GET request for /info
The attackers machine acknowledges receipt of the GET request and reports a response code
of 302 (Site Moved) in packet 6. This status code is commonly used to redirect a browser to
another site which is exactly what is happening here. Along with the 302 response code
there is also a Location field which specifies a location of /info?rFfWELUjLJHpP  (Figure 99).
Figure 9-9: The client browser is redirected with this packet
After receiving the HTTP 302 packet, the client initiates another GET request to the
/info?rFfWELUjLJHpP URL in packet 7, for which an ACK is received in packet 8. Following
the ACK, the next several packets represent data being transferred from the attacker to the
victim. We can take a closer look at that data by right clicking one of the packets in the stream,
such as packet 9, and selecting Follow TCP Stream (Figure 9-10).
Figure 9-10: The data stream being transmitted to the client
In this stream output we can see the initial GET request, the 302 redirection, and the second
GET request. It’s after this that things starting getting really odd. The attacker responds to the
GET request with some very odd looking content. The first section of this content is shown in
Figure 9-11.
Figure 9-11: This scrambled content within a <script> tag appears to be encoded
This content appears to be a series of random numbers and letters inside of a <script> tag .
The <script> tag is used within HTML to denote the use of a higher level scripting language.
Within this tag you should normally see various scripting statements but this gibberish indicates
that the content we are seeing may be encoded in order to hide it from detection. Given the
context that we know this is exploit traffic, it might be safe to assume that this obfuscated section
of text contains the hexadecimal padding and shellcode used to actually exploit the vulnerable
service.
The second portion of the content sent from the attacker is shown in Figure 9-12.
Figure 9-12: This portion of the content sent from the server contains readable text and a
suspicious iframe
After the encoded text we finally see text that is readable. Without needing to have extensive
programming knowledge this text appears to do some string parsing based upon a few variables.
This is the last bit of text before the closing </script> tag.
The last section of data sent from attacker to client has two parts. The first of these is a <span
id="vhQYFCtoDnOzUOuxAflDSzVMIHYhjJojAOCHNZtQdlxSPFUeEthCGdRtiIY"> section 
and the second is contained within the <span></span> tags and is <iframe
src="/infowTVeeGDYJWNfsrdrvXiYApnuPoCMjRrSZuKtbVgwuZCXwxKjtEclbPuJPPctcflhsttM
RrSyxl.gif" onload="WisgEgTNEfaONekEqaMyAUALLMYW(event)" /> . Once again, this
content is a sign of malicious activity due to the nature of the long random strings of obfuscated
text.
The portion of the code contained within the <span> tag is an iframe. An iframe is a very
common method for an attacker to embed additional unexpected content into an HTML page.
This tag creates an inline frame that can go undetected by the user. In this case the iframe
contains reference to an oddly named GIF image file. When the victims browser sees the
reference to this file it makes a GET request for it in packet 21  and the GIF is sent
immediately following that  (Figure 9-13). It is likely that this GIF is actually used to
somehow trigger the exploit code that has already been downloaded to the victim.
Figure 9-13: The GIF specified in the iframe is requested and downloaded by the victim
The most peculiar part of this capture occurs at packet 25 when the victim initiates a
connection back to the attacker on port 4321. Viewing this second stream of communication
from the packet details window doesn’t yield much information so we will once again view the
TCP stream of the communication get a clearer picture of the data being communicated (Figure
9-14).
Figure 9-14: The attacker is interacting with a command shell through this connection
In this display we see something that should set off immediate alarms: a Windows command
shell . This shell is sent from the victim to the server, indicating that the exploit attempt by the
attacker was successful and the payload was setup such that the client shoveled a command shell
back to the attacker once the exploit was launched. In this capture we can even see the attacker
interacting with the victim by entering the dir command  to view a directory listing . An
attacker with access to this command shell has unrestricted administrative access to the victim
machine and can do virtually anything he wishes to it.
The victim has just given control of his computer to an attacker with only a single click in a
matter of a few seconds. At this point you’ve witnessed the attacker launch a very sophisticated
attack against a victim, successfully exploit a vulnerability on that victim system, and launch a
payload that results in a command shell being sent back to the attacker. It’s typical of exploits
like this to be encoded so that they are not recognizable when going across the wire. This is done
in order to prevent these exploits from being picked up by network intrusion detection systems.
Without prior knowledge of this exploit or even a sample of the exploit code it might be difficult
to tell exactly what it is doing on the victim system without further analysis of that system.
Luckily for us, we were able to pick out some tell tale signs of malicious code in this packet
capture. This includes the obfuscated text in the <script> tags, the peculiar iframe, and the
command shell seen in clear text.
Just for the purpose of completeness, here is an overview of how the Aurora exploit we’ve
just viewed works:
The victim receives a targeted e-mail from the attacker that appears to be legitimate and
clicks a link within it.
The victim issues a GET request to the attackers malicious site.
The attackers web server issues a 302 redirection to the victim.
The victim issues a GET request to the redirected URL.
The attackers web server transmits a webpage containing obfuscated javascript code to
the client that includes a vulnerability exploit and an iframe containing a link to a
malicious GIF image.
The victim issues a GET request for the malicious image and downloads it from the
server.
The javascript code transmitted earlier is deobfuscated using the malicious GIF and the
code executes on the victim. This code exploits a vulnerability in Internet Explorer.
Once exploited, the payload hidden within the obfuscated code is executed. This payload
opens a new session from the victim to the attacker on port 4321.
A command shell is spawned from the payload and shoveled back to the attacker so that
he may interact with it.
From a defenders point of view we can use this capture file to create a signature for our
intrusion detection system that might help capture further occurrences of this attack. For
example, this could be done by filtering on a non obfuscated part of the capture such as the clear
text code seen at the end of the obfuscated text in the <script> tag. Another train of thought
might be to write a signature for all 80 traffic with a 302 redirection to a site with “info” in the
URI.
Being able to create traffic signatures based upon malicious traffic samples is a crucial step
for someone attempting to defend a network against unknown threats, and captures such as this
are a great way to develop skills in writing those signatures. If you are interested in learning
more about intrusion detection and attack signatures I suggest looking into the Snort project
(http://www.snort.org) and some of its associated documentation/books.
ARP Cache Poisoning
We discussed ARP cache poisoning in Chapter 2 as a useful means of tapping into the wire and
intercepting traffic of hosts whose packets you need to analyze. When used in a legitimate
manner ARP cache poisoning is effective and useful for a network engineer. However, when
used with malicious intent this technique is also a very lethal form of man-in-the-middle attack.
A man-in-the-middle (MITM) attack is any attack where an attacker redirects traffic between two
hosts in such a way that it can be intercepted or modified in transit. There are many lethal forms
of MITM attacks including session hijacking, DNS spoofing, and SSL hijacking.
You already know how to execute ARP cache poisoning for legitimate purposes. That being
said, this is the security chapter, so this section is focused on showing you how ARP cache
poisoning works at the packet level so that you can detect when it is being used for malicious
purposes.
As a recap, remember that ARP cache poisoning works because of specially crafted ARP
packets that trick two hosts into thinking they are communicating with each other when in fact
they are communicating with a third party who is relaying packets back and forth as an
intermediary. There is an example of this in the file arppoison.pcap.
At first glance this traffic appears normal. If you follow through the packets you will see the
host that is our victim in this case, 172.16.0.107, browsing to Google and performing a search.
As a result of this there is quite a bit of HTTP traffic with some DNS queries mixed in.
We know that ARP cache poisoning is a technique that occurs at layer two, so if we are just
casually perusing through the packets in the packet list window it may be hard to see if any foul
playing is going on. In order to give us a leg up we will add a couple of columns to the packet
list window.
In order to add these columns:
Click Edit on the main drop-down menu and select Preferences
Click Columns on the left side of the dialog
Click Add
Type Source MAC and press Enter
In the Field type drop-down, select Hw src addr (resolved)
Click on the newly added entry and drag it so that it is directly after the Source column
Click Add
Type Dest MAC and press Enter
In the Field type drop-down, select Hw dest addr (resolved)
Click on the newly added entry and drag it so that it is directly after the Destination
column
Click OK the apply the changes
When you have completed this, your screen should look similar to Figure 9-15.
Figure 9-15: The column configuration screen with newly added columns for source and
destination hardware addresses
You should now have the two additional columns showing the source and destination MAC
addresses of the packets. If you still have MAC name resolution turned on then you should see
that communicating devices have MAC addresses that are indicative of Dell and Cisco hardware.
This is very important to remember, because as we scroll through the capture this changes at
packet 54 when we see some peculiar ARP traffic occurring between the Dell host (our victim)
and a newly introduced HP host (the attacker) (Figure 9-16).
Figure 9-16: Strange ARP traffic between the Dell device and an HP device.
Before proceeding further let’s take note of the endpoints involved in this communication as
this example might get a bit confusing. These are listed in Table 9-3.
Table 9-3: Endpoints being monitored
Role
Device Type
IP Address
MAC Address
Victim
Dell
172.16.0.107
00:21:70:c0:56:f0
Router
Cisco
172.16.0.1
00:26:0b:21:07:33
Attacker
HP
Unknown
00:25:b3:bf:91:ee
Now that I’ve told you this traffic is strange, what makes it strange? If you remember back to
our discussion of ARP in Chapter 6, there are two primary types of ARP packets, a request and a
response. The request packet is sent as a broadcast to all host on the network in order to find who
has the MAC address associated with a particular IP address. The response is then sent as a
unicast packet from whoever answers the request back to the device that transmitted the request.
Given this, there are a few peculiar things we can find by examining this communication
sequence.
First, packet 54 is an ARP request sent from the attacker, who has a MAC address of
00:25:b3:bf:91:ee, but instead of being broadcast to all hosts on the network segment it is sent as
a unicast packet directly to the victim, whose MAC is 00:21:70:c0:56:f0 . Notice that this type
of request should be a broadcast packet to all hosts on the network, but it is targeted directly at
the victim. Also, notice that although this packet is sent from the attacker and includes the
attackers MAC address in the ARP header, it lists the routers IP address rather than its own.
This packet is followed by a response from the victim to the attacker with its MAC address
information . The real voodoo here occurs in packet 56, when the attacker sends a packet to the
victim with an unsolicited ARP reply telling it that 172.16.0.1 is located at its MAC address of
00:25:b3:bf:91:ee . The problem with this is that the MAC address of 172.16.0.1 isn’t
00:25:b3:bf:91:ee, it is actually 00:26:0b:31:07:33. We know this because we’ve just been
witnessing 172.16.0.1 (the router) communicating with the victim earlier in the packet capture.
Since the ARP protocol is inherently insecure in that it accepts unsolicited updates to its ARP
table, the victim will now being sending traffic that is supposed to be going to the router to the
attacker instead.
Keep in mind that this packet capture was taken from the victim machine, so you don’t seen
the entire picture. In order for this to work the same sequence of packets has to be sent to the
router in order to trick it into thinking the attacker is actually the victim, but we would have to
take another packet capture from the router (or the attacker) in order to see those packets. Once
both parties have been duped it means that communication between the victim and the router is
now flowing through the attacker. This entire process is shown in Figure 9-17.
Figure 9-17: ARP cache poisoning as a MITM attack
Success of this attack is confirmed immediately by looking at packet 57. If you compare this
with a packet occurring before the mysterious ARP traffic, such as packet 40, you will see that
the IP address of the remote server (Google) remains the same , but the target MAC address
has changed  (Figure 9-18). This change in MAC address means that the traffic is now being
routed through the attacker before it gets to the router.
Figure 9-18: The change in target MAC address shows this attack was a success
Because of the subtlety of this attack it is very difficult to detect and typically requires the aid
of an IDS configured specifically to detect this type of attack or software running on individual
devices that can detect sudden change in ARP table entries. Since you will most likely being
using ARP cache poisoning to capture packets on networks you are analyzing it’s important to
know how this technique can be used against you as well, which is why this section exists.
Remote Access Trojan
Thus far we’ve examined security events from the perspective of knowing what we have before
we begin looking at the capture. This is a great way to learn what attacks look like, but it’s not
too realistic of a real world situation. In most real world scenarios someone tasked with
defending a network won’t be examining every single packet that goes across the network.
Instead, they will be utilizing some form of intrusion detection system (IDS) that will alert the
analyst to an anomaly in the network traffic that warrants examining based upon a predefined
attack signature.
In this example, we are going to begin just as our intrusion analyst does, with a simple alert.
In this case, the alert our IDS generates is:
[**] [1:132456789:2] CyberEYE RAT Session Establishment [**]
[Classification: A Network Trojan was detected] [Priority: 1]
07/18-12:45:04.656854 172.16.0.111:4433 -> 172.16.0.114:6641
TCP TTL:128 TOS:0x0 ID:6526 IpLen:20 DgmLen:54 DF
***AP*** Seq: 0x53BAEB5E
Ack: 0x18874922
Win: 0xFAF0
TcpLen: 20
Based upon this alert it would do us well to view the signature rule that triggered this alert,
which is:
alert tcp any any -> $HOME_NET any (msg:"CyberEYE RAT Session Establishment";
content:"|41 4E 41 42 49 4C 47 49 7C|"; classtype:trojan-activity;
sid:132456789; rev:2;)
Of course, this isn’t a book about intrusion detection or Snort so I don’t expect you to be able
to break down every component of the alert or rule. For our purposes, you should know that the
rule shown above is set to alert whenever it sees a packet from any network entering the internal
network with the hexadecimal content 41 4E 41 42 49 4C 47 49 7C. This content converts to
ANA BILGI| in readable ASCII. When detected, an alert fires signifying potential prescense of
the CyberEYE Remote Access Trojan (RAT). RATs are malicious programs that sun silently on a
victims computer and connect back to an attacker so that the attacker can perform remote
administration of the victim machine. In this case, CyberEYE is a very popular Turkish-born tool
for creation of RAT executables and administration of compromised hosts. Coincidentally
enough, the Snort rule seen here is firing on the string ANA BILGI, which is Turkish for
BASIC INFORMATION.
Now that we have some background information we can look at some traffic associated with
the alert in the file ratinfected.pcap. This Snort alert would typically only capture the single
packet that triggered the alert but we have the fortune of having the entire communication
sequence between the hosts involved with the alert.
In order to skip to the punch line we can perform a search for the hexadecimal string
mentioned in the Snort rule. In order to do this:
Click Edit in the main drop-down menu
Select Find Packet
Select the Hex Value radio button
Type the value 41 4E 41 42 49 4C 47 49 7C into the text area
Click Find
When you do this it should bring to the first instance of this strings occurrence which is in the
data portion of packet two  (Figure 9-19).
Figure 9-19: The content string in the snort alert is first seen here in packet four
If you click Edit and then Find Next a few more times you will see that this string also
occurs in packets 5, 10, 32, 156, 280, 405, 531, and 652 as well. Although all of the
communication in this capture file is between the attacker (172.16.0.111) and victim
(172.16.0.114), it appears as though some instances of the string in question occur in different
conversations. This is evident in that while packets 4 and 5 are communicated using ports 4433
and 6641, most of the other instances occur between port 4433 and another randomly selected
ephemeral port. We can confirm the multiple conversations do indeed exist by looking at the
TCP tab of the Conversations window, shown in Figure 9-20.
Figure 9-20: Three individual conversations exist between the attacker and victim
One thing we can do to visually separate out the different conversations in this capture file is
to colorize them. There are a couple of ways to do this, but my preferred method is to do this:
Input the filter (tcp.flags.syn == 1) && !(tcp.flags.ack == 0) into the filter expression
dialog box above the packet list window and click Apply. This will select the initial SYN
packet for each conversation in the traffic.
Right click the first packet and select Colorize Conversation
Select TCP and then select the color of your choosing
Repeat this process for the remaining SYN packets, choosing a different color for each
When finished, click Clear to remove the filter
Now that we’ve colorized the conversations we can see how they relate to each other. This
will help us to better track the communication process between the two hosts. The first
conversation (ports 6641/4433) is where the communication between the two hosts begins so it is
a good place to start. You can click on any packet within the conversation and click Follow TCP
Stream to see the data that was transferred (Figure 9-21).
Figure 9-21: The first conversation yields interesting results
Immediately we see that the text string ANABILGI|556 is sent from the attacker to the
victim . As a result, the victim responds with some basic system information including the
computer name (CSANDERS-6F7F77) and the operating system (Windows XP Service Pack 3)
. After doing this it begins transmitting the same string of BAGLIMI? back to the attacker .
The only communication coming back from the attacker is the string CAPSCREEN60 , which
appears 6 times.
This CAPSCREEN60 string being sent from the attacker seems interesting so we will
examine this further to see if it leads to any positive conclusions. In order to do this we can
search for the text string within the packets by using the search dialog again but this time
specifying the String option. When you perform this search the first instance of the string that is
found is in packet 27. The intriguing thing about this is that immediately after the string is sent
from attacker to client, the client acknowledges receipt of the packet and a new conversation is
started in packet 29. If we follow the TCP stream output of this new conversation then we see the
familiar string ANABILGI|12 followed by the string SH|556 and finally, the string
CAPSCREEN|C:\WINDOWS\jpgevhook.dat|84972 . It’s interesting that there is a file path
specified after the CAPSCREEN string, and that this is followed by unreadable text. The most
intriguing thing here is that the unreadable text is prepended by the string JFIF , which a quick
Google search will tell you are commonly found at the beginning of JPG files.
Figure 9-22: The attacker appears to be initiating a request for a JPG file
At this point it’s safe to say that this conversation is setup for the purpose of transferring this
JPG image. Most importantly however we are starting to see a command structure evolve from
the traffic. It appears that CAPSCREEN is a command sent by the attacker that is used to
initiate the transfer of this JPG image from victim to attacker. If you were to actually perform
some data extraction and hex editing from this TCP stream you would see that the image is a
screenshot of the victims desktop.
At this point it may be safe to assume that whenever the CAPSCREEN command is sent that
the result will be the same. You can verify this individually by viewing the stream of each
conversation, or for a more condensed snapshot you can try using the IO graphing feature. In
order to do this:
Select Statistics from the main drop down menu and click IO Graphs
Insert the filters tcp.stream eq 2, tcp.stream eq 3, tcp.stream eq 4, tcp.stream eq 5,
and tcp.stream eq 6 into the five filter dialog boxes respectively.
Click the Graph 1, Graph 2, Graph 3, Graph 4, and Graph 5 buttons to enable the data
points for the filters specified.
Change the Y Axis scale to Bytes/Tick
Figure 9-23: This graph shows the same activity appears to be repeating
Based upon this graph it appears as though each conversation contained the same amount of
data and occurred for the same time duration. Based upon this we can conclude that this activity
is repeating several times. After this has completed the communication ends with a normal TCP
teardown sequence.
Although this example was very clear cut it is a prime example of the thought process an
intrusion analyst would go through when analyzing traffic based upon an IDS alert. In this case
we looked at the alert and the signature that fired it, validated that what the signature said was in
the traffic was indeed in it, and dug into the traffic to find out exactly what the attacker had done
with the compromised machine. At this point incident response would begin and containment of
the issues would be a priority before any more sensitive information leaked from the
compromised victim.
Final Thoughts
Although this chapter was devoted to security it wasn’t nearly enough. Many other books could
be written on breaking down packet captures in security related scenarios, analyzing common
attacks, and responding to intrusion detection system alerts. In this chapter we examined some
common scanning and enumeration types, looked at a common man-in-the-middle attack, and
examined two very modern and very relevant examples of how a system might get exploited and
what might happen after it is exploited. If this chapter interests you then be sure and read Chapter
11 for some other resources relating to packet analysis as a function of network security.