Erkennung von HAFNIUM-Aktivitäten zur Ausnutzung der Zero-Day-Lücke auf Exchange-Servern mit Splunk

Wenn ihr nur wissen wollt, wie man die Aktivitäten von HAFNIUM zur Ausnutzung der Zero-Day-Lücken auf Exchange-Servern entdeckt, könnt ihr direkt zum Abschnitt „Erkennung“ springen. Falls ihr euch für eine kurze Zusammenfassung dessen interessiert, was genau passiert ist, wie man das Problem erkennen kann und welche MITRE ATT&CK-Zuordnungen bestehen, lest einfach hier weiter.

Erläuterungen zu HAFNIUM und den Aktivitäten zur Ausnutzung der Zero-Day-Lücken auf Exchange-Servern

Am Dienstag, den 2. März 2021, hat Microsoft eine Reihe von Sicherheitspatches für seinen Mailserver Microsoft Exchange veröffentlicht. Diese Patches reagieren auf eine Reihe von Sicherheitslücken, von denen bekannt ist, dass sie Exchange 2013, 2016 und 2019 betreffen. Es ist wichtig, zu beachten, dass auch ein Sicherheitsupdate für Exchange 2010 veröffentlicht wurde, obwohl die CVEs diese Version nicht als verwundbar anführen.

Während die CVEs die Besonderheiten der Schwachstellen oder Exploits nicht im Detail beschreiben, ist die erste Schwachstelle (CVE-2021-26855) ein Remote-Netzwerk-Angriffsvektor, der es dem Angreifer – in diesem Fall einer Gruppe, die von Microsoft als HAFNIUM bezeichnet wird – erlaubt, sich als Exchange-Server zu authentifizieren. Im Rahmen dieser Aktivitäten wurden zudem drei weitere Schwachstellen (CVE-2021-26857, CVE-2021-26858 und CVE-2021-27065) identifiziert. Werden sie gemeinsam mit CVE-2021-26855 für den Erstzugriff ausgenutzt, kann ein Angreifer die komplette Kontrolle über den Exchange-Server erlangen. Dies beinhaltet die Möglichkeit, Code als Systemprozess auszuführen und in jeden Pfad auf dem Server zu schreiben.

Eine temporäre Abhilfe für diese Schwachstellen ist die Einschränkung des Zugriffs auf OWA, beispielsweise durch Platzierung des OWA-Servers hinter einem VPN, um externen Zugriff zu verhindern. Dies verhindert jedoch nicht, dass ein Angreifer der bereits intern im Netzwerk unterwegs ist, diese Schwachstelle ausnutzen kann. Kurzum, ihr solltet den Patch so schnell wie möglich installieren.

Die wichtigsten Informationen

Ihr denkt jetzt vielleicht: „Nur ein weiterer Tag mit Patches, wie in jedem anderen Monat auch.“ Das mag bis zu einem gewissen Grad auch stimmen, aber es ist laut dem Volexity-Blog wichtig, auf Folgendes hinzuweisen:

„Volexity hat in allen Fällen von RCE (Remote Code Execution) beobachtet, dass der Angreifer Web-Shells (ASPX-Dateien) auf die Festplatte schreibt und weitere Operationen durchführt, um Anmeldedaten zu dumpen, Benutzerkonten hinzuzufügen, Kopien der Active-Directory-Datenbank (NTDS.DIT) zu erstellen um anschließend auf der gleichen Ebene auf andere Systeme und Umgebungen zuzugreifen.“

Ich weiß nicht, wie es euch geht, aber wenn ich sehe, dass ein Angreifer Kopien meiner Active-Directory-Datenbank (AD) erstellt, läuft mir ein kalter Schauer über den Rücken. Denn zum Schutz vor dieser Bedrohung muss ich dann meine komplette AD von Grund auf neu aufbauen. Genauer gesagt: Durch das Kopieren der AD-Datenbank erhält der Angreifer Domain-Administrator-Rechte. Daher ist es wichtig, auf diesen Punkt besonders zu achten.

