Wie sich eine Backdoor in einem LinkedIn-Jobangebot versteckte

Markus Seyfferth
Autor Dr. Web
3 Min. Lesezeit
Wie eine Backdoor in einem LinkedIn-Jobangebot steckte

Ein gefälschtes LinkedIn-Jobangebot kann längst mehr kosten als verlorene Zeit, nämlich die Kontrolle über den eigenen Rechner. Der Entwickler Roman Imankulov hat einen solchen Fall öffentlich gemacht. Hinter einer harmlos wirkenden Programmieraufgabe steckte eine Backdoor, die sich nach der Installation von selbst startete.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Waren Sie schon einmal in dieser Situation? Ein Recruiter meldet sich mit einem attraktiven Angebot, schickt eine Aufgabe und bittet um einen kurzen Coding-Test. Genau dieser Ablauf wird gerade zur Falle.

Das Wichtigste in Kürze

  • Ein angebliches Krypto-Startup lockte den Entwickler mit einem Jobangebot und einer Coding-Aufgabe auf GitHub.
  • Die Backdoor versteckte sich in einer Testdatei, getarnt zwischen auskommentierten Tests.
  • Ein prepare-Skript in der package.json führte den Schadcode automatisch nach dem npm install aus.
  • Sicherheitsforscher ordnen die Masche der Kampagne Contagious Interview zu.

Echte Identität gestohlen. Der Recruiter trat unter dem Namen einer realen Kunstjournalistin auf, die mit Technik nichts zu tun hatte. Die 39 Commits im Projekt liefen auf den Namen eines echten Full-Stack-Entwicklers, der jede Zusammenarbeit bestritt und angab, auf GitHub schon mehrfach so missbraucht worden zu sein. Diese geliehene Glaubwürdigkeit ist der eigentliche Köder.

Wie tarnte sich die Backdoor im Coding-Test?

Holzpferd mit „Traumjob“-Anhänger, offener Klappe und kleinem Besen auf einer Matte vor weiß
Schadcode in Testsuite versteckt: Zeile 225 der Datei app/test/index.js enthielt gefährlichen Code zwischen auskommentierten Tests, der durch das Testmodul automatisch ausgeführt wurde

Der Schadcode lag in der Datei app/test/index.js, auf Zeile 225, mitten zwischen auskommentierten Tests. Auf rund 250 Zeilen sah alles nach einer gewöhnlichen Testsuite aus, sodass der gefährliche Teil schlicht in der Masse unterging.

Selbstläufer. Die Hauptdatei app/index.js band das Testmodul ein und führte den versteckten Code damit aus. In der package.json sorgte ein prepare-Skript dafür, dass node app/index.js automatisch nach jedem npm install lief. Die Aufforderung, ein Problem mit veralteten Node-Modulen zu prüfen, war nur der Vorwand, denn genau das verleitet zum npm install. So entstand eine klassische Hintertür für Schadcode aus zweiter Hand.

Ferngesteuert. Der Code setzte aus einzelnen Fragmenten die Adresse rest-icon-handler.store zusammen, lud von dort Befehle nach und führte alles aus, was dieser Server zurückschickte. Damit hatten die Angreifer eine offene Fernsteuerung auf dem Entwicklerrechner, mit Zugriff auf Quellcode, Zugangsdaten und alles, was lokal erreichbar war.

Steckt hinter dem Jobangebot ein bekanntes Muster?

Ja, der Fall ist kein Einzelfall, sondern Teil der Kampagne Contagious Interview, die Sicherheitsforscher der nordkoreanischen Lazarus-Gruppe zuschreiben. Das Drehbuch wiederholt sich seit Jahren mit erschreckender Verlässlichkeit.

Der Ablauf gleicht sich jedes Mal: Auf ein Jobangebot folgt eine Programmieraufgabe per GitHub, danach schleust ein Infostealer wie BeaverTail Browser-Logins und Krypto-Wallets aus, bevor der Python-Trojaner InvisibleFerret einen dauerhaften Fernzugriff einrichtet. Die npm-Lifecycle-Skripte sind dabei das Einfallstor, weil sie Code ohne Zutun ausführen. Wie professionell solche Angreifer heute vorgehen, zeigt auch unsere CISO-Studie zu Angriffen übers Endgerät.

Ein Jobangebot ist heute ein Angriffsvektor wie eine Phishing-Mail. Fremder Code auf der eigenen Maschine öffnet die Tür, und blindes Vertrauen ersetzt keine Sandbox.

— Michael Dobler, Herausgeber Dr. Web

Wie schützen sich Entwickler und Mittelstand?

Ein grüner Schlauch mit einer kleinen, offenen Holztür in einer Messingkupplung
Fremden Code nur in isolierten Umgebungen wie Wegwerf-VMs oder Containern ausführen. BSI warnt vor Social Engineering beim Recruiting

Fremden Code niemals ungeprüft auf dem Arbeitsrechner ausführen, das ist die wichtigste Regel. Das BSI warnt seit Längerem vor Social Engineering über Recruiting, und die Schutzmaßnahmen sind technisch simpel.

Setzen Sie unbekannte Projekte grundsätzlich in einer isolierten Umgebung auf, etwa in einer Wegwerf-VM oder einem Container ohne Zugriff auf echte Zugangsdaten. Deaktivieren Sie automatische Skripte mit npm install –ignore-scripts, bevor Sie ein fremdes Repository das erste Mal installieren. Prüfen Sie zudem Recruiter und Auftraggeber über einen zweiten Kanal, weil eine gestohlene Identität auf den ersten Blick echt wirkt. Die Grundlagen dazu fasst unser Ratgeber zu den Cybersecurity-Grundlagen für KMU zusammen.

Den größten Hebel hat ohnehin die Routine. Behandeln Sie jede Coding-Aufgabe aus einer Kaltakquise wie eine verdächtige E-Mail-Anlage, dann bleibt der vermeintliche Traumjob ein überschaubares Risiko.

Mehr Newshunger?

4,1 20 Bewertungen

Wie hat Ihnen dieser Artikel gefallen?

Empfohlene Artikel
Markus Seyfferth
Autor
ist seit 2019 geschäftsführender Gesellschafter von Dr. Web. Er verantwortet die redaktionelle Ausrichtung des Dr. Web Magazins und bringt seine Expertise in den Bereichen Webdesign, Webentwicklung, WordPress, SEO sowie Online Marketing ein. Zudem verfasst er regelmäßig Fachartikel, um sein Wissen und seine Erfahrungen zu teilen und anderen im Online Marketing weiterzuhelfen.
857 Artikel veröffentlicht
Alle Artikel

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Newsletter

Mehr solcher Artikel?
Jetzt kostenlos abonnieren.

Jeden Dienstag die besten Artikel aus dem Dr. Web-Magazin direkt in Ihr Postfach – kein Spam, jederzeit abmeldbar.

Einmal pro Woche, kein täglicher Spam
Jederzeit mit einem Klick abmeldbar
DSGVO-konform via Brevo