MAUTSTELLE: Was ist deine, IIS meine?

Einführung

Im September 2025 entdeckte die Cybersicherheitsabteilung des Texas A&M University System (TAMUS), ein Anbieter von Managed Detection and Response, in Zusammenarbeit mit Elastic Security Labs Aktivitäten nach der Ausnutzung einer Sicherheitslücke durch einen chinesischsprachigen Bedrohungsakteur, der ein bösartiges IIS-Modul installiert hatte, das wir TOLLBOOTH nennen. Während dieser Zeit beobachteten wir ein von Godzilla abgeleitetes Webshell- Framework, die Verwendung des Remote Monitoring and Management (RMM)-Tools GotoHTTP sowie einen bösartigen Treiber, der dazu diente, ihre Aktivitäten zu verschleiern. Der Angreifer nutzte einen falsch konfigurierten IIS-Webserver aus, der ASP.NET-Maschinenschlüssel verwendete, die in öffentlichen Quellen wie der Dokumentation von Microsoft oder den Supportseiten von StackOverflow gefunden wurden.

Eine ähnliche Ereigniskette wurde erstmals im Februar dieses Jahres von Microsoft gemeldet . Unser Team geht davon aus, dass es sich hierbei um die Fortsetzung derselben Bedrohungsaktivitäten handelt, die AhnLab bereits im April detailliert beschrieben hat , basierend auf ähnlicher Malware und ähnlichen Verhaltensweisen. Im Rahmen dieser Veranstaltung konnten wir unsere Partnerschaft mit der Cybersicherheitsabteilung des Texas A&M Systems nutzen, um Erkenntnisse über die Aktivitäten zu gewinnen. Darüber hinaus haben wir durch die Zusammenarbeit mit Validin und die Nutzung ihrer globalen Scaninfrastruktur festgestellt, dass Organisationen weltweit von dieser Kampagne betroffen sind. Im Folgenden werden die Ereignisse und die in diesem Aktivitätscluster, bekannt als REF3927, verwendeten Werkzeuge detailliert beschrieben. Wir hoffen, das Bewusstsein für diese Aktivität bei Verteidigern und Organisationen zu schärfen, da sie weltweit aktiv missbraucht wird.

Wichtigste Erkenntnisse

• Bedrohungsakteure missbrauchen falsch konfigurierte IIS-Server mithilfe öffentlich zugänglicher Maschinenschlüssel.
• Zu den Verhaltensweisen nach einer Kompromittierung gehören die Verwendung eines schädlichen Treibers, Fernüberwachungstools, das Auslesen von Anmeldeinformationen, die Bereitstellung von Webshells und IIS-Malware.
• Bedrohungsakteure haben das Open-Source-Rootkit-Projekt „Hidden“ angepasst, um ihre Präsenz zu verbergen.
• Das Hauptziel scheint die Installation einer IIS-Hintertür namens TOLLBOOTH zu sein, die SEO-Cloaking und Webshell-Funktionen umfasst.
• Diese Kampagne umfasste groß angelegte Ausbeutung über verschiedene Regionen und Branchen hinweg.

Übersicht über die Kampagne

Angriffsvektor

Im vergangenen Monat untersuchten Elastic Security Labs und Texas A&M System Cybersecurity einen Einbruch, bei dem ein falsch konfigurierter Windows IIS-Server beteiligt war. Dies stand in direktem Zusammenhang mit einem Server, der mit ASP.NET-Maschinenschlüsseln konfiguriert war, die zuvor im Internet veröffentlicht worden waren. Bei den in ASP.NET-Anwendungen verwendeten Maschinenschlüsseln handelt es sich um kryptografische Schlüssel, die zum Verschlüsseln und Validieren von Daten verwendet werden. Diese Schlüssel bestehen aus zwei Teilen, ValidationKey und DecryptionKey, die zur Sicherung von ASP.NET-Funktionen wie ViewState und Authentifizierungs-Cookies verwendet werden.

ViewState ist ein Mechanismus, der von ASP.NET -Webanwendungen verwendet wird, um den Zustand einer Seite und ihrer Steuerelemente über HTTP-Anfragen hinweg zu erhalten. Da HTTP ein zustandsloses Protokoll ist, ermöglicht ViewState die Erfassung von Daten beim Absenden und erneuten Rendern der Seite. Diese Daten werden in einem versteckten Feld (__VIEWSTATE) auf der Seite gespeichert, das serialisiert und in Base64 kodiert wird. Dieses ViewState Feld ist anfällig für Deserialisierungsangriffe, wodurch ein Angreifer mithilfe der Maschinenschlüssel der Anwendung Payloads fälschen kann. Wir haben Grund zu der Annahme, dass dies Teil einer opportunistischen Kampagne ist, die auf Windows-Webserver abzielt, indem öffentlich zugängliche Maschinenschlüssel verwendet werden.

Nachfolgend ein Beispiel für diese Art von Deserialisierungsangriff, demonstriert durch eine POST-Anfrage in einer virtuellen Umgebung unter Verwendung eines Open-Source-.NET-Deserialisierungs-Payload- Generators. Das Feld __VIEWSTATE enthält eine URL-codierte und Base64-codierte Nutzlast, die eine whoami ausführt und eine Datei in ein Verzeichnis schreibt. Bei erfolgreicher Ausnutzungsanfrage antwortet der Server mit einem HTTP/1.1 500 Internal Server Error.

Aktivitäten nach dem Kompromittierungsfall

Beim ersten Zugriff über ViewState-Injection wurde beobachtet, dass REF3927 Webshells, einschließlich eines Godzilla-Shell-Frameworks, einsetzte, um einen dauerhaften Zugriff zu ermöglichen. Anschließend zählten sie die Berechtigungen auf und versuchten (erfolglos), eigene Benutzerkonten zu erstellen. Als Versuche zur Kontoerstellung fehlschlugen, lud der Akteur das GotoHTTP Remote Monitoring and Management (RMM)-Tool hoch und führte es aus. Der Angreifer erstellte ein Administratorkonto und versuchte, mit Hilfe von Mimikatz Zugangsdaten auszulesen, was jedoch von Elastic Defend verhindert wurde.

Nachdem Versuche, den Umfang des Eindringens weiter auszudehnen, blockiert wurden, setzte der Angreifer sein IIS-Modul TOLLBOOTH zur Manipulation des Datenverkehrs ein, um seinen Zugriff zu monetarisieren. Der Akteur versuchte außerdem, eine modifizierte Version des Open-Source-Rootkits Hidden einzusetzen, um seine Malware zu verschleiern. Bei dem beobachteten Einbruchsversuch verhinderte Elastic Defend die Ausführung von TOLLBOOTH und des Rootkits.

Godzilla EKP-Analyse

Eines der wichtigsten Werkzeuge dieser Gruppe ist ein von Godzilla abgeleitetes Framework namens Z-Godzilla_ekp geschrieben von ekkoo-z. Dieses Tool baut auf dem vorherigen Godzilla -Projekt auf, indem es neue Funktionen hinzufügt, wie zum Beispiel ein AMSI-Bypass-Plugin, und seinen Netzwerkverkehr maskiert, um legitimer zu wirken. Dieses Toolkit ermöglicht es Anwendern, ASP.NET-, Java-, C#- und PHP-Payloads zu generieren, Verbindungen zu Zielen herzustellen und bietet verschiedene Verschlüsselungsoptionen zum Verbergen des Netzwerkverkehrs. Dieses Framework verwendet ein Plugin-System mit einer grafischen Benutzeroberfläche (GUI) und vielen Funktionen, darunter:

• Erkennungs-/Aufzählungsfähigkeiten
• Techniken zur Rechteausweitung
• Befehlsausführung/Dateiausführung
• Shellcode-Loader, Meterpreter, PE-Ausführung im Speicher
• Dateiverwaltung, ZIP-Komprimierungsprogramm
• Cred-Stealing-Plugin (lemon) – Ruft Anmeldeinformationen für FileZilla, Navicat, WinSCP und Xmanager ab.
• Browserpasswort-Scraping
• Port-Scanning, HTTP-Proxy-Konfiguration, Notizen machen

Nachfolgend ein Beispiel für Netzwerkverkehr, das den Betreiberverkehr zur Webshell (error.aspx) über Z-Godzilla_ekp zeigt. Die Webshell nimmt die Base64-kodierten, AES-verschlüsselten Daten aus der HTTP-POST-Anfrage entgegen und führt anschließend die .NET-Assembly im Speicher aus. Diese Anfragen werden verschleiert, indem die verschlüsselten Daten in HTTP-POST-Parameter eingebettet werden, um sie als normalen Netzwerkverkehr erscheinen zu lassen.

Rootkit-Analyse

Der Angreifer verschleierte seine Anwesenheit auf dem infizierten Rechner durch den Einsatz eines Kernel-Rootkits. Dieses Rootkit arbeitet mit einer Benutzeranwendung namens HijackDriverManager zusammen, deren Schnittstellenzeichenfolgen in Chinesisch verfasst sind, um mit dem Treiber zu interagieren. Für diese Analyse untersuchten wir sowohl das bösartige Rootkit als auch den Code des ursprünglichen Open-Source-Projekts „Hidden“, aus dem es abgeleitet wurde. Intern rufen wir das Rootkit HIDDENDRIVER und die Benutzeranwendung HIDDENCLI auf.

Bei dieser Schadsoftware handelt es sich um eine modifizierte Version des Open-Source-Rootkits Hidden, das seit Jahren auf GitHub verfügbar ist. Der Malware-Autor nahm vor der Kompilierung kleinere Änderungen vor. Beispielsweise nutzt das Rootkit Direct Kernel Object Manipulation (DKOM), um seine Präsenz zu verbergen und sich dauerhaft auf dem kompromittierten System einzunisten. Der kompilierte Treiber enthält immer noch „hidden“ in der Pfadzeichenfolge der Kompilierung, was darauf hindeutet, dass das Rootkit-Projekt „Hidden“ verwendet wurde.

Beim ersten Laden in den Kernel priorisiert der Treiber eine Reihe kritischer Initialisierungsschritte. Zunächst werden sieben Initialisierungsfunktionen aufgerufen:

• InitializeConfigs
• InitializeKernelAnalyzer
• InitializePsMonitor
• InitializeFSMiniFilter
• InitializeRegistryFilter
• InitializeDevice
• InitializeStealthMode

Um die internen Komponenten vorzubereiten, bevor das Treiberobjekt und zugehörige Felder, wie z. B. Hauptfunktionen, gefüllt werden.

In den folgenden Abschnitten werden die sieben kritischen Initialisierungsfunktionen und ihre jeweiligen Zwecke detailliert erläutert.

