Warlock Staged Its Ransomware in SYSVOL, and the SharePoint Patch Did Not Evict It

SYSVOL is a shared folder that sits on every domain controller in an Active Directory domain. Group Policy keeps its scripts and templates there, Active Directory copies its contents to every other domain controller automatically, and every domain-joined computer can read it. That design is the whole point: it is how a policy written once reaches a thousand machines without anyone touching them. In at least one intrusion this year, it is also how ransomware reached 33 of them.

Symantec's Threat Hunter Team published the account on October 2. The group it tracks as Longlegs, which Microsoft calls Storm-2603, entered a water utility through an unpatched on-premises SharePoint server, spent nine days inside, pushed a tool that kills security software to at least 40 hosts in about two hours, then staged the Warlock ransomware binaries in SYSVOL and let the domain carry them the rest of the way. Four organisations in Portuguese-speaking and Spanish-speaking countries across Europe, Africa and Latin America have been hit in the past two months: the water utility, a telecommunications provider, a regional government body and a university.

Who owns this, and who can close the tab

The way in belongs to a specific and shrinking population. Longlegs enters through ToolShell, the SharePoint exploit chain made up of CVE-2025-49704, CVE-2025-49706, CVE-2025-53770 and CVE-2025-53771. All four are on-premises SharePoint Server bugs from July 2025. If your intranet runs on SharePoint Online or anything else hosted, that entry point is closed and you can stop reading here. Three of the four sit in CISA's Known Exploited Vulnerabilities catalogue with the known-ransomware flag set, and their federal remediation deadline was a single day in July 2025. Fifteen months later the group is still finding servers.

The second half of the intrusion belongs to almost everyone. If you run an Active Directory domain of any size, you have a SYSVOL share, it replicates, and your workstations read it on every policy refresh. The delivery mechanism does not care how the attacker got in. Any foothold that reaches Domain Admin reaches SYSVOL, and an unpatched SharePoint box is one of a hundred routes to Domain Admin. For an owner reading this, the question worth asking is whether anyone in your organisation would notice a new program appearing in the folder your server copies to every computer in the building. In most small environments nobody would, because nobody has ever looked.

The intrusion, in the order it happened

Symantec's timeline covers nine days from first access to encryption. That window is the part worth studying, because every hour of it was a chance to catch the intrusion with telemetry most organisations already generate.

• July 22 - a webshell is written into the SharePoint LAYOUTS directory, the standard ToolShell landing spot.
• July 24 - reconnaissance using nothing but built-in Windows commands: net, whoami, nltest.
• July 27 - an out-of-band callback test through Burp Collaborator, confirming the server can reach the internet.
• July 28 - the exploitation chain is run in full.
• July 31 - the security-software killer goes to 40 or more hosts in roughly two hours, then Warlock lands on 33 or more.

In between, the group used NetExec (nxc.exe) for directory enumeration, credential spraying and remote command execution, hosted payloads on catbox[.]moe and wasabisys[.]com, and ran the ransomware as run.exe and rune.exe, leaving a note named how to restore your files.txt. The tool that disabled endpoint protection loaded K7RKScan, a signed kernel driver tracked as CVE-2025-1055. For persistence they installed Microsoft's own code-insiders.exe as a Windows service and turned on the Visual Studio Code tunnel feature.

The patch does not take the keys back

Here is the detail most of this week's coverage dropped, and it is the one that decides whether a patched server is actually clean. ToolShell's payoff is the server's ASP.NET machine keys. Microsoft's customer guidance for CVE-2025-53770 said so in July 2025: once an attacker holds the validation and decryption keys, they forge a signed __VIEWSTATE payload that SharePoint accepts as its own, and that payload executes code. Install the update, delete the webshell, reboot, and a forged ViewState still works. The keys are what has to change.

Microsoft shipped cmdlets for exactly this in KB5001974 and its 2016 counterpart. Set-SPMachineKey generates a new pair and Update-SPMachineKey deploys it across the farm. An IIS restart is required afterwards, because the old keys stay resident in worker-process memory until the pool recycles.

# SharePoint Management Shell, run on one server in the farm.
Get-SPWebApplication | ForEach-Object {
    Set-SPMachineKey    -WebApplication $_.Url -Confirm:$false
    Update-SPMachineKey -WebApplication $_.Url -Confirm:$false
}

# Then on every server in the farm, so no worker process keeps the old keys.
iisreset.exe /noforce

A large farm runs this behind change control, in a maintenance window, after confirming that no custom web part pins a key value in web.config. A two-server farm runs it on a Sunday morning and tests one form afterwards. The procedure is the same and the cost difference is an afternoon of paperwork. On SharePoint Server Subscription Edition, the Machine Key Rotation timer job in Central Administration does the same work from the browser.

