Answers to the Honeynet SOTM32 Challenge:

Vinay A. Mahadik

Q1. Identify and provide an overview of the binary, including the fundamental pieces of information that would help in identifying the same specimen.

A. The binary is a Windows Win32 executable. It’s compiled as a VB6 native code later packed with a yet unknown exe packer. It attempts to persist on the system across reboots by copying itself to the C: drive and putting its path-info in the HKLM\Software\Microsoft\Windows\CurrentVersion\Run key (Name: RaDa, and by default, Data: C:\RaDa\bin\RaDa.exe). By default, it periodically connects to a target server at IP address 10.10.10.10 for retrieving commands that control its future operations.

Q2. Identify and explain the purpose of the binary.

A. In a real world, this binary would probably be intended as a stealth trojan/spyware.

Q3. Identify and explain the different features of the binary. What are its capabilities?

A. The binary is clearly a trojan. It can be sent the following commands with arguments: exe, screenshot, get, put, and sleep. As shown in the analysis, the exe command allows execution of arbitrary commands on the infected host. The screenshot saves screenshots to local disk, but this could very well be uploaded to the command server with a little effort. This would then classify the binary as a spyware as well. Apart from that, the binary attempts to evade reverse engineering – its packed with a packer (possibly scrambled later on), and also checks for installed instances of VMWare etc.

Q4. Identify and explain the binary communication methods. Develop a Snort signature to detect this type of malware being as generic as possible, so other similar specimens could be detected, but avoiding at the same time a high false positives rate signature.

A. The “Confirming Trojan Behavior” section of the Analysis (section 3.4.6) details the trojan’s communication mechanisms.

The following signature will catch the default communication, but with the –server, and –commands arguments, this signature is useless.

alert tcp $EXTERNAL_NET any -> 10.10.10.10 80 (msg:"RaDa Command Fetch Attempt"; flow:to_server,established; uricontent:"/RaDa/RaDa_commands.html";)

We attempt to detect the transmission of the binary itself instead. The best place to look for a long string of bytes unique to the executable is usually at the entry point of the compressed binary:

Apart from the instructions sequence, which must be unique to the decompression routine, the address offsets are fairly unique to the uncompressed binary. 0x40C000 is the start of the JDR1 section, and 0xB000 is the size of the JDR0 section in memory. Such offsets will vary based on the input binary’s size and compressibility. So we chose the byte sequence: “60 BE 00 C0 40 00 8D BE 00 50 FF FF 57 83 CD FF EB 10 90 90 90 90 90 90” to uniquely represent the binary.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"RaDa Trojan Alert!"; flow:to_server,established; content:"| 60 BE 00 C0 40 00 8D BE 00 50 FF FF 57 83 CD FF EB 10 90 90 90 90 90 90|";)

The signature reliability would improve greatly with protocol parsing abilities in Snort – say specifically looking for this content inside exes being downloaded via an HTTP/FTP GET etc. Still, given the length/randomness/uniqueness of the string, the false positive rate should be low.

Q5. Identify and explain any techniques in the binary that protect it from being analyzed or reverse engineered.

A. The binary uses exe compression/packing to deter immediate reverse engineering. It checks for VMWare sandboxed environment and if found, quits. Apart from these two anti-reversing techniques, I also noticed a peculiar use of push and returns. Essentially, some routines had an address of a location pushed onto the stack. Then, a retn is called without pop-ing EBP, and while ESP is pointing to this stored location address. This causes execution to jump to that address (while still remaining in the routine). A more typical pop ebp, retn closure follows later. This seemed to confuse IDA pro’s detection of function boundaries it seems. This is either a standard VB compiler issue or something intentionally added to the binary to obscure the disassembly:

Q6. Categorize this type of malware (virus, worm...) and justify your reasoning.

A. A Virus is characterized by its ability to replicate itself (spreading to multiple files, copying to various media etc). A worm is characterized by a similar ability to infect other machines across the network. This binary does neither. It attempts to just copy itself to a fixed location on the file system (in the real world this would be an inconspicuous location like %WINDIR% etc. Then it attempts to poll a remote server for commands. This is therefore a trojan/backdoor malware. Had the screenshots been wired over the network to the command server as well, it would also be a spyware.

Q7. Identify another tool that has demonstrated similar functionality in the past.

A. Sorry couldn’t find one, and I am running out of time..

Q8. Suggest detection and protection methods to fight against the threats introduced by this binary.

A. For detection, check for the RaDa.exe file in the Task Manager, and kill it. If an AV utility is available that detects this trojan, use it on the entire filesystem. Else, one can be written to grep for the content (hex bytes) used in Q4 for network detection. For protection, first disable System Restore feature. Then delete all finds identified as this trojan. Also edit the Registry with regedit and remove the ‘RaDa’ value.

Bonus Questions:

1. Is it possible to interrogate the binary about the person(s) who developed this tool? In what circumstances and under which conditions?

A. From the analysis, we can see that –authors argument will pop-up IE with the author’s credits. The function first checks for whether VMWare is installed though. So this will work only outside of VMWare.

2. What advancements in tools with similar purposes can we expect in the near future?

A. Packing methods that are much harder to reverse (decompress only small portions of the exe at a time, and repeat as required – idea is increased difficulty in reversing at the cost of reduced performance). More techniques like the ‘fake return’ from Q5 (tools that obfuscate the assembly generated from a high level language – without performing any compression, and more sandbox detections perhaps.

Thanks for an interesting challenge!