EEMS - Exchange Emergency Mitigation Service

Mit den Exchange Updates im Sep 2021 hat Microsoft einen weiteren Dienst zum Schutz von On-Premises-Servern umgesetzt, den ich hier beschreibe. Microsoft hat am 24. Sep 2021 berichtet:

• New security feature in September 2021 Cumulative Update for Exchange Server
  https://techcommunity.microsoft.com/t5/exchange-team-blog/new-security-feature-in-september-2021-cumulative-update-for/ba-p/2783155
• Released: September 2021 Quarterly Exchange Updates
  https://techcommunity.microsoft.com/t5/exchange-team-blog/released-september-2021-quarterly-exchange-updates/ba-p/2779883

Am 1. Okt 2022 wurde diese Funktion erstmals zur Sicherung von Exchange aufgrund des Exchange-0-day-Exploit 2022 aktiviert.
Exchange Emergency Mitigation (EM) service - List of mitigations released
https://learn.microsoft.com/en-us/exchange/exchange-emergency-mitigation-service?view=exchserver-2016#list-of-mitigations-released

Achtung
Wenn Sie ein neues Exchange CU installieren, dann wird auch die IIS-Konfiguration neu gemacht und EEMS muss die Änderungen wieder addieren. Sie sind dann also bis zu einer Stunde "ungeschützt". Wer manuell schon gleichnamige Regeln angelegt hat, kann mit URL_Rewrite Probleme bekommen.

Noch ein Tool?

Warum noch ein Dienst, noch eine Software, noch mehr URLs, werden Sie sich vielleicht fragen. Die großen Sicherheitsprobleme von Microsoft Exchange im Jahr 2021 haben bei Microsoft zu der Erkenntnis geführt, dass selbst nach Hafnium Exploit es immer noch zu viele Exchange Server gibt, die nicht so betreut werden, wie es sein müsste. Ich vergleiche das gerne mit dem Autofahrer, der regelmäßige Inspektionen und Reifenwechsel auslässt und sich dann beschwert, wenn er liegen bleibt oder im Straßengraben landet. Aber selbst aktuelle Server sind nicht davor geschützt, eine unerkannte Lücke zu haben, für die es am Anfang noch nicht mal einen Patch gibt.

In dem Umfeld gibt es mit EEMS nun eine weitere Komponente zum sicheren Betrieb eines Exchange Server. Diese sind:

• Aktuelles Betriebssystem und Software
  Natürlich müssen Sie auch zukünftig ihren Server möglichst zeitnah mit verfügbaren Updates und Patches versehen. Ich würde hier nicht länger als 1 Woche warten oder sogar schneller aktualisieren.
• Virenscanner
  Wenn eine Malware den Weg auf den Server findet, dann kann ein lokaler Virenscanner entweder eine bekannte Malware schon erkennen oder das nächste Pattern-File kann eine aktive Malware hoffentlich schnell genug blocken. Das gelingt sogar sehr oft.
• Sichere Konfiguration
  Natürlich sollten Sie alle Register des Betriebssystems ziehen, z.B. getrennte Admin-Konten, Arbeiten mit wenig Rechten, Beschränkung auf notwendige Software, Applocker und SmartScreen, PowerShell ExecutionPolicy etc. um das System zu härten.
• EEMS
  Mit EEMS kommt nun ein weiterer Dienst dazu, der sehr oft von Microsoft eine Liste von "Konfigurationsanpassungen" abfragt und diese sehr schnell umsetzt.

EEMS ist also ein weiterer Baustein in der Kette zur Verteidigung eines Exchange Servers gegen externe und interne Angriffe. Wenn Microsoft über eine neue Lücke oder einen Angriff informiert wird, und die Auswirkungen durch schnelle Konfigurationsanpassungen verhindert werden können, dann sollte das schnell passieren. Womit wir wieder bei den Exchange Servern sind, die von ihren Besitzern eher lieblos behandelt werden. Hier hilft dann EEMS, indem es eigenständig ohne Neustart entsprechende Anpassungen umsetzt.

Exchange Telemetrie

Mit dem Updates und EEMS spendiert Microsoft den On-Premises Exchange Servern eine weitere Funktion, die sogar richtig deutlich sichtbar bei den Kommandozeilenparametern für die "Unattended Installation" wird:

/IAcceptExchangeServerLicenseTerms 