SYSVOL is a software deployment channel you never configured

MITRE catalogues the technique as Group Policy modification, T1484.001, and Microsoft recorded Storm-2603 editing GPOs to distribute Warlock during the original July 2025 wave. The pairing matters: a policy edit points thousands of machines at a file, and SYSVOL is where that file sits.

Large security teams handle this by treating SYSVOL as production code. File integrity monitoring watches the share, GPO change auditing feeds the SIEM, and a change-control process governs who may edit a policy at all. That stack costs real money and a person to run it, which is why small organisations skip it entirely and end up with no record of what their most trusted folder contains.

The right-sized version is two questions and one command. Who can write to the policy tree, and what is in it today?

# Run from a domain-joined host as any domain user.
$sysvol = "\\$env:USERDNSDOMAIN\SYSVOL\$env:USERDNSDOMAIN"

# 1. Write access to the policy tree, beyond the groups you expect.
(Get-Acl "$sysvol\Policies").Access |
  Where-Object {
    $_.FileSystemRights -match 'Write|Modify|FullControl' -and
    $_.IdentityReference -notmatch 'SYSTEM|Domain Admins|Enterprise Admins|Administrators|CREATOR OWNER'
  } | Format-Table IdentityReference, FileSystemRights, AccessControlType

# 2. Every executable and archive under SYSVOL, hashed and dated.
Get-ChildItem $sysvol -Recurse -File -ErrorAction SilentlyContinue `
    -Include *.exe,*.dll,*.ps1,*.bat,*.cmd,*.vbs,*.zip,*.7z |
  Select-Object FullName, Length, LastWriteTime,
    @{n='SHA256';e={(Get-FileHash $_.FullName -Algorithm SHA256).Hash}} |
  Sort-Object LastWriteTime -Descending |
  Export-Csv .\sysvol-baseline.csv -NoTypeInformation

Reading the output

A healthy domain returns a short list on both counts. On the first query, anything outside the built-in administrative groups deserves an explanation; a service account or a help-desk group with Modify on Policies is a path from a stolen password to domain-wide code execution. On the second, most well-kept domains hold a handful of logon scripts and nothing else. I have yet to see a small environment where the inventory did not turn up at least one abandoned installer that nobody could account for.

Delete what nobody owns, keep the CSV, and re-run it weekly. The baseline is the control. A new signed executable appearing in SYSVOL on a Tuesday afternoon is either a change somebody made on purpose, in which case they can tell you about it in thirty seconds, or it is the last quiet step before encryption.

Two more controls that cost nothing

A Microsoft-signed tunnel is still a tunnel

The persistence in this campaign ran as code-insiders.exe tunnel service install --accept-server-license-terms. The binary is signed by Microsoft, the traffic leaves over HTTPS to Microsoft-operated relay infrastructure, and a responder scanning a process list sees a developer tool. Visual Studio Code's tunnel documentation describes the feature plainly, including the service install and the hostnames it uses. If nobody in your organisation writes software, there is no reason for that traffic to exist, and your DNS resolver can say no.

# Sysmon process creation, last 7 days.
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-Sysmon/Operational'
    Id        = 1
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'code(-insiders)?\.exe.*tunnel' } |
  Select-Object TimeCreated, MachineName, Message

# No Sysmon? Service installs land in the System log as 7045.
Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 7045
    StartTime = (Get-Date).AddDays(-30)
} -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'tunnel|code-insiders' } |
  Select-Object TimeCreated, MachineName, Message

Turn on the driver blocklist you already own

The tool that cleared the way for Warlock worked by loading a vulnerable signed driver. Microsoft ships a recommended driver blocklist with Windows, and on many builds it is present but not enforced until someone enables it. Enabling it is free and it blocks the drivers Microsoft has catalogued, which is worth more than nothing and less than real tamper protection on your endpoint agent. Check whether yours is switched on, and check whether its tamper protection survives a local administrator.

Rotate the machine keys before you close the ticket

If you run on-premises SharePoint Server and you installed the July 2025 updates without rotating machine keys, treat that server as still reachable until you have proven otherwise. That is the highest-value hour anywhere in this article, and the cmdlets above are the whole job. Then pull the SYSVOL inventory, because it costs one command and it is the one check that would have caught the final step of this intrusion while 33 machines were still running.

For an owner, the version to hand your IT provider is three questions. Have our machine keys been rotated since the SharePoint patch? Who can write to SYSVOL? What is in it right now? If the answers take longer than a day to produce, that gap is the finding, and it is worth more attention than the ransomware headline that brought you here. We build and test incident response playbooks for organisations without a security team on staff, and the SYSVOL baseline is in every one of them.