Reverse Engineering Firefox and TOR Targeted Payload

The Lotan research team is constantly seeking out new and novel memory corruption exploits to enhance our detection heuristics. This week, an exploit targeting Firefox and the Tor Browser was released, giving us a chance to exercise the capabilities of Lotan. In order to conduct an analysis, we extracted the shellcode from the exploit (the 'thecode' variable) and side loaded it into a bastion crashdump (see VirusTotal sample). This is a slightly different approach than the standard method of consuming crashdumps with Lotan, but allows our research team to quickly inspect the actions inside the shellcode. From here, we spun up a live version of the exploit to see how it behaved in a lab setting. By using Windows 10 (version: 1511 build: 10586.545) + Tor Browser (6.0.6), we could reproduce the exploit and collect a crashdump. Our research team closely examines how often new exploits fail or crash after executing the payload. In this instance, the exploit did not clean up the corrupted memory in the heap, which resulted in Tor crashing nine out of ten times. Given that Lotan relies on crashdumps for analysis, this exploit was ripe for opportunity.

Shellcode analysis can be incredibly slow and rigorous, but rewarding in finding conclusions. The Lotan emulator aims to speed up that process and make determinations whether the code was malicious or not. Lotan confirmed the IP address posted on twitter (5.39.27.226, port 80) as well as illustrating the shellcode's behavior:

Lotan Output:

Conclusions:

Malice detected: The payload performs dynamic resolution and call of restricted function kernel32.dll!LoadLibraryA 
Malice detected: The payload loads external modules into the process. 
Malice detected: The payload performs TCP/IP actions. 
Malice detected: The payload attempts to contact: 5.39.27.226:80

Facts:

Fast TEB -> PEB -> PEB_LDR_DATA walk detected.
Dynamic resolution and call of a restricted function occurred: kernel32.dll!LoadLibraryA
Payload attempts to load Winsock library: ws2_32
Call on a restricted function occurred: KERNELBASE.dll!LoadLibraryExA
Call on a restricted function occurred: ntdll.dll!LdrLoadDll
Call on a restricted function occurred: kernel32.dll!LoadLibraryA
Payload attempts to load a dynamic library: IPHLPAPI
Payload attempts to initialize Winsock.
Call on a restricted function occurred: ws2_32.dll!WSAStartup
Payload attempts to create a socket.
Call on a restricted function occurred: ws2_32.dll!WSASocketA
Call on a restricted function occurred: ws2_32.dll!WSASocketW
Payload attempts to initiate a TCP connection to: 5.39.27.226:80
Call on a restricted function occurred: ws2_32.dll!connect

Lotan breaks down the exploit's output into facts and conclusions about the shellcode. The facts represent what the heuristic engine observed and the conclusions are drawn from those about the general behavior of the payload. We can see the IP and port that was attempting to be reached and the libraries loaded (ws2_32 and IPHLPAPI). The latter of those two being able to operate on low level components of the networking stack. As pointed out publicly, this shellcode does not fetch a stage2, but instead makes a request back to an IP of a OVH provided machine, recording information about the machine such as the MAC address. Leviathan observed the maturity of the exploit and shellcode a bit lacking. The exploit does not correctly cleanup process state, allowing a crash. Furthermore, the exploit makes use of direct open source component clones, such as Stephen Fewer's block_api (used in Metasploit). Finally, it completely lacks an encoder to protect the shellcode itself. While doing research for Lotan, we normally look at modern exploit kit shellcode, which on average is much more technically evolved than this targeted payload. Since this exploit and payload are obviously targeted, we would most likely point the finger at a law enforcement campaign.