InitializeConfigs

Die erste Aktion des Rootkits besteht darin, die Funktion InitializeConfigs auszuführen. Die einzige Aufgabe dieser Funktion besteht darin, die Konfiguration des Rootkits aus dem Dienstschlüssel des Treibers in der Windows-Registrierung zu lesen, der von der Benutzeranwendung befüllt wird. Diese Werte werden extrahiert und in globalen Konfigurationsvariablen gespeichert, die später vom Rootkit verwendet werden.

Die folgende Tabelle fasst die Konfigurationsparameter zusammen, die das Rootkit aus der Registry extrahiert:

InitializeKernelAnalyzer

Sein Zweck besteht darin, den Kernelspeicher dynamisch zu durchsuchen, um die Adressen der benötigten PspCidTable und ActiveProcessLinks zu finden.

Die PspCidTable ist die Kernelstruktur, die als Tabelle für Prozess- und Thread-IDs dient, während ActiveProcessLinks unter der _EPROCESS Struktur als doppelt verkettete Liste dient, die alle aktuell laufenden Prozesse miteinander verbindet. Es ermöglicht dem System, alle aktiven Prozesse zu verfolgen und zu durchlaufen. Durch das Entfernen von Einträgen aus dieser Liste ist es möglich, Prozesse vor Enumerationstools wie dem Process Explorer zu verbergen.

LookForPspCidTable

Es sucht nach der Adresse PspCidTable , indem es die Funktion PsLookupProcessByProcessIdmit der Bibliothek Zydis disassembliert und analysiert.

LookForActiveProcessLinks

Diese Funktion bestimmt den Offset des Feldes ActiveProcessLinks innerhalb der Struktur _EPROCESS . Es verwendet fest codierte Offsetwerte, die für verschiedene Windows-Versionen spezifisch sind. Es verfügt über einen schnellen Scanvorgang, der auf diesen fest codierten Werten basiert, um das Feld ActiveProcessLinks zu finden, welches anschließend von einer anderen Funktion validiert wird. Falls die Suche mit den fest codierten Werten fehlschlägt, wird ein Brute-Force-Ansatz verfolgt, indem von einem fest codierten relativen Offset zum maximal möglichen Offset ausgegangen wird.

InitializePsMonitor

InitializePsMonitor Richtet die Prozessüberwachungs- und Manipulations-Engine des Rootkits ein. Dies ist der Kern seiner Fähigkeit, Prozesse zu verbergen.

Zunächst werden drei AVL-Baumstrukturen initialisiert, um Informationen (Regeln) zum Ausschließen, Schützen und Ausblenden von Prozessen zu speichern. Es verwendet RtlInitializeGenericTableAvl für Hochgeschwindigkeitsabfragen und füllt diese mit Daten aus der Konfiguration. Anschließend werden verschiedene Kernel-Callbacks eingerichtet, um das System anhand der festgelegten Regeln zu überwachen.

Registrierung des Objektmanager-Callbacks mit (ObRegisterCallbacks)

Dieser Hook registriert die Funktionen ProcessPreCallback und ThreadPreCallback . Der Objektmanager des Kernels führt diesen Code aus, bevor er eine Anfrage zum Erstellen oder Duplizieren eines Handles zu einem Prozess oder Thread abschließt.

Wenn ein Prozess versucht, einen anderen Prozess zu übernehmen, wird die Rückruffunktion ProcessPreCallback aufgerufen. Es wird zunächst geprüft, ob es sich bei dem Zielprozess um einen geschützten Prozess (in der Liste) handelt. In diesem Fall wird der Zugriff nicht verweigert, sondern die Rechte am geschützten Prozess werden einfach herabgestuft, wobei der Zugriff auf SYNCHRONIZE | PROCESS_QUERY_LIMITED_INFORMATION gesetzt wird.

Dadurch wird sichergestellt, dass Prozesse nicht mit dem geschützten Prozess interagieren, ihn untersuchen oder beenden können.

Der gleiche Mechanismus gilt auch für Fäden.

Prozesserstellungs-Callback (PsSetCreateProcessNotifyRoutineEx)

Das Rootkit registriert bei der Prozesserstellung einen Callback bei der PsSetCreateProcessNotifyRoutineEx API. Wenn ein neuer Prozess gestartet wird, führt dieser Callback eine Funktion CheckProcessFlags aus, die das Image des Prozesses mit der konfigurierten Liste der Image-Pfade vergleicht. Anschließend wird ein Eintrag für diesen neuen Prozess in der internen Tracking-Tabelle erstellt, wobei die Flags excluded, protected und hidden entsprechend gesetzt werden.

Verhalten basierend auf Flags:

• Ausgeschlossen
  • Das Rootkit ignoriert den Prozess und lässt ihn einfach wie erwartet laufen.
• Geschützt
  • Das Rootkit wird es keinem anderen Prozess erlauben, einen privilegierten Zugriff darauf zu erhalten, ähnlich wie es in ProcessPreCallback der Fall ist.
• Versteckt
  • Das Rootkit wird den Prozess durch direkte Kernel-Objektmanipulation (DKOM) verbergen. Die direkte Manipulation der Kernstrukturen eines Prozesses im Moment seiner Entstehung kann zu Instabilität führen. Im Callback zur Prozesserstellung wird ein Prozess, der ausgeblendet werden soll, aus der Liste ActiveProcessLinks entfernt. Allerdings wird ein postponeHiding -Flag gesetzt, das weiter unten erläutert wird.

