Packet Forensics Part One: The Packet Anatomy

Introduction.

Computer attacks have grown to be overwhelmingly sophisticated. I don't mean it in a way that it's because current attacks are carried by ready-made programs, but rather because of the technique itself that is used to launch a successful attack today is quite extra-ordinary. As security measures evolve, new and smarter techniques are born. With most attacks, they are usually done remotely (unless the hacker is great with social engineering and gets a pass into the organization's system). When we approach a computer network breach, we most definitely need to know exactly what has happened --trying to find out what are the steps taken and tools used by the attacker. Moreover, it's to find out what is indeed lacking on the target's security.

I'm writing this article in order to arm you with the basic knowledge to perform packet forensics which will allow you to understand what is really going on on your network. This will also be one of the indicators if there's a breach on your network. Consider this as "part one" of an entire write-up about packet forensics wherein the scope of this article would only be on how to dissect packets and understanding the packet structure. The analysis of the application layer data would be on a separate document--part 2. And a simple installation and usage of Snort to monitor your network on part 3. Again, this article would focus on the basics --the knowledge that you require in order to conduct packet forensics.

What is packet forensics? (What is the purpose of packet forensics? Why do we do such?)

Packet forensics is the process of analyzing packet captures (and binary log files), even live packets, to find out the nature of the attacks that occurred on the network. It includes building up the details of how the attack was conducted, technique and tools used, and any factors that would have an effect towards the success of the attack. Packet forensics is somehow deriving the whole picture with just the use of the packet captures you have.

Well, it's not always the case wherein you get your analysis right all the time (like those in crime investigations). You can only come as close as what you have unearthed with the packet capture data you have with you. Moreover, different analysts will have their own idea on how the attack came about. That is why it's always good to ask for consults with your peers as it might help you connect the dots and see the bigger picture.

What are the information or "evidences" we analyze?

As said, packet forensics would deal with packet capture files or binary log files from different devices (depending if the devices are capable of producing one). The terms packet capture files or binary logs files can be used interchangeably, and for this article I will use the term packet capture files to refer to such. Packet capture files are snapshots of the network traffic taken by an interface (in promiscuous mode) at a specific location on the network. It enables us to "rewind" back to see what conspired on your network at a given location. The packet capture file format that we'll be using is the libpcap file format (which if not most, all packet capturing device and software use) and they can be read by well-known packet sniffers like Wireshark, Ethereal, Tcpdump, and Windump. Having a standard log file format and function library allows us to use many different tools to analyze a single log capture.

What are the cases wherein packet forensics can be conducted?

Any attacks that involves network traversal can be analyzed by packet forensics. Then again, you're analysis and conclusion can only go as much as what your data provides you. So one simple piece of advice, place your sniffers/sensors (you are not limited to just using one sniffer) on strategic locations wherein it can sniff all the packets coming in and out of your network.

What are the tools needed?

No proprietary software or hardware will be needed in order for you to conduct packet forensics. You just need some tools that will aid you in getting the necessary answers you need. The set of tools that we will be using are as follows:

* tcpdump/windump - sniffer [tcpdump and windump website]
* Wireshark/Ethereal - sniffer and protocol analyzer (we won't be using Wireshark/Ethereal for this article, but you are free to use it to look how a packet looks like) [Wireshark and Ethereal website]
* Snort - IDS [www.snort.org] With this article, we won't be covering all the features of each tool that we will be using, but just the essential features that will aid us in accomplish our task. For more information about each of the tools here, check out their respective website.

The Packet Anatomy.

To fully understand packets, one must have basic understanding of how the IP and TCP protocols work. These include understanding IP addresses, TCP flags (states), sequence and acknowledgment numbers, and the TCP three-way handshake. Generally, its knowing how IP addressing works, communication between hosts, etc. Let's get down to business. Below are Figure 1.1 and Figure 1.2 that shows how a packet looks like logically.

FIGURE 1.1. Packet Logical Structure (IP)

FIGURE 1.2. Packet Logical Structure (TCP)

For more details about the logical structures (field values, etc), you can review it here.

Using TCPDUMP.

So how does a packet look like on the wire? What we will do next is to open a packet capture file using tcpdump with the appropriate switches to see how a packet looks like. Like I said, for this article, I won't be using Wireshark or Ethereal to show you how a packet looks like. Wireshark and Ethereal will provide you a better way of presenting you the structure of a packet. I just choose to use tcpdump because I prefer working on a shell (don't let my preference hinder yours, it's up to you if you want to use Wireshark or Ethereal).

tcpdump can be used to read packet capture files and sniff on a given interface. To enable tcpdump to read a packet capture file, we use the -r switch followed by the packet capture file. Here is an example.

ice@thesecuredbox ~$ tcpdump -r samplecapture.pcap

To enable tcpdump to sniff on an interface, we use the -i switch followed by the name of the interface (for Linux, it will be the name of the interface. For Windows, it will be the number). Here is an example.

ice@thesecuredbox ~$ tcpdump -i eth0 (Linux)
or
C:\> tcpdump -i 1 (Windows)

Here is the simple explanation of the switches that I'll be using to get an output below.
* -n : Don't resolve IP to hostnames.
* -X : Show the packet's contents in both hex and ASCII.
* -vvv : Increase the amount of packet information you get back.
* -c : Only get x number of packets and then stop.
* -S : Print absolute sequence numbers.

ice@thesecuredbox ~$ tcpdump -nvvvXS -r samplecapture.pcap

tcpdump provides simple ways of decoding what they have captured on the wire or in the capture file. In Figure 2. The lines that are highlighted in orange are the decode hex values of the packet done by tcpdump. The lines that are highlighted in yellow are the source and destination IP addresses, and the lines that are highlighted in red are the source and destination ports respectively. With the proper labels, you can easily determine what the field is and its value. What we will be concerned with are the lines that are in hex values. The hex values are the raw values of the packet.

FIGURE 2 TCPDUMP output

So okay, what does this output of ours mean? Okay, let's take this byte per byte. This output of ours is 48 bytes long. A packet is divided into chunks of 32 bits (8 bytes) as shown in Figure 1. If you would notice the way the packet is addressed, if it were in memory, are in increments of 16 bytes. 0x0000 to 0x0010 translates to byte 0 to byte 16 when converted to decimal numbers. tcpdump shows us the raw packet in chunks of 64 bits (16 bytes).

Now, Figure 3 will match the logical structure of the packet, to how it really looks like, raw.

FIGURE 3. Packet Structure

Conclusion.

This article mainly discussed the structure of a TCP/IP packet and how it looks like on the wire. What we will discuss in the Part Two of Packet Forensics series is the different factors that affect packet forensics. This will entail us in looking at the SEQ and ACK numbers, ports, IP addresses, activity duration, and packet payload. Finally, after performing all of these steps to gather vital information, we will finally perform analysis to determine what application or tool was used and what malicious payload are seen.

If you have any questions, inquiries, or suggestions, feel free to leave a comment and we'll be happy to respond.