Microsoft Exchange Server Hack - der Patch kam bereits zu spät

In einer Aufsehen erregenden Angriffswelle wurden im März 2021 aufgrund einer Sicherheitslücke im Microsoft Exchange Server weltweit zehntausende E-Mail-Server Opfer von Cyberattacken.

Die Schwachstellen hatte in dem sogenannten Zero-Day-Exploit eine bisher unbekannte chinesischen Spionagegruppe mit dem Namen „Hafnium“ ausgenutzt. Auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) ermahnte daraufhin tausende deutsche Unternehmen, die Lücke in selbst betriebenen Exchange Servern schnell zu schließen. Microsoft hatte kurz nach Entdeckung der Sicherheitslücke Patches veröffentlicht, die die Schwachstellen in Exchange-Servern behoben haben.

Wir klären in diesem Beitrag den zeitlichen Vorgang auf: Was war passiert und hätte man die Angriffe verhindern können?

Wer gepatcht hatte, war trotzdem nicht sicher

Folgendes haben wir anhand eines DriveLock Testsystems recherchiert; der zeitliche Ablauf konnte bei vielen Unternehmen beobachtet werden:

• In der Nacht zum 03.03.2021 - also einen Tag, bevor der Patch durch Microsoft veröffentlicht wurde - wurde der Testserver durch einen Zero-Day-Exploit angegriffen. Dabei wurde eine „Webshell“ hinterlassen, ein sehr einfaches Skript, das alles lokal ausführt, was an Parametern übergeben wurde.
  
  
• Am 03.03. wurde der Patch von Microsoft veröffentlicht.
  
  
• Am 05.03. wurde das angegriffene System gepatcht. Man könnte also vermuten, dass es somit vor den Angriffen sicher sei. Zu diesem Zeitpunkt war aber noch nicht veröffentlicht, woran man einen Angriff überhaupt konkret erkennt. Und es gab noch nicht die Erkenntnis, dass der Patch die zuvor eingeschleuste Webshell nicht entfernt.
  
  
• Wenig später, am 07.03., wurde die Webshell dann ausgenutzt, um das System zu inventarisieren. In vielen Publikationen ist zwar beschrieben, nach welchen gefährlichen Dateien Unternehmen suchen müssen, aber der Inhalt der Dateien wurde nicht erklärt. Jetzt ist klar: Dateien, die auf einen Angriff hindeuten, wären Informationen zum Systeminventar gewesen.
  Dieses Systeminventar wird auf dem angegriffenen System abgelegt. Das System war zu diesem Zeitpunkt schon gepatcht. Das hat aber trotzdem den unbefugten Zugriff nicht verhindert, weil die Webshell noch vorhanden war.
  
  
• Ebenfalls am 07.03. wurde dann eine weitere Backdoor - neben der ersten Backdoor namens "Webshell" - auf dem Server hinterlassen. Ob dafür die gleiche Hackergruppe wie bei der ersten Backdoor verantwortlich war, lässt sich nicht rekonstruieren.
  
  
• Erst am 09.03. waren dann die beiden Hinterlassenschaften, Webshell sowie zweite Backdoor, in aktualisierten Virenscanner-Signaturen enthalten, konnten gefunden und beseitigt werden.
  
  

Das wäre eigentlich einfach gewesen, handelt es sich doch nur um eine einzige Datei (Webshell), die in einem Verzeichnis des Exchange-Servers liegt.

Keine Vorwürfe an die Serverbetreiber und Serveradministratoren

Besonders in der Tagespresse las man, dass die Administratoren der betroffenen Systeme die verfügbaren Patches nur rechtzeitig hätten einspielen müssen, um den Angriff zu verhindern. Bei anderen Angriffen mag das stimmen, aber nicht bei dieser Welle:

Die Sicherheitslücke wurde ausgenutzt, bevor noch überhaupt ein Patch vom Hersteller zur Verfügung stand.

Selbst, wer unmittelbar nach Veröffentlichung des Patches diesen eingespielt hatte, ist vermutlich bereits Opfer des Angriffes gewesen. Und da man davon ausgehen muss, dass einfach systematisch alle ip-Adressen im World Wide Web gescannt wurden, ist potenziell jeder Exchange-Server auch angegriffen worden.

Microsoft Exchange Server Hack: HACKER KOCHEN AUCH NUR MIT WASSER

Wenn man den Ablauf der Aktion aus Sicht der Kriminellen betrachtet, war das Ganze vom Timing her wirklich clever organisiert: Die Microsoft Exchange Server Hacker scannen einmal das gesamte Internet (ca. 4,3 Mrd. IP-Adressen) und hinterlassen auf jedem Server die genannte Webshell. Das klingt zunächst nach einem großen Aufwand. Aber wenn man sich bei einem der großen Cloud-Anbieter beispielsweise 255 virtuelle Maschinen mietet, dann verbleiben pro Maschine nur noch ca. 17 Mio. zu scannende IP-Adressen. Wer so in drei Tagen das ganze Internet „abarbeiten“ will, muss dann rund 66 IP-Adressen pro Sekunde schaffen. Das ist ziemlich leicht machbar. Mit der günstigsten virtuellen Maschine kostet das rund 400 €.

Der Scan muss jedenfalls beendet sein, bevor richtig Notiz von der Angriffswelle genommen wird. Denn wissen die Administratoren erstmal von der Gefahr und werden aktiv, sind die Einfallstore schnell geschlossen. Daher haben die Hacker ja neben dem eigentlichen Zero-Day-Exploit ein weiteres Einfallstor aufgesperrt, die Webshell. Es gab also insgesamt drei Angriffspunkte:

1. Zero-Day-Exploit
2. Webshell (erste Backdoor)
3. Zweite Backdoor

