Patching against an automated adversary
Jul 23rd, 2025 by Jesper Kråkhede
This month a critical vulnerability in on-premises SharePoint, called ToolShell, was exploited on a massive scale. Attackers could run code on internet facing servers without logging in. Within days, several hundred servers in many countries were confirmed compromised, and the attackers stole the servers´ machine keys, which let them keep access even after the patch.
What struck me was the speed. From the first exploitation to mass scanning and to the exploit being available in public tools took days, not weeks. That is what automation looks like on the attacker´s side.
So what can defenders do? First, know what you expose to the internet. You can´t patch what you don´t know you have, and many organisations found SharePoint servers they had forgotten.
Second, have an emergency process for critical patches on internet facing systems that works in hours, not in the next maintenance window. Practise it.
Third, assume breach when a vulnerability has been exploited before you patched. Patching closes the door, but if keys or credentials were stolen, the attacker can come back through another. In this case, rotating the machine keys was as important as patching.
Fourth, reduce what you expose. Does that server really need to be reachable from the whole internet? Can it be moved to a cloud service where the provider patches it for you?
And fifth, automate detection. Hunting queries for known indicators should run within hours of their publication.
The attackers automated their side. Automate yours.