Loading...
Blogs & Stories

SpiderLabs-Blog

Mit mehr als einer halben Million Lesern pro Jahr ist dies die Anlaufstelle der Sicherheitsgemeinschaft für technische Informationen zu den neuesten Bedrohungen, Informationen zu kritischen Sicherheitslücken und aktuellen Forschungsergebnissen.

HAFNIUM, China Chopper und ASP.NET Runtime

Die jüngsten Microsoft Exchange Server Zero-Day-Exploits (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065) haben dazu geführt, dass Zehntausende Unternehmen und Organisationen von HAFNIUM und zahlreichen anderen kriminellen Gruppen kompromittiert wurden. In enger Zusammenarbeit mit unseren Kunden auf der ganzen Welt waren wir schnell in der Lage, bestimmte Merkmale dieser Angriffe zu identifizieren und zu isolieren. Dazu zählt insbesondere die Web-Shell China Chopper, die auf kompromittierte Microsoft Exchange Server mit einem öffentlich zugänglichen Internet Information Services (IIS)-Server hochgeladen wurde. Obwohl es die China Chopper schon seit mehreren Jahren gibt, haben wir aus aktuellem Anlass genauer untersucht, wie sie funktioniert und welchen Einfluss die ASP.NET Runtime hat.

China Chopper ist eine Active Server Page Extended (ASPX) Web-Shell, die typischerweise über ein Exploit auf einem IIS-Server installiert wird. China Chopper wird für die Post-Exploitation-Phase verwendet, indem es Angreifern ermöglicht, beliebigen Code auf dem Server auszuführen.

Die serverseitige ASPX-Web-Shell ist extrem klein und besteht gewöhnlich nur aus einer Zeile. Es gibt mehrere Versionen dieser Web-Shell zum Ausführen von Code in verschiedenen Sprachen wie ASP, ASPX, PHP, JSP und CFM. In diesem Blog gehen wir auf die JScript-Version ein; generell sind sich die Versionen, abgesehen von der verwendeten Sprache, jedoch alle sehr ähnlich.

 

01

Abbildung 1 – China Chopper ASPX Script

 

Dieses Skript ist im Wesentlichen eine Seite, auf der – wenn eine HTTP-POST-Anfrage an die Seite gestellt wird – das Skript die JScript-Funktion „eval“ aufruft, um die Zeichenfolge innerhalb einer bestimmten POST-Anfragevariablen auszuführen. Im obigen Skript heißt diese Variable „secret“, was bedeutet, dass jedes in der „secret“-Variablen enthaltene JScript auf dem Server ausgeführt wird.

JScript ist als aktive Scripting-Engine implementiert, die es der Sprache ermöglicht, ActiveX-Objekte auf dem Client zu verwenden, auf dem sie ausgeführt wird. Dies kann und wird von Angreifern missbraucht, um Reverse-Shells, File-Management, Prozessausführung und vieles mehr zu erreichen.

Nachdem wir einen Test-IIS-Server eingerichtet und die Web-Shell auf dem Server platziert haben, können wir nun unsere eigenen Payloads dagegen testen. Dazu haben wir mit Python HTTP-POST-Anfragen an die China Chopper-Seite gesendet und unser schadhaftes JScript in eine HTTP-POST-Variable „secret“ eingefügt.

Hier ist unser Beispiel-Payload, der eine Befehlseingabe startet und sich selbst anpingt. Dies demonstriert eine mögliche Prozessausführung.

 

02

Abbildung 2 – Jscript Payload 01

 

China Chopper aus der Angreiferperspektive

Der Angreifer verwendet typischerweise eine Client-Komponente der China Chopper Web-Shell auf seinen Systemen. Bei diesem Client handelt es sich um eine C-Binärdatei. Diese ermöglicht es dem Angreifer, unautorisiert z.B. Dateien herunter- und hochzuladen, ein Virtual Terminal zu betreiben – um alles auszuführen, was man normalerweise mit cmd.exe könnte –, Zeitstempel zu verändern, benutzerdefinierten JScript auszuführen, Dateien zu durchsuchen und vieles mehr. All dies wird nur durch eine einzige Codezeile auf dem Server möglich gemacht.

 

03

Abbildung 3 – Custom Script Execution

 

04

Abbildung 4 – Virtual Terminal

 

05

Abbildung 5 – File Manager

 

Um genau zu sehen, was der Client an die Web-Shell sendet, haben wir die HTTP-Anfrage zum Ausführen des folgenden benutzerdefinierten JScript aufgezeichnet:

Response.Write(“Hello World”);

Dieses Skript sollte als HTTP-POST-Anfrage vom Client an den Server gesendet werden, wobei das benutzerdefinierte JScript im POST-Feld „secret“ gesendet werden sollte. Der folgende Code zeigt die gesendete Anfrage:

 

06

Abbildung 6 – Custom JScript Response

 

Wir können sehen, dass der Client das benutzerdefinierte JScript in Base64 codiert und die Marker „->|“ sowie „<-|“ verwendet, um dem Client zu helfen, den Teil der Antwort zu identifizieren, der sich auf die Web-Shell bezieht.

Das Ausführen eines komplexeren Befehls wie der für das Virtual Terminal sowie das Ausführen von „ipconfig“ führt zum gleichen Ergebnis. Allerdings wird der Base64-codierte Befehl automatisch vom Client generiert und in den folgenden Code decodiert:

 

