Shai-Hulud erwacht nach 111 Tagen von den Toten

Hallo Internet,

Erinnerst du dich noch an die Angriff des Shai-Hulud der Treffer @AntV Am 19. Mai 2026? Ich weiß, in der Welt der Lieferketten kommt es mittlerweile einem ganzen Leben vor. Ein gehacktes Betreiberkonto hat innerhalb einer einzigen Stunde 639 bösartige Versionen von @antv-Paketen auf npm hochgeladen. Wir haben diese Payload – zusammen mit dem Großteil der npm-Sicherheits-Community – innerhalb weniger Stunden auseinandergenommen. Technisch gesehen war das nichts Neues. Es war einfach wieder ein Tag, an dem man aufwachte und feststellte, dass es einen Supply-Chain-Angriff gab. Business as usual.

Seitdem hat npm eine Malware-Prüfung zum Zeitpunkt der Veröffentlichung eingeführt. Ihr könnt euch also vorstellen, wie überrascht ich war, als ich heute Morgen unsere „ triage “-Warteschlange durchging und etwas entdeckte, das ich sofort als „Wormy Boy“ erkannte. Es hatte denselben Hash wie das @AntV Welle. Gleiche Nutzlast:

e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6. Das ist genau dieselbe Datei, deren Fingerabdruck npm, wir und die Hälfte der Anbieter auf dieser Liste bereits vor Monaten erfasst hatten.

Das sind 111 Tage völliger Stille bei diesem Hash. Soweit wir das beurteilen können, ist das die längste Zeitspanne zwischen Inaktivität und Reaktivierung, die wir bisher bei einer Shai-Hulud-Nutzlast beobachtet haben – und zwar mit großem Abstand. Nennen wir es beim Namen: ein Zombie, der vier Monate, nachdem alle ihn schon für tot gehalten hatten, wieder auftaucht.

Die vier Pakete, die es wieder verfügbar machten, wurden alle am 7. September innerhalb derselben Stunde über denselben npm-Account veröffentlicht:

• feishu-docx-mcp@0.3.2
• bmc-i18n-extract-cli@1.1.1
• blueai-cli@0.7.0
• bmc-translate-utils@1.1.1

Die Zahlen

Wir haben unsere Erkennungshistorie für genau diesen Datei-Hash über alle von uns gescannten Paketversionen hinweg abgerufen. So sieht die Zeitleiste tatsächlich aus:

Unseren Aufzeichnungen zufolge gibt es 319 Paketversionen mit diesem Hash, von denen jede einzelne erstmals am 19. Mai 2026 auftauchte, dem Tag des @AntV Eine Welle – und kein Tag davor oder danach. Dann nichts mehr. Zwischen dem 20. Mai und dem 6. September gab es keine neuen Treffer für diesen Hash. Dann, ab heute (7. September), tauchten vier weitere Paketversionen auf npm auf, die genau denselben Inhalt enthielten. Das ist eine Lücke von 111 Tagen: zuletzt gesehen am 19. Mai, das nächste Mal am 7. September.

Vier Pakete sind eine kleine Zahl, hinter der sich eine größere Tatsache verbirgt: Eine Nutzlast mit einem bekannten, veröffentlichten und indizierten Hash blieb über drei Monate lang unberührt in der Toolchain eines Nutzers und wurde anschließend erneut in einem Register veröffentlicht, das seit diesem Jahr jedes Paket ausdrücklich überprüft, bevor es online gestellt wird.

Der einfache Fall

Im Juli führte npm eine Malware-Prüfung zum Zeitpunkt der Veröffentlichung ein: Jedes Paket wird 5 bis 15 Minuten lang zurückgehalten, während ein automatisiertes System es überprüft, bevor es zur Installation freigegeben wird. Laut dem Changelog von npm besteht das Ziel darin, „die Malware, die wir erkennen können“, abzufangen, bevor sie den Befehl „npm install“ erreicht.

Ein Dateihash-Abgleich ist eine einfache Abfrage, kein schwieriges Problem. Er erfordert weder „ Verhaltensanalyse “ noch Sandboxing noch Rückschlüsse auf die Absicht hinter verschleiertem Code. Und diese Payload war weder neu noch neu gepackt oder auch nur geringfügig verändert worden, um einem Signaturabgleich zu entgehen. Es handelte sich um dieselben 64 Hexadezimalzeichen, die bereits seit Mai in den Unterlagen verzeichnet waren.

Wir behaupten nicht, dass der Scanner alles erkennen sollte. Mehrstufige Loader, Abhängigkeitsverwirrung und zur Laufzeit ausgelöste Payloads sind tatsächlich schwierige Probleme. Eine exakte Hash-Übereinstimmung mit einem Wurm, der vor vier Monaten für internationale Sicherheitsschlagzeilen sorgte, gehört jedoch nicht dazu. Das ist das absolute Minimum dessen, was ein Scan zum Zeitpunkt der Veröffentlichung erkennen sollte – und es wurde übersehen. Dieses konkrete Beispiel sollte im Testkorpus jedes Anbieters enthalten sein, der Supply-Chain-Scans durchführt.

Das Fazit

Eine Wurm-Payload mit einem öffentlichen Hash, ausführlichen Beschreibungen von Anbietern und monatelanger Erkennungsabdeckung lag 111 Tage lang im Ruhezustand und tauchte dann völlig ungehindert wieder bei npm auf – in einer Registry, die mittlerweile damit wirbt, jede Veröffentlichung zu scannen. Diese Diskrepanz zwischen dem, was das Scannen auf Registry-Ebene angeblich leistet, und dem, was eine Reaktivierung mit identischem Hash tatsächlich aufdeckt, ist hier die eigentliche Geschichte. Der Abgleich von Signaturen mit bekanntermaßen bösartigen Artefakten ist die einfachste Hürde in dieser Branche – und genau diese Hürde sollte uns alle am meisten beunruhigen, wenn sie nicht genommen wird. Wenn schon so etwas im einfachsten Fall durchrutscht, stellt sich die Frage, was eine Payload bewirkt hätte, bei der man sich die Mühe gemacht hätte, auch nur ein einziges Byte zu ändern.

Indikatoren für Kompromittierung

Netzwerk:

• t[.]m-kosche[.]com (C2, aus der ursprünglichen Mai-Welle)

Datei:

• SHA256: e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6
• Stammverzeichnis index.js Nutzlast
• Ausführung des Vorinstallationsskripts bun run index.js

Beharrlichkeit:

• .vscode/tasks.json
• .claude/settings.json

Verhaltensbezogen:

• Ausgehende Validierungsaufrufe an die npm-Registry unter Verwendung gestohlener Token
• Tarball-Download, Einfügen von Payloads, Versionserhöhung, Veröffentlichungszyklus
• Massenanlegung von GitHub-Repositorys mit Namen im Dune-Stil und umgekehrten „Shai-Hulud“-Zeichenfolgen in den Beschreibungen