Eine bösartige Erweiterung, die bereits aus Open VSX entfernt wurde, jedoch bis heute noch über den Erweiterungsmarkt von TRAE IDE heruntergeladen werden kann. Die Erweiterung gibt sich als gängiges Solidity-Sprachunterstützungs-Plugin aus; der Paketname lautet juannegro.solidity. Bis zum 18. Juli 2026 stellt die Plugin-Marktplatz-API von TRAE weiterhin die Version 0.0.189 dieser Erweiterung bereit (VSIX-Datei).

Die Reverse-Analyse zeigt, dass es sich bei der Erweiterung tatsächlich um einen plattformübergreifenden (Windows, macOS, Linux) bösartigen Dropper handelt. Er wird nach dem Start der IDE automatisch ausgeführt, erstellt einen Autostart-Eintrag auf Benutzerebene im System und bezieht anschließend über Ethereum-Smart-Contracts die Download-Adresse für den weiteren bösartigen Code oder verbindet sich direkt mit der Adresse eines Remote-Controlled Shell.

VSIX-Dateien sind nur für die erste Bereitstellung zuständig, während C2-(Command-and-Control)-Konfigurationsinformationen auf der Blockchain gespeichert sind und jederzeit geändert werden können. Der Angreifer muss die Erweiterung nicht erneut veröffentlichen; er muss nur die Parameter im Vertrag ändern, um alle infizierten Hosts auf neue Backend-Server zu verweisen.

1. Hintergrund

Der erste, der dieses Ereignis öffentlich gemacht hat, war der X-User @Will42W. Am 17. Juli 2026 warnte er in einem Beitrag die TRAE-IDE-Nutzer vor Risiken in der Erweiterungs-Lieferkette und erwähnte in seinem Tweet das Sicherheitsteam von @SlowMist. Er wies darauf hin, dass TRAE Erweiterungen, die auf Open VSX neu hochgeladen werden, schnell synchronisiert, aber die später folgenden Risiken durch Downlisting oder Blacklisting-Risikoerweiterungen auf Open VSX nicht synchronisiert.

Das Sicherheitsteam von SlowMist kommunizierte anschließend mit Will42W und bestätigte, dass das Problem in der Erweiterung juannegro.solidity erweitert wurde. Danach überprüften wir den TRAE-Markt und analysierten VSIX-Dateien, Ladedaten auf verschiedenen Plattformen, Persistenzmethoden sowie die Konfiguration des Vertrags auf Ethereum. Schließlich bestätigten wir, dass der Angreifer nach der Veröffentlichung dieser Erweiterung weiterhin dynamisch die Backend-Adresse über Blockchain-Transaktionen austauschte.

MistEye-Antwort

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

MistEye synchronisierte das Risiko umgehend über den Informations-Feed und den Kunden-Alarmkanal.

2. Bösartige Erweiterungsanalyse

2.1 Nachahmung einer legitimen Solidity-Erweiterung

Der Herausgeber dieser Erweiterung heißt juannegro und gibt die offizielle Solidity-Erweiterung vor, die von Juan Blanco entwickelt wurde. Es wird die Beschreibung, die Symbole und die Repository-Informationen direkt aus dem Original übernommen. Zwischen juannegro und dem legitimen Herausgeber juanblanco liegen nur ein paar Buchstaben, wodurch Nutzer leicht in die Irre geführt werden können.

Laut den Informationen, die Will bereitstellte, und den offiziellen Aufzeichnungen von Open VSX wurde die Erweiterung am 1. Mai 2026 veröffentlicht und wenige Stunden später entdeckt und downlistet. Die aktuelle Open-VSX-API-Abfrage liefert „Erweiterung nicht gefunden“, aber bis zum 18. Juli kann TRAE die Erweiterung juannegro.solidity@0.0.189 weiterhin suchen und herunterladen.

Bei zweimaliger erneuter Prüfung stellten wir fest, dass die von TRAE bereitgestellten herunterladbaren Versionen stets 0.0.189 sind, und auch der interne Versionstimestamp bei dem 1. Mai verbleibt. Die einzige Änderung ist das Feld „Letzte Aktualisierung“ auf der Seite mit den Erweiterungsinformationen; dies bedeutet jedoch nicht, dass der Angreifer neue Dateien hochgeladen hat, sondern nur eine Aktualisierung der Metadaten.