07

Abbildung 7 – Virtual Terminal ipconfig Response

 

Diese Anfrage führt zwei neue POST-Variablen ein, die Base64-codierte Zeichenketten enthalten:

08

 

Gemäß diesem Code startet die Funktion „Virtual Terminal“ den CMD-Prozess im Hintergrund und führt den vom Client gesendeten Befehl aus. Die Ausgabe wird dann erfasst und an den Client zurückgesendet.

 

ASP.NET Runtime and .NET DLLs

Bei einigen der Artefakte, die auf den kompromittierten IIS-Servern gefunden wurden, handelte es sich um DLLs. Wird ein ASPX-Skript der ASP.NET Runtime zum ersten Mal angezeigt, wird das ASPX-Skript geparst und in eine C#- oder VB.NET-Klassendatei umgewandelt. Diese wird dann entweder in eine eigene .NET-Assembly kompiliert oder, abhängig von den IIS-Einstellungen, mit anderen konvertierten ASPX-Skripten zu einer größeren .NET-Assembly kombiniert. Diese .NET-Assembly ist das, was dem Endbenutzer zur Verfügung gestellt wird – und nicht das ASPX-Skript selbst. Die .NET-DLLs werden zusammen mit einer XML-Datei, die speziell für diese .NET-DLL erstellt wurde und als Aufbewahrungsdatei bezeichnet wird, an einem temporären Speicherort gespeichert.

09

Abbildung 8 – ASP.NET Runtime Flow

 

Für die China Chopper ASPX-Datei wurde eine .NET-Assembly zusammen mit einer Aufbewahrungsdatei kompiliert und in einem temporären Verzeichnis für kompilierte ASPX-Dateien gespeichert. Bei unserem IIS-Server waren die Speicherorte:

10

 

Die verdächtig aussehenden zufälligen Zeichenfolgen sind nur Hashes der Dateinamen und Pfade für die interne Verwendung mit der ASP.NET Runtime.

Beim Öffnen der Datei App_Web_bvbfecjk.dll in DNSpy können wir mehrere Verfahren innerhalb der DLL sehen. Nur eines dieser Verfahren enthält die C# .NET-Version des China Chopper ASPX-Skripts. Bei den anderen handelt es sich um Boilerplate-Code, den die ASP.NET Runtime ausführen kann, bevor sie zum kompilierten ASPX-Skript gelangt.

11

Abbildung 9 – C# Converted ASPX Script

 

Bei dieser Methode ist eine starke Ähnlichkeit zu der ASPX China Chopper Web-Shell in einem kompilierten C# .NET Assembly-Format zu erkennen. Dies wird einem Benutzer bereitgestellt, wenn die Seite angefordert wird.

Interessant ist hier der JScript-Stack-Frame. Wir können sehen, dass zwei lokale Variablen auf den JScript-Stack verschoben wurden. Bei diesen Variablen handelt es sich um „__w“ und „parameterContainer“. Theoretisch sollten wir in dem JScript, das wir zur Ausführung senden, auf diese Variablen zugreifen können.

 

12

Abbildung 10 – Jscript Payload 02

 

Wie wir feststellen können, wurde das JScript erfolgreich ausgeführt. Dabei wurde die auf den Stack geschobene Variable „__w“ verwendet, um den Text „Hello World“ fett gedruckt auf der Seite darzustellen. Dies kann für den Angreifer nützlich sein, um die Ausgabe seines Skripts zu rendern.

Bei der Aufbewahrungsdatei für die generierte Assembly handelt es sich um eine XML-Datei mit der Erweiterung „.compiled“. Der Inhalt dieser Datei ist nicht sehr interessant. Sie enthält hauptsächlich Metadaten für die ASP.NET Runtime, mit denen ermittelt werden kann, ob die ursprüngliche ASPX-Datei neu kompiliert werden muss. Außerdem lässt sich damit beantworten, für welche Assembly-Datei eine Seitenanfrage bereitgestellt werden soll.

13

Abbildung 11 – Preserve File

 

Zusammenfassend lässt sich sagen, dass bei der Untersuchung von Servern auf Anzeichen einer Kompromittierung nicht nur auf ASPX-Skripte, sondern auch auf die entsprechenden DLLs geachtet werden sollte, die von der ASP.NET Runtime generiert werden. Zukünftig werden aufgrund der Zero-Day-Exploits von HAFNIUM und mehreren anderen kriminellen Gruppen wahrscheinlich noch viele Systeme mit Web-Shells kompromittiert. Daher schadet es nicht, ein wenig mehr darüber zu wissen, wie diese ASPX-Web-Shell-Skripte im Hintergrund mit der ASP.NET Runtime funktionieren und wie der Angriff aus Sicht eines Angreifers aussieht.

 

IOCs

Name

Hash (SHA-1)

File Type

App_Web_rkpouxdy.dll

fa3dc5cd49bd6aadb7f4c30e3381d0da0c7adb96

DLL

chinachopper.aspx

55f29d511d39e87b32c710a3ad32e61d4c40a30a

ASPX

ChinaChopperClient.exe

056a60ec1f6a8959bfc43254d97527b003ae5edb

PE32