DarkGate Rises: New version of DarkGate malware hunts like a Duck but bites like a RAT

Introduction

On 4th August 2023, WithSecure Detection and Response Team (DRT) received an alert regarding spoofed process injection with abnormal memory characteristics on a host belonging to a WithSecure Countercept MDR customer. The DRT triaged the host and determined the presence of malware which had not previously been observed on our customer base. Whilst this malware shared similarities with known ‘infostealers’ (showing a similarity to ‘DUCKTAIL’, which WithSecure identified in the latter half of 2021), the sophistication of observed tradecraft in this case was significantly beyond that seen in other examples.

Since this initial case, the DRT has detected numerous additional infection attempts on various customers across multiple verticals (all of whom had been previously targeted by 'DUCKTAIL’). Upon the reverse engineering of the malware by members of both the DRT and WithSecure Intelligence, it was determined that this malware was a new version of DarkGate, a malware being marketed as of June 2023 on two prolific cybercrime forums known as xss.is and exploit.in.

DarkGate Infection Chain

The open-source reporting by the security community has described multiple different infection vectors for this malware; including email, Teams messaging and SEO poisoning, but the main infection vector used against WithSecure customers was phishing via LinkedIn - in particular, lure documents related to salary and product expectations for prospective hires such as that displayed in Figure 1.

Upon download of the zip file payload, the user extracts and executes the contained obfuscated VBS script. This script creates a new directory on the Windows C: drive, and then proceeds to copy the legitimate curl binary from “C:\Windows\System32” into it with a randomised name, before downloading additional payloads from hardcoded remote IP addresses. One file is a AutoIT3 portable binary, and the other is a compiled AutoIT3 script which contains the DarkGate payload. 

The choice of AutoIT3 is noteworthy as less advanced threat actors typically bundle AnyDesk or other commercial remote monitoring and management (RMM) tools to allow remote desktop access to the target host. However, AutoIT3 is a “scripting language designed for automating the Windows GUI” , bringing functionality more in line with keystroke injection tools like a USB Rubber Ducky.

However, what makes AutoIT so effective for executing malware is the presence of the DllCall function , which allows AutoIT to execute arbitrary functions within any DLL to which it can open a handle. In this case, this allows injection of the final DarkGate payload. 

Figure 2  is the deobfuscated and cleaned up code responsible for the first of two injections performed by the malware. In the first injection, a large block of hex characters in $ODHAIHNEQR is converted to a DllStruct, and VirtualProtect is called to change the region of memory which contains the DllStruct and assign it read, write, and execute permissions (indicated in the Win32 API as PAGE_EXECUTE_READWRITE). Once the page permissions have been altered, the memory region is populated with shellcode using the DllStructSetData function. This shellcode location is then passed to the routine CallWindowProc from user32.dll. This newly injected shellcode appears to be the loader for the final-stage DarkGate implant.

The second injection was into a remote process (utilising the classic ‘fork and run’ technique popularised by Cobalt Strike). Using the WithSecure Countercept MDR agent’s response functionality, it was noted that an additional 504KB memory region with PAGE_EXECUTE_READWRITE permissions was present, which the DRT then carved for further analysis. This is the DarkGate implant itself, which is written in Delphi 2-3.

Extracting key strings from this dump suggests DarkGate allows the following capabilities:

• SOCKS5 proxy
• CreateToolhelp32Snapshot (likely for LSASS dumping)
• Bundled Pidgin client, possibly for data exfiltration
• Cookie/Browser credential stealing
• Hidden VNC
• Adding credentials via cmdkey
• Admin and system privilege escalation using PSExec

Detection Methods

WithSecure DRT uses a layered approach to detecting complex, multi-stage threats like DarkGate, focusing more on attacker behaviour instead of simple atomic indicators (process names or file hashes, for example). It is worth examining a few of the detections which were particularly effective in this instance and enabled hunting for DarkGate proactively across WithSecure customer’s estates.

Script With Abnormal Metadata

Existing as an Alternate Data Stream, Windows utilises a mechanism called a Mark of The Web (MoTW) to establish and enforce a trust level with all files downloaded from the internet or intranet to tailor User Account Control to the risk level of a file. A MoTW is applied to most files downloaded by web browsers and is an excellent way to quickly determine the origin (and hence, how suspicious defenders should be) of files in datasets   . 

This feature is particularly useful in phishing investigations, as any script files that the threat actor uses to establish a foothold in the estate must be downloaded and executed by a user directly from the internet.

The presence of a MoTW can be determined using a wide variety of tools, including the Windows command prompt, as can be seen in the following screenshots.

Note the presence of the “:Zone.Identifier” ADS in the figure above. The content of this stream will also provide defenders with useful metadata about the malicious file, including the origin URL and Internet Explorer Zone ID. In this case, ZoneID 3 shows that the file is from the internet.

The presence of this stream is one of many indicators we can use in a layered approach to detecting threats originating from social engineering. One example of this is SEO poisoning, which is an attack vector which has increased in popularity in recent years. Defenders can then use the HostURL field to accurately track attacker infrastructure and implement effective blocking to protect customer networks pre-emptively, if needed. 

In Memory Anomalies

The in-memory anomalies were the largest indicator of the presence and sophistication of the DarkGate implant in the cases investigated by the DRT. The use of reflective loading is common in commercial red team frameworks including    Cobalt Strike, Havoc and PoshC2. But its use in commodity malware such as this is noteworthy.   

A common method, and that observed in DarkGate, of injecting a PE file into memory using   a technique called “Reflective DLL Injection”, commonly implemented using the following three Win32 API function calls :

• VirtualAllocEx
• WriteProcessMemory
• CreateRemoteThread  

Of these, VirtualAllocEx and CreateRemoteThread are the most useful for determining malicious or abnormal behaviour. Usage of VirtualAllocEx is not inherently suspicious, as during the normal operation of applications such as debuggers or antivirus products, memory is allocated into processes these applications are interacting with. 

Despite this, the properties of allocated memory regions can help to determine how suspicious they are. As per the MSDN documentation for VirtualAllocEx , note the presence of the arguments flAllocationType and flProtect  , which signify the type of memory that is being allocated and the permissions that memory region will be assigned. Memory regions where memory has been reserved, committed(i.e., where flAllocationType is MEM_COMMIT and MEM_RESERVE)  and has execute permissions(i.e., where flProtect is PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_READ)  is a meaningful indication that code injection has occurred. 

After the use of VirtualAllocEx comes CreateRemoteThread, which is used to execute the newly written code. When a module is loaded normally (using LoadLibraryA ), the memory region to which it is assigned contains a reference to the file path on disk where the DLL is stored (with the memory region being termed as ‘backed’). However, when a PE is loaded reflectively, this information is not present (termed ‘unbacked’) and the threads that are created to execute the injected payload are also unbacked. This information is visible in Process Hacker as a thread with a start address of ‘0x0’ in the figure below:

These techniques, both in isolation and together, are significant indicators of injected code.

Detection Improvements

For defenders, detections and rule-based systems must be constantly evolving to fit a changing threat landscape and evolving techniques. This investigation presented opportunities to fingerprint indicators of malicious activity that had not been previously observed. 

One such rule was derived from a quirk in the curl activity used to download the .au3 file. As observed by both WithSecure and TrueSec , the URI at which the payload is hosted does not have an extension (as if it were a directory instead of a full URL).    This curl command then outputs the target URL to a file including the extension. This behaviour deviates enough from normal website design to be a very precise detection of the loader employed by DarkGate.

Additionally, DarkGate does not use the curl.exe binary located in “C:\Windows\System32”. Instead, it copies this binary to a new folder matching the pattern C:\<4 random chars>, likely to avoid any static signaturing of the usage of curl.exe by defenders. However, whilst attackers may be able to alter certain characteristics of helpful binaries, defenders should look at execution beyond what is presented at face value and evaluate various pieces of metadata within the binaries. In this case, although the attacker renamed the curl binary, it was possible to ascertain what the binary was due to the file’s original name contained within the signature information.  

This, combined with the payload download behaviour detailed above is a surprisingly high-fidelity detection combination for the DarkGate loaders across multiple lures and infection chains.

Conclusion

The WithSecure MDR Detection and Response Team (DRT) has been conducting proactive threat hunting for historical and ongoing infections of DarkGate on our entire customer base. Infection via phishing payloads pretending to be job postings such as this is very common, however DarkGate represents a notable shift in the types of 2nd and 3rd stage payloads that usually follow. 

The most prominent difference is the type of malware to which DarkGate belongs. During the hunting performed, members of the DRT and WithSecure Threat Intelligence noted significant overlap in the organisations targeted by DarkGate and those targeted by DuckTail and its derivatives as documented in the previous report Meet the Ducks. 

DuckTail is primarily an infostealer and has no regard for stealth or even access to a target device. DuckTail is a single stage and is fire-and-forget, transmitting the acquired browser credentials via Telegram to the attacker. DarkGate, by comparison, is primarily a RAT and contains the prerequisites for obtaining long-term remote access to a compromised host, including staying undetected. This includes prioritizing stealth, which is achieved by the payload being memory-resident in multiple processes and persistent via the startup folder.  

With this comes the most evident shift from DuckTail; DarkGate is not built to specifically target browser credentials (specifically Meta, formerly Facebook, business accounts) like DuckTail, it is simply a commercial RAT being used by the threat actor who may or may not be linked to DuckTail. This is further evidenced by the fact that DRT only observed a single case of the threat actor directly targeting browser credentials. 

This shift obviously has significant implications for companies affected by DuckTail by function of the increased impact – with the presence of command execution comes the ability of privilege escalation, lateral movement and eventually domain dominance if undetected (or at least the ability to sell access to this foothold if the actor chooses to).