Warlock Reached Water and Telecom Operators
Water and telecommunications operators were among at least four unnamed organisations attacked by the group behind Warlock ransomware in the two months covered by Symantec’s 1 October report. A regional government body and a university were also affected. The victims were in Portuguese- and Spanish-speaking countries across Europe, Africa and Latin America.
Symantec tracks the group as Longlegs, also known as Storm-2603, and assesses a China nexus. That attribution does not establish state direction of these particular attacks. The report does not name the victims or establish that water treatment or telecommunications services were interrupted.
A SharePoint foothold became a domain-wide problem
In one critical-infrastructure intrusion, the first observed web shell appeared on a SharePoint server on 22 July. The researchers considered SharePoint exploitation the likely entry route. They did not identify the specific vulnerability used in that case.
The chronology then follows reconnaissance, DLL sideloading and machine-key abuse through to the final deployment on 31 July. Stolen ASP.NET machine keys can let an attacker produce payloads that SharePoint accepts as trusted, turning possession of a secret into another route to code execution.
The attackers added an account to local Administrators groups on further hosts, installed Visual Studio Code Insiders tunnelling as a service, and used NetExec while moving through the domain. Legitimate software and cloud services therefore formed part of the intrusion. A signed executable or familiar outbound destination would not, by itself, establish that the activity was authorised.
In the final phase, security-disabling tooling reached at least 40 hosts within about two hours. Warlock binaries and a ransom note were recorded on at least 33 hosts. The researchers suspected a vulnerable driver, but its identity remained unknown in this intrusion. Their observation of K7RKScan in other recent attacks does not identify this case’s driver.
Ransomware files were staged in SYSVOL. Evidence from three further hosts showed the replication service delivering those files through normal domain replication. Delivery establishes how the files arrived; it does not, by itself, prove execution on those three hosts. The host counts describe the investigated organisation, not every victim in the campaign.
Recovery has to cover the farm and the identities around it
Update, 31 October 2026: The current CISA SharePoint alert, last revised on 26 August, remains relevant to recovery. It is broader hardening guidance, not confirmation of the entry flaw in Symantec’s case.
- Avoid exposing SharePoint directly to the internet. Where exposure is unavoidable, CISA calls for an application-layer control that authenticates, inspects and filters inbound requests.
- Apply current Microsoft security updates and verify successful installation across the farm. Completion on one server is not evidence that every server is protected.
- Verify Antimalware Scan Interface integration for every web application. Select Full Mode for request-body scanning where feasible, respecting the supported edition and configuration.
- Hunt for and remediate intrusion artefacts, including machine-key harvesters, before rotating IIS machine keys. Otherwise, an attacker may obtain the replacement secrets as well.
- Check logging, suspicious worker-process activity and machine-key access. Restrict Central Administration and farm/database communications to the systems that need them.
Use the key procedure supported by the deployed edition
Microsoft’s key-management procedure, updated on 9 September 2025, applies to SharePoint Server 2016, 2019 and Subscription Edition. It does not apply to SharePoint 2013 or SharePoint in Microsoft 365. Automatic rotation is available from Subscription Edition 25H1 and the September 2025 public update for 2016 and 2019.
The distinction between a local change and farm-wide distribution matters. The manual -Local option updates only the local server. Other servers retain the previous keys, and load-balanced web sessions can fail if the keys are not synchronised. Confirm the edition, installed update and distribution scope together rather than inferring complete recovery from one successful command.
BlackTree’s earlier machine-key analysis explains the wider recovery problem: changing vulnerable code does not revoke secrets already copied by an intruder. Here, that context supports investigating the farm and its identities. It does not supply an unproven vulnerability attribution for Warlock’s entry route.