OWA! Das tut weh! 

Einige dieser Schwachstellen werden über Outlook Web Services (OWA) ausgenutzt, eine häufig aktivierte Funktion von Exchange Server 2013, 2016 und 2019. Die Grundlage für OWA ist der altehrwürdige Webserver von Microsoft, Internet Information Services (IIS). Glücklicherweise lassen sich Elemente dieses Angriffs identifizieren, indem man in den IIS-Protokollen nach den entsprechenden POST-Anforderungen sucht.

Aber Moment mal, was für ein Zufall: Splunk ist super gut darin, Protokolle aus allen möglichen Quellen aufzunehmen und darin nach Mustern zu suchen! Dafür müssen wir lediglich sicherstellen, dass die Protokolle von unseren OWA-Servern ordnungsgemäß aufgenommen werden.

Unser Erfolgsrezept dafür ist der Splunk Universal Forwarder– mit ein bisschen Hilfe des von Splunk unterstützten Technical Add-On für Microsoft IIS. Anschließend solltet ihr so etwas wie das hier zu eurer inputs.conf-Datei hinzufügen, damit ihr all die aufregenden Protokolle in das Verzeichnis C:\inetpub\logs\LogFiles im W3C-Format aufnehmen könnt. Damit könnt ihr die IIS-Zugriffsprotokolle nach ungewöhnlichen Mustern in den User Agent Strings durchsuchen. Von diesen ist bekannt, dass sie mit dem Angriff im Zusammenhang stehen, wie unsere Freunde von Red Canary in einem anderen Artikel bereits erwähnt haben. Außerdem solltet ihr einen Monitoring-Eintrag hinzufügen, um die Protokollaktivität in C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy zu erfassen.

In dem Blogeintrag von Volexity findet ihr weitere interessante User-Agents, die sowohl vor als auch nach dem Exploit gesehen wurden.

Richtig, schon wieder sind wir auf Windows Events und Command Line Auditing angewiesen

Wenn ihr bereits auf die Dienste des Universal Forwarders zurückgreift, könnt ihr auch sicherstellen, dass ihr sowohl relevante Windows-Sicherheitsereignisse als auch die Prozessstart-Ereignisse sammelt. Beide sind nämlich für die Erkennung bestimmter Aktivitäten von HAFNIUM wichtig. Hierfür empfehlen wir euch, das Technical Add-On für Windows zu verwenden und auch das Ereignis 4688 (mit Befehlszeilenargumenten) aus dem Protokoll der Sicherheitsereignisse zu sammeln, ODER ihr könnt natürlich Microsoft Sysmon verwenden und Event 1 sammeln. Diese Prozessstart-Ereignisse können auf eine anomale Ausführung des Dienstes Exchange UM hin durchsucht werden.

Außerdem könnt ihr Auditing auf eurem UM-Prozess des Exchange Server konfigurieren und dann die Windows-4663-Events nach verdächtigen FileCreated-Ereignissen (in diesem Fall im Zusammenhang mit Web-Shells) durchsuchen. Seid dabei aber vorsichtig – wenn ihr eure Auditing-Richtlinien nicht richtig einrichtet, besteht die Möglichkeit, viele tausend 4663-Ereignisse zu generieren!

Zu guter Letzt sammelt ihr noch das Anwendungsprotokoll von euren Exchange-Servern, wieder mit dem Windows-TA. Damit könnt ihr in dem Protokoll nach Fehlern suchen, die bestimmte Muster im Feld RenderedDescription über die Ausführung des Exchange-UM-Dienstes enthalten.

Erkennung der Aktivitäten von HAFNIUM zur Ausnutzung der Zero-Day-Lücken auf Exchange-Servern mit Splunk

Hier erhaltet ihr ein paar druckfrische Suchen aus den Blogs von Volexity und Microsoft, um einige der HAFNIUM-Angriffe ausfindig zu machen. Sofern wir diese Suchen in ESCU abdecken können, führen wir sie weiter unten im Abschnitt MITRE ATT&CK auf.

