Next.js unterwandert: So nutzen DPRK-Entwickler gefälschte Jobangebote als Einfallstor
Wenn aus einem Traumjob-Albtraum wird: So infiltrieren Hacker Entwickler über gefälschte Jobinterviews
Stell dir vor: Ein Recruiter schreibt dich auf LinkedIn an. Remote-Arbeit, faire Bezahlung, interessante Tech-Stack – klingt traumhaft. Zu traumhaft? Leider gibt es mittlerweile gut organisierte Kampagnen, die genau diese Sehnsüchte ausnutzen.
Elastic Security Labs hat kürzlich eine besorgniserregende Operation aufgedeckt, die auf Softwareentwickler abzielt. Die Drahtzieher sitzen in Nordkorea (Tracking-Name: REF9403), und die Methoden sind raffiniert. Besonders beunruhigend: Die Schadsoftware versteckte sich in SVG-Grafiken mittels Steganografie, und kein einziger Antivirus-Hersteller hat sie erkannt.
Der Köder: Vertrauenswürdig aussehende Jobangebote
Alles beginnt mit Social Engineering. Am 26. Mai tauchte in einem öffentlichen Slack-Workspace eine Nachricht von jemandem namens "Maxwell" auf. Er suchte Hilfe beim Upgrade einer E-Commerce-Plattform – ein völlig normales Szenario für Freelancer und Angestellte.
Nach dem ersten Kontakt folgte eine klassische Verschiebung in Direct Messages. Seriöse Personalvermittler nutzen für Erstgespräche normalerweise keine DMs – das allein sollte stutzig machen. Dann kam die berühmte Take-Home-Challenge: ein angebliches Coding-Projekt zum Testen der Fähigkeiten.
Das Repository sah absolut legitimate aus. Ein Next.js-Shop namens "GoCart", basierend auf einem Template von GreatStackDev. Es ließ sich fehlerfrei ausführen. Keine verdächtigen Berechtigungsanfragen, keine merkwürdigen Warnungen. Einfach nur ein Bewerber, der seine Aufgabe erledigt – wie jeden Tag weltweit tausende andere Entwickler.
Genau hier liegt die Stärke dieser Attacke.
Die Technik dahinter: Steganografie in Bildern
Die Malware verteilte sich über das gesamte Repository, versteckt in Variablennamen, die völlig unverdächtig wirkten. Der eigentliche Clou waren jedoch die SVG-Dateien.
Jeder Online-Shop braucht Länderflaggen für die Internationalisierung. Die Angreifer erstellten SVG-Dateien für verschiedene Länder (AE.svg, AF.svg und so weiter), die völlig normal aussahen. Doch in HTML-Kommentaren verbarg sich Base64-kodierter Schadcode – aufgeteilt in kleine Fragmente.
Eine JavaScript-Datei namens serverValidation.js reassembliert diese Bruchstücke alphabetisch, dekodierte sie und führte die Payload aus. Für jemanden, der den Code überfliegt, sieht das nach harmloser Dateiverarbeitung aus. Der bösartige Kern bleibt unsichtbar.
Was dann passierte: Vierstufige Payload
Nach der Ausführung richteten sich die Opfer einen mehrstufigen Trojaner ein:
Stufe 1: Browser-Credentials im Visier Gespeicherte Passwörter für Arbeitskonten, interne Tools, Cloud-Dienste – alles wurde eingesammelt.
Stufe 2: Krypto-Wallets als Hauptziel Vermutlich die finanzielle Triebfeder: Wallet-Zugänge wurden systematisch abgeräumt.
Stufe 3: Sensible Dateien verschwinden Dokumente, SSH-Keys, API-Tokens, Environment-Variablen – alles Wertvolle wanderte zu den Angreifern.
Stufe 4: Persistenz durch Backdoor Ein Remote-Access-Trojaner nutzte Socket.IO (eine legitime Echtzeit-Kommunikationsbibliothek) für Command-and-Control. So hatten die Angreifer dauerhaften Zugriff.
Warum das funktionierte: Null Erkennungen
Die Angreifer verteilten präparierte Repositories unter verschiedenen Namen:
- next-ecommerce-private-main.zip
- shopping-platform-main.zip
- ecommerce-platform.zip
- ecommerce-platform-main.zip
- shopping-platform.rar
- shop-main.zip
- ecommerce-main.zip
Keine einzige Erkennung. Stand der Entdeckung meldete kein Antivirus etwas. Das zeigt, wie sorgfältig der Code entwickelt wurde, um statische Analysen zu umgehen.
Das große Bild: Entwickler als Einfallstor
Hinter dieser Kampagne steckt mehr als die Kompromittierung einzelner Entwickler. Ein infizierter Account bedeutet potenziellen Zugang zu:
- Firmeninternen Systemen
- GitHub/GitLab-Repositories mit Sourcecode
- CI/CD-Pipelines
- Produktionsumgebungen
- Kundendaten
- Supply-Chain-Beziehungen
Die Folge könnten Angriffe auf die gesamte Lieferkette sein – mit Auswirkungen auf Tausende oder Millionen Nutzer downstream. Kein Wunder, dass APT-Gruppen Entwickler als Hochvalue-Ziele betrachten.
Schutzmaßnahmen: Was du konkret tun kannst
1. Take-Home-Challenges kritisch betrachten Seriöse Unternehmen lassen selten Unbekannte beliebige Repositories herunterladen und ausführen. Wenn die "Coding-Challenge" npm install und node serverValidation.js erfordert – Finger weg.
2. SVG-Dateien inspizieren Öffne sie in einem Texteditor. Ungewöhnliche Kommentare oder Base64-Strings? Die meisten legitimen Bilder enthalten keine HTML-Kommentare mit kodierten Daten.
3. Jobangebote unabhängig verifizieren Wenn jemand per DM schreibt, finde das Unternehmen selbst und prüfe, ob die Position existiert. Verlasse dich nicht auf den Absender.
4. Isolierte Umgebungen nutzen Niemals Code-Challenges auf dem Hauptgerät ausführen. VMs, Container oder dedizierte Lab-Umgebungen ohne Zugriff auf sensible Systeme.
5. Den Workflow hinterfragen Warum erfordert ein Jobinterview das Ausführen einer Full-Stack-Anwendung mit npm install? Für eine Coding-Challenge ist das ungewöhnlich.
Fazit
Unsere Community lebt von Zusammenarbeit, Open-Source-Beiträgen und Vertrauen in geteilten Code. Genau das machen sich Bedrohungsakteure zunutze.
Diese Kampagne zeigt ein neues Level an Raffinesse: Steganografie, vertrauenswürdig wirkende Projekte und Social Engineering – kombiniert, um Entwickler zu kompromittieren. Dass monatelang nichts erkannt wurde, sollte uns alle nachdenklich stimmen.
Bleib wachsam. Nicht jede Jobchance ist, was sie verspricht – und manchmal führt der Code, der einwandfrei läuft, genau das aus, wofür du nie unterschrieben hast.
Mehr zum Thema Sicherheit? In unserem Guide erfährst du, wie du sichere Entwicklungsumgebungen aufsetzt und verdächtige Aktivitäten in CI/CD-Pipelines erkennst.