Der Image Load Callback (PsSetLoadImageNotifyRoutine)

Dies registriert die LoadProcessImageNotifyCallback mit PsSetLoadImageNotifyRoutine, die der Kernel immer dann aufruft, wenn ein ausführbares Image (ein .exe oder .dll) in den Speicher eines Prozesses geladen wird.

Beim Laden des Images prüft der Callback das Flag postponeHiding ; falls gesetzt, ruft er UnlinkProcessFromCidTable auf, um es aus der Master-Prozess-ID-Tabelle (PspCidTable) zu entfernen.

InitializeFSMiniFilter

Die Funktion definiert ihre Fähigkeiten in FilterRegistration structure(FLT_REGISTRATION). Diese Struktur teilt dem Betriebssystem mit, welche Funktionen für welche Arten von Dateisystemoperationen aufgerufen werden sollen. Es registriert Rückruffunktionen für die folgenden Anfragen:

• IRP_MJ_CREATE: Unterbindet jeden Versuch, eine Datei oder ein Verzeichnis zu öffnen oder zu erstellen.
• IRP_MJ_DIRECTORY_CONTROL: Unterbindet jeden Versuch, den Inhalt eines Verzeichnisses aufzulisten.

FltCreatePreOperation(IRP_MJ_CREATE)

Dies ist ein Voroperations-Callback; diese Funktion wird ausgelöst, wenn ein Prozess versucht, eine Datei zu erstellen/zu öffnen. Es prüft den Pfad anhand seiner Liste der auszublendenden Dateien. Wird eine Übereinstimmung gefunden, ändert sich das Operationsergebnis der IRP-Anfrage auf STATUS_NO_SUCH_FILE, was dem anfragenden Prozess signalisiert, dass die Datei nicht existiert, es sei denn, der Prozess ist in der Ausschlussliste enthalten.

FltDirCtrlPostOperation(IRP_MJ_DIRECTORY_CONTROL)

Dies ist ein Callback nach der Operation; der implementierte Hook fängt im Wesentlichen die vom System generierte Verzeichnisliste ab und modifiziert sie, indem er alle als versteckt aufgeführten Dateien entfernt.

InitializeRegistryFilter

Nachdem das Rootkit seine Prozesse und Dateien verborgen hat, besteht der nächste Schritt darin, Einträge aus der Windows-Registrierung zu löschen. Die Funktion InitializeRegistryFilter erreicht dies durch die Installation eines Registry-Filter-Callbacks, der Registry-Operationen abfängt und modifiziert.

Es registriert einen Callback mithilfe der CmRegisterCallbackEx API, nach dem gleichen Prinzip wie bei Dateien. Wenn sich der Registrierungsschlüssel oder -wert in der Liste der versteckten Registrierungseinträge befindet, gibt die Rückruffunktion den Status STATUS_NOT_FOUND zurück.

Gerät initialisieren

Die Funktion InitializeDevice führt die notwendige Treiberinitialisierung durch und richtet eine IOCTL communication ein, damit die Benutzeranwendung direkt mit ihr kommunizieren kann.

Nachfolgend eine Tabelle mit den vom Treiber verarbeiteten IOCTL-Befehlen.

Stealth-Modus initialisieren

Nach erfolgreicher Einrichtung der Konfiguration, der Prozess-Callbacks und der Dateisystemfilter führt das Rootkit seine letzte Initialisierungsroutine aus: InitializeStealthMode. Wenn das Konfigurationsflag Kbj_YinshenMode aktiviert ist, werden alle mit dem Rootkit verbundenen Artefakte, einschließlich Registrierungsschlüssel, der Datei .sys und anderer zugehöriger Komponenten, mithilfe der oben beschriebenen Techniken ausgeblendet.

Code-Variationen

Obwohl die Malware stark auf dem HIDDENDRIVER -Quellcode basiert, haben wir in unserer Analyse einige kleinere Änderungen festgestellt. Im folgenden Abschnitt werden die von uns beobachteten wesentlichen Codeunterschiede detailliert erläutert.

Der ursprüngliche Code in der Funktion IsProcessExcluded schließt den Systemprozess (PID 4) konsequent von den Operationen des Rootkits aus. Allerdings verfügt das bösartige Rootkit über eine Ausschlussliste für zusätzliche Prozessnamen, wie im beigefügten Screenshot dargestellt.

Der ursprüngliche Code verwendete die Callback-Funktion zum Filtern von Systeminformationen (einschließlich Dateien, Verzeichnissen und Registrierungseinträgen), um mit der Funktion IsDriverEnabled zu überprüfen, ob die Treiberfunktionen aktiviert waren. Allerdings führte das beobachtete Rootkit eine zusätzliche, automatische Whitelist-Prüfung für Prozesse mit dem Image-Namens-Hijack ein, der der Benutzeranwendung entspricht.

RMM-Nutzung

Das Tool GotoHTTP ist eine legitime Remote Monitoring and Management (RMM)-Anwendung, die vom Angreifer eingesetzt wird, um den Zugriff auf den kompromittierten IIS-Server zu erleichtern. Durch die „Browser-zu-Client“-Architektur kann der Angreifer den Server von jedem Standard-Webbrowser über gängige Webports (80/443) aus steuern, indem der gesamte Datenverkehr über die eigene Plattform von GotoHTTP geleitet wird. Dadurch wird eine direkte Netzwerkverbindung zur eigenen Infrastruktur des Angreifers verhindert.

