TL;DR - Warlock ransomware hit a water utility and a telecom operator through SharePoint server exploitation, in the same campaign that also took a regional government and a university, per BleepingComputer on 2 October 2026 and The Hacker News on 3 October. Both describe a kill chain that includes disabling security tools, and both attribute it to a China-linked actor. The target class is self-hosted SharePoint servers, not Microsoft 365 tenants. What you need to do: confirm your patch level against the September fixes, confirm the server is not exposed straight to the internet, and confirm tamper protection is on and nobody muted it.
By The Numbers
| Item | Value |
|---|---|
| Outlets running the story | 2 (BleepingComputer 2 Oct, The Hacker News 3 Oct) |
| Sectors named in reporting | 4 (water utility, telecom, regional government, university) |
| Entry vector both outlets name | SharePoint server exploitation |
| Kill-chain stages in both write-ups | 2 (initial access, disabling security tools) |
| Deployment class in scope | On-prem SharePoint (Subscription Edition, 2019, 2016) |
| Microsoft 365 / SharePoint Online | Not the target class |
| Checks in the sweep below | 5 |
| Time to run all five | 30 minutes |
I read the second Warlock write-up on the morning of 3 October with my coffee going cold, and the thing that stayed with me was the second half of the sentence. A water utility does not run patched-every-month infrastructure. A telecom certainly does not. The organisations in the blast radius are the ones where the SharePoint server has sat in a server room since 2019, doing the intranet nobody looks at.
Then I read it again with a different question. Not "is this bad" but "would I have known?" That is the question that costs money, and in most estates I have walked into the honest answer is no.
Here is the shape of it. Warlock, a ransomware operation both outlets link to a China-linked actor, exploited SharePoint servers to reach a water utility and a telecom operator. The same campaign also hit a regional government and a university. Both describe a kill chain that includes disabling security tools, a deliberate step rather than a side effect: the attacker removes the thing that would have raised an alert before the encryption starts.
That step is what I want to spend your time on, because it turns bad news into a detection opportunity. And the split that decides everything is deployment. This is reporting about self-hosted SharePoint servers. If your whole estate is Microsoft 365, you are not in this campaign. If you have one on-prem box nobody has touched since a migration finished, keep reading.
Let me walk you through what got reported, why the on-prem split decides whether this is your problem, and the five checks you can run.
What actually got reported
Two outlets, one day apart, agreeing on the shape. That matters, because single-source breach reporting is where campaign names get invented.
Targets. A water utility and a telecom operator via SharePoint exploitation, plus a regional government and a university. Neither outlet names the organisations, and I am not going to guess. The pattern is the story: critical infrastructure and public sector.
Kill chain. Both include disabling security tools as an explicit stage. That is not a scripting bug. Knocking out endpoint protection first buys quiet time, and the tool that would have fired the alert is the one they switched off. Neither write-up gave me a CVE identifier I could verify, so I am not inventing one.
The on-prem split decides whether this is your problem
Fully on Microsoft 365? You are not the target class. The reporting is about servers organisations run themselves, on their own patch schedule. Your tenant's patching is Microsoft's job, and they are good at it.
Running SharePoint on premises? You own the patch calendar. Subscription Edition, 2019 and 2016 servers, usually in a rack in a regional office, usually exposed through a reverse proxy because somebody needed to reach a site from home. That is the box in this campaign, and Microsoft's September brief carried the fixes. Behind it means you are inside the window attackers are working in now.
A lot of these exist because a project finished years ago and nobody owns them. They are not "legacy". They are unowned, and unowned is what an attacker picks.
The "disables security tools" step is your best early warning
Turning off endpoint protection before ransomware buys a quiet window and no alerts. It also leaves a configuration change behind, because the setting they flipped is recorded, dated and attributable.
Check tamper protection. In Defender for Endpoint, this is what stops an attacker or a careless local admin disabling real-time protection permanently. If it was never on, there is no record and no alert. If it was on and something tried to change it, that is your signal.
Check the tamper events. Defender for Endpoint logs attempted tamper changes as event ID 5001. A cluster of those on a server is not maintenance. It is an operator making space.
Check for a quiet Defender. Pull 14 days of protection status per endpoint. Real-time protection off, or a platform that has not reported in days while everything around it is healthy, is a disabled tool. Do this before you rebuild the box, because after that the evidence is gone.
An attacker who silences your tooling has to record that they did it. That record is the only thing you get for free.
The 30-minute sweep
Five checks, one laptop, before a meeting. Small on purpose, because a two-week project will not happen.
1. Find every SharePoint server you own. Not the ones you remember. Search the asset register, DNS records, firewall rules and server room. A hostname nobody can name an owner for goes to the top of the list.
2. Read the build and the patch level. The version and last cumulative update tell you where you sit against the September fixes. If you cannot produce that in five minutes, the inventory gap is the finding, and worth more than the number.
3. Look at how it is exposed. Pull the internet-facing rules and find the SharePoint server behind them. Anything reachable straight from the internet on its own port, no reverse proxy in front, is the highest-value finding you will produce today. They do not need a clever exploit to get there.
4. Pull 14 days of Defender tamper and protection status. Event 5001, plus any endpoint showing protection disabled or going quiet. One export, ten minutes.
5. Prove your backups are restorable and immutable. Ransomware without recoverable backups is an expensive outage. With a tested, immutable copy it is a Tuesday. The test is restoring one file.
None of this is exciting. It works.
Key Takeaways
- The reporting is about self-hosted SharePoint servers. Microsoft 365 tenants are not the target class described in these write-ups.
- Two outlets, one day apart, agree on the shape. Water utility and telecom via SharePoint exploitation, plus a regional government and a university. China-linked.
- Disabling security tools is a deliberate stage. Event 5001 and a quiet Defender are the early signal.
- A SharePoint box exposed straight to the internet is the worst finding in the sweep. Reverse proxy in front, or take it offline.
- Backups are only real once you have restored from one. Immutability beats backup count.
FAQ
Is SharePoint Online / Microsoft 365 affected?
Not as described in the reporting. The write-ups are about servers organisations run themselves. If your estate is a Microsoft 365 tenant, your patch calendar is Microsoft's and this campaign is not your problem.
Which SharePoint versions are in scope?
The self-hosted ones: Subscription Edition, Server 2019 and Server 2016. The factor is that you run the server, not the year it is from.
What should I check first?
Get the build number and last cumulative update for every on-prem SharePoint server you own, then compare it against the September fixes. If you cannot do that in five minutes, the inventory gap is your finding.
How do I know if someone disabled my security tools?
Defender for Endpoint logs attempted changes to protection settings as event ID 5001. Pull 14 days of tamper events and protection status. Protection off, or a host that went quiet while its neighbours are healthy, is the pattern.
What if our SharePoint server is old and nobody owns it?
Top item, not a someday item. Find out whether it still serves anything anyone needs. If not, plan the shutdown. If it does, patch it this week or get it behind a reverse proxy. Unowned is what an attacker picks.
My Take
The number that stays with me is four. Water, telecom, government, university. That is not a list of organisations that failed at security. A regional government and a university have security teams and budgets, and they still landed in the same campaign as a water utility. The driver is not competence, it is exposure.
Which is good news. Exposure is measurable. You can find internet-facing SharePoint servers this week with a DNS query and a firewall rule review, and unpatched ones with one version check. None of that needs a budget line or a board conversation.
The bit I would push back on hardest is treating an on-prem server as dormant because nobody has mentioned it in a year. It is not dormant. It is reachable, it holds data, and it runs a patch level somebody chose a while ago for a different problem. Get the list, find which ones you cannot produce a patch level for. Those are the ones that matter.
Mathew Clark Founder, SecureInSeconds Currently: writing down which SharePoint boxes in my own estate I could not produce a patch level for
Further Reading
- Warlock ransomware breaches SharePoint in water, telecom operator attacks (BleepingComputer)
- Warlock Exploits SharePoint Flaws to Disable Security Tools and Deploy Ransomware (The Hacker News)
- Swiss government lost 200 accounts in a SharePoint breach
- ServiceNow: patch your self-hosted AI Platform this week
- The third EDR zero-day in five weeks tells ANZ blue teams about containment, not patching
- Ransomware Does Not Care About Your Compliance Certificates
