Shai-Hulud auferstanden nach 111 Tagen

Hallo Internet,

Erinnert ihr euch an den Shai-Hulud-Angriff der am @AntV 19. Mai 2026 einschlug? Ich weiß, in der Welt der Supply Chain kommt das inzwischen wie eine halbe Ewigkeit vor. Ein kompromittierter Maintainer-Account hatte innerhalb einer einzigen Stunde 639 schadhafte Versionen von @antv-Paketen auf npm veröffentlicht. Wir haben diese Nutzlast zusammen mit dem Großteil der npm-Sicherheits-Community innerhalb von Stunden in ihre Einzelteile zerlegt. Technisch gesehen war das nichts Neues. Einfach ein weiterer Tag, an dem man aufwacht und ein Supply Chain Attack stattfindet. Business as usual.

Seitdem hat npm eine Malware-Scans eingeführt, die beim Publizieren greifen. Ihr könnt euch also meine Überraschung vorstellen, als ich heute Morgen unsere Triage-Warteschlange durchging und etwas sah, das ich sofort als einen kleinen Wurm erkannte. Er hatte denselben Hash wie die @AntV Welle. Gleiche Nutzlast:

e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6. Dies ist exakt 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öllige Stille zu diesem Hash. Soweit wir das beurteilen können, ist das die längste Zeitspanne zwischen Inaktivität und Reaktivierung, die wir jemals bei einer Shai-Hulud-Nutzlast gesehen haben – und es ist nicht mal knapp. Nennen wir es beim Namen: Ein Zombie, der vier Monate auftaucht, nachdem alle dachten, er sei tot.

Die vier Pakete, die ihn zurückgebracht haben, alle am 7. September innerhalb derselben Stunde vom selben 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 Dateihash über jede von uns gescannte Paketversion hinweg abgerufen. So sieht die Zeitleiste tatsächlich aus:

Unsere Aufzeichnungen zeigen 319 Paketversionen mit diesem Hash, von denen jede einzelne erstmals am 19. Mai 2026 gesichtet wurde – dem Tag der @AntV Welle und keinen Tag davor oder danach. Danach nichts. Null neue Treffer für diesen Hash zwischen dem 20. Mai und dem 6. September. Ab heute (7. September) landeten dann vier weitere Paketversionen auf npm, die exakt dieselbe Nutzlast 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 im Vergleich zu einer größeren Tatsache: Eine Nutzlast mit einem bekannten, veröffentlichten, indizierten Hash lag über drei Monate lang unberührt in keiner Toolchain und wurde dann auf einer Registry republiziert, die seit diesem Jahr jedes Paket explizit scannt, bevor es live geht.

Der einfache Fall

Im Juli hat npm Malware-Scans zum Zeitpunkt der Veröffentlichung eingeführt: Jedes Paket wird 5 bis 15 Minuten lang zurückgehalten, während ein automatisiertes System es überprüft, bevor es installierbar wird. Laut dem eigenen Changelog von npm ist das Ziel, „die Malware, die wir erkennen können“, abzufangen, bevor sie npm install erreicht.

Ein Dateihash-Abgleich ist eine einfache Abfrage und kein schwieriges Problem. Er erfordert keine Verhaltensanalyse, kein Sandboxing und keine Überlegungen zur Absicht von verschleiertem Code. Und diese Nutzlast war weder neu noch neu verpackt oder auch nur leicht modifiziert, um dem Signaturabgleich zu entgehen. Es waren dieselben 64 Hexadezimalzeichen, die seit Mai aktenkundig waren.

Wir wollen damit nicht sagen, dass der Scanner alles erkennen sollte. Mehrstufige Loader, Dependency Confusion und zur Laufzeit ausgelöste Nutzlasten sind echte Herausforderungen. Ein exakter Hash-Abgleich mit einem Wur, der vor vier Monaten weltweit für Sicherheits-schlagzeilen sorgte, ist das jedoch nicht. Das ist das absolute Minimum dessen, was ein Scan bei der Veröffentlichung abfangen muss, und es wurde übersehen. Diese spezifische Probe sollte im Testkorpus von jedem enthalten sein, der Supply-Chain-Scanning betreibt.

Das Fazit

Eine Wurm-Nutzlast mit einem öffentlichen Hash, umfangreichen Berichten von Anbietern und monatelanger Erkennungsabdeckung schlummerte 111 Tage lang und tauchte dann ohne Hindernisse wieder auf npm auf – auf einer Registry, die nun damit wirbt, jede Veröffentlichung zu scannen. Diese Lücke zwischen dem, was ein Scan auf Registry-Ebene vorgibt zu leisten, und dem, was eine Reaktivierung mit identischem Hash tatsächlich gezeigt hat, ist die eigentliche Geschichte hier. Der Signaturabgleich mit bekannten Schadkomponenten ist die allererste Hürde in dieser Branche, und es ist die Hürde, deren Verfehlen uns alle am meisten alarmieren sollte. Wenn das im einfachen Fall durchschlüpft, stellt sich die Frage, was eine Nutzlast angerichtet hätte, die 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
• Root-Ebene index.js Nutzlast
• ausführung des Preinstall-Skripts bun run index.js

Persistenz:

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

Verhaltensanalyse:

• Ausgehende Validierungsaufrufe an die npm-Registry unter Verwendung gestohlener Token
• Herunterladen des Tarballs, Injektion der Nutzlast, Versionsanpassung, Republikationszyklus
• Massenhafte Erstellung von GitHub-Repositories mit Dune-Naming und umgedrehten „Shai-Hulud“-Strings in den Beschreibungen