RMMs erfreuen sich weiterhin wachsender Beliebtheit und werden an verschiedenen Punkten der Cyber-Kill-Chain sowie von unterschiedlichen Bedrohungsakteuren eingesetzt. Die meisten Anti-Malware-Anbieter betrachten sie isoliert betrachtet nicht als schädlich und blockieren sie daher nicht pauschal. RMM C2 leitet Daten ausschließlich an legitime RMM-Anbieter-Websites weiter und weist daher die gleiche Dynamik für netzwerkbasierte Schutz- und Überwachungsmechanismen auf.

Die optimale Schutzmaßnahme wäre, die Masse der derzeit aktiven RMM-Systeme zu blockieren und nur das vom Unternehmen bevorzugte RMM-System zuzulassen. Dieses Paradigma steht jedoch nur Unternehmen zur Verfügung, die über das entsprechende technische Wissen, defensive Werkzeuge, ausgereifte Organisationsrichtlinien und eine abteilungsübergreifende Koordination verfügen.

IIS-Modulanalyse

Es wurde beobachtet, dass der Angreifer sowohl 32-Bit- als auch 64-Bit-Versionen von TOLLBOOTH, einem bösartigen IIS-Modul, einsetzte. TOLLBOOTH wurde bereits von Ahnlab und dem Sicherheitsforscher @Azaka diskutiert. Zu den wichtigsten Funktionen der Malware gehören SEO-Cloaking, ein Managementkanal und eine öffentlich zugängliche Webshell. Wir haben festgestellt, dass sowohl native als auch .NET-verwaltete Versionen im Einsatz sind.

Malware-Konfigurationsstruktur

TOLLBOOTH bezieht seine Konfiguration dynamisch von hxxps://c[.]cseo99[.]com/config/<victim_HTTP_host_value>.json, und die Erstellung der JSON-Konfigurationsdatei jedes Opfers wird von der Infrastruktur des Bedrohungsakteurs übernommen. Jedoch antwortete hxxps://c[.]cseo99[.]com/config/127.0.0.1.json und zeigte damit das Fehlen von Anti-Analyse-Prüfungen an – wodurch wir eine Kopie einer Konfigurationsdatei zur Analyse abrufen konnten. Es kann in diesem GitHub Gist eingesehen werden, und wir werden gegebenenfalls darauf eingehen, wie einige der Felder verwendet werden.

Bei nativen Modulen werden die Konfigurationsdateien und andere temporäre Cache-Dateien Gzip-komprimiert und lokal unter einem fest codierten Pfad C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\ gespeichert. Für das verwaltete Modul werden diese mit dem Schlüssel YourSecretKey123 und dem Initialisierungsvektor 0123456789ABCDEF AES-verschlüsselt, Gzip-komprimiert und unter C:\\Windows\\Temp\\AcpLogs\\ gespeichert.

Webshell

TOLLBOOTH stellt eine Webshell unter dem Pfad /mywebdll bereit, für deren Datei-Uploads und Befehlsausführung das Passwort hack123456! erforderlich ist. Durch das Absenden des Formulars wird eine POST Anfrage an den /scjg Endpunkt gesendet.

Das Passwort ist in der Binärdatei fest codiert, und diese Webshell-Funktion ist sowohl in v1.6.0 als auch in v1.6.1 der nativen Version von TOLLBOOTH vorhanden.

Die Datei-Upload-Funktionalität enthält einen Fehler, der auf die sequentielle, reihenfolgeabhängige Analyse der multipart/form-data -Felder zurückzuführen ist. Das Standard-HTML-Formular ist so aufgebaut, dass das Dateiauswahlfeld vor den Verzeichnisauswahlfeldern erscheint. Der Server, der die Anfrageteile verarbeitet, versucht, die Dateidaten vor dem Zielverzeichnis zu verarbeiten, wodurch ein Abhängigkeitskonflikt entsteht, der dazu führt, dass Standard-Uploads fehlschlagen. Durch manuelles Umordnen der multipart/form-data Teile kann ein erfolgreicher Datei-Upload weiterhin ausgelöst werden.

Managementkanal

TOLLBOOTH stellt einige zusätzliche Endpunkte für die Verwaltung/Fehlerbehebung durch C2-Betreiber bereit. Sie sind nur zugänglich, wenn der User-Agent auf einen der folgenden Werte eingestellt ist (dies ist jedoch konfigurierbar):

Hijackbot
gooqlebot
Googlebot/2.;
Googlébot
Googlêbot
Googlebót;
Googlebôt;
Googlebõt;
Googlèbot;
Googlëbot;
Binqbot
bingbot/2.;
Bíngbot
Bìngbot
Bîngbot
Bïngbot
Bingbót;
Bingbôt;
Bingbõt;

Der /health -Endpunkt bietet eine schnelle Möglichkeit, den Zustand des Moduls zu beurteilen. Er gibt den Dateinamen für den Zugriff auf die unter c[.]cseo99[.]com gespeicherte Konfiguration, Informationen zum Speicherplatz, den Installationspfad des Moduls und die Version von TOLLBOOTH zurück.

Der /debug -Endpunkt liefert weitere Details, darunter eine Zusammenfassung der Konfiguration, des Cache-Verzeichnisses, Informationen zur HTTP-Anfrage usw.

Die analysierte Konfiguration ist unter /conf zugänglich.

