Forensic Victory: Catching the Ransomware EDR Couldn't See
This blog details a simulation of a ransomware attack that bypassed EDR, simulated via a ClickFix social engineering technique. The attack used an obfuscated HTML and custom C++ binary to encrypt files and establish a reverse shell. Cado's forensic platform then demonstrated how to trace the attack chain, highlighting the need for robust DFIR beyond EDR.
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Nate Bill
Threat Researcher
Share
13
Feb 2025
Introduction: Catching the ransomware EDR couldn't see
Endpoint Detection & Response (EDR) is frequently used by organizations as the first line of defense against cyberattacks. EDR platforms monitor organizations’ endpoints (servers, employee laptops, etc.) and detect and contain malicious activity running where possible. This blog will explore a ransomware attack in a lab environment, using payloads inspired from real attacks.
The incident
For this experiment, Cado Security Labs (now part of Darktrace) set up an up-to-date Windows machine, with a mainstream EDR tool installed, and simulated a ClickFix attack [1] against the user, which relies on socially engineering the user into running malicious commands.
During the first stage of the attack, the fake end user receives a phishing email with a ClickFix attachment:
Figure 1: Test Email
As this is a test, the email was kept fairly short. However, an attacker in a real-world setting would make the email far more convincing to view. In the real world, this type of attack is often seen being used with fake invoices being sent to finance staff.
After opening up the HTML, the end user is presented with the following page:
Figure 2: The ClickFix HTML the user is presented with as part of our simulated attack
This is taken from a real attack where a Microsoft Word online page is mimicked, prompting the user to interact with it. The user needs to interact with the button, as most browsers will block clipboard writes unless the user has interacted with an element. Clicking the button copies a command to the user’s clipboard, and updates the instructions to tell them to press Win + R, Ctrl + V, and then Enter. If the user does this, it will open the run dialog, paste in the command, and execute it. This approach capitalizes on the typical user's lack of comprehension or uncritical adherence to directives, a tactic that has demonstrated efficacy in real-world cyberattacks.
It is worth noting that the EDR tool flagged this stage during initial testing. However, adding a layer of obfuscation to the HTML allowed for bypass detection. The page was able to be encoded, decoded and then written to the document using reflection to access methods that would normally be flagged.
Once the command is executed, PowerShell is invoked to download and run an .exe file from an attacker-controlled server.
The payload is a custom C++ binary that was developed for the purpose of this test. The binary spawns a reverse shell, as well as encrypting all of the files in the Documents folder for ransom. This binary was iteratively tested against the EDR tool, and the functionality was tweaked each time to bypass elements that were getting detected. Bypassing the EDR tool did not require any fancy techniques. Simply using a different Windows API to accomplish a goal that was previously flagged by the EDR tool, or altering the behavior, timing, and ordering of activities performed was sufficient to evade detection. This may seem surprising that sophisticated techniques aren’t strictly required to be undetected.
The aftermath of the attack can be seen in the images below, with a ransom note being written, and our important documents no longer being readable.
Figure 3: The Ransom Note
Figure 4: The aftermath of trying to open one of the PDFs
With no alerts to investigate from the EDR tool - how could a blue team uncover this attack chain after the fact for incident response?
Investigating the artifacts with cado
Using Cado (acquired by Darktrace), we can import the affected VM directly with just a few clicks.
Figure 5: Import the affect VM
The ransom note is a good starting point for the investigation. The timeline search feature quickly finds entries that show what process made the readme.txt file.
Figure 6: Timeline search feature
It shows that the ransom note was created by the process fix.exe, which can be used to pivot off and build a better understanding of what else the malware did, and how it got onto the system.
Reviewing events relating to the fix.exe payload shows that an event established a connection to a server, in this case, an attacker-controlled C2 server. It also spawned a command prompt instance, which provides a remote shell to the attacker.
Figure 7: Event Information
Figure 8: Event Information showing ransomware
Looking at the event information, it’s easy to spot the ransom attacks against the files. For example, the ransom attack modified the internal_draft_important.pdf document, which was seen before it can no longer be opened.
Figure 9: Event information showing the modified document
And finally reaching the start of the log trail relating to the payload, it shows it initially being executed by PowerShell.
Figure 10: Event information showing PowerShell
However, this does not definitively show what caused the malware to run in the first place, and so the next step is running the pivot feature to find related events.
Pivoting off the event allows for quickly figuring out this was precipitated by a visit to obfuscated.html, which was downloaded from an email in Outlook online:
Figure 11: Related events showing that the attack was precipiated by a visit to a obfuscated.html
The Cado Platform [2] also allows for directly jumping to the file in the file browser to conduct further analysis:
Figure 12: File seen in file browser
An EDR platform usually only provides an alert, process snapshot, and event details for a singular moment in time, missing the vital context needed to successfully understand the attack. Cado provides the vital context needed to successfully understand the full scope of the attack, not just its entry point.
Key takeaways
This research covered how Cado can provide the ability to forensically analyze systems and fully understand how attacks have occurred and unfolded. Defense-in-depth is a core component of cybersecurity, and being entirely reliant on an EDR platform as your only line of defense and insight into attacks can leave you without full context.
This was an example only, and a finely tuned EDR platform would likely detect an attack similar to this. However, many organizations may overlook the forensics side of Digital Forensics and Incident Response [3], and remediate incidents solely using their EDR platform. This can result in organizations missing out on the complete picture of an attack, potentially leaving them open to re-infection. A DFIR platform is vital to respond quickly to incidents across Cloud, SaaS, and on-prem.
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Bringing Together SOC and IR teams with Automated Threat Investigations for the Hybrid World
Incident response often breaks down after detection due to fragmented tools and limited visibility. Darktrace unifies detection and investigation across cloud and on-premises environments, enabling automated evidence capture and faster, clearer response.
React2Shell Reflections: Cloud Insights, Finance Sector Impacts, and How Threat Actors Moved So Quickly
This blog breaks down how attackers rapidly weaponized the React2Shell vulnerability, with a particular focus on cloud‑native financial environments. Drawing on Darktrace’s honeypot research, it explores emerging threat actor tooling, exploitation timelines, and why behavioral‑anomaly‑led security is critical in today’s cloud landscape.
Chinese APT Campaign Targets Entities with Updated FDMTP Backdoor
Darktrace have identified activity consistent with Chinese-nexus operations, a Twill Typhoon-linked campaign targeting customer environments, primarily within the Asia-Pacific & Japan (APJ) region
Beginning in late September 2025, multiple affected hosts were observed making requests to domains impersonating content delivery networks (CDNs), including infrastructure masquerading as Yahoo- and Apple-affiliated services. Across these cases, Darktrace identified a consistent behavioral execution pattern: the retrieval of legitimate binaries alongside malicious Dynamic Link Libraries (DLLs), enabling sideloading and execution of a modular .NET-based Remote Access Trojan (RAT) framework.
The activity aligns with patterns described in Darktrace’s previous Chinese-nexus operations report, Crimson Echo. In this case, observed modular intrusion chains built on legitimate software, and staged payload delivery. Threat actors retrieve legitimate binaries alongside configuration files and malicious DLLs to enable sideloading of a .NET-based RAT.
Observed Campaign
Across cases, the same ordered sequence appears: retrieval of a legitimate executable, (2) retrieval of a matching .config file, (3) retrieval of the malicious
DLL, (4) repeated DLL downloads over time, and (5) command-and-control (C2) communication. The .config file retrieves a malicious binary, while the legitimate binary provides a legitimate process to run it in.
Darktrace assesses with moderate confidence that this activity aligns with publicly reported Twill Typhoon tradecraft. The observed use of FDMTP, DLL sideloading, and overlapping infrastructure is consistent with previously observed operations, though not unique to a single actor. While initial access was not directly observed, previous Twill Typhoon campaigns have typically involved spear-phishing.
What Darktrace Observed
Since late September 2025, Darktrace has observed multiple customer environments making HTTP GET requests to infrastructure presenting as “CDN” endpoints for well-known platforms (including Yahoo and Apple lookalikes). Across cases, the affected hosts retrieved legitimate executables, then matching .config files (same base filename), then DLLs intended for sideloading. The sequencing of a legitimate binary + configuration + DLL has been previously observed in campaigns linked to China-nexus threat actors.
In several cases, affected hosts also issued outbound requests to a /GetCluster endpoint, including the protocol=Dotnet-Tcpdmtp parameter. This activity was repeatedly followed by retrieval of DLL content that was subsequently used for search-order hijacking within legitimate processes.
In the September–October 2025 cases, Darktrace alerting commonly surfaced early-stage registration and C2 setup behaviors, followed by retrieval of a DLL (e.g., Client.dll) from the same external host, sometimes repeatedly over multiple days, consistent with establishing and maintaining the execution chain.
In April 2026, a finance-sector endpoint initiated a series of GET requests to yahoo-cdn[.]it[.]com, first fetching legitimate binaries (including vshost.exe and dfsvc.exe), then repeatedly retrieving associated configuration and DLL components (including dfsvc.exe.config and dnscfg.dll) over an 11-day window. The use of both Visual Studio hosting and OneClick (dfsvc.exe) paths are used to ensure the malware can run in the targeted environment.
Technical Analysis
Initial staging and execution
While the initial access method is unknown, Darktrace security researchers identified multiple archives containing the malware.
A representative example includes a ZIP archive (“test.zip”) containing:
A legitimate executable: biz_render.exe (Sogou Pinyin IME)
A malicious DLL: browser_host.dll
Contained within the zip archive named “test.zip” is the legitimate binary “biz_render.exe”, a popular Chinese Input Method Editor (IME) Sogou Pinyin.
Alongside the legitimate binary is a malicious DLL named “browser_host.dll”. As the legitimate binary loads a legitimate DLL named “browser_host.dll” via LoadLibraryExW, the malicious DLL has been named the same to sideload the malicious DLL into biz_render.exe. By supplying a malicious DLL with an identical name, the actor hijacks execution flow, enabling the payload to execute within a trusted process.
The legitimate binary invokes the function GetBrowserManagerInstance from the sideloaded “browser_host.dll”, which then performs XOR-based decryption of embedded strings (key 0x90) to resolve and dynamically load mscoree.dll.
The DLL uses the Windows Common Language Runtime (CLR) to execute managed .NET code inside the process rather than relying solely on native binaries. During execution, the loader loads a payload directly into memory as .NET assemblies, enabling an in-memory execution.
C2 Registration
A GET request is made to:
GET /GetCluster?protocol=DotNet-TcpDmtp&tag={0}&uid={1}
with the custom header:
Verify_Token: Dmtp
This returns Base64-encoded and gzip-compressed IP addresses used for subsequent communication.
Figure 2: Decoded IPs.
Staged payload retrieval
Subsequent activity includes retrieval of multiple components from yahoo-cdn.it[.]com. The following GET requests are made:
Dfsvc.exe is the legitimate Windows ClickOnce Engine, part of the .NET framework used for updating ClickOnce Applications. Accompanying dfsvc.exe is a legitimate dfsvc.exe.config file that is used to store configuration data for the application. However, in this instance the malware has replaced the legitimate dfsvc.exe.config with the one retrieved from the server in: C:\Windows\Microsoft.NET\Framework64\v4.0.30319.
Additionally, vhost.exe the legitimate Visual Studio hosting process is retrieved from the server, along with “Microsoft.VisualStudio.HostingProcess.Utilities.Sync.dll” and “config.etl”. The DLL is used to decrypt the AES encrypted payload in config.etl and load it. The encrypted payload is dnscfg.dll, which can be loaded into vshost instead of dfsvc, and may be used if the environment does not support .NET.
Figure 3: ClickOnce configuration.
The malicious configuration disables logging, forces the application to load dnscfg.dll from the remote server, and uses a custom AppDomainManager to ensure the DLL is executed during initialization of dfsvc.exe. To ensure persistence, a scheduled task is added for %APPDATA%\Local\Microsoft\WindowsApps\dfsvc.exe.
Core payload
The DLL dnscfg.dll is a .NET binary named Client.TcpDmtp.dll. The payload is a heavily obfuscated backdoor that generates its logic at runtime and communicates with the command and control (C2) over custom TCP, DMTP (Duplex Message Transport Protocol) and appears to be an updated version of FDMTP to version 3.2.5.1
Once connected, the malware enters a persistent loop (LoopMessage), enabling it to receive commands from the remote server.
Figure 5: DMTP Connect function.
Rather than referencing values directly, they are retrieved through containers that are resolved at runtime. String values are stored in an encrypted byte array (_0) and decrypted by a custom XOR-based string decryption routine (dcsoft). The lower 16 bits of the provided key are XORed with 0xA61D (42525) to derive the initial XOR key, while subsequent bits define the string length and offset into the encrypted byte array. Each character is reconstructed from two encrypted bytes and XORed with the incrementing key value, producing the plaintext string used by the payload.
Figure 6: Decrypted strings.
Embedded in the resources section are multiple compressed binaries, the majority of which are library files. The only exceptions are client.core.dll and client.dmtpframe.dll.
Figure 7: Resources.
Modular framework and plugins
The payload embeds multiple compressed libraries, notably:
client.core.dll
client.dmtpframe.dll
Client.core.dll is a core library used for system profiling, C2 communication and plugin execution. The implant has the functionality to retrieve information including antivirus products, domain name, HWID, CLR version, administrator status, hardware details, network details, operating system, and user.
Figure 8: Client.Core.Info functions.
Additionally, the component is responsible for loading plugins, with support for both binary and JSON-based plugin execution. This allows plugins to receive commands and parameters in different formats depending on the task being performed.
The framework handles details such as plugin hashes, method names, task identifiers, caller tracking, and argument processing, allowing plugins to be executed consistently within the environment. In addition to execution management, the library also provides plugins with access to common runtime functionality such as logging, communication, and process handling.
Figure 9: Client.core functions.
client.dmtpframe.dll handles:
DMTP communication
Heartbeats and reconnection
Plugin persistence via registry:
HKCU\Software\Microsoft\IME\{id}
Client.dmtpframe.dll is built on the TouchSocket DMTP networking library and continues to manage the remote plugins. The DLL implements remote communication features including heartbeat maintenance, reconnection handling, RPC-style messaging, SSL support, and token-based verification. The DLL also has the ability to add plugins to the registry under HKCU/Software/Microsoft/IME/{id} for persistence.
Plugins observed
While the full set of plugins remains unknown, researchers were able to identify four plugins, including:
Persist.WpTask.dll - used to create, remove and trigger scheduled Windows tasks remotely.
Persist.registry.dll - used to manage registry persistence with the ability to create, and delete registry values, along with hidden persistence keys.
Persist.extra.dll - used to load and persist the main framework.
Assist.dll - used to remotely retrieve files or commands, as well as manipulate system processes.
Figure 10: Plugins stored in IME registry.
Figure 11: Obfuscated script in plugin resources.
Persist.extra.dll is a module that is used to load a script “setup.log” to load and persist the main framework. Stored within the resources section of the binary is an obfuscated script that creates a .NET COM object that is added to the registry key HKCU\Software\Classes\TypeLib\ {9E175B61-F52A-11D8-B9A5-505054503030} \1.0\1\Win64 for persistence. After deobfuscating this script, another DLL is revealed named “WindowsBase.dll”.
Figure 12: Registry entry for script.
The binary checks in with icloud-cdn[.]net every five minutes, retrieves a version string, downloads an encrypted payload named checksum.bin, saves it locally as C:\ProgramData\USOShared\Logs\checksum.etl, decrypts it with AES using the hardcoded key POt_L[Bsh0=+@0a., and loads the decrypted assembly directly from memory via Assembly.Load(byte[]). The version.txt file acts as an update marker so it only re-downloads when the remote version changes, while the mutex prevents duplicate instances.
Figure 13: USOShared/Logs.
Checksum.etl is decrypted with AES and loaded into memory, loading another .NET DLL named “Client.dll”. This binary is the same as “dnscfg.dll” mentioned at the start and allows the threat actors to update the main framework based on the version.
Conclusion
Across cases, Darktrace consistently observed the following sequence:
Retrieval of legitimate executables
Retrieval of DLLs for sideloading
C2 registration via /GetCluster
This approach is consistent with broader China-nexus tradecraft. As outlined in Darktrace’s Crimson Echo report, the stable feature of this activity is behavioral. Infrastructure rotates and payloads can change, but the execution model persists. For defenders, the implication is straightforward: detection anchored to individual indicators will degrade quickly. Detection anchored to a behavioral sequence offer a far more durable approach.
Credit to Tara Gould (Malware Research Lead), Adam Potter (Senior Cyber Analyst), Emma Foulger (Global Threat Research Operations Lead), Nathaniel Jones (VP, Security & AI Strategy)
Edited by Ryan Traill (Content Manager)
Appendices
A detailed list of detection models and triggered indicators is provided alongside IoCs.
Resilience at the Speed of AI: Defending the Modern Campus with Darktrace
Why higher education is a different cybersecurity battlefield
After four decades in IT, now serving as both CIO and CISO, I’ve learned one simple truth: cybersecurity is never “done.” It’s a constant game of cat and mouse. Criminals evolve. Technologies advance. Regulations expand. But in higher education, the challenge is uniquely complex.
Unlike a bank or a military installation, we can’t lock down networks to a narrow set of approved applications. Higher education environments are open by design. Students collaborate globally, faculty conduct cutting-edge research, and administrators manage critical operations, all of which require seamless access to the internet, global networks, cloud platforms, and connected systems.
Combine that openness with expanding regulatory mandates and tight budgets, and the balancing act becomes clear.
Threat actors don’t operate under the same constraints. Often well-funded and sponsored by nation-states with significant resources, they’re increasingly organized, strategic, and innovative.
That sophistication shows up in the tactics we face every day, from social engineering and ransomware to AI-driven impersonation attacks. We’re dealing with massive volumes of data, countless signals, and a very small window between detection and damage.
No human team, no matter how talented or how numerous, can manually sift through that noise at the speed required.
Discovering a force multiplier
Nothing in cybersecurity is 100% foolproof. I never “set it and forget it.” But for institutions balancing rising threats and finite resources, the Darktrace ActiveAI Security Platform™ offers something incredibly valuable: peace of mind through speed and scale.
It closes the gap between detection and response in a way humans can’t possibly match. At the speed of light, it can quarantine, investigate, and contain anomalous activity.
I’ve purchased and deployed Darktrace three separate times at three different institutions because I’ve seen firsthand what it can do and what it enables teams like mine to achieve.
I first encountered Darktrace while serving as CIO for a large multi-campus college system. What caught my attention was Darktrace's Self-Learning AI, and its ability to learn what "normal" looked like across our network. Instead of relying solely on static signatures or rigid rules, Darktrace built a behavioral baseline unique to our environment and alerted us in real time when something simply didn’t look right.
In higher education, where strict lockdowns aren’t realistic, that behavioral model made all the difference. We deployed it across five campuses, and the impact was immediate. Operating 24/7, Darktrace surfaced threats in ways our team couldn’t replicate manually.
Over time, the Darktrace platform evolved alongside the changing threat landscape, expanding into intrusion prevention, cloud visibility, and email security. At subsequent institutions, including Washington College, Darktrace was one of my first strategic investments.
Revealing the hidden threat other tools missed
One of the most surprising investigations of my career involved a data leak. Leadership suspected sensitive information from high-level meetings was being exposed, but our traditional tools couldn’t provide any answers.
Using Darktrace’s deep network visibility, down to packet-level data, we traced unusual connections to our CCTV camera system, which had been configured with a manufacturer’s default password. A small group of employees had hacked into the CCTV cameras, accessed audio-enabled recordings from boardroom meetings, and stored copies locally.
No other tool in our environment could have surfaced those connections the way Darktrace did. It was a clear example of why using AI to deeply understand how your organization, systems, and tools normally behave, matters: threats and risks don’t always look the way we expect.
Elevating a D-rating into a A-level security program
When I arrived at my last CISO role, the institution had recently experienced a significant ransomware attack. Attackers located data which informed their setting ransom demands to an amount they knew would likely result in payment. It was a sobering example of how calculated and strategic modern cybercriminals have become.
Third-party cyber ratings reflected that reality, with a D rating.
To raise the bar, we implemented a comprehensive security program and integrated layered defenses; -deploying state of the art tools and methods- across the environment, with Darktrace at its core.
After a 90-day learning period to establish our behavioral baseline, we transitioned the platform into fully autonomous mode. In a single 30-day span, Darktrace conducted more than 2,500 investigations and autonomously resolved 92% of all false positives.
For a small team, that’s transformative. Instead of drowning in alerts, my staff focused on less than 200 meaningful cases that warranted human review.
Today, we maintain a perfect A rating from third-party assessors and have remained cybersafe.
Peace of mind isn’t about complacency
The effect of Darktrace as a force multiplier has a real human impact.
With the time reclaimed through automation, we expanded community education programs and implemented simulated phishing exercises. Through sustained training and awareness efforts, we reduced social engineering susceptibility from nearly 45% to under 5%.
On a personal level, Darktrace allows me to sleep better at night and take time off knowing we have intelligent systems monitoring and responding around the clock. For any CIO or CISO carrying institutional risk on their shoulders, that matters.
The next era: AI vs. AI
A new chapter in cybersecurity is unfolding as adversaries leverage AI to enhance scale, speed, and believability. Phishing campaigns are more personalized, impersonation attempts are more precise, and deepfake video technology, including live video, is disturbingly authentic. At the same time, organizations are rapidly adopting AI across their own environments —from GenAI assistants to embedded tools to autonomous agents. These systems don’t operate within fixed rules. They act across email, cloud, SaaS, and identity systems, often with broad permissions, and their behavior can evolve over time in ways that are difficult to predict or control.
That creates a new kind of security challenge. It’s not just about defending against AI-powered threats but understanding and governing how AI behaves within your environment, including what it can access, how it acts, and where risk begins to emerge.
From my perspective, this is a natural next step for Darktrace.
Darktrace brings a level of maturity and behavioral understanding uniquely suited to the complexity of AI environments. Self-Learning AI learns the normal patterns of each business to interpret context, uncover subtle intent, and detect meaningful deviations without relying on predefined rules or signatures. Extending into securing AI by bringing real-time visibility and control to GenAI assistants, AI agents, development environments and Shadow AI, feels like the logical evolution of what Darktrace already does so well.
Just as importantly, Darktrace is already built for dynamic, cross-domain environments where risk doesn’t sit in a single tool or control plane. In higher education, activity already spans multiple systems and, with AI, that interconnection only accelerates.
Having deployed Darktrace multiple times, I have confidence it’s uniquely positioned to lead in this space and help organizations adopt AI with greater visibility and control.
---
Since authoring this blog, Irving Bruckstein has transitioned to the role of Chief Executive Officer of the Cyberaigroup.