Bitte beachtet, dass das tatsächliche Remote Code Execution (RCE) Proof of Concept (POC) für diese CVEs noch nicht veröffentlicht wurde. Die folgenden Erkennungen stammen alle aus den Original-Blogeinträgen von Microsoft und Volexity. Sobald wir weitere Informationen haben, werden wir Updates veröffentlichen!

Indicators of Compromise (IOCs)

Sowohl Volexity als auch Microsoft haben in ihren Blogeinträgen IOCs veröffentlicht, die IP-Adressen der beobachteten Angreifer, Web-Shell-Hashes und Dateinamen sowie User Agents enthalten. Wir haben diese Indikatoren in ein einfaches CSV-Format konvertiert, damit ihr sie als Lookups verwenden könnt – Ihr könnt sie hier herunterladen. Aber was ist eine Nachschlagetabelle (Lookup Table) und wie hilft sie bei der Erkennung von Sicherheitsereignissen in Splunk? Hier erfahrt ihr es.

Authentication Bypass Vulnerability

Aus dem Blogeintrag von Volexity geht hervor, dass dieser Exploit die Authentifizierung umgeht und dann mit minimalem Aufwand auf die E-Mails der Nutzer zugreift.  Der Exploit erfordert einen HTTP POST für Dateien in einem bestimmten Verzeichnis /owa/auth/Current/themes/resources/.

Wir können dieses Verhalten über die folgende Suche erkennen, die das Erfassen der IIS-Protokolle auf dem Exchange-OWA-Server erfordert.

index=* sourcetype="ms:iis:auto" http_method=POST uri_path="/owa/auth/Current/themes/resources/*"
| stats count by src_ip, http_user_agent, uri_path, http_method, uri_query

Nishang PowerShell Framework

Eines der Tools, die HAFNIUM bei diesem Angriff verwendet haben, war das Nishang PowerShell Framework. Eine Methode wäre, nach PowerShell-Meldungen zu suchen, in denen sich die im Blogeintrag von Microsoft genannten Nishang-Befehle finden:

index="*" sourcetype="WinEventLog" source="WinEventLog:Security" EventCode=4104 Message="* Invoke-PowerShellTCP*"

Eine andere wäre, den Ereigniscode 4688 zu verwenden und einige der ausgeführten spezifischen Aktivitäten zu finden:

index="*" sourcetype="WinEventLog" source="WinEventLog:Security" EventCode=4688 Creator_Process_Name="powershell.exe" System.Net.Sockets.TCPClient

Powercat-Erkennung

Der Angreifer nutzte PowerShell, um Powercat herunterzuladen und im Speicher auszuführen. Bei Splunk sprechen wir schon seit Jahren über PowerShell und IEX Cradles (z.B. in diesem Blogeintrag und in dieser .conf16-Diskussion). Eine einfache Möglichkeit, um zu erkennen, ob ihr von dieser Aktivität betroffen wart, besteht darin, sicherzustellen, dass ihr den Eventcode 4104 eingebt und nach „powercat“ sucht:

index="*" sourcetype="WinEventLog" source="WinEventLog:Security" EventCode=4104 Message="*powercat*"

Der Exchange Unified Messaging Service erstellt ausführbare Inhalte

Der Unified Messaging Service von Microsoft Exchange Server kann von HAFNIUM ausgenutzt werden, um ausführbare Inhalte in gängigen serverseitigen Formaten wie PHO, JSP, ASPX usw. zu erstellen. Es ist ungewöhnlich und gefährlich für eine serverseitige Komponente wie den Unified Messaging Service, neue ausführbare Inhalte zu erstellen. Solche Inhalte können, wenn sie anschließend ausgeführt werden, zur Ausführung von Remote Code genutzt werden. Diese Suche untersucht die Ereignis-ID 4663 in den Auditprotokollen des Dateisystems auf Hinweise, dass der Unified Messaging-Dienst ausgenutzt wurde, um neue ausführbare Inhalte auf dem Server zu erstellen.

