Sechs npm-Pakete lesen C2-Adressen aus Ethereum-Wallet

Sechs npm-Pakete wurden gefunden, die eine von Angreifern kontrollierte Ethereum-Wallet abfragen, um zu ermitteln, woher sie ihre nächste Malware-Stufe beziehen sollen, indem sie Command-and-Control (C2)-Adressen aus einer Blockchain-Transaktion auslesen.

Sonatype Research Labs identifizierte die Pakete am 10. August und veröffentlichte die Analyse am selben Tag. Alle sechs enthalten dieselbe Payload, und Sonatype verfolgt sie unter sonatype-2026-005899 und sonatype-2026-005901.

Die Wallet-Adresse stimmt mit einer überein, die von Forschern bei OpenSourceMalware dokumentiert wurde. Diese nannten die Technik NullReceiver und ordneten die untersuchten Aktivitäten der mit der DVRK in Verbindung stehenden Contagious Interview-Kampagne zu, die mit der Lazarus-Gruppe assoziiert wird. 

Sonatype gab an, die Übereinstimmung der Wallet bestätigt und ein ähnliches Vorgehen beobachtet zu haben, einschließlich des Kaperns von Paketen und des blockchain-basierten Abrufs von Folge-Infrastruktur.

Lesen Sie mehr über npm-Lieferkettenangriffe: Nordkoreanische Hacker starten neue Welle von npm-Paketangriffen

Eine Transaktion als Dead Drop

Bei der Ausführung fragte der Loader Ethereum nach einer ausgehenden Transaktion der Wallet ab und las Bytes aus der Empfängeradresse der Transaktion. Diese Bytes ließen sich in zwei IPv4-Adressen dekodieren, die er als primäre und sekundäre C2-Endpunkte behandelte.

Sonatype stellte fest, dass diese Implementierung umfangreicher war als das zuvor dokumentierte Verhalten. Der Loader konnte mehrere Ethereum-Remote-Procedure-Call-Provider abfragen, Anfragen zwischen ihnen priorisieren, seine Aufrufe stapeln und auf die Blockscout-API zurückgreifen, um die relevante Transaktion zu lokalisieren. Dies ermöglichte mehrere Wege zur Wiederherstellung seiner Infrastruktur, falls einer fehlschlagen sollte.

Sobald die Adressen aufgelöst waren, lud er zwei weitere Stufen vom Server herunter. Wenn eine Standardanfrage fehlschlug, wiederholte er den Vorgang und stellte die Payload stattdessen aus einem Response-Header wieder her.

Das Ergebnis wurde dekodiert und konnte entweder direkt innerhalb des aktuellen Node.js-Prozesses ausgeführt oder als separater Child-Prozess gestartet werden.