/IAcceptExchangeServerLicenseTerms_DiagnosticDataOn 

/IAcceptExchangeServerLicenseTerms_DiagnosticDataOff

Damit stellt sich natürlich die Frage, welche Daten Microsoft damit einsammelt. Laut Microsoft sind das:

• Exchange Version (Buildnummer)
• Status des Exchange Mitigation Service
• Eindeutige DeviceID des Servers und OrgID der Installation
• Angewendete Updates durch EEMS
• Blockierte Updates durch EEMS

Ich finde es eher erstaunlich, dass diese Daten nicht schon früher im Rahmen einer allgemeinen Telemetrie gesammelt wurden und nun erst explizit erfasst werden. Microsoft hatte bis zum Sep 2021 Update quasi keinen Überblick über die bei Kunde installierten Exchange Versionen. Dann fehlt eigentlich nur noch die Angabe einer "Kontaktperson", die bei Probleme automatisiert angesprochen werden kann.

Wobei spätestens seit dem Hafnium Exploit klar sein muss, das ein eigener Exchange Server aktiv betreut werden muss (Selbst oder per Dienstleister) oder Sie besser einen Hosted Service wie Exchange Online nutzen. In beiden Fällen wird auch ein Monitoring und Telemetrie genutzt.

Funktionsweise

Der Dienst fragt jede Stunde beim "Office Configuration Service" nach entsprechenden Lücken nach. Die URL ist nicht geheim und kann auch einfach per PowerShell abgefragt werden. Seit dem 1. Okt 2022 gibt es sogar eine erste aktive Konfiguration:

