Signed, sealed, injected: The mechanics of DCRat in 2026

By Madhini Muralidharan, Shalaka Patil and Kaushal Sarda · August 13, 2026

Introduction

In early 2026, the Trellix Advanced Research Center (ARC) identified and analyzed an active DarkCrystal RAT (DCRat) campaign following a critical customer escalation. The operation relied on a judicial‑themed phishing lure, masquerading as an official “Resolución Denuncia Jurídica” (legal complaint resolution) to pressure victims into opening the attachment. Every stage of the attack required human interaction, from opening the phishing email to extracting the archive to executing the malicious components alongside trusted libraries by using DLL sideloading. In its final stage, the malware employed process hollowing to inject malicious code into a trusted system process, effectively evading detection. The end payload was DCRat, granting attackers full remote access and control. This campaign is particularly notable for legitimate, signed utility to bypass traditional security perimeters.

This blog unpacks each stage of the infection chain, revealing how attackers combine stealth, sideloading, and process injection to establish long‑term access.

Here is a refined, explanatory breakdown of the infection chain identified by Trellix ARC.

Attack kill chain

Attack kill chain view

Initial access:

This attack chain begins with a deceptive phishing email carrying an SVG attachment, a seemingly harmless vector image that hides embedded JavaScript. Once triggered, the script drops a ZIP archive containing an executable and multiple DLLs.

This is a classic example of HTML Smuggling, a technique where an attacker hides a malicious payload inside a seemingly harmless file format, in this case, an SVG file. Because SVGs are essentially XML-based image files that can execute JavaScript, they are perfect "trojan horses" for bypassing email gateways that might block .EXE or .JS files but allow .SVG files.

Execution through deception

The figure is a phishing page, masquerading as the Citizen Consultation Portal for the Colombian Judicial. The document deceives the user into initiating a download. When the user clicks anywhere on this page, they are redirected to a second page pretending the download has completed successfully. This second page provides a password (1601) to open the file, creating a false sense of legitimacy and security. In reality, this tactic is designed to trick victims into opening malware disguised as judicial documents, exploiting trust in government branding and the fear of legal matters.

Once the user clicks the page, they are redirected to a new page that states the file is being downloaded and prompts them to open it using the provided password “1601”. Upon inspecting the source code, we discovered an embedded JavaScript script containing double Base64-encoded content (figure 4: Embedded JS in SVG). The script includes function code to decode the content and uses a Blob function to reconstruct a ZIP file entirely in the browser's memory. It then saves the file as 'DOC-16-ENE-2026 RESOLUCION DENUNCIA JURIDICA.7z' in the user’s downloads folder.

Examining Brotli‑disguised loader and DLL sideloading strategies

The ZIP file contains a decoy loader along with several libraries that pretend to be Brotli components. Brotli is a modern compression algorithm created by Google and commonly used to shrink web content, so using Brotli‑style names helps the malware blend in and look harmless at first glance. These Brotli compression functions hint at hidden or compressed payloads used to obscure configuration data or secondary stages. This setup uses staged, callback‑driven loading, which means modules are loaded dynamically from unusual locations or from hidden content. That approach gives the attacker tight control over how each piece is initialized and run, while also allowing in‑memory execution that leaves fewer traces on disk.

DLL side-loading is a key approach. The decoy loader pretends to be a genuine program but intentionally includes malicious DLLs (such as libbrotlidec.dll and libbrotlienc.dll) alongside itself. When the executable is run, Windows' DLL search order resolves these deceptive Brotli libraries rather than genuine ones, allowing the attacker to execute code disguised as standard compression methods. This method challenges detection because the imports appear legitimate, but the functionality is hijacked.

The decoy loader masquerades as a legitimate executable, but examining the PE structure quickly exposes its intent. The sample DOC‑16‑ENE‑2026 RESOLUCION DENUNCIA JURIDICA.exe imports common libraries like kernel32.dll and msvcrt.dll, along with unusual modules such as libbrotlidec.dll (for decryption) and libbrotlienc.dll (for encryption). By analyzing its import directory, we can see how the executable leverages system APIs and compression routines to prepare for malicious activity, complicating detection and reverse engineering.

Persistence through registry entry

After execution, a folder is created in the user directory, inside it is dropping selfcopy with its dependency DLLs and a batch script. It also creates a run entry in the Windows Registry for persistence.

Runtime initialization

The following figure shows the entry point of DOC‑16‑ENE‑2026 RESOLUCION DENUNCIA JURIDICA.exe, a 64‑bit binary compiled with the VC++ compiler. Program execution begins with two benign TLS callback functions, which are part of the program’s standard initialization sequence. Once they finish, control passes to the actual entry point, where staged initialization occurs, and malicious import modules are dynamically loaded.

The figure shows the entry to the malicious import function. The name mimics a legitimate Brotli API to disguise harmful activity. Execution then passes to the real entry point, which calls this import and leverages DLL sideloading to load extra modules from unusual locations. This technique enables malicious code to run within a trusted process, leaving minimal traces on disk, and blending in as legitimate dependencies.

Stealth execution: From memory decryption to process hollowing

