Hintergrund

Solidity Pro ist eine VS-Code-Erweiterung für Solidity/Web3-Entwickler. Sie positioniert sich nach außen als Entwicklungshilfe und bietet Funktionen wie Gas-Abfragen, Token-Preise, Code-Snippets und Compiler-Hinweise. Ihr GitHub-Repository hat zudem zeitweise Sicherheitsfunktionen wie „AI Audit“ und „Security Scanner“ beworben.

In öffentlichen Aktivitäten hat Solidity Pro nacheinander die beiden Publisher helper-beeps und web3devtoolsx eingesetzt (Publisher-Identität). Die zugehörigen Extension-IDs (eindeutige Kennungen der Erweiterungen) lauteten jeweils helper-beeps.solidity-pro und web3devtoolsx.solidity-pro. Obwohl sich die Veröffentlichungsidentität geändert hat, wurden in den späteren Build-Artefakten weiterhin der alte Publisher, die Repository-Adresse und die Copyright-Informationen beibehalten, was darauf hindeutet, dass zwischen beiden eine direkte technische Vererbung besteht.

Vom 6. bis 7. August 2026 wurden diese beiden Extension-IDs nacheinander in die bösartige Erweiterungskontrollliste aufgenommen, die für Open VSX verwendet wird. Theoretisch sollte man bei einer rückwärts gerichteten Prüfung entlang der Versionen weiterhin die entsprechenden bösartigen Fähigkeiten sehen. Aber das, was wir bei Solidity Pro 4.0.0 (publisher: web3devtoolsx) erhalten haben, zeigt ein völlig anderes Ergebnis: Im finalen Bundle (verpackter Ausführungscode) bleiben nur normale Funktionen wie Gas, Token-Preise und Logs übrig. Module, die in historischen bösartigen Versionen vorkamen – Credential-Erfassung, Remote-Load-Downloads, Subprozess-Ausführung und Remote-VSIX-Updates – sind alle verschwunden.

Damit stellt sich die Frage: Warum wird ein Plugin, das bereits eine klar bösartige Historie hat, in späteren Versionen wieder „sauber“?

Dieser Artikel verfolgt von 4.0.0 aus rückwärts die Versions- und Veröffentlichungsidentitätsänderungen von Solidity Pro, analysiert zwei historische bösartige Versionen, den GitHub-Clean-commit, die Migration des Publishers und die Zeitleiste öffentlicher Aktivitäten und diskutiert die Erkennungsblindstellen, die entstehen können, wenn man nur anhand der aktuellen Version das Risiko von IDE-Erweiterungen beurteilt.

Die Analyse in diesem Artikel basiert auf statischen Belegen. Es wurden keine Samples ausgeführt und keine Verbindung zu entfernten Infrastrukturen hergestellt.

MistEye-Antwort

MistEye ist eine Web3-Threat-Intelligence- und dynamische Sicherheitsüberwachungsplattform, die von SlowMist eigenständig entwickelt wurde. Sie integriert Fähigkeiten zur Sicherheitsüberwachung und zur Bündelung von Threat-Intelligence und bietet Nutzern Echtzeit-Risikovorsorge sowie Schutz für Assets.

MistEye hat eine Zuordnung für die beiden Veröffentlichungsidentitäten helper-beeps.solidity-pro und web3devtoolsx.solidity-pro sowie die jeweiligen Samples durchgeführt. In Kombination mit statischer Entobfuskation, einer Kreuzprüfung bösartiger Fähigkeiten und der Zeitleiste öffentlicher Plattformen wurden Sample-Hashes, Extension-IDs, gefährliche Request-Pfade und Remote-Update-Verhalten extrahiert, um eine Warnung bezüglich Lieferkettenrisiken für IDE-Erweiterungen bereitzustellen.

I. Aktuelle Version

Um zu beurteilen, warum 4.0.0 keine bösartigen Codes trifft, müssen zwei Dinge gleichzeitig überprüft werden: das hier erhaltene 4.0.0-Sample sowie der GitHub-Repository-Status, der mit seinem Bundle übereinstimmt.

