Warlock Ransomware Still Targets On-Premises SharePoint: ToolShell, SYSVOL and AD Defense

If your organization still runs SharePoint Server on-premises, read this report as a warning about your own servers. The intrusion Symantec reconstructed began with one SharePoint web shell and ended nine days later with ransomware on dozens of domain-joined Windows machines.

Who is behind Warlock?​

Different vendors use different names for the attacker. Warlock is developed by a China-nexus threat actor Symantec calls Longlegs (aka Storm-2603). Symantec has previously tied this group to older activity clusters known as CL-CRI-1040, CamoFei, and ChamelGang.

Storm-2603 is Microsoft's name for the group. In its July 2025 ToolShell write-up, Microsoft said it had seen two Chinese nation-state actors, Linen Typhoon and Violet Typhoon, exploiting the SharePoint flaws. It described Storm-2603 separately, as another China-based actor using the same vulnerabilities to deploy ransomware. Microsoft assessed Storm-2603 as China-based with moderate confidence and said it could not confidently determine the group's objectives. Keep those three actors separate: the Typhoon groups are espionage outfits, and Storm-2603 is the one that deployed ransomware.

Warlock's victim list was already broad before this campaign. SecurityWeek reported that by October 2025, researchers uncovered numerous Warlock ransomware attacks that exploited ToolShell. Some of the group's victims included a Middle East telecom firm, African and South American government entities, and a US university.

Section summary: Symantec's Longlegs and Microsoft's Storm-2603 are names for the same Warlock operator. It's a China-nexus group whose motives are not fully understood, and it has a long record of breaking in through SharePoint.

Is it still ToolShell, or something newer?​

"Warlock emerged in June 2025 and hit the headlines weeks later, when attackers deploying it were found exploiting zero-day vulnerabilities in Microsoft SharePoint Server, dubbed 'ToolShell' (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, and CVE-2025-53771)," Symantec wrote. The researchers add that "Those flaws likely remain in the group's arsenal, alongside newer SharePoint flaws, which the U.S. Cybersecurity and Infrastructure Security Agency (CISA) warned about in an advisory published in July 2026."

That sentence hedges, and the hedge matters. Dark Reading reports that Symantec couldn't say whether Warlock is still feasting off ToolShell, or whether it might be taking advantage of newer SharePoint vulnerabilities. CISA added a handful of them to its Known Exploited Vulnerabilities (KEV) catalog over the summer. Dick O'Brien, principal intelligence analyst for the Symantec Threat Hunter Team, told Dark Reading that "the exploits for these more recent vulnerabilities behave quite similarly" to ToolShell.

For defenders, the uncertainty makes the job bigger. Installing the July 2025 ToolShell fixes is necessary but may not be enough. A SharePoint farm that missed any of the later security updates may still be exposed to the newer flaws.

Section summary: Nobody has confirmed which SharePoint bug was used in these intrusions. Assume the newer CVEs in CISA's KEV catalog are in play alongside ToolShell.

The attack chain: nine days from web shell to encryption​

Symantec reconstructed one intrusion at a critical infrastructure operator in detail. The report doesn't say which one, and Symantec named none of the victims or their countries. Here is the sequence the researchers describe:

1. July 22, 2026: web shell. The first malicious activity was a web shell written by PowerShell into the SharePoint LAYOUTS directory. Symantec says the group drops shells into the LAYOUTS directories of several SharePoint versions at once, so one of them works whichever version is installed. The shell collects the farm's ASP.NET machine keys. The attackers then use those keys to forge signed payloads that run code inside the SharePoint application pool.
2. July 24: reconnaissance and cleanup. Basic discovery commands (net user /domain, whoami) ran on a second SharePoint server. Some numerically named staging files were deleted. Executables for DLL sideloading appeared, including ssvagent.exe, logger.exe and doexe.exe with doexeloc.dll. nltest /domain_trusts mapped the domain's trust relationships.
3. July 27: confirmation ping. The second server sent a web request to an oastify.com subdomain, which is Burp Collaborator's out-of-band testing domain. The victim's own domain name was part of the URL, which looks like a per-target canary to confirm that injected code had executed.
4. July 28: exploitation and payload downloads. PowerShell repeatedly loaded the System.Workflow.ComponentModel assembly, which supplies the deserialization gadget that turns a forged __VIEWSTATE into code execution. The attackers then used msiexec to pull MSI packages from catbox.moe and wasabisys.com, both legitimate file hosts.
5. July 28–29: spreading into the domain. A domain account named SPSEPRDSetup was added to local Administrators on three more hosts. Symantec thinks the name was chosen to look like a normal SharePoint setup account. The attackers also installed a VS Code tunnel service and ran NetExec.
6. July 31: security tools killed, then ransomware. In the early hours, an AV/EDR killer (a.exe) was pushed from an internal share. Warlock (run.exe and rune.exe, plus a ransom note titled how to restore your files.txt) followed on each host.

Symantec said one thing about the final stage bluntly: Warlock appeared almost as soon as each host lost its protection. During one intrusion, the threat actor disabled security software on 40 systems and deployed Warlock on 33 of them. Symantec says "at least" for both counts, and they cover this one intrusion, not the whole campaign. Ignore the figure of "over 400 servers compromised" circulating on some aggregator sites. It doesn't appear in Symantec's report.

Section summary: The attackers spent about a week quietly preparing and then took the whole environment down in a matter of hours. Detection has to work during that quiet week, because the final strike is too fast to stop.

