Warlock’s nine-day SharePoint intrusion, and the dark-web trail behind it

from the first web shell to ransomware

9 days

hosts with protection disabled in about two hours

≥ 40

leak-site listings in our collection, 27 marked as sold

78

new listings since 26 January 2026, while the intrusions continued

0

On 1 October 2026, Symantec and Carbon Black published the most detailed account yet of a Warlock intrusion: a critical-infrastructure operator whose SharePoint servers were compromised on 22 July and whose estate was running ransomware nine days later. BleepingComputer carried the story the next day. This analysis adds what those reports do not have — the group’s own leak-site record, the underground forums that track it, and FireIntel’s actor profile — and turns the July chronology into an ATT&CK mapping, hunting queries and machine-readable indicators.

Nine days, host by host

The first recorded malicious act came on 22 July 2026, when PowerShell wrote a web shell named layout2sp.aspx into the SharePoint LAYOUTS directory. The group writes its shell into the folders of several SharePoint versions at once, so it runs whichever version is installed; its job is to harvest the farm’s ASP.NET machine keys, which let the attackers forge a validly signed payload and run code inside the SharePoint application pool.

The pace is patient, then sudden. Reconnaissance and DLL side-loading on 24 July were followed by two silent days. On 27 July an out-of-band request to oastify.com — Burp Collaborator, with the victim’s own domain baked into the subdomain — confirmed that injected code had run. On 28 July a deserialization gadget turned a forged __VIEWSTATE into code execution, and three MSI packages arrived from public file hosts within ninety minutes. Over the next day a look-alike account, SPSEPRDSetup, joined local Administrators on three more hosts; VS Code Insiders was installed as a tunnel service; and NetExec mapped Active Directory and sprayed passwords.

Then, in the early hours of 31 July, an AV/EDR killer copied from an internal share ran on at least 40 hosts in about two hours, and Warlock — run.exe, rune.exe and a note called “how to restore your files.txt” — appeared on at least 33. The payload had been staged in SYSVOL, which replicates to every domain controller: on three hosts the DFS Replication service itself was recorded delivering it.

What the dark web shows

We queried FireIntel’s DDW Advance collection for Warlock across ransomware leak sites and underground forums on 3 October 2026. The leak-site search returns 78 listings. Each record carries the leak site’s own date for the listing separately from the date it was collected, and we checked both: the listings are dated 28 July 2025 to 26 January 2026, while collection ran well into 2026. In every capture below, victim names are covered with fixed-width bars so that not even their length gives anything away; a domain suffix such as .ru or .local is left visible where it carries analytic value, and onion addresses are withheld.

Source: FireIntel DDW Advance · captured 3 Oct 2026Open full image ↗

Read the listings rather than counting them and the operators’ business model surfaces. Each carries a short status line written by the operators themselves, and four kinds recur:

• “The data has been bought by other buyers (not victims)” — 25 listings, plus two worded “purchased by other buyers”: 27 sales in all, every one dated July or August 2025.
• “The customer has not paid, and there are no other buyers within the validity period” — the data is then published for anyone to take. Two listings.
• Partial leaks offered as samples, with the full set “to be purchased separately” — one of them advertised as an auction of a million documents.
• The rest give only a data volume or “all data”, with no status at all.

Source: FireIntel DDW Advance · selected listingsOpen full image ↗

Sophos counted the same number of sales, 27, by mid-September 2025. Neither collection names the buyers, so we cannot confirm the two counts cover identical listings, but the agreement is strong. The more telling signal is that the sales stop after August: either buyers dried up or the operators stopped advertising sales in public. What the status lines do show is the leverage. A victim who refuses to pay does not get its data back unpublished — it goes to the highest bidder or, failing one, to everyone.

Two smaller details deserve attention. Six listings are named after internal Active Directory domains ending in .local or .home rather than public websites — a sign the operators named those victims from inside the network, most likely from a domain controller. And the public domains span at least ten country codes: Australia, Bolivia, Canada, Czechia, Japan, Russia, Taiwan, the UAE, the United Kingdom and the United States. That breadth matches the geography researchers reported in 2025; the 2026 cluster of Portuguese- and Spanish-speaking victims that Symantec describes is not visible on a leak site that has been silent since January.

What the forums say

