Tag Archives: wireshark

Packet Carving with SMB and SMB2

One of the more useful network forensic skills is the ability to extract files from packet captures. This process, known as packet data carving, is crucial when you want to analyze malware or other artifacts of compromise that are transferred across the network. That said, packet data carving has varying degrees of difficulty depending on the type of traffic you are attempting to extract data from. Carving files from simple protocols like HTTP and FTP is something that can be done in a matter of minutes and is usually cut and dry enough that it can be done in an automated fashion with tools like Foremost and Network Miner.

There are articles all over the Internet about carving files from simple protocols so I won’t rehash those. Instead, I want to take a look at a two more complex protocols that are extremely common in production networks. Server Message Block (SMB) is the application-layer protocol that Microsoft operating systems use for file sharing and communication between networked devices. If you live on a Microsoft network (or a Unix network that utilizes SAMBA) then you are a user of SMB or SMB2, depending on your operating system version. In this article I’m going to discuss the art of carving files from SMB and SMB2 traffic. If you want to follow along you’ll need to download a copy of Wireshark (http://www.wireshark.org) and your favorite hex editor. I’ve used Cygnus Hex Editor (http://www.softcircuits.com/cygnus/fe/) for the purpose of this article since it’s simple and a free version exists.

 

Carving Files from SMB Packets

 

The first version of SMB is in use on all modern Microsoft operating systems prior to Windows Vista. In order to setup a packet capture for this scenario I took two Windows XP SP3 virtual machines running on VMWare Workstation and placed them in the same network. Once they were able to communicate with each other I setup a shared folder on one host (192.168.47.132) that is acting as the server. I then fired up Wireshark and began capturing packets as I copied an executable file from the client (192.168.47.133) to the servers shared folder. The resulting packet capture is called smb_puttyexe_xfer.pcap.

If you’ve never looked at SMB traffic then don’t get scared by all the different types of SMB packets in the capture, we will only be looking at a few of them. This article isn’t meant to be an exhaustive reference on each and every type of SMB packet (there are over a hundred of them), so if you want the gory details then take a look at the references at this end of this article.

In order to carve the file out of these packets we have to find some basic information about it. Before and after transferring a file to a server the client will attempt to open the file in order to see if it exists. This is done with an SMB NT Create AndX Request packet.  The response from the server to this is an SMB NT Create AndX Response, which contains the name, extension, and size of the file being transferred. This is everything we need to get started. You can filter for Create AndX Response packets in Wireshark with the filter (smb.cmd == 0xa2) && (smb.flags.response == 1). If we examine one of those requests that occur after the file has been transferred, we can identify that the file being transferred is putty.exe and its file size is 454,657 bytes. We will use this information later.

Figure 1: Note the file name, extension, and size.

The next step we have to take in order to extract this file is to isolate the appropriate block of traffic. Wireshark makes this pretty easy with its Follow TCP Stream functionality. Start by right-clicking any packet in the capture file and selecting Follow TCP Stream. This will bring up a window that contains all of the data being transferred in this particular communication stream concatenated together without all of the layer 2-4 headers getting in the way. We are only concerned about the traffic transferred from the client to the server so we will need to specify this in the directional drop down box by selecting 192.168.47.133 –> 192.168.47.132 (458592 bytes). Click Save As and save the file using the name putty.raw.

Figure 2: Saving the isolated traffic from Wireshark

If you were to view the properties of the data you just extracted and save you should find that its file size is 458,592 bytes. This is 3,935 bytes more than the size of the actual file that was transferred. This means that our goal is to get this raw files size down to exactly 454,657 bytes. This is where the real carving begins.

First things first, we have to delete all of the extra data that occurs before the executable data actually begins. Since we do know that the transferred file is an executable the quickest way to do this is to look for the executable header and delete everything that occurs before it. The executable header begins with the hex bytes 4D 5A (MZ in ASCII), which occurs approximately 1112 bytes into the putty.raw file. Once deleted, resave the file as putty.stage1. You should now be down to a file size of 457,480 bytes.

Figure 3: Removing added bytes from the beginning of the file

Now things get a bit trickier. SMB transmits data in blocks. This is great for reliability since a lost or damaged block can be retransmitted, but it adds some extra work for us. This is because each block must contain some bytes of SMB header data in order to be interpreted correctly by the host that is receiving it. The good thing is that the size of this data is somewhat predictable, but you have to understand a bit more about SMB in order to put the rubber to the road. The thing to know here is that the data block size in SMB is limited to 64KB, or 65536 bytes.  Of this amount, only 60KB is typically used for each block. These 61,440 bytes are combined with an additional 68 bytes of SMB header information. This means that after every 61,440 bytes of data we will have to strip out the next 68 bytes.

There is one thing to add to this that must be taken into consideration before stripping out those bytes. As a part of the normal SMB communication sequence, an additional packet is sent right after the first block. This is an NT Trans Request packet, which is packet 77 in the capture file. The SMB portion of this packet is 88 bytes, which means we will have to remove those 88 bytes in addition to the 68 bytes that make up the normal SMB block header, for a total of 156 bytes.

Now that we have all that sorted out let’s start removing bytes. In your hex editor, skip one byte past the 61,440th byte. This will be offset 0x0F000. You should start with this byte and select a range of 156 bytes and delete them. Save this file as putty.stage2.

Figure 4: Removing the initial 156 bytes

Things get a bit easier now as we are just concerned with stripping out the 68 bytes after every block. Skip through the file in 61,440 byte increments deleting 68 bytes each time. This should occur X times in this file at offsets 0x1e000, 0x2d000, and 0x3c000, 0x4b000, 0x5a000, 0x69000. Once finished, save the file as putty.stage3.

Figure 5: Removing a 68 byte SMB header block

Go ahead and take a look at the file size of putty.stage3. We are still XXX bytes off from our target, but luckily the last part is the easiest. The data stream is actually just padded by some extra information that needs to be deleted. We know that the file should be 454,657 bytes, so browse to that byte and delete everything that occurs after it.


Figure 6: Trimming the extra bytes off the end of the file

Save the final product as putty.exe and if you did everything right, you should have a fully functioning executable.

Figure 7: Success! The executable runs!

 

The whole process can be broken down into a series of repeatable steps:

  1. Record the file name, extension, and size by examining one of the SMB NT Create AndX Response packets
  2. Isolate and extract the appropriate stream data from Wireshark by using the Follow TCP Stream feature and selecting the appropriate direction of traffic
  3.  Remove all of the bytes occurring before the actual file header using a hex editor
  4. Following the first 61,440 byte block, remove 156 bytes
  5. Following each successive 61,440 byte block, remove 68 bytes
  6. Trim the remaining bytes off of the file so that it matches the file size recorded in step 1

 

Carving Files from SMB2 Packets

 

Microsoft introduced SMB2 with Windows Vista and began using it with its newer operating systems moving forward. In order to setup a packet capture for this scenario I took two Windows 7 (x32) virtual machines running on VMWare Workstation and placed them in the same network. Once they were able to communicate with each other I setup a shared folder on one host (192.168.47.128) that is acting as the server. I then fired up Wireshark and began capturing packets as I copied an executable file from the client (192.168.47.129) to the servers shared folder. The resulting packet capture is called smb2_puttyexe_xfer.pcap.

You should notice that this traffic is a little bit cleaner than the SMB traffic we looked at earlier. This is because SMB2 is optimized so that there are a lot less commands. Whereas SMB had over a hundred commands and subcommands, SMB2 only has nineteen. Regardless, we still need to find the filename being transferred and the size of that file. One of the best places to do this is at one of the SMB2 Create Response File packets. This packet type serves a purpose similar to that of the SMB NT Create AndX Response packet. You can filter these out in Wireshark with the filter (smb2.cmd == 5) && (smb2.flags.response == 1). The last one of these in the capture, which is packet 81, is the one we want to look at since it occurs after the file transfer is complete. This identifies the file name as putty.exe and the file size as 454,656 bytes. This is indeed the same file as our earlier example, but it is being reported as being one byte smaller. The missing byte is just padding at the end of the file and has a null value so it’s not of any real concern to us.

Figure 8:  Once again we note the file name, extension, and size

At this point you should perform the same steps as we did earlier to isolate and extract the data stream from the capture using Wiresharks Follow TCP Stream option. Doing this should yield a new putty.raw file whose file size is 459,503 bytes. This is 4,847 too big, so it’s time to get to carving.

Once again we need to start by stripping out all of the data before the executable header. Fire up your favorite hex editor and remove everything before the bytes 4D 5A. This should account for a deletion of 1,493 bytes.

Figure 9: Removing the extra bytes found prior to the executable header

Now things change a bit. SMB2 works in a method similar to SMB, but it actually allows for more data to be transferred at once. SMB had a maximum block size of 64K because it has a limit of 16-bit data sizes. SMB2 uses either 32-bit or 64-bit data sizes, which raises the 64KB limit. In the case of the transfer taking place in the sample PCAP file, these were two 32-bit Windows 7 hosts under their default configuration which means that the block size is set at 64KB. Unlike SMB however, the full 64KB is used, so we will see data in chunks of 65,536 bytes being transferred. These 65,536 bytes combine with a 116 byte SMB2 header to form the full block.

SMB2 doesn’t include an additional initial request packet like the SMB Trans Request, so we don’t have to worry about stripping out any extra bytes right off the bat. As a matter of fact, some might say that carving data from SMB2 is a bit easier since you only have to strip out 116 bytes after each block of 65,536 bytes. You can do this now on putty.stage1. In doing so you should be deleting 116 bytes of data at offsets 0x10000, 0x20000, 0x30000, 0x40000, 0x50000and 0x60000.

Figure 10: Removing 116 bytes of data following the first 65,536 chunk

Once you’ve finished this save the file as putty.stage2. All that is left is to remove the final trailing bytes from the file. In order to do this, browse to by 454,656 and delete every byte that occurs after it.

Figure 11: Removing the final trailing bytes

Finally, save the file as putty.exe and you will have a fully functioning executable. The process of carving a file from an SMB2 data stream breaks down as follows:

  1. Record the file name, extension, and size by examining one of the SMB2 Create Response File packets
  2. Isolate and extract the appropriate stream data from Wireshark by using the Follow TCP Stream feature and selecting the appropriate direction of traffic
  3.  Remove all of the bytes occurring before the actual file header using a hex editor
  4. Following each successive 65,536 byte block (assuming a 64K block size), remove 116 bytes
  5. Trim the remaining bytes off of the file so that it matches the file size recorded in step 1

 

Conclusion

 

That’s all there is to it. I’ll be the first to admit that I didn’t cover every single aspect of SMB and SMB2 here and there are a few factors that might affect your success in carving files from these streams, but this article shows the overall process. Taking this one step farther, it’s pretty reasonable to assume that this process can be automated with a quick Python script, but this is something I’ve not devoted the time to yet. If you feel like taking up that challenge then be sure to get in touch and I’ll be glad to post your code as an addendum to this post. In the mean time, happy carving!

 

References

http://msdn.microsoft.com/en-us/library/cc246231%28v=PROT.10%29.aspx

http://msdn.microsoft.com/en-us/library/cc246482%28v=PROT.10%29.aspx

http://channel9.msdn.com/Blogs/Darryl/Server-Message-Block-SMB21-Drill-down

 

Keeping Capture Files Manageable

When you are capturing a lot of traffic the size of your capture files can grow really quickly. When this happens you are really going to have a hard time getting anything done when trying to sort through the file. There are a couple of things you can to do prevent this from happening.

Use an Effective Capture Filter

Capture filters are great when you know what you are looking for. If you ONLY want SMTP traffic, you can capture only that traffic. If you ONLY want to see HTTP POSTs, then you can capture only that traffic. If you aren’t sure what you are looking for then its bests to stick to capturing everything and using display filters, but when you have an eye on your target then capture filters are a great way to cut through the weeds. You will find this especially beneficial when capturing packets from a busy server or network segment.

Some of the things you can filter based upon include:

  • Specific Protocols
  • A Particular IP/MAC Address
  • Incoming/Outgoing Traffic Only

Split the Capture File as It’s Being Captured

Wireshark has some really great flexibility in allowing you to split a capture file as its being created. You can access this by selecting Capture from the main drop-down menu and selection Options, or by pressing Ctrl+K.

captureoptions

You have a couple of options here and they all become available to you when you place a check mark next to the Use Multiple Files box. There are two primary sections which I’ve creatively labeled the Multiple File and Stop Capture sections.

The multiple file section lets you specify a point at which a new file is created, either by reaching a certain size limit or at a certain time interval. I find that I typically use the size option for typical uses, but specifying a time interval for the packet capture can become very useful when you are trying to pinpoint when a certain event is happening. In this scenario you could start the capture at 12:00 and place and set the multiple file option to create the next file every 1 hour which should create a nice clean display of capture files by the hour.

It’s important to note that you can specify both of these criteria and in this case, a new file will be created when EITHER condition is met. In this top section you can also specify a maximum number of files to be created (don’t underestimate the value of this, I’ve accidentally filled up a hard drive on many occasions) and specify a ring buffer. A ring buffer uses a set number of files, and after the last file has been written it will begin overwriting the first file and cycling back through.

The stop capture section of this area is very straightforward and allows you to stop a capture after it reaches a certain point, either at a certain number of packets captured, a certain size limit, or a particular time interval. This comes in handy when you want to start a capture and run off to lunch or take a call.

Ensure You Are Capturing in the Best Location

One of the most overlooked parts of the packet analysis process is ensuring you are properly tapped into the network and getting the packets you need. Although the typical concern is whether or not you are getting enough packets, there are some cases in which you may be capturing TOO MUCH information. If you are having trouble weeding through a large capture file then you need to ask yourself if you really need to be where you are at. If it is a client/server issue, do you really need to capture from the server or would capturing from the client yield the traffic you need? If you are analyzing a slow network link, do you really need to be inside the router or would you be best suited to tap the outside interface of the router and get away from the internal networks broadcast domain?

Working with larger capture files is a real quick way to bog down your system and further complicate what may already be a long drawn out process. Using these techniques you should be able to keep tabs on your capture file size and make your analysis process quite a bit more efficient.

Using a Tap for Packet Analysis

I’ve already written quite a bit about getting on the wire as it pertains to packet analysis. Half the battle when you are capturing packets is placing the sniffer computer so that it captures the packets you need. The advent of switched networks makes this a bit harder on us as traffic is now directed and not free-flowing across every port on a network. In a post a few months ago I outlined three methods for getting on the wire. Those three methods were ARP Cache Poisoning, Hubbing Out, and Port Mirroring. One other technique which I had not previously used, but have now grown to love is using a network tap.

 

tap-diagram2A tap is basically a hardware device that you can place on the wire to intercept the right packets.

 

The tap has at least three ports. These are inbound and outbound ports and a monitor port.

 

Say you wanted to intercept all network traffic entering your router. Typically, you would have a single cable going from a switch to your router. In order to insert the tap into the mix, you would unplug the current cable from the router and plug it into the inbound port on the tap. You would add an additional cable from the outbound port of the tap into the port on your router. Lastly, you would place a cable into the monitor port that leads to your analysis machine. The analysis machine will then capture all traffic flowing between the switch port and the router.

 

The great thing about doing this as opposed to hubbing out is that you aren’t using an old school hub that could cause dropped packets and limits you to half-duplex communication. This is also advantageous over ARP cache poisoning because it doesn’t generate any extra traffic on the wire, which is something you typically want to avoid doing…especially in security scenarios.  If your layer three switches typically have a very high processor utilization, you could also consider this over port mirroring. The tap adds no extra traffic or latency to the traffic on the wire and is completely undetectable.

 

barr_tapThat all being said I recommend the Barracuda network tap. They run about $130 and have an added benefit of having TWO monitor ports. One port monitors all inbound traffic and the other monitors all outbound traffic rather than having a single port for both, which can add some flexibility in your analysis. The Barracuda tap also allows for the use of a nine volt battery in situations where a power outlet isn’t handy or you just want to capture some packets quickly.

 

 

 

You can get the Barracuda network tap from http://www.barracudanetworks.com/tap/.

Using ARP Cache Poisoning for Packet Analysis

Unfortunately, sniffing packets isn’t always as easy as plugging into an open port and firing up Wireshark. In fact, it is sometimes more difficult to place a packet sniffer on a network’s cabling system than it is to actually analyze the packets. In the grand ole days of packet analysis when everybody used hubs you could plug in and sniff all of the traffic on a network segment. As most of you know now however, the advent of switched networks prevents this. When you plug a sniffer in to a port on a switch, you can only see broadcast traffic and the traffic transmitted and received by your machine. Because of that we have had to come up with a few alternative techniques to getting the traffic we need.

The three most popular techniques for doing this are port mirroring, hubbing out, and ARP cache poisoning. The goal of this article is to give a brief overview of port mirroring and hubbing out, which are very commonly used, and then to give a detailed explanation of ARP cache poisoning, the least well known of the trio.

The Common Techniques

Port Mirroring is probably one of the easiest ways to capture the traffic you are looking for. Also called port spanning, this is a feature available on most managed network switches. This is configurable by accessing the command line or GUI management for the switch the target and sniffer systems are plugged in to and entering commands which mirror the traffic of one port to another. For instance, to capture the traffic of a device plugged in to port 3 on a switch, you could plug your sniffer into port 6 and enter a vendor specific mirroring command that mirrors port 3 to port 6.

Hubbing out is a technique in which you localize the target device and your analyzer system on the same network segment by plugging them directly in to a hub. In order to do this, all you need is an old hub and a few network cables. Simply go to the switch that the target computer resides on and unplug it from the network. Plug the targets network cable, along with the cable for your sniffer, into the hub, and then plug the hub into the network switch. This will put your sniffer and the target machine on the same broadcast domain and allow you to see all of the packets going to and from the target machine, as well as yours. Since this does involve a brief moment of connectivity loss, I do highly recommend letting the user of the target system know that you will be briefly disrupting their connectivity, especially if it is someone in management!

Poisoning the ARP Cache

The ARP protocol was designed out of necessity to facilitate to translation of addresses between the second and third layers of the OSI model.  The second layer, or data-link layer, uses MAC addresses so that hardware devices can communicate to each other directly on a small scale. The third layer, or network layer, uses IP addresses (most commonly) to create large scalable networks that can communicate across the globe. The data link layer deals directly with devices connected together where as the network layer deals with devices that are directly connected AND indirectly connected. Each layer has its own addressing scheme, and they must work together in order to make network communications happen. For this very reason, ARP was created with RFC 826, “An Ethernet Address Resolution Protocol”. I’m not going to go into detail on the whole ARP process here, but I highly recommend reading my Packet School 201 write up on it here in order to better understand this process.

ARP cache poisoning is a more advanced form of tapping into the wire on a switched network. It is commonly used by hackers to send falsely addressed packets to client systems in order to intercept certain traffic or cause denial of service (DoS) attacks on a target, but ARP cache poisoning can still serve as a legitimate way to capture the packets of a target machine on a switched network.

ARP cache poisoning, sometimes referred to as ARP spoofing, is the process of sending ARP messages to an Ethernet switch or router with fake MAC (Layer 2) addresses in order to intercept the traffic of another computer.

 

Using Cain & Abel 

When attempting to poison the ARP cache, the first step is to download the required tools and collect some necessary information. We’ll use the popular security tool Cain & Abel from Oxid.it (http://www.oxid.it). The installation is pretty straight forward so I won’t go through that here.

Once you have installed the Cain & Abel software, you need to collect some additional information including the IP addresses of your analyzer system, the remote system you wish to capture the traffic from, and the router that the remote system is downstream from.

When you first open Cain & Abel, you will notice a series of tabs near the top of the window. (ARP cache poisoning is only one of a variety of Cain & Abel’s features.) For our purposes, we’ll be working in the Sniffer tab. When you click this tab, you will see an empty table. In order to fill this table you will need to activate the program’s built-in sniffer and scan your network for hosts.

Click the second icon on the toolbar, which resembles a network card. The first time you do this you will be asked to select the interface you wish to sniff. This interface should be the one that is connected to the network you will be performing your ARP cache poisoning on. Once you’ve selected this interface, click OK to activate Cain & Abel’s built-in sniffer. To build a list of available hosts on your network, click the icon that resembles a plus (+) symbol, and click OK.

The once-empty grid should now be filled with a list of all the hosts on your attached network, along with their MAC addresses, IP addresses, and vendor identifying information. This is the list you will work from when setting up your ARP cache poisoning.

At the bottom of the program window, you will see a set of tabs that will take you to other windows under the Sniffer heading. Now that you have built your host list, you will be working from the APR tab. Switch to the APR window by clicking the tab.

Once in the APR window, you are presented with two empty tables: an upper and a lower one. Once you set them up, the upper table will show the devices involved in your ARP cache poisoning, and the lower table will show all communication between your poisoned machines.

Continue setting up your ARP poisoning by clicking the icon resembling the plus (+) symbol on the program’s standard toolbar. The window that appears has two selection columns side by side. On the left side, you will see a list of all available hosts on your network. Click the IP address of the target computer whose traffic you wish to sniff. This will result in the right window showing a list of all hosts in the network, omitting the target machine’s IP address. In the right window, click the IP address of the router that is directly upstream of the target machine, and click OK.

The IP addresses of both devices should now be listed in the upper table in the main application window. To complete the process, click the yellow-and-black radiation symbol on the standard toolbar. This will activate Cain & Abel’s ARP cache poisoning features and allow your analyzing system to be the middleman for all communications between the target system and its upstream router.

You can now fire up your packet sniffer and begin the analysis process. When you are finished capturing traffic, simply click the yellow-and-black radiation symbol again to stop ARP cache poisoning.

A Final Note

As a final note on ARP cache poisoning, you should be very aware of the roles of the systems you implement this process for. For instance, do not use this technique when the target device is something with very high network utilization, such as a fileserver with a 1Gbps link to the network (especially if your analyzer system only provides a 100Mbps link). When you perform this rerouting of traffic, all traffic transmitted and received by the target system must first go through your analyzer system, therefore making your analyzer the bottleneck in the communication process. This can create a DoS-type effect on the machine you are analyzing, which will result in degraded network performance and faulty analysis data.

That is all there really is to ARP cache poisoning. This technique has always proved significantly useful in packet analysis experience and I hope it does in yours as well.