Beim Verteilen der Webshell hat die Hackergruppe eine Datenbank mit der Information erstellt, unter welchen IP-Adressen überhaupt ein Exchange-Server erreichbar ist.
Das macht den nächsten Schritt viel leichter: Nicht jedes System hat interessante Daten und ist deshalb relevant.
Damit eine Unterscheidung nach interessanten und irrelevanten Systemen getroffen werden kann, sind noch mehr Informationen nötig. Diese müssen auch automatisiert eingesammelt werden, denn noch sind es zu viele Server. Daher generierten die Kriminellen mit Windows-Bordmitteln (mittels hinterlassener Webshell) ein Systeminventar und sammelten diese Informationen ein. Nachdem die Angreifer damit rechnen mussten, dass ihre Angriffswelle mittlerweile entdeckt worden war, mussten sie das Inventar unmittelbar nach beendetem Scan fertigstellen – während die halbe Administratoren-Welt gerade in Panik Patches verteilte. Nun müssen sich die Hacker etwas beeilen, denn sie müssen mit dem gesammelten Inventar noch die interessanten Systeme finden und diese noch „richtig“ angreifen, bevor das zweite Einfallstor (Webshell) entdeckt wird. Die eigentlichen Angriffe könnten zum Beispiel Memory Dumps von Authentifizierungs-Datenbanken (LSASS) gewesen sein, in denen z.B. Passwörter liegen.

Und nun kommen wir zum Thema „Kochen mit Wasser“:
Der zeitliche Ablauf war gut, die Webshell aber war ausbaufähig. Diese war nämlich immer die Gleiche und damit von einem Virenscanner (auch als „Blacklisting“ bekannt) leicht erkennbar.
Man kann diese auch noch „personalisieren“, dann wird es sehr schwierig, sie im Blacklisting automatisch zu erkennen. Der kriminelle Angreifer kann Dateien, die er automatisch über die Webshell generiert und später heruntergeladen hat, auch über die Webshell wieder löschen – dann wird es sehr schwierig zu identifizieren, ob überhaupt ein Angriff stattgefunden hat. Zusammengefasst: Der Angriff hätte besser sein können und quasi unbemerkt durchgeführt werden können.

Application Whitelisting als Lösung

Es ist wie bei vielen Angriffen in der Vergangenheit: Wäre auf den Servern ein Whitelisting-Produkt (z.B. DriveLock Application Control) gelaufen, hätte der Exchange-Server nur die Skripte ausgeführt, die von Microsoft geliefert wurden. Dann hätte es zwar die Lücke im Exchange Server gegeben. Die Webshell-Datei kann jedoch nur abgelegt, nicht aber ausgeführt werden, weil sie nicht auf der Whitelist steht. Somit wird bei versuchter Ausführung der Zugriff blockiert.

Betrachten wir, was die Angreifer bei interessanten Systemen danach noch gemacht haben, beispielsweise Speicherabzüge von der Benutzerdatenbank des Betriebssystems (erstellt mit einem Tool von Microsoft) oder die Erstellung eines Archivs mit Daten (mit Hilfe eines Komprimierungsprogramms). Auch dies lässt sich sehr leicht durch Applikationskontrolle verhindern. Denn diese Tools wurden erst bei der Exchange Server-Attacke auf die Rechner jeweils aufgebracht und anschließend ausgeführt. Sie standen also nicht auf der Whitelist.

Microsoft Exchange Server Hack: Der Blick in die Zukunft

Die nächste Sicherheitslücke kommt bestimmt. Nehmen wir einmal an, es agiert diesmal jemand, der sich ein bisschen mehr Mühe gibt: Er personalisiert die Webshell, sodass sie vom Antivirusprogramm auch per Heuristik nicht leicht erkannt wird. Dies gibt dem Angreifer viel mehr Zeit, bis er entdeckt wird.

Die Angreifer löschen dieses Mal ihre Hinterlassenschaften/Backdoors wieder, nachdem sie die Daten heruntergeladen haben. Und sie löschen dieses Mal auch alle Logdateien. Einziges Indiz auf einen Angriff sind (nicht mehr vorhandene) Logs. Es gibt dann keine Möglichkeit mehr herauszufinden, was genau heruntergeladen wurde und was vor allem evtl. an zusätzlichen Backdoors geschaffen wurde. Und vielleicht werden diese Schlupflöcher auch erst in einem Jahr ausgenutzt. Dann muss das betroffene Unternehmen nach dem Angriff im Grunde seine gesamte Infrastruktur neu installieren, um sicherzugehen, dass sie keine Schlupflöcher übersehen haben. Das bedeutet einen hohen Kostenaufwand.

Applikationskontrolle mit Application Whitelisting verhindert solche Worst Case-Szenarien. Viele Unternehmen lehnen aber Application Whitelisting immer noch ab und befürchten einen hohen administrativen Aufwand. Der manuelle Aufwand lässt sich jedoch reduzieren. Predictive Whitelisting sorgt dafür, dass die Whitelist selbstständig dazulernt und das System trotzdem sicher bleibt: Zum Zeitpunkt der DriveLock Installation wird das System „versiegelt“. Ab dann gibt es nur noch definierte und konfigurierte Wege, wie Änderungen an der Whitelist selbstlernend vorgenommen werden. Das automatisierte Lernen der Whitelist gewährleistet stets den Sicherheitsstandard und reduziert den Pflegeaufwand.

Es stellt sich die grundsätzliche Frage nach diesem Angriff:
Ist der Aufwand für Application Whitelisting wirklich höher als die Aufklärungsarbeit, was im Zusammenhang mit diesem Hack alles passiert ist?