This weekend, Microsoft rolled out the URL rewrite rule, which prevents the successful attack via ProxyNotShell, as an emergency mitigation rule. This means that all Exchange 2016 and Exchange 2019 servers should be equipped with the workaround. However, this only applies if Exchange is at a current patch level and the emergency mitigation feature is active. For Exchange 2013 servers, the URL rewrite rule must still be configured manually. For Exchange 20133, the "URL Rewrite" module must first be installed and the rule configured.
For Exchange 2013, you can find the URL Rewrite module and an article on how to configure the rule here:
On Exchange 2016 and Exchange 2019 servers, the following command can be used to check whether the emergency mitigation feature is active:
Get-OrganizationConfig | fl MitigationsEnabled
Get-ExchangeServer | ft Name,MitigationsEnabled
The following command can be used to check whether ProxyNotShell Mitigation has been applied to the Exchange servers:
Get-ExchangeServer | Format-List Name,*Mitigations*
If the rule "M1.1" does not appear in the list of Applied Mitigation, you should check whether the Exchange Server can display the following website:
The "MSExchangeMitigation" service retrieves the XML file with the corresponding rules from this URL every hour. For ProxyNotShell (CVE-2022-41040), the name of the mitigation is "M1".
If the rule has not been applied, a look at the MitigationService log file can also be helpful:
The log file can be found in the path $Exinstall\Logging\MitigationService. If you have already acted quickly and created your own URL rewrite rule, you should now delete the rule you created yourself:
The rule published by Microsoft goes further than the self-created rule. Microsoft switches the URL rewrite rule to the "Default Web Site" and inherits the rule to all subdirectories. According to the initial information on this zero-day vulnerability, the self-created rule was only applied to the "Autodiscover" directory.
Here is a small script that searches for the IOC of the ProxyNotShell vulnerability:
A security update is not yet available, so make sure that the URL rewrite rule is configured.
Hallo Frank,
sollte man mittlerweile diese alte Regel wieder löschen? Bringt sie Nachteile? Ausgerollt wird sie ja nicht mehr, aber auch nicht automatisch entfernt.
Viele Grüße
Markus
Hallo Frank. Erstmal vielen Dank für die schnellen Infos.
Kleine Frage: Hat mir jemand einen Tipp wie ich vorgehen muss, dass EMS trotz Proxy rauskommt?
netsh winhttp scheint nicht zu funktionieren.
Das gleiche Problem habe ich auch. Der Mitigation Service kommt nicht raus, somit auch keine aktivierten Mitigations.
Hallo Jens,
wie sollte denn jetzt die Antwort aussehen?
Wenn ich den Test mit folgender URL „https://unserer.exchangeserver/autodiscover.json@notreallyevilpowershell“ & „https://unserer.exchangeserver/autodiscover.jsonnotreallyevilpowershell“ aufrufe erhalte ich :
Die Website ist nicht erreichbar
Die Webseite unter https://unserer.exchangeserver/autodiscover.json@notreallyevilpowershell ist eventuell vorübergehend nicht verfügbar oder wurde dauerhaft an eine neue Webadresse verschoben.
ERR_HTTP2_PROTOCOL_ERROR
Wir haben auf allen unserer Mailserver auch beide Regeln angewandt.
ACHTUNG: die Entdecker der Schwachstelle haben den RegEx-Teil angepasst auf: „.*autodiscover\.json.*Powershell.*“
MS hat da anscheinend noch nicht nachgezogen…
Laut den Entdeckern, konnte man anscheinend das ‚alte‘ RegEx-Pattern ‚umgehen‘ – man sollte daher zus. zu MS eine weitere eigene Regel am Start haben.
Auch das 403 wurde im Update 8 zun „Anforderung abbrechen“ umgestellt. Siehe den Original-Artikel: https://www.alitajran.com/0-day-vulnerability-microsoft-exchange/#h-block-known-attack-patterns-manual
Danke für die Info. Wer Kemp einsetzt, kann das natürlich auch dort umsetzen.
Dort kann man das dann im Virtual Service (entweder global oder per Sub-VS) und dem Pattern “ /.*autodiscover\.json.*Powershell.*/“ einfügen.
Der Kemp Artikel hat noch nicht die Aktuellsten Änderungen drin, aber das sollte man ja anpassen können:
https://support.kemptechnologies.com/hc/en-us/articles/9548819650701
Moin!
Auf Twitter empfiehlt oder weist man auf eine ergänzende Regel ({HTTP_COOKIE} containing Email=autodiscover) hin – keine Ahnung wie die dann aussehen müsste :(
Angepasst mit Anforderung abbrechen und RegEx Eintrag.
Keine extra neue Regel gemacht, die alte gelöscht und neu angelegt.
Sind jetzt weiterhin 2 drin, einmal die von MS und die selbst erstellte
Zur Info.
Wir haben cu11 mit August Patch, ohne Windows Extended Protection aktiviert.
Die Regel wurde trotzdem angewandt. Ich schätze es reicht wenn das Modul installiert ist, ohne kompletten Patchstand.
Hallo Jens,
Emergency Mitigation wurde mit CU11 eingeführt, daher hast du das Update erhalten. Auf einem Exchange 2013 würde nur die Installation des Moduls nicht reichen, da hier das Feature Emergency Mitigation nicht verfügbar ist.
Beste Grüße,
Frank