Three techniques worth hunting for​

1. A vulnerable signed driver used to kill security software (BYOVD)​

According to Symantec, Longlegs abuses a vulnerable, signed driver (K7RKScan) to disable security software before deploying ransomware, and has also been observed abusing Visual Studio Code's tunneling feature for covert remote access. The K7RKScan flaw is tracked as CVE-2025-1055. There is an important caveat for the July incident: Symantec says it doesn't know which driver the EDR killer used there. K7RKScan is confirmed only in other recent attacks by the group.

On Windows, the main defence here is Microsoft's vulnerable driver blocklist, together with alerting on any new kernel driver loaded on a server shortly before security tools stop. It is general industry practice, not a Symantec-specific recommendation, to treat an unexpected third-party AV driver turning up on a host that doesn't run that vendor's product as a high-priority alert.

2. VS Code tunnels used for remote access​

The attackers ran code-insiders.exe tunnel service install from the Windows\debug folder. Symantec points out that the binary is signed by Microsoft and the tunnel relays through Microsoft infrastructure. That makes the traffic look like normal developer or administrator activity. Nobody legitimately runs VS Code Insiders as a service from C:\Windows\debug on a server, so that combination is a strong lead. Check your servers for unexpected VS Code tunnel services. If your developers don't need tunnels, think about restricting the feature by policy.

3. Ransomware distributed through SYSVOL​

This technique is the most Windows-specific of the three. The threat actor stages the Warlock payload inside the domain's SYSVOL share, which is automatically replicated to every domain controller and is readable domain-wide, to execute the file-encrypting ransomware at scale. Telemetry from three hosts showed dfsrs.exe, the DFS Replication service, as the parent process that delivered run.exe and rune.exe from a SYSVOL\domain\scripts\run path. In other words, normal replication carried the payload. The ransomware arrived through a feature working exactly as designed.

Symantec describes SYSVOL staging as a known way to run payloads through logon scripts or Group Policy. It doesn't say which mechanism launched the files on every host. In 2025, Microsoft separately reported Storm-2603 modifying GPOs to distribute Warlock, so watching for Group Policy changes is still worthwhile.

Section summary: Every one of these techniques abuses something legitimate: a signed driver, a Microsoft-signed developer tool, and Active Directory's own replication. Signature-based detection alone won't catch them, so you need behavioural baselines.

What SharePoint and AD admins should do now​

Microsoft's ToolShell guidance applies only to SharePoint Server on-premises; SharePoint Online in Microsoft 365 was not affected. Its recommendations, adapted to this campaign:

• Run only supported versions with every current update installed. Microsoft lists SharePoint Server Subscription Edition, 2019 and 2016 as supported. The July 2025 fixes were KB5002768 for Subscription Edition, KB5002754 plus language pack KB5002753 for 2019, and KB5002760 plus KB5002759 for 2016. Those are only the baseline: check the Security Update Guide and CISA's KEV catalog for anything released since. CISA recommends disconnecting public-facing SharePoint versions that are end-of-life.
• Turn on AMSI in Full Mode and run Defender Antivirus or an equivalent on every SharePoint server. Microsoft notes that AMSI integration was enabled by default from the September 2023 update for 2016/2019 and from Version 23H2 for Subscription Edition, but confirm that nobody has switched it off. If you can't enable AMSI, Microsoft advises taking the server off the internet or putting it behind authenticated access.
• Rotate ASP.NET machine keys and restart IIS. Use Set-SPMachineKey, or run the Machine Key Rotation Job from Central Administration, then run iisreset.exe on every SharePoint server. Warlock's web shell exists to steal these keys, so patching without rotating them leaves the attacker able to forge payloads.
• Look for web shells. Check for unfamiliar .aspx files in LAYOUTS directories for every SharePoint version, including legacy paths such as the 14\template\layouts folder seen in this intrusion. Investigate w3wp.exe launching encoded PowerShell.
• Monitor SYSVOL. New executables under SYSVOL\<domain>\scripts deserve an immediate alert, as do new members of local Administrators groups whose names look like service accounts.
• Protect your security tools. Run EDR in block mode, keep tamper protection on, enable LSA protection, and use attack surface reduction rules where you have them.
• Search for the published IOCs. Symantec published SHA-256 hashes for the Warlock binaries, the malicious DLLs, the EDR killer and the vulnerable driver, along with network indicators including litter.catbox[.]moe and xn8xyt-drop.s3.wasabisys[.]com. Check your logs against them, but remember that catbox and Wasabi are legitimate services.

The bigger picture​

Two balancing points. First, Symantec sells endpoint products, and its report ends with a pitch for its XDR platform. The technical findings stand up, and outlets including SecurityWeek, The Record and Industrial Cyber covered them independently, but they all rely on Symantec's telemetry. Second, the cluster of Portuguese- and Spanish-speaking victims doesn't prove deliberate targeting. Symantec itself suggests the pattern could be either opportunistic or tasked, depending on which vulnerable SharePoint servers happened to be exposed.

What is clear is the conclusion Symantec draws: "Longlegs' continued activity, more than a year after Warlock ransomware first came to prominence, shows that exploitation of ToolShell and other related SharePoint vulnerabilities remains a viable initial access route for attackers on SharePoint deployments that have not been patched or otherwise mitigated."

When the victims include a water utility and a telecom provider, the damage doesn't stop at encrypted files. If you have a SharePoint server you haven't checked since summer 2025, check it now.