[English]Redmond hat die neueste Version des Microsoft Support Emergency Response Tool (MSERT) um Sicherheitsinformationen erweitert. Das Tool lässt sich nun ausführen, um die neuesten Bedrohungen in Sachen Exchange Server zu erkennen und zu beseitigen. Konkret findet das Tool installierte Web Shells in Exchange-Instanzen.
Anzeige
Der Exchange Meldown
Meltdown bezeichnet zwar eine Hardware-Schwachstelle, ist aber in der deutschen Übersetzung mit Einschmelzen, Durchbrennen oder Zusammenbruch gleichzusetzen. Als Kernschmelze lässt sich auch das interpretieren, was mit Microsofts Exchange Server jetzt passiert ist. Ich hatte es im Blog-Beitrag Neues zum Exchange-Hack – Testtools von Microsoft & Co. angesprochen. Hacker der mutmaßlich staatsnahen chinesischen Hackergruppe Hafnium haben monatelang diverse Schwachstellen (siehe Exchange-Server 0-day-Exploits werden aktiv ausgenutzt, patchen!) in On-Premise Exchange Servern zum Eindringen benutzt.
Die Schwachstellen können erst seit dem 2. März 2021 durch Sicherheitsupdates, die Microsoft veröffentlicht hat, geschlossen werden. Ich hatte in diversen Blog-Beiträgen darüber berichtet (siehe Artikelende). Und im Volexity-Blog (deren Sicherheitsforscher haben den Angriff und die Schwachstellen entdeckt) findet sich dieser Beitrag zum Thema.
Infizierte Exchange-Server, Quelle: Rapid7 – Zum Vergrößern klicken
Sicherheitsanbieter Rapid7 geht in diesem Artikel von 170.000 gefährdeten Exchange-Servern aus, wobei es in den USA und in Deutschland wohl „Hot-Spots" mit mehr als 10.000 Instanzen gibt (aktuell, 12.3., sind es fast 300.000). Weitere Informationen und Analysen liefert dieser Microsoft-Artikel, sowie diese US-CERT-Warnung. Interessant ist in diesem Kontext der Kommentar von Stephan, der darauf hinweist, dass die taiwanesische Firma DEVCORE zwei der Schwachstellen bereits im Dezember 2020 gefunden und an Microsoft gemeldet hat. Also lange bevor die Massenangriffe gestartet wurden (siehe die Timeline hier).
Anzeige
Die US CISA weist in diesem Tweet darauf hin, dass alle Unternehmen Maßnahmen ergreifen sollten, um die beobachteten Schwachstellen mit Microsoft Exchange On-Premises-Produkten zu beheben. Dies gilt auch für hybride Konfigurationen, bei denen sich Exchange-Server in Netzwerken befinden, aber Daten in O365-Cloud-Umgebungen übertragen werden. Die Directive ist hier abrufbar.
Microsoft MSERT hilft Defender beim Exchange-Scan
Aktuell brennt da natürlich weltweit (bildlich gesprochen) die Hütte – und Administratoren dürften, sofern sie es mitbekommen haben, am heutigen 8. März 2021 mit heißen Ohren ihre Exchange Server-Instanzen auf eine Infektion überprüfen. Microsoft hat Power-Shell-Scripte veröffentlicht, die das tun sollen (aber unter Exchange Server 2010 nicht laufen). Ich hatte kurz im Beitrag Neues zum Exchange-Hack – Testtools von Microsoft & Co. berichtet.
Über aktualisierte Signaturdateien kann der Microsoft Defender die nachfolgenden Web-Shells erkennen, die von den Angreifern über 0-day-Schwachstellen auf Systemen installiert werden:
- Exploit:Script/Exmann.A!dha
- Behavior:Win32/Exmann.A
- Backdoor:ASP/SecChecker.A
- Backdoor:JS/Webshell
- Trojan:JS/Chopper!dha
- Behavior:Win32/DumpLsass.A!attk
- Backdoor:HTML/TwoFaceVar.B
Aber es gibt wohl Unternehmen, die keinen Microsoft Defender als Virenschutz einsetzen. Für diesen Fall steht das kostenlose Microsoft Support Emergency Response Tool (MSERT) zur Verfügung. Dieses ermöglicht einen Systemscan auf die obigen Bedrohungen.
In obigem Tweets weist SwiftOnSecurity darauf hin, dass Microsoft sein Microsoft Support Emergency Response Tool (MSERT) um Sicherheitsinformationen erweitert hat. Damit lässt sich das Tool ausführen, um die neuesten Bedrohungen in Sachen Exchange Server zu erkennen und zu beseitigen. Konkret kann der aktualisierte Microsoft Safety Scanner (MSERT) Web-Shells erkennen, die bei den jüngsten Exchange Server-Angriffen der Hafnium-Gruppe verwendet werden. Microsoft stellt auf der Webseite Microsoft Safety Scanner den Safety Scanner zum Download bereit. Ich habe beim Schreiben des Beitrags kurz recherchiert – die Kollegen von Bleeping Computer haben hier beschrieben, wie das Tool eingesetzt werden kann.
Wird eine Infektion erkannt, reicht es aber nicht, die Tools ihre Arbeit machen und die Web-Shells entfernen zu lassen. Es ist eine forensische Analyse erforderlich, ob nicht weitere Änderungen am System und ggf. am Active Directory durch die Angreifer vorgenommen wurden.
Ähnliche Artikel:
Exchange-Server 0-day-Exploits werden aktiv ausgenutzt, patchen!
Wichtige Hinweise Microsofts und des BSI zum Exchange-Server Sicherheitsupdate (März 2021)
Exchange-Probleme mit ECP/OWA-Suche nach Sicherheitsupdate (März 2021)
Neues zum Exchange-Hack – Testtools von Microsoft & Co.
Microsoft MSERT hilft bei Exchange-Server-Scans
Exchange-Hack: Neue Patches und neue Erkenntnisse
Anatomie des ProxyLogon Hafinum-Exchange Server Hacks
Exchange-Hack: Neue Opfer, neue Patches, neue Angriffe
Neues zur ProxyLogon-Hafnium-Exchange-Problematik (12.3.2021)
Gab es beim Exchange-Massenhack ein Leck bei Microsoft?
ProxyLogon-Hack: Repository für betroffene Exchange-Administratoren
Anzeige
Wer es jetzt von den werten Kollegen noch nicht mitbekommen hat, sei noch auf folgende Ergänzung vom Wochenende hingewiesen: https://www.borncity.com/blog/2021/03/07/neues-zum-exchange-hack-testtools-von-microsoft-co/ Denmach muss das Updatepaket von der letzten Woche mit administrativen Rechten, also z.B. aus einer administrativen CMD gestartet werden, um wirklich alle verwundbaren Dateien zu ersetzen. Die Frage ist nun, was ist, wenn man das letzte Woche nicht so getan hat? Lässt sich das MSU Paket erneut installieren, oder meldet das System dann, dass das Paket schon installiert ist, und verweigert somit eine erneute Installation, obwohl einige verwundbaren Dateien letzte Woche nicht ersetzt wurden?
Ein Hinweis:
Das MS MSERT sollte man in einer ruhigen Minute starten, da es den Exchangeserver vollends auslastet bei einem DeepScan! Eventuell gekoppelte IP-Voice-Anlagen wie z.B. SWYX, stellen dann telefonietechnisch auch gleich das erwartete Anwendererlebnis schwer in den Schatten…
Also am Besten am WE, wenn gerade keiner auf einem der Exchangeserver herumturnt…;-).
Ja klar warten wir einfach noch einige Tage oder Wochen wo es dem Nutzer dann gefällt
man man man
Ganz meiner Meinung, aber leider stehe ich in der Nahrungskette aufgrund fehlenden Studiums weit am Ende…
Für den Fall kann man ja schonmal das hier durchlaufen lassen, das tut im Prinzip das selbe, halt speziell für diesen Fall (und nicht wie die große Keule MSERT) und das ohne große Rechenlast:
https://github.com/cert-lv/exchange_webshell_detection
Das löscht übrigens die gefundenen aspx Files auch nicht, so dass man da nochmal forensisch drüber kann. MSERT macht nämlich gleich auch tabularasa mit den Dateien.
Ich hätte da mal noch eine Frage:
Hat eine UTM mit reverse proxy for exchange einen davor schützen können, oder wurde die auch ausgehebelt?
Danke.
Wurde auch schon auf heise im Forum, in Verbindung mit Offloading, erwähnt. Dort schrieb der Admin, was an weiteren Maßnahmen erforderlich ist, damit die Anfragen nicht einfach weiter gereicht werden. Klang für mich logisch.
@Günther
Bist du sicher, dass du den richtigen Kommentar verlinkt hast?
Hat er…in den Comments darunter steht es…;-).
Wir haben das in unserer Hauptniederlassung hier auch so eingerichtet, allerdings habe ich die Updates direkt am Dienstag eingespielt und CU19 schon vor Wochen.
Wer deprimiert werden möchte startet MSERT.exe in meinem "Minenfeld" (https://skanthak.homepage.t-online.de/minesweeper.html) und lässt danach die Finger von solchem unsicheren, von blutigen Anfängern verbrochenem Schrott.
Oder fragt diese Frickler, wieso sie die zahlreichen Sicherheitshinweise ihrer eigenen Klitsche https://web.archive.org/web/20190508180320/https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/,
https://msdn.microsoft.com/en-us/library/ff919712.aspx,
https://technet.microsoft.com/en-us/library/2269637.aspx, https://support.microsoft.com/en-us/kb/2269637, https://support.microsoft.com/en-us/kb/2389418, https://support.microsoft.com/en-us/kb/2533623, …) seit über 13 Jahren ignorieren!
Zum "Offender" und den DANK diesem vorhandenen Sollbruchstellen siehe https://skanthak.homepage.t-online.de/offender.html
;-)
[++]
Warum arbeiten Sie eigentlich noch nicht für Microsoft?
Möglicherweise antwortet Stefan – als Externer hat er es immerhin in den Kreis der Top 100 geschafft, die Microsoft Schwachstellen meldeten – und für manche dieser Schwachstellen gab es sogar Bug-Bounty-Prämien. Allerdings interpretiere ich so manche Mail, die per cc bei mir einschlug, als "die Kommunikation mit dem MSRT – Microsoft Un-Security Response Team" ist frustbehaftet.
Als jemand, der mal in einem Großunternehmen geackert hat, würde ich mir drei Mal überlegen, bei einem solchen Laden anzuheuern ;-).
MSERT zeigt während es läuft an "Files Infected: 8". Am Ende dann aber "No infection found." Vertrauenserweckend.
Hallo zusammen,
genau das gleiche Problem hatte ich auch. Infections während des Scans und dann folgendes Ergebnis:
->msert.log
Results Summary:
—————-
No infection found.
Successfully Submitted MAPS Report
Successfully Submitted Heartbeat Report
Habe genau einen Beitrag dazu im Internet gefunden: https://web.archive.org/web/20211201110403/https://social.technet.microsoft.com/Forums/azure/en-US/7ee17928-7482-49c1-8512-862c607d6085/msrt-reports-an-infected-file-during-scan-then-reports-no-infections-on-completion?forum=w7itprosecurity
Da hat jemand eine Erklärung, die natürlich sinnvoll erscheint, aber nicht von MS stammt.
Viele Grüße
Sebastian
Mir ging nur eine Info spontan im Hinterkopf herum. Irgendwo in den Kommentaren habe ich gelesen, dass MSERT die Infektion beseitigt (was für die Forensik ungut ist). Möglicherweise ist das der springende Punkt – mag mich aber täuschen.
Wenn er die Infektion dann aber nicht listet (GUI und Log), wie hier im zweiten Screensheet (https://www.bleepingcomputer.com/news/security/microsofts-msert-tool-now-finds-web-shells-from-exchange-server-attacks/) gelistet, dann gebe ich bald jegliche Hoffnung bei MS auf.
Hier bei Reddit hat jemand übrigens bestätigt, dass für EXC 2016 CU 19 (genau meine Version) ein Scan des ISOs Infektionen beim Scannen listet.
"Aparently the newest version of MSERT (build 1.333.160.0) likes to give sysadmins heartattacks by detecting(and showing) false positives on Exchange2016 CU19 during scanning(Files Infected: 1) but then gives an all clear once its finished scanning(Gui and logfile)."
Klingt übel – da gebe ich dir Recht.
Ich hatte das Phänomen mit den angezeigten Infektion auch und am Ende waren es null. Hat mich auch etwas irritiert. Bei einem anderen waren es direkt 230 und am Ende auch null.
Habe dann noch mal mit Kasp. ResC. das System gescannt und da tauchten dann auch die 230 auf.
Und was soll ich sagen? Er hat alles gekennzeichnet was in irgendeiner weise nur halbwegs das System manipulieren kann. z.B. hatte ich in einen Ordner ein paar Batch gespeichert, die ich selbst geschrieben habe um Windows anzupassen. Selbst die hat er erkannt.
MSERT wie auch das allmonatlich per Windows Update als KB890830 verteilte MRT und natürlich MSE alias Windows/Microsoft Defender richten MEHR Schaden an als sie nutzen, und glänzen wie früher der Schrott von Avira mit "false positives".
Ich habe Hunderte "Einzelfälle" bei Microsoft gemeldet, ohne Reaktion dieser üblen Klitsche.
Danke für den Link Sebastian. Klingt durchaus sinnvoll was er schreibt und super UX-unfreundlich in der Umsetzung.