Execution Flow

The execution flow of DarkGate v6 is illustrated in the figure below. The breakdown of execution flow is in the technical analysis section.

Technical Analysis

Initial Stager

URL Obfuscation

Typically, PDFs delivered via phishing emails serve as the initial stager for the Darkgate malware. In this particular PDF sample, there was a “Download” button that, when clicked, will open a URL, which seems like a tracking URL from ClickCease as shown below.

Actually, the malicious URL is hidden using a tracking URL from ClickCease. Darkgate abused Ads technologies to make the URL appear legitimate and to bypass security tools that only verify the domain of a URL to assess its malicious nature. Clicking the download button on PDF will redirects the user to a malicious URL, initiating the download of the next stager, an MSI file.

Second Stager

The MSI file was downloaded after clicking the Download button on PDF file, which on examination using Orca revealed the presence of two binary files within the MSI: a DLL file (bz.CustomActionDLL) and a CAB file (bz.WrapperSetupProgram) as indicated by their signature.

Additionally, the CAB file header point out presence of three files under it; CoreFoundation.dll, iTunesHelper.exe and sqlite3.dll as can be seen below.

Further inspection using Orca indicated that the CustomAction section is configured to execute the DLL file (bz.CustomActionDll).

CAB Extraction & Execution by DLL

Since the DLL will be executed first, the DLL file (bz.CustomActionDll) was analyzed using IDA. The analysis revealed that the DLL retrieves the path to the %TEMP% directory (C:\Users<USER>\AppData\Local\Temp) and appends ‘MW-«UUID»’ to this path. It then creates a directory with this name within the %TEMP% directory, as shown below.

The DLL proceeds to extract those three files of the CAB file under the abovementioned directory using ‘expand.exe’ binary. To achieve this, it first retrieves the path to System32 by calling SHGetFolderPathW with the second argument 37, corresponding to the CSIDL_SYSTEM constant (C:\Windows\System32). It then appends ‘EXPAND.EXE’ to construct the full path to the binary. The DLL also appends the parameters ‘-R files.cab -F:* files’ to specify the extraction operation via ‘expand.exe’ binary . The extraction process is executed by calling ShellExecuteExW with the constructed command.

The three files extracted from CAB file can be seen below.

Following the extraction of the CAB file contents, the DLL utilizes a similar approach to retrieve the path to the ‘icacls.exe’ binary from the C:\Windows\System32 directory. This executable is then run using ShellExecuteExW. By executing the ‘icacls.exe’ binary, the DLL sets the directory integrity level to high, thereby evading detection. This tactic makes it more difficult for security tools operating at a lower integrity level to detect and remove the directory and its contents.

Finally, the DLL execute the iTunesHelper.exe by calling ShellExecuteExW as can be seen below, which is one of the content of the CAB file that was previously extracted via ‘expand.exe’.

Third Stager

DLL SideLoading

The DLL at last executed iTunesHelper.exe as covered in above section. This execution appears to be part of a DLL sideloading technique, where a legitimate executable is used to load and execute a trojanized DLL by hijacking the DLL search order. The DLL search order is shown in image below.

From the previously extracted 3 files, iTunesHelper.exe is a legitimate executable. The CoreFoundation.dll is a trojanized DLL that gets loaded by the legitimate iTunesHelper.exe due to the DLL search order hijacking. The file sqlite3.dll appears to be an encrypted binary as can be seen below. The ‘sqlite3.dll’ is likely to be decrypted by the trojanized DLL after sideloading.

Decrypting Files from Encryted Dropper

Additionally, there are lots of repeating text ‘VzXLKSZE’ under the sqlite3.dll file as seen above. That string looked like XOR key, where the contents of sqlite3.dll will perform XOR operation with that key likely to output a new PE (executable) file. This is one of obfuscation technique seen in the wild.

To verify this hypothesis, the CoreFoundation.dll was loaded into IDA. Analysis confirmed that the contents of sqlite3.dll were indeed subjected to an XOR operation using the string ‘VzXLKSZE’ as the XOR key. The resulting payload from the XOR operation is allocated memory using VirtualAlloc, mapped, and then executed.

Drop Next Stager Files

A quick XOR operation performed on sqlite3.dll with the ‘VzXLKSZE’ key on CyberChef revealed the result to be a 64-bit executable file.

The above resulting executable was saved from CyberChef and loaded in IDA. It was found that this decrypted executable will again use the sqlite3.dll to decrypt next stager files: Autoit3.exe, script.a3x and test.txt. Those file will be dropped under C:\temp. Then, the script.a3x Autoit script will be executed with Autoit3.exe binary, after the encrypted Autoit3.exe binary with XOR operation using ‘VzXLKSZE’ as key.