index=* sourcetype=WinEventLog source="WinEventLog:Security" EventCode=4663 Object_Type="File" (Object_Name="*.php" OR Object_Name="*.jsp" OR Object_Name="*.js" OR Object_Name="*.aspx" OR Object_Name="*.asmx" OR Object_Name="*.cfm" OR Object_Name="*.shtml") (Process_Name="*umworkerprocess.exe*" OR Process_Name="*UMService.exe*") 

Der Exchange Unified Messaging Service erstellt Child-Prozesse

Der Unified Messaging Service von Microsoft Exchange Server kann von HAFNIUM ausgenutzt werden, um Child-Prozesse auszuführen. Die Suche nach ungewöhnlichen Parent-Prozessen ist eine gut etablierte Erkennungstechnik, die wir anpassen und damit auch für diese Situation nutzen können. Diese Splunk-Suche macht sich die Windows-Ereignis-ID 4688 zunutze, die auch als Process Creation Events bezeichnet wird. Wenn der Parent-Prozess mit Exchange Unified Messaging zusammenhängt, kann der Prozess verdächtig sein. Bei dieser Suche wird eine NOT-Klausel verwendet, um falsch positive Treffer zu reduzieren.

index=* sourcetype="WinEventLog" source="WinEventLog:Security" EventCode=4688 (Creator_Process_Name="*umworkerprocess.exe*" OR Creator_Process_Name="*UMService.exe*") NOT New_Process_Name="*UMWorkerProcess.exe*"

Erkennung von Hacker-Tools

Verdächtige .zip-, .rar- und .7z-Dateien, die in C:\ProgramData\ erstellt werden, können auf eine mögliche Bereitstellung von Daten zur Exfiltration hinweisen. Die folgende Suche nach Sysmon- bzw. Windows-Ereignisprotokollen kann dabei helfen, diese Dateien zu identifizieren.

index=* (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" OR source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational") EventCode=11 (TargetFilename="C:\\ProgramData\\*.rar" OR TargetFilename="C:\\ProgramData\\*.zip" OR TargetFilename="C:\\ProgramData\\*.7z")

ODER

index=* (sourcetype="WinEventLog" source="WinEventLog:Security"  OR sourcetype=XmlWinEventLog source="XmlWinEventLog:Security") EventCode=4663 AccessList="%%4417" (ObjectName="C:\\ProgramData\\*.rar" OR ObjectName="C:\\ProgramData\\*.zip" OR ObjectName="C:\\ProgramData\\*.7z")

Außerdem wurde festgestellt, dass die Ausführung von 7-Zip zur Erstellung von Archiven als Mittel zur Bereitstellung von Daten für die Exfiltration genutzt wurde. Um herauszufinden, ob diese spezifische Datei ausgeführt wurde, können die folgenden Suchen mit Sysmon bzw. Windows-Ereignisprotokollen als Ausgangspunkt verwendet werden.

index=* (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" OR source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational") EventCode=1 CommandLine="C:\\ProgramData\\7z*"

ODER

index=* (sourcetype="WinEventLog" source="WinEventLog:Security"  OR sourcetype=XmlWinEventLog source="XmlWinEventLog:Security") EventCode=4688 process="C:\\ProgramData\\7z*"

Web Shells

Wenn ihr keine IIS-Protokolle habt, müsst ihr euch trotzdem keine Sorgen machen, denn Wire-Daten (wie Splunk for Stream) oder Zeek-Protokolle, die den Web-Traffic aufzeichnen, können ebenfalls dazu dienen, einen gewissen Grad an Visibilität zu erlangen. Natürlich verlangt es nach einem „Hunting with Splunk“-Post zu diesem Thema! Bis dahin könnt ihr euch diesen Klassiker von James Bower auf YouTube ansehen, um zu erfahren, wie man mit Splunk Web Shells jagt.

Splunk Enterprise Security und ESCU

Kenne Dich selbst

