Microsoft provides the tool "Exchange On-premises Mitigation Tool (EOMT) for securing unpatched Exchange servers for download:
EOMT first secures the Exchange Server against the vulnerability CVE-2021-26855 using URL rewrite and then downloads the Microsoft Safty Scanner to check the server for a successful attack. However, EOMT does not install the available updates but only implements a workaround, so the updates must be installed separately.
EOMT is therefore intended to help admins who are unable to patch the servers quickly, for example because the systems are distributed among many customers. As with "ExchangeMitigations.ps1", EOMT is a PowerShell script that also attempts to rectify the effects of a successful attack. Someone affected would have to try out whether this really works. Perhaps a reinstallation of the server can be avoided in this way. However, the extent to which you want to trust the tool is up to you. EMOT only scans the Exchange server, it cannot determine whether an attacker has already penetrated deeper into the network.
Important: Vulnerable Exchange servers must be supplied with the updates, EOMT should only provide a little more time here. Even those who have already installed the updates can use EOMT to check whether there are any indications of a successful attack:
EOMT can simply be executed via PowerShell and then runs automatically. The server must have access to the Internet so that the Safty Scanner and the IIS rewrite module can be downloaded. The script then runs automatically:
After the script has run, the log file can be found under C:\
The EOMTSummary.txt file also contains the directory where further logs were recorded.
Hallo,
bei uns laufen die lets encrypt scripte nicht mehr erfolgreich durch. Es kommt immer der Fehler „order not ready“ Ich habe den Verdacht, dass es am EOMT tool liegt. Der Zugriff auf den IIS über Port 80 ist seitdem nicht mehr möglich. Kann mir das jemand bestätigen oder sogar eine Lösung anbieten.
Hallo zusammen,
habe einen EX2019 mit aktuellem CU9.
Trotz diesem, neuen, EOT:
Version 21.03.18.2345
führt er eine Mitigation durch… was soll ich denn nun glauben???
Ist denn das KB5000871 noch nach dem CU9 erschienen?
Würdet ihr ein Rollback empfehlen?
Danke für Hinweise, Gruß Thomas
Hallo,
ich mach mal mit mir selbst hier weiter ;-)
2 x EX2016 melden kein Probleme mit diesem EOMT.
2x EX2019 meinen da ist etwas nötig und verändern die webconfig in c:\inetpub\wwwroot.
Diese Änderungen sind in der webconfig der EX2016 aber nicht vorhanden…
Ich werde da nicht so recht schlau draus… habe mich aber entschieden die Änderungen drin zu lassen (eigentlich sind es zusätzliche Einträge).
Gruß Thomas
mach das nicht. das script wertet auf Exchange 2019 die installierte Version falsch aus und meldet dann anfällig.
siehe auch: https://github.com/microsoft/CSS-Exchange/pull/406 bzw. https://github.com/microsoft/CSS-Exchange/issues/396 solang das nicht behoben ist, oder du in dem script intern die version für ex2019cu9 dementsprechend angleichst, wir das script nur mist machen
Ich hätte eine Frage – mit dem Test-ProxyLogon kann man ja prüfen ob laut den Logs ein Angriff stattgefunden hat.
Standardmässig werden ja nur 30 Tage gespeichert, jetzt habe ich die Logs der letzten 3 Monate zurückgesichert, wenn ich diese aber in das Log Verzeichnis einspiele werden diese automatisch gelöscht.
Wie kann ich diese Logs prüfen, bzw. gibt es ein Commando mit dem ich sagen kann bitte die letzten 3 Monate prüfen in folgendem Verzeichnis?
DANKE
du brauchst mindestens v21.03.18.1452 damit es korrekt ermittelt wird.
hab heute morgen mal noch Rollback gemacht vorsichtshalber.
so nun aktuell kann ich dort die Version: 21.03.18.2345 runterladen, also wohl nochmal neuer…
damit wendet er es wieder an und gibt noch folgendes zusätzlich aus:
AUSFÜHRLICH: For long-term protection, please use Microsoft Update to install the latest Security Update for Exchange
Server (KB5000871).
Für Exchange Server 2019 CU9 gibt es kein Sicherheitsupdate KB5000871….
hab jetzt wieder Rollback gemacht und lass es so.
Auf der CU9 Download Seite von MS steht ja das die März Security Updates enthalten sind.
Nur bin normal ein Freund von sowas nochmal zu überprüfen statt blind drauf zu vertrauen das es auch mit dem CU9 passt.
würde mich an microsoft wenden.
warst nicht du der, der im anderen Thema schrieb:
Im Script gesehen: E19CU9 = „15.2.858.5“ … bei mir ist 15.2.858.2 ?!
entweder hat es ein problem bei deiner CU9 installation, oder microsoft liefert überall falsche Info zu den Build Nummern, denn laut
https://docs.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates?view=exchserver-2019
heisst es:
PowerShell
Copy
Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion
EXCHANGE SERVER 2019
Product name Release date Build number
(short format) Build number
(long format)
Exchange Server 2019 CU9 March 16, 2021 15.2.858.5 15.02.0858.005
ne hab nur in dem Thema hier kommentiert.
Wenn ich das CU per Exchange Shell Abfrage zeit er es mir schon korrekt an:
Edition : Enterprise
AdminDisplayVersion : Version 15.2 (Build 858.5)
hab jetzt gerade mal noch mit dem Script „http-vuln-cve2021-26855“ per nmap von außen getestet und da sieht es gut aus.
https://github.com/microsoft/CSS-Exchange/issues/396
ich glaub das ist das problem bei 2019 und CU9
Hallo,
na da hätte ich mal früher hier kucken sollen.
EOMT in aktueller Version 21.03.17.2012 bringt mir bei meinem
Exchange 2016 mit CU20 „is vulnerable“ und wendet die mitigations an.
Kann mir jemand sagen ob das jetzt ein Problem werden kann?
Danke und VG!
Gero
lass deine version vom script nochmal laufen mit dem parameter RollbackMitigation
dann hol dir von github die aktuelle version, wo das gefixed ist und cu20 als sicher angesehen wird, und lass dann halt nochmal diese laufen.
Genau so hatte ich es dann gemacht.
Danke :)
Hatte es damals beim Exchange 2019 CU 7 mit dem Sicherheitsupdate geschlossen und es kam beim testen auch das es soweit passt.
Nun gerade CU7 auf CU9 geupdated, Sicherheitsupdates gabs keins und wenn ich nun teste mit 21.03.18.0954 sagt er bei mir: is vulnerable: applying mitigation
Hab die aktuelle Version von EOMT genommen gerade…
Jemand eine Idee ?
nicht auf aktuellerem CU level ausführen. das derzeitige EOMT hat eine falsche Prüfroutine für den Check ob ein Server Anfällig ist oder nicht.
Ich bin noch hin- und hergerissen zwischen Scan/Patch und neu Aufsetzen.
Bei mir sind möglicherweise 2 Exchangeserver betroffen, die erstmal komplett vom Netz genommen wurden.
Wie wahrscheinlich schätzt ihr denn die Situation nach Scan/Bereinigung mit EOMT / Microsoft Safety Scanner (FullScan) und Installation aller Patche ein? Kann man so einen Exchange wieder an’s Netzt lassen, oder doch am Ende auf jeden Fall neu aufsetzen?
Hallo,
ich bekomme die von MS bereit gestellten Scripte wie z.B. EOMT.ps1 nicht zum Laufen.
Der Aufruf wird immer mit einer Fehlermeldung „Sie müssen auf der rechten Seitte des Operators „-“ einen Wertausdruck angeben
Hallo Frank,
wenn ich mich im Bekanntenkreis umhöre und sehe das fast 100% der ungepatchten Server bereits ab dem 3. oder 4. März angegriffen wurden bezweifele ich den Sinn des Tools.
Pikanterweise scheinen ja die ungepatchten 2010er wesentlich unanfälliger weil sie nicht die gesamte Bandbreite an Sicherheitslücken aufwiesen. Oder die Hacker hatten mit den Firmen Mitleid die immer noch so alte Systeme einsetzen und dachten sich dass da eh nichts zu holen ist ;-)
Es ist aber schön mit dem Tool dem Kunden noch mal zeigen zu können das nach jetzigem Kenntnisstand alles in Ordnung ist und man den Zugriff von extern wieder freigeben kann. Oder sollte man lieber noch ein paar Tage abwarten bis näheres bekannt ist?
Aber ich habe den Eindruck dass es ja je nach Hackergruppe sehr unterschiedliche Ansätze gibt so dass eine generelle Abschätzung sehr schwierig ist. Und wenn man keine Firewall hat die alles penibel dokumentiert (so wie bei den meisten meiner Kunden die VPN-Router mit einfacher Firewall nutzen) wird es bei fehlenden WebEx ja auch sehr schwierig im Nachhinein noch den möglichen Schaden bei einem Befall nachzuvollziehen. Der MS Safety Scanner ist ja auch nicht unbedingt das Mittel der Wahl weil ja die gefundenen Bedrohungen einfach entfernt werden oft ohne dass man erfährt was da gelöscht wurde (unabhängig von der sehr langen Laufzeit beim Full Scan). Jedenfalls wurde auf etlichen Systemen was gemeldet mit Angabe der Bedrohung, auf vielen aber während des Laufes eine Anzahl an Bedrohungen gelistet, und dann war er plötzlich fertig und sagte alles wäre gut und keine Bedrohungen gefunden. Gibt es da bekannte Probleme?
Hi,
„Jedenfalls wurde auf etlichen Systemen was gemeldet mit Angabe der Bedrohung, auf vielen aber während des Laufes eine Anzahl an Bedrohungen gelistet, und dann war er plötzlich fertig und sagte alles wäre gut und keine Bedrohungen gefunden. Gibt es da bekannte Probleme?“
Ja ist bekannt. Hier sind noch „bugs“ im Scanner. Habe einige Einträge dazu im Inet gefunden, da ich auch etwas verwundert war.
Microsoft hat hier bestätigt, das die Anzeige am Ende entscheidend ist. Leider sieht man auch nicht welche Dateien hier wohl was haben, da der Log erst am Ende geschrieben wird und hier immer alles OK ist.
https://answers.microsoft.com/en-us/protect/forum/all/what-is-wrong-with-the-microsoft-safety-scanner/27c95df9-7d49-4d02-b734-bcb16495cfc3
Near the end of the scanning process around 95% complete, the Microsoft scanners all perform a MAPS (Microsoft Active Protection Service) request via internet to the the Microsoft cloud servers in order to upload their initial findings and request confirmation that these findings are either truly malware or instead possible false positive detections or incomplete fragments of inactive malware.
Though the entire process isn’t displayed, the clues to this are the following 2 lines in your first log above.
„No infection found.
Successfully Submitted MAPS Report“