Underground forums keep their own score. On 31 January 2026, a user on a forum presenting itself as a relaunch of XSS answered a question about which ransomware groups were still active with a tracker table pasted as plain text: each group’s first and last victim, its victim counts over 7, 30 and 90 days, and whether its site was up. We have set the relevant rows out below.

Source: FireIntel DDW Advance · forum excerptOpen full image ↗

By the tracker’s numbers, Warlock was a small operator at the end of January: eight victims in 90 days and none in the last 30, against 145 for Clop and 79 for LockBit 5. But the tracker had missed something. It puts Warlock’s last victim at 6 November 2025, while the leak site itself dated 17 listings in January 2026, the latest on 26 January — five days before the post. Secondary trackers lag the sites they count. Its first-victim date, 2 April 2025, two months before Warlock’s public debut, is a second reason to treat it as a lead rather than a record.

Eighteen months of Warlock activity

Laid end to end, the record shows an operation that went public fast. Warlock announced itself in June 2025, was exploiting the ToolShell zero-days within six weeks, and had a working leak site by late July. Our first listing is dated 28 July 2025; by the end of September there were 61, against the 60 that Sophos counted by mid-September.

Then the record thins. Our collection holds no listings dated October to December 2025, although the forum tracker recorded a Warlock victim on 6 November — so this is leak-site downtime or a gap in collection, not a proven pause. Seventeen listings are dated January 2026, and none since. The intrusions did not stop: Trend Micro documented one in January 2026, ReliaQuest another in February, Symantec the July case. Whatever the reason — new infrastructure, more private sales, or victims settling quietly — the leak site is no longer a reliable gauge of Warlock’s tempo.

Not only SharePoint

The front door is whichever internet-facing Windows application is behind on patches. On 29 January 2026, Warlock breached SmarterTools, the company that makes the SmarterMail mail server, through a SmarterMail virtual machine an employee had set up and nobody was updating. On 9 February, ReliaQuest attributed SmarterMail exploitation it had observed to Storm-2603 with moderate-to-high confidence: an authentication bypass, CVE-2026-23760, chained with the product’s own Volume Mount feature to run commands as the mail service, pull an MSI from Supabase and install Velociraptor as a backdoor. No ransomware was deployed in the case it describes; the staging matched earlier Warlock intrusions step for step.

The research travelled. Within weeks it was being retold, in Russian, on underground forums we collect from. Forum audiences read vendor research closely: the write-up that helps defenders patch also tells other crews which servers are worth scanning for.

Source: FireIntel DDW Advance · captured 3 Oct 2026Open full image ↗

Who is behind Warlock

Symantec calls the actor Longlegs and treats it as the group Microsoft tracks as Storm-2603. Microsoft assesses Storm-2603 as China-based with moderate confidence and has found no link to the separately tracked Linen Typhoon or Violet Typhoon. Unit 42 assesses with high confidence that its CL-CRI-1040 cluster is the same actor, while stating it cannot attribute the cluster to any nation-state. Sophos tracks the operator as GOLD SALEM and dates Warlock’s public debut to 10 June 2025, on the RAMP forum.

The lineage is older than the brand. Symantec has traced a stolen code-signing certificate used by Warlock operators back to the CamoFei and ChamelGang clusters, active since at least 2019. Unit 42 found an affiliate account called “wlteaml” in leaked LockBit 3.0 panel data, registered in April 2025 and sharing a Tox ID with AK47 ransom notes, and Check Point documented the group running LockBit Black alongside Warlock. The older “Warlock Dark Army” ransomware is unrelated.

The actor profile in our collection

FireIntel’s profile of the group records Warlock from 10 June 2025 — the day Sophos dates its RAMP debut and first leak site — and summarises the attribution picture: Storm-2603, a history with LockBit, and an overlap in victims with Black Basta, read as an “old affiliate” that went on to build its own encryptor. All four known sites, three leak-site addresses under the “Client Data Leak Show” name and a file portal, are reported offline.

Source: FireIntel Threat actors · captured 3 Oct 2026Open full image ↗

A profile summary is an analysis, and we weigh it like any other source. Its Storm-2603 and LockBit links match Microsoft’s and Unit 42’s reporting; the Black Basta victim overlap is not established by the research cited here, so we carry it as a lead. The same discipline applies to the tooling the profile data associates with the group. The table separates what independent reporting corroborates from what it does not.

