Lucky for NSM — Extracting files from TFTP packets in Wireshark
So the other day I get a call from the forensics team at work asking for help with some packet analysis. A client’s users had reported phishing activity, so they decided to run a full-content capture using Wireshark on the external and internal network interfaces. Upon doing so, they witnessed suspicious activity; commands such as cmd.exe were triggering alerts on their Snort sensors as well. Oh boy…
After the attack was contained, the client’s internal security team had reconstructed the attack and learned that the attacker had compromised a server, downloaded tools to C:\Windows\system32\, including Foundstone’s SuperScan and Sysinternal’s PsExec, and then uploaded three RAR files via TFTP.
My goal: see what was in those RAR files. Whether it be intellectual property, client information, etc, the most important task was to identify the sensitivity of the data inside. I opened the raw capture in Wireshark and identified the three TFTP streams. I thought I would right-click and select “Follow UDP Stream,” then save the raw data as a RAR file. Unfortunately, when I did this, I could then not extract the contents of the archive. Looking for an alternative, Landon pointed me to tcpxtract (as detailed on Bejtlich’s blog), which at the time sounded good, but I couldn’t get it to compile under Cygwin and I wanted to get this done quickly. Oh well, with a name like tcpxtract, can it even handle UDP streams?
So, looking at the packets again, there were only about 20 per stream, I decided to do this task manually. Who knew if it would work, but I gave it a try. I manually selected each individual TFTP Data Packet (not acknowledgments!) and selected the TFTP Data portion which began at the 47th byte in the packet. I did a Ctrl-H (or select File > Export > Selected Packet Bytes) and saved as block01, block02, block03 for each packet in the stream. I then cat all the files and redirected stdout to file01.rar like so:
$ cat block* > file01.rar
I opened the RAR file and extracted the contents without a problem. I admit I was a bit excited at this point, interested to see its contents. I later spoke with Richard about this, who pointed me to a blog post from last year about TFTPgrab. Remembering this post now, I find it interesting that there was no way to rebuild files transferred through TFTP before TFTPgrab. Yet, I successfully managed to do so here.
Anyways, here are some lessons learned. The attacker was sloppy, amateur at best. To call it amateur would be an insult to amateurs everywhere. For the client, it was sheer luck they ran a full-content capture at the moment of the intrusion and our adversary used a non-encrypted medium to transfer data. Had he encrypted his files or used an SSL tunnel, we wouldn’t have anything. Not to mention, if this is the kind of stuff that gets picked up during a random packet capture, who knows what kinds of malicious activity they have been or are currently subject to. Even more so, why are companies not doing egress filtering of traffic? TFTP should have been blocked at the firewall no ifs, ands or buts.
One last lesson. When you outsource IDS monitoring activities to an MSSP (who probably has one or two analysts per 30-35 clients like yourself), attacks against you will not be treated with the same diligence you would expect of your own staff. They just don’t care as much as you do.
Cool post, were you able to determine what the attacker used to exploit the server? depending on how they got in, that could point to bigger problems on the network.
On your last comment about MSSP’s: Depends on your SLA. Hopefully, you have some recourse you can take because they didn’t meet the SLA.
@ Sam: Do you get an SLA for “degree of caring” with your providers? ;>
Honestly, there is a place for business-process outsourcing. For parts of the organization covered by SOX, GBLA, HIPAA, and PCI, I typically could care less if it’s MSSP or not most of the time.
The misconception of outsourcing/SaaS is that you have to outsource “everything”. Outsourcing the parts of your business that you care less about often makes sense. However, every company should still have an incident response plan and/or team that can deal with the most risky issues — for example, the risky scenario that the MSSP be fired on the spot due to a breach in their network that causes a breach in yours.
The difficulty that executives and security professionals have with concepts such as “scoping” and “segmentation” seem to bother me exponentially everyday. There is no silver bullet. There is no one true answer. Security is a process, not a product.
@ CG: I did not bother, nor have time to investigate those details. The client also told us they reconstructed the attack and knew what vulnerability was exploited.
@ Sam: Dre could not have explained it any better for me. SLA or not, you have a personal stake (your job and reputation) whereas an MSSP merely has a contract.
You left out the most important part.
What was in those rar files?
Candy.