Atrás 
Summary
In the past month, the Netskope Threat Labs team observed a considerable increase of SharePoint usage to deliver malware caused by an attack campaign abusing Microsoft Teams and SharePoint to deliver a malware named DarkGate.
DarkGate (also known as MehCrypter) is a malware that was first reported by enSilo (now Fortinet) in 2018 and has been used in multiple campaigns in the past months. Since its recent update announcement in an underground forum, several campaigns have been conducted to deliver the malware using different methods, such as phishing and SEO poisoning.
DarkGate appeals to many attackers because of its broad feature set, which includes HVNC, keylogging, information stealing, and downloading and executing other payloads. DarkGate can be used as a starting point for bigger attacks, including Ransomware infections.
Netskope Threat Labs recently identified a new DarkGate variant delivered via MSI using a loading approach based on Cobalt Strike Beacon’s default shellcode stub. Correlating the analyzed samples with findings from other researchers, we could determine that this is part of a new version of the DarkGate malware. Let’s take a closer look:
Infection analysis
The infection starts via a fake invoice email delivering a PDF document to the victim. The PDF file contains a DocuSign template that is used as an attempt to lure the user to open a document to be reviewed:
Once the user clicks on the fake document a CAB file is downloaded. The CAB file contains an internet shortcut that once executed downloads an MSI file to the infected machine:
Once the user executes the MSI file a whole chain of loading mechanisms starts using the files presented in another CAB file inside the MSI:
Stage 1 – DLL Side-Loading
The chain starts via the execution of the windbg.exe binary present in the CAB file. The DLL side-loading technique is used here in order to execute a fake version of the dbgeng.dll DLL file. Since windbg.exe imports functions from dbgeng.dll, this DLL will be included in its import table, causing the Windows loader to map the DLL into windbg.exe’s address space and then execute the DllMain function:
The dbgeng.dll is written in the Delphi programming language and has the internal name of SideLoader.dll, a common name observed in several DarkGate DLLs. It also contains export functions required for different binaries, such as windbg.exe and KeyScramblerLogon.exe, which was also observed being abused to side-load malicious DLLs.
In the KeyScramblerLogon.exe case, the side-loaded DLL is named KeyScramblerIE.dll and that is also written in Delphi. The loading methods and decoding algorithm are slightly different from the version presented in this blog, which abuses the WinDbg binary.
Upon execution of its DllMain function dbgeng.dll reads the content of a file named data.bin, present in the same directory, and decodes it using a custom base64 approach using the “zLAxuU0kQKf3sWE7ePRO2imyg9GSpVoYC6rhlX48ZHnvjJDBNFtMd1I5acwbqT+=” alphabet. This approach is the same used in other variants of DarkGate.
The decoded content results in a PE file (also written in Delphi) with a shellcode at the end of the file. The execution flow will then be redirected to the base address (first byte of the DOS header) of the decoded file.
The DOS Header bytes of this file contains a tiny snippet that is responsible for calculating the base address of the current decoded file, adding the RVA of the decoded shellcode to the base address and then calling it via a “call eax” instruction:
The technique employed here is very similar to the Cobalt Strike Beacon’s default shellcode stub, which is usually employed to call the Beacon’s ReflectiveLoader export function.
The called shellcode then prepares the file to be executed performing actions such as resolving its Import Address Table. The LoadLibraryA and GetProcAddress Windows API functions are resolved by hash using the CRC32 algorithm and then used to resolve the IAT.
The execution flow is then transferred to the stage 2 entry point:
Stage 2 – Another Delphi loader
The actions performed by this stage is very similar to the first one. The difference here is that the file read and decoded is the data2.bin file. Also, instead of being decoded all at once the malware first tries to find the occurrence of the “splitres” string in the file and then splits it in two parts. After the malware obtains the two parts it decodes both using the same custom base64 approach.
The first decoded part results in the AutoIt.exe binary and the second part is an AutoIt script that will be named script.au3. The use of AutoIt files is a well-known approach used by DarkGate actors.
A directory named “tmpa” is created under “C:\”, both files are written to it, and then the CreateProcessA function is called to execute the AutoIt script using AutoIt.exe:
