Der eigene Fehler des Hackers öffnete die Tür

22 Monate lang beobachtete Vangelis Stykas eine nordkoreanische Staatshacker-Crew von innen, nicht weil er sich in ihre Systeme gehackt hätte, sondern weil deren eigene Schadsoftware zuerst ihre eigenen Arbeitsrechner infizierte. Stykas, Chief Technology Officer beim Cybersicherheitsunternehmen Kumio, erklärte auf der Black-Hat-Konferenz in Las Vegas Anfang August 2026, dass sich die Operatoren selbst infizierten und ihm so ein Fenster in ihre internen Slack- und Discord-Kanäle öffneten.

Dieser zufällige Zugang verschaffte ihm einen stillen Blick auf rund 5 Terabyte an Daten, die die Gruppe von ihren eigenen Opfern gestohlen hatte, sowie einen seltenen Einblick in den täglichen Ablauf der Operation, völlig unbemerkt von den Hackern selbst.

1.640 Unternehmen, 57 Länder, ein Dutzend Namen

Stykas gab an, dass die Gruppe während des Zeitraums, in dem er Zugang hatte, 1.640 Unternehmen in 57 Ländern kompromittiert hatte. Zwischen 700 und 800 dieser Einbrüche stufte er als schwerwiegend ein, das heißt, die Angreifer erreichten Root-Zugriff auf Server, AWS-Cloud-Umgebungen oder Kryptowährungs-Wallets, weit über einen bloßen Fuß in der Tür auf einem einzelnen Rechner hinaus.

In seiner Präsentation nannte Stykas öffentlich rund ein Dutzend der betroffenen Organisationen, darunter den Smartphone-Hersteller Oppo, Coinbase, Uniswap Labs, das Boston Children's Hospital sowie mehrere Regierungsbehörden, die er nicht namentlich nannte.

Der Einstieg war ein Vorstellungsgespräch

Unabhängig von Stykas' Forschung verfolgen Sicherheitsteams von Elastic Security Labs, Proofpoint und weiteren Firmen seit 2026 eine aktive nordkoreanische Kampagne namens Contagious Interview, die der Lazarus Group zugeschrieben wird. Die Operatoren geben sich auf Plattformen wie LinkedIn als Recruiter aus, sprechen Softwareentwickler mit einem scheinbar echten Jobangebot an und schicken dann einen Programmiertest, der in einem GitHub-Repository gehostet wird.

Die Falle sitzt im .githooks-Ordner des Repositorys als Pre-Commit-Hook und löst automatisch aus, sobald der Entwickler seinen Testcode committet, ganz ohne separaten Download oder Doppelklick. Andere Varianten derselben Kampagne haben die Schadsoftware mittels Steganografie in SVG-Bilddateien versteckt, und Proofpoint registrierte allein im April und Mai 2026 mehr als 250 bösartige Recruiting-E-Mails, konzentriert auf Beschäftigte in Technologie, Bildung und Finanzen, mit besonderem Fokus auf kryptonahe Rollen.

Was die Schadsoftware tatsächlich tut

Die in diesen Kampagnen eingesetzten Schadprogramm-Familien, darunter OTTERCOOKIE und verwandte Tools, sind darauf ausgelegt, Browser-Zugangsdaten, Kryptowährungs-Wallets und Dateien zu stehlen und den Operatoren Fernzugriff auf den infizierten Rechner zu verschaffen. Bei einem Entwickler landet dieser Zugriff oft genau in der Umgebung, die Firmen-Repositorys, Cloud-Zugangsdaten und Kundendaten enthält.

Das ist die Verbindung zwischen den beiden Strängen. Eine Gruppe, die nachweislich Einbrüche im von Stykas dokumentierten Ausmaß betreiben kann, 1.640 Unternehmen in 57 Ländern, betreibt nachweislich auch einen erheblichen Teil ihres Zugangs über den ganz gewöhnlichen Akt der Einstellung, was den Angriffsweg für jedes EU- oder UK-Unternehmen relevant macht, das remote Entwickler oder Auftragnehmer einstellt, sowie für jeden Entwickler, der aktuell auf Jobsuche ist.

Drei Prüfungen, bevor Sie das Repo klonen

Die praktische Verteidigung ist konkret, keine allgemeine Phishing-Warnung. Prüfen Sie die Identität eines Recruiters unabhängig, über die eigene Karriereseite des Unternehmens oder einen bekannten Mitarbeiter, bevor Sie irgendeinen von ihm gesendeten Code ausführen. Betrachten Sie einen Programmiertest, der das Klonen eines vollständigen Repositorys mit Hooks und Setup-Skripten erfordert, als verdächtiger als einen, der über eine isolierte Sandbox-Plattform bereitgestellt wird, da die Sandbox genau den Mechanismus entfernt, auf den der .githooks-Trick angewiesen ist.

Behandeln Sie einen ungewöhnlich schnellen, druckvollen Einstellungszeitplan als größeres Warnsignal, als er es vor einem Jahr gewesen wäre, und führen Sie niemals ein Setup-Skript, npm install oder einen Build-Befehl aus einem Test-Repository aus, bevor diese Identitätsprüfung abgeschlossen ist. Nichts davon erfordert neue Werkzeuge, nur eine Pause, bevor der erste Befehl läuft.