Warlock ransomware SYSVOL: How SharePoint Access Became Domain-Wide Spread

Warlock ransomware SYSVOL is the detail that makes a new Symantec investigation more revealing than another warning about unpatched SharePoint servers. In an intrusion against a critical infrastructure organization, attackers used compromised SharePoint access to move through the environment, disabled security software on at least 40 hosts in roughly two hours, and then deployed Warlock ransomware on at least 33 hosts. The sequence shows how an internet-facing application can become the starting point for a much broader Windows domain compromise.

Warlock is still using SharePoint as the front door

Symantec's Threat Hunter Team reported on October 1 that the group behind Warlock, which Symantec calls Longlegs and Microsoft tracks as Storm-2603, had attacked at least four organizations during the previous two months. The victims included a water utility, a telecommunications provider, a regional government body and a university across Europe, Africa and Latin America, with the recent activity concentrated in Portuguese- and Spanish-speaking countries. The common starting point was on-premises Microsoft SharePoint Server, rather than SharePoint Online in Microsoft 365. That distinction matters because the exposed server is directly connected to an organization's internal identity, documents and Windows infrastructure.

Warlock first became known in 2025 when attackers exploited a group of SharePoint vulnerabilities known collectively as ToolShell. Microsoft documented Storm-2603 using those vulnerabilities to deploy ransomware after compromising internet-facing SharePoint servers, and Microsoft specifically distinguished the affected on-premises product from SharePoint Online. The original ToolShell set included CVE-2025-49704, CVE-2025-49706, CVE-2025-53770 and CVE-2025-53771. Symantec's new investigation indicates that the group continues to rely on SharePoint weaknesses while also potentially incorporating newer flaws disclosed during 2026.

The first foothold is only the beginning of the attack

Once inside a vulnerable SharePoint server, the attackers did not immediately encrypt everything they could reach. Symantec observed a web shell, which is a small malicious component placed on a web server to provide attackers with persistent remote control, followed by reconnaissance and additional tooling. The investigation describes the attackers obtaining ASP.NET machine keys from the SharePoint environment and using them to create signed payloads capable of executing code inside the SharePoint application process. This turns a vulnerable web application into a platform from which the attackers can continue operating inside the victim's environment.

That progression also explains why patching the original entry point is not the same thing as proving that an organization is clean. Microsoft documented the same broader pattern during the 2025 SharePoint attacks: initial exploitation was followed by discovery, persistence, credential access and movement through the Windows environment before ransomware deployment. Microsoft recommended security updates, rotating SharePoint ASP.NET machine keys, restarting Internet Information Services and checking defensive controls after compromise. In other words, administrators have to treat a successfully exploited SharePoint server as an incident to investigate, not merely as a machine waiting for the next update.

Why the attackers used ordinary administration tools

Symantec's evidence shows a deliberate effort to make later stages resemble legitimate administration. The attackers used standard Windows utilities for reconnaissance, employed dynamic-link library (DLL) sideloading to load malicious code through legitimate-looking software components, and used other trusted tools rather than relying entirely on custom malware. They also abused the tunneling capability built into Visual Studio Code to establish remote access that could resemble traffic from developer or administrator machines. The practical problem for defenders is that an alert based only on the presence of these tools can produce noise because the same programs have legitimate uses.

Another technique involved bring your own vulnerable driver, usually abbreviated BYOVD. The idea is simple: instead of developing a kernel-level component from scratch, an attacker abuses a legitimately signed driver that contains a known weakness to interfere with security software. Symantec linked Longlegs to the K7RKScan driver, which has been associated with CVE-2025-1055, and reported its use to terminate protected security processes in recent attacks. The July intrusion described in the new report recorded a security-software disabling tool across at least 40 hosts, although Symantec notes that the exact vulnerable driver used in that particular stage was not identified.

SYSVOL turned the Windows domain into a delivery system

