Wednesday, January 2, 2008

yanking exe's from pcaps

Sometimes it seems that some pretty interesting tools just don't get the press they should.

Recently as in New Years Eve - I picked up a new binary in my honeynet. It came across as a themida packed binary that wouldn't run under vmware. After noticing the following snort alert:

[**] [1:2000419:7] BLEEDING-EDGE PE EXE or DLL Windows file download [**]
[Classification: Misc activity] [Priority: 3]
12/31-15:58:26.967376 ->
TCP TTL:112 TOS:0x0 ID:60052 IpLen:20 DgmLen:1460 DF
***A**** Seq: 0xEF909157 Ack: 0x3FE9D46F Win: 0x41C5 TcpLen: 20

and not a whole lot else I decided to suspend the honeypot, copy the files over to my compromises directory, and hash them. I then took a good look at the network capture I picked up.

At this point since I could see who the attacker was I just plugged in the IP to a tcpflow command:

hogfly@oink:~/flows$ tcpflow -r 20071231.pcap host
tcpflow[20963]: truncated dump file; tried to read 1514 captured bytes, only got 392
hogfly@oink:~/flows$ ls

So in this case, which file should I care about? Well I know the file was transferred from the attacker to the victim, so I don't care about anything involving my honeypot as the source for this exercise. That leaves me with two possible files of interest:

Grand. Now..based on the snort alert I can narrow it down to just one flow of interest.

Taking a quick look to verify that the signature didn't just pick up 'MZ' in the content of the flow I find some interesting information rather quickly simply using trusty old strings and a hex editor (yes I have a full pcap and can just do some work with wireshark but it's always good to use alternatives).

hogfly@oink:~/flows$ strings -eb

Hmmm...interesting. Looks like EXPOCUSTOM could be the netbios name of the attacking computer, and the user was Administrator. Could the binary transferred have been placed as \system32\smlogsvcc.exe ? Odds are yes.

strings -a gives us some other interesting output:
C:\Dokumente und Einstellungen\haase\Desktop\new server\running\rBot___Win32_Debug\rBot.pdb

Looks like someone with a name containing hasse had compiled a new version of rbot? It's certainly possible.

At this point I think it might be safe to say there's a strong possibility of having a good binary.

So how does one actually pull a binary from a stream like this?

I used pehunter from the honeytrap project at I didn't bother with the pehunter snort plugin for this exercise, I simply went after the pehuntd binary.

pehuntd is a standalone daemon and client application. The daemon listens on a local socket and the client simply throws data at the daemon.

after unpacking it I followed the instructions and compiled the binary as follows:
pehuntd: gcc -o pehuntd pehuntd.c pehuntd.h md5.c md5.h -Wall -Werror
pehuntc: gcc -o pehuntc pehuntc.c -Wall -Werror

Running the daemon is simple...

hogfly@oink:~/pehuntd-0.1$ pehuntd v0.1 (C) Tillmann Werner. Awaiting connections...

hogfly@oink:~/pehuntd-0.1$ ./pehuntc ../flows/
Stream received, scanning 451657 bytes.
hogfly@oink:~/pehuntd-0.1$ PE file extracted: 449024 bytes dumped to /tmp/8740055003268cebd4e6c7310f07f761.

Cool, so now I have a binary that was extracted and it's in my /tmp directory. Oh..the file name is the md5sum of the binary.


iamnowonmai said...

Hmmm.... interesting. I usually use tcpxtract for this, but I will try this next time.