CVE-2024-21412: DarkGate Operators Exploit Microsoft Windows SmartScreen Bypass in Zero-Day Campaign

In addition to our Water Hydra APT zero day analysis, the Zero Day Initiative (ZDI) observed a DarkGate campaign which we discovered in mid-January 2024 where DarkGate operators exploited CVE-2024-21412.


The Zero Day Initiative (ZDI) recently uncovered a DarkGate campaign in mid-January 2024, which exploited CVE-2024-21412 through the use of fake software installers. During this campaign, users were lured using PDFs that contained Google DoubleClick Digital Marketing (DDM) open redirects that led unsuspecting victims to compromised sites hosting the Microsoft Windows SmartScreen bypass CVE-2024-21412 that led to malicious Microsoft (.MSI) installers. The phishing campaign employed open redirect URLs from Google Ad technologies to distribute fake Microsoft software installers (.MSI) masquerading as legitimate software, including Apple iTunes, Notion, NVIDIA, and others. The fake installers contained a sideloaded DLL file that decrypted and infected users with a DarkGate malware payload.

This campaign was part of the larger Water Hydra APT zero-day analysis. The Zero Day Initiative (ZDI) monitored this campaign closely and observed its tactics. Using fake software installers, along with open redirects, is a potent combination and can lead to many infections. It is essential to remain vigilant and to instruct users not to trust any software installer that they receive outside of official channels. Businesses and individuals alike must take proactive steps to protect their systems from such threats.

 DarkGate, which operates on a malware-as-a-service (MaaS) model is one of the most prolific, sophisticated, and active strains of malware in the cybercrime world. This piece of malicious software has often been used by financially motivated threat actors to target organizations in North America, Europe, Asia, and Africa.

Trend Micro customers have been protected from this zero-day since January 17. CVE-2024-21412 was officially patched by Microsoft in their February 13 security patch. In a special edition of the Zero Day Initiative Patch Report, we provide a video demonstration of CVE-2024-21412. To gain insights into how Trend customers enjoy zero-day protection through the ZDI from attacks such as CVE-2024-21412, we provide an in-depth webinar including a Trend Vision One™ live demo.

Analyzing the infection chain

In the following sections, we will explore the DarkGate campaign by looking at each piece of the chain, as shown in Figure 1.

Figure 1. Attack chain schema
Figure 1. Attack chain schema (click to enlarge)

Open redirect: Google DoubleClick Digital Marketing (DDM)

In recent years, threat actors have been abusing Google Ads technologies to spread malware. In addition to purchasing ad space and sponsored posts, threat actors have also been utilizing open redirects in Google DDM technologies. Abusing open redirects could lead to code execution, primarily when used with security bypasses such as CVE-2023-36025 and CVE-2024-21412.  Open redirects abuse the inherent trust associated with major web services and technologies that most users take for granted.

To initiate the DarkGate infection chain, the threat actors deployed an open redirect from the doubleclick[.]net domain inside a PDF file served via a phishing campaign, using the “adurl” parameter that redirected the victim to a compromised web server (Figure 2). The target of the phishing campaign must select the button inside the phishing PDF in order for exploitation of CVE-2024-21412 and DarkGate infection to occur.

Figure 2. Open redirect inside phishing PDF

Figure 2. Open redirect inside phishing PDF

Google uses URL redirects as part of its ad platform and suite of other online ad-serving services. At its core, Google DoubleClick provides solutions designed to help advertisers, publishers, and ad agencies manage and optimize their online advertising campaigns. We have seen an increase in the abuse of the Google Ads ecosystem to deliver malicious software in the past, including threat actors using popular MaaS stealers such as Rhadamanthys and macOS stealers like Atomic Stealer (AMOS). Threat actors can abuse Google Ads technologies to increase the reach of malware through specific ad campaigns and by targeting specific audiences.

When a user uses the Google search engine to look for content, sponsored ads will be shown to the user. These are placed by businesses and marketing teams using technologies such as Google DoubleClick. These ad technologies track what queries the user submits and show relevant ads based on the query.

When selecting an ad, the user initiates a request chain that leads the user to redirect to the targeted resource set by the advertiser (Figure 3). The Google DoubleClick technologies operate under the HTTP/2 protocol; we can decrypt this traffic to understand the flow of redirection from the network. 

