A China-linked ransomware crew disabled the security tools at a critical infrastructure operator before it launched the encryptor. Most security budgets never priced that in.
The post What happens when security tools go dark before the ransomware appeared first on CyberScoop.
On Oct. 1, threat researchers reported that the China-linked group behind Warlock ransomware, which Microsoft tracks as Storm-2603, had attacked at least four organizations in the prior two months. A water utility and a telecommunications provider were among them, along with a regional government body and a university. This all occurred in Portuguese- and Spanish-speaking countries across Europe, Africa and Latin America.
The likely way in was on-premises Microsoft SharePoint. The researchers believe the group still carries the ToolShell flaws it exploited in July 2025, the same month Microsoft shipped the fixes, alongside newer SharePoint flaws. An exploit for a bug patched more than a year ago is still worth packing. Somewhere, a server is still waiting for its fix.
Before I ran a security company, I ran its finances. The habit I kept is reading the assumption under every number. Equipment is expected to keep producing. Inventory is expected to sell. When the assumption breaks, the asset gets written down.
Security budgets carry one too, and almost nobody writes it down. It is that the tools on the books will still be running when the attack arrives. Warlock’s operators went after that assumption directly.
Nine days in, 2 hours to disarm
One intrusion, against a critical infrastructure operator, shows the pattern.
On July 22, the attackers planted a web shell on a SharePoint server. Over the following week, they mapped the domain, set up covert remote access and added an account, apparently named to pass as a SharePoint service account, to local administrator groups. Then, for about a day, the only recorded activity was one piece of planted code running in the background.
In the early hours of July 31, they moved. First came a tool built to disable security software. Its execution was recorded on at least 40 hosts within about two hours. Next, they 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 one, the researchers found, the ransomware showed up almost as soon as the protection was gone.
Do the arithmetic. Roughly 40 hosts in 120 minutes averages out to one machine losing its protection every three minutes.
The attackers targeted the tools watching the data before the data itself.
A line item the adversary can switch off
On the researchers’ facts, this is a patching story and an Active Directory story first. Patching and endpoint detection and response remain essential. Patching closes the door this group most likely walked through, and detection is often the only reason a team learns something is wrong. A utility that cuts either one to fund something else has made a bad trade. Tamper protection and blocking known vulnerable drivers belong switched on everywhere, too. They make the kill step harder.
But a control the adversary can switch off is worth less than its line item says.
Accountants would call it an impairment. When an event suggests an asset can no longer deliver the value it is carried at, you test it. If it fails the test, you write it down. The asset still has value. The books simply overstated it. Most security spend is expensed rather than capitalized, so no auditor will make you run this test. Run it anyway.
Warlock is that event for a lot of security budgets. Most detection spending depends on a sequence of things going right at the worst possible moment, with a sensor staying alive, a console receiving what it reports and a person reading it in time. Take away the sensor and the rest has nothing to work with. The spend remains in the budget, but the machine is left without protection.
Thinly staffed utilities carry more of that gap than their boards realize. 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. Larger systems, the report says, have more capacity to hire security specialists. That likely means fewer people watching, and more hours when nobody is.
All of the victims in this latest round were outside the United States. The playbook needs no passport.
And in the early hours, when the sensors go quiet, silence looks exactly like safety.
Prevention that does not wait for the sensor
If switching off whatever is watching comes right before the payload, the protection that matters has to be in place well before then. It cannot depend on a cloud connection holding, an analyst reading an alert or a sensor surviving the night.
Start with the limit. A tool that loads a vulnerable signed driver works at the deepest level of the machine and can end any security software it finds, including the kind I am about to describe.
That is why timing is the key factor. Here the kill step came after nine days inside. Before it, the attackers had to exploit a server, load their own code into memory through sideloading and work their way to rights across the domain. Each of those steps was a chance to stop them with a control that never had to survive the kill switch, because the attacker would not have gotten close enough to use one.
One way to build that control works in memory. Much of the code an intruder loads along the way depends on finding applications laid out in memory the way it expects. Change that layout each time an application loads, and code relying on those expectations should fail at the moment it runs, on endpoints and on servers, whether or not a sensor is reporting to anyone. The decision happens on the machine.
The impairment test for a utility board
Boards already run this review for every other asset. For security, it comes down to one question. What still holds once the monitoring stops?
Ask management to split the security budget into two piles. The first is protection that depends on a sensor staying online and a person responding. The second is protection that makes its decision on the machine, without waiting on a console or a person, and acts before the attacker has earned the rights to turn it off. Then ask who would learn that the sensors went quiet, and from what, since the attacker turns off the obvious messengers first.
If the second pile is empty and nobody would be told, write that in the risk register in those words. The share of the first pile that would not survive that night is the impairment. Better to book it in a board meeting than to read about it in an incident report.
40 machines went dark in two hours. Budget for the attacker who brings a switch.
The post What happens when security tools go dark before the ransomware appeared first on CyberScoop.
Source: CyberScoop
Source Link: https://cyberscoop.com/warlock-ransomware-storm-2603-sharepoint-attacks-op-ed/