Warlock's SharePoint Playbook: Disable the Agent, Then Deploy the Ransomware
Warlock is exploiting year-old on-premises SharePoint flaws to reach Active Directory, disable security tooling, and deploy ransomware against critical infrastructure. Alert-only monitoring cannot survive a window where the agent dies before it fires.
The News
Warlock ransomware operators, tracked as connected to the Storm-2603 cluster, are still exploiting the on-premises SharePoint vulnerability chain publicly known as ToolShell, more than a year after Microsoft first moved to disrupt active exploitation of it [5]. Recent reporting ties Warlock activity to attacks on water utilities, telecom operators, and government organizations, with the SharePoint flaws serving as the initial foothold into environments that then lead straight to Active Directory [4][17].
The part that should make every MSSP sit up is not the exploit itself. It is the sequence. Before ransomware ever touches a file, Warlock operators use a vulnerable, signed driver to disable security tooling across the compromised environment, a classic Bring Your Own Vulnerable Driver (BYOVD) technique that lets an attacker with kernel-level access turn off EDR agents the tools were never designed to defend against from the inside [8]. Ransomware payloads have also been staged through SYSVOL after domain compromise, meaning the attacker is not just evading one endpoint's agent, they are using the domain's own trusted distribution mechanism to push the final blow at scale [16]. Storm-2603 has run this exploit-to-ransomware pattern before ToolShell was even named, which tells you this is a refined operational playbook, not an improvised one [2].
If your client list includes anyone running on-premises SharePoint, the question is not whether this campaign is relevant to you. It is whether you can see the tool-disabling step while it is happening, because by the time ransomware lands, the fight is already over.
The Exploit Chain, In Plain Terms
Strip away the CVE numbers and the sequence looks like this:
- Attacker exploits a known, unpatched on-premises SharePoint vulnerability to get code execution on the server [1][5].
- From the SharePoint server, the attacker pivots toward Active Directory, often reaching domain-level access [16][19].
- Using a vulnerable driver, the attacker disables EDR, antivirus, and related security agents across reachable hosts, not one at a time by hand, but systematically [8].
- Ransomware is staged and pushed, in some observed cases through SYSVOL, giving it the same trust and reach as legitimate Group Policy content [16].
Every step after step one depends on the defender's tooling staying blind or dead. That is the design. An attacker who can disable your agent doesn't need to out-think your detection logic. They just need to make sure it never runs.
Why Alert-Only Monitoring Fails Here
This is the uncomfortable truth buried in every one of these reports: a SOC model built around "detect, alert, wait for a human to read it and respond" assumes the agent generating the alert is still alive when the alert matters most. Warlock's own playbook breaks that assumption on purpose. The vulnerable driver step exists specifically to kill the thing that would have told you something was wrong, before it can tell you.
So picture the timeline from the defender's side. Host after host goes dark, not because of a network outage, but because something with kernel access just turned off the agent. If your monitoring model is alert-only, that moment produces nothing to act on; silence looks a lot like a quiet Tuesday night. The alert that should have triggered the response never fires, because the sensor that would have fired it no longer exists. By the time ransomware notes appear, the organization isn't dealing with a detection failure. They're dealing with a containment failure that happened hours earlier and nobody was positioned to stop it.
This is also why "we have good EDR" is not the same conversation as "we have 24/7 coverage that can act." EDR is the sensor and the enforcement arm. Someone, or something, still has to pull the trigger on containment the moment tooling integrity itself is the thing under attack, and that decision cannot wait for a ticket queue.
What Vijilan's Global SOC Does Differently
This is precisely the scenario ThreatRespond™, Vijilan's Managed XDR service, is built around. Our Global SOC does not treat detection as the finish line. When our analysts or Praxis AI™ see processes attempting to disable, tamper with, or kill security agents across multiple hosts in a short window, that pattern is itself the signal, and the response is isolation and process termination, not a ticket waiting for a shift change.
The operational difference matters most in exactly the window Warlock is engineered to exploit. If an agent goes dark on one host while a tampering pattern is visible on others, a 24/7 Global SOC watching across the environment can isolate the affected hosts and kill the malicious process chain before the attacker's next host in sequence loses its own protection. That's containment acting ahead of, or alongside, the spread, instead of a post-mortem written after ransomware notes are already on every desktop.
For environments still running on-premises SharePoint, this layered coverage extends naturally into NextDefend™ for network and identity visibility and ThreatHunt™ for proactively looking at Active Directory for the lateral movement patterns that precede a mass tool-disabling event. The goal is not another dashboard. It's a SOC that acts on the behavior of an attack, not just the signature of it.
What MSSP Partners Should Do Right Now
For partners with clients running on-premises SharePoint, a few concrete steps matter more than any vendor pitch:
- Patch the known SharePoint vulnerabilities immediately if that has not already happened. This exploit chain is over a year old and still working, which tells you patching alone has not closed the gap industry-wide [17].
- Audit Active Directory exposure from the SharePoint server. If that server has a clear path to domain admin or SYSVOL write access, you have inherited the attacker's fastest route to scale [16][19].
- Ask what happens the moment an agent goes dark, not just when it alerts. If the answer is "we investigate the ticket," you have an alerting pipeline, not a containment capability.
- Confirm coverage includes behavioral detection for tampering and driver abuse, not only known malware signatures. BYOVD techniques are explicitly designed to be invisible to signature-based tools [8].
Vijilan works alongside MSSPs and MSPs to extend exactly this kind of coverage, white-labeled where needed, across CrowdStrike Falcon, Microsoft Defender and Sentinel, SentinelOne, and other monitored EDR platforms your clients already run. We never compete with our partners for their clients. Our job is to make sure the SOC behind your brand can act in the minutes that matter, not just report on them afterward.
If you're assessing whether your current monitoring stack can contain an attack like this one, or you want to talk through what white-label ThreatRespond™ coverage looks like for your book of business, our MSP partner page is the place to start. Pricing questions go to our pricing page.
Frequently asked questions
What makes Warlock's attack different from typical ransomware?
Warlock operators systematically disable security tooling across multiple hosts using a vulnerable driver before deploying ransomware, rather than relying on evasion alone. This turns the containment window into the real battleground, not just the ransomware payload itself.
Is this a new SharePoint vulnerability?
No. Warlock is still exploiting the on-premises SharePoint vulnerability chain known as ToolShell, which Microsoft first acted to disrupt over a year ago. The campaign's persistence shows unpatched environments remain exposed long after fixes are available.
Why doesn't EDR alone stop this kind of attack?
EDR agents can be disabled by attackers with kernel-level access via vulnerable driver abuse. If no one is watching for the tampering pattern itself and acting on it in real time, the alert the agent would have generated simply never fires.
What does Vijilan's Global SOC do differently in a scenario like this?
Rather than waiting on an alert to be read and triaged, Vijilan's Global SOC and ThreatRespond™ service isolate affected hosts and kill malicious processes directly when tampering or mass tool-disabling patterns are detected, acting in the same window the attacker is trying to exploit.
Threat notes, once a week
What our SOC actually saw this week: new attack patterns, the detections we shipped against them, and what it means if you run an MSP. Written by the analysts, not by marketing.
See what 24/7 looks like when the SOC actually acts.
Book a 20-minute platform walkthrough: no slide deck, just the console.
Book a walkthrough →