Der /clean -Endpunkt ermöglicht es dem Bediener, die aktuelle Konfiguration zu löschen, indem er die lokal gespeicherten Konfigurationsdateien (clean?type=conf) löscht, um sie auf dem Zielserver zu aktualisieren, alle anderen temporären Caches, die die Malware verwendet (clean?type=conf), löscht oder beides löscht – alles im Pfad C:\\Windows\\Temp\\_FAB234CD3-09434-8898D-BFFC-4E23123DF2C\\ (clean?type=all).

SEO-Cloaking

Das Hauptziel von TOLLBOOTH ist SEO Cloaking, ein Prozess, bei dem den Suchmaschinen-Crawlern keywordoptimierte Inhalte präsentiert werden, während diese vor dem normalen Nutzerzugriff verborgen bleiben, um höhere Suchmaschinenplatzierungen für die Seite zu erreichen. Sobald ein menschlicher Besucher auf den Link in den hervorgehobenen Suchergebnissen klickt, leitet die Schadsoftware ihn auf eine bösartige oder betrügerische Seite weiter. Diese Taktik ist im Vergleich zu Alternativen wie direktem Phishing eine effektive Methode, den Traffic auf schädlichen Seiten zu erhöhen, da die Nutzer den von ihnen angeforderten Suchmaschinenergebnissen mehr vertrauen als unerwünschten E-Mails.

TOLLBOOTH unterscheidet zwischen Bots und Besuchern, indem es die User-Agent- und Referer-Header auf in der Konfiguration definierte Werte überprüft.

Sowohl die nativen als auch die verwalteten Module sind nahezu identisch implementiert. Der einzige Unterschied besteht darin, dass die nativen Module v1.6.0 und v1.6.1 sowohl den User-Agent als auch den Referer anhand der Liste seoGroupRefererMatchRules überprüfen, während das .NET-Modul v1.6.1 den User-Agent anhand der Liste seoGroupUaMatchRules und den Referer anhand der Liste seoGroupRefererMatchRules überprüft.

Ausgehend von der aktuellen Konfiguration sind die Werte für seoGroupUaMatchRules und seoGroupRefererMatchRules jeweils googlebot und google. Ein GoogleBot-Crawler hätte eine Übereinstimmung mit dem User-Agent, aber keine Übereinstimmung mit dem Referer, während ein menschlicher Besucher eine Übereinstimmung mit dem Referer, aber keine Übereinstimmung mit dem User-Agent hätte. Die Tatsache, dass die Fallback-Liste sowohl bing als auch yahoo enthält, lässt vermuten, dass diese Suchmaschinen auch in der Vergangenheit Ziel von Angriffen waren.

Der unten stehende Codeausschnitt ist dafür verantwortlich, eine Seite zu erstellen, die mit mit Schlüsselwörtern gefüllten Links versehen ist, die von Suchmaschinen-Crawlern erfasst werden.

Das Modul baut eine Linkfarm in zwei Phasen auf. Zunächst wird zur Erstellung der internen Linkdichte eine Liste zufälliger Schlüsselwörter aus den im Konfigurationsfeld affLinkMainWordSeoResArr definierten Ressourcen-URIs abgerufen. Für jedes Schlüsselwort wird ein „lokaler Link“ generiert, der auf eine andere SEO-Seite auf derselben kompromittierten Website verweist. Anschließend wird das externe Netzwerk aufgebaut, indem "Affiliate-Link-Ressourcen" aus dem Feld affLinkSeoResArr abgerufen werden. Bei diesen Ressourcen handelt es sich um eine Liste von URIs, die auf SEO-Seiten auf anderen externen Domains verweisen, die ebenfalls mit TOLLBOOTH infiziert sind. Die URIs sehen in der Konfiguration wie hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> aus. Das Modul erstellt dann Hyperlinks von der aktuellen Seite zu diesen anderen Opfern. Diese Technik, bekannt als Link Farming, dient dazu, die Suchmaschinenplatzierungen im gesamten Netzwerk kompromittierter Websites künstlich zu erhöhen.

Nachfolgend ein Beispiel dafür, was ein Crawler-Bot beim Besuch der Landingpage eines mit TOLLBOOTH infizierten Webservers sehen würde.

Die URL-Pfadpräfixe der SEO-Seiten enthalten Wörter oder Phrasen aus dem Konfigurationsfeld seoGroupUrlMatchRules . Dies wird auch in der Logik zur Website-Weiterleitung für Besucher berücksichtigt. Dies sind derzeit folgende:

• stock
• invest
• summary
• datamining
• market-outlook
• bullish-on
• news-overview
• news-volatility
• video/
• app/
• blank/

Vorlagen und Inhalte für SEO-Seiten werden auch extern über URIs abgerufen, die in der Konfiguration wie hxxps://f[.]fseo99[.]com/<date>/<md5_file_hash><.txt/.html> aussehen. Hier ist ein Beispiel dafür, wie eine der SEO-Seiten aussieht:

Für die Benutzerumleitungslogik erfasst das Modul zunächst einen Fingerabdruck des Besuchers, einschließlich seiner IP-Adresse, seines User-Agents, des Referrers und des Zielkeywords der SEO-Seite. Anschließend werden diese Informationen per POST-Anfrage an hxxps://api[.]aseo99[.]com/client/landpage gesendet. Wenn die Anfrage erfolgreich ist, antwortet der Server mit einem JSON-Objekt, das ein spezifisches landpageUrl enthält, welches zum Ziel für die Weiterleitung wird.

