Ransomware

On October 1, Symantec's threat hunters reported that the China-nexus group they call Longlegs, which Microsoft tracks as Storm-2603, has hit at least four organisations with Warlock ransomware in the past two months. Two are critical infrastructure operators, a water utility and a telecommunications provider. The other two are a regional government body and a university. All four are in Portuguese- and Spanish-speaking countries across Europe, Africa and Latin America.

The way in is still on-premises SharePoint and the ToolShell flaws from July 2025: CVE-2025-49704 and CVE-2025-49706, chained together, and their bypasses CVE-2025-53770 and CVE-2025-53771. What deserves attention is what happens after that. In the intrusion Symantec describes in detail, the attackers turned a security-tool killer loose on at least 40 machines in about two hours, then put Warlock and its ransom note on at least 33. Most of the steps after the web shell ran through signed software or built-in Windows services, so the detections below focus on those steps.

How it works

ToolShell gives an unauthenticated attacker code execution on an unpatched SharePoint server. Here the attackers used it to place an ASPX web shell in SharePoint's LAYOUTS directory on July 22, 2026. The shell's job was to read the farm's ASP.NET machine keys, the secrets SharePoint uses to sign and validate __VIEWSTATE, the blob of page state a browser sends back with each form. With those keys, the attackers can forge a validly signed __VIEWSTATE that the server deserialises and runs inside the SharePoint application pool. Patching after the fact does not undo that. Until the keys are rotated, a forged payload still passes the signature check.

From there the chain moves off SharePoint and onto public file hosts, signed programs and Windows services that defenders rarely alert on:

• Payloads arrived as MSI packages fetched with msiexec from litter.catbox.moe and xn8xyt-drop.s3.wasabisys.com, both public file hosts. They ran through DLL sideloading, where a legitimate program loads a malicious DLL placed beside it: pairs such as ssvagent.exe with gsdll64.dll.tmp and logger.exe with doexeloc.dll.tmp.
• For remote access, the attackers installed Visual Studio Code Insiders as a service with code-insiders.exe tunnel service install --accept-server-license-terms. A VS Code tunnel gives remote shell access relayed through Microsoft's own tunnel service, so the traffic goes to a Microsoft domain from a Microsoft-signed binary.
• To blind defenders, Longlegs uses K7RKScan.sys, a signed kernel driver from K7 Security Anti-Malware, tracked as CVE-2025-1055. Versions before 23.0.0.10 do not check who is calling one of the driver's control functions (an IOCTL), so any process that can load the driver can ask it to terminate protected processes, security agents included. This is bring your own vulnerable driver (BYOVD): the attacker supplies an old, legitimately signed driver precisely because Windows will load it.
• For distribution, the attackers used SYSVOL, the share every domain controller replicates through the Distributed File System Replication service (DFSR) and every domain member can read. Warlock's binaries, run.exe and rune.exe, were staged in SYSVOL's scripts folder. On three hosts, Symantec's telemetry recorded dfsrs.exe, the replication process, as the process that delivered them. Once staged on one domain controller, the payload sits on all of them.

What attackers are doing

The detailed case is one of the critical infrastructure operators. After the web shell went in, the attackers ran whoami, net user /domain and nltest /domain_trusts to map the domain. A second host ran NetExec (nxc.exe), the open-source successor to CrackMapExec, for Active Directory enumeration and credential spraying, which means trying one or two common passwords against many accounts.

They then added a domain account named SPSEPRDSetup to the local Administrators group on three further hosts. SharePoint service accounts usually carry an SPS or SP prefix, so the name was most likely chosen to blend in. The tool killer, a.exe, followed on at least 40 hosts within roughly two hours, and Warlock with a ransom note named how to restore your files.txt on at least 33. Symantec says a.exe likely relied on a vulnerable driver and names K7RKScan as the driver the group abuses.

This continues what Microsoft reported in July 2025, when it first linked Storm-2603 to Warlock after exploitation of the same SharePoint flaws from July 18 that year. Then the group used Mimikatz, PsExec and Impacket, and pushed Warlock out by modifying Group Policy Objects. The 2026 cases swap GPO edits for SYSVOL staging, which never touches a GPO but uses the same replicated share GPOs live in. Symantec has not said how run.exe was launched on each host.

What to do

1. Close the SharePoint entry point

Install the current cumulative update on every SharePoint Server 2016, 2019 and Subscription Edition server, which includes the July 2025 ToolShell fixes and later ones such as the August 2026 fix covered in our CVE-2026-65660 post. Turn on the Antimalware Scan Interface (AMSI) integration in Full Mode with Microsoft Defender Antivirus on each server. If a farm was internet-facing and unpatched at any point since July 2025, rotate its machine keys with Update-SPMachineKey or the Machine Key Rotation timer job in Central Administration, then run iisreset on every server.

2. Block the driver and the tunnel

Add K7RKScan.sys to your Windows Defender Application Control (App Control for Business) deny rules and confirm the Microsoft vulnerable driver blocklist is enabled. The driver is listed on LOLDrivers.io, which publishes hashes you can import. Unless K7's product is actually installed, any load of this driver is suspicious, so alert on Sysmon Event ID 6 (driver loaded) for it.

For VS Code, deploy Microsoft's Dev Tunnels administrative templates and enable "Disable Dev Tunnels" on servers, or "Allow only selected Microsoft Entra tenant IDs" on developer machines. At the proxy, block or alert on *.tunnels.api.visualstudio.com from servers and domain controllers. Hunt for any service whose path points at code.exe or code-insiders.exe, and any command line containing tunnel service install.

3. Check whether you were already hit

• List every executable under SYSVOL: Get-ChildItem \\<domain>\SYSVOL\<domain>\scripts -Recurse -Include *.exe,*.dll,*.msi. Executables there are rare in most domains; run.exe and rune.exe are the names seen in this campaign.
• On SharePoint servers, look for w3wp.exe (the IIS worker) spawning cmd.exe or encoded PowerShell, and for new .aspx files under the LAYOUTS folder.
• Search Security event logs for Event ID 4732 (member added to a local group) where the group is Administrators and the account looks like a SharePoint setup account you did not create.
• Search proxy and DNS logs for litter.catbox.moe and the wasabisys.com hosts above, and for msiexec command lines that install from a URL.
• Look for a file named how to restore your files.txt on file servers and workstations; one hit means encryption has already started.

4. If you find any of it

Treat the domain as compromised. Remove staged files from SYSVOL on one domain controller and confirm replication cleared them everywhere. Reset the passwords of every account NetExec could have sprayed, the SharePoint farm and application pool accounts, and the KRBTGT account twice. Rotate the SharePoint machine keys even if the farm is now patched.

The wider lesson

Most detections assume an attacker brings malware. Apart from the tool killer and Warlock itself, this chain ran on signed code and built-in services: a K7 driver, a Microsoft-signed editor, the domain's own replication. Controls that decide what may load (driver blocklists, application control, tunnel policies) and alerts on configuration changes (new executables in SYSVOL, new local admins) catch it where signature checks would not.

Our security operations team builds and tunes detections like the SYSVOL and tunnel checks above, and our safeguarding and hardening work puts driver blocklists and tunnel policies in place across a domain. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Symantec Threat Hunter Team, Cybersecurity News, Cryptika, Dark Reading, Hendry Adrian, Microsoft Security blog, July 2025, Help Net Security, NVD CVE-2025-1055, LOLDrivers, Microsoft Learn, Dev Tunnels policies, mnemonic, Sigma rule for VS Code tunnel connections.