Ransomware Attacks Expose Vulnerability in Security Tool Reliance

“Roughly 40 hosts in 120 minutes averages out to one machine losing its protection every three minutes.”

Storm-2603 (Warlock) and the reported victims

On Oct. 1, threat researchers reported that a China-linked group behind Warlock ransomware — which Microsoft tracks as Storm-2603 — had attacked at least four organizations in the prior two months. The victims included a water utility, a telecommunications provider, a regional government body and a university, located in Portuguese- and Spanish-speaking countries across Europe, Africa and Latin America. The researchers say the likely entry point was on-premises Microsoft SharePoint.

Initial foothold: SharePoint, ToolShell, and old patches

Researchers believe the group still carried ToolShell flaws it exploited in July 2025 — the same month Microsoft shipped fixes — alongside newer SharePoint flaws. The report notes that an exploit for a bug patched more than a year earlier remained useful to the attackers: somewhere, a server was still waiting for its fix.

The intrusion timeline: web shell to domain control in nine days

The researchers reconstructed one intrusion against a critical infrastructure operator in detail. On July 22 attackers planted a web shell on a SharePoint server. Over the following week they mapped the domain, established covert remote access and added an account — apparently named to pass as a SharePoint service account — to local administrator groups. For about a day the only recorded activity was a single piece of planted code running in the background. Nine days after initial access, in the early hours of July 31, the adversary executed the move that mattered.

The kill step: disabling security and SYSVOL staging

First came a tool built to disable security software; its execution was recorded on at least 40 hosts within about two hours. The attackers then staged Warlock in the domain’s SYSVOL share — a folder Windows replicates to every domain controller and makes readable across the domain — and let ordinary replication carry it to at least 33 hosts. On each of those machines, the ransomware appeared almost as soon as protection was gone. The arithmetic is blunt: taking protections offline at a pace of 40 hosts in 120 minutes equates to roughly one machine losing protection every three minutes. In short, the adversary targeted the tools watching the data before they targeted the data itself.

What this means for utilities, boards, and security budgets

• Utilities: The report highlights that thinly staffed utilities are especially exposed. The Congressional Research Service noted in August that 81% of the nearly 49,500 community water systems in the United States are classified as small, serving 3,300 people or fewer — and larger systems have more capacity to hire security specialists. That translates into more hours when nobody is watching for smaller systems.
• Boards: The author urges boards to treat a control that an attacker can switch off as impaired. “Accountants would call it an impairment,” the piece says, and recommends an audit-style question: what still holds once monitoring stops? If the protections that do not require a live sensor are absent, that gap should be recorded in the risk register and discussed at the board level rather than discovered in an incident report.
• Security budgets and procurement leaders: Management is asked to split the security budget into two piles — protections that depend on a sensor and a responder, and protections that make decisions on the machine without waiting on a console or a person. The share of the first pile that would not survive a night when sensors can be disabled is, in effect, an impairment to be budgeted and managed.

Prevention that does not wait for a sensor: memory controls and timing

The report emphasizes timing as the decisive factor. The kill step here came after nine days inside; to reach that point attackers had to exploit a server, load code into memory through sideloading and escalate rights across the domain — each a chance to stop them. One defensive approach described works in memory: change the layout of applications every time they load so code that relies on expected memory layouts will fail when it runs. That decision and enforcement happen on the machine itself, and therefore do not depend on a cloud connection, a console, or an analyst staying awake.

The broader point is operational: tamper protection and blocking known vulnerable drivers should be switched on everywhere because controls the adversary can flip are worth far less than their line item suggests. Most detection spending depends on a sequence of things going right at the worst possible moment — a sensor surviving, a console receiving telemetry and a person reading an alert in time. Take away the sensor and the rest has nothing to work with.

Forty machines went dark in two hours. Budget for the attacker who brings a switch — and, before writing another purchase order, ask whether the purchase still protects the machine when the lights go out.

The post first appeared on CyberScoop. Read the original CyberScoop piece.