Microsoft MSERT hilft bei Exchange-Server-Scans

[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
Infizierte Exchange-Server, Quelle: Rapid7Zum 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).

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.


Anzeige

Defender Scan auf Exchange-Hack

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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Anzeige


Dieser Beitrag wurde unter Sicherheit abgelegt und mit Sicherheit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

20 Antworten zu Microsoft MSERT hilft bei Exchange-Server-Scans

  1. 1ST1 sagt:

    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?

  2. Mr.Blacksmith sagt:

    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…;-).

    • Gert sagt:

      Ja klar warten wir einfach noch einige Tage oder Wochen wo es dem Nutzer dann gefällt

      man man man

    • 1ST1 sagt:

      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.

  3. Lothar sagt:

    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.

    • Günter Born sagt:

      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.

      • DW sagt:

        @Günther
        Bist du sicher, dass du den richtigen Kommentar verlinkt hast?

        • Mr.Blacksmith sagt:

          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.

  4. 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://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

    • 1ST1 sagt:

      ;-)

      [++]

      Warum arbeiten Sie eigentlich noch nicht für Microsoft?

      • Günter Born sagt:

        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 ;-).

  5. Bastian sagt:

    MSERT zeigt während es läuft an "Files Infected: 8". Am Ende dann aber "No infection found." Vertrauenserweckend.

  6. Bastian sagt:

    Danke für den Link Sebastian. Klingt durchaus sinnvoll was er schreibt und super UX-unfreundlich in der Umsetzung.

Schreibe einen Kommentar zu DW Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.