2.2 Bösartige Erweiterung aktiviert sich automatisch beim Start

In der package.json der Erweiterung werden zwei Aktivierungsereignisse deklariert:

onLanguage:solidity aktiviert die Erweiterung, wenn der Nutzer eine Solidity-Datei öffnet; noch gefährlicher ist jedoch onStartupFinished. Laut der VS-Code-Erweiterungs-API-Dokumentation wird dieses Ereignis automatisch ausgelöst, nachdem der Editor gestartet ist, ohne dass der Nutzer irgendeine Datei öffnen oder einen Befehl ausführen muss.

Solange die Erweiterung installiert und aktiviert ist, ruft die IDE bei jedem Start nach Abschluss oder bei einem Neustart des Erweiterungsprozesses automatisch die activate()-Funktion auf – selbst wenn niemals eine Solidity-Datei geöffnet wird – und der bösartige Code beginnt sofort zu laufen.

2.3 Hash-Obfuskierung zur Verbergung der Befehlsausführung

In out/extension.js verwendet der Entwickler nicht direkt child_process.exec. Stattdessen berechnet er zuerst SHA-256-Hashes für den Namen des im Node.js eingebauten Moduls und für den Funktionsnamen, und verwendet dann zwei feste Hashwerte, um rückwärts nachzuschlagen und dadurch die beiden Strings child_process und exec zu erhalten. Daher zeigt die Variable hash im Code tatsächlich auf child_process.exec.

Danach vergleicht der Code den Hash (tatsächlich die Funktion) mit einer festen Zeichenkette. Da das Funktionsobjekt niemals gleich der Zeichenkette ist, ist das Ergebnis des Vergleichs immer wahr. Dadurch wird die Prüfung umgangen und attempt_update(child_process.exec) ausgeführt. Die Funktion attempt_update nutzt das übergebene exec, um Systembefehle auszuführen und beginnt mit der Installation einer Persistenz-Backdoor.

2.4 Plattformübergreifende Persistenzspeicherung

Innerhalb von attempt_update prüft das Programm zuerst das Betriebssystem über os.platform() und ruft dann je nach Plattform exec auf, um bösartige Dateien zu schreiben, und setzt die entsprechenden Autostart-Einträge. Sobald die Persistenz abgeschlossen ist, ist die bösartige Nutzlast nicht mehr von dem IDE-Prozess abhängig; selbst das Deinstallieren der Erweiterung ermöglicht ein weiteres Laufen.

• macOS: Die Nutzlast wird nach ~/.solidity/ geschrieben, die Isolationsattribute werden gelöscht und anschließend wird ein LaunchAgent erstellt, damit sie beim Login des Benutzers startet.

• Linux: Die Nutzlast wird nach ~/.solidity/ geschrieben, als systemd-User-Service registriert und nach einem abnormalen Beenden neu gestartet.

• Windows: Der Updater wird nach C:\Users\Public\solidity\ geschrieben, von wo aus er app.js herunterlädt und ausführt; die zugehörigen Dateien werden verborgen, gleichzeitig wird der HKCU-Run-Schlüssel geschrieben und versucht, Defender-Ausnahmen hinzuzufügen.

Danach startet Windows aus C:\Users\Public\solidity\solidity-compiler.js, während macOS/Linux die nativen Dateien unter ~/.solidity/ ausführt. Der Persistenzmechanismus stellt sicher, dass die Nutzlast erneut gestartet werden kann; wohin die Verbindung nach jedem Start geht, wird jedoch durch denselben Ethereum-Vertrag bestimmt.

2.5 Nutzung eines Ethereum-Vertrags zur dynamischen Aktualisierung von C2

Windows und macOS/Linux lesen dieselbe On-Chain-Konfiguration, verwenden jedoch unterschiedliche Parameter.

Das auf Windows gelandete solidity-compiler.js wird von out/components/compiler.js generiert. Das Skript pollt mehrere öffentliche RPCs, liest param2() per eth_call aus und ruft dann curl.exe -k auf, um app.js herunterzuladen und auszuführen. -k deaktiviert die TLS-Zertifikatsprüfung, und das Skript überprüft weder digitale Signaturen noch feste Hashwerte. Wenn sich der Benutzer erneut einloggt, startet der HKCU-Run-Key dieses Skript und fragt die Download-Adresse erneut ab.

macOS/Linux verwenden Go-Ausführungsdateien unter extension/bin/, die nach System und CPU-Architektur unterschieden sind. Die im Sample erhaltenen Funktionssymbole umfassen antivm.Check, eth.ReadParam1WithFallback, hubclient.startShellLocked und runCommand. In Kombination mit der Aufrufbeziehung lässt sich bestätigen, dass die Nutzlast zunächst eine Prüfung der Laufzeitumgebung durchführt, param1() aus dem Vertrag liest, eine Remote-Shell aufbaut und nach einer Unterbrechung wieder verbindet.

Beide Arten von Nutzlasten sind fest in denselben Ethereum-Mainnet-Vertrag eingebettet:

0xf8a900db50b3331be6b768ba460bb59f3e40c344

Nach dem Reverse Engineering der Contract-Bytecodes lassen sich zwei zentrale Konfigurationen identifizieren: param1() (0x02d91518) speichert die Remote-Shell-Adresse für macOS/Linux, param2() (0x1f049b68) speichert die Download-Adresse für die Windows-Zweitstufe-Nutzlast. Die Funktions-Selectoren zum Aktualisieren dieser beiden Parameter sind 0xc832508f und 0xf56f9b48 und beide sind auf Owner-Berechtigungen beschränkt. Durch den Aufruf von owner() (0x8da5cb5b) erhält man die Steuergeldbörse 0xFd3fc58bcbd8ccc77b6000201438eDfc636E7cA7.

Zum Zeitpunkt der erneuten Überprüfung lautet die Konfiguration im Vertrag:

Infizierte Hosts müssen nur über den öffentlichen RPC eth_call ausführen: Windows liest param2(), um app.js herunterzuladen; macOS/Linux liest param1(), um eine Remote-Shell zu verbinden. Nachdem der Angreifer die Vertragsparameter geändert hat, erhalten alle nachfolgenden Abfragen der Nutzlasten neue Adressen, ohne dass eine erneute VSIX-Veröffentlichung erforderlich ist.

Nachdem die C2-Adresse in den Vertrag eingefügt wurde, muss in dem Erweiterungspaket lediglich noch die Vertragsadresse und die Abfragelogik verbleiben. Öffentliche RPCs können ersetzt werden; ein einzelner Knotenfehler trennt nicht das Auslesen der Konfiguration. Zudem hinterlässt jede Aktualisierung der Parameter eine On-Chain-Aufzeichnung. In diesem Artikel machen wir nur eine read-only-Abfrage des Vertrags, verbinden keine Remote-Shell und greifen nicht auf die zweite Stufe zu oder laden sie herunter. On-Chain werden diese Adressen weiterhin gespeichert; das bedeutet nicht, dass die zugehörigen Server aktuell erreichbar sind, und es kann nicht beweisen, dass es noch aktive Opfer gibt.

2.6 On-Chain-C2-Aktualisierungsprotokoll

Über Blockscout lässt sich der Transaktionsverlauf des Vertrags einsehen, um den Prozess der Parameteränderung nachzuvollziehen. Wir haben Transaktionen herausgefiltert, mit denen die Steuergeldbörse den Vertrag anspricht, und unterscheiden dann param1 und param2 anhand der Funktions-Selectoren. In den UTF-8-Teilen der Transaktionseingabedaten sieht man die geschriebenen Inhalte direkt.

Der Vertrag wurde am 14. März 2026 um 13:03 UTC bereitgestellt. Nach 20 Minuten initiiert die Steuergeldbörse eine Transaktion (0x972f...), ruft 0xc832508f auf, setzt param1 auf http://localhost:4912 und ändert es anschließend mehrfach auf andere öffentliche IPs. Das zeigt, dass der Angreifer die Kontrollmechanismen auf dieser Kette bereits getestet hatte, bevor die bösartige Erweiterung in den Markt hochgeladen wurde.

Die Erweiterung wurde am 1. Mai im Markt eingestellt. Zwei Tage später (am 3. Mai um 16:55 UTC) änderte die Steuergeldbörse param1 über eine weitere Transaktion (0xadea...) auf 107[.]189[.]27[.]46:4912.

Am 16. Mai um 12:08 UTC ändert dieselbe Geldbörse über eine Transaktion (0x8e5d...) param2 auf hxxp://107[.]189[.]27[.]46:3000/app.js.