Figure 3. Sample decrypted Google DoubleClick ad request
Figure 3. Sample decrypted Google DoubleClick ad request (click to enlarge)

Besides purchasing ad space directly, one way in which threat actors can spread malicious software more efficiently is by using open redirects in URLs related to Google DDM. Abusing open redirects might lead to code execution, primarily when used with security bypasses such as CVE-2023-36025 and CVE-2024-21412. While Microsoft Windows has a feature called Mark-of-the-Web (MotW) to flag content from insecure sources such as the web, DarkGate operators can bypass Windows Defender SmartScreen protections by exploiting CVE-2024-21412, which leads to DarkGate infection. In this attack chain, the DarkGate operators have abused the trust given to Google-related domains by abusing Google open redirects, paired with CVE-2024-21412, to bypass Microsoft Defender SmartScreen protections, which green-flags victims into malware infection.

Execution: Exploiting CVE-2024-21412 (ZDI-CAN-23100) to bypass Windows Defender SmartScreen

To exploit CVE-2024-21412, the operators behind DarkGate redirect a victim with the Google DoubleClick open redirect to a compromised web server which contains the first .URL internet shortcut file.

This internet shortcut file exploits CVE-2024-21412 by redirecting to another internet shortcut file, as shown in Figure 4. The internet shortcut file uses the “URL=” parameter to point to the next stage of the infection process; this time, it is hosted on an attacker-controlled WebDAV server.

Figure 4. Contents of “JANUARY-25-2024-FLD765.url”

Figure 4. Contents of “JANUARY-25-2024-FLD765.url”

The next stage of the infection process points to a .MSI file containing a zip archive (ZIP) in the path exploiting CVE-2023-36025, as shown in Figure 5. 

Figure 5. Contents of “gamma.url”

Figure 5. Contents of “gamma.url”

This sequence of internet shortcut redirection that executes a Microsoft software installer from an untrusted source should properly apply MotW that will, in turn, stop and warn users through Microsoft Defender SmartScreen that a script is attempting to execute from an untrusted source, such as the web. By exploiting CVE-2024-21412, the victim’s Microsoft Defender SmartScreen is not prompted due to a failure to properly apply MotW. This leaves the victim vulnerable to the next stage of the DarkGate infection: fake software installers using .MSI files.

Execution: Stage 1 –  DarkGate Microsoft software installers 


File name SHA256 Size
Test.msi 0EA0A41E404D59F1B342D46D32AC21FBF3A6E005FFFBEF178E509EAC2B55F307 7.30 MB


Table 1. .MSI file sample

In the next stage of the infection chain, a .MSI file is used to sideload a DLL file, and an AutoIt script is used to decrypt and deploy the DarkGate payload. In the particular sample shown in Table 1, the DarkGate operators wrap the DarkGate payload in a .MSI installer package masquerading as an NVIDIA installer (Figure 6). This installer is executed with the Windows msiexec.exe utility, as shown in Figure 7.  To the victim, an installer appears, and to them it seems as if a normal NVIDIA software installation is occurring.

Figure 6. The fake NVIDIA .MSI installer package, “instantfeat.msi”

Figure 6. The fake NVIDIA .MSI installer package, “instantfeat.msi”
Figure 7. MSI execution process

Figure 7. MSI execution process

The .MSI installer employs a CustomActionDLL, a DLL file that contains the logic of the installation process (Figure 8).

Initially, the CustomActionDLL generates a directory within the %tmp% folder named MW-<Uuid>, where it places a Windows Cabinet archive (CAB) named It then utilizes the built-in Windows tool expand.exe to decompress the contents of the CAB file. Following this, it proceeds to execute a digitally signed, legitimate binary file, NVIDIA Share.exe.

Figure 8. MSI installation logic
Figure 8. MSI installation logic (click to enlarge)

Execution: Stage 2 – DLL sideloading


