Research By: Mark Lechtik
DorkBot is a known malware that dates back to 2012. It is thought to be distributed via links on social media, instant messaging applications or infected removable media. Although it is a veteran among the notorious malware families, we believe that more networks have been infected with Dorkbot than previously expected, with the most affected countries being Sri Lanka, India and Russia.
General geographic distribution of the Dorkbot infections
The malware essentially serves as a general purpose downloader and launcher of other binary components, mostly modules for conducting DDoS attacks or stealing passwords. The analysis in this case was based on the sample that was observed in multiple infections in the wild in the past month.
The DorkBot malware comes packed within a simple dropper, in which the payload is embedded as an RC4 encrypted blob. This blob can be found at the resource section of the binary, encoded with Base64.
Figure 1: Base64 encoded & RC4 encrypted resource
The RC4 ciphertext is prepended with 32 bytes of metadata containing the RC4 key for decryption in bytes 8-12.
Figure 2: Structure of the decoded resource
The dropper decodes the Base64 payload and decrypts the result, which consists of a PE loading shellcode and the raw binary of the malware. Right after decryption, control is passed to the shellcode which locates the raw binary, loads it and then passes execution to its entry point.
Figure 3: Decryption and execution of the payload embedded within the resource
The malware’s dropper can be identified by a peculiar loop which invokes a message box to an undefined handle with the value 0xFFFFA481 and the text “Will exec“.
The payload consists of the following actions taking place consecutively:
Figure 4: Enumeration and termination of start-up process,
according to paths from registry run keys.
An example of such structure in run-time can be seen here:Figure 5: Structure of the buffer used for
calculating the hash value for the machine ID.
DWORD Data1: MD5(sysinfo)[0..3] xor key
DWORD Data2|Data3: MD5(sysinfo)[4..7] xor key
DWORD Data4[0..3]: MD5(sysinfo)[8..11] xor CRC32(user_SID)
DWORD Data4[4..7]: MD5(sysinfo)[12..15] xor CRC32(user_SID)
The flow of the actions taken by the function itself is:
If the malware is executed from removable media, it will register a designated class for it under HCKU\Software\Classes\CLSID, with the classes name being a calculated GUID with the key 0xDEADBEEF.
Figure 6: Registration of a class for the malware
File modification watchdog: A thread that constantly calculates the CRC32 of the copied malware binary in %appdata% and compares it with the original file’s CRC32. In case this changes, the copied file is deleted and rewritten it with the contents of the original one.
Figure 7: File modification watchdog code
Injection of process watchdog code: The malware will enumerate all running processes and will exclude 64 bit processes, the current process and ones which run an image with the names “teamviewer.exe“\”tv_w32.exe”
Figure 8: Exclusion of TeamViewer from targeted processes for injection
All other processes (as well as a malware created notepad.exe process) will get injected with the following piece of code:
Figure 9: Injected process watchdog code
where the pointers 0x11111111, 0x22222222, 0x33333333 and 0x44444444 will be replaced by the injecting function prior to writing the code, as can be seen below:
Figure 10: Replacement of invalid pointers in the process watchdog
payloads to actual function pointers.
The injected code itself will wait indefinitely on an event, which will be signaled when the original malware process is terminated. In case this happens the malware is spawned again.
Communication: All C2 domains are resident within the binary as AES256-CBC encrypted blobs, ordered in a pointer table that can be found in offset 16 of the .data section.
Figure 11: Encrypted CnC domain table
The key for decryption is “GD!brWJJBeTgTGSgEFB/quRcfCkBHWgl“
Figure 12: Decryption routine for the CnC domains
The following types of communication can be observed in the malware:
Figure 13: Structure of a raw protocol request to the CnC
The response consists of 517 bytes and has the following structure:
Figure 14: Response packet from the CnC
153a3104fe52062844fed64c7a033d8378f7977f – Dropper 0cf0f00b7c78d68365b4c890c76941051e244e6f – Unpacked payload
We have 9 active Anti-Bot signatures for DorkBot family: