Attacks on outdated Exchange servers are currently underway again. Specifically, the ProxyNotShell vulnerability, which became known in October of this year, is being exploited again. The new attack method has been christened OWASSRF. The IIS rewrite rules published by Microsoft are bypassed in this new attack method. The only thing that helps at the moment is to install the available security updates from November:
A detailed description of the new attack method can be found on the CrowdStrike blog:
Anyone currently running Exchange Server without the November SU should install the update as soon as possible. The Christmas period in particular is often used for automated attacks, as many employees in IT departments are on vacation, reducing the likelihood of an attack being noticed quickly.
As already mentioned, only the installation of the update KB5019758 helps against this new attack, the IIS Rewrite Rules, which Microsoft has distributed via Exchange Emergency Mitigation, do not help, as they were only configured for the Autodiscover vDir:
However, the new attack now targets the OWA vDir. Without the KB5019758 update, the only workaround currently available is to disable OWA to protect against OWASSRF. With the following IIS rewrite rule, OWA can be restricted to the local subnet and deactivated for all other IPs:
Als Rule Template kann „Request blocking“ verwendet werden:
The new rule is now configured as shown in the next screenshot. This rule applies to all IPs, except if the request comes from the network 192.168.200.* (the network must be adjusted accordingly):
This is what the finished rule looks like:
It may be easier to block access at a reverse proxy or a web application firewall, if these are used.
Vielleicht ließe sich auch die ProxyNotShell Regel von „(?=.*autodiscover)(?=.*powershell)“ nach „(?=.*owa)(?=.*powershell)“ umstellen, dazu habe ich aber bisher keine Informationen gefunden. Wenn es so einfach wäre, hätte CrowdStrike vermutlich auch schon darauf hingewiesen.