Why this matters now
Symantec's Threat Hunter team reports that the China-linked group behind Warlock ransomware — tracked by Symantec as Longlegs and by Microsoft as Storm-2603 — is still breaking into organizations through Microsoft SharePoint flaws. Over two months ending October 1, 2026, the group hit at least four organizations: a water utility, a telecommunications provider, a regional government body, and a university, concentrated in Portuguese- and Spanish-speaking countries across Europe, Africa, and Latin America.
What makes this campaign worth hunting is not the encryption — it is the kill chain discipline. The group exploits SharePoint vulnerabilities first seen in the 2025 ToolShell chain (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771), for which many shops have had fifteen months to patch. It then blinds endpoint protection on dozens of hosts in about two hours using a legitimately signed but vulnerable driver, and finally stages the ransomware in the domain's own SYSVOL share so Windows' normal file replication delivers it to every machine. In one documented intrusion, the EDR-killing tool reached 40+ hosts in roughly two hours, and Warlock itself landed on 33 hosts through SYSVOL. The newer CVE-2026-45659 is now in CISA's Known Exploited Vulnerabilities catalog, which turns patching from an incident report into a compliance clock.
This playbook hunts the Warlock intrusion the way Symantec described it: driver load, tunnel, staging, detonation. Each hunt below maps to a stage you can instrument today in Microsoft Defender or Splunk.
The kill chain, stage by stage
1. Initial access: unpatched on-premises SharePoint
Warlock enters through internet-facing SharePoint Server, reusing the ToolShell chain plus newer SharePoint flaws. The attackers drop a web shell into the SharePoint LAYOUTS directory for several SharePoint versions at once, so the shell works whichever version is installed. They then steal the SharePoint farm's ASP.NET machine keys and use them to forge signed __VIEWSTATE payloads — full remote code execution inside the SharePoint application pool. Symantec notes the group's continued success suggests many organizations patched but never rotated their machine keys, the mandatory recovery step Microsoft's ToolShell guidance requires.
2. Defense evasion: BYOVD EDR kill (K7RKScan.sys, CVE-2025-1055)
The campaign's signature move is a bring-your-own-vulnerable-driver (BYOVD) attack. The attackers deploy K7RKScan.sys, a signed but flawed driver tracked as CVE-2025-1055, which can terminate protected security processes at kernel level. The same driver was previously exploited by DragonForce ransomware actors. In the July 22–31 intrusion Symantec traced, the driver-bearing tool reached at least 40 hosts in about two hours. They also disguise tooling with legitimate names — renaming the rclone data-exfiltration tool as TrendSecurity.exe — and use DLL sideloading to load malicious code into memory of signed binaries.
3. Command and control: Visual Studio Code tunnels
Rather than a custom backdoor, the group abuses Visual Studio Code's built-in code tunnel feature for remote access, installing VS Code (or VS Code Insiders) as a Windows service so tunneling persists. Because Microsoft signs the binary and relays the traffic, the channel blends into legitimate developer activity. NetExec, an open-source post-exploitation framework, handles Active Directory enumeration and credential spraying for lateral movement via SMB and RDP.
4. Staging: the SYSVOL trick
This is the stage most defenders miss. Warlock is staged directly inside the domain's SYSVOL share. Ordinary DFS replication then carries the ransomware binary to every domain controller — and from there to member hosts. In the documented intrusion, ordinary domain replication delivered Warlock to at least 33 hosts; the payload then executed with high privilege and encrypted simultaneously. Files appearing in SYSVOL that your Group Policy tooling did not put there are a five-alarm fire.
5. Exfiltration and detonation
Follow-on payloads arrive from legitimate cloud file-sharing and storage services such as catbox.moe and wasabisys.com, and stolen data leaves via Proton Drive with burner credentials. Symantec describes the group cleaning up staging artifacts to minimize detection.
The KQL hunts
Hunt 1 — K7RKScan vulnerable-driver loads (the EDR-kill precursor)
The single highest-value hunt in this playbook. A driver load of k7rkscan.sys on a production server has no legitimate explanation:
// Hunt: K7RKScan vulnerable driver loads (CVE-2025-1055) across the fleet
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType == "DriverLoad"
| where FileName =~ "k7rkscan.sys"
| project Timestamp, DeviceName, DeviceId, InitiatingProcessFileName,
InitiatingProcessCommandLine, InitiatingProcessAccountName, SHA1, SHA256
| order by Timestamp descBroader net — flag any signed-driver load of a known-bad driver on tier-0 assets by joining your own vulnerable-driver watchlist rather than hardcoding one name:
// Hunt: driver loads from a vulnerable-driver watchlist on critical servers
let badDrivers = dynamic(["k7rkscan.sys"]);
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType == "DriverLoad"
| where FileName in~ (badDrivers)
| where DeviceName has_any ("dc", "ad", "srv")
| project Timestamp, DeviceName, FileName, InitiatingProcessFileName, SHA1Hunt 2 — VS Code tunnel abuse as covert remote access
// Hunt: VS Code tunnel sessions started by interactive or service accounts
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("code.exe", "code-tunnel.exe", "code-insiders.exe")
| where ProcessCommandLine has "tunnel"
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
InitiatingProcessFileName, ProcessId, InitiatingProcessAccountName
| order by Timestamp desc// Hunt: VS Code installed/persisted as a service (tunnel survival trick)
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType == "ServiceInstalled"
| where ServiceFileName has "code" or InitiatingProcessFileName has_any ("code.exe", "code-insiders.exe")
| project Timestamp, DeviceName, ServiceName, ServiceFileName, InitiatingProcessFileNameTune for your environment: shops where developers legitimately use code tunnel should baseline expected hosts and alert on first-seen devices, unusual parent processes, or tunnel activity on servers.
Hunt 3 — Files appearing in SYSVOL
// Hunt: unexpected executables/scripts written to the SYSVOL share
DeviceFileEvents
| where Timestamp > ago(30d)
| where ActionType == "FileCreated"
| where FolderPath has @"\SYSVOL\"
| where FileName endswith ".exe" or FileName endswith ".dll"
or FileName endswith ".ps1" or FileName endswith ".bat"
| where InitiatingProcessFileName !in~ ("dfsrs.exe", "gpsvc.exe", "svchost.exe")
| project Timestamp, DeviceName, FolderPath, FileName, SHA1,
InitiatingProcessFileName, InitiatingProcessAccountName
| order by Timestamp descRun this one against your domain controllers first. Any hit deserves an immediate look: legitimate GPO changes land in \SYSVOL\...\Policies\ via admin tooling, not random executables.
Hunt 4 — Rogue local-admin additions (the fake SharePoint-style account)
Symantec observed the group adding a fake SharePoint-style account to the local administrators group to keep a foothold as it moved across hosts:
// Hunt: accounts added to local Administrators by odd parents
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType == "UserAccountAddedToGroup"
| where InitiatingProcessFileName has_any ("w3wp.exe", "powershell.exe",
"pwsh.exe", "net.exe", "cmd.exe", "netexec.exe", "nxc.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName,
InitiatingProcessCommandLine, AdditionalFields
| order by Timestamp descSplunk equivalents
The same stages, expressed for Splunk with Sysmon and Windows Event Log sourcetypes:
SPL 1 — Vulnerable driver load (Sysmon EventCode 6)
index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=6
| search ImageLoaded="*k7rkscan.sys*"
| table _time, Computer, User, Image, ImageLoaded, HashesSPL 2 — VS Code tunnel process or service
index=windows (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 CommandLine="*tunnel*")
OR (sourcetype=WinEventLog:System EventCode=7045 Service_File_Name="*code*")
| table _time, Computer, EventCode, Image, CommandLine, ServiceName, Service_File_NameSPL 3 — SYSVOL file creation (Sysmon EventCode 11)
index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=11
| search TargetFilename="*SYSVOL*" (TargetFilename="*.exe" OR TargetFilename="*.dll" OR TargetFilename="*.ps1")
| table _time, Computer, Image, TargetFilename, UserSPL 4 — Accounts added to Administrators (EventCode 4728)
index=wineventlog sourcetype=WinEventLog:Security EventCode=4728
| table _time, Computer, TargetUserName, MemberName, SubjectUserNameFor the SharePoint stage itself, your primary log source is IIS: hunt for requests to /_layouts/ paths that do not match your farm's normal traffic, web shells dropped as .aspx in LAYOUTS directories, and POST volume anomalies against SharePoint endpoints.
Triage: what to do when a hunt hits
1. Driver load hit. Treat it as active EDR tampering until proven otherwise. Check whether endpoint protection on the host is still functional, pull the driver's SHA256, and check it against the CVE-2025-1055 advisory and Microsoft's vulnerable-driver blocklist. Ask: what process dropped the driver, and did it arrive via SMB from another host (lateral movement already underway)?
2. VS Code tunnel hit. Correlate the tunnel start time with any driver-load or SYSVOL hits on the same device. If the tunnel started on a server with no developers, assume compromise and capture the account that started it plus the outbound tunnel endpoint.
3. SYSVOL hit. Do not delete the staged file before imaging: capture its hash, note every host that has already pulled it via DFSR (DFS Replication event logs), and check for scheduled tasks, logon scripts, or GPO edits referencing it. A staged binary in SYSVOL means the actor had domain-level write access — scope the intrusion, don't just clean the file.
4. SharePoint hit. If a webshell appears in LAYOUTS, assume machine-key compromise: patch alone is not enough. Microsoft's ToolShell guidance requires rotating the ASP.NET machine keys after patching; the EU's joint technical assessment of the 2025 incident flagged key rotation as a mandatory recovery step.
Remediation and hardening
- Patch SharePoint for the ToolShell chain (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771) and CVE-2026-45659 — then rotate ASP.NET machine keys on every farm.
- Enable the vulnerable-driver blocklist: turn on HVCI / Memory Integrity and Microsoft's vulnerable driver blocklist (WDAC policy) so BYOVD drivers like K7RKScan.sys cannot load even if an attacker drops them. Enforce tamper protection in Defender so the blocklist cannot be disabled.
- Restrict VS Code tunneling: if your developers don't need it, block
code tunnelvia policy; if they do, alert on first-seen hosts and server-class devices. - Watch SYSVOL like a tripwire: deploy the SYSVOL file-creation hunt as a scheduled detection on all domain controllers, with a low-noise allowlist for legitimate GPO operations.
- Segment and rotate: local admin accounts used by SharePoint app pools should be unique per farm and rotated after any webshell finding.
Mapping to MITRE ATT&CK
For detection-engineering bookkeeping, the Warlock stages map to: T1190 (Exploit Public-Facing Application — SharePoint), T1505.003 (Server Software Component: Web Shell), T1562.001 (Impair Defenses: Disable or Modify Tools — BYOVD), T1572 (Protocol Tunneling — VS Code tunnels), T1074 (Local Data Staging — SYSVOL), T1110 (Brute Force — NetExec spraying), T1021 (Remote Services — SMB/RDP lateral movement), and T1567.002 (Exfiltration to Cloud Storage — Proton Drive).
Pair this endpoint playbook with its companion piece from yesterday, the OSINT hunting playbook on exposed data platforms behind the Japan–Korea breach wave — outside-in exposure hunting plus inside-out kill-chain hunting is how a shop covers both ends of a campaign like this one.