Falls die Kommunikation aus irgendeinem Grund fehlschlägt, erstellt TOLLBOOTH eine neue URL, die auf denselben C2-Endpunkt verweist, kodiert aber stattdessen die Besucherinformationen direkt in die URL als GET-Parameter. Schließlich wird die gewählte URL – entweder aus der erfolgreichen C2-Antwort oder der Fallback-URL – in einen JavaScript-Snippet (window.location.href) eingebettet und an den Browser des Opfers gesendet, wodurch eine sofortige Weiterleitung erzwungen wird.

Seitenhijacker

Bei den nativen Modulen antwortet TOLLBOOTH mit einer benutzerdefinierten Ladeseite, die ein Skript-Tag enthält, wenn der URI-Pfad xlb enthält. Das src-Attribut dieses Skripts verweist auf eine dynamisch generierte URL, mlxya[.]oss-accelerate[.]aliyuncs[.]com/<12_random_alphanumeric_characters>, die zum Abrufen einer verschleierten JavaScript-Nutzlast der nächsten Stufe verwendet wird.

Die deobfuskierte Nutzlast scheint ein Seitenersetzungstool zu sein, das auf der Grundlage bestimmter Auslöseschlüsselwörter (z. B. xlbh, mxlb) in der URL ausgeführt wird. Sobald es ausgelöst wird, kontaktiert es einen der vom Angreifer kontrollierten Endpunkte unter asf-sikkeiyjga[.]cn-shenzhen[.]fcapp[.]run/index/index?href= oder ask-bdtj-selohjszlw[.]cn-shenzhen[.]fcapp[.]run/index/index?key= und hängt die URL der aktuellen Seite als Base64-codierten Parameter an, um die kompromittierte Website zu identifizieren. Anschließend verwendet das Skript document.write() , um das DOM der aktuellen Seite vollständig zu löschen und durch die Antwort des Servers zu ersetzen. Obwohl die endgültige Nutzlast zum Zeitpunkt der Erstellung dieses Dokuments nicht ermittelt werden konnte, ist diese Technik darauf ausgelegt, vom Angreifer kontrollierte Inhalte einzuschleusen, in der Regel eine bösartige HTML-Seite oder eine JS-Weiterleitung zu einer anderen bösartigen Website.

Kampagnenausrichtung

Bei der Analyse von TOLLBOOTH und der zugehörigen Webshell haben wir mehrere Mechanismen identifiziert, mit denen sich durch aktive und halbpassive Datenerfassungsmethoden weitere Opfer ermitteln lassen.

Anschließend haben wir uns mit @SreekarMad von Validin zusammengetan, um seine Expertise und deren Scanning-Infrastruktur zu nutzen und so eine umfassendere Liste der Opfer zu erstellen.

Zum Zeitpunkt der Veröffentlichung wurden 571 IIS-Serveropfer mit aktiven TOLLBOOTH-Infektionen identifiziert.

Diese Server sind global verteilt (mit einer wichtigen Ausnahme, die weiter unten beschrieben wird) und lassen sich keiner klar definierten Branchenkategorie zuordnen. Aus diesen Gründen und angesichts des schieren Umfangs der Operation gehen wir davon aus, dass die Auswahl der Opfer nicht gezielt erfolgt und automatisierte Scans genutzt werden, um IIS-Server zu identifizieren, die öffentlich gelistete Maschinenschlüssel wiederverwenden.

Die Zusammenarbeit mit Validin und Texas A&M System Cybersecurity lieferte eine umfangreiche Menge an Metadaten über die zusätzlichen TOLLBOOTH-infizierten Opfer.

Auch automatisierte Ausnutzung kann zum Einsatz kommen, doch TAMUS Cybersecurity stellte fest, dass die Aktivitäten nach der Ausnutzung interaktiv zu sein scheinen.

Validin entdeckte weitere potenziell infizierte Domains, die über die SEO-Farming-Linkkonfigurationen verknüpft waren, stellte jedoch bei der Überprüfung der Webshell-Schnittstelle fest, dass diese bei einigen nicht erreichbar war. Nach einer eingehenderen manuellen Untersuchung dieser Server stellten wir fest, dass sie tatsächlich mit TOLLBOOTH infiziert waren, aber entweder die Besitzer das Problem behoben haben oder die Angreifer sich zurückgezogen haben.

Weitere Scans ergaben, dass viele der gleichen Server erneut infiziert worden waren. Wir haben dies als Hinweis darauf gewertet, dass die Sanierungsmaßnahmen unvollständig waren. Eine plausible Erklärung ist, dass die bloße Beseitigung der Bedrohung die durch die Wiederverwendung des Maschinenschlüssels entstandene Sicherheitslücke nicht schließt. Opfer, die diesen letzten Schritt auslassen, werden daher höchstwahrscheinlich auf demselben Weg erneut infiziert. Weitere Einzelheiten finden Sie im Abschnitt „Remediation REF3927“ weiter unten.

Geographie