The most consequential part of the intrusion came after the attackers had weakened endpoint defenses. SYSVOL is a special shared folder used by Windows Active Directory domains to distribute files needed by domain controllers and Group Policy operations. Because its contents are replicated between domain controllers, an attacker who abuses it can use the domain's own replication mechanisms as part of a malware-distribution chain. Symantec observed Warlock binaries staged in SYSVOL before they appeared on at least 33 hosts.

This is different from simply copying ransomware to dozens of computers one at a time. The attacker first gets into the infrastructure that already has permission to replicate domain data, then uses that infrastructure as part of the distribution process. Symantec's investigation recorded the Windows Distributed File System Replication service, which handles SYSVOL replication between domain controllers, associated with delivery of the ransomware files to additional machines. The result is a multiplication effect: one compromised administrative layer can help move the payload across a much larger portion of the organization.

The timing shows why defense evasion matters

The numbers from the intrusion are revealing because the attackers did not spend days moving ransomware manually from computer to computer. Symantec observed the security-software disabling activity on at least 40 hosts within about two hours, followed by Warlock appearing on at least 33 hosts. That puts the transition from weakened defenses to ransomware deployment on a much shorter operational timeline than a traditional incident in which every endpoint must be individually compromised. For defenders, the important signal is therefore not only the final ransom note but the coordinated change in security controls that precedes it.

The sequence also shows why endpoint protection alone cannot carry the entire response. If an attacker can first compromise a public-facing application, establish persistence, obtain credentials or other trust material, and then disable security controls, the endpoint product is being attacked after the adversary has already built several layers of access. Microsoft's earlier investigation into Storm-2603 documented credential access and lateral movement after SharePoint exploitation, including abuse of Windows administration mechanisms before Group Policy was used to distribute ransomware. The newer Symantec case shows the same general progression from application compromise to domain-wide impact, but with a particularly clear SYSVOL distribution stage.

What SharePoint administrators should check now

Organizations running on-premises SharePoint should start with the basics: confirm that supported SharePoint Server installations have the relevant security updates, verify that internet exposure is intentional, and check whether security monitoring is functioning on the servers. Microsoft previously recommended enabling Antimalware Scan Interface (AMSI) in Full Mode and using Microsoft Defender Antivirus or an equivalent security product on SharePoint servers. After a known or suspected compromise, Microsoft also recommended rotating ASP.NET machine keys and restarting Internet Information Services. Those measures address both the vulnerable entry point and the possibility that attackers already established persistence.

The second layer is investigation rather than patching. Security teams should review unexpected web shells and changes within SharePoint directories, unusual administrative-account additions, suspicious use of trusted remote-access or developer tooling, and security products being disabled across multiple machines in a short period. SYSVOL deserves particular attention because unexpected executable files or unauthorized changes there can indicate that an attacker is attempting to use domain replication as a distribution mechanism. These checks are especially relevant when a SharePoint server was exposed to the internet during the period in which the relevant vulnerabilities were being actively exploited.

The bigger warning is about trust inside the Windows domain

The new Warlock cases are not simply another reminder to patch SharePoint. They show how an application server can become the first step in an attack that eventually abuses the trust relationships and administrative infrastructure underneath an organization. SharePoint sits close to identity, Windows services and business data, so a successful compromise can give attackers opportunities far beyond the original web application. The fact that recent victims include a water utility and a telecommunications provider makes that distinction particularly relevant for organizations whose IT systems support essential services.

For security teams, the useful question is no longer only whether the SharePoint server is patched. It is whether the organization can detect what happens after a SharePoint server is breached: machine-key access, unexpected web shells, unusual administrator activity, security controls being disabled, suspicious tunneling and changes to domain-replicated content. Warlock's recent activity shows that attackers can combine those behaviors into one chain and then let existing Windows infrastructure help carry the ransomware farther. The next defensive step is therefore to test those detection points before an exposed SharePoint server becomes the first computer in a much larger incident.