Was ist im VSIX-Paket enthalten. Das lokal rekonstruierte 4.0.0-Bundle enthält im Wesentlichen ApiClient, GasTracker, PriceMonitor und Logger; der Netzwerkzugriff konzentriert sich auf Etherscan und CoinGecko. Nach Aktivierung über onStartupFinished oder in einem Workspace, der Solidity-Dateien enthält, werden nur der Gas-tracker, Price monitor und logger gestartet und drei öffentliche Befehle registriert; der compile-Befehl zeigt nur einen einzigen Hardhat/Foundry-Hinweis an, ruft aber keinen Compiler tatsächlich auf. In den überprüften Dateien und statisch erreichbaren Pfaden wurden keine vier bösartigen Fähigkeiten gefunden, die es in historischen Versionen gab: Credential-Erfassung, Remote-Load-Downloads, Subprozess-Ausführung und Remote-VSIX-Updates.

Was ist noch im GitHub-Repository enthalten? Das 4.0.0-Paket selbst enthält keinen Quellcode. Daher gehen wir weiter auf GitHub zurück bis zu dem öffentlich verfügbaren Engineering. In dem Repository gibt es einen package.json-Versions-Rollback zu v1.0.0, einen commit 95dce4f und eine Commit-Nachricht „Clean release“. Das out/extension.js und das 4.0.0-Bundle haben beide 10.633 Bytes und stimmen bei SHA-256 überein.

Das out/extension.js dieser Commit enthält ebenfalls nur ApiClient, GasTracker, PriceMonitor und Logger. Aktivierungs- und Deaktivierungsfunktionen dienen nur der Initialisierung und Bereinigung. Aber der src/-Ordner in demselben Commit zeigt ein anderes Bild: src/telemetry/Web3Analytics.ts ist weiterhin vorhanden; die Dateikopfzeile lautet „Sends install ping immediately, then scans for secrets“. Intern enthält sie eine BIP39-Wortliste, Erkennung von Wallet-Zugriffsdaten, eine WORKERS-Weiterleitungs-Konfiguration und ein Limit für die großangelegte Dateisuche; src/services/AutoUpdater.ts bleibt ebenfalls erhalten und definiert eine Versionierungsprüfung im 30-Minuten-Zyklus sowie die Remote-VSIX-Installationslogik.

GitHub-Repository (Clean commit 95dce4f)
├── src/telemetry/Web3Analytics.ts # Bösartiger Erfassungs-Engine-Quellcode ist noch vorhanden
├── src/services/AutoUpdater.ts # Quellcode für Remote-VSIX-Updates ist noch vorhanden
├── .vscodeignore # schließt src/**, scripts/** und *.ts aus
└── out/extension.js # beim Bundlen sichtbares sauberes Bundle

Warum ist der bösartige Quellcode nicht in das VSIX-Paket gelangt? Dafür gibt es zwei Grenzen.

Der erste Punkt ist der Ausführungseinstieg: Im Clean commit löscht src/extension.ts die Imports und die Startlogik für Web3Analytics und AutoUpdater. Wenn esbauild aus diesem Einstiegspunkt das Abhängigkeitsdiagramm erstellt, werden diese beiden Module nicht mehr in out/extension.js eingebunden.

Der zweite Punkt ist die Sichtbarkeit im Paket: .vscodeignore schließt src/**, scripts/** und *.ts aus, behält aber out/** bei. Daher bleiben auch Rest-TypeScript-Quelltexte nicht im ursprünglichen Quellcode-Format in das per dieser Konfiguration generierte VSIX. Die Commit-Nachricht für v1.0.0 lautet „Clean release“, aber die Quellcodedateien des bösartigen Moduls wurden in diesem Commit weder gelöscht noch geändert – am Ende ist das ausgelieferte Artefakt sauber; innerhalb des Projekts kann der bösartige Modul jedoch in späteren Änderungen von Quellcode oder Build-Konfiguration erneut eingebunden werden.

II. Historisch bösartige Versionen

Da weder im aktuellen Bundle noch im Bundle des Clean commits das ursprüngliche bösartige Modul gefunden wurde, muss die Untersuchung fortgesetzt werden und die historischen Versionen von Solidity Pro unter den beiden Veröffentlichungsidentitäten nachverfolgen.

Solidity Pro verwendet nicht durchgehend dieselbe bösartige Implementierung. In der von helper-beeps veröffentlichten Identität erhaltene 2.4.1 und die unter der von web3devtoolsx veröffentlichten Identität erhaltene 3.4.0 zeigen zwei deutlich unterschiedliche Ausführungsweisen: Erstere setzt auf verzögertes Downloaden und Remote-Code-Ausführung, während letztere auf eingebautes Sammeln von Zugangsdaten und einen Remote-Update-Kanal setzt.

2.4.1: Verzögerte Zustellung

In den in diesem Artikel gewonnenen Solidity-Pro-2.4.1-Samples (publisher: helper-beeps) wird die Erweiterung in Solidity-Dateien oder in Hardhat/Foundry-Workspaces aktiviert; telemetry ist standardmäßig aktiviert. Nach der Aktivierung gelangt der Code nicht sofort in die Download-Phase, sondern setzt ein zufälliges Wartefenster von 24 bis 48 Stunden:

MIN_DELAY_MS: 86400000,
MAX_DELAY_MS: 172800000

Nach Ablauf der Wartezeit prüft der Code auf Existenz von Umgebungsvariablen wie CI, GITHUB_ACTIONS, JENKINS_HOME, GITPOD_WORKSPACE_ID usw.; bei Treffer wird sofort beendet. Anschließend werden sechs codierte Hauptverzeichnis-relative Pfade nacheinander mit fs.existsSync gefiltert; diese Pfade werden in dieser Phase nur zur Existenzprüfung verwendet.

Nach dem Filtern versucht der Code nacheinander zwei kodierte Endpunkte und fordert auf jedem Endpunkt einen festen Pfad /firmware an. Nach Erhalt der Antwort wird die Länge validiert; anschließend wird mit crypto.createDecipheriv und AES-GCM entschlüsselt. Der entschlüsselte Text wird mit eingeschränkten Berechtigungen in eine .py-Datei im temporären Verzeichnis geschrieben und dann per child_process.spawn im detached-Modus ausgeführt. Nach etwa 60 Sekunden bereinigt unlinkSync die temporären Dateien. Wenn /firmware keine echte Antwort liefert, ist die konkrete Funktion der zweiten Phase unbekannt.

3.4.0: Erfassung von Zugangsdaten

Solidity Pro 3.4.0 (publisher: web3devtoolsx) deklariert in der activationEvents der package.json sowohl workspaceContains:*.sol als auch onStartupFinished. Die Erweiterung kann nach Abschluss des VS-Code-Startvorgangs automatisch in activate() übergehen und verlangt nicht, dass der Nutzer seine öffentlichen Befehle ausführt.

Standardkonfiguration solidity-pro.telemetry.enabled=true erstellt und startet Web3Analytics. README behauptet, es würden nur anonyme Nutzungsdaten gesammelt und keine privaten keys oder Quellcodes gespeichert. Das Modul scannt jedoch tatsächlich Objekte, die die Kernwerte des Entwickler-Vertrauensbereichs abdecken:

• Wallet- und Signatur-Materialien: EVM-Private-Keys, BIP39-Mnemonics, Keystores, Solana id.json, Daten von Browser-Wallet-Erweiterungen (MetaMask, Phantom, Coinbase Wallet, Rabby).

• Quellcode und Veröffentlichungsnachweise: GitHub ghp_/gho_/github_pat_-Token, GitLab glpat-, .npmrc, PyPI-Token, .netrc, Git-Zugriffsdaten.

• Cloud und Infrastruktur: AWS access/secret/session key, Kubernetes-Konfiguration, Docker-Zertifikate, Azure, GCP-Konfiguration.

• Projekt- und Interaktionsspuren: .env und Varianten, API key, AI-Service-Token (sk-, sk-proj-, sk-ant-), Shell-Historie und Host-Informationen.

Der Regex für EVM-Private-Keys deckt gängige Variablennamen wie privateKey, PRIVATE_KEY, WALLET_KEY, DEPLOYER_KEY sowie 64-Bit-hexadezimale Werte ab:

var _0x4e0bcc = [
  /["']privateKey["']\s*:\s*["'](?:0x)?([0-9a-fA-F]{64})["']/g,
  /(?:PRIVATE_KEY|PRIVATEKEY|ETH_KEY|ETHKEY|WALLET_KEY|WALLETKEY|DEPLOYER_KEY|OWNER_KEY)\s*=\s*["']?(?:0x)?([0-9a-fA-F]{64})["']?/gi,
  /(?:privateKey|private_key|ethKey|eth_key|walletKey|wallet_key)\s*[:=]\s*["'](?:0x)?([0-9a-fA-F]{64})["']/gi,
  /(?:priv(?:ate)?[ _-]?key|secret)[:=]\s*["']?(0x[0-9a-fA-F]{64})["']?/gi
];

Die Logik zum Sammeln von SSH-Verzeichnissen enumeriert Kandidaten-Private-Key-Dateien in ~/.ssh/, liest deren Inhalte ein und übergibt sie an den extractSecrets-Extractor. Die Ergebnisse des Sammelns werden über zwei HTTP-Request-Pfade nach außen gesendet: Text-JSON wird per HTTPS an den obfuskierten CFG.WORKERS-Host POST /x gesendet, und der vollständige Bericht wird als multipart/form-data an denselben Satz von Hosts POST /y gesendet.

Parallel zu dieser Erfassungs-Kette läuft auch AutoUpdater. Er wird in activate() bedingungslos erstellt und gestartet und hängt nicht von telemetry-Konfigurationen ab. Nach dem Start wird sofort einmal /version angefragt; anschließend werden alle 30 Minuten zwei fest codierte Worker abgefragt. Solange in der Antwort version und url enthalten sind, vergleicht der Code Versionsnummern, lädt das VSIX herunter, ruft den VS-Code-Installationsbefehl auf und löscht anschließend temporäre Dateien.

Die gesamte Update-Kette beinhaltet keinerlei Integritätsprüfung – der Updater selbst implementiert keine Hashes, Signaturen, Publisher-Fixierung oder Zertifikatsfixierung. Das bedeutet: Der Server kann bei jeder beliebigen Polling-Anfrage eine höhere Version und Download-Adresse zurückgeben und selbst entscheiden, wann das Update ausgelöst wird und welches VSIX ausgeliefert wird. Noch kritischer ist: Vor dem Update erscheint nur eine Benachrichtigung mit einer einzigen „OK“-Schaltfläche; nach Ende des Benachrichtigungsflusses wird weiter installiert, ohne dass es eine echte Abbruchoption gibt oder das Ergebnis der Nutzerentscheidung eingelesen wird.

Warum sind diese Sammelziele gefährlich? Weil der IDE Extension Host selbst innerhalb des Vertrauensbereichs von Entwicklern läuft. Entwickler-Arbeitsplätze für Web3 speichern häufig gleichzeitig Wallet-Materialien, Quellcode-Repository-Berechtigungen, Paket-Publishing-Tokens, CI/CD und Cloud-Plattform-Konfigurationen. Ein einziger Supply-Chain-Angriff über eine Erweiterung kann damit mehrere Sicherheitsgrenzen gleichzeitig überschreiten.

Abgleich der Rollen von vier Arten von Samples oder Versionen:

III. Migration des Publishers

Solidity Pro 2.4.1 und 3.4.0 gehören nicht zu derselben Extension ID. Erstere wurde von helper-beeps veröffentlicht, letztere nutzt einen neuen Publisher web3devtoolsx. Warum kann man sie dennoch in derselben Untersuchungslinie führen?

Die interne Metadaten des initialen v3.4.0 Commits fe794a2 beantworten die Frage direkt. package.json deklariert publisher: web3devtoolsx, Version 3.4.0, und repository zeigt auf github.com/web3devtoolsx/solidity-pro. In dem out/package.json desselben Commits wird jedoch publisher: helper-beeps, Version 3.3.0 beibehalten, repository zeigt auf github.com/helper-beeps/solidity-pro. Die LICENSE-Datei steht weiterhin mit „Copyright (c) 2026 Helper Beeps“.

Zwei package.json stammen aus demselben Commit und belegen, dass die initialen Build-Artefakte von Solidity Pro unter der Identität web3devtoolsx direkt aus dem helper-beeps-Engineering stammen; es besteht eine direkte Quellenverknüpfung zwischen Code bzw. Build-Artefakten.

Nachdem man die Vererbungsbeziehungen der Build-Artefakte mit der offiziellen bösartigen Markierung-Zeitleiste überlagert hat, wird das Muster des Publisher-Wechsels noch klarer:

helper-beeps.solidity-pro wurde zur offiziellen malicious-Liste hinzugefügt (2026-08-06 14:27:24 UTC)
    │ 8 Stunden 32 Minuten 48 Sekunden
    ▼
web3devtoolsx GitHub-Kontoerstellung (2026-08-06 23:00:12 UTC)
    │ ca. 16 Minuten
    ▼
Neue Solidity-Pro v3.4.0 taucht auf
    │ am nächsten Tag
    ▼
web3devtoolsx.solidity-pro wurde ebenfalls zur offiziellen malicious-Liste hinzugefügt (2026-08-07 12:38:52 UTC)

IV. Clean release

Der GitHub-Initial-Commit sendet nach dem Einreichen des bösartigen v3.4.0-Bundles nur 13 Minuten und 29 Sekunden später ein Rollback: In demselben Repository wurde ein „Clean commit“ mit Version v1.0.0 eingereicht. In diesem extrem kurzen Zeitfenster initiierte der Publisher außerdem kurzzeitig und schloss selbst den Open-VSX-Namespace-Claim (Issue ohne Kommentare, geschlossen von web3devtoolsx selbst).

Die Änderungen im Clean commit konzentrieren sich exakt auf zwei Zielgruppen. Auf der Ausführungsebene werden Web3Analytics-Aktivierung, AutoUpdater-Start, telemetry-Konfiguration, javascript-obfuscator-Abhängigkeiten und der Obfuskations-Build-Schritt entfernt. Auf der Produktoberfläche werden der AI Audit Engine, der Security Scanner, das 100K+-Badge und aufgeblasene Capability-Textinhalte entfernt. Die Versionsnummer wird von 3.4.0 auf 1.0.0 zurückgesetzt.

Diese Änderungen treten gebündelt in demselben Commit auf, der „Clean release“ heißt. Er entfernt direkt öffentlich erreichbare Hochrisiko-Einstiege und einen Teil der auffälligen Marketing-Texte, sodass Systeme, die nur das neue Bundle prüfen, die ursprünglichen bösartigen Module nicht mehr treffen. Die Bereinigung ist nicht vollständig: In der package.json-description werden „Trusted by 100K+“ und „vulnerability scanner“ nicht entfernt – die auffälligste Badge wurde gelöscht. Falls dieses Manifest tatsächlich gebündelt und veröffentlicht wird, könnten die Metadaten, die die Suchergebnisse und die Store-Seite beeinflussen, noch vorhanden sein. Wie zuvor beschrieben bleiben die bösartigen Quellmodule jedoch vollständig im src/-Verzeichnis erhalten, nur werden sie durch .vscodeignore nicht in das finale Paket aufgenommen.

„Clean release“ verändert das finale Auslieferungsartefakt, nicht die Geschichte, die dieses Engineering bereits durchlaufen hat.

V. Vertrauenswürdige Verpackung

Fast gleichzeitig mit den Versionsänderungen kam noch eine schnelle Verpackung einer neuen Veröffentlichungsidentität hinzu: Rund 16 Minuten nach der Erstellung des web3devtoolsx-Kontos traten Unternehmensstil-Materialien, sechs bekannte Projekt-Forks, ein Produkt-Repository, reife Versionsnummern und 100K+-Claims gebündelt auf. Weil diese Signale gebündelt auftauchen, vermittelt das neue Konto objektiv den Eindruck einer relativ reifen Organisationsdarstellung.

Unternehmensstil-Materialien. Etwa 15 Minuten nach der Kontoerstellung enthält das Profile bereits den Namen „Web3 Dev Tools“, das Feld für das Unternehmen, den Standort Zug, die Website, einen Twitter-Link, ein veröffentlichtes Produkt und eine Roadmap mit zwei „Coming Q3“-Produkten. Bei einer erneuten Prüfung bis zum 12. August 2026 bleiben Kennzahlen für langfristige Aktivität wie followers, following, gists usw. weiterhin bei 0.

Sechs bekannte Projekt-Forks. Das Konto hat OpenZeppelin Contracts, Foundry, Hardhat, Chainlink, Uniswap v3-core und ethers.js innerhalb von 13 Sekunden fortlaufend geforkt. Normale Besucher sehen auf der Startseite bekannte Web3-Projektnamen, aber Forks bedeuten nur, dass man das Upstream-Repository kopiert hat; sie stehen nicht automatisch für Beitrag, Zusammenarbeit oder jede Form von Billigung.

Versionskennzeichen und Erstellungszeit stimmen nicht überein. Der erste Commit, der 8 Sekunden nach Erstellung des Repositories erfolgte, trägt gleichzeitig fünf Versionstags: v2.4.1, v2.4.5, v3.2.3, v3.3.0 und v3.4.0. Am Kopf des Quelltexts wird außerdem behauptet, dass es 2025 erstmals veröffentlicht wurde. Diese Versionen und die Alterskennzeichen passen offensichtlich nicht zu dem Konto bzw. dem öffentlichen Verlauf, der am selben Tag erstellt wurde.

Wiederholte Verstärkung sozialer Bewährtheit. „100K+“ taucht gleichzeitig in repository description, package.json, out/package.json, README-Badge, README-Text und im Build-Output auf – eine Nutzergrößen-Aussage, die in öffentlich verfügbaren Projektmaterialien wiederholt betont wird. Die vorhandenen Materialien erlauben jedoch keine unabhängige Verifizierung der Wahrhaftigkeit dieser Zahl. Dennoch bildet diese Darstellung gemeinsam mit reifen Versionsnummern, der enterpriseartigen Profile-Struktur und den Forks bekannter Projekte ein reifes Produktbild, mit dem Solidity Pro nach außen auftritt.

Diese Werbeaussagen stehen in deutlichem Widerspruch zum zuvor bestätigten tatsächlichen Codeverhalten: README behauptet, dass keine private keys oder Quellcodes gespeichert werden; die Konfiguration beschreibt telemetry als anonym genutzte Daten; das Build-Skript bezeichnet den Obfuskationsprozess von javascript-obfuscator als „privacy“. Das Produkt behauptet ein KI-Audit, Schwachstellenscans und Reentrancy-Erkennung, aber die öffentlichen Befehle dienen vor allem dem Abfragen von Gas, dem Anzeigen von Tokenpreisen und einer über Hardhat/Foundry kompilierten Hinweiszeile.

Organisationsdaten, bekannte Forks, reife Versionsnummern, 100K+ sowie echte nutzbare kleine Funktionen und Hinweise zum Datenschutz beeinflussen die erste Einschätzung der Besucher über die Erweiterung. Jedes Element für sich betrachtet kann normal sein; das Anormale besteht darin, dass diese Signale gleichzeitig mit bösartigem Code, einer schnellen Zeitleiste und dem Build-Rest eines alten Publishers auftreten.

VI. Blindstelle bei Einzelversions-Erkennung

Bösartiger Code kann gelöscht werden, aber Versionshistorie, Veröffentlichungsidentitäten und Quellen des Engineering werden nicht automatisch auf Null gesetzt.

Wenn man die Erkenntnisse der ersten fünf Kapitel zusammenführt, zeigt Solidity Pro ein Muster, das eine Plattform und Sicherheitsprodukte ernsthaft beachten sollten: Ein Erweiterungsname und Publisher, die eindeutig mit einer bösartigen Historie verknüpft sind; durch die Veröffentlichung neuer Versionen, die die ursprünglichen bösartigen Fähigkeiten nicht treffen, können Detektionen, die nur den aktuellen Build prüfen, plötzlich wieder Ergebnisse als „clean“, „nicht getroffen“ oder „niedriges Risiko“ ausgeben.

Um dieses Muster von normaler Sicherheitskorrektur zu unterscheiden, darf man nicht nur darauf achten, ob der neue Code sauber ist. Man muss gleichzeitig vier Ebenen prüfen:

• Hash vs. aktuelle Bundle-Antwort: Was enthält diese Datei jetzt?

• Antwort zur Versionshistorie: Was hat diese Erweiterungs-ID oder dieser Publisher zuvor ausgeliefert?

• Antwort zu Publisher und Codequelle: Mit welchen bekannten bösartigen Projekten besteht eine direkte Verbindung zum aktuellen Paket?

• Antwort zur aktuellen vs. historischen Remote-Control-Flächen: Erlaubt der aktuelle lokale Code oder eine frühere Version, dass der Server den ausgelieferten Inhalt verändert?

Für den Markt der Erweiterungen und Sicherheitssysteme bedeutet das: Das Erkennungsobjekt muss von „einzelner Dateihash“ erweitert werden zu Versionshistorie, Publisher-Wechseln, Unterschieden in den Build-Artefakten und dem Remote-Control-Flächenbereich:

• Speichern der Hashes der Historie und der Entobfuskationsergebnisse. Wenn eine neue Version eine große Anzahl gefährlicher Module entfernt, sollte eine differenzielle Prüfung ausgelöst werden – statt automatisch das Ansehen wiederherzustellen.

• Verknüpfung alter Publisher-Reste, Code-Ähnlichkeiten und Build-Skripte, um eine Quellenverknüpfung von Code oder Build-Artefakten aufzubauen.

• Aufnahme periodischer /version-Prüfungen, entfernter URLs und temporärer VSIX-Installationsprotokolle in die Laufzeitüberwachung.

• Ladezahlen, Stars und enterpriseartiges Profile nur als Kontext verwenden, nicht als Sicherheits-Siegel.

Zusammenfassung

Solidity Pro weist sowohl unter den beiden Veröffentlichungsidentitäten helper-beeps als auch web3devtoolsx eine klar bösartige Implementierung auf: 2.4.1 setzt lokale Zufallsverzögerung und Umgebungsfilterung als Voraussetzung, lädt dann verschlüsselte Python-Dateien aus dem Remote-Endpunkt herunter und führt sie aus; 3.4.0 löst nach dem Start von VS Code automatisch die Erfassung von Zugangsdaten aus und leitet über zwei HTTP-Request-Pfade (/x und /y) ab, während gleichzeitig ein VSIX-Update-Kanal beibehalten wird, der durch die Antwort des Remote-Servers gesteuert wird. Das initiale 3.4.0 out/package.json, die repository- und Copyright-Informationen zeigen weiterhin auf helper-beeps und belegen, dass zwischen den Build-Artefakten der beiden Veröffentlichungsidentitäten eine direkte Quellenverknüpfung besteht.

Das finale Bundle des GitHub-Clean-Commits entfernt diese bösartigen Module zwar, aber das Repository behält weiterhin die Quellcodedateien der bösartigen Module; auch das lokal rekonstruierte 4.0.0-Paket findet keine ursprünglichen bösartigen Module. Der Zeitraum von 13 Minuten und 29 Sekunden zwischen dem initialen Commit, der den bösartigen Einstieg und Build-Artefakte enthält, und dem Clean commit ist extrem kurz. Unternehmensstil-Materialien, sechs bekannte Forks, das Produkt-Repository sowie die reifen Versionsangaben tauchen dann gebündelt innerhalb von etwa 16 Minuten nach Erstellung des Kontos auf.

Dieses Fallbeispiel zeigt letztlich Folgendes: Es reicht nicht, das Erweiterungsrisiko nur anhand der aktuellen Datei bzw. der aktuellen Version zu beurteilen. Bösartiger Code kann aus dem neuesten Bundle verschwinden, aber frühere bösartige Aufzeichnungen verlieren dadurch nicht ihre Gültigkeit: Eine saubere neue Version kann nicht die Tatsache „wegwischen“, dass der gleiche Name und Publisher zuvor bösartigen Code ausgeliefert haben.

Empfehlung

1. Entwickler, die helper-beeps.solidity-pro oder web3devtoolsx.solidity-pro installiert hatten, sollten zuerst das Netzwerk isolieren und die Erweiterungsverzeichnisse, Installationskopien des Pakets, laufende Prozesse sowie Netzwerkprotokolle sichern, bevor sie die betreffenden Versionen deaktivieren und deinstallieren. Danach prüfen: VS-Code-Prozessbaum, Python-Dateien in temporären Verzeichnissen, ungewöhnliche VSIX-Installationshistorien sowie /firmware-, /x-, /y- und /version-Anfragen in Proxy-Logs.

2. Wenn jemals Solidity Pro 3.4.0 ausgeführt wurde (publisher: web3devtoolsx), könnten Wallet-Private-Keys, Mnemonics, GitHub/GitLab/npm/PyPI/AWS/Cloudflare/AI-Services und CI/CD-Token offengelegt werden. Es sollte von sauberen Geräten aus entsprechende Berechtigungsnachweise bevorzugt widerrufen oder rotiert werden. Krypto-Assets müssen in Wallets mit neuem Seed oder neuen Private Keys migriert werden; es darf nicht nur das Passwort des ursprünglichen Wallets geändert werden.

3. Wenn jemals Solidity Pro 2.4.1 ausgeführt wurde (publisher: helper-beeps), dann gilt: Sobald die Maschine das Verzögerungsfenster für dieses Sample möglicherweise überschritten hat oder die tatsächliche Laufzeit nicht verlässlich bestätigt werden kann, sollte man eine Ereignisuntersuchung wie für potenziell lokalen Code durchführen.

4. Sicherheitsteams im Unternehmen sollten zunächst nach Extension-IDs, gefährlichen Request-Pfaden, bekannten Workern, temporären Dateien und ungewöhnlichen Prozessbäumen suchen; anschließend sollten sie mithilfe zweier Sample-SHA-256, der Installationszeit der Erweiterung sowie der Netzwerkprotokolle des VS-Code-Prozesses den betroffenen Umfang bestimmen. Schwerpunkt der Prüfung: Kombinationen von Verhaltensmustern wie der Start des VS Code Extension Host mit detached Python, die Installation eines VSIX aus einem temporären Pfad und das Auslösen von multipart-HTTPS-Anfragen, nachdem wertvolle Konfigurationen ausgelesen wurden.

5. Erweiterungsanbieter sollten eine erzwungene manuelle Überprüfung für die Fähigkeit durchführen lassen, in der standardmäßigen telemetry Credentials auszulesen, remote herunterzuladen, zu entschlüsseln oder die Installation von VSIX über Umgehung offizieller Kanäle zu ermöglichen; historische Versionen aufbewahren und differenzielle Prüfungen über Versionen hinweg durchführen, um das Risiko zu vermeiden, dass alte bösartige Risiko-Tags automatisch für nachfolgende Versionen gelöscht werden, in denen der bösartige Code nicht mehr angetroffen wird.

IOC

Bösartige Datei

filename: helper-beeps.solidity-pro-2.4.1.tar.gz 

SHA256: 7b53b1d93f46babc7415d898e17e71ffb6f3a3af3adb222f21c03adea8b30d50
filename: web3devtoolsx.solidity-pro-3.4.0.gz 

SHA256: bcbaf774f9cea0b0131859b96ba0eeadfd5a49bba59302de1bcf3d884300d508

Zu MistEye

MistEye ist eine von SlowMist eigenständig entwickelte Web3-Threat-Intelligence- und dynamische Sicherheitsüberwachungsplattform. Über APIs bietet sie die Fähigkeit zur Erkennung bösartiger Aktivitäten in einer offenen Paket-Ökosystem-Community sowie zur Vorwarnung von Lieferkettenrisiken.

Alle bösartigen Pakete und IOC, die in dieser Aktion betroffen sind, wurden in die MistEye-Threat-Detection-Engine integriert. Entwickler können über die API automatisch Projektabhängigkeiten prüfen, schnell feststellen, ob sie auf bekannte bösartige Pakete treffen, und Empfehlungen für die Behebung erhalten.

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

🛠️ MistEye-DepScan: https://github.com/slowmist/MistEye-DepScanLeichtgewichtiges CLI-Tool, das mit einem einzigen Befehl Projektabhängigkeiten und bekannte bösartige Pakete in global installierten Paketen scannt; unterstützt npm / PyPI / Rust (Cargo) / Go / RubyGems-Ökosysteme

🛠️ MistEye-Skills: https://github.com/slowmist/misteye-skillsAI Coding Assistant Security Skills Pack; aktiviert MistEye Sicherheitschecks automatisch, bevor Abhängigkeiten installiert und auf eine URL zugegriffen wird

🛠️ MistEye-DNS-Guard: https://github.com/slowmist/MistEye-DNS-GuardRust-Implementierung eines lokalen DNS-Relays, das bösartige Domains und riskanten Zugriff erkennt und Netzwerkbedrohungen wie Phishing und C2 identifiziert.

Dieser Artikel wurde vom SlowMist-Threat-Intelligence-Team in Kombination mit der MistEye-Threat-Intelligence-Plattform und der von SlowMist Agent AI gesteuerten Analyse geschrieben. Bei Fragen können Sie sich gerne melden und Feedback geben.

Referenzlinks:

[1] https://yeethsecurity.com/blog/2026-08-06-Solidity-Pro-WhiteCobra-C2-to-Telegram