The sqlite3.dll file have ‘delimitador’ text inside it as marker to separate those file, which can be seen below.

Fourth Stager

Decrypting Obfuscated Autoit (.au3) Script

The files dropped under C:\temp can be seen below.

The Autoit3.exe is legitimate binary which will execute the script.a3x script. So, the analysis was shifted to script.a3x. The original script from script.a3x was extracted using Autoit Extractor as can be seen below. The extracted output was saved to a file.

The output from Autoit Extractor is obfuscated as can be seen below.

From the script, it can be seen that first it will read test.txt file that was dropped previously. After reading the content of test.txt, it will generate array of characters using StringSplit function and saved them to variable $a.

The content of test.txt can be seen below.

The content of test.txt will be used as dictionary to resolve the values of $a[0x??].

• Example: $a[0x3a] = 9, $a[0x6] = 0, $a[0x3e]= E, etc.

Using the above concept, the script can be de-obfuscated. We had written a python script employing that concept and successfully managed to de-obfuscate the script. The script can be found in the Github page.

Autoit3 Process Injection

The de-obfuscated script from above can be seen below.

From the script, it can be seen that all the hex values are concatenated into a variable $bzxrgjfo. This could potentially be another payload. We will analyze it later.

After that, there is check for C:\ProgramData\Sophos directory. And if that directory does not exist, it calls VirtualProtect to modify memory protection of $bzxrgjfo to 0x40 (PAGE_EXECUTE_READWRITE). This is an evasion technique to not get flagged by Sophos.

Then the payload is copied into DLL structure and is injected by calling EnumWindows. Through this, the payload is injected and executed.

Lets now focus on the payload. With the help of Cyberchef, the payload was decrypted which revealed an 32-bit executable as can be seen below.

Fifth Stager

Decrypting Darkgate Loader Autoit (.a3x) Script

The junk code above ‘MZ’ of above decrypted executable was removed to fix the executable and loaded in IDA for analysis. It was found that this executable searches for script.a3x script and locate the payload marked by ‘VzXLKSZE’ under the script.a3x script. Then the payload is decrypted with XOR operation and later mapped and executed.

The payload is marked by ‘VzXLKSZE’ under script.a3x as can be seen below.

Under the xorDecrypt() function, it uses the ‘VzXLKSZE’ to generate new XOR key. Using the new XOR key, the payload is decrypted. The decrypted payload is then executed later.

I have written the loader decryption script to get the final decrypted payload which is in the Github page.

Final Payload

Version

The above decrypted payload, which is the DarkGate was loaded in IDA for analysis. It was found that the version of this DarkGate was ‘6.1.9’ as can be seen below.

Dynamic DLL Loading

The DarkGate dynamically load DLLs and resolve APIs to hinder static detection and analysis as can be seen below.

Security Softwares Checks

DarkGate attempts to check major security softwares via their folders paths and their process names to evade detection as can be seen below.

The security software that DarkGate checks are listed below:

Bitdefender
Avast
Kaspersky
Nod32
Avira
Norton
Symantec
Trend Micro
McAfee
SUPER AntiSpyware
Comodo
MalwareBytes
ByteFence
Search & Destroy
360 Total Security
Total AV
IObit Malware Fighter
Panda Security
Emsisoft
Quick Heal
F-Secure
Sophos
G DATA
Windows Defender

Decrypt Configuration

The DarkGate decrypt its configuration via XOR encryption. The XOR decryption mechanism is similar to that of decrypting DarkGate from DarkGate loader (script.a3x) as covered in above section. The only difference is that instead of using ‘VzXLKSZE’ as marker and to generate XOR key, ‘ckcilIcconnh’ was used as can be seen below.

The same XOR decryption script, which is in the Github page was used to decrypt the DarkGate configuration.

The decrypted reable configuration is shown below.

prodomainnameeforappru.com|
8=No
11=DarkGate
12=R0ijS0qCVITtS0e6xeZ
13=6
14=Yes
15=443
1=Yes
3=Yes
4=Yes
18=50
6=Yes
7=No
19=7000
5=Yes
21=No
22=Yes
23=No
25=admin888
26=No
27=VzXLKSZE
28=No
29=1
tabla=(nq]N*0CV3&ReMOtJ}UaD{W Zxb8uldY"SK2T1rspj$oIFfGB=QL65.Hci9wz)Em4ghAy,k7[XvP