The rotation matters more than any single name on that list. Blocking one driver buys little; enforcing Microsoft’s vulnerable driver blocklist with memory integrity (HVCI) turned on, and alerting on any new kernel driver load on servers, closes the class.

Detection and response

Each technique below is tied to an artefact in the published telemetry for the July intrusion, not inferred from the group’s wider reputation. Where the report stops short — the exact CVE, the driver behind the AV/EDR killer — the mapping stops short too.

For on-premises SharePoint, Microsoft’s guidance is current patches, AMSI integration in Full Mode, Defender or an equivalent on every SharePoint server, then a machine-key rotation and an IIS restart. CISA’s July 2026 alert adds the order that matters: if compromise is suspected, find and remove web shells and machine-key harvesters before rotating keys, or the attacker simply reads the new ones. For SmarterMail, ReliaQuest’s advice is build 9511 or later and strict isolation of mail servers. Patching closes the door; it does not evict anyone already inside.

For Microsoft Defender XDR, the advanced-hunting queries below turn those signals into searches. Each was checked with Microsoft’s Kusto language parser against the Defender table schema; none has been run against live telemetry for this post, so they are deliberately broad — expect to tune out your own administration tooling before alerting on them.

DeviceFileEvents
| where Timestamp > ago(30d)
| where FolderPath has @"\web server extensions\" and FolderPath has @"\template\layouts\"
| where FileName endswith ".aspx"
| project Timestamp, DeviceName, FolderPath, FileName,
          InitiatingProcessFileName, InitiatingProcessCommandLine

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName in~ ("w3wp.exe", "MailService.exe")
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "nltest.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName,
          ProcessCommandLine, InitiatingProcessCommandLine

DeviceProcessEvents
| where Timestamp > ago(30d)
| where (FileName in~ ("code.exe", "code-insiders.exe")
         and ProcessCommandLine has_all ("tunnel", "service", "install"))
    or (FileName =~ "msiexec.exe"
         and ProcessCommandLine has_any ("catbox.moe", "wasabisys.com", "supabase.co"))
    or (InitiatingProcessFileName =~ "dfsrs.exe" and FileName endswith ".exe")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessFileName

• Take SharePoint and mail servers off the open internet where you can. If they must stay reachable, put them behind an authenticated layer-7 proxy and block external access to SharePoint Central Administration.
• Hunt before you rotate: web shells, machine-key harvesters and unexpected ASPX files first, then new machine keys and an IIS restart on every server in the farm.
• Review local Administrators membership on SharePoint and adjacent servers against a known-good baseline, and alert on changes.
• Treat the 31 July pattern — one share copied to dozens of hosts in minutes — as a tripwire. Mass execution of the same binary from C:\Users\Public is rarely legitimate.

Indicators

The primary report’s IOC appendix lists 19 SHA-256 hashes: five Warlock payloads, six malicious DLLs, six suspicious files, one AV/EDR killer and one vulnerable driver. They are reproduced below under the source’s own classifications. This is a report-wide set rather than a list of files from the 22–31 July case, and the report does not map every hash to a filename. A match warrants investigation; a non-match clears nothing, because this group changes tooling.

Method, confidence and limits

The July chronology, host counts and IOC appendix come from Symantec and Carbon Black; the SmarterMail activity and its indicators from ReliaQuest; actor naming and history from Microsoft, Unit 42, Sophos, Check Point, Trend Micro and Symantec’s earlier research. Each is cited where it is used, and every indicator was checked against its source. Leak-site and forum figures come from FireIntel’s DDW Advance collection as queried on 3 October 2026; listings are dated by the leak site, counted as claims rather than confirmed victims, and the collection can have gaps.

Confidence follows common intelligence practice. High confidence means the judgment rests on direct observation in our collection or on several independent sources that agree. Moderate means the evidence is credible but incomplete, or comes from a single source. Low means the judgment is plausible but thinly supported. “No assessment” means we lack an independent basis to judge.

The diagrams are analyst reconstructions. Screenshots were captured from the FireIntel console on 3 October 2026 and redacted before publication: victim names are covered with fixed-width bars and onion addresses are withheld. Beyond choosing which listings to show and highlighting the Warlock row of the forum tracker, nothing in them was altered. No unnamed victim in the Symantec report is identified here.