Basic Truman Usage
Analyzing a binary with Truman is simple:
- First, make sure it's an EXE. Truman cannot analyze DLLs, infected Office files, malformed ZIPs or anything else. Just straight up Windows EXE files.
- On the Truman server, start the fake servers in their own window. This will also start up tcpdump to capture the data to a PCAP file, and a copy of ngrep that simply displays the packet headers and payloads in real time.
- Also on the Truman server, copy the suspicious executable into the analysis queue directory. Make sure it's world-readable.
# cp malware.exe /forensics/queue # chmod a+r /forensics/queue/malware.exe
- On the malware client, log in as the malware user. The automated analysis script should start up, download the first sample in the queue and execute it.
- Wait 10 minutes while the malware executes. At the end of this time, the client will reboot.
- While the client is rebooting, you may go ahead and hit CTRL-C in the data collection window. This will stop the fake servers as well as tcpdump and ngrep.
- The malware client should automatically store a copy of it's infected hard drive image onto the Truman server, then re-image itself from the clean baseline and reboot into Windows.
- Once the system has rebooted, run the forensic analysis script to clean up, retrieve the collected data and create some automated reports.
Once the forensics script completes, you should find all the collected data inside the /forensics/$EXENAME-files directory, and the infected image file at /images/$EXENAME.img. For example, if the executable was named malware.exe, you'd have /forensics/malware.exe-files and /images/malware.exe.img.
Well, there are a lot of options, too many to list here. Suffice it to say that if necessary, you can mount the image directly under Linux:
# mount -o ro,loop /images/malware.exe.img /mnt/new
After that, you can pretty much do whatever you want. I've had good luck running ClamAV against this filesystem, for example. You can also use this to recover unpacked binaries, config files, etc.
There's also quite a lot of information in the sandnet.pcap file (if the malware was active on the network, that is). As a start, try using Wireshark to generate a "Protocol Hierarchy Statistics" report. It'll give you a good breakdown of what sort of traffic is in the capture file. For example:
=================================================================== Protocol Hierarchy Statistics Filter: frame frame frames:130 bytes:83495 eth frames:130 bytes:83495 ip frames:126 bytes:83291 tcp frames:110 bytes:81481 http frames:1 bytes:182 tcp.segments frames:1 bytes:722 http frames:1 bytes:722 media frames:1 bytes:722 smtp frames:15 bytes:2107 udp frames:14 bytes:1690 dns frames:4 bytes:364 nbdgm frames:2 bytes:486 smb frames:2 bytes:486 mailslot frames:2 bytes:486 browser frames:2 bytes:486 ntp frames:2 bytes:180 nbns frames:6 bytes:660 igmp frames:2 bytes:120 arp frames:4 bytes:204 ===================================================================
One thing that sticks out here is that there is SMTP traffic, which would normally never be generated by the malware client. Obviously, the sample under analysis was responsible for this traffic.