Exchange Emergency Mitigation (EM) is, as already mentioned in this article available from CU 11 for Exchange 2019 and CU 22 for Exchange 2016. The way it works is as simple as it is effective: the Exchange servers check every hour whether there is a new set of rules for mitigating a vulnerability. For this purpose, a signed XML document is retrieved from Microsoft's "Office Config Service (OCS)" servers every hour. Depending on the vulnerability, the XML file contains certain actions or configurations that are automatically applied by the Exchange servers to mitigate a vulnerability until appropriate updates have been installed.
Exchange Emergency Mitigation therefore does not relieve admins of the task of installing Exchange updates, but can protect against the exploitation of a security vulnerability by blocking the attack path. The installation of updates is of course still necessary.
EM can perform three different actions to prevent an attack:
- Applying IIS URL rewrite rules, which many people know from Apache web servers (mod_rewrite). Malicious HTTP requests can be blocked using rewrite rules. As most Exchange protocols are provided via the IIS web server, an appropriate set of rules can be used to respond very effectively to attacks
- Disable vulnerable Exchange services. EM can deactivate vulnerable Exchange services and thus protect against the exploitation of a vulnerability. This can of course affect the availability of certain Exchange functions.
- Deactivating IIS application pools. EM can deactivate certain IIS app pools, similar to the Exchange services. This can also affect the availability of certain functions.
Requirements for Exchange Emergency Mitigation (EM)
In addition to the current CUs for Exchange Server 2016/2019, Exchange Emergency Mitigation requires the IIS URL Rewrite Module, which can be downloaded here:
The URL Rewrite Module can be easily installed via the Web Platform Installer:
After installation, you will find the "URL Rewrite" item in the IIS Manager:
In addition, the Exchange servers must be able to reach the "Office Config Service" via HTTPS (port 443). This URL may therefore need to be enabled on the firewall:
- officeclient.microsoft.com
Access from the Exchange servers can be easily tested via a browser by calling up the following URL:
A corresponding XML should already be displayed here:
There is also the script "Test-MitigationServiceConnectivity.ps1" in the Exchange Scripts directory (C:\Program Files\Microsoft\Exchange Server\V15\scripts\):
This script also tests whether the URL specified above can be reached by the Exchange Server.
Settings for Exchange Emergency Mitigation
After installing the corresponding CUs for Exchange, EM is automatically active for all Exchange servers in the organization.
However, EM can be activated or deactivated for all servers or only for certain servers. To disable EM for all Exchange servers in the organization, the following command can be used:
Set-OrganizationConfig -MitigationsEnabled $false
To deactivate EM for specific servers only, the following command can be used:
Set-ExchangeServer -Identity SERVERNAME -MitigationsEnabled $false
In a larger Exchange environment, it may make sense to leave EM activated only for the servers that are also accessible from the Internet.
The following commands can be used to check the status of EM:
Get-OrganizationConfig | fl MitigationsEnabled
Get-ExchangeServer | ft Name,MitigationsEnabled
To enable EM for all Exchange servers in the organization (if it was previously disabled), the following commands can be used:
Set-OrganizationConfig -MitigationsEnabled $true
Set-ExchangeServer -Identity SERVERNAME -MitigationsEnabled $true
Applying or blocking mitigations
The PowerShell script "Get-Mitigations.ps1" can be used to display an overview of the available workarounds for vulnerabilities. The script is also located in the Exchange Script directory and currently only shows a mitigation with the ID "PING1":
This is a test that does not perform any actions or change any configurations. Microsoft plans to publish mitigations when Exchange servers are actively attacked, similar to the HAFNIUM vulnerability was the case. In this case, EM can help to implement workarounds as quickly as possible and thus prevent far-reaching attacks until all Exchange servers have been updated.
The mitigations that are applied by EM can be displayed and (if necessary) blocked. The following command displays the applied and blocked mitigations:
Get-ExchangeServer | fl Name,Mitigations*
The following command can be used to block mitigations so that they are no longer automatically applied by Exchange:
Set-ExchangeServer -Identity -MitigationsBlocked @("PING1")
"PING1" is the ID supplied by "Get-Mitigations.ps1" or "Get-ExchangeServer | fl Name,Mitigations*". To reactivate a mitigation, the following command can be used:
Get-ExchangeServer | Set-ExchangeServer -MitigationsBlocked @()
You have to be a bit careful when adding mitigations to the Blocked list, only after the next run, the mitigation is removed from the Applied list, as long as the mitigation is visible under MitigationsBlocked and MitigationsApplied:
It is also not a very nice solution that there is no check whether the MitigationID also exists, here you can simply enter values as you wish:
The output of "Get-Mitigations.ps1" is also not very helpful here if you make a mistake:
The output is only correct again once a new EM run has been performed, but this can take up to 60 minutes. If the service is restarted, it only takes 10 minutes.
Note: If mitigations are blocked, they are no longer applied by Exchange Server (in the hourly search), but the URL rewrite rules are not reset after a mitigation has been blocked, so any existing URL rewrite rule must be removed manually:
The same also applies if the Exchange servers have been updated, the applied mitigations are not automatically revoked. If mitigation is no longer required because the vulnerability has been closed with an update, the corresponding ID is removed from the list of applied mitigations, but any existing URL rewrite rules must be deleted manually.
Logs
Logs are written to the server's event logs by the "MSExchange Mitigation Service". The EventID 1005,1006 and 1008 are relevant for EM:
Another detailed log file is written to the following path:
C:\Program Files\Microsoft\Exchange Server\V15\Logging\MitigationService
This log contains detailed information on which actions were used by EM. The Admin Audit Log can also be helpful if problems occur in connection with mitigations.
Note: EM is provided via the "Microsoft Exchange Emergency Mitigation Service":
Let's hope that the Emergency Mitigation Service doesn't have to intervene too often.
Hallo zusammen,
das PING1 XML-Mitigation-Script wirft seit 09.06.2022 jede Stunde Fehler:
Jun 13 11:27:48 49152.1008 MSExchange_Mitigation_Service An unexpected exception occurred. Diagnostic information: Exception encountered while fetching mitigations : System.Exception: This XML is not deemed safe to consume since Response xml’s signing cert is invalid or not from microsoft bei Microsoft.Exchange.Mitigation.Service.Common.SignatureVerifierUtils.ThrowIfIntegrityChecksFail(SafeXmlDocument xmlDoc) bei Microsoft.Exchange.Mitigation.Service.Common.SignatureVerifierUtils.GetValidatedDocumentWithoutSignature(SafeXmlDocument xmlDoc) bei Microsoft.Exchange.Mitigation.Service.Common.Utils.FetchDataFromXmlStream[T](Stream stream) bei Microsoft.Exchange.Mitigation.Service.Common.Utils.FetchMitigationsFromUrl[T](String url, RemoteCertificateValidationCallback certValidationCallback, X509Certificate clientAuthCert, Boolean isResponseJson) bei Microsoft.Exchange.Mitigation.Service.MitigationCloudServiceV2.FetchMitigations() bei Microsoft.Exchange.Mitigation.Service.Mitigations.MitigationEngine.FetchAndApplyMitigation()
Hintergrund ist der, dass die Signatur des PING1-Skripts (https://officeclient.microsoft.com/getexchangemitigations) abgelaufen ist.
Siehe https://tools.keycdn.com/ssl
Kopiert dort die Signatur aus dem XML-Dokument rein (im Tag SignatureValue):
—–BEGIN CERTIFICATE—–
MIIGCTCCA/GgAwIBAgITMwAAAjqaxD9adf61fAAAAAACOjANBgkqhkiG9w0BAQsFADB+MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3RvbjEQMA4GA1UEBxMHUmVkbW9uZDEeMBwGA1UEChMVTWljcm9zb2Z0IENvcnBvcmF0aW9uMSgwJgYDVQQDEx9NaWNyb3NvZnQgQ29kZSBTaWduaW5nIFBDQSAyMDExMB4XDTIxMDYxMDE4NDQxMloXDTIyMDYwOTE4NDQxMlowfTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0b24xEDAOBgNVBAcTB1JlZG1vbmQxHjAcBgNVBAoTFU1pY3Jvc29mdCBDb3Jwb3JhdGlvbjEnMCUGA1UEAxMeTWljcm9zb2Z0IEV4Y2hhbmdlIFhNTCBTaWduaW5nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9dM4E6w69Lwq1Rejh0vwyo+v4jnnni9zmRCyv9xxwhCSlCf8UcZtl8e8o5qO7OTlXqkw7JjMxZVC11rym4p1tfvOhBRCJ0gnaMP5728qm5E2g13YZmoMh0V4JxsQnQI3PV28l4MUiMTNCeX/Nvkj+ojnOV8ypbCEZrW9W73oS0LaApigN1LEBVAimt/4kg5lqeUux+Rvdn+M/FlE2C6AFKuPeb8f0YrRgUS5xIcb6LmIBbfNlnlAYcJM6qy+ercj+gYyFjWRdUQZM1tw4eTyXQhX7rtpk+vtPOcCV5pUhQe/6rSUcMFIFDfAu17OZK+oKzKhe+ZNjgo6F+evr8SnvQIDAQABo4IBfzCCAXswIAYDVR0lBBkwFwYIKwYBBQUHAwMGCysGAQQBgjdMOQELMB0GA1UdDgQWBBRrQYqQ4HWN1StB2eYy7NP0NkAxBDBQBgNVHREESTBHpEUwQzEpMCcGA1UECxMgTWljcm9zb2Z0IE9wZXJhdGlvbnMgUHVlcnRvIFJpY28xFjAUBgNVBAUTDTQ2NDg2OCs0NjQ4NzkwHwYDVR0jBBgwFoAUSG5k5VAF04KqFzc3IrVtqMp1ApUwVAYDVR0fBE0wSzBJoEegRYZDaHR0cDovL3d3dy5taWNyb3NvZnQuY29tL3BraW9wcy9jcmwvTWljQ29kU2lnUENBMjAxMV8yMDExLTA3LTA4LmNybDBhBggrBgEFBQcBAQRVMFMwUQYIKwYBBQUHMAKGRWh0dHA6Ly93d3cubWljcm9zb2Z0LmNvbS9wa2lvcHMvY2VydHMvTWljQ29kU2lnUENBMjAxMV8yMDExLTA3LTA4LmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBCwUAA4ICAQARts69VpMn56WbNtOtux5sm62G8+GDsrWYwlOw6VL+k5gJ3pG/XjTniC2yz8STpzyA/KO3RQ+nbXMQFP5do3VnxIprdzFB1LBVIpmCeNKIBeB2BxCbuFEqDVqa/Np6KaXYNLHB56pcpZaU2ZlzZ9HMrD5szWyKPeUxjB7S8uNUWMBA2bJp90s7W7WiaiEt+M2MogPpRa1tzTu5og3mWW+rTD/r9IhC14ynBOEvvBPaL0Iev0uWfqeS0cxxCFIGw9bWPkRyNX08LF5oEEq+PfU9jSTvjhfMU7alGD1D1EGsUqJ5p5ZZZtiWzJBjVY4ovuPocn8LNeDkMS893XBiRBpG8yOyUQB2rD1xLI4vHzFoK967qOz7fCEjFcgiTqocu59GrcnoDg8tLRezt6MuOwerMssBUx0WZvlI4pb8kas3sX2c1RuenIRrK4B0kKUY69Gg6SZqHySxQRe/pMuHe+5z3dLppa+gjzz0l5FJGOZ/mnCyTQtWFhmVegqhEas5Oa1mdwooPLR6n97WAxQgRXAeKfRT4W/4FopL8/Qv9SCkjcdC+KTm2UHMWJn5n984l0gldDSiaUYRbJoVsLN/FtMHbI+IMKww+33nALK2vhjKmKOMI4QN80n5B/8jjoyFTTwNlomVALy0U3cJTYnrHMXIugbwTNxt1v3tAnnmi8PS0g==
—–END CERTIFICATE—–
Die dekodierten Signatur-Daten sind dann:
The certificate has expired (2022-06-09T18:44:12+00:00 ISO 8601).
1. Subject CN: Microsoft Exchange XML Signing > Issuer CN: Microsoft Code Signing PCA 2011
Decoded Certificate
{
„name“: „\/C=US\/ST=Washington\/L=Redmond\/O=Microsoft Corporation\/CN=Microsoft Exchange XML Signing“,
„subject“: {
„C“: „US“,
„ST“: „Washington“,
„L“: „Redmond“,
„O“: „Microsoft Corporation“,
„CN“: „Microsoft Exchange XML Signing“
},
„hash“: „23a28e10“,
„issuer“: {
„C“: „US“,
„ST“: „Washington“,
„L“: „Redmond“,
„O“: „Microsoft Corporation“,
„CN“: „Microsoft Code Signing PCA 2011“
},
„version“: 2,
„serialNumber“: „0x330000023A9AC43F5A75FEB57C00000000023A“,
„serialNumberHex“: „330000023A9AC43F5A75FEB57C00000000023A“,
„validFrom“: „210610184412Z“,
„validTo“: „220609184412Z“,
„validFrom_time_t“: 1623350652,
„validTo_time_t“: 1654800252,
„signatureTypeSN“: „RSA-SHA256“,
„signatureTypeLN“: „sha256WithRSAEncryption“,
„signatureTypeNID“: 668,
„purposes“: {
„1“: [
false,
false,
„sslclient“
],
„2“: [
false,
false,
„sslserver“
],
„3“: [
false,
false,
„nssslserver“
],
„4“: [
false,
false,
„smimesign“
],
„5“: [
false,
false,
„smimeencrypt“
],
„6“: [
true,
false,
„crlsign“
],
„7“: [
true,
true,
„any“
],
„8“: [
true,
false,
„ocsphelper“
],
„9“: [
false,
false,
„timestampsign“
]
},
„extensions“: {
„extendedKeyUsage“: „Code Signing, 1.3.6.1.4.1.311.76.57.1.11“,
„subjectKeyIdentifier“: „6B:41:8A:90:E0:75:8D:D5:2B:41:D9:E6:32:EC:D3:F4:36:40:31:04“,
„subjectAltName“: „DirName:OU = Microsoft Operations Puerto Rico, serialNumber = \“464868+464879\““,
„authorityKeyIdentifier“: „keyid:48:6E:64:E5:50:05:D3:82:AA:17:37:37:22:B5:6D:A8:CA:75:02:95\n“,
„crlDistributionPoints“: „\nFull Name:\n URI:http:\/\/www.microsoft.com\/pkiops\/crl\/MicCodSigPCA2011_2011-07-08.crl\n“,
„authorityInfoAccess“: „CA Issuers – URI:http:\/\/www.microsoft.com\/pkiops\/certs\/MicCodSigPCA2011_2011-07-08.crt\n“,
„basicConstraints“: „CA:FALSE“
}
}
Fazit:
Das ist der Grund warum das supertolle sicherheitserhöhende und von Microsoft ungepflegte Tool (weil ausgelaufene Signatur) das Eventlog stündlich vollschreibt.
Leider kann ich bei MS keinen Call aufmachen… Evtl. unterstützt Ihr mich ?! *ächz*
Ein leidgeplagter Monitoring-Admin…
Hallo nochmal,
hier Links zu Beiträgen, die ich bzgl. Zertifikatsproblem gefunden habe:
https://techcommunity.microsoft.com/t5/exchange-team-blog/addressing-your-feedback-on-the-exchange-emergency-mitigation/bc-p/3498825#M33257
https://docs.microsoft.com/en-us/answers/questions/887192/exchange-emergency-mitigation-xml-file-contains-ex.html
A lot of Grüße
Wolfgang ;)
Seit heute Nacht wurde das Heartbeat-Skript von Microsoft offenbar mit neuen, gültigen Zertifikaten ausgestattet. Siehe https://techcommunity.microsoft.com/t5/exchange-team-blog/addressing-your-feedback-on-the-exchange-emergency-mitigation/bc-p/3498825#M33257
Die stündlichen Fehlermeldungen sind nun weg.
Hallo zusammen,
wir haben eine Testumgebung im Mixed Mode.
Also 2 Exchange 2016 und 2 Exchange 2019.
Auf einem haben wir jetzt das CU22 installiert aber beim Befehl Set-OrganizationConfig -MitigationsEnabled $false kommt der Fehler
A parameter cannot be found that matches parameter name ‚MitigationsEnabled‘
Müssen erst alle auf neuste CU Level gebracht werden?
Nachtrag:
Jupp, gerade noch mal gecheckt: „Get-Mitigations.ps1“ ist vollkommen wertlos um bereitstehende Mitigationen anzuzeigen, bevor sie angewendet wurden.
.\Get-Mitigations.ps1
Es werden keine Risikominderung angewendet
(OrganizationConfig MitigationsEnabled ist auf $true)
Dann:
Set-ExchangeServer -Identity ExchangeServerA -MitigationsEnabled $true
Set-ExchangeServer -Identity ExchangeServerB -MitigationsEnabled $true
30 Min Später:
.\Get-Mitigations.ps1
Server : ExchangeServerA
Version : Version 15.1 (Build 2375.7)
ID : PING1
Type : Ping
Description : EEMS Heartbeat probe. Does not modify any exchange settings.
Status : Applied
Server : ExchangeServerB
Version : Version 15.1 (Build 2375.7)
ID : PING1
Type : Ping
Description : EEMS Heartbeat probe. Does not modify any exchange settings.
Status : Applied
Um die Auslieferung neuer Mitigations-Regeln zu checken, bevor man sie angewendet werden, hilft es wohl nur https://officeclient.microsoft.com/getexchangemitigations selbst zu parsen.
Chaos wo man hinschaut,
die Aussage, dass man mit „Get-Mitigations.ps1“ bereitstehende Mitigationen anzeigen kann, stimmt nicht. Das Skript zeigt nur Mitigationen an, die bereits angewendet wurden.
.\Get-Mitigations.ps1 zeigt – anders als überall angegeben – immer n-u-r Mitigationregeln an, die auf Servern b-e-r-e-i-ts angewendet werden.
Es werde keine n-e-u-e-n, einfach nur bereitstehenden Regeln angezeigt. Bei uns zeigt: .\Get-Mitigations.ps1 immer nur:
Es werden keine Risikominderung angewendet
Obwohl diese Testregel „PING1“ eigentlich bereitstehen sollte. „PING1“ wird bei uns aber nicht angewendet (auf Organisationsebene sind Mitigationen erlaubt, auf den Exchange Servern nicht), daher wird die „PING1“ von Get-Mitigations.ps1 auch nicht angezeigt.
Das sind unsere Einstellungen für die Server und die Organisation:
Set-OrganizationConfig -MitigationsEnabled $true
Set-ExchangeServer -Identity ExchangeServerA -MitigationsEnabled $false
Set-ExchangeServer -Identity ExchangeServerB -MitigationsEnabled $false
.\Get-Mitigations.ps1 ist also wertlos, um abzufragen, ob neue Regeln ausgeliefert wurden, b-e-v-o-r man sie anwendet.
Will man einfach nur auswerten, ob neue Regeln da sind, bevor man sie anwendet, muss man wohl selbst https://officeclient.microsoft.com/getexchangemitigations selbst parsen.
.\Test-MitigationServiceConnectivity.ps1
Ergebnis: Erfolgreich.
Meldung: Auf den Endpunkt des Minderungsdiensts kann von diesem Computer aus zugegriffen werden.
Logs dem Mitigations-Dienstes sehen bei uns auch gut aus:
2021-11-02T11:02:38.891Z,ExchangeServerA,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations successful
2021-11-02T11:02:38.894Z,ExchangeServerA ,ApplyMitigation,S:LogLevel=Warning;S:Message=No mitigation applied. MitigationEnabled is False
Hallo,
was macht man wenn die Exchange Server nicht ins Internet dürfen auch nicht gezielt auf die Seite https://officeclient.microsoft.com/*.
Hätte an sowas gedacht wie Informationen von extern mit eine Internet Access Client abholen und intern unter einer eigenen URL bereitstellen.
Was denkt ihr ist so ein Szenario denkbar? Wie?
Dankeschön.
Hallo, der Dienst läuft bei uns soweit.
Ich würde gerne die passenden Events monitoren und bei Auftreten eine Mail (über einen anderen Maildienst als den Exchange…) senden.
Allerdings wird ständig diese Test-Mitigation PING1 entweder mit 1005 (Applylist) oder 1006 (Blocklist) getriggert.
Kann ich PING1 gefahrlos aus der Applylist löschen, damit ich reale Events wie geplant monitoren kann?
Oder wie würdet ihr vorgehen?
Hallo zusammen,
bei mir funktioniert die .\Test-MitigationServiceConnectivity.ps1 einwandfrei und auch der direkte Zugriff über den IExplore funktioniert.
ABER: \Get-Mitigations.ps1 liefert:
WARNUNG: Die Verbindung mit dem Minderungsendpunkt war nicht erfolgreich. Um die Konnektivität zu aktivieren, sehen
Sie: https://aka.ms/HelpConnectivityEEMS
In den Event-Logs finde ich ID 1008-Einträge und entweder
—> (Interne Ausnahme #0) 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
oder
—> (Interne Ausnahme #0) System.Net.Http.HttpRequestException: Fehler beim Senden der Anforderung. —> System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten SSL/TLS-Kanal konnte keine Vertrauensstellung hergestellt werden.. —> System.Security.Authentication.AuthenticationException: Das Remotezertifikat ist laut Validierungsverfahren ungültig.
Wenn jemand da eine Lösung oder hat jemand ähnliche Probleme?
Moin,
bei unserer Fortigate musste ich noch die Symantec-Web-Services zulassen! Dann hat es funktioniert.
Hallo, es scheitert bei uns wie immer am Proxy. https://docs.microsoft.com/de-de/exchange/plan-and-deploy/deployment-ref/ms-exch-setupreadiness-MitigationsCloudEndpointUnreachable?view=exchserver-2019
Hallo,
ich bekomme es mit dem Mitigation Service nicht hin.
ich bekomme folgende Fehlermeldung :
021-10-14T14:57:35.405Z,WIN-T-EX01VM,FetchMitigation,S:LogLevel=Information;S:Message=Fetching mitigations from https://officeclient.microsoft.com/getexchangemitigations
2021-10-14T14:57:35.405Z,WIN-T-EX01VM,FetchMitigation,S:LogLevel=Information;S:Message=No diagnostic data sent. DataCollectionEnabled is false
2021-10-14T14:57:35.562Z,WIN-T-EX01VM,FetchMitigation,S:LogLevel=Error;’S:Message=Exception encountered while fetching mitigations : This XML is not deemed safe to consume since Response xml“s signing cert is invalid or not from microsoft‘;S:Source=Microsoft.Exchange.Mitigation.Service.Mitigations.MitigationEngine
1. Es gibt kein Webproxy
2. Ausgehend sind in der FW Port 80 und 443 erlaubt
3. Das Root Zertifikat liegt im Cert. Store.
4. Über den Webbrowser komme ich ohne Fehlermeldung auf die Seite https://officeclient.microsoft.com/getexchangemitigations
Woran könnte es noch liegen ?
Vielen Dank
Vielleicht hilft es dir weiter. Ich habe das gleiche Problem, das ich mir anschaue. Es scheint, dass die Validierung der Zertifikatskette fehlschlägt
certutil -verify c:\something\office.cer
Incomplete certificate chain
Cannot find certificate:
CN=Microsoft RSA TLS CA 02, O=Microsoft Corporation, C=US
ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)
Hallo Frank,
ist es vielleicht sinnvoll Informationen von „Exchange Emergency Mitigation“ als Modul im Exchange Reporter zu integrieren?
So hätten die Admins es eher im Blick wenn sich etwas geändert hat.
Nur eine Idee :-)
Hallo Paul,
ist bereits in Arbeit.
Gruß,
Frank
Hallo Frank,
das ist sehr schön zu hören und ich schätze deinen Exchange Reporter und die Artikel sehr. Wir müssen nur jetzt auch in der Firma den Einsatz des EM bewerten und das wird keine leichte Sache gerade weil es sehr neu ist und Auswirkungen auf den laufenden Betrieb haben kann.
MfG Paul
Habt ihr das ernsthaft aktiv auf euren exchange servern? ein system das aus dem internet einfach mal so services stoppen kann und konfigs verändern kann? und vor allem, wenns das mal gemacht hat und ein update kommt, dass das problem behebt, soll der admin mal schauen, wie er den schnellschuss von microsoft wieder rückgängig macht?
na ich weiss nicht, was das mit sicherheit zu tun hat. bin mal gespannt, wann die „erste mitigation fernab des hauses microsoft“ dann verteilt wird.
Hallo zusammen,
gerade CU22 auf einem 2016er installiert.
Org und Server stehen nach Installation beide auf true und auch sonst alles so wie es sein soll.
VG!
Gero
Hier gibt es aber schon einen Eintrag, dass der Eintrag wohl öfters auf False steht und Sie gerade den Fehler suchen.
https://techcommunity.microsoft.com/t5/exchange-team-blog/addressing-your-feedback-on-the-exchange-emergency-mitigation/ba-p/2796190
„We’re currently investigating this issue, but in the meantime, if you see this happen in your environment and you want automatic mitigation to take place, you can easily update the value to True by running the following command:
Set-OrganizationConfig -MitigationsEnabled $True“
Danke.
Ohje – eine Funktion bringt das Ende zu Ende!
Mir zeigte diese Funktion eindeutig, dass der Gesamtsicherheitszustand in der IT immer kritischer wird.
Bei ZERO Days sind ggf. die Angreifer alle schneller als die Abwehrmaßnahmen. Das hilft keine Firewall mit ContentFiltering oder lokaler Malware Schutz mit CloudUpdates und Verhaltungserkennung und sonstigen Schnickschnack mit DXL, SASE, XDR usw. usw. schlussendlich kommt der Hacker durch und betreibt Destruktion. Ein „Emergency Mitigation“ ist damit für mich nicht der letzte Sicherheitsschrei, sondern nur das Ende vom Ende. Es möge mir mal keiner erzählen, dass die „Emergency Mitigation“ nicht auch durch Dritte vulnerable wäre. Ich bleibe daher bei meiner Auffassung: Technik kann nicht durch noch mehr Technik noch sicherer gemacht werden. Ja und der große Spasss steht uns eh noch ins Haus, wenn nämlich verstärkt die KI Angriffe ggf. per Quantencomputer auflaufen – ich hoffe da bin ich dann längst in Rente.
Trotzdem vielen lieben Dank @franky für diesen – wie immer – guten Beitrag.
Lieber Oliver, eines sehe ich ganz ähnlich wie Du. Es braucht Menschen, die die technischen Security-Bausteine effektiv bereitstellen. Damit lässt sich Geld verdienen. In wessen Geschäftsmodell oder IT Strategie das nicht passt, der kann mit Exchange Online einen leistungsfähigen und sicheren Dienst buchen, der seinerseits einen Administrator nicht überflüssig macht. Ich bin aber optimistisch, dass die AMSI-Integration von Exchange -sobald sich auch Sophos darauf eingestellt hat- und der EM-Dienst die Sicherheitskette -vor allem gegen zero-days effektiver machen.
Also wie gesagt, ich hab das jetzt auf mehreren Orgs sowie 2016 als auch 2019 getestet und überall war das auf false.
Vielleicht ist das schon die erste „Emergency Mitigation“ ;)
Das wär natürlich clever. Aber am Ende wird es, wenn das öfter vorkommen eben dazu führen, dass im Worst Case doch wieder jede Menge Server ungeschützt rumstehen.
Hallo NorbertFe,
bei meinem Server steht der Wert auf True. Am System wurde nur das EX16 CU 22 eingespielt.
Bei einem EX 19 nur das CU11 installiert steht der Wert ebenfalls auf „True“.
Ja beim Server. Das hilft aber nix, wenn auf Organization Level nicht auch True gesetzt ist. Liest denn hier niemand die Artikel? ;)
Hi Norbert,
in meinem Lab (Ex2019) ist es auf Organisations-, sowie auf Server Level per Default aktiviert. Ich hab bisher nur das Lab aktualisiert.
Gruß,
Frank
Also ich hab jetzt zwei Orgs 2019 mittels Get-OrganizationConfig | fl MitigationsEnabled getestet und bekomme bei beiden False zurück. Das widerspricht etwas der Aussage Microsofts, dass es per Default enabled ist. Kann das mal jemand gegenchecken?
Danke
Bei mir war es genauso. Exchange 2019 Get-OrganizationConfig | fl MitigationsEnabled -> False
Das selbe hier bei Exchange 2016. Musste es manuell auf true setzen.
Bei mir kommt als Antwort True
Wäre jetzt zu klären, wie und warum es dort Unterschiede gibt.
Bei meinem 2019er (Mitglied in DAG) -> Erst einer upgedatet steht ebenfalls der Wert auf false.
Wenn ich den Technet-Beitrag richtig verstanden habe, werden die Mitigations automatisch angewendet (HTTP-Requests und ggf. Dienste-Deaktivierung), müssen aber durch den Administrator manuell rückgängig gemacht werden, sobald diese nicht mehr benötigt werden.
Da kann ich nun also im Vorfeld Blogs verfolgen, welche Schwachstellen es gibt (Hafnium!), und die KBs lesen, was alles bei Updates zu beachten ist oder mir bei Fehlern hinterher die Mühe mit der Fehlersuche zu den Mitigations machen, um die gröbsten Kollateralschäden zu beheben. Worauf habe ich wohl mehr Lust?
muss da eigentlich dann auch der MS Defender auf den Exchange laufen?
Habe meine Testserver auf CU22 mit den „URL Rewrite Tool“ aktualisiert aber der Dienst „Microsoft Exchange Emergency Mitigation Service“ ist bei mir auf den Servern 2016 nicht vorhanden.
Der ist ja auch erst nach der Installation von CU22/CU11 vorhanden und heißt auf deutschsprachigen Systemen „Microsoft Exchange-Notfallrisikominderungsdienst“
Danke Norbert dieser Dienst ist existent ;-)
also bei mir nennt es sich „Microsoft-Exchange-Notfallschutzdienst“ und verweist auf die Datei Microsoft.Exchange.Mitigation.Service.exe – denke das gilt auch :-)
und ich warte jetzt auf den Tag, wo das bei einem unserer Kunden mal kurz IMAP / POP3 / SMTP oder den IIS runterfährt … Das gibt ein schönes Chaos
Hi Macros, treffe einfach mit Deinen Kunden schriftliche Vereinbarungen im Vorfeld. Wenn der Kunde lieber einen Domain Highjack riskiert als die Verfügbarkeit, dann kannst Du das Feature ja in seinem Auftrag abschalten. Grüße
Hallo Macros,
es gibt kein Vorfeld (ala Markus) außer Du spürst Verlangen Dich über Microsoft hinwegzusetzen.
Teile den Benutzer*innen mit, dass Microsoft mit dem zurückliegenden Update einen Remote-Ausschalter integriert hat und dieser standardmäßig seitens Mircrosoft auf EIN gestellt ist und Auswirkungen bis zum Totalverlust haben kann.
Es gibt Alternativen!
LG Vanessa
sehr schön und ausführlich. Danke!
Danke für die Ausführliche Beschreibung.
Nur noch ein Hinweis: im Blogeintrag von MS zu den CUs wird explizit erwähnt, dass man die „x64 MSI Version“ vom „IIS URL Rewrite“ Modul installieren soll.
VG
Martin
Hallo Martin,
kannst du den Link mal posten denn ich habe es über den Webinstaller gemacht (Ex2016) und nun die Version 7.2.1993 installiert.
MfG Paul
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-september-2021-quarterly-exchange-updates/ba-p/2779883
Nino Bilic Microsoft
Sep 28 2021 08:49 AM
@sjhudson Correct, x64 MSI version. I added that to the bullet. Thanks!