When the EDR Goes Dark: What the Warlock Attacks Teach Us About Single-Layer Defense
Nine days, then two hours
The ransomware was the last two hours of a nine-day operation. Everything that decided the outcome happened before it.
Last week, Symantec’s Threat Hunter Team published details of a campaign by the China-linked Warlock ransomware group against a water utility, a telecom provider, a regional government body and a university. Symantec tracks the operator as Longlegs, and SecurityWeek notes it is also tracked as Storm-2603. As BleepingComputer reports, the group has spent the past two months concentrating on Portuguese- and Spanish-speaking countries across Europe, Africa and Latin America.
One intrusion began on 22 July. The encryption came on 31 July. In between, the attacker did what attackers always do: they looked around, collected credentials, set up remote access and staged their payload. Then, in the final stretch, they switched off the endpoint protection on at least 40 machines in roughly two hours and encrypted at least 33 of them.
That sequence is worth sitting with, because it describes a failure mode that a lot of security programs are quietly built on top of.
Anatomy of the attack
Based on Symantec’s research, the intrusion unfolded in six stages over nine days. Only the last one looked like ransomware. Every earlier stage was quieter, and every one was a chance to stop it.
Getting in through SharePoint
The group typically breaks in through unpatched, internet-facing on-premises SharePoint servers. It made its name in July 2025 by exploiting ToolShell, a chain of SharePoint zero-days, and The Record reports that the 2026 attacks also use newer SharePoint flaws CISA has warned are under active exploitation. Once inside, the attacker plants a web shell written to work across multiple SharePoint versions.
Symantec’s assessment is blunt: more than a year after Warlock first appeared, these vulnerabilities remain a viable way in on any SharePoint deployment that hasn’t been patched or mitigated.
Looking around and cleaning up
Two days after gaining access, the attacker began reconnaissance and deleted what appeared to be staging artifacts. That clean-up is telling. It points to an operator who expects someone might eventually look, and who is deliberately shrinking the forensic trail before the main event.
Hiding inside a developer tool
Rather than deploying an obvious remote access trojan, the attacker installed the VS Code Insiders executable as a Windows service. That let them reconnect to compromised machines through VS Code’s built-in Remote Tunnels feature, a legitimate capability designed to let developers reach a remote machine through a secure tunnel.
To most security tools, that traffic looks like a developer using a trusted Microsoft product. The giveaway is context: a code editor running as a service, on a server that has no reason to host one.
Going after identity
On one system, researchers found NetExec, an open-source penetration testing framework. The attacker used it to enumerate Active Directory, spray credentials across accounts and execute commands remotely.
This is the moment an intrusion on one server becomes an intrusion on the whole domain. Every one of those actions authenticates against domain controllers, so the evidence lands in identity telemetry rather than on any single endpoint.
Staging for a domain-wide blast
The ransomware payload was placed in the domain’s SYSVOL share. SYSVOL is replicated to every domain controller and readable across the domain, which is exactly why administrators use it for logon scripts and Group Policy. For an attacker, it is a launchpad: a payload staged there can be executed across the entire network at once rather than one host at a time.
Blinding the defenders, then encrypting
On 31 July, the attacker made the final move. Using a “bring your own vulnerable driver” (BYOVD) technique, they loaded a legitimately signed but vulnerable K7RKScan driver (CVE-2025-1055) to gain kernel-level access and switch off security software.
Symantec observed protection disabled on at least 40 hosts in roughly two hours. Encryption followed on each machine within moments of its protection going offline, and at least 33 hosts were hit.
Symantec’s full report includes indicators of compromise for the files and infrastructure used, and the campaign has also been covered by BleepingComputer, SecurityWeek and The Record.
Why the endpoint couldn’t save itself
Endpoint detection is a strong control. But in this attack it was also the attacker’s primary target, and that is the problem with treating it as the whole defense.
Think about what the endpoint saw. A web shell on a web server. A developer tool running as a service. Authentication attempts against Active Directory. A file sitting in a share that exists on every Windows domain. Each of those can be benign on its own, and an agent judging one host at a time has little context to tell otherwise.
Then, at the decisive moment, the attacker used a signed driver to remove the agent altogether. A sensor that has been switched off generates no alerts. If your detection and your response both live on the same agent, an attacker who disables that agent removes both at once.
This is not a criticism of any one product. It is a design question every security leader should be asking: what is still watching when the endpoint goes dark?
Nine days of signals, outside the endpoint
Almost every stage of this attack left evidence somewhere other than the endpoint agent. The defender’s window was nine days, not two hours.
Two of these deserve special attention. First, deception: an attacker running credential spraying and AD enumeration is exactly the kind of adversary that trips over a decoy account or fake share, and a decoy alert has almost no false positives because no legitimate user should ever touch it. Second, sensor health: 40 agents going quiet within two hours is itself a high-confidence alert, but only if something outside those agents is watching for it.
This is the gap between telemetry and coverage. Telemetry is what one sensor reports. Coverage is whether the whole attack chain is visible, correlated and acted on, even when one layer is blinded.
What to do today
If you run on-premises SharePoint, or any environment where one agent carries your detection and response, these steps close most of the gaps this campaign used.
- Patch or isolate on-premises SharePoint. Confirm the ToolShell fixes and the newer SharePoint patches CISA has flagged are applied, rotate machine keys, and hunt web directories for unfamiliar script files. If a server can’t be patched, take it off the internet.
- Hunt for remote-access tooling running as services. Look for VS Code, VS Code Insiders, or other developer and RMM tools installed as services on servers, especially with outbound Remote Tunnels connections.
- Block known-vulnerable drivers. Turn on the Microsoft vulnerable driver blocklist and the Attack Surface Reduction rule that blocks abuse of exploited vulnerable signed drivers. Alert on loads of drivers known to be abused for BYOVD, including the K7RKScan driver named in this research.
- Watch SYSVOL and Group Policy. Alert on any new executable in SYSVOL and on GPO changes outside your change windows.
- Monitor your sensors, not just their alerts. Treat several agents going offline in a short window as a priority incident, not a maintenance ticket.
- Plant tripwires. Deploy decoy accounts, credentials and shares where an attacker enumerating Active Directory will find them.
- Ingest the IOCs. Symantec’s report publishes file and infrastructure indicators. Run a retrospective search across at least the last 90 days.
- Test the scenario. Ask your SOC or MDR provider directly: if every endpoint agent were disabled tonight, how would you know, and who would contain the attack?
Coverage, not just telemetry
The lesson from Warlock is not “endpoint security doesn’t work.” It is that endpoint visibility is important, but operational visibility across the entire attack chain is what determines security outcomes.
At LMNTRIX, that principle shapes how we build detection. Network, identity, endpoint and deception telemetry are correlated in one platform, so an attacker who blinds one layer still has to get past the others. Our analysts run more than 450 automated hunts continuously, looking for exactly the quiet, pre-ransomware behaviour this campaign relied on. Every alert is validated by a human before it reaches you, which is how we keep our false-positive rate below 0.0001%. And when something is real, we own the response: containment in under 30 minutes, with incident response included rather than metered.
The Warlock attacker had nine days. The question for every security team is how many of them you would have needed.
Want to find out? LMNTRIX offers a free 30-day proof of concept: we deploy, baseline your environment, hunt for active threats, validate what we find, and close out with an executive briefing. If something like Warlock is already inside, that’s how you’d want to learn about it.