EtherRAT-Kampagne nutzt SEO-Vergiftung und GitHub-Fassaden, um Unternehmensadministratoren anzugreifen

Markt und Strategie

Eine erfolgreiche Infektion auf dem Arbeitsplatz eines Administrators kann Bedrohungsakteuren die Schlüssel zu einem gesamten Unternehmensumfeld an die Hand geben. Das psychologische Element dieser Kampagne ist besonders aggressiv.

Viele der nachgeahmten Tools sind dieselben, die Sicherheitsexperten zur Untersuchung und Reaktion auf bösartige Aktivitäten verwenden.

Dies schafft eine ironische Situation, in der ein Verteidiger, der versucht, ein vermeintliches Problem mit einem Tool wie Process Explorer oder TCPView zu diagnostizieren, unwissentlich genau die Bedrohung einführt, die er zu finden versucht.

Moegliche Anwendungen

Zweistufige GitHub-Lieferkette Die Kampagne nutzt eine sorgfältig getrennte, zweistufige Lieferarchitektur, die darauf ausgelegt ist, auch dann aktiv zu bleiben, wenn Teile davon abgeschaltet werden. Das erste GitHub-Repository dient lediglich als ansehnliche Fassade.

Es ist SEO-optimiert und enthält eine professionelle README-Datei ohne bösartigen Code, wodurch anfänglich Vertrauen sowohl bei Benutzern als auch bei Sicherheitstools aufgebaut wird. Eingebettet in diese README befindet sich ein Link, der auf ein zweites, verstecktes GitHub-Konto verweist.

Dieses sekundäre Repository beherbergt die eigentliche bösartige MSI-Payload. Durch die Trennung der SEO-sichtbaren Storefront vom Payload-Lieferkonto können die Bedrohungsakteure ihre Verteilungs-Repositories schnell rotieren, falls diese markiert werden, während die primäre, über Suchmaschinen indexierte Fassade aktiv und unberührt bleibt.

Zwischen Anfang Dezember 2024 und April

Zwischen Anfang Dezember 2024 und April 2026 setzten die Bedrohungsakteure 17 separate GitHub-Fassaden ein, die jeweils ein anderes Verwaltungs- oder Entwicklertools nachahmten, was auf einen anhaltenden Versuch hindeutet, die Suchmaschinen-Sichtbarkeit zu maximieren und eine vielfältige Reihe.

Malware vom Benutzer heruntergeladen (Quelle – Atos) Wenn ein Opfer die MSI herunterlädt und ausführt, werden vier Dateien extrahiert und ein CMD-Batch-Skript wird über eine benutzerdefinierte Aktion mit SYSTEM-Rechten unmittelbar nach der Dateiexraktion gestartet.

Der Einstiegspunkt ist ein stark verschleierter Windows-Batch-Skript, das unmittelbar nach der Dateiexraktion gestartet wird.

Sein primärer Verschleierungmechanismus teilt alle sensiblen

Sein primärer Verschleierungmechanismus teilt alle sensiblen Befehlsnamen, einschließlich curl, tar, copy, start und cmd, über mehrere SET-Variablenzuweisungen auf, die zur Laufzeit stillschweigend konkateniert werden, wodurch sichergestellt wird, dass keine erkennbaren Schlüsselwörter in der Rohdatei erscheinen und einfache stringbasierte statische Analysen umgangen werden.

Stufe 2 ist ein minimales Node.js-Skript, das nicht verschleiert und vollständig lesbar ist und niemals auf die Festplatte gespeichert wird.

Stufe-2-Code (Quelle – Atos) Sein Hauptziel ist es, eine Datei zu lesen, die eine verschlüsselte Nutzlast der zweiten Stufe enthält, diese mit einem hartkodierten Schlüssel und einem Initialisierungsvektor (IV) zu entschlüsseln und sie im Speicher auszuführen. Es erstellt auch Persistenz über einen Registry Run-Schlüssel.

Sicherheitslage und Risiko

Stage 3 RAT (Quelle – Atos) Stage 3 ist die Hauptlast des Malware, eine JavaScript-Datei, die bei jedem Systemstart im Hintergrund in conhost.exe läuft, einem legitimen Windows-Prozess, sodass sie im Task-Manager nicht auffällt.

Blockieren Sie den Zugriff auf die öffentlichen Ethereum (ETH) RPC-Endpunkte, die, und die im Abschnitt „Appendices“ des Atos TRC GitHub-Repository aufgeführt sind.

Überprüfen Sie historische Netzwerkprotokolle, um jegliche ausgehenden Kommunikationen mit den aufgeführten RPC ETH-Endpunkten und identifizierten historischen C2-Domains zu ermitteln.

Technik und Auswirkungen

Erhöhen Sie das Bewusstsein des IT-Personals hinsichtlich der Risiken, kritische Utilities aus Suchmaschinenergebnissen zu beziehen; verlangen Sie die Nutzung verifizierter interner Softwarezentren oder direkter, authentifizierter Anbieterportale für alle Verwaltungswerkzeuge.

Suchen Sie nach Verhaltensmustern in der Telemetrie: wiederholte, hochfrequente Beacons (alle ~500ms) an verdächtige externe Domains, periodische ausgehende Anfragen (alle ~ ) an öffentliche ETH RPC Endpunkte und verdächtige Prozessbäume, bei denen node.exe Prozesse Shell-Befehle ausführen.

Behandeln Sie jede Nutzung headless als einen potenziellen Indikator für die sekundären Stufen der EtherRAT-Payload. Sie uns auf

Der Beitrag EtherRAT Campaign Uses SEO Poisoning and GitHub Facades to Target Enterprise Admins erschien zuerst bei