Hafnium: Nachbereitung

Exchange Server gepatched, MSERT und Virenscanner findet nichts mehr. Aufregung gelegt? So leicht sollten Sie es sich nicht machen. Der 2. März 2021 war eine Zäsur bei vielen Firmen, einmal ihren zukünftigen Betrieb zu überdenken. Die schwere Lücke und die massiven und erfolgreichen Angriffe auf tausende Exchange Server zeigen, wie verletzlich eine Firma sein kann. Ich würde nicht von einem Krieg sprechen aber wenn der Angreifer die Zerstörung als primäres Ziel gehabt hätte, dann würden viele Firmen bis zum erfolgreichen "Restore" ohne Kommunikationsplattform dagestanden. Es fehlt an Personal, Dienstleister und ob das Backup wirklich funktionierte, steht auf einem andern Blatt. Wie gehen wir mit dem Risiko um?

Unwohlsein

Wenn Sie diesmal Glück hatten und mit einem frühzeitigen Patchen vor den Angreifern ihren Exchange Server geschützt haben, dann ist das nur eine trügerische Ruhe. Es gab schon in der Vergangenheit ähnliche Lücken in den unterschiedlichsten Produkten.

Die wichtigste Aussage: Nach dem Exploit ist vor dem Exploit.
Hafnium hat viele Exchange Administratoren aufgeweckt aber die Herausforderung gibt es schon immer und hört auch nicht auf. Suchen Sie mal nach Spectre und Meltdown (https://meltdownattack.com//meltdownattack.com/) und Foreshadow (https://foreshadowattack.eu/).

Es gibt aber ganz konkrete Vorfälle im Zeitraum um Hafnium, die nicht weniger kritisch waren. Hier nur ein Beispiel der letzten Monate.

Wer etwas mit Software und Computernetzwerken zu tun hat, sollte einfach damit leben, das es vermutlich noch Schwächen gibt, die schon noch niemandem oder nur den falschen Personen bekannt sind (Zero-Day-Exploit). Zudem gibt es bekannte Lücken, die aber nie einen Patch bekommen, z.B. weil es die Firma nicht mehr gibt oder das Produkt nicht mehr gewartet wird. Denken Sie aber auch an die Lücken für die es Updates gibt, aber die Administratoren einfach noch nicht installiert haben. Manchmal ist es es einfach der Faktor Zeit, manchmal die Veränderung des Verhaltens (z.B. Abschaltung SMB1, Zwang von TLS 1.2) und sehr oft auch das Unwissen, dass dieser Code überhaupt in ihrem Netzwerk genutzt wird.

Die Wellen des Angriffs

Nach meiner Beobachtung haben wie mit Hafnium die folgenden Phasen durchlaufen und das Muster dürfte für alle Zero-Day-Exploits ähnlich sein:

Hafnium - Die verschiedenen Angriffswellen
https://www.youtube.com/watch?v=1nIVSPJECgc

Bei Exchange war die Lücke nicht von Anfang an vorhanden. Wenn ich den Quellen glauben, dann sind Exchange 2007 und frühere Versionen nicht betroffen und erst mit Exchange 2010 wurden die ersten Lücken (CVE-2021-26857/CVE-2021-26858/CVE-2021-27065 ) und mit Exchange 2013 der Fehler CVE-2021-26855 (ProxyLogon) eingeführt:

Phase Beschreibung

T0 - Unsichere Phase

In der Zeit von über 7 Jahren ist niemand die Lücke aufgefallen bis sie dann irgendwann von jemandem entdeckt wurde. Gehen wir mal davon aus, dass die Hafnium-Gruppe die Lücke zuerst gefunden hat.

T1 - Hochrisiko-Phase

Hafnium wird diese kostbare Zero-Day-Lücke vermutlich sehr selektiv eingesetzt haben, um interessante Ziele zu infiltrieren. Man möchte ja nicht gleich erwischt werden und unter dem Rada bleiben. Ob nun DEVCORE (https://proxylogon.com/#timeline) im Dezember die gleiche Lücke zufällig gefunden oder irgendwie Wind bekommen hat, wird vermutlich auch nicht herauskommen. Er hat zumindest die Lücke an Microsoft gemeldet und damit T3 eingeleitet.

T2 - Detect und Remediation

Die Aktionen der Hafnium wurden aber durch eine Überwachungssoftware bemerkt und die Firma Volexity (https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities/) hat zumindest bei ihren Kunden eine Analyse durchgeführt, die installieren Backdoors erkannt und erste Gegenmaßnahmen eingeleitet.
Das dürfte von den Angreifern nicht unbemerkt geblieben sein. Nun war es nur noch eine Frage der Zeit, bis Hersteller und AV-Produkte ein Update bekommen

T3 - Welle 2

Wenn bald Server gepatched und Malwarescanner sensibilisiert werden, dann sollte man nun "Masse machen", also möglichst viele Firmen infizieren und eine Backdoor installieren. Vielleicht bleibt die Backdoor ja erhalten, selbst wenn der Server bald gepatched wird. Eine andere Payload ist natürlich auch möglich und "verkaufen" lässt sich so eine Zero-Day-Lücke auch noch, solange die Welt nichts davon weiß.
In der Zwischenzeit war Microsoft nicht untätig und hat die Fehler analysiert, Ursachen gefunden und Updates vorbereitet.

T4 - Welle 3

Mit der Veröffentlichung der Patches wurde nun das Wettrennen gestartet. Die Hafnium-Gruppe ist nun nicht mehr allein, denn jede APT-Gruppe schaut sich den Patch an um den Angriffsvektor zu finden und schon wenige Tage später gab es Exploit-Samples auf GitHub und anderen Foren. Nun geht es nur noch drum, welche Administratoren ihre Exchange Server gepatcht haben, ehe Sie angegriffen wurden und welche schon unerwünschten Besuch hatten. Hier hat der Hersteller Microsoft aber auch ein BSI u.a. das Problem, dass sie keinen Ansprechpartner für die Server haben. Man muss drauf hoffen, dass die Administratoren schon irgendwie die Meldungen im Internet, Zeitschriften u.a. lesen

Leider wird diese letzte Welle noch einige Zeit anhalten, wenn sehr viele Exchange Server haben schon immer einen sehr alten Stand und belegen damit, dass keine Wartung erfolgt. Technisch könnte man das Internet nach solchen Servern durchsuchen, und einige Stellen machen das sogar. Aber wer schon im Normalfall seine Server nicht aktuell hält, wird auch einen Anruf oder eine Mail als Spam einfach löschen. Das Problem dabei ist, dass ich ja versuchen müsste die Lücke auszunutzen, um die "Härtung" zu prüfen und schon das dürfte eine strafbare Handlung sein. Es ist ein Unterschied, ob ich nur ihr Klingelschild lese oder schaue, ob einer meiner Schlüssel passt. Wenn die Tür dann auf ist, bin ich schon Einbrecher.

Neuaufbau oder Bereinigen?

Wenn sie mit Test-Proxylogon.ps1 entsprechende Spuren finden, dann hatten sie vermutlich Einbrecher im Haus. Natürlich können Sie nun das Schloss in der Haustür austauschen und die Tür schließen. Aber würden Sie nicht auch sicherheitshalber jedes Zimmer und jeden Raum auf Spuren kontrollieren?. Fehlen wichtige Dinge, wurden Schubladen geöffnet und nicht mehr verschlossen oder ist der Einbrecher vielleicht sogar noch im Haus? Vielleicht hat er ja ein Kellerfenster entriegelt, um später noch einmal wieder zu kommen.

Aber niemand wird deswegen gleich das ganze Haus abreißen und neu bauen. Dafür muss man schon gewichtige Gründe haben, z.B. eine komplette strukturelle Beschädigung, deren Reparatur teurer kommt oder nicht möglich ist. Die Feststellung eines solchen Schadens ist aber keine Routineaufgabe eines Administrators.

Dennoch werden nun viele Firmen mit "Hafnium-Spuren" sich überlegen, wie sie nun weiter machen. Reicht es den Exchange Server zu patchen, mit den Tools von Microsoft die eventuell installierte Malware zu beseitigen und zum Tagesgeschäft überzugehen? Aus meiner Sicht ist das zu kurz gesprungen, denn schon wenige Tage nach dem Patch wurde klar, dass nicht nur eine Gruppe die Lücke nutzt, sondern viele andere APT-Gruppen umgehend anhand der Updates die Lücke rekonstruiert und eigene Angriffe mit ganz anderen Payloads gestartet haben. Daher ist es auch nicht ausreichend "nur" die Microsoft Tools zum Bereinigen von Hintertüren zu verwenden.

Die Herausforderung ist aber nicht neu. Quasi kontinuierlich werden IT-Umgebungen angegriffen und die "Erfolge" von Verschlüsselungstrojanern (Emotet u.a.) zeigt, dass dies auch immer wieder gelingt. Wir werden also immer mit der Situation konfrontiert, dass ein nicht weiter bekannter Teil der IT-Umgebung fremdbestimmt ist oder war. Auch die Frage, wie die eigene Umgebung wieder "sicher" wird ist falsch gestellt. Gerade in IT wenige versierte Personen denken bei "Sicher/Unsicher" an einen binären Zustand. Sicherheit ist aber eine analoge Größe, die kontinuierlich weiter gelebt werden muss.

Analog zum einem Einbruch im Eigenheim sollten Sie...

  1. ... die Spuren des Angreifers nachverfolgen
    Wohl dem, der seine IISLogs noch lange genug aufbewahrt hat, seine Windows Eventlog hält u.a.
  2. ...die Unversehrtheit der Systeme/Räume überprüfen
    Dazu zählt zuerst mal ein Virenscanner, der hoffentlich die erkannten Payloads nach einigen Tagen findet. Denkbar ist aber auch ein "Vorher/Nachher"-Vergleich über Hashwerte und die Überprüfung wichtiger Verzeichnisse.
  3. .. ermitteln was fehlt
    Das ist in der IT aber schwer, denn wenn jemand etwas "Kopiert", dann nimmt er ihnen ja nichts weg. Es sei denn er beschädigt Daten z.B. durch Verschlüsselung. Da kann man vielleicht indirekt etwas "vermuten", z.B. wenn ein Export-Mailboxrequest im Exchange Management Eventlog zu finden ist und im Webserverlog dann der Download des bereitgestellten Archivs zu finden ist.

Es bleibt immer ein ungutes Gefühl, etwas übersehen zu haben. Eine Neuinstallation kann aber auch nicht die Lösung sein. Nur den Exchange Server neu zu installieren bringt ihnen nichts, wenn der Angreifer den Server mit den Berechtigungen als Sprungbrett zu anderen Systemen genutzt hat. Eine sehr kleine Firma konnte früher ihren "Small Business Server" neu installieren aber wer sagt ihnen, dass nicht auch die Daten, die sie danach wieder weiter verwenden, wieder Schaden anrichten. Es reicht ja ein Makro, das nun in einer internen Datei hinterlassen wurde und später vom arglosen Anwender gestartet wird? Firmen mit Software-Entwicklung müssen schon zweimal hinschauen, welcher Sourcecode wann eingecheckt wurde oder wer einen "GIT-Clone" angefertigt hat..

Sind wir realistisch: Die meisten Firmen werden keinen kompletten Neuaufbau planen und stattdessen die Exchange Server patchen und die gefundenen Hintertüren durch Virenscanner, MSERT und andere Tools entfernen lassen

Und wenn ich die vielen Meldungen richtig deute, dann haben die meisten Firmen auch nicht die leiseste Ahnung, wie Sie die Aktivitäten der Angreifer zuverlässig nachvollziehen können. Da Sie das Tagesgeschäft schnell wieder einholt, wird man den Vorfall immer weiter nach hinten schrieben, bis die Logdateien auch wirklich nichts mehr hergeben. Vermutlich werden viele Firmen damit sogar mit einem blauen Auge davon kommen. Es gibt zwei Fälle, wo dies nicht funktioniert.

  • Der Angreifer was mehr als nur ein "Script-Kiddie"
    Er hat im schlimmsten Falle Daten abgezogen, womit er sie in einigen Wochen erpresst oder er hat eine persistente Hintertür eingebaut, um mit etwas Abstand und in Ruhe ihre Umgebung kennenzulernen und "teure Daten" zu schürfen.
  • Sie haben unsichere Systeme nicht abgesichert
    Dann laden Sie quasi neue Angreifer geradezu ein, sich in ihrem Netzwerk auszutoben.

Ich würde mich hier also nicht auf einem "hoffentlich ist nichts passiert" ausruhen, sondern ein paar Schritte weiter gehen.

Wo kann ich schauen?

Wenn Sie Exchange und Windows einfach nur "Standard" installiert haben, dann sollten sie folgende Dinge prüfen:

Diese Analysen funktionieren nur dann, wenn der Angreifer nicht seine Spuren verwischt hat. Sie sollten nicht überrascht sei, wenn Sie vielleicht noch andere Spuren anderer Angriffe finden. Nur weil Hafnium gerade möglich ist, werden die anderen Angriffe nicht ausbleiben. Selbst AV-Hersteller und Microsoft haben interne "Mitleser" erst nach einiger Zeit gefunden.

Quelle Aktion Check

IIS-Logs auf dem Exchange Server

Der erste Angriff erfolgt per HTTP gegen ihre von extern (oder intern) erreichbare Exchange Server. Das Skript Test-proxylogon.ps1 analysiert diese Logs.

Achtung: Das Skript findet nur Logs, die sich auch noch habe. Wer seine IISLogs automatisch löscht, sollte aus dem Backup zumindest die Logs seit dem 1. Jan 2021 wiederherstellen

Diese Analyse ist die wichtigste Komponente, denn sie sollten bei einem erfolgreichen Angriff den Zeitpunkt des ersten Erfolgs erfassen.

Unerwünschte Shells

MSERT und Test-ProxyLogon prüfen ihren Server auf "unerwünschte Programme". Das bezieht sich aber auf "erkannte" Programme. Da mittlerweile viele Angreifer unterschiedliche Malware einsetzen, ist das allein kein Schutz. Hier sollten sie in den nächsten Tagen immer mal wieder einen Scan machen und sicherstellen, dass der lokale Virenscanner aktuelle Patterns hat.

Sie haben keinen Malware-Scanner auf ihren Servern? Dann wissen Sie nun, warum das eine schlechte Idee ist und umgehend geändert werden sollte.

Eine Malware kann auch bestehende Dateien ändern. Sie könnten daher auch nach veränderten oder neu angelegten ausführbaren Dateien suchen. "Sicher" ist das aber nicht, da eine Malware auch einfach das Dateidatum setzen kann.

Exchange Management Log

Exchange 2010 und neuer protokollieren alle PowerShell-Aufruf in einem eigenen Eventlog. Die Hafnium-Gruppe hat z.B. "set-OABVirtualDirectory aufgerufen. Aber andere Angreifer können andere Aktionen auslösen. Eine einfache Kontrolle der ausgeführten Befehle seit dem Angriff ist eine gute Idee.

Get-WinEvent -LogName "MSExchange Management" | export-csv exchangeevent.csv

Taskplaner

Ich kenne mindestens eine Payload, die einen geplanten Task mit dem Namen "WwanSvcdcs" anlegt. Leider nutzt Windows selbst viele geplante Tasks. Mit "Get-ScheduledTask" (PowerShell 7) können Sie aber schnell eine Liste samt den ausgeführten Programmen erhalten:

Get-ScheduledTask | select actions -ExpandProperty actions | ft execute

In Zukunft könnten Sie ja diese Liste regelmäßig im Rahmen einer Inventarisierung erfassen und "neue Tasks" zumindest melden.

Die Aktivitäten des Task-Scheduler finden Sie im Eventlog

Services Logs / Microsoft / Windows / TaskScheduler / Optional 

Eine Auswertung per PowerShell, z.B. als Export in eine Datei ist einfach

Get-WinEvent -LogName "Microsoft-Windows-TaskScheduler/Operational" | export-csv taskscheduler.csv

PowerShell History

Wussten sie, dass Powershell eine "History" pflegt? Jeder Befehlt, der in der PowerShell eingegeben wird, landet in diesem Log und mit etwas Glück können Sie hier die Aktionen nachverfolgen. Leider ist das Log nicht "global" sondern pro Benutzer. Sie müssen das richtige Verzeichnis finden. Für Benutzer steht es unter:

%AppData%\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt

Firewall Logs

Die eingehenden Zugriffe auf ihren Exchange Server können Sie im IISLogs sehr gut. Aber wenn der Angreifer eine Backdoor oder RemoteShell eingerichtet hat, dann versucht diese Shell eine ausgehende Verbindung zu einem Command and Control-Server aufzubauen. Das kann sie per UDP, TCP oder HTTP auch über Proxies versuchen. Bei Exchange Servern ist es z.B. oft möglich, dass der Server per Port 25 die Welt erreichen kann. Es gibt aber auch andere "offene" Ports, z.B. zu HBCI-Banken, Elster, Teams TURN-Servern u.a., die Sie auf der Firewall eigentlich für Clients aufgemacht haben aber auch Servern offen stehen könnten.

Kontrollieren Sie, welche Ziel-Adressen ihr Exchange Server ausgehend so alles erreicht hat oder erreichen wollte. Normalerweise spricht er vielleicht SMTP mit dem Internet oder einem vorgelagerten Proxy und ansonsten nimmt er nur Anfragen an. Vielleicht müssen Sie noch CRL-Checks, Office 365-Adressen, Windows update etc. filtern. Aber viel sollte nicht mehr übrig bleiben

Proxy Logs

Viele Remote Shells versuchen Malware nachzuladen. Leider können viele Exchange Server per HTTP/HTTPS das Internet erreichen. Das ist eine Einladung. Aber wenn Sie ausgehend den Zugriff über einen Proxy-Server zwingen, dann können Sie hier erkennen, was nachgeladen wurde.

Eventlogs

Windows kann den Start und das Ende von Prozessen protokollieren. Leider sind viele Protokollierungen per Default nicht eingeschaltet und wenn dies so ist, dann laufen die Logs schnell voll und werden überschrieben. Es ist schwer hier nach Spuren zu suchen. Sie müssten hier schon ein System haben, welches die Logs einsammelt und die "erwarteten Meldungen" ausblendet. So etwas kostet Zeit, Geld und Arbeit. Es ist nicht standardmäßig aktiviert und wenn Sie ehr schon viele Fehler und Warnungen und noch mehr Information-Events haben, dann wird es die Suche im Heuhaufen. Ohne konkrete Anhaltspunkte sollten Sie andere Quellen zuerst bearbeiten.

Allenfalls das "Security-Eventlog" könnte etwas über "Anmeldungen" protokollieren. Das ist aber eher auf anderen Servern interessant, zu denen sich ein Angreifer verbinden könnte

AD Objekte

Neben der Einrichtung von Hintertüren möchte ein Angreifer natürlich auch "mehr Rechte" bekommen. Wenn er einen neuen Benutzer samt Berechtigungen anlegt, dann hat er eine wichtige Hürde geschaffen. Daher ist eine Suche im Active Directory eine wichtige Quelle:

  • Welche Objekte wurden seit dem Angriff neu angelegt
    Sind diese ihnen bekannt und machen Sinn?
  • Welche Gruppen wurden verändert
    Insbesondere die Gruppe "DomainAdmins" ist hier gefährdet. Aber auch andere Gruppen mit "Admincount=1" sind für Angreifer interessant. (Siehe AdminSDHolder)
  • Veränderungen an Gruppenrichtlinien
    Um z.B. das neue Konto überall als lokaler Admin zu addieren, weitere Skripte zur Ausführung zu hinterlegen

Das sind nur erste Denkabsätze. Eine generelle Suche nach "WhenChanged > Einbruchzeitpunkt" liefert aber meist sehr viele Elemente und wenig zusätzliche Informationen.

Andere Server und Daten

Als "LocalSystem" hat der Angreifer nur bedingt Rechte auf andere System. Aber wenn Sie ihre Dateifreigaben mit "Jeder:Vollzugriff" eingerichtet haben, dann könnte der Angreifer nicht nur Daten gelesen sondern auch verändert haben.

Eigentlich "sollte" ihr Freigaben, egal auf welcher Plattform, besser gesichert sein. Die Realität sieht leider anders aus. Mit SharedEnum gibt es ein Werkzeug, welches auf Servern die Freigaben mit ihren Berechtigungen anzeigt. Wenn der Angreifer nur "Exchange Server$" war, können Sie gewisse Verzeichnisse erst einmal ausschließen. Das Bedeutet nicht, dass der Angreifer nicht über andere Wege doch einen Zugang gefunden hat.

NetFlow /IPFix

Es gibt Firmen, die auf ihren Switches und Routern die Kommunikationsbeziehungen (TCP/UDP) erfassen. Dies ist hilfreich, wenn die Daten nicht durch eine Firewall laufen. So können Sie dennoch sehen, welche Systeme miteinander kommunizieren und mit etwas Training können Sie "erwartete" Verbindungen unterbinden und sich auf die fraglichen Verbindungen konzentrieren. So lassen sich einfach Portscans, Zugriffe auf ungewöhnliche Ports u.a. erkennen. Fragen sie ihr Netzwerkteam, ob solche Daten vorliegen.

Prozess-Überwachung

Mark Russinovich  hat mit dem Programm "SYSMON" ein nettes Tool geschaffen, welches "ungewöhnliche" Aktionen auf einem Server protokolliert und durch andere Systeme dann ausgelesen werden können. Wenn das Tool noch nicht genutzt wird, dann könnten Sie es nun einsetzen, um aktive Hinterlassenschaften zu erkennen

Allerdings ist auch hier wieder ein SIEM oder anderes "Event-Sammel-System" ratsam, um die Meldungen zu verarbeiten.

Die Liste ist schon recht lang aber kann weiter fortgesetzt werden.

Virenscanner

Schon mehrfach habe ich auf die Bedeutung von Virenscannern hingewiesen. Sie sind sicher nicht perfekt und erkennen auch nicht alle Schadprogamme aber sie sind ein Werkzeug zur Verteidigung. Bei mir gibt es keinen Server ohne Virenscanner.

  • Ja, es kostet etwas Performance
  • Ja, es kann False Positive / Stabilitätsprobleme geben
  • Ja, die Erkennungsleistung ist bei individuellen Angriffen lausig
  • Ja, man muss bei der Konfiguration hinschauen, z.B. Exchange Datenbanken ausschließen

ABER

  • Sie erkennen die Schadsoftware, die schon länger benutzt wird.
    Bei Hafnium erkannte Defender, Sophos und einige andere nach einigen Tagen die verwendete Backdoor
  • Sie aktualisieren sich alleine
    Ich muss nicht auf einen Administrator warten, der ein Security Update installiert. Wenn mein Server nicht zur ersten Angriffswelle gehört, kann ich Glück haben, dass ein späterer Angriff vielleicht schon erkannt wird.
  • Einige Scanner könne mehr als „nur“ Pattern erkennen.
    Einige erkennen den Start von Prozessen, Dumps (Speziell LSASS), Neuanlage von ausführbaren Dateien. Entweder verhindern sie diese oder melden zumindest.
  • Luft nach oben
    Allerdings muss ich Virenscanner auch kritisch sehen. Warum erkannte kein Scanner eine Webshell (China Chopper), die schon im Jahr 2012 eingesetzt wurde? Auch könnte ein Virenscanner durchaus einen "Schutzmode" haben, bei dem Änderungen und die Ablage von "ausführbaren" Dateien (EXE, COM, BAT, CMD aber auch ASP, ASPX, JS etc.) unterbunden wird oder nur vom "Windows Update"-Prozess oder nach Rückfrage beim Administrator erlaubt sind.

AV Scanner sind eine wichtige Teilkomponente einer Schutzlösung aber auch nur ein Teil. Allerdings sind mittlerweile viele Produkte nur mehr nur ein "Virenscanner", sondern eine komplette "Endpoint Protection Lösung", die Netzwerkverkehr erfasst, Verhalten erkennt u.a.

Zumindest will und das Marketing dies als Mehrwert verkaufen. Wenn aber eine seiet 2012 bekannte WebShell auch 2021 nicht erkannt wird, dann erscheint dieser Versprechen in einem schlechten Licht.

Hier am Beispiel von Microsoft Defender for Endpoint.

Darf es ein bisschen mehr Logging sein?

Die Liste zeigt aber auch, wie viele Quellen Sie nicht nur nach einem Befall und bei der Analyse weiter untersuchen können, sondern dass all diese Quellen "verbessert" werden können. IISlogs können Sie um weitere Spalten (z.B. Bytes In/Out) erweitern, Eventlogs können vergrößert und weitere Events aktiviert werden, Zusatzprogramme wie Sysinternals Sysmon oder 3rd Party Malware-Scanner können wertvolle Informationen liefern.

Datenschutz und Betriebsräte sind keine Feinde sondern Gesprächspartner!
Eine Ausweitung der Protokollierung sollte abgestimmt werden aber bei Hafnium sieht man, dass zwischen den ersten Angriffen und der öffentlichen Information ca. 8 Wochen vergangen sind. Andere Angriffe wie Sunburst, Fireeye haben sich über viele Monate hingezogen.

... we detected unusual activity in December and took action to secure our systems. Our analysis shows the first viewing of a file in a source repository was in late November and ended when we secured the affected accounts. We continued to see unsuccessful attempts at access by the actor into early January 2021, when the attempts stopped.
Quelle: https://msrc-blog.microsoft.com/2021/02/18/microsoft-internal-solorigate-investigation-final-update/

Die Herausforderung besteht darin, die relevanten Informationen von den verschiedenen Systemen abzuholen oder zu empfangen, So dass auf dem Systemen selbst gar nicht viele Informationen lange Zeit liegen bleiben. Dieses zentrale "Log-System" ist dann natürlich entsprechend abzusichern, dass es ein Angreifer nicht übernehmen kann und nur legitime Personen die historischen Event einsehen können. Um die Datenmenge überschaubar und die Suche flott zu halten, nutzen die meisten Produkte entsprechende Regeln, um Events auch wieder zu entfernen. Ich empfehle kein spezielles Programm aber bei Kunden haben ich schon folgende Programme im Einsatz gesehen.

Natürlich gibt es noch ganz viele kommerzielle Tools wie Azure Sentinel, Zabbix, Solarwinds, unzählige Syslog-Server u.a. aber das Ziel ist bei allen System das gleiche.

  • Alle System loggen an eine gemeinsame Stelle
    Sie brauche lokal nicht viel Platz und ein Angreifer kann die Logs nicht mehr vernichten
  • Die zentrale Stelle speichert, analysiert und alarmiert
  • Kontrollierter Zugriff auf Logs
    Über Regeln und Rechte kann gesteuert werden, welcher Teilbereich welche Daten einsehen kann.

Am Beispiel von Azure Log Analytics und Sentinel lässt sich gut die Funktionsweise erkennen.

Aber auch Defender for Endpoint hat schon entsprechend eingebaute Regeln.

Gerade an den Sentinel-Regeln erkennt man schön, dass der Server alle Prozess-Aktivitäten im Security Eventlog protokolliert, diese dann in Azure Log Analytics landen und Sentinel Alarme triggert.

Interessant wird die Kombination von Logging und Monitoring. Klassische Tools wie Incinga, Cacti, Nagios, PRTG kommen aus dem Service-Monitoring und überwachen die Erreichbarkeit von Diensten und ermitteln Kennzahlen aber arbeiten kaum mit Logs. Diverse System loggen aber nicht nur "Nachrichten" sondern auch Performance-Werte und einen "Zustand". In der Kombination können diese Meldungen dann auch an ein Monitoring übertragen werden.

Selbst Lücken suchen

Mit Hafnium haben wir schnell gesehen, dass Werkzeuge zur Schwachstellenanalyse diese Lücke als Regel gelernt haben. Diese Werkzeuge werden natürlich von Angreifern eingesetzt aber auch intern können Sie mit solchen Werkzeugen in Abstimmung mit den Serververantwortlichen nach Schwachstellen suchen. Es ist immer noch besser, wenn Sie eine Lücke finden als wenn ein unbekannter Angreifer ihre System scannt.

Da bei Hafnium der Angreifer eine Shell auf ihrem Server hatte, könnte er entsprechende Werkzeuge von intern gegen ihre anderen Server in Stellung bringen. Die meisten Virenscanner erkennen und blocken solche Programme. Auch das ist ein Grund mehr auf jedem Server einen Scanner zu nutzen. Sie sollten selbst intern die gleichen Werkzeuge regelmäßig einsetzen, die auch Angreifer verwenden.

Wenn ihr Monitoring gut ist, dann sollten Sie solche Angriffe auch sehen und alarmiert werden. insbesondere, wenn die erfolgreich waren.

Es gibt auch mehrere Werkzeugkisten von "Red Teams", mit denen Systeme attackiert werden können.

Und natürlich gibt es Dienstleister, die solche Tests als Service anbieten. Solche Checks sollten sie nicht nur von extern auf die von ihnen veröffentlichten Dienste durchführen sondern auch von intern. Die Hafnium-Angreifer sind von innen gekommen.

Sie können sogar einen Schritt weiter gehen und einen Host aufsetzen, der gezielt "unsicher" ist und von Angreifern aber nicht normalen Anwendern gefunden wird. Das kann schon eine IP-Adresse sein, die niemals vergeben wird. Sobald jemand einen ARP-Request auf diese Adresse macht, ist das ein Alarmzeichen. Wenn Sie mutiger sind, können Sie hinter der Adresse einen Honeypot betreiben. Aber eigentlich ist jeder interne Server schon ein "Honeypot" und Scanversuche von Angreifern sollten sie erkennen.

AppLocker und Co

Interessant in dem Zuge natürlich auch Lösungen, die nicht explizit zugelassene Dateien blockieren. Sie könnten z.B. alle Dateien auf ihrem Server digital signieren und dann per Gruppenrichtlinie alle anderen Dateien verhindern. Mit Windows Applocker könnten Sie sehr genau zumindest COM/EXE/BAT/PS1 kontrollieren oder erkennen. Allerdings hilft es nichts, z.B. Verzeichnisse wie C:\Programme, C:\Windows oder die Exchange Installationspfade "freizugeben", denn als "LocalSystem" kann ein Angreifer natürlich gerade da auch seine Temp-Dateien anlegen.

Auch andere Lösungen wie "Tripwire", die alle Dateien des Servers nach Regeln in einer Datenbank mit Hashwert ablegen, helfen nur nach einer Infektion bei der Suche nach veränderten, gelöschten oder neuen Dateien.

Allerdings könnte man auch mal hinterfragen, warum "LocalSystem" oder der WebServer die Rechte hat, Dateien in die interessanten Verzeichnisse zu schreiben. Exchange ist doch kein "selbstveränderliches" System und neuere Versionen kommen durch den Administrator auf die Festplatte. Allerdings dürfen Sie "Windows Update" nicht vergessen, welches als "LocalSystem" arbeitet. Damit kann dieser Exploit nicht gestoppt werden.

Zero Trust

Ausgehend von dem Angriffsvektor "innenangriff von Exchange auf andere Server" kommt der "Zero Trust"-Ansatz ins Rampenlicht. Früher wurden Netzwerk nach "Intern" und "Extern" unterschieden und dazwischen gab es eine DMZ. Spätestens jetzt ist klar, dass auch ein interner PC oder Server nicht vertrauenswürdig ist.

Sie können jedem Server in ein eigenes Subnetz stecken und mit einer Firewall die Pakete dazwischen inspizieren. Allerdings kostet das Zeit und Geld und die Firewall als zentraler Faktor ist der Flaschenhals und kritische Baustein.

Aber lassen sie in all ihre Überlegungen diesen "Zero Trust"-Ansatz mit einfließen. Es gibt viele kleine Bausteine, die Sie dabei umsetzen können und die die Auswirkungen von Hafnium beschränkt hätten, z.B.

  • Muss ihr Exchange Server ohne Beschränkung in Internet?
    Es bedeutet natürlich mehr Arbeit, wenn der Zugriff selektiv konfiguriert wird. Sie müssen genau wissen, welche Verbindungen Exchange tatsächlich benötigt und wie sie diese freischalten. Aber Sicherheit ist nicht einfach
  • Muss ihr Exchange Server Verbindungen zu allen Servern in allen Standorten aufbauen können?
    Er muss natürlich mit Domaincontrollern sprechen aber sicher nicht mit Dateiserver, SQL-Servern u.a. Sie könnten das Unterbinden, z.B. per IPSEC oder Firewalls auf den Servern und Alarmieren, wenn es solche Verbindungen gibt.
    Denken Sie immer dran, dass sie auch ohne Hafnium einen ungebetenen Gast in ihrem Netzwerk haben könnten.
  • Kennen Sie ihre Server und Dienste
    Sie müssen für jeden Service wissen, wo er läuft, welche Systeme verbunden sind, welche Versionen eingesetzt sind und wer die System patchen kann und notwendige Updates überwacht. Der Fokus ist dabei nicht auf "dem Exchange Server", sondern auf der Komponente "Messaging". Bei Exchange gehört da auch das Wissen um die Firewall, Reverse Proxies, externe DNS-Einträge dazu

Microsoft interpretiert Zero Trust auch hinsichtlich der Anwender. Um auf Daten zuzugreifen, muss sich der zugreifende Benutzer oder Service authentifizieren. Dazu reicht nicht mehr die Kombination aus Benutzername und Kennwort sondern es werden weitere Kriterien wie Gerätestatus, Standort, Verbindung oder weitere Faktoren mit einbezogen. Das hilft nur bei Hafnium erst mal nicht weiter, denn ich kann "Exchange Trusted Subsystem" ja nicht weniger Rechte Berechtigungen geben, als die er für die Funktion braucht. Der Server steht ja "intern" und ist angeblich "voll verwaltet" und hat damit einen Vertrauenslevel, den ein "Bring your own Device"-Gerät eines freiberuflichen Mitarbeiters im Homeoffice nie haben wird.

Weitere Links

Microsoft Exchange Schwachstellen CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065 Detektion und Reaktion
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Vorfaelle/Exchange-Schwachstellen-2021/MSExchange_Schwachstelle_Detektion_Reaktion.pdf?__blob=publicationFile&v=3

Analysis - Post-Exploitation from Microsoft Exchange HAFNIUM
https://www.youtube.com/watch?v=rn-6t7OygGk
Analyse eines Exchange Servers und was die Angreifer per WebShell angestellt haben könnten.