PS C:\> (Invoke-RestMethod https://officeclient.microsoft.com/getexchangemitigations).EOCS.config

id    desc                                                         Roles ActionList
--    ----                                                         ----- ----------
M1    Mitigation M1                                                Roles ActionList
PING1 EEMS Heartbeat probe. Does not modify any exchange settings.       ActionList

PS C:\> (Invoke-RestMethod https://officeclient.microsoft.com/getexchangemitigations).EOCS.config[0].actionlist.action | fl

type  : UrlRewrite
id    : 1
scope : Server
desc  : Mitigation of CVE-2022-41040 via a URL Rewrite configuration.
Value : Value

Die URL können Sie auch im Browser öffnen. Hier nur ein Auszug:

Diese XML-Datei ist noch ein Muster, welche keine erforderlich Aktivitäten enthält. Wenn der lokal installierte EEMS-Service jede Stunde die Konfiguration bekommen, dann kann er folgende Aktionen ausführen:

• IISRewrite-Rules addieren
  diese Modul im IIS erlaubt es umfangreiche "Umschreibungen" für HTTP-Request anzuwenden. Das ist die erste Verteidigungslinie, mit der ein Web-Administrator die dahinterliegenden Webapplications schützen kann. Es ist eine kleine eingebaute Firewall, mit der Anfragen analysiert, bewertet und ggfls. auch abgelehnt werden können.
• Exchange IIS-AppPool stoppen
  Der IIS kennt das Modell der AppPools, um bestimmte Funktionen dauerhaft zu instanzieren, so dass die Umgebung nicht bei jedem Request neu initialisiert werden muss. Sollte daher ein Code-Teil eine Lücke aufweisen, die EEMS nicht über eine URL-Rewrite-Regel beheben kann, dann kann EEMS den AppPool stoppen. Damit ist dann natürlich auch die damit verbundene Funktion bestört-
• Exchange Dienste beenden
  Das ist dann wohl die härteste Methode, dass ein Dienst komplett beendet wird, um die Ausnutzung einer Lücke zu unterbinden. Angeblich betrifft dies aber nur Exchange Dienste. Die Lücken im Windows Spooler Dienst, die auch in 2021 zu Problemen geführt hat, würde EEMS wohl nicht korrigieren.

Er wendet diese "Korrekturen" aber auch jede Stunde wieder an. Die Änderungen durch den EEMS passieren ohne Reboot. Es kann aber schon sein, dass bestimmte Korrekturen von Anwendern natürlich bemerkt werden. Ein gestoppter AppPool wird sicher die damit verbundene Funktion unterbrechen.

Einrichtung

Die Installation des EEMS ist Teil der Exchange Installationsroutine im September 2021 Update oder neuer. Allerdings sind zwei Voraussetzungen erforderlich, die das Setup selbst aktuell nicht sicherstellt aber drauf hinweist:

• Update 2999226 Universal C RunTime Windows
  http://support.microsoft.com/kb/2999226 Update for Universal C Runtime in Windows
  https://www.microsoft.com/de-de/download/details.aspx?id=49093
  Angeblich ein Update für Windows 7
• IIS URl Rewrite
  Damit EEMS entsprechende "Rewrite Rules" aktivieren kann, muss das Module im IIS addiert werden
  
• Erreichbarkeit des OCS-Service
  Die EEMS-Dienst muss natürlich per HTTPS den Office Configuration Service bei Microsoft erreichen
  

Hier muss der Administrator vor dem Setup noch nachbessern.

Konfiguration

Die erfolgreiche Installation finden Sie natürlich auch an mehreren Stellen:

• Windows Service "MSExchangeMitigation"
  
• PowerShell Get-ExchangeServer
  Auch in der Exchange PowerShell können Sie sehen, ob und wie der Dienst aktiv ist. Dazu gibt es bei "Get-ExchangeServer" neue Properties:
  
• Ein/Ausschalten per PowerShell
  Sie können die Anwendung der Mitigations global oder pro Server steuern.
  
  Diese Änderungen werden natürlich wie jeder andere PowerShell-Befehl im AdminAuditLog des Exchange Server protokolliert.

Hinweise für den Betrieb

EEMS wird durch den Administrator über die normale Installationsroutine auf den Server gebracht. Für den Einsatz gibt es aber einige Randbedingungen, die sie beachten sollten:

• Exchange muss "surfen" können
  d.h. Proxy-Server und Authentication müssen berücksichtigt werden, damit EEMS auch die aktuellen Hinweise erhalten kann. Ich kann mir aber vorstellen, dass Sie in einer "High Secure"-Umgebung vielleicht die Information auch extern abholen und intern unter einer eigenen URL bereitstellen können.

Hinweis
Exchange funktioniert auch ohne den EEMS-Server aber bekommt natürlich keine Updates. Es ist in einem abgeschotteten Netzwerk aber möglich, den EEMS-Service zu deaktivieren.

• Microsoft kann tracken
  Genau genommen sieht Microsoft natürlich den HTTP-Request ihres Servers und je nach Informationsumfang kann man zumindest die Source-IP auf einen Kunden zuordnen.
• Erst nach Update
  Die Funktion erhalten natürlich nur die Server, die auch das Update vom Sep 2021 erhalten haben. Die tausende Exchange Server, die auch 6 Monate nach Hafnium Exploit immer noch nicht gepatched sind, werden auch die neue EEMS-Funktion nicht bereitstellen.
• Öffentliche URL für Monitoring
  Was sollte sie daran hindern, diese URL über ihr Monitoring regelmäßig zu prüfen, um über den Weg aktiv eine Information zu erhalten. Wenn Microsoft über EEMS eine Konfigurationsänderung veröffentlich, dann möchte ich das als "Exchange Verantwortlicher" gerne umgehend erfahren.

Eventlog

Der Service hinterlässt auch Meldungen im Eventlog. Hier ist insbesondere interessant, wenn der Server nicht mit dem Cloud-Service kommunizieren kann:

Protokollname: Application
Quelle:        MSExchange Mitigation Service
Datum:         22.12.2021 10:15:51
Ereignis-ID:   1008
Aufgabenkategorie:General
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Beschreibung:
An unexpected exception occurred. Diagnostic information: 

Mindestens ein Fehler ist aufgetreten. 
---> System.Net.Http.HttpRequestException: Fehler beim Senden der Anforderung. 
---> System.Net.WebException: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden. 
---> System.Net.Sockets.SocketException: Ein Verbindungsversuch ist fehlgeschlagen, 
da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, 
oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host 
nicht reagiert hat 52.109.88.177:443

Sie könnten also zumindest auf "Fehler" mit der Quelle "MSExchange Mitigation Service" überwachen.

Get-Mitigations und andere

Microsoft legt im "Exchange Scripts"-Verzeichnis auch eine "Get-Mitigations.ps1" ab, welches die angewendeten Fixes anzeigt:

[PS] C:\>'C:\Program Files\Microsoft\Exchange Server\V15\scripts\Get-Mitigations.ps1'

Server      : EX2016A
Version     : Version 15.1 (Build 2375.7)
ID          : PING1
Type        : Ping
Description : EEMS Heartbeat probe. Does not modify any exchange settings.
Status      : Applied

Ich habe versucht, das Skript zu verstehen aber es ist doch recht umfangreich und leistet recht viel.

Mitigation im AD

Ich habe schon sehr früh festgestellt, dass ein "Get-ExchangeServer" auch Server anzeigt, die ausgeschaltet oder nicht erreichbar sind

[PS] C:\>Get-ExchangeServer  | ft name,miti* -AutoSize

Name        MitigationsEnabled MitigationsApplied MitigationsBlocked
----        ------------------ ------------------ ------------------
EX01                      True {M1.1, PING1}
EX02                      True {PING1}

Daher muss das Skript die Daten "irgendwo anders" auslesen. Eine kurze Suche im AD zeigt, dass im Feld "msExchConfigurationXML" bei jedem Exchange Server eine XML-Information liegt.

Hier ist ein Auszug einer XML, bei der Mitigation aktiv ist und neben dem PING auch schon das MIG.1.1-Update eingespielt ist

<TransportServerConfigXml>
  <MitigationsEnabled p2:nil="true" xmlns:p2="http://www.w3.org/2001/XMLSchema-instance" />
  <MitigationsApplied>
    <Mitigation>M1.1</Mitigation>
    <Mitigation>PING1</Mitigation>
  </MitigationsApplied>
</TransportServerConfigXml>

Die Werte sollten Sie aber nicht per ADSIEDIT anpassen. Das geht ganz offiziell mit "Set-ExchangeServer"

[PS] C:\>get-ExchangeServer EX2016A | fl miti*

MitigationsEnabled : True
MitigationsApplied : {M1.1, PING1}
MitigationsBlocked :

[PS] C:\>set-ExchangeServer EX2016A -MitigationsApplied $null
[PS] C:\>get-ExchangeServer EX2016A | fl miti*


MitigationsEnabled : True
MitigationsApplied :
MitigationsBlocked :

Es kann dann bis zu 1 Stunde dauern, bis der MitigationService den Eintrag wieder nachholt und entsprechend die Werte wieder setzt.

Dies ist später für ein Monitoring durchaus ein interessanter Weg ganz schnell zu sehen, welche Server welchen Stand haben.

Protokolldateien

Standardmäßig ist beim MitigationService aber auch eine Protokollierung im Dateisystem aktiviert. Die Exchange Administrator kennen sicherlich das "Logging"-Verzeichnis im Exchange Programm Verzeichnis.

Der Inhalt der Dateien ist aber relativ "überschaubar". Hier ein Auszug.

#Software: Microsoft Exchange Server
#Version: 15.0.0.0
#Log-type: Mitigation-Service
#Date: 2022-10-09T00:41:47.005Z
#Fields: TimeStamp,ServerName,EventId,EventData
2022-10-09T00:41:47.005Z,EX2016A,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations from https://officeclient.microsoft.com/getexchangemitigations
2022-10-09T00:41:47.005Z,EX2016A,FetchMitigation,S:LogLevel=Information;S:Message=No diagnostic data sent. DataCollectionEnabled is false
2022-10-09T00:41:47.177Z,EX2016A,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations successful
2022-10-09T00:41:47.209Z,EX2016A,ApplyMitigation,S:LogLevel=Information;S:Message=Mitigation M1.1 is currently applied
2022-10-09T00:41:47.209Z,EX2016A,ApplyMitigation,S:LogLevel=Information;S:Message=Mitigation PING1 is currently applied
2022-10-09T01:21:41.209Z,EX2016A,StopService,S:LogLevel=Information;S:Message=Stopped MSExchangeMitigation
2022-10-09T01:21:42.139Z,EX2016A,StartService,S:LogLevel=Information;S:Message=Started MSExchangeMitigation
2022-10-09T01:41:47.033Z,EX2016A,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations from https://officeclient.microsoft.com/getexchangemitigations
2022-10-09T01:41:47.033Z,EX2016A,FetchMitigation,S:LogLevel=Information;S:Message=No diagnostic data sent. DataCollectionEnabled is false
2022-10-09T01:41:47.220Z,EX2016A,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations successful
2022-10-09T01:41:47.251Z,EX2016A,ApplyMitigation,S:LogLevel=Information;S:Message=Mitigation M1.1 is currently applied
2022-10-09T01:41:47.251Z,EX2016A,ApplyMitigation,S:LogLevel=Information;S:Message=Mitigation PING1 is currently applied
2022-10-09T02:41:47.039Z,EX2016A,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations from https://officeclient.microsoft.com/getexchangemitigations
2022-10-09T02:41:47.039Z,EX2016A,FetchMitigation,S:LogLevel=Information;S:Message=No diagnostic data sent. DataCollectionEnabled is false
2022-10-09T02:41:47.180Z,EX2016A,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations successful
2022-10-09T02:41:47.227Z,EX2016A,ApplyMitigation,S:LogLevel=Information;S:Message=Mitigation M1.1 is currently applied

Sie sehne einfach, dass jede Stunde der Mitigation Service hier die aktuelle Version nachlädt und prüft, welche Updates umzusetzen sind.

Leider habe ich noch keine Einträge gesehen, wenn EEMS eine Update erstmalig einspielt. Ich sehe dann nur ein "Mitigation <name> is currently applied"

Anscheinend werden die Mitigation einfach immer wieder angewendet.

Monitoring

Der Schutz ist natürlich nur gegeben, wenn der Dienst läuft, Updates von Microsoft erhalten und diese auch anwenden kann. Daher ist eine generelle Überwachung wichtig. Hier gibt es mehrere Ansatzpunkte:

PS C:\> Get-Item "HKLM:\SOFTWARE\Microsoft\IIS Extensions\URL Rewrite"

    Hive: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS Extensions

Name                           Property
----                           --------
URL Rewrite                    Install : 1
                               Version : 7.2.1993

if ((Get-Item "HKLM:\SOFTWARE\Microsoft\IIS Extensions\URL Rewrite\").getvalue("Install") -eq 1){
   "OK IIS URLRewriteInstalled"
}
Else {
   "FAIL IIS URLRewrite Not Installed"
}

(Get-Service  MSExchangeMitigation -ErrorAction SilentlyContinue).status -ne "running"

if (Get-Process "Microsoft.Exchange.Mitigation.Service") {
   "Running"
}
else {
  "EEMS not running"
}

Source                         EventID    Message
MSExchange Mitigation Service  1001       Service startet successfully
MSExchange Mitigation Service  1002       Service stopped successfully
MSExchange Mitigation Service  1005       Mitigation PING1 is currently applied
MSExchange Mitigation Service  1005       Mitigation M1.1 is currently applied
MSExchange Mitigation Service  1008       Unexpected Erorr  (Kein Internet

(Invoke-RestMethod https://officeclient.microsoft.com/getexchangemitigations).EOCS.config.count

(Get-ExchangeServer).MitigationsEnabled
True

(Get-ExchangeServer).MitigationsApplied.count
1

Die Zeit wird zeigen, wie wir weitere Überwachungen aktivieren können, um die Anwendung der Mitigations zu erkennen. Wenn man all das dann zusammenfasst, bekommt man ein kleines PS1-Script, welches die Werte einfach liefert.

Test-EEMS

Das Skript prüft die oben genannten Einstellungen und gibt sie einfach als Ausgabe zur Weiterverarbeitung aus.

Info für Hacker

Eine öffentlich anonym erreichbare URL, die automatisiert "Korrekturhinweise" für Sicherheitslücken bereitstellt, interessiert natürlich auch die "bösen Jungs/Mädels". Denn wann veröffentlicht ein Hersteller über eine URL eine JSON-Datei mit Anweisungen zum "Patchen". Selbst wenn der Inhalt nicht nur signiert sondern verschlüsselt wäre, könnte ich einen eigenen Exchange Server mit installiertem EEMS betreiben, und bei Änderungen umgehend schauen, was Microsoft hier wie korrigiert oder verhindert.

Das Risiko ist natürlich geringer, wenn irgendwann alle On-Premises Exchange Server ebenfalls mit EEMS ausgestattet sind und nicht nur aus dem Internet erreichbar sind, sondern auch zumindest die OCS-URL erreichen können. Dann dürfte die 60 Minuten als Zeitfenster schon sehr kurz sein, eine Lücke zu analysieren und einen Angriff zu fahren.

Vielleicht gibt es irgendwann die ersten Firewall-, Loadbalancer- und Webproxy-Hersteller, die ebenfalls diese Information einbinden.

Signatur/Sicherheit

Wenn Exchange im Internet eine "Handlungsanweisung" zur Anpassung von Konfigurationen abruft, dann muss ich natürlich sicherstellen, dass kein Angreifer diese Daten verfällt und damit meinen Exchange Betrieb stört oder sogar eigene "Regeln" addiert, die dann eine Hintertür öffnen. Microsoft sichert den Service über mehrere Funktionen ab:

• HTTPS-Übertragung
  Der Zugriff auf den Office Configuration Service erfolgt per HTTPS. Damit ist ab "Abhören" der Verbindung erschwert aber nicht wirklich kritisch, da die Informationen eh anonym erreichbar sind
• HTTPS-Zertifikatspinning
  Aktuell habe ich noch nicht geprüft, ob der EEMS-Service das ausgelieferte Zertifikat prüft.
• Signiertes XML
  Neben dem Transport wird aber auch die Information selbst digital signiert. Das Zertifikat samt Chain können Sie aus der XML-Datei einfach extrahieren und ist auf die "Microsoft Exchange XML Signing" ausgestellt
  
  Auch hier muss ich aber noch prüfen, wie streng der EEMS-Dienst die Prüfung nimmt.

Entsprechende Prüfungen der "Sicherheit" stehen noch aus

Andere On-Premises Server?

Schön, dass das Exchange Team mal wieder seine Hausaufgaben macht und die On-Premises Plattform weiter entwickelt. Aber neben Exchange gibt es ja auch noch SharePoint, Skype for Business und andere "On-Premises"-Services auf Basis on Microsoft. Die "Printer Nightmare"-Problematik im Sommer 2021 hat gut aufgezeigt, dass selbst grundlegende Dienst wie der "Spooler" nicht fehlerfrei sind und als schnelle Lösung z.B. die Deaktivierung des Spooler-Diensts genannt wurde oder auch nur ein paar Registrierungsschlüssel den Schutz verbessert haben.

Da kommt natürlich der Gedanke auf, dass EEMS in ähnlicher Form auch in anderen Produkten umgesetzt wird oder es vielleicht sogar zu einem "Microsoft Update Realtime"-Dienst kommen könnte. Exchange war ja schon Vorreiter bei der Nutzung der PowerShell oder RBAC - Role Based Access Control und es würde mich nicht überraschen, wenn abhängig von den Erfahrungen mit EEMS die Funktion nicht auch bei anderen Diensten adaptiert wird. Wir leben nun mal in einer schnelllebigen Welt.

Ich weiß nicht, ob Microsoft auch in Exchange Online mit EEMS arbeitet. Ich vermute aber, dass hier Updates und Konfigurationsänderungen aktiv "durchgedrückt" werden und man sich hier nicht drauf verlässt, dass ein lokaler Dienst vielleicht Änderungen liest und umsetzt.

Weitere Links

• Exchange-0-day-Exploit 2022
• URL_Rewrite
• AMSI - AntiMalware Scan Interface
• Exchange Fail Jan 2019 - CVE-2018-8581
• Exchange-0-day-Exploit 2022
• Hafnium Exploit
• Hafnium Nachbereitung
• ProxyLogon
• RBAC - Role Based Access Control
• Applocker und SmartScreen
• PowerShell ExecutionPolicy
• Exchange Emergency Mitigation (EM) service - List of mitigations released
  https://learn.microsoft.com/en-us/exchange/exchange-emergency-mitigation-service?view=exchserver-2016#list-of-mitigations-released
• New security feature in September 2021 Cumulative Update for Exchange Server
  https://techcommunity.microsoft.com/t5/exchange-team-blog/new-security-feature-in-september-2021-cumulative-update-for/ba-p/2783155
• New Microsoft Exchange service mitigates high-risk bugs automatically
  https://www.bleepingcomputer.com/news/microsoft/new-microsoft-exchange-service-mitigates-high-risk-bugs-automatically/
• Released: September 2021 Quarterly Exchange Updates
  https://techcommunity.microsoft.com/t5/exchange-team-blog/released-september-2021-quarterly-exchange-updates/ba-p/2779883
• Exchange Emergency Mitigation
  https://www.frankysweb.de/exchange-emergency-mitigation/