Beide Transaktionen erfolgten nach der Veröffentlichung der VSIX, was zeigt, dass der Angreifer keinen Update-Mechanismus über den Erweiterungsmarkt durchlaufen musste, um die Remote-Shell und die Download-Adresse der zweiten Stufe zu ändern. Da die Aktualisierung auf der Kette erfolgt, ändern sich die in TRAE angezeigten Erweiterungsversionen und Aktualisierungszeiten nicht entsprechend.

2.7 Downlisting einer Erweiterung kann die Infektion nicht beseitigen

TRAE synchronisiert nicht das Open-VSX-Deinstallations-/Downlisting-Ergebnis, wodurch bereits vom Upstream gelöschte VSIX-Dateien weiterhin verteilt werden. Selbst wenn es jetzt dringend downlistet wird, kann dies nur neue Installationen verhindern, nicht aber bereits in das System geschriebene bösartige Nutzlasten bereinigen.

Da die Erweiterung beim ersten Lauf bereits Autostart-Einträge im System erstellt (LaunchAgent auf macOS, systemd-Dienste auf Linux, Registry-Einträge auf Windows) und möglicherweise bereits den zweiten Stufe bösartigen Code heruntergeladen hat, werden diese Reste nicht automatisch gelöscht, wenn die Erweiterung downlistet wird oder der Nutzer sie deinstalliert. Die On-Chain-C2-Konfiguration ist unabhängig von der Erweiterung selbst und bleibt weiterhin wirksam.

Daher muss die Plattform zusätzlich zum Downlisting und dem Stoppen der Bereitstellung von VSIX auch die bereits installierten Nutzer informieren, Erkennungs- und Bereinigungsmaßnahmen bereitstellen und auf der Client-Seite durch Blockierung basierend auf Erweiterungs-ID, Dateihashes und den jeweiligen On- bzw. Landing-IOCs vorgehen.

2.8 Ermittlung und Maßnahmen bei Infektionen

Falls juannegro.solidity bereits installiert wurde, reicht es nicht aus, nur aus der IDE-Erweiterungsliste zu deinstallieren. Es wird empfohlen, zuerst die Netzwerkverbindung zu trennen, verdächtige Dateien für die anschließende forensische Untersuchung zu sichern und dann die folgenden Stellen zu überprüfen:

• macOS: Überprüfen Sie das Verzeichnis ~/solidity/ sowie die Datei ~/Library/LaunchAgents/com.solidity.langsupport.runner.plist.

• Linux: Überprüfen Sie das Verzeichnis ~/solidity/ sowie die Datei ~/.config/systemd/user/solidity-langsupport-runner.service.

• Windows: Überprüfen Sie das Verzeichnis C:\Users\Public\solidity\ sowie verdächtige Autostart-Einträge, die auf solidity-compiler.js zeigen, in der Registry unter HKCU\Software\Microsoft\Windows\CurrentVersion\Run; prüfen Sie außerdem HKCU\Software\Microsoft\Windows\CurrentVersion\EVJ (falls vorhanden).

Zusätzlich sollte überprüft werden, ob auf dem Host Protokolle für Netzwerkverbindungen zu öffentlichen Ethereum-RPC-Knoten sowie zu den folgenden IPs und Ports vorhanden sind: 107[.]189[.]27[.]46:4912 und 107[.]189[.]27[.]46:3000.

Die bösartige Erweiterung hat die Fähigkeit, beliebige Befehle auszuführen und eine Remote-Shell aufzubauen. Daher kann man auch nach dem Löschen der oben genannten Dateien und Registry-Einträge nicht davon ausgehen, dass das System sicher ist. Wenn dieses Gerät jemals Codesignatur-Schlüssel, SSH-Private Keys, Cloud-Service-Zugangsangaben, Kryptowallet-Mnemonics oder Tokens für Produktionsumgebungen gespeichert hat, gehen Sie bitte nach dem Ablauf bei Host-Kompromittierung vor:

• Die betroffene Anlage sofort isolieren;

• Installieren Sie das System neu oder bauen Sie die Umgebung von einem vertrauenswürdigen Installationsmedium aus neu auf;

• Widerrufen Sie auf einem anderen sicheren Gerät alle alten Sitzungen und Zugriffstokens und ersetzen Sie alle möglicherweise kompromittierten Zugangsdaten.