File name SHA256 Size Signature verification
NVIDIA Share.exe F1E2F82D5F21FB8169131FEDEE6704696451F9E28A8705FCA5C0DD6DAD151D64 3,264 KB Signed file, valid signature
libcef.dll 64D0FC47FD77EB300942602A912EA9403960ACD4F2ED33A8E325594BF700D65F 1,514 KB
sqlite3.dll DF0495D6E1CF50B0A24BB27A53525B317DB9947B1208E95301BF72758A7FD78C 1,656 KB
chrome_elf.dll 37647FD7D25EFCAEA277CC0A5DF5BCF502D32312D16809D4FD2B86EEBCFE1A5B   Signed file, valid signature


Table 2. DLL sideloading samples

In the second stage of payload execution, DarkGate employs a DLL sideloading technique, where a legitimate app loads a malicious DLL file. In this case, the adversary uses the NVIDIA Share.exe application to load a trojanized libcef.dll library. Our investigation showed that different campaigns use a variety of legitimate apps for DLL sideloading. We have listed these compromised files at the end of this entry.

The malicious code resides within the “GetHandleVerifier” function of the libcef.dll file, which is invoked from the DLL’s entry point. The purpose of this DLL is to decrypt the next stage of the XOR-encrypted loader, named sqlite3.dll (Figure 9). The DarkGate stub builder creates an 8-byte master key, which is used throughout all modules and components in that build. In this attack, the master key is “zhRVKFlX”. For each stage, the malware uses this key in different ways. Sometimes it uses the key as a marker to tell different payloads apart in a file, or it decrypts this key with a custom XOR algorithm to make another key for decrypting the payload.

Figure 9. Decryption process of “sqlite3.dll”
Figure 9. Decryption process of “sqlite3.dll” (click to enlarge)

Execution: Stage 3 – AutoIt loader


File name SHA256 Size Compile date
DLL_Internal.exe 5C5764049A7C82E868C9E93C99F996EFDF90C7746ADE49C12AA47644650BF6CB 1,657 KB Jan. 3, 2024


Table 3. AutoIT dropper sample

The sqlite3.dll file is segmented into four distinct parts:

  • Segment 1: Encrypted loader
  • Segment 2: Encrypted Autoit3.exe
  • Segment 3: Clear-text script.au3
  • Segment 4: Clear-text test.txt

The first segment, which is 321 KB, is an AutoIt loader executable that was decrypted from an earlier step. The loader binary starts with an “MZRE” header, allowing it to execute as a shellcode. This shellcode is engineered to dynamically map and load a PE file (AutoIt loader) into the system’s memory. Once the PE file is mapped in memory, the shellcode executes the Original Entry Point (OEP) of the payload executable.

Upon execution, the loader reads the original sqlite3.dll file and looks for the keyword “delimitador” (Figure 10). It uses this keyword as a marker to identify and separate each file contained within. Then, it extracts these files and saves them to the C:temp directory.

Figure 10. AutoIt modules dropper
Figure 10. AutoIt modules dropper (click to enlarge)

Execution: Stage 4 – AutoIt script analysis

File name SHA256 Size
Autoit3.exe 237D1BCA6E056DF5BB16A1216A434634109478F882D3B1D58344C801D184F95D 873 KB
script.au3 22EE095FA9456F878CFAFF8F2A4871EC550C4E9EE538975C1BBC7086CDE15EDE 469 KB
test.txt 1EA0E878E276481A6FAEAF016EC89231957B02CB55C3DD68F035B82E072E784B 76 bytes

Table 4. AutoIt script samples

The script.au3 is a pre-compiled AutoIt script that contains two sections (Figure 11). The first section is a valid AutoIt compiled script with magic bytes “AU3!EA06” (0x4155332145413036) that will be executed by the AutoIt.exe file. The second section is an encrypted DarkGate remote access trojan (RAT), the start and end of the encrypted payload marked with “zhRVKFlX”.

Figure 11. Structure of “script.au3”
Figure 11. Structure of “script.au3” (click to enlarge)

The script.au3 is responsible for loading and executing the stage-five DarkGate loader in memory. The snippet shown in Figure 12 is a decompiled AutoIt script. 

Figure 12. Decompiled AutoIt script
Figure 12. Decompiled AutoIt script (click to enlarge)

The test.txt file acts as an external data source. The script reads the content of test.txt (Figure 13), splits it into an array of individual characters, and then selectively concatenates certain characters based on predefined indices to construct a command or expression. 

Figure 13. Contents of “test.txt”

Figure 13. Contents of “test.txt”

The variable “$ ZZNDMOFL” holds a binary file, and at the end there is logic to load the binary into memory and pass the execution process to via API callback functions. The snippet shown in Figure 14 is the deobfuscated logic:

Figure 14. Deobfuscated logic
Figure 14. Deobfuscated logic (click to enlarge)

The code proceeds to verify the presence of “CProgramDataSophos” directory on the system. It seems this directory name is distorted due to obfuscation processes. In a previous version of the script, the existence check was aimed at the C:Program Files(x86)Sophos folder, indicating an error in directory naming in this version.

The script creates a C-like structure in memory via “DllStructCreate,” which will be used when calling DLL functions and allocates the necessary space for the DarkGate loader payload. It then makes a system call to kernel32.dll using “DllCall”, invoking the “VirtualProtect” function. This function is used to change the protection on a region of memory within the process’s virtual address space. The protection is set to 0x40, which corresponds to “PAGE_EXECUTE_READWRITE”, allowing the memory region to be executed, read, and written to.

The script then populates the previously created structure with binary data converted from a string representation. This conversion is done by taking a hexadecimal string stored in the variable “$ZZNdmOFL”, converting it to binary with “BinaryToString”, and then setting this binary data into the first segment of “$PT” using “DllStructSetData”. This process effectively loads the DarkGate Delphi loader binary.

Lastly, the script uses API callback functions to redirect the flow of execution to the next stage payload. Callback functions are routines that are passed as a parameter to Windows API functions. The script issues a system call to user32.dll to invoke “EnumWindows”, leveraging the pointer that corresponds to the “$ZZNdmOFL” value.

Execution: Stage 5 – DarkGate shellcode PE loader

The shellcode execution begins with three jumps to the binary header. From there, a call is made to a custom implementation of the PE loader (Figure 15).

Figure 15. Call made to a custom implementation of the PE loader
Figure 15. Call made to a custom implementation of the PE loader (click to enlarge)

The DarkGate loader requires a PE loader to map the binary file in memory. To solve this issue, the “$ZZNdmOFL” variable contains a shellcode that loads and executes a PE file in memory (Figure 16).

Figure 16. DarkGate custom PE loader
Figure 16. DarkGate custom PE loader (click to enlarge)

Execution: Stage 5.1 – DarkGate Delphi loader analysis

The primary purpose of the DarkGate loader is to extract the final payload DarkGate RAT from the AutoIt script, load it into the memory, decrypt it, and execute it (Figure 17).

When the loader is run, it checks the command-line argument of the AutoIt.exe process, which indicates the path to the AutoIt script. If a parameter is present, it proceeds to load the script’s content into a buffer. Then, it uses an 8-byte marker (“zhRVKFLX”) to search through the content to find the encrypted blob, which starts right after the marker.

Figure 17. Find and load encrypted DarkGate payload from AutoIt script

Figure 17. Find and load encrypted DarkGate payload from AutoIt script

The payload decryption key is encrypted with XOR. The loader decrypts the key by iterating over each byte, applying an XOR operation with a value that decreases from the key’s length, as shown in Figure 18.

Figure 18. Process for decrypting the payload decryption key
Figure 18. Process for decrypting the payload decryption key (click to enlarge)

After obtaining the decryption key, “roTSOEnY”, the malware then utilizes a custom XOR decryption method to decrypt the payload (Figure 19). The decryption process begins by applying an XOR operation to each byte, pairing it with a corresponding byte from the decrypted key. This pairing is guided by a key index that dynamically updates throughout the process. This key index is recalculated after each XOR operation by adding the current key byte’s value to the index and taking the modulus with the key’s total size, ensuring the index cycles through the key in a pseudo-random manner. If the key index ever reaches zero following an update, it is reset to the last position in the key. This process is repeated for each byte in the payload until the entire blob has been decrypted.

Figure 19. DarkGate payload decryption process
Figure 19. DarkGate payload decryption process (click to enlarge)

Once the loader decrypts the payload, it passes it to the function “mw_Execute_Payload” to execute the payload directly from memory (Figure 20). The execution process can be broken down into five steps:

  1. Memory allocation. The function begins by allocating memory to host the payload. It uses the “VirtualAlloc” API call with “MEM_COMMIT” and a protection flag of 0x40 (PAGE_EXECUTE_READWRITE), allowing the allocated memory to be executed.
  2. Header and section mapping. It then copies the PE headers and each section of the PE file into the allocated memory. This includes both the executable code and data sections.
  3. Import resolution. Next, the function resolves imports by walking through the import directory. For each imported DLL, it loads the library using “LoadLibraryA” and then resolves each required function with “GetProcAddress”. The addresses of these functions are updated in the Import Address Table (IAT).
  4. Base relocation handling. The code performs base relocations to adjust memory addresses within the loaded image.
  5. Execution. Finally, the loader transfers execution control to the entry point (OEP) of the loaded PE file. This is implied to be done through an assembly jump instruction “__asm { jmp eax }”, where each contains the address of the entry point.
Figure 20. DarkGate loader execution overview

Figure 20. DarkGate loader execution overview

Figure 21. DarkGate loader payload executing process
Figure 21. DarkGate loader payload executing process (click to enlarge)

DarkGate RAT analysis


SHA-256 18d87c514ff25f817eac613c5f2ad39b21b6e04b6da6dbe8291f04549da2c290
Compiler Borland Delphi
Original name Stub
File type Win32 
DarkGate version  6.1.7


Table 5. Properties of the DarkGate RAT sample

DarkGate is a RAT written in Borland Delphi that has been advertised as a MaaS on a Russian-language cybercrime forum since at least 2018. The malware has various features, including process injection, the download and execution file, information stealing, shell command execution, keylogging abilities, and more. It also employs multiple evasion techniques.

In this campaign, DarkGate version 6.1.7 has been deployed. The main changes in version 6 include XOR encryption for configuration, the addition of new config values, a rearrangement of config orders to overcome the version 5 automation config extractor, and updates to command-and-control (C&C) command values.

Upon execution, DarkGate activates anti-ntdll.dll hooking by using the Direct System Call (syscall) method, specifically designed for times when the malware needs to call native APIs from ntdll.dll. This technique permits DarkGate to invoke kernel-mode functions directly, bypassing the standard user-mode API layers. Utilizing syscalls, DarkGate adeptly masks its deployment of process hollowing techniques, which are often flagged through the monitoring of API calls. This method not only enhances the stealthiness of the malware but also complicates detection and analysis efforts by security mechanisms, as it obfuscates the malware’s reliance on critical system functions for malicious activities.

The malware determines the operating system architecture by checking for the presence of the C:WindowsSysWOW64ntdll.dll file. Depending on whether the architecture is x64 or x86, DarkGate employs a different syscall method. For x86 architecture, syscalls are executed directly using inline assembly with the “sysenter” instruction. Conversely, for x64 architecture, it utilizes the “FS:[0xC0]” pointer, which references the “wow64cpu!KiFastSystemCall” to perform the syscall (Figure 22).

Figure 22. 64-bit system KiFastSystemCall function

Figure 22. 64-bit system KiFastSystemCall function

Malware often calls API functions that leave behind static artifacts, such as strings in the payload files. These artifacts can be leveraged by defense analysts to deduce the range of functions a binary file might execute, typically through an examination of its Import Address Table (IAT).

To evade static analysis, minimize the visibility of suspicious API calls, obscure malicious functionalities, and hinder the effectiveness of defensive analysis, the malware dynamically resolves API functions during runtime. The following is a list of API functions resolved dynamically at runtime by DarkGate:

  • user32.dll
    • MessageBoxTimeoutA
    • GetWindowTextA
    • GetWindowTextW
    • FindWindowExA
    • GetForegroundWindow
    • FindWindowA
    • GetKeyState
    • EnumDisplayDevicesA
    • GetKeyboardState
    • GetWindow
    • GetWindowThreadProcessId
    • SendMessageA
    • GetWindowTextLengthW
  • Advapi32.dll
    • RegSetValueExA
    • RegDeleteValueA
    • RegCloseKey
    • RegOpenKeyExA
  • Shell32.dll
    • ShellExecuteA

Unlike DarkGate version 5, in which configuration is in clear text, the configuration in version 6 is XOR-encrypted. The decryption process, as shown in Figure 23, is similar to the Delphi loader in Figure 21. The function accepts the encrypted buffer, hard-coded key and buffer size. It then generates a new decryption key based on the given key and decrypts the configuration buffer. 

Figure 23. DarkGate version 6 configuration decryption process
Figure 23. DarkGate version 6 configuration decryption process (click to enlarge)

Table 6 outlines key configuration settings for DarkGate version 6, including parameter keys, value types, and descriptions.


Parameter key Value type and value Description
0/DOMAINS String: jenb128hiuedfhajduihfa[.]com C&C server domain
EPOCH Int: XXXXXX Payload generated time
8 Bool: Yes Fake Error: Display “MessageBoxTimeOut with” message for six seconds
11 String: DarkGate Fake Error: “MessageBoxTimeOut lpCaption” value
12 String: R0ijS0qCVITtS0e6xeZ Custom Base64-encoded text for the fake error message, decodes to “HelloWorld!”
15 80 Designates the port number used by the C&C server
1 Bool: Yes Enables startup persistence and malware installation
3 Bool: Yes Activates anti-virtual machine (VM) checks based on display devices
4 Bool: Yes Enables anti-VM check for minimum disk storage
18 Int: 100 Specifies the minimum disk storage required to bypass the VM check in option 4
6 Bool: Yes Activates anti-VM checks based on display devices
7 Bool: Yes Enables anti-VM check for minimum RAM size
19 Int: 7000 Sets the minimum RAM size required for the anti-VM check in option 7
5 Bool: Yes Checks if the CPU is Xeon to detect server environments
25 String: admin888 Campaign ID
26 Bool: No Determines whether execution with process hollowing is enabled
27 String: zhRVKFlX Provides the XOR key/marker used for DarkGate payload decryption
Tabla String: n]Swa6”NY=.yB3jICJzqO147gos{UaciQP(LT2[…REDACTED…] test.txt data (External data source to decrypt AutoIt script)


Table 6. Key configuration settings for DarkGate version 6

After completing the initial setup, the malware registers the infected system with its C&C server via HTTP POST requests. The following snippet shows the structure of a registration message:

<Foreground Window title – utf16 – Hex encoded>|<Idle Time>|<GetTickCount >|<Bool: IsUserAnAdmin>|<Darkgate Version>|||

The structure is composed of the following:

  1. Title of foreground window. This is the title of the window that is currently active or in the foreground on the infected machine. The title is encoded in UTF-16 and then converted to hexadecimal.
  2. Idle time in seconds. This represents the duration, in seconds, since the last user interaction (keyboard or mouse input) with the system.
  3. System uptime in milliseconds. This is obtained using the “GetTickCount” Windows API function and indicates the amount of time, in milliseconds, that has elapsed since the system was last started.
  4. Is the user an administrator. This is a Yes/No flag indicating whether the malware has administrative privileges on the infected system.
  5. Version of DarkGate malware. This specifies the version of the DarkGate malware that has infected the system.

To transmit the data to the C&C server, the malware executes a series of steps, detailed as follows:

  1. Initialization of data packet: The data designated for exfiltration is prepended with a distinct traffic identifier to facilitate tracking. For instance, the integer “1000” is utilized for initial C&C registration traffic and command retrieval.
  2. Unique identification hash calculation: A custom encoded MD5 hash is generated by combining the Windows Product ID, Processor Information, and Hex-Encoded Computer Name. The malware uses this hash for various operations, and it is generated during the malware’s initial execution. The components used in this calculation include:
    1. Windows Product ID: Located at the registry path, “HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProductId”
    2. Processor Information: Extracted from “KLMHARDWAREDESCRIPTIONSystemCentralProcessorProcessorNameString” and the total number of processors obtained through the “GetSystemInfo” function
    3. Computer Name: The computer’s name, encoded in UTF-16 hex format
    4. Custom Encoding: The resulting MD5 digest is then encoded with a specialized alphabet: “abcdefKhABCDEFGH”.
  3. Key generation: An XOR operation is applied to the MD5 hash to produce a new encryption key.
  4. Data encryption: The original data is encrypted using the newly generated key through an XOR cipher.
  5. Prepending encoded hash: The original (pre-encryption) encoded MD5 hash is prepended to the encrypted data. This hash serves as a decryption key for the DarkGate C&C server, ensuring data retrieval.
Figure 24. Packet decryption key and encrypted content

Figure 24. Packet decryption key and encrypted content

6. Final encoding: The data packet, which includes the encoded hash and encrypted data, is then converted into Base64 format using a custom alphabet:


An example of DarkGate version 6 C&C server initial network traffic is shown in Figure 25.

Figure 25. DarkGate version 6 C&C initial traffic

Figure 25. DarkGate version 6 C&C initial traffic

The decrypted content is as follows:


If the C&C server does not return the expected command, DarkGate will enter an infinite loop and continue sending traffic until it receives an expected command. Figure 26 is an example of a command request from an infected system and the response from the C&C server.

Figure 26. DarkGate version 6 command request

Figure 26. DarkGate version 6 command request

The decrypted request content is as follows:



In this research, a follow-up to our Water Hydra APT Zero Day campaign analysis, we explored how the DarkGate operators were able to exploit CVE-2024-21412 as a zero-day attack to deploy the complex and evolving DarkGate malware. We also explored how security bypass vulnerabilities can be used in conjunction with open redirects in technologies such as the Google Ads ecosystem to proliferate malware and abuse the inherent trust that organizations have in basic web technologies.

To make software more secure and protect customers from zero-day attacks, the Trend Zero Day Initiative works with security researchers and vendors to patch and responsibly disclose software vulnerabilities before APT groups can deploy them in attacks. The ZDI Threat Hunting team also proactively hunts for zero-day attacks in the wild to safeguard the industry.

Organizations can protect themselves from these kinds of attacks with Trend Vision One, which enables security teams to continuously identify attack surfaces, including known, unknown, managed, and unmanaged cyber assets. Vision One helps organizations prioritize and address potential risks, including vulnerabilities. It considers critical factors such as the likelihood and impact of potential attacks and offers a range of prevention, detection, and response capabilities. This is all backed by advanced threat research, intelligence, and AI, which helps reduce the time taken to detect, respond, and remediate issues. Ultimately, Trend Vision One can help improve the overall security posture and effectiveness of an organization, including against zero-day attacks.

When faced with uncertain intrusions, behaviors, and routines, organizations should assume that their system is already compromised or breached and work to immediately isolate affected data or toolchains. With a broader perspective and rapid response, organizations can address breaches and protect their remaining systems, especially with technologies such as Trend Micro™ Endpoint Security™ and Trend Micro Network Security, as well as comprehensive security solutions such as Trend Micro™ XDR, which can detect, scan, and block malicious content across the modern threat landscape.

Trend Protections

The following protections exist to detect and protect Trend customers against the zero-day CVE-2024-21412 (ZDI-CAN-23100).

Trend Vision One Model

  • Potential Exploitation of Microsoft SmartScreen Detected (ZDI-CAN-23100)
  • Exploitation of Microsoft SmartScreen Detected (CVE-2024-21412)
  • Suspicious Activities Over WebDav

Trend Micro Cloud One – Network Security & TippingPoint Filters

  • 43700HTTP: Microsoft Windows Internet Shortcut SmartScreen Bypass Vulnerability
  • 43701ZDI-CAN-23100: Zero Day Initiative Vulnerability (Microsoft Windows SmartScreen)

Trend Vision One Network Sensor and Trend Micro Deep Discovery Inspector (DDI) Rule

  • 4983CVE-2024-21412: Microsoft Windows SmartScreen Exploit – HTTP(Response)

Trend Vision One Endpoint Security, Trend Cloud One – Workload and Endpoint Security, Deep Security and Vulnerability Protection IPS Rules

  • 1011949Microsoft Windows Internet Shortcut SmartScreen Bypass Vulnerability (CVE-2024-21412)
  • 1011950 Microsoft Windows Internet Shortcut SmartScreen Bypass Vulnerability Over SMB (CVE-2024-21412)
  • 1011119Disallow Download Of Restricted File Formats (ATT&CK T1105)
  • 1004294Identified Microsoft Windows Shortcut File Over WebDav
  • 1005269Identified Download Of DLL File Over WebDav (ATT&CK T1574.002)
  • 1006014 Identified Microsoft BAT And CMD Files Over WebDav

Indicators of Compromise (IOCs)

Download the IOC list here.

Source: Original Post

“An interesting youtube video that may be related to the article above”