Nachdem wir nun einige Zeit damit verbracht haben, zu erklären, dass dieser Angriff schwerwiegend ist und Anstrengungen unternommen werden müssen, um ihn zu untersuchen, ist es auch wichtig, zu betonen, dass die Grundlagen von zentraler Bedeutung sind. Das grundlegende Asset Management, hoffentlich über euer Asset- und Identity-Framework, zeigen euch, wo sich eure Exchange-Server befinden. Regelmäßige Schwachstellen-Scans, die in Splunk integriert sind, zeigen an, welche Exchange-Server anfällig sind, und können euch helfen, eure Patching-Pläne zu priorisieren und eure Anstrengungen zur Erkennung von Angriffen besser zu fokussieren.

Threat Intelligence Framework

Wenn ihr Splunk Enterprise Security verwendet, können die oben aufgelisteten IOCs einfach in das Threat Intelligence Framework aufgenommen werden. Vielleicht seid ihr euch nicht sicher, wie man das macht. Keine Sorge, wir haben Tipps und eine Anleitung zur Integration von IOC-Listen in das Enterprise Security Threat Intelligence Framework veröffentlicht.

Enterprise Security Content Updates (ESCU)

Für alle, die ESCU nutzen, hat unser Security Research Team am 4. März 2021 eine neue Splunk Analytic Story mit dem Namen „HAFNIUM Group“ veröffentlicht, die Erkennungsmöglichkeiten für diese Bedrohung enthält. Dafür solltet ihr euch außerdem die Tabelle zu MITRE ATT&CK weiter unten anschauen. Wenn ihr ESCU bereits nutzt, habt ihr dadurch bereits eine gute Erkennungsmöglichkeit!

MITRE ATT&CK

Nach Durchsicht der Blogeinträge von Microsoft und Volexity haben wir die Aktivitäten der Angreifer zu MITRE ATT&CK zugeordnet. Jede Taktik ist außerdem mit Splunk-Inhalten verknüpft, um euch bei der Suche nach diesen Informationen zu helfen. Bitte beachtet, dass diese Suchen nur dazu dienen, die Erkennung zu beschleunigen. Wir empfehlen euch, sie über die Splunk Security Essentials App zu konfigurieren. Es kann sein, dass ihr sie modifizieren müsst, damit sie in eurer Umgebung funktionieren! Viele dieser Suchen sind für die Verwendung mit dem Befehl tstats optimiert.

Sobald mehr Informationen verfügbar sind und weitere ATT&CK TTPs bekannt werden, werden wir diese Suchen aktualisieren.

Hier ist eine Liste aller MITRE ATT&CK TTPs, von denen wir festgestellt haben, dass die bei diesem Angriff eingesetzt wurden: 
T1003.001, T1005, T1027, T1046, T1059, T1059.001, T1070, T1071, T1074.002, T1083, T1110, T1190, T1505, T1560.001, T1589.002, T1590.002

Fazit

Wir wissen, dass es sich hierbei um eine signifikante Schwachstelle handelt und dass Kunden so schnell wie möglich patchen und feststellen wollen, ob sie in der Vergangenheit von diesem Angriff betroffen waren. Wenn ihr noch nicht gepatcht habt (ist uns allen schon mal passiert), werden euch diese Suchen hoffentlich die Möglichkeit geben, mehr Einblick in eure Umgebung und eventuelle bösartige Aktivitäten zu erhalten. Wenn sie nicht perfekt funktionieren, betrachtet sie einfach als „SplunkSpiration“ :-). Sobald wir weitere Informationen haben, werden wir diesen Blogeintrag aktualisieren und, wie bereits erwähnt, nach weiteren Erkennungen unseres Threat Research Teams Ausschau halten, die über Enterprise Security Content Updates veröffentlicht werden.

Wie immer ist das Thema Security bei Splunk ein gemeinschaftliches Unterfangen. Vielen Dank an unsere Autoren und Mitarbeiter:

Mick Baccio
James Brodsky
Shannon Davis
Michael Haag
Amy Heng
Jose Hernandez
Dave Herrald
Ryan Kovar
Marcus LaFerrera
John Stoner

^{*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier: Detecting HAFNIUM Exchange Server Zero-Day Activity in Splunk.}