Security Blog

634 Passwörter in 56 Sekunden

#174

October 2, 2026 · By Marketing team

← All posts

Eine Entwicklerin oder ein Entwickler durchlief zwei Interviewrunden bei einem gefälschten Unternehmen. Echte Website, echte Gesichter, echte technische Gespräche. Dann kam die Programmieraufgabe. In unter einer Minute waren alle Chrome-Passwörter, die macOS-Keychain und Krypto-Wallet-Daten weg.

Eine Entwicklerin oder ein Entwickler — sicherheitsbewusst, erfahren, jemand, der aktiv nach Betrugsmaschen sucht — durchlief ein mehrstufiges Bewerbungsverfahren bei einem gefälschten Unternehmen. Erstgespräch mit der Personalabteilung. Technisches Interview mit zwei Ingenieuren. Echte Website mit Teamfotos. Echte LinkedIn-Profile. Wochen des Beziehungsaufbaus.

Danach wurde gebeten, eine kleine Programmieraufgabe während einer Bildschirmfreigabe auszuführen.

56 Sekunden später hatten die Angreifer 634 gespeicherte Chrome-Passwörter, die macOS-Keychain-Datei (die den Schlüssel zu ihrer Entschlüsselung enthält) und MetaMask-Wallet-Daten.

Wie der Angriff funktionierte

Das GitHub-Repo sah sauber aus. Ein paar Backend-Dateien, nichts Verdächtiges. Aber eine Abhängigkeit — winston-middleware, ein unauffällig klingendes Logging-Paket — hatte selbst eine Abhängigkeit: next-runtimejs.

Dort saß die Waffe.

In dem Moment, in dem npm install lief, wurde ein Shell-Skript stillschweigend ausgeführt. Keine Rückfragen, keine Warnungen. Es lud eine Backdoor auf Go-Basis herunter und registrierte sie für den Autostart bei jedem Systemstart.

Das war kein Script-Kiddie-Werkzeug. Eigenes, RC4-verschlüsseltes C2-Protokoll. Befehle zur Shell-Ausführung, zum Dateidiebstahl, zur Extraktion von Chrome-Passwörtern, zum Exfiltrieren der Keychain und zur gezielten Ausspähung von Krypto-Wallets. Professionell gebaut.

Die Backdoor startete um 16:16:37. Auf die Chrome-Passwörter wurde um 16:17:33 zugegriffen. Die betroffene Person bemerkte einen macOS-Hinweis auf eine ausgehende Verbindung und schaltete WLAN innerhalb einer Minute ab — der Schaden war aber bereits angerichtet.

Warum das Interview entscheidend war

Dieser Angriff wäre als Kaltakquise-Mail gescheitert. „Führen Sie dieses Repo aus" von einem Fremden wird ignoriert.

Aber nach zwei Interviewrunden? Nachdem man gemeinsam darüber gelacht hatte, wie viele gefälschte Jobangebote auf Entwickler abzielen? Nachdem einer der Interviewer lächelnd sagte: „Suchen Sie ruhig nach Backdoors"?

In dem Moment lässt die Wachsamkeit nach. Vertrauen ist die Schwachstelle. Die Malware ist nur die Nutzlast.

Die betroffene Person hat es auf den Punkt gebracht: „Wenn es mir passieren kann, kann es jedem in Ihrem Team passieren."

Was Chrome-Passwörter tatsächlich bedeuten

Chrome verschlüsselt gespeicherte Passwörter mit AES. Der Entschlüsselungsschlüssel liegt in der macOS-Keychain. Die Angreifer stahlen beide Dateien in unter einer Minute.

Jedes gespeicherte Passwort — Banking, E-Mail, GitHub, Cloud-Konsolen — war auf deren Seite lesbar. Die Keychain-Datei lässt sich offline knacken, ohne Ratenbegrenzung. Die betroffene Person musste alles rotieren.

Das ist das offene Geheimnis der im Browser gespeicherten Passwörter: Sie sind mit einem Schlüssel verschlüsselt, der auf derselben Maschine liegt. Ist die Maschine kompromittiert, ist die „Verschlüsselung" Dekoration.

Das DPRK-Muster

Die betroffene Person erwähnte, dass ihr vorheriger Arbeitgeber drei Monate zuvor ebenfalls von Nordkorea gehackt wurde. Es handelt sich um die Kampagne „Contagious Interview" — staatsnahe DPRK-Angreifer, die gefälschte Bewerbungsgespräche führen, um Malware auf Entwicklerrechnern zu platzieren.

Das ist kein Zufall. Sie zielen gezielt auf Entwickler ab, und zwar wegen dessen, worauf Entwickler Zugriff haben: Produktionszugangsdaten, Signaturschlüssel, Cloud-Infrastruktur und — zunehmend — Tokens für KI-Agenten, die noch mehr erreichen.

Das Ausmaß ist industriell. Gefälschte Unternehmen mit generierten Gesichtern. Hochwertige Websites. Bewerbungsprozesse über mehrere Wochen. Sie investieren, weil sich die Rechnung lohnt.

„Passwort-Manager helfen nicht"

Die betroffene Person brachte im Thread eine interessante These vor: „Passwort-Manager helfen nicht, wenn jemand über eine solche Backdoor Zugriff auf Ihren Rechner hat, weil dann jede Datei übertragen, ein gezielter Exploit für Sie gebaut, Keylogger und Bildschirmfotos eingesetzt werden können."

Das ist teils richtig und teils falsch.

Ein Passwort-Manager, der seinen Tresor auf Ihrer lokalen Festplatte speichert und per eingegebenem Master-Passwort entsperrt wird — ja, eine Backdoor mit Keylogging und Dateizugriff kann das kompromittieren.

Aber ein Passwort-Manager mit hardwaregebundenen Schlüsseln — bei dem der Entschlüsselungsschlüssel aus einem physischen Authenticator abgeleitet wird und nie als Datei auf der Festplatte existiert — ist grundlegend anders. Die Backdoor kann Dateien stahlen, Tastatureingaben protokollieren, Bildschirmfotos aufnehmen. Aber sie kann keinen Schlüssel extrahieren, der nur innerhalb eines Hardware-Sicherheitsmoduls existiert und eine physische Handlung erfordert.

Die 634 Chrome-Passwörter wurden gestohlen, weil sowohl die verschlüsselten Daten als auch der Entschlüsselungsschlüssel Dateien im Dateisystem waren. Wenn der Entschlüsselungsschlüssel den physischen Besitz eines Geräts voraussetzt, erhalten Sie durch gestohlene Dateien verschlüsselte Blobs und sonst nichts.

Was Sie tun können

  • Führen Sie Interview-Code nie auf Ihrem Hauptrechner aus. Nutzen Sie eine VM oder ein separates Gerät.
  • Führen Sie npm install --ignore-scripts bei jedem unbekannten Repo aus, bevor Sie etwas ausführen
  • Nutzen Sie eine ausgehende Firewall (Little Snitch, LuLu), die bei neuen Verbindungen warnt
  • Speichern Sie keine Passwörter mehr in Chrome. Punkt.
  • Bewahren Sie Kryptowerte auf Hardware-Wallets auf, nicht in Browser-Erweiterungen
  • Behandeln Sie jede Programmieraufgabe eines Recruiters als potenziell feindselig, egal wie viele Gespräche Sie bereits geführt haben

Die betroffene Person kam davon, weil ein macOS-Hinweis die ausgehende Verbindung rechtzeitig anzeigte. Die meisten hätten ohne nachzudenken auf „Zulassen" geklickt.

56 Sekunden. Mehr braucht es nicht.