Jobangebot als Falle: Wie Git-Hooks Schadcode starten können
Ein vermeintlicher Arbeitgeber schickt ein Projekt zur Durchsicht. Der Quellcode kommt als Repository oder ZIP-Archiv, die Aufgabe passt zum Bewerbungsprozess. Dieses Vertrauen nutzen Angreifer, um Malware auf Entwicklerrechner zu bringen. Die praktische Konsequenz: Ein fremdes Bewerbungsprojekt gehört in eine isolierte Testumgebung, bevor man damit arbeitet. Erst beim Installieren von Abhängigkeiten vorsichtig zu werden, kann zu spät sein.
Eine Falle sind Git-Hooks. Darin können Skripte stecken, die bei bestimmten Git-Aktionen ausgeführt werden. Unter passenden Bedingungen reicht dann bereits ein Branch-Wechsel, um weiteren Schadcode herunterzuladen. Der gefährliche Schritt muss also nicht wie das bewusste Starten eines fremden Programms aussehen.
Die Coding-Aufgabe schafft den Anlass
Gefälschte Coding-Interviews sind als Verbreitungsweg für Malware dokumentiert. Sicherheitsberichte beschrieben unter anderem eine Nordkorea zugeschriebene Kampagne mit manipulierten Repositories, die auf sensible Dateien und Anmeldeinformationen zielte. Einzelne Prüfergebnisse aus solchen Berichten sind Momentaufnahmen und sagen nicht zuverlässig aus, ob spätere Schutzprogramme dieselben Dateien erkennen.
Das zeigt die Grenze eines einzelnen Prüfergebnisses: Keine Erkennung ist kein belastbarer Nachweis dafür, dass ein Projekt ungefährlich ist. Wer eine Coding-Aufgabe auf dem eigenen Arbeitsrechner startet, sollte diese Entscheidung nicht allein von einem unauffälligen Virenscan abhängig machen.
Der Bewerbungsprozess liefert den Angreifern einen plausiblen Anlass für den Umgang mit fremdem Code. Ein Projekt zu prüfen oder eine Aufgabe darin zu bearbeiten, passt zu einem technischen Auswahlverfahren. Deshalb muss die Sicherheitsgrenze vor der Bearbeitung liegen. Dass eine Aufgabe beruflich sinnvoll wirkt, sagt nichts über die Sicherheit der Dateien aus.
Warum ein Branch-Wechsel riskant werden kann
Git-Hooks sind Skripte, die an bestimmte Vorgänge in Git gekoppelt werden können. Schadcode kann in Dateien unter .git/hooks versteckt sein. Wird ein entsprechender Hook beim Wechseln eines Branches ausgeführt, kann er weiteren Schadcode nachladen und starten.
Dabei ist die Einschränkung wichtig: Nicht jedes Repository führt beim Branch-Wechsel Malware aus. Entscheidend sind ein vorhandener, ausführbarer Hook und die Bedingungen, unter denen Git ihn aufruft. Auch das bloße Vorhandensein eines ZIP-Archivs bedeutet noch keine Infektion. Problematisch wird die weitere Arbeit mit einem präparierten Projekt.
Für die Prüfung reicht deshalb der Blick auf die offensichtlichen Programmdateien nicht aus. Auch mitgelieferte Git-Metadaten gehören zur Sicherheitsbetrachtung. Wer nur nach einem auffälligen Installationsskript sucht, erfasst diesen Ausführungsweg nicht. Die Annahme „Ich schaue mir nur kurz die Branches an“ ist bei einem unbekannten Projekt keine verlässliche Schutzmaßnahme.
Die Testumgebung muss vor dem ersten Versuch stehen
Unbekannter Bewerbungscode sollte in einer isolierten Umgebung untersucht werden, nicht direkt auf dem Hauptsystem. Diese Umgebung muss bereitstehen, bevor Git-Aktionen, Installation oder Tests beginnen. Sie erst nach einem verdächtigen Verhalten einzurichten, schützt den zuvor benutzten Rechner nicht.
Zur Isolation gehört eine klare Trennung von persönlichen und beruflichen Zugängen. Eine Testumgebung, in der dieselben sensiblen Dateien und Anmeldeinformationen verfügbar sind wie auf dem Arbeitsrechner, verfehlt den Zweck. Die Empfehlung lautet deshalb: nur die für die Prüfung benötigten Inhalte bereitstellen und keine produktiven Zugangsdaten mitnehmen.
Das passt zum möglichen Schaden. Bei solchen Angriffen können unter anderem Browserdaten, Passwörter, Dateien und Kryptowährungs-Wallets gestohlen werden. Auch Systeminformationen, Telegram-Daten und Discord-Token gehören zu den dokumentierten Zielen. Es geht also um mehr als ein beschädigtes Testprojekt. Die erreichbaren Daten bestimmen, wie weit ein erfolgreicher Angriff reicht.
Ein glaubwürdiger Auftritt ersetzt keine Trennung
Auch ein Repository auf einer bekannten Plattform ist kein Sicherheitsnachweis. Sicherheitsberichte beschrieben außerdem Kampagnen mit zahlreichen gefälschten GitHub-Repositories, die vertrauenswürdige Softwareanbieter imitierten und Infostealer verbreiteten. Solche Kampagnen sind von gefälschten Coding-Interviews zu unterscheiden. Sie zeigen aber, dass ein vertrauter Anbietername als Tarnung dienen kann.
Im Bewerbungsprozess sollten daher zwei Prüfungen getrennt bleiben: Ist der Kontakt plausibel? Und lässt sich das zugesandte Projekt sicher untersuchen? Eine überzeugende Antwort auf die erste Frage macht die zweite nicht überflüssig. Ein vermeintlich seriöses Jobangebot darf keine Ausnahme von den Regeln für unbekannten Code schaffen.
Auch Unternehmen können ihren technischen Auswahlprozess daran ausrichten. Klare Aufgaben und die Möglichkeit, sie ohne produktive Zugänge in einer isolierten Umgebung zu bearbeiten, vermeiden unnötige Risiken. Für Bewerber bleibt die Grenze konkret: Fremder Code erhält keinen direkten Zugriff auf den Rechner, auf dem die eigene Arbeit und die eigenen Konten liegen.