Die geografische Verteilung der Opfer schließt bemerkenswerterweise alle Server innerhalb der Grenzen Chinas aus. Ein Server wurde in Hongkong identifiziert, hostete aber eine .co.uk -Domain. Dieses wahrscheinliche Geofencing entspricht Verhaltensmustern anderer krimineller Bedrohungen, bei denen Mechanismen eingesetzt werden, um sicherzustellen, dass Systeme in den Heimatländern nicht angegriffen werden. Dies mindert ihr Risiko einer Strafverfolgung, da die Regierungen dieser Länder dazu neigen, kriminelle Aktivitäten gegen Ausländer zu ignorieren oder gar offen zu billigen.

Diamant-Modell

Elastic Security Labs verwendet das Diamond-Modell, um übergeordnete Beziehungen zwischen Angreifern, Fähigkeiten, Infrastruktur und Opfern von Eindringversuchen zu beschreiben. Während das Diamond-Modell am häufigsten bei einzelnen Eindringversuchen verwendet wird und Activity Threading (Abschnitt 8) nutzt, um Beziehungen zwischen Vorfällen herzustellen, ist ein angreiferzentriertes Modell (Abschnitt 7.1.4) üblich. Dieser Ansatz ermöglicht die Verwendung eines einzelnen Diamanten.

Sanierung von REF3927

Die Beseitigung der Infektion selbst kann durch branchenübliche Verfahren erfolgen, wie z. B. die Wiederherstellung eines sauberen Zustands und die Bekämpfung von Malware und Persistenzmechanismen. Angesichts potenzieller automatisierter Scans und Ausnutzungen bleibt die Schwachstelle des wiederverwendeten Maschinenschlüssels jedoch für jeden Angreifer bestehen, der den Server übernehmen möchte.

Daher muss die Behebung des Problems die Rotation der Maschinenschlüssel auf einen neuen, ordnungsgemäß generierten Schlüssel umfassen.

Fazit

Die REF3927-Kampagne verdeutlicht, wie ein einfacher Konfigurationsfehler, wie beispielsweise die Verwendung eines öffentlich zugänglichen Maschinenschlüssels, zu einer erheblichen Gefährdung führen kann. In diesem Fall haben die Cybersicherheitsabteilung des Texas A&M University Systems und der betroffene Kunde umgehend Maßnahmen ergriffen, um den Server zu reparieren. Unseren Recherchen zufolge gibt es jedoch weiterhin andere Opfer, die mit denselben Techniken angegriffen werden.

Die Integration von Open-Source-Tools, RMM-Software und einem bösartigen Treiber durch den Bedrohungsakteur ist eine effektive Kombination von Techniken, die sich bei seinen Operationen als erfolgreich erwiesen haben. Administratoren von öffentlich zugänglichen IIS-Umgebungen sollten ihre Maschinenschlüsselkonfigurationen überprüfen, eine robuste Sicherheitsprotokollierung sicherstellen und bei potenziellen Vorfällen Endpoint-Detection-Lösungen wie Elastic Defend nutzen.

Erkennungslogik

Regeln für die Erkennung

• Web-Shell-Erkennung: Skriptprozess-Unterprozess von gängigen Webprozessen

Präventionsregeln

• Verdächtige Ausführung über Windows-Dienste
• Mögliche Shellcode-Einschleusung über eine WebShell
• Ausführung aus verdächtigem Verzeichnis

YARA-Unterschriften

Elastic Security hat die folgenden YARA-Regeln erstellt, um die in REF3927 beobachtete Malware zu verhindern:

• Windows.Trojan.Mautstelle
• Windows.Trojan.HiddenCli
• Windows.Trojan.HiddenDriver

REF3927 durch MITRE ATT&CK

Elastic verwendet das MITRE ATT&CK-Framework , um gängige Taktiken, Techniken und Verfahren zu dokumentieren, die Bedrohungen gegen Unternehmensnetzwerke einsetzen.

Taktiken

Taktiken stellen das Warum einer Technik oder Untertechnik dar. Es ist das taktische Ziel des Gegners: der Grund für die Ausführung einer Aktion.

• Erstzugriff
• Ausführung
• Tarnung
• Zugriff mit Anmeldeinformationen
• Erfassung
• Exfiltration

Techniken

Techniken stellen dar, wie ein Angreifer ein taktisches Ziel erreicht, indem er eine Aktion ausführt.

• Exploit Public-Facing Application
• Server-Softwarekomponente: IIS-Komponenten
• BS-Credential-Dumping
• Hide Artifacts: Hidden Files and Directories
• Daten aus dem lokalen System
• Rootkit
• Gültige Konten

Beobachtungen

Die folgenden beobachtbaren Größen wurden in dieser Studie diskutiert.

Referenzen

In der obigen Studie wurde auf Folgendes Bezug genommen:

• https://www.microsoft.com/en-us/security/blog/2025/02/06/code-injection-attacks-using-publicly-disclosed-asp-net-machine-keys/
• https://asec.ahnlab.com/en/87804/
• https://unit42.paloaltonetworks.com/initial-access-broker-exploits-leaked-machine-keys/
• https://blog.blacklanternsecurity.com/p/aspnet-cryptography-for-pentesters
• https://github.com/ekkoo-z/Z-Godzilla_ekp
• https://x.com/AzakaSekai_/status/1969294757978652947

Nachtrag

HarfangLab veröffentlichte seinen Forschungsentwurf zu dieser Bedrohung am selben Tag, an dem dieser Beitrag veröffentlicht wurde. Darin enthalten sind weitere ergänzende Erkenntnisse:

• https://x.com/securechicken/status/1980715257791193420
• https://harfanglab.io/insidethelab/rudepanda-owns-iis-servers-like-2003/