2.9 Bedrohungsindikatoren (IOCs)

Erweiterung und Dateihashes

Extension: juannegro.solidity@0.0.189
VSIX SHA-256: ff943371750ecd2ce6caa50c12d673e82743bdbc9569552eebfa98ccb2f4ac69

darwin_amd64: 80d2672e2599732d3c0ae2a4cd0d1e3fe4d555a60273ce33feb99db3f34d250f
darwin_arm64: fae61f31f00988fdc5cc9e7272b51e08af2e245d81003237875415930fd27358
linux_amd64: 9b73e7cd4e1425e770392549d8df46c706139ef476f4f7b9ac405165dc8d9696
linux_arm64: b601776817363b96295119f7221338a122d5247a35a77a64b04f286e1bbcc565

On-Chain- und Netzwerkmetriken

Vertrag: 0xf8a900db50b3331be6b768ba460bb59f3e40c344
Owner: 0xFd3fc58bcbd8ccc77b6000201438eDfc636E7cA7

107[.]189[.]27[.]46:4912
hxxp://107[.]189[.]27[.]46:3000/app.js
91[.]108[.]240[.]156:4912
hxxp://91[.]108[.]240[.]156:3000/app.js
107[.]189[.]16[.]215:4912

Da die Vertragsparameter fortlaufend aktualisiert werden, darf man bei der Erkennung nicht nur auf die aktuelle IP setzen. Es muss auch die Vertragsadresse, die Funktions-Selectoren, der Pfad zur Freigabe der bösartigen Dateien, der Name der Autostart-Einträge sowie der Hash des Samples abgedeckt werden.

3. Zusammenfassung

Die eigentliche Gefahr von juannegro.solidity liegt nicht nur darin, dass TRAE die Downlisting-Informationen nicht synchronisiert. Es nutzt den Erweiterungsmarkt als ersten Bereitstellungskanal, baut dauerhafte Hintertüren auf Windows, macOS und Linux auf und bezieht über den Ethereum-Vertrag dynamisch veränderbare C2-Konfigurationen. On-Chain-Transaktionen am 3. Mai und 16. Mai belegen, dass der Angreifer nach der Veröffentlichung von VSIX weiterhin die Adressen für die Remote-Shell und die zweite Stufe der Nutzlast aktualisierte.

Die Erweiterungsmarkt-Plattform kann nicht nur Upload-Informationen synchronisieren; sie muss außerdem Risiko-Bewertungen und Downlisting-Status synchronisieren und bereits installierte Nutzer umgehend benachrichtigen. Andernfalls ist die auf Open VSX bereits abgeschlossene Behandlung auf TRAE faktisch wirkungslos, und die bereits in das System gepflanzten Hintertüren verschwinden nicht durch das Downlisting des Marktes – sie können weiterhin unter Umgehung des Marktes laufen.

Über MistEye

MistEye ist eine von SlowMist eigenständig entwickelte Web3-Threat-Intelligence- und dynamische Sicherheitsüberwachungsplattform. Über eine API bietet sie eine quelloffene Paket-Ökosystem-Erkennung bösartiger Aktivitäten sowie Fähigkeiten zur Vorwarnung von Lieferkettenrisiken.

Alle bösartigen Pakete und IOCs, die in dieser Aktion betroffen sind, wurden in die MistEye-Threat-Detection-Engine integriert. Entwickler können über die API eine automatisierte Prüfung der Projektabhängigkeiten durchführen, um schnell festzustellen, ob bekannte bösartige Pakete getroffen werden, und Empfehlungen zur Behandlung zu erhalten.

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

🛠️ MistEye-DepScan: https://github.com/slowmist/MistEye-DepScan – leichtgewichtiges CLI-Tool, mit dem man in einem einzigen Befehl Projektabhängigkeiten und in global installierten Paketen bekannte bösartige Pakete scannt; unterstützt npm / PyPI / Cargo / Go / RubyGems-Ökosystem

🛠️ MistEye-Skills: https://github.com/slowmist/misteye-skills – KI-Codierungsassistent-Sicherheits-Fähigkeitenpaket, das MistEye-Sicherheitsprüfungen automatisch auslöst, bevor Abhängigkeiten installiert und URLs aufgerufen werden