This figure below is a decryption routine where it takes input bytes from the .rdata section and uses a key to perform decryption operations (XOR and SHR) across 0xBE00 bytes, storing the output in a newly allocated address space. Once complete, the buffer reveals the MZ and PE headers of a Windows executable, meaning the payload has been fully reconstructed in memory.

The figure shows the data before decryption as random, unreadable bytes, and the data after decryption as clear executable content with recognizable headers like MZ and PE.

After the payload is decrypted in memory, the injection phase begins. The payload starts a legitimate process, “AddInProcess32.exe,” in a suspended state using CreateProcessInternalW. It then manipulates the thread’s registers with Wow64GetThreadContext and Wow64SetThreadContext, and injects its malicious code into the target process’s memory using WriteProcessMemory. Finally, ResumeThread restarts the process, which now runs the attacker’s code while appearing to be a normal Windows executable. This allows the malware to blend in with trusted system processes and execute stealthily. Here, AddInProcess32.exe is being injected. The following figure illustrates the process hollowing injection flow.

After injection, the malicious payload runs inside AddInProcess32.exe because the malware replaces the original code of that trusted process with its own. From the outside, it still looks like a normal Windows process, but inside it’s executing the attacker’s code. This way, the malware hides in plain sight and avoids detection.

Final payload examination

Injection has already occurred, and the malicious payload is now stealthily running within a trusted system process. From this point forward, we can examine what the decrypted end payload actually is. It is a compact .NET executable functioning as a client stub. It decrypts hidden configuration information, applies anti‑analysis and persistence techniques, and persistently attempts to establish an encrypted communication channel with its command‑and‑control (C2) server.

The main function begins with a delay to evade sandbox detection, then loads its settings and runs anti‑analysis checks to block debugging or security tools. It ensures only one instance runs via a mutex, may mark itself as critical to destabilize the system if killed, and installs itself for persistence. It bypasses AMSI to avoid Windows malware scanning, prevents the host from sleeping, and clears traces if running with administrator rights. Finally, it enters an endless loop, constantly attempting to reconnect and reinitialize its client socket.

The figure below shows static configuration information stored in encoded form. Each variable contains strings that appear to be Base64 or other obfuscated data, representing things like ports, host addresses, version information, installation flags, mutex values, encryption keys, and certificates.

The figure below illustrates the InitializeSettings() method, a critical routine that prepares the malware’s configuration before execution. It begins by decoding a Base64‑encoded key, which is then used to set up AES‑256 decryption. Through this process, multiple hidden settings are unlocked, including host and port details, version information, installation flags, mutex values, and anti‑analysis options. The method also generates a hardware ID (HWID) unique to the machine, decrypts the server’s signature, and reconstructs a certificate from a Base64 string. To ensure reliability, all of these values are verified with a hash check. If any step fails, the routine returns false; otherwise, it returns to confirm success and allow the client to proceed. In essence, this function ensures that sensitive configuration data remains concealed until runtime, where it is securely decrypted, validated, and ready to drive operations. When examining the mutex name “DcRatMutex_qwqdanchun,” it becomes clear that the payload belongs to the DCRAT.

The figure below shows the decrypted settings results.

Command and control (C2) communication routine and persistence

After configuring buffer sizes and creating a TCP socket, it chooses the server’s host and port either by retrieving them from a Pastebin link or by selecting at random from a list of predefined values. It attempts to connect if the selected host is a domain name; if not, it resolves it to IP addresses. After the client authenticates via TLS, internal buffers are ready for data transmission, and the socket is wrapped in an SSL stream to secure communication. After that, the code establishes timers for ping and keep-alive packets to continue the connection, sends an identifier to the server, and begins reading data. The figure below shows the complete process for setting up a network client.

Currently, the C2 server is down, and the payload is repeatedly attempting to connect to the attacker's machine at regular intervals. This indicates the malware remains present but inactive until its operator restores the C2. When the server is unavailable, the RAT cannot receive instructions or exfiltrate data, so it becomes idle, continuing to retry or sleep until the connection is re‑established.

Conclusion:

This DCRat campaign demonstrates how attackers blend phishing lures, DLL sideloading, and process hollowing to bypass defenses and gain remote access. By abusing trusted utilities and requiring user interaction, the operation underscores both the persistence of social engineering and the sophistication of modern malware delivery. Such attacks, which disguise malicious components as legitimate libraries, highlight the importance of stronger defensive practices. Security teams should harden their environment by strengthening application security, monitoring for anomalies in module loading, and improving visibility into in‑memory execution. General measures such as validating component integrity, correlating suspicious activity with network behavior, conducting regular threat hunting, and maintaining patch hygiene help reduce the effectiveness of malware that masquerades as legitimate software within trusted processes.

Trellix protection against DCRAT campaign: Recommended mitigation

Trellix security solutions provide layered defense against campaigns like this. Trellix Email Security blocks phishing lures and malicious attachments, stopping the attack at the initial delivery stage. Trellix Endpoint Security and EDR detect disguised files from executing and stopping in‑memory payloads. Trellix Network Security monitors and disrupts suspicious C2 traffic. Combined with ongoing user awareness, these defenses work together to reduce the risk of stealthy, multi‑stage attacks such as DCRat.

MITRE Techniques:

Reference IOCs:

Coverage Details

Discover the latest cybersecurity research from the Trellix Advanced Research Center.