Ein Fake-Interview-Angriff landet als harmlose Job-Anfrage im Postfach, getarnt als Beratungsmandat eines vermeintlichen Singapur-VCs. Ein kanadischer Rust-Entwickler hat genau so einen mutmaßlich staatlich gesteuerten Angriffsversuch Schritt für Schritt dokumentiert und damit einen seltenen Blick in eine reale Angriffskette geöffnet.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Das Wichtigste in Kürze
- Der Köder bestand aus einem gefälschten Berater-Profil samt LinkedIn-Seite und zwei Schein-Investments, gefolgt von einem TypeScript-Repo als „Test“.
- Die Schadlast steckte versteckt in einem von vielen
patches/-Verzeichnissen, base64-codiert und XOR-verschlüsselt, getarnt als TypeScript-Patch. - Der Code feuert beim ersten
buildodertypecheck, nicht beim Installieren, und umging zum Zeitpunkt der Analyse jeden Virenscanner auf VirusTotal. - Das Muster gehört zur Kampagne „Contagious Interview“, die Sicherheitsforscher Nordkorea zuordnen.
Wie lief die Angriffskette konkret ab?
Der Aufbau folgte dem Drehbuch eines echten Bewerbungsprozesses. Zuerst kam eine seriös wirkende E-Mail mit Link zu einem unauffälligen LinkedIn-Profil. Danach folgte ein Telefonat mit einem schwer verständlichen Gesprächspartner, der einen deutschen Akzent hatte und angeblich gerade unterwegs war. Erst nach dem Gespräch kam der Köder: eine Folge-E-Mail mit einem „Test“ in Form eines Repositorys.
Die erste echte Warnflagge stieg, sobald die Aufgabe nicht zur angeblichen Architektur-Analyse passte, sondern wie ein TypeScript-Bewerbungstest aussah. Eine schnelle Prüfung durch einen KI-Assistenten brachte die Tarntechnik ans Licht: eine unverhältnismäßig große Zahl an patches/-Verzeichnissen, von denen die meisten nur Rauschen erzeugten, damit die eigentliche Schadlast unbemerkt blieb. Versteckt in einem als „module specifier“-Patch getarnten Eintrag lag ein selbstausführender Stub. Dieser Stub dekodiert eine base64-Zeichenkette, entschlüsselt jedes Byte mit dem Schlüssel 73 per XOR und führt das Ergebnis über new Function aus.
Warum ist das kein Einzelfall?
Dieser Vorfall taugt als Lehrstück für eine ganze Angriffsklasse. Lieferketten-Angriffe über manipulierte Pakete produzieren seit Monaten Schlagzeile nach Schlagzeile. Socket-Forscher führen unter dem Namen Contagious Interview inzwischen mehr als 1.700 schädliche Pakete, verteilt über npm, PyPI, Go, Crates.io und Packagist. Auffällig dabei: Der Schadcode zündet nicht beim Installieren, sondern versteckt sich in normal wirkenden Funktionen und hebelt so klassische Scanner aus.
Die Handschrift bleibt über die Wellen hinweg gleich. Sicherheitsanbieter ordnen die Aktivität mit hoher Sicherheit dem Lazarus-Umfeld und nordkoreanischen IT-Worker-Programmen zu, gestützt auf wiederkehrende Köder, GMT+9-Zeitstempel in Commits und einen festen Fokus auf Krypto-Wallets, Signing-Keys und CI/CD-Zugänge. Operatoren lassen den Implantat-Code nach dem Erstzugriff oft bewusst ruhen, damit das Opfer den fehlgeschlagenen Call neu ansetzt und der Rechner unbemerkt kompromittiert bleibt. Wie stark selbst offizielle Pipelines betroffen sind, zeigte zuletzt der Miasma-Wurm in Red Hats npm-Paketen.
Die eigentliche Lehre steckt nicht im Telefonat, sondern im Build-Schritt. Eine Entwickler-Workstation, die fremden Code kompiliert, ist 2026 ein direkter Eintrittspunkt in Ihre gesamte Lieferkette.
— Markus Seyfferth, Chefredakteur Dr. Web
Was bedeutet das für deutschsprachige Unternehmen?
Für DACH-Entscheider verschiebt der Fall die Haftungsfrage. Ein kompromittierter Entwickler-Rechner kann zum Türöffner für ein ganzes Unternehmen werden, und das NIS-2-Umsetzungsgesetz zieht seit Dezember 2025 rund 29.500 Unternehmen aus 18 Sektoren in die direkte Verantwortung der Geschäftsleitung. Erleidet eine regulierte Einrichtung einen erheblichen Sicherheitsvorfall, läuft die 24-Stunden-Frühwarnung an das BSI ab Kenntnis des Vorfalls, gefolgt von einer 72-Stunden-Meldung und einem Abschlussbericht nach einem Monat. Versäumte Meldungen können Bußgelder bis 10 Mio. € nach sich ziehen.
Drei Sofortmaßnahmen senken das Risiko spürbar. Klonen Sie fremden Code grundsätzlich nur in einer isolierten Sandbox und bauen oder typechecken Sie ihn niemals direkt auf der Arbeitsmaschine. Prüfen Sie Patch-Dateien und Lifecycle-Hooks in jeder package.json vor dem ersten Build, weil genau dort die Schadlast lauert. Dokumentieren Sie den Meldeweg über das BSI-Portal vorab und benennen Sie eine erreichbare Kontaktperson, damit im Ernstfall keine Stunde verloren geht.
Bauen Sie diese Prüfschritte fest in Ihren Onboarding- und Recruiting-Prozess ein, bevor der nächste „Test“ im Postfach landet.
Mehr #Cybersecurity News
Mehr zu Supply-Chain-Sicherheit
Mehr Newshunger?
