Warlock Ransomware — Longlegs SharePoint Campaign

The attacker's objective in this campaign is domain-wide ransomware detonation launched from a single exploited internet-facing SharePoint Server. Longlegs (tracked by Microsoft as Storm-2603, with older activity linked to CL-CRI-1040, CamoFei and ChamelGang) exploits on-premises SharePoint vulnerabilities, drops a webshell into the LAYOUTS directory, steals the farm's ASP.NET machine keys, and forges a validly signed __VIEWSTATE payload to get code execution inside the SharePoint application pool. From there the group pivots through living-off-the-land recon, DLL side-loading, a masquerading domain account, NetExec-driven AD enumeration, and finally a BYOVD defense-evasion stage before staging Warlock ransomware in the domain's SYSVOL share for replication to every domain controller.

Symantec's Threat Hunter Team (security.com, published 1–2 Oct 2026) documented at least four victims over the preceding two months: 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. In one intrusion the actor disabled security tooling on at least 40 hosts within about two hours, then deployed Warlock on at least 33 hosts.

The single highest-leverage defensive angle in this pack is the Visual Studio Code Insiders tunnel-as-a-service technique: it is the most distinctive persistence/C2 mechanism in the campaign, it rides on a Microsoft-signed binary and Microsoft's own relay infrastructure, and it is unlikely to be present at all on a SharePoint farm member or domain controller in most environments, making it one of the cleanest high-fidelity signals available. The BYOVD stage and the SYSVOL-staged ransomware execution are the two steps immediately before mass detonation and deserve equal priority.

Four sources were fetched and saved verbatim to Warlock-Longlegs-SharePoint-Hunt-sources/. Two additional sources (Industrial Cyber and cyberpress.org) were attempted and are listed in References as not cited, because both returned a Cloudflare bot-detection interstitial (HTTP 403 "Just a moment...") rather than article content. Per policy against bypassing bot detection, no further access was attempted and no claim in this pack relies on either page.

No distinct, directly-quoted Microsoft blog post or advisory specific to this October 2026 Warlock/Longlegs campaign could be located. Microsoft's documented connection to this activity is limited to its prior (2025) attribution of the ToolShell exploit chain to Storm-2603, alongside state-backed Linen Typhoon/Violet Typhoon activity, as reported independently by BleepingComputer and The Record. This pack does not attribute any 2026-specific claim to Microsoft that Microsoft itself has not been quoted making.

Prompt-injection check: all fetched content was treated as untrusted data. No fetched page contained text directing the model to run a command, fetch an unrequested URL, change the output path, skip a step, or claiming user/administrator authorization. Nothing was found to report on this front.

Hunt Hypotheses

1. H1 — Initial access/execution: SharePoint ToolShell-class exploitation drops a webshell and triggers a deserialization gadget under the SharePoint worker process. (T1190, T1505.003, T1059.001 · high confidence)
2. H2 — Tool ingress: Follow-on payloads are pulled via msiexec from public object-storage/paste services. (T1105 · high confidence)
3. H3 — Defense evasion via side-loading: DLL side-loading pairs are staged outside standard install directories to run without a flagged standalone binary. (T1574.002 · medium confidence)
4. H4 — Recon & masquerade: Living-off-the-land recon runs from the SharePoint worker process, and a masquerading setup-style account is added to local Administrators. (T1087.002, T1482, T1098.007 · medium-high confidence)
5. H5 — OOB canary beaconing: Out-of-band DNS callbacks to a Burp-Collaborator-style domain confirm RCE. (T1071.004 · medium confidence, dual-use infrastructure)
6. H6 — Covert C2/persistence via VS Code tunneling: VS Code Insiders is installed as a Windows service to open a Microsoft-signed remote tunnel. (T1219, T1543.003, T1036 · high confidence — most distinctive signal in this campaign)
7. H7 — Lateral movement: NetExec drives AD enumeration and credential spraying ahead of domain-wide staging. (T1087.002, T1110.003, T1021.002 · high confidence)
8. H8 — BYOVD defense evasion → domain-wide ransomware: A vulnerable signed driver disables security tooling at kernel level, immediately followed by Warlock staged through SYSVOL/DFSR replication. (T1068, T1562.001, T1072, T1486 · high confidence)

Attack Chain — Documented Intrusion, 22–31 July 2026

All atomic indicators above trace to a single primary research source (Symantec/Carbon Black). Per this pack's sourcing policy, nothing here ships at Prevent or Critical severity: pure-malware hashes are single-sourced for exact values (the bar for Prevent/Critical is two independent sources), and the driver hash/filename is a legitimate signed product that is never actioned as Prevent regardless of sourcing.

Non-CQL checks that close the gaps Falcon process telemetry alone cannot reach:

• IIS / SharePoint ULS logs: search for anomalous POST requests to /_layouts/15/ or /_vti_bin/ endpoints carrying large base64 payloads or abnormal response codes, correlated to the exploitation window.
• Windows Security Event ID 4697/4698/7045 (service installed): cross-reference against Falcon's CreateService event for the code-insiders.exe tunnel; Windows Event Forwarding is a useful independent confirmation channel where deployed.
• SharePoint machineKey / web.config change auditing: file-integrity monitoring on every farm member's web.config, alerting on any modification timestamp outside a planned change window.
• DNS resolver / proxy logs: lookups for *.oastify.com, *.wasabisys.com, and *.catbox.moe originating outside approved developer or security-testing source ranges.
• AD "Restricted Groups" / local administrators drift report: any account matching an SPS*Setup / SP*PRDSetup naming pattern added outside a documented patch or farm-configuration window.
• SYSVOL file-integrity monitoring: alert on any new, unexpected file under \SYSVOL\<domain>\scripts\ on any domain controller.

All IOA candidates below are recommended at Detect only. None of this pack's behavioral patterns or pure-malware hashes clear the two-independent-source bar this pack requires for Prevent/Critical, and the driver/VS Code/NetExec binaries are legitimate or dual-use and are never actioned as Prevent regardless of sourcing.

IOA-1 · SharePoint LAYOUTS Webshell Write

Pattern: Q1 (PowerShell/w3wp.exe WriteAllBytes to a layouts path + .aspx). Exclusions: legitimate .wsp solution deployment via stsadm/Install-SPSolution. Deployment: enable in Detect across all SharePoint farm members; route to the highest-priority queue given this is the initial-access artifact.

IOA-2 · VS Code Insiders Tunnel Service (process + CreateService)

Pattern: Q8/Q9/Q10. Exclusions: approved developer-workstation allowlist. Deployment: Detect, fleet-wide, excluding the allowlist; tag campaign:Warlock-Longlegs. This is the most distinctive signal in the campaign and should route to a dedicated high-priority alert, not a general queue.

IOA-3 · K7RKScan-class Vulnerable Driver Load

Pattern: Q13 (hash) and Q14 (filename). Exclusions: hosts with a legitimately licensed K7 Computing product. Deployment: Detect, fleet-wide; route to P1 given BYOVD preceded mass ransomware deployment by roughly two hours in the documented intrusion.

IOA-4 · SYSVOL-Staged Ransomware Execution

Pattern: Q15. Exclusions: none known — SYSVOL is not a normal execution path for arbitrary binaries. Deployment: Detect-first for 7 days, then evaluate promoting toward Prevent for the specific confirmed Warlock SHA256 hashes only (never the generic filename pattern), noting the hash list remains single-sourced per Section 4.

IOA-5 · Broad SharePoint-Worker LOLBin Canary

Pattern: Q17. Exclusions: documented SharePoint timer-job/maintenance scripts. Deployment: Audit/Detect after a 7-day baseline; this is a volume canary, not a precision alert, and should feed a hunting queue rather than paging on its own.

• Telemetry ready: confirm Falcon sensor coverage and ingestion of ProcessRollup2, PeFileWritten/NewExecutableWritten, DriverLoad, CreateService, DnsRequest, and RansomwareOpenFile for every SharePoint farm member and domain controller before enabling any query as an alerting IOA.
• Benign baseline: run every query over the last 30–90 days before enabling. Expect zero or near-zero hits for Q1, Q2, Q8, Q9, Q10, Q13, Q15, Q16; expect some low-volume noise for Q3, Q5, Q6, Q7, Q11, Q12, Q14, Q17 that the stated // TUNING: line must resolve.
• Positive tests: validate detection logic against a lab replay of the documented command lines (e.g. a test PowerShell WriteAllBytes to a non-production LAYOUTS path, a test code-insiders.exe tunnel-service install on an isolated host) before trusting any query in production.
• Promotion criteria: 14 days of clean baseline and zero unresolved false-positive tickets before any IOA moves from Investigate-only to Custom IOA Detect. No query in this pack is promoted to Prevent per Section 9 and Section 4's sourcing policy.

Playbook A · SharePoint ASP.NET Machine Key Rotation

1. Inventory current machineKey values across every web.config in the farm.
   Prerequisites: farm admin rights; maintenance window scheduled.
   Reboot required: no.
   Rollback: keep a secured backup of the pre-rotation web.config files; restore them to revert.

2. Patch SharePoint to the vendor-fixed build for the ToolShell CVEs and the July 2026 flaws
   BEFORE rotating keys, so a freshly-rotated key cannot be re-harvested through the same hole.
   Prerequisites: patch validated in a staging farm; full farm backup taken.
   Reboot required: yes (CU install restarts IIS/SharePoint services; some CUs require a server reboot).
   Rollback: restore from the pre-patch farm backup/snapshot if the CU breaks farm functionality.

3. Generate new validationKey/decryptionKey values with a cryptographically random generator
   and apply via Central Administration > Manage Web Applications > Authentication (or web.config directly).
   Prerequisites: step 2 complete; change-control approval obtained.
   Reboot required: no, but an IIS reset / app-pool recycle is required on every WFE immediately after.
   Rollback: reapply the backed-up web.config from step 1 and recycle app pools again.

4. Recycle every application pool farm-wide to force re-authentication and invalidate any
   outstanding __VIEWSTATE tied to the old key.
   Prerequisites: steps 1-3 complete; user communication sent (active sessions will drop).
   Reboot required: no.
   Rollback: none required; an app-pool recycle is non-destructive and is the expected end state.

5. Verify: re-run Q2 to confirm no further System.Workflow.ComponentModel loads, and confirm
   Get-SPFarm BuildVersion matches the patched baseline.

Playbook B · Vulnerable Driver Blocklist / HVCI Enforcement

1. Audit current HVCI and Microsoft Vulnerable Driver Blocklist state fleet-wide.
   Prerequisites: read access to the Device Guard WMI class; pilot ring identified.
   Reboot required: no (read-only audit).
   Rollback: none required; read-only step.

2. Enable the Vulnerable Driver Blocklist / HVCI, or merge K7RKScan (CVE-2025-1055) into an
   explicit WDAC deny policy for builds where HVCI cannot be enabled.
   Prerequisites: pilot ring validated 1-2 weeks; signed WDAC policy infrastructure in place.
   Reboot required: yes, enabling HVCI requires a reboot to take effect.
   Rollback: disable HVCI via the same policy setting and reboot again; keep the prior
   WDAC policy file archived for rapid rollback.

3. Deploy to the pilot ring; monitor for driver-load failures on legitimate signed drivers
   for 7-14 days.
   Prerequisites: step 2 piloted; alerting on driver-load failures in place.
   Reboot required: yes, per device as it receives the policy.
   Rollback: revert to the previous HVCI/WDAC policy version and reboot affected devices.

4. Roll out fleet-wide in waves, prioritizing SharePoint farm members and domain controllers.
   Prerequisites: pilot clean for 14 days.
   Reboot required: yes, per wave.
   Rollback: same as step 3, per-wave policy rollback and reboot.

Playbook C · Block Unauthorized code-insiders.exe Tunnel-as-a-Service

1. Inventory hosts where VS Code Insiders tunneling is an approved, documented remote-dev
   workflow; everything else is out of policy.
   Prerequisites: application-owner sign-off on the allowlist.
   Reboot required: no.
   Rollback: none required; documentation/inventory step.

2. Create a WDAC or AppLocker deny rule blocking code-insiders.exe execution and service
   creation outside the allowlisted host group.
   Prerequisites: step 1 allowlist finalized; AppLocker/WDAC already in audit mode fleet-wide.
   Reboot required: no (gpupdate/policy refresh is sufficient).
   Rollback: remove or disable the deny rule and run gpupdate /force to restore prior behavior.

3. Deploy in Audit mode fleet-wide for 7 days, review the audit log for unexpected
   legitimate hits, then flip to Enforce.
   Prerequisites: step 2 rule authored; SIEM/Falcon ingesting AppLocker/WDAC audit events.
   Reboot required: no.
   Rollback: flip the policy back to Audit mode (or disabled) and run gpupdate /force;
   no device-state change to undo.

Playbook D · Restricted Groups Lockdown for Local Administrators

1. Baseline current local Administrators membership fleet-wide; flag any account matching
   the SPS*/SP*Setup masquerade naming pattern or not on the documented approved list.
   Prerequisites: read access to local group membership (Falcon RTR, GPO reporting, or LAPS).
   Reboot required: no.
   Rollback: none required; read-only baseline.

2. Configure a Restricted Groups GPO enforcing the approved membership list, scoped first
   to the SharePoint farm and Tier 0/1 OU.
   Prerequisites: step 1 baseline reviewed and approved; GPO tested in a lab OU.
   Reboot required: no, a policy refresh (gpupdate /force) applies it.
   Rollback: unlink or disable the GPO and run gpupdate /force. Note: already-removed
   accounts are not automatically restored; re-add manually if a removal was a false positive.

3. Expand the GPO scope fleet-wide once validated on the pilot OU for 7-14 days with no
   unexpected removals.
   Prerequisites: step 2 clean on pilot.
   Reboot required: no.
   Rollback: scope the GPO link back down or disable it, same as step 2.

Validation gates for every query above are detailed in Section 11; no query ships without a stated benign-baseline and promotion path.