CVE-2024-21412: DarkGate Attackers Utilize Microsoft Windows SmartScreen Circumvention in Zero-Day Operation

In mid-January 2024, the Zero Day Initiative (ZDI) discovered a DarkGate campaign leveraging CVE-2024-21412. This campaign utilized counterfeit software installers to exploit the vulnerability. Attackers deceived users with PDFs containing Google DoubleClick Digital Marketing (DDM) open redirects, which directed victims to compromised websites featuring the CVE-2024-21412 bypass for Microsoft Windows SmartScreen. These sites hosted malicious Microsoft (.MSI) installers. The phishing effort used open redirect URLs from Google Ad technologies to distribute fraudulent Microsoft software installers (.MSI) that appeared to be legitimate, including well-known programs such as Apple iTunes, Notion, and NVIDIA. These fake installers carried a sideloaded DLL that decrypted and deployed a DarkGate malware payload onto the users' systems.

This operation was a component of the broader Water Hydra APT zero-day analysis. The Zero Day Initiative (ZDI) tracked this campaign carefully and examined its methods. The use of counterfeit software installers in conjunction with open redirects proves to be a highly effective strategy for spreading infections. It is crucial to stay alert and advise users against trusting any software installer received through unofficial sources. Both businesses and individuals should adopt proactive measures to safeguard their systems against these kinds of threats.

DarkGate, a prominent example of malware-as-a-service (MaaS), stands out as one of the most widespread, advanced, and active malware variants in the cybercriminal landscape. Frequently utilized by financially driven threat actors, this malware targets organizations across North America, Europe, Asia, and Africa.

Since January 17, DeepDefend customers have been shielded from this zero-day vulnerability. Microsoft addressed CVE-2024-21412 with a security patch released on February 13. In a special edition of the Zero Day Initiative Patch Report, we feature a video demonstration of CVE-2024-21412. For a detailed look at how DeepDefend’s protection against zero-day threats like CVE-2024-21412 is delivered through the ZDI, we offer an in-depth webinar that includes a live demonstration of DeepDefend XDR™.

Examining the Infection Chain

In the upcoming sections, we will delve into the DarkGate campaign by dissecting each element of the infection chain, as illustrated in Figure 1.

Figure 1. Attack Chain schema

Open Redirect: Google DoubleClick Digital Marketing (DDM)

In recent years, cybercriminals have increasingly exploited Google Ads technologies to disseminate malware. Beyond purchasing advertising space and sponsored content, they have also been taking advantage of open redirects within Google DDM technologies. These redirects can be particularly dangerous when combined with security vulnerabilities such as CVE-2023-36025 and CVE-2024-21412, as they exploit the inherent trust users place in major web services and technologies.

To kickstart the DarkGate infection chain, attackers utilized an open redirect from the doubleclick[.]net domain embedded in a PDF file distributed through a phishing scheme. This PDF contained an “adurl” parameter that directed victims to a compromised server (see Figure 2). For the exploitation of CVE-2024-21412 and subsequent DarkGate infection to take place, the target needs to click the button within the phishing PDF.

Figure 2. Open redirect inside phishing PDF

Google's ad platform and associated services utilize URL redirects as a fundamental component. Google DoubleClick, in particular, offers tools to assist advertisers, publishers, and ad agencies in managing and optimizing their digital advertising efforts. Recently, there has been a notable rise in the misuse of the Google Ads ecosystem for delivering malware. Cybercriminals have leveraged this platform to distribute various types of malicious software, including popular MaaS stealers like Rhadamanthys and macOS stealers such as Atomic Stealer (AMOS). By exploiting Google Ads technologies, attackers can broaden the reach of their malware through targeted ad campaigns and specific audience targeting.

When a user performs a search on Google, sponsored ads are displayed alongside the search results. These ads are placed by businesses and marketing teams utilizing technologies like Google DoubleClick. These ad technologies monitor the search queries submitted by users and display relevant ads tailored to those queries.

When a user clicks on an ad, it triggers a request chain that redirects the user to the intended resource specified by the advertiser (see Figure 3). Google DoubleClick technologies operate using the HTTP/2 protocol, which allows us to decrypt this traffic and trace the redirection flow through the network.

Figure 3. Sample decrypted Google DoubleClick ad request.

In addition to directly purchasing ad space, threat actors can more effectively distribute malicious software by exploiting open redirects in URLs associated with Google DDM. Abusing open redirects can enable code execution, particularly when combined with security vulnerabilities like CVE-2023-36025 and CVE-2024-21412. Although Microsoft Windows features a Mark-of-the-Web (MotW) mechanism to flag content from less secure sources, DarkGate operators can circumvent Windows Defender SmartScreen protections by leveraging CVE-2024-21412. This tactic allows them to bypass these security measures and facilitate DarkGate infections. In this attack chain, DarkGate operators exploit the trust associated with Google-related domains by using Google open redirects in conjunction with CVE-2024-21412 to evade Microsoft Defender SmartScreen protections, ultimately leading to malware infections for the victims.

Execution: Leveraging CVE-2024-21412 (ZDI-CAN-23100) to Circumvent Windows Defender SmartScreen

To exploit CVE-2024-21412, DarkGate operators first redirect a victim via a Google DoubleClick open redirect to a compromised web server. There, the victim encounters the initial .URL internet shortcut file.

This internet shortcut file takes advantage of CVE-2024-21412 by redirecting the victim to a subsequent internet shortcut file, as depicted in Figure 4. The file employs the “URL=” parameter to direct to the next phase of the infection process, which is now hosted on an attacker-controlled WebDAV server.

Figure 4. Contents of "JANUARY-25-2024-FLD765.url"

The subsequent stage of the infection process directs to an .MSI file that contains a ZIP archive within its path, exploiting CVE-2023-36025, as illustrated in Figure 5.

Figure 5. Contents of "gamma.url"

This chain of internet shortcut redirections, which triggers the execution of a Microsoft software installer from an untrusted source, should normally invoke the Mark-of-the-Web (MotW) flag. This flag would prompt Microsoft Defender SmartScreen to alert users about the execution of a script from an insecure source, such as the web. However, by exploiting CVE-2024-21412, the victim's Microsoft Defender SmartScreen does not trigger the MotW flag properly. As a result, the victim remains exposed to the next phase of the DarkGate attack: malicious software installers disguised as .MSI files.

Execution: Stage 1 – DarkGate Malicious Microsoft Software Installers

File name	SHA256	Size
Test .msi	0EA0A41E404D59F1B342D46D32AC21FBF3A6E005FFFBEF178E509EAC2B55F307	7.30 MB

Table 1. .Msi file sample

In the following stage of the infection chain, a .MSI file is employed to sideload a DLL file, while an AutoIt script is used to decrypt and deploy the DarkGate payload. In the example detailed in Table 1, the DarkGate operators have encapsulated the DarkGate payload within a .MSI installer that masquerades as an NVIDIA installer (see Figure 6). This installer is run using the Windows msiexec.exe utility, as illustrated in Figure 7. To the victim, the installer appears as if a standard NVIDIA software installation is taking place.

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

Figure 7. MSI execution process.

The .MSI installer utilizes a CustomActionDLL, which is a DLL file responsible for managing the logic of the installation process (see Figure 8).

Initially, the CustomActionDLL creates a directory in the %tmp% folder labeled MW-<Uuid>, where it stores a Windows Cabinet archive (CAB) named files.cab. It then uses the built-in Windows tool expand.exe to extract the contents of the CAB file. After extraction, the installer executes a legitimate, digitally signed binary file, NVIDIA Share.exe.

Figure 8. MSI insallation logic.

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	-
slite3.dll	DF0495D6E1CF50B0A24BB27A53525B317DB9947B1208E95301BF72758A7FD78C	1,656 KB	-
chrome_elf.dll	37647FD7D25EFCAEA277CC0A5DF5BCF502D32312D16809D4FD2B86EEBCFE1A5B		Signed file, valid signature

Table 2. DLL sideloading samples

In the second stage of the payload execution, DarkGate utilizes DLL sideloading, where a legitimate application is exploited to load a malicious DLL file. Specifically, the attackers use the NVIDIA Share.exe application to load a compromised libcef.dll library. Our investigation has revealed that various campaigns employ different legitimate applications for DLL sideloading. A list of these compromised files is provided at the end of this entry.

The malicious code is embedded within the “GetHandleVerifier” function of the libcef.dll file, which is called from the DLL's entry point. This DLL’s role is to decrypt the next stage of the XOR-encrypted loader, identified as sqlite3.dll (see Figure 9). The DarkGate stub builder generates an 8-byte master key, which is used consistently across all modules and components of this build. In this instance, the master key is “zhRVKFlX”. The malware employs this key in various ways throughout each stage: it may use the key as an identifier to differentiate between payloads in a file, or it may decrypt this key using a custom XOR algorithm to produce another key for decrypting the payload.

Figure 9. Decryption process of "sqlite3.dll"

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 initial segment, measuring 321 KB, is an AutoIt loader executable that was decrypted in a previous step. This loader binary begins with an "MZRE" header, enabling it to function as shellcode. This shellcode is designed to dynamically map and load a Portable Executable (PE) file—specifically, the AutoIt loader—into the system's memory. Once the PE file is successfully mapped, the shellcode then executes the Original Entry Point (OEP) of the payload executable.

Upon execution, the loader scans the sqlite3.dll file for the keyword "delimitador" (see Figure 10). This keyword serves as a marker to identify and demarcate each file embedded within. The loader then extracts these files and saves them to the C:\temp directory.

Figure 10. AutoIT modules dropper (click to enlarge)

Execution: Stage 4 - AutoIt script analysis

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

Table 4. Autoit script samples

The `script.au3` file is a pre-compiled AutoIt script comprising two distinct sections (see Figure 11). The first section contains a valid AutoIt script, identified by the magic bytes “AU3!EA06” (0x4155332145413036), which will be executed by the AutoIt.exe file. The second section holds an encrypted DarkGate remote access trojan (RAT), with the beginning and end of the encrypted payload delineated by the marker “zhRVKFlX”.

Figure 11. Structure of "script.au3"

The `script.au3` file is tasked with loading and executing the stage-five DarkGate loader directly in memory. The decompiled AutoIt script, as illustrated in Figure 12, demonstrates this functionality.

Figure 12. Decompiled Autoit script.

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"

The variable `$ZZNDMOFL` contains a binary file. At the end of the script, there is code designed to load this binary into memory and transfer execution to the loader using "EnumWindows" API callback functions. The deobfuscated logic is depicted in the snippet shown in Figure 14.

Fiure 14. Deobfuscated logic.

The code then checks for the presence of a directory named “CProgramDataSophos” on the system. This directory name appears to be obfuscated. In an earlier version of the script, the check was for the C:\Program Files(x86)\Sophos folder, suggesting that there may have been an error or intentional distortion in the directory naming in this current version.

The script constructs a C-like structure in memory using `DllStructCreate`, which will be utilized for calling DLL functions and allocating space for the DarkGate loader payload. It then makes a system call to `kernel32.dll` through `DllCall`, invoking the `VirtualProtect` function. This function modifies the memory protection for a region within the process's virtual address space. The protection is set to `0x40`, which equates to `PAGE_EXECUTE_READWRITE`, permitting the memory region to be executed, read, and written.

The script then fills the previously created structure with binary data converted from a string representation. This is achieved by taking a hexadecimal string stored in the variable `$ZZNdmOFL`, converting it to binary using `BinaryToString`, and then inserting this binary data into the first segment of `$PT` with `DllStructSetData`. This step effectively loads the DarkGate Delphi loader binary.

Finally, the script employs API callback functions to redirect the execution flow to the next stage of the payload. Callback functions are routines provided as parameters to Windows API functions. The script makes a system call to `user32.dll` to invoke `EnumWindows`, using the pointer associated with the `$ZZNdmOFL` value to facilitate this transition.

Execution: Stage 5 - DarkGate shellcode PE loader

The shellcode execution starts with three jump instructions that direct the flow to the binary header. From this point, a call is made to a custom implementation of the PE loader (see Figure 15).

Figure 15. Call made to custom implementation of the PE loader.

The DarkGate loader needs a PE loader to map the binary file into memory. To address this, the `$ZZNdmOFL` variable contains shellcode designed to load and execute a PE file directly in memory (see Figure 16).

Figure 16. DarkGate custom PE loader

Execution: Stage 5.1 - DarkGate Delphi loader analysis

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

Upon execution, the loader examines the command-line arguments of the AutoIt.exe process to determine the path to the AutoIt script. If a parameter is provided, it loads the script's content into a buffer. It then searches the content using an 8-byte marker (“zhRVKFLX”) to locate the encrypted blob, which begins immediately after the marker.

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

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

Figure 18. Process for decrypting the payload decryption key

Once the decryption key, “roTSOEnY,” is obtained, the malware employs a custom XOR decryption method to decrypt the payload (see Figure 19). The decryption process involves applying an XOR operation to each byte of the payload using a corresponding byte from the decrypted key. This pairing is managed by a dynamically updating key index. After each XOR operation, the key index is recalculated by adding the value of the current key byte to the index and then taking the modulus with the total length of the key. This ensures that the index cycles through the key in a pseudo-random fashion. If the key index reaches zero after an update, it is reset to the last position in the key. This process continues for each byte in the payload until the entire encrypted blob is decrypted.

Figure 19. DarkGate payload decryption process

After decrypting the payload, the loader invokes the function `mw_Execute_Payload` to run the payload directly from memory (see Figure 20). The execution process involves the following five steps:

1. Memory Allocation: The function starts by allocating memory to accommodate the payload. It uses the `VirtualAlloc` API with the `MEM_COMMIT` flag and a protection setting of `0x40` (PAGE_EXECUTE_READWRITE), allowing the allocated memory to be executable.

2. Header and Section Mapping: The next step involves copying the PE headers and each section of the PE file into the allocated memory. This includes both the code and data sections of the executable.

3. Import Resolution: The function then resolves imports by traversing the import directory. For each required DLL, it uses `LoadLibraryA` to load the library and `GetProcAddress` to resolve each needed function. The addresses of these functions are updated in the Import Address Table (IAT).

4. Base Relocation Handling: The code adjusts memory addresses within the loaded image to handle base relocations.

5. Execution: Finally, the loader transfers control to the entry point (OEP) of the loaded PE file. This is typically achieved with an assembly jump instruction, `__asm { jmp eax }`, where `eax` holds the address of the entry point.

Figure 20. DarkGate loader execution overview

Figure 21. DarkGate loader payload executing process

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 Remote Access Trojan (RAT) developed in Borland Delphi and has been marketed as malware-as-a-service (MaaS) on Russian-language cybercrime forums since at least 2018. This malware offers a wide range of features, including process injection, file downloading and execution, information theft, shell command execution, keylogging, and more. It also incorporates several evasion techniques.

In the current campaign, DarkGate version 6.1.7 is in use. Notable updates in this version include the implementation of XOR encryption for configuration data, the addition of new configuration values, a reordering of configuration parameters to evade the version 5 automation config extractor, and modifications to command-and-control (C&C) command values.

Upon execution, DarkGate activates anti-ntdll.dll hooking by utilizing the Direct System Call (syscall) method. This approach is specifically designed for scenarios where the malware needs to call native APIs from `ntdll.dll`. By using syscalls, DarkGate can directly invoke kernel-mode functions, circumventing the usual user-mode API layers. This technique helps DarkGate avoid detection of its process hollowing methods, which are typically flagged through API call monitoring. The use of syscalls enhances the malware’s stealth capabilities and complicates detection and analysis by security mechanisms, as it conceals the malware's dependence on critical system functions for its malicious activities.

To determine the operating system architecture, DarkGate checks for the presence of the `C:\Windows\SysWOW64\ntdll.dll` file. Depending on whether the system is x64 or x86, DarkGate employs different syscall methods. For x86 architecture, syscalls are executed directly using inline assembly with the `sysenter` instruction. For x64 architecture, DarkGate uses the `FS:[0xC0]` pointer, which refers to `wow64cpu!KiFastSystemCall` to perform the syscall (see Figure 22).

Figure 22. 64-bit system KiFastSystemCall function

Malware frequently invokes API functions that leave static artifacts, such as strings embedded in the payload files. These artifacts can be used by defense analysts to infer the range of functions a binary might execute, usually through an examination of its Import Address Table (IAT).

To counter static analysis, reduce the visibility of suspicious API calls, obfuscate malicious functions, and complicate defensive efforts, DarkGate dynamically resolves API functions at runtime. The following is a list of API functions that DarkGate resolves dynamically during its execution:

• user32.dll

  • MessageBoxTimeoutA

  • GetWindowTextA

  • GetWindowTextW

  • FindWindowExA

  • GetForegroundWindow

  • FindWindowA

  • GetKeyState

  • EnumDisplayDevicesA

  • GetKeyboardState

  • GetWindow

  • GetWindowThreadProcessId

  • SendMessageA

  • GetWindowTextLengthW

• Advapi32.dll

  • RegSetValueExA

  • RegDeleteValueA

  • RegCloseKey

  • RegOpenKeyExA

• Shell32.dll

  • ShellExecuteA

In contrast to DarkGate version 5, which used clear text for its configuration, version 6 employs XOR encryption for added security. The decryption process for this version, illustrated in Figure 23, follows a method similar to that used by the Delphi loader depicted in Figure 21.

The decryption function takes the encrypted configuration buffer, a hard-coded key, and the buffer size as inputs. It then generates a new decryption key based on the provided key and uses it to decrypt the configuration buffer.

Figure 23. DarkGate version 6 configuration decryption process

Table 6 provides an overview of the key configuration settings for DarkGate version 6. It details the parameter keys, their value types, and corresponding 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, DarkGate registers the infected system with its command-and-control (C&C) server using HTTP POST requests. The registration message follows this structure:

<Foreground Window title – UTF-16 – Hex encoded>|<Idle Time>|<GetTickCount>|<Bool: IsUserAnAdmin>|<DarkGate Version>|||

Here's a breakdown of each component:

• Foreground Window Title: The title of the currently active window on the infected machine, encoded in UTF-16 and then converted to hexadecimal.

• Idle Time: The duration, in seconds, since the last user interaction (e.g., keyboard or mouse input) with the system.

• System Uptime: The time elapsed since the system was last started, measured in milliseconds using the `GetTickCount` API function.

• Is User an Administrator: A flag indicating whether the malware has administrative privileges on the system.

• DarkGate Version: Specifies the version of the DarkGate malware installed on the system.

To send this information to the C&C server, DarkGate follows these steps:

1. Initialization of Data Packet: The data for exfiltration is prefixed with a unique traffic identifier to help with tracking. For example, the integer “1000” is used for initial C&C registration traffic and command retrieval.

2. Unique Identification Hash Calculation: A custom MD5 hash is created by combining several pieces of system information:

- Windows Product ID: Retrieved from the registry at `HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId`.

- Processor Information: Extracted from `HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ProcessorNameString` and includes the total number of processors, obtained via the `GetSystemInfo` function.

- Computer Name: The computer's name, encoded in UTF-16 hex format.

The resulting hash is then encoded with a custom alphabet: "abcdefKhABCDEFGH".

3. Key Generation: An XOR operation is applied to the MD5 hash to generate a new encryption key.

4. Data Encryption: The data is encrypted using the newly generated key through an XOR cipher.

5. Prepending Encoded Hash: The pre-encryption encoded MD5 hash is appended to the beginning of the encrypted data. This hash is used by the DarkGate C&C server as a decryption key for retrieving the data.

Figure 24. Packet decryption key and encrypted conent

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

“zLAxuU0kQKf3sWE7ePRO2imyg9GSpVoYC6rhlX48ZHnvjJDBNFtMd1I5acwbqT+=”

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

The decrypted content is as follows:

"10004100750074006F006900740033002E0065007800650[...REDACTED...]|0|317394|No|6.1.7|||"

If the command-and-control (C&C) server fails to return the anticipated command, DarkGate will enter an infinite loop, persistently sending requests until it receives a valid command. This mechanism ensures that the malware continues to operate and wait for instructions, even if initial communication fails.

Figure 26 illustrates a typical command request from an infected system and the subsequent response from the C&C server.

Figure 26. DarkGate version 6 command request

the decyrpted request content is as follows:

1000|87|283|Yes|6.1.7|||"

Conclusion

In this analysis, a continuation of our investigation into the Water Hydra APT Zero Day campaign, we examined how DarkGate operators exploited CVE-2024-21412 as a zero-day vulnerability to deploy the sophisticated and evolving DarkGate malware. This investigation highlighted how security bypass vulnerabilities, when combined with open redirects in technologies like the Google Ads ecosystem, can be leveraged to spread malware by exploiting the inherent trust that organizations place in fundamental web technologies.

To enhance software security and shield customers from zero-day threats, the Trend Zero Day Initiative collaborates with security researchers and vendors to patch and responsibly disclose vulnerabilities before they can be exploited by APT groups. Additionally, the ZDI Threat Hunting team actively searches for zero-day attacks in the wild, contributing to industry-wide protection against emerging threats.

How DeepDefend XDR Can Help You

In the context of sophisticated threats like those uncovered in the DarkGate campaign, having a robust and proactive security solution is crucial. DeepDefend XDR (Extended Detection and Response) offers comprehensive protection against such advanced and evolving threats by integrating multiple security layers into a unified system. Here’s how DeepDefend XDR can be instrumental in identifying, blocking, and mitigating these types of attacks:

1. Advanced Threat Detection: DeepDefend XDR employs advanced behavioral analysis and machine learning algorithms to detect anomalies and suspicious activities that are indicative of sophisticated attacks like DarkGate. It analyzes patterns of behavior across endpoints, networks, and cloud environments to identify potential threats that traditional security measures might miss.

2. Unified Visibility: With DeepDefend XDR, you gain centralized visibility into your entire security landscape. This integration allows for a comprehensive view of all activities, including those involving CVE-2024-21412 exploitation and malicious payloads delivered via open redirects. By aggregating and correlating data from various sources, DeepDefend XDR enhances your ability to identify and respond to complex attack vectors.

3. Real-time Threat Intelligence: DeepDefend XDR continuously updates its threat intelligence feeds to stay ahead of emerging threats. This means it is equipped with up-to-date information on the latest vulnerabilities, such as CVE-2024-21412, and can adapt its detection and response strategies accordingly to block exploitation attempts before they cause harm.

4. Automated Response and Mitigation: In the event of an identified threat, DeepDefend XDR automates response actions to contain and neutralize the threat swiftly. For instance, if it detects an attempted exploitation of a vulnerability or an anomalous behavior indicative of DarkGate malware, it can automatically quarantine affected systems, block malicious traffic, and remediate vulnerabilities.

5. Enhanced Forensics and Investigation: DeepDefend XDR provides detailed forensic analysis and visibility into attack chains, such as the one involving DarkGate. This includes tracking the initial vector of attack, subsequent stages of malware deployment, and the impact on your systems. Such insights are crucial for understanding how the attack unfolded and improving future defenses.

6. Integration with Existing Tools: DeepDefend XDR seamlessly integrates with existing security tools and platforms, enhancing their effectiveness by providing additional layers of analysis and response capabilities. This ensures that your current security infrastructure is bolstered by the advanced features of XDR.

By deploying DeepDefend XDR, you can significantly enhance your organization’s ability to detect, prevent, and respond to sophisticated threats, such as those demonstrated in the DarkGate campaign. To see how DeepDefend XDR can safeguard your environment, click the button below to request a demo.

Request a Demo