Overview
The DarkGate malware family is known for its variety of features including the download and execution of malicious payloads, information stealing and keylogging abilities, as well as employing multiple evasion techniques. It is being sold as a service to cybercriminals and has been active since at least 2018, but only recently gained in popularity after the Qakbot infrastructure was taken down by law enforcement. What stands out is its rather complex delivery methods and multitude of evasion tactics to avoid detection, one of which is the abuse if AutoIt scripts to execute native code and not just commands.
AutoIt, commonly used to automate tasks within the Windows environment, such as simulating mouse clicks or keystrokes on the GUI, is abused to execute a malicious shellcode in DarkGate’s hands. This technique attempts to let the malware operate under the radar by betting on static analysis tools inability to parse compiled and obfuscated AutoIt scripts.
Recently, we have taken an in-depth look into the DarkGate malware family to gain insights into the inner workings of this malware family as well as to improve detection and configuration extraction. In this blog post, we want to specifically highlight the interesting way by which DarkGate accomplishes executing malicious native code via AutoIt scripts.
Infection chain of DarkGate
DarkGate’s infection chain can start with multitude of file types, including DLLs, JScript, VBScript, EXE and MSI files (see Figure 1 for a common delivery chain).
This visualization highlights the journey from the initial delivery file to the subsequent stages. It progresses through the AutoIt interpreter to the execution of shellcode, ending in the execution of the actual DarkGate Loader.
DarkGate Using AutoIt Scripts
The choice of AutoIt by DarkGate’s developers is strategic: Our investigations reveal that the malware often employs compiled and protected AutoIt scripts, which are additionally obfuscated to further cloak their malicious intent. This level of protection makes it challenging to dissect and understand the malware’s inner workings for researchers and static analysis tools alike.
By utilizing tools such as myAut2Exe or Binary Refinery, we can extract the original source code from these obfuscated scripts. This process, albeit requiring some clean-up, does produce a readable source code for our manual reverse engineering purposes. The deobfuscated code in Figure 3 provides us with a pivotal insight into DarkGate’s operation: The malware utilizes specific Windows API functions, notably EnumWindows, but in other samples we have also seen a call to CallWindowProc.
DarkGate’s Shellcode Execution
The aforementioned API functions, while typically used for legitimate purposes, are repurposed by DarkGate to execute its malicious payload.
CallWindowProc is typically used for customizing actions in a Windows GUI, like modifying button functionality. However, DarkGate calls this function while pointing the first parameter, lpPrevWndFunc, to its shellcode. In effect, Windows then executes the malicious shellcode as if it were a window procedure. This seems to be a known workaround to execute native code via AutoIt scripts at least since 2008.
In some variants of DarkGate, EnumWindows is abused instead, which is a legitimate API for enumerating top-level windows. This function is designed to execute a specified callback function for each window, but DarkGate sets the callback function address to it’s shellcode location. Given that there’s almost always at least one open window, this ensures the execution of the malicious shellcode at least once.
Any callback-based Windows API function could potentially be abused in a similar way, but specifically executing native code via EnumWindows in AutoIt seems to be new and unique to DarkGate as far as we are aware. While all of this may be hard for static analysis tools to extract, behavior-based analysis allows one to capture this in action. Our execution logs (see Figure 4) clearly show the runtime execution of EnumWindows and the following call to LoadLibraryA executed by the shellcode.
Variants of DarkGate
To investigate this further, we have manually selected multiple DarkGate samples dating back to it’s initial version in 2018. Through manual clustering based on code similarities, we’ve identified four distinct variants:
- First Variant: This variant embeds the payload within the compiled AutoIt script, encrypted using XOR and surrounded by the “padoru” keyword. It specifically checks for the presence of Sophos antivirus software and leverages the VirtualProtect call to make the shellcode memory region executable and uses the CallWindowProc API to execute the shellcode.
- Second Variant: Here, the payload is scattered throughout the AutoIt source code as hex codes, which is put together at runtime. This variant switches its strategy to abuse the EnumWindows API instead of CallWindowProc.
- Third Variant: This is similar to the others but with a key difference: it checks if it is running with SYSTEM privileges.
- Fourth Variant: This one is from 2018, has much less complexity as it contains no obfuscation. It creates a shortcut (LNK) to the AU3 file placed in the startup directory and reads the shellcode from a previously dropped ‘shell.txt’ file. Like the first variant, it also abuses CallWindowProc.
We have also noticed that there are differences in how the shellcode was implemented, which we will briefly look into next.
Payloads in DarkGate
The payloads in DarkGate’s various samples typically follow a similar mechanism, primarily focusing on loading the next stage of the malware, which is often tasked with downloading the final DarkGate malware.
One notable technique observed in these payloads is the byte-by-byte construction of the code using the mov instruction, a method likely adopted to evade detection by scanning tools before runtime extraction (see Figure 5).
Additionally, some payloads exhibit a deliberate pattern of jumping around the code (see Figure 6).
This complexity is designed to hinder manual analysis, making it more challenging to dissect and understand the malware’s functionality and intent. For dynamic, behavior-based analysis solutions such as VMRay’s Platform, none of these obfuscation attempts can hide the malicious actions taken by the sample.
In particular, while such intricacies in the payloads underscore the stealth and sophistication embedded in DarkGate’s design, our dynamic approach reveals the executed functions in the function log just the same, regardless of any obfuscation attempts such as jumping around, calling native functions via AutoIt scripts or employing multi-stage payloads spread over different memory regions.
Conclusion
Despite DarkGate’s extensive obfuscation efforts, dynamic, behavior-based analysis proves to be a helpful tool in identifying and understanding this malware. By not solely relying on static analysis, it’s possible to trace the entire code execution journey – from initial infection, through the AutoIt3 interpreter stage, to the injection, and finally to the actual DarkGate malware, culminating in the extraction of its configuration.
This case study highlights the lengths to which attackers will go, continually exploring obscure methods to deliver their malware and challenge existing security solutions.
References
IOCs
Hashes:
- 754d7afb2c3454d86ded95668c74c119c5ec4465
- 18f49619d69b057e81163bdf08eab5f355ce662c
- 5629b3684d406e431c6f41c5df56455c3b944c41
- 47718e8df5e7a0d0b2c74f10696ca50cf6e1e0b9
- bb0f4a60bbd8256e42f57d8b0b1269f2ec855428
- eabcef1e27b7452c74acfa0f201e9a937b0dee6d
- c46e52b896bf3b53a6878d2b2386a9dc40377f19
- 29b6a8ae869cdc1a95bae83dd97874e5efa79613
- d25e55d1eed18e55557ee9da7d195748dd2814f0
- 2e0d4798c12a7d71ad45a621dddb750bae0cd23b
- edc5d0dc190dcd0e031e2c5b43026fd3a61caed0
- c90d572f7f160dd8a3ae6e825eeb2a9d6628cef5
- 0d47cbd6d19a17a57077cbc0d0aa659865458672
- f68cc52f19c11d07d72118e71919df20ffabe9f2
URLs:
- hxxp://adhufdauifadhj13[.]com:2351
- hxxp://sftp.bitepieces[.]com:443
- hxxp://sftp.noheroway[.]com:443
- hxxp://saintelzearlava[.]com:80
- hxxp://trans1ategooglecom[.]com:80
- hxxp://sanibroadbandcommunicton[.]duckdns[.]org:5864
- hxxp://faststroygo[.]com
