Listen to this Post
Introduction: A Phishing Email Designed to Terrify Its Victim
Cybercriminals do not always need sophisticated social engineering to get someone to open a malicious file. Sometimes, all they need is the right combination of fear, urgency, authority, and curiosity.
That is exactly what makes the latest DCRat campaign so concerning. Attackers disguised their malware delivery as a Colombian legal notice with the alarming title “Resolución Denuncia Jurídica”—a fake judicial complaint designed to make recipients believe they were facing an immediate legal problem.
The message does not initially look like a conventional executable-based malware campaign. Instead, victims receive an SVG file, a format commonly associated with harmless vector graphics. Hidden inside that SVG, however, is JavaScript capable of reconstructing a password-protected 7-Zip archive directly in the browser.
From there, the attack becomes considerably more sophisticated.
The archive delivers a decoy executable alongside malicious DLL files. Through DLL sideloading, the attackers cause the legitimate-looking executable to load their malicious libraries. The malware then establishes persistence, decrypts an embedded payload, and ultimately performs process hollowing against AddInProcess32.exe.
The result is a remote-access trojan hiding inside a process that appears legitimate.
This campaign is a powerful reminder that modern endpoint attacks are increasingly built around abusing trusted Windows behavior rather than simply dropping obviously malicious executables onto disk.
The Campaign Begins With Fear
The attack begins with a phishing email carrying a judicial-themed lure named:
ENVIO DE RESOLUCION DENUNCIA JUDICIAL RA-093-7397.eml
The wording is deliberately intimidating. A recipient may interpret the message as an official legal complaint, court notification, or administrative proceeding.
That emotional reaction matters.
Attackers understand that people make different decisions when they believe something is urgent. A suspicious attachment that might normally be ignored can suddenly appear important when the victim thinks it could involve a lawsuit, government agency, unpaid obligation, or legal accusation.
The campaign therefore attacks the
The SVG File Is More Dangerous Than It Looks
The attachment uses SVG, a legitimate image format based on XML.
That makes it particularly interesting from an
In this campaign, JavaScript is embedded inside the SVG and is used to redirect the victim toward a fake Colombian judicial portal.
The file ultimately creates an archive called:
DOC-16-ENE-2026 RESOLUCION DENUNCIA JURIDICA.7z
The use of a legal-looking filename reinforces the social-engineering theme and makes the next step appear to be part of the supposed legal documentation.
HTML Smuggling Without the Typical HTML File
One of the most important technical elements of this campaign is the use of HTML smuggling.
Instead of simply attaching an executable or conventional archive to the phishing email, the attackers hide the malicious content inside JavaScript.
The JavaScript is reportedly encoded twice using Base64. When the browser executes the script, it reconstructs the archive dynamically with a Blob object.
In simplified terms, the process resembles this:
const decoded = atob(encodedData);
const blob = new Blob([decoded], {
type: "application/octet-stream"
});
The actual malware is considerably more complex than this simplified example, but the underlying concept is important.
The malicious file does not necessarily exist as a conventional attachment in its final form. Instead, the browser can reconstruct it at runtime.
Why HTML Smuggling Matters
HTML smuggling is attractive to attackers because it attempts to move malicious content through security boundaries using legitimate browser behavior.
Security products may inspect an attachment differently depending on its file type and structure. A suspicious .exe can immediately attract attention, while an SVG may initially appear much less threatening.
This does not mean SVG files are inherently dangerous.
The problem is that a legitimate format can be transformed into a delivery mechanism.
That distinction is crucial for defenders.
The Archive Contains a Trap
Once the victim reaches the archive stage, the attack switches from browser-based delivery to Windows execution techniques.
The archive contains a decoy executable and supporting DLL files.
Some of the DLL filenames are associated with Brotli, a legitimate compression technology commonly encountered in modern software.
Among the filenames are:
libbrotlidec.dll
libbrotlienc.dll
To an ordinary user, these names may look completely legitimate.
That is exactly the point.
DLL Sideloading Turns Windows Search Behavior Against the User
Windows applications frequently rely on DLL libraries.
When an executable starts, Windows may search specific locations for the libraries it needs. Attackers can abuse that search behavior by placing a malicious DLL beside a legitimate executable.
The application believes it is loading the required library.
Instead, it loads an attacker-controlled replacement.
This technique is known as DLL sideloading.
The technique is particularly effective because the malicious code can execute in the context of a legitimate application rather than requiring the attacker to launch an obviously suspicious program.
Why the Brotli Names Are Important
The use of Brotli-related filenames is more than simple camouflage.
Security analysts frequently investigate suspicious filenames, paths, process relationships, and loaded modules. A DLL named something like libbrotlidec.dll can initially appear ordinary.
This demonstrates an important principle in malware analysis:
A legitimate filename is not evidence of legitimate code.
Defenders should validate the
The Loader Establishes Persistence
After execution, the loader creates a directory within the user’s profile and copies itself and its dependencies into that location.
It also creates a batch script.
The malware then establishes persistence using a Windows Registry Run key.
That means the malicious program can automatically start when the victim logs into Windows again.
Conceptually, defenders can inspect common Run-key locations with:
reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run
and:
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run
A suspicious entry should not automatically be considered malicious, but unexpected executables launched from unusual user-profile directories deserve investigation.
The Payload Is Hidden Inside the Loader
The attack does not stop after persistence.
The loader contains an encrypted or otherwise protected payload inside its .rdata section.
During execution, the malware decrypts that data.
The resulting content contains the familiar Windows executable signatures:
MZ
PE
Those headers indicate that the malware has reconstructed a Windows executable in memory.
This approach reduces the need to leave the final payload sitting on disk in an easily discoverable form.
Deep Analysis: From Decryption to Process Hollowing
The most technically interesting stage begins when the loader starts AddInProcess32.exe.
The process is initially created in a suspended state.
The attacker then uses Windows process-manipulation APIs to replace the legitimate process’s memory with malicious content.
Relevant APIs observed in this technique include:
CreateProcessInternalW
WriteProcessMemory
Wow64GetThreadContext
Wow64SetThreadContext
ResumeThread
A defender researching this behavior can begin investigating suspicious process creation and memory manipulation with tools such as:
Get-Process | Select-Object Name,Id,Path
For suspicious processes, additional information can be collected through:
Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId,Name,ExecutablePath,CommandLine
Security teams should also monitor for unusual combinations of:
CreateProcess
WriteProcessMemory
SetThreadContext
ResumeThread
especially when they occur across unrelated process boundaries.
Process Hollowing Makes the Attack Harder to See
This technique is known as process hollowing.
The basic idea is deceptively simple.
The attacker creates a legitimate process.
The process is suspended before it begins normal execution.
The malware modifies its memory.
The malicious code is placed where legitimate program instructions would normally exist.
The attacker resumes the process.
To an analyst looking only at process names, everything can appear normal.
The process is still called:
AddInProcess32.exe
But its memory no longer represents the original program.
The Difference Between Process Identity and Process Reality
This is one of the most important lessons from the campaign.
A process name is not the same thing as process behavior.
A trusted-looking executable can become a container for malicious instructions after its memory has been modified.
That is why modern endpoint detection cannot rely exclusively on executable names, file reputation, or process lists.
Security tools need to correlate:
Process creation
Parent-child relationships
Loaded DLLs
Digital signatures
Memory permissions
Cross-process memory writes
Thread-context manipulation
Registry persistence
Network connections
User-profile execution paths
The attack becomes much easier to understand when these events are viewed as a chain rather than isolated alerts.
DCRat Becomes the Final Payload
After the process-hollowing stage, the final payload is identified as DCRat, a remote-access trojan designed to provide attackers with control and information-gathering capabilities.
DCRat is not simply trying to execute one malicious command.
A remote-access trojan can provide attackers with a platform from which they can perform additional actions after gaining a foothold.
That makes the successful delivery of the malware potentially more serious than the initial phishing email suggests.
Anti-Analysis Techniques Add Another Layer
The DCRat payload performs several checks designed to make analysis more difficult.
The malware can delay execution, perform anti-analysis checks, and create a mutex named:
DcRatMutex_qwqdanchun
A mutex can help malware determine whether another copy of itself is already running.
For defenders, the mutex becomes a potentially useful behavioral indicator.
However, security teams should never rely on a single string as their only detection mechanism because attackers can change such identifiers between campaigns or builds.
AMSI Bypass Raises the Risk
The malware also attempts to bypass AMSI,
AMSI provides a mechanism through which security products can inspect potentially malicious content and scripts.
Attempting to interfere with AMSI demonstrates that the malware is designed not merely to establish execution, but to operate in an environment where defensive inspection is expected.
This is an important escalation in sophistication.
The attacker is not simply asking, “Can I run?”
The attacker is effectively asking, “Can I run while security software is watching?”
Runtime Configuration Decryption
DCRat also collects a hardware identifier and decrypts its configuration during execution using AES-256.
Runtime decryption makes static analysis more difficult because important configuration information may not be immediately visible in the binary.
Analysts therefore need to examine both:
Static file contents
+
Runtime memory
+
API behavior
+
Network activity
A malware sample that appears relatively quiet during static inspection may reveal significantly more information once executed inside a controlled analysis environment.
The Attack Chain in One Picture
The campaign can be understood as a sequence of carefully connected stages:
Phishing Email
↓
Judicial-Themed Social Engineering
↓
Malicious SVG Attachment
↓
Embedded JavaScript
↓
Double Base64 Decoding
↓
Browser Blob Reconstruction
↓
HTML Smuggling
↓
Password-Protected 7z Archive
↓
Decoy Executable + Malicious DLLs
↓
DLL Sideloading
↓
User-Profile Installation
↓
Registry Run-Key Persistence
↓
Encrypted Payload Decryption
↓
AddInProcess32.exe
↓
Process Hollowing
↓
DCRat
↓
Anti-Analysis + AMSI Bypass ↓
Configuration Decryption
↓
Remote Access and Data Collection
The strength of this campaign is not necessarily any single technique.
It is the combination.
Detection Should Focus on Behavior
Organizations should avoid building their entire defense around the filename of this particular campaign.
Attackers can rename:
AddInProcess32.exe
They can rename:
libbrotlidec.dll
They can change:
DcRatMutex_qwqdanchun
They can create a different archive.
They can modify the phishing subject.
But reproducing the entire behavioral chain without generating suspicious telemetry is much harder.
Useful Windows Investigation Commands
For an initial endpoint investigation, defenders can inspect suspicious processes with:
Get-CimInstance Win32_Process | Select-Object ProcessId,ParentProcessId,Name,ExecutablePath,CommandLine |
Sort-Object ParentProcessId
To inspect recently modified files in a
Get-ChildItem "$env:USERPROFILE" -Recurse -File -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 100 FullName,Length,LastWriteTime
To inspect common persistence locations:
reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run
For PowerShell environments, defenders can also look for suspicious processes with unusual command lines:
Get-CimInstance Win32_Process |
Where-Object {$_.CommandLine} |
Select-Object Name,ProcessId,ParentProcessId,CommandLine
These commands are intended for defensive investigation and incident response, not for executing or deploying malware.
What EDR Should Look For
An effective EDR strategy should correlate process hollowing indicators instead of waiting for a known DCRat hash.
High-value telemetry includes:
Process created suspended
↓
Memory allocation in another process
↓
WriteProcessMemory
↓
Thread context modification
↓
ResumeThread
The appearance of several of these events in a short time window should receive substantially more attention than any single event by itself.
Look Closely at DLL Loading
DLL sideloading also produces valuable telemetry.
Security teams should investigate situations where:
A signed executable loads an unsigned DLL.
A DLL is loaded from a user-writable directory.
A legitimate application loads an unexpected library.
DLL filenames resemble legitimate third-party libraries.
The executable and DLL have unusual timestamps or signatures.
The loaded DLL’s hash does not match the vendor’s known version.
A signed executable does not automatically make every module it loads trustworthy.
The Registry Run Key Is Another Clue
The persistence mechanism provides another opportunity for detection.
Organizations should monitor new or modified Registry Run entries, especially when the target executable is located inside:
%AppData%
%LocalAppData%
%Temp%
%ProgramData%
A Run key pointing to an executable in an unusual user-controlled directory is significantly more suspicious than a known application installed under a standard vendor directory.
Email Security Must Inspect More Than File Extensions
The campaign also exposes a weakness in simplistic email security strategies.
Blocking .exe attachments is not enough.
Attackers can use:
SVG
ZIP 7Z LNK ISO
Office documents
PDF files
or combinations of these formats to reach the same objective.
Modern email security should analyze:
Embedded scripts
Obfuscated JavaScript
Archive construction
Archive passwords
Redirect chains
Browser-generated files
External domains
Suspicious document naming
Social-engineering context
A file’s extension is only one piece of the evidence.
User Training Still Matters
Technology cannot completely solve the social-engineering problem.
The legal lure used in this campaign demonstrates why.
Employees should understand that attackers frequently impersonate:
Courts
Government agencies
Tax authorities
Police departments
Lawyers
Banks
Shipping companies
Employers
Security teams
A message claiming that immediate legal action is pending should not be opened impulsively.
Instead, the recipient should independently verify the claim through a known official channel.
Indicators of Compromise
The supplied intelligence identifies the following campaign indicators.
Email hash:
F205AB7E6AEFC10B9833D1A9A91BAD02
This hash is associated with the phishing email carrying the judicial-themed lure.
Email filename:
ENVIO DE RESOLUCION DENUNCIA JUDICIAL RA-093-7397.eml
Archive filename:
DOC-16-ENE-2026 RESOLUCION DENUNCIA JURIDICA.7z
Mutex:
DcRatMutex_qwqdanchun
Referenced DLL names:
libbrotlidec.dll
libbrotlienc.dll
Security teams should treat these indicators as useful hunting clues rather than permanent signatures. Malware operators routinely alter filenames, hashes, infrastructure, mutexes, and payloads.
What Undercode Say:
- The Real Weapon Is the Attack Chain
This campaign is a good example of why modern malware cannot be understood by looking at one technique in isolation.
2. Social Engineering Comes First
The technical attack becomes possible because the victim first believes the legal story.
3. Fear Can Defeat Technical Defenses
A frightened user may interact with a file they would otherwise reject.
4. SVG Is Not Automatically Safe
A graphic format can contain executable scripting logic.
5. HTML Smuggling Remains Relevant
Reconstructing payloads dynamically gives attackers another method of moving malicious content through security controls.
6. Legitimate Software Names Are Being Weaponized
Brotli-related DLL names demonstrate how attackers exploit familiarity.
7. DLL Sideloading Is Still Powerful
The technique survives because Windows applications continue to depend heavily on dynamically loaded libraries.
8. Trusted Processes Are Valuable Targets
A malicious payload looks less suspicious when it lives inside a process associated with legitimate software.
9. Process Names Are Not Enough
An endpoint showing AddInProcess32.exe does not prove that the process is behaving legitimately.
10. Memory Analysis Matters
Process hollowing makes memory telemetry increasingly important.
11. File-Based Detection Has Limits
The final malicious payload does not need to exist on disk in its most obvious form.
12. Runtime Behavior Reveals More
Decryption, process injection, persistence, and network activity can expose what static inspection misses.
- Persistence Creates a Second Chance for Detection
The Registry Run key provides defenders with another point of visibility.
14. Anti-Analysis Is a Sign of Intent
The malware is designed with defensive resistance in mind.
15. AMSI Bypass Should Raise Priority
Attempts to disable or circumvent security inspection deserve immediate attention.
16. Configuration Encryption Complicates Hunting
Security analysts may need memory-based analysis to recover meaningful configuration data.
17. DCRat Is More Than a Dropper
Once deployed, the RAT can become a platform for further attacker activity.
18. Initial Access Is Only the Beginning
The phishing email should be treated as the first phase of a potential intrusion.
19. Endpoint Telemetry Must Be Correlated
A suspicious DLL alone may not trigger an alert.
- Several Weak Signals Can Become One Strong Signal
DLL sideloading plus Run-key persistence plus process hollowing is far more significant.
21. User-Writable Directories Deserve Attention
Malware frequently chooses locations where attackers can write files without elevated privileges.
22. Signed Does Not Mean Safe
A legitimate executable can load malicious components.
23. Hashes Have a Short Shelf Life
IOC-based detection is useful but easily bypassed through recompilation or repackaging.
24. Behavioral Detection Is More Durable
The underlying execution techniques are harder for attackers to change.
- Email Security and EDR Must Work Together
Stopping the attachment is preferable, but endpoint detection must assume something eventually gets through.
26. Browser Activity Can Become Security Telemetry
The browser is increasingly involved in malware delivery through scripts and dynamic file creation.
27. Archive Files Need More Inspection
Password-protected archives should not automatically be treated as harmless.
28. Legal-Themed Lures Deserve Special Attention
Messages involving courts, fines, lawsuits, or government notices can create unusually strong psychological pressure.
29. Analysts Should Reconstruct the Timeline
The sequence from email to process hollowing is more informative than any individual alert.
30. Incident Response Should Look for Persistence
Removing the visible malware file is not enough if the Run key remains.
31. Memory Inspection Can Expose Hollowed Processes
A mismatch between executable identity and memory contents can reveal sophisticated injection.
32. Threat Hunting Should Search for Relationships
Parent-child processes, DLL loading, registry changes, and memory writes should be analyzed together.
- Security Teams Should Assume Variants Will Appear
The same operators can easily change filenames, hashes, lures, and payload configurations.
34. Detection Engineering Should Target Techniques
MITRE ATT&CK-style behavioral mappings are more resilient than relying exclusively on campaign-specific IOCs.
35. Phishing Simulations Should Include Emotional Lures
Employees need to practice resisting urgency, not merely recognizing bad spelling.
36. Security Awareness Must Match Modern Attacks
Attackers increasingly make malicious documents look professional and believable.
- The Most Dangerous File May Look Completely Ordinary
The campaign demonstrates how little visual information tells us about a file’s actual behavior.
38. Trust Must Be Verified at Runtime
Applications, libraries, processes, and scripts should be validated by behavior and provenance.
39. Defense-in-Depth Is Essential
Email filtering, endpoint protection, application control, logging, identity security, and user awareness all contribute to stopping the attack.
40. The Biggest Lesson Is Simple
The attack does not win because DCRat is invisible.
It wins by making every stage before DCRat look ordinary enough to be trusted.
✅ DCRat Is Used as the Final Malware Payload
The supplied technical description identifies the final payload as DCRat, a remote-access trojan.
The reported execution chain includes anti-analysis behavior, persistence mechanisms, configuration decryption, and attempts to bypass AMSI.
✅ DLL Sideloading Is a Real Windows Attack Technique
The campaign description accurately reflects how attackers can place malicious DLLs beside an executable to influence library loading.
Using legitimate-looking library names such as Brotli-related DLLs is consistent with a broader malware tactic of masquerading as trusted software components.
✅ Process Hollowing Can Hide Malicious Code Behind a Legitimate Process
Process hollowing involves creating or using a legitimate process and replacing or manipulating its memory before execution continues.
The APIs listed in the supplied material are associated with low-level Windows process and thread manipulation and are relevant indicators for detecting this type of activity.
✅ HTML Smuggling Can Reconstruct Malicious Files at Runtime
HTML smuggling is a recognized technique in which browser-side content dynamically reconstructs a file instead of delivering the final payload as a conventional attachment.
The use of JavaScript, encoded data, and a Blob object fits the general mechanism described by the technique.
⚠️ IOCs Should Not Be Treated as Permanent Proof
The hashes, filenames, DLL names, and mutex provided here are valuable hunting indicators.
However, they should not be considered sufficient evidence by themselves because attackers can modify these values without changing the underlying technique.
❌ A Legitimate Process Name Does Not Prove the Process Is Safe
Seeing AddInProcess32.exe in Task Manager is not proof that the original executable is executing normally.
If its memory has been replaced through process hollowing, the visible process identity can differ dramatically from the code actually executing.
Prediction
(+1) Behavioral Detection Will Become More Important Than Malware Names
As attackers increasingly combine legitimate filenames, signed executables, dynamic payload reconstruction, memory injection, and encrypted configurations, security products will increasingly move away from simple signature matching.
Future EDR platforms are likely to place greater emphasis on process lineage, memory behavior, DLL provenance, API sequences, and cross-process manipulation.
The most resilient detections will not ask only, “Is this file known to be malicious?”
They will ask a more important question:
“Does this sequence of behavior make sense for the application that is performing it?”
(+1) Email Security Will Move Toward Content and Behavior Analysis
The use of SVG and browser-based reconstruction demonstrates why traditional attachment filtering is becoming less effective.
Email security systems will increasingly need to inspect embedded scripts, dynamically generated files, archive behavior, redirects, and the context surrounding the message.
(+1) Attackers Will Continue Abusing Trusted Software
DLL sideloading and process hollowing are unlikely to disappear.
As security teams become better at identifying obvious malware, attackers have stronger incentives to hide behind legitimate applications and normal operating-system mechanisms.
(-1) Simple IOC Blocking Will Become Less Reliable
Blocking the known hash or filename may stop one version of this campaign, but it will not necessarily stop the next version.
Threat actors can rebuild the malware, rename the files, change the mutex, replace the lure, or modify the delivery infrastructure.
(+1) Memory-Based Detection Will Become a Bigger Part of Endpoint Security
As malware increasingly avoids writing its final payload directly to disk, security teams will need greater visibility into memory.
Process hollowing, injection, suspicious memory permissions, thread manipulation, and abnormal executable regions will become increasingly important signals.
Final Thoughts: The Attack Is a Lesson in Modern Malware Design
The most frightening part of this campaign is not that DCRat can hide inside a Windows process.
It is how many small decisions work together to make that hiding possible.
The attacker starts with a believable legal threat.
Then comes an innocent-looking SVG.
Inside it is JavaScript.
The JavaScript reconstructs an archive.
The archive contains a decoy.
The decoy loads malicious DLLs.
The loader establishes persistence.
The payload is decrypted in memory.
A legitimate Windows process is hollowed out.
Finally, DCRat begins operating behind the identity of something that appears trustworthy.
Every individual step has a purpose.
Together, they form a carefully engineered intrusion chain.
For defenders, the lesson is equally clear: trust cannot be based on appearance alone.
A harmless-looking attachment may contain executable logic. A familiar DLL name may point to malicious code. A signed process may contain attacker-controlled memory. A normal-looking Registry entry may provide persistence.
The strongest defense is therefore not a single antivirus signature or IOC list.
It is the ability to connect the dots.
When an unusual SVG attachment is followed by browser-generated archive creation, suspicious DLL loading, persistence in a user profile, and cross-process memory manipulation, the individual events stop looking harmless.
They become a story.
And in modern cybersecurity, recognizing that story quickly can be the difference between stopping an infection at the endpoint and discovering a fully operational remote-access trojan after the attacker has already established a foothold.
▶️ Related Video (74% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.medium.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
