Vermeintliches Jobangebot im ZIP: Git als Code-Starter

Ein vermeintliches Jobangebot enthielt ein fertig präpariertes Git-Repository, in dem bereits eine Statusabfrage einen Downloader starten konnte. Das beschreibt der Entwickler Evgeny Igumnov in einem am 13. November 2026 veröffentlichten Beitrag. Der entscheidende Bestandteil lag im mitgelieferten .git-Verzeichnis: Lokale Einstellungen verbanden gewöhnliche Git-Befehle mit einem versteckten Skript. Ob dieses beim Empfänger tatsächlich lief und welchen Code es gegebenenfalls nachlud, ist nicht belegt.

Nach Igumnovs Darstellung begann der Kontakt auf LinkedIn. Eine Person trat als Recruiter der angeblichen Firma Cryptic Heaven auf und verwies auf ein angeblich in Entwicklung befindliches Finanzsystem für Nutzer von Krypto-Kreditkarten. Vertrag, Stellenbeschreibung und Projekt sollten über einen Link zugänglich sein. Dieser lieferte ein Archiv namens Contract-2026.zip aus. Wer hinter der Kontaktaufnahme und der genannten Firma steht, bleibt ungeklärt. (Habr: Как мне прислали предложение о работе, а внутри ZIP спрятали запуск вредоносного кода через Git (Evgeny Igumnov))

Das Archiv lieferte die lokale Git-Umgebung gleich mit

Im ZIP lagen README.md, contract.docx und ein vollständiges .git-Verzeichnis mit Historie, mehreren Branches und lokalen Einstellungen. Die Anleitung gab eine Reihenfolge vor: Auf dem Branch doc liege der Kooperationsvertrag, auf job die Stellenbeschreibung und auf codebase der Quellcode. Der Empfänger sollte also Git benutzen, um die angebotenen Unterlagen durchzusehen.

Inhaltlich waren diese dünn. Der Vertrag bestand laut Bericht aus einer Vorlage mit leeren Feldern; juristische Person, Vergütung und Gerichtsbarkeit fehlten. Auch die Stellenbeschreibung für einen Smart Contract Developer enthielt zahlreiche Leerstellen. Die technische Vorbereitung des Repositorys war dagegen konkret.

Das ZIP-Format war dafür wesentlich. Bei einem gewöhnlichen git clone werden die lokale .git/config und ausführbare lokale Hooks des Quell-Repositorys nicht mitkopiert. Hier kamen die Einstellungen und Skripte bereits gemeinsam beim Empfänger an. Das Archiv transportierte damit auch eine vorbereitete Ausführungsumgebung für Git. Das bloße Entpacken ist im beschriebenen Ablauf allerdings noch kein belegter Auslöser.

Warum selbst git status den Downloader erreichen konnte

Der erste Teil der Konstruktion steckte in .git/config. Dort war core.hooksPath auf .git/objects/interrupt/ gesetzt. Git sollte seine Hooks damit aus einem Unterordner des Objektspeichers laden, statt aus dem üblichen Verzeichnis .git/hooks. Wer nur dort nach auffälligen Skripten gesucht hätte, hätte diesen Hook übersehen.

Im umgeleiteten Verzeichnis lag ein post-checkout-Hook. Sein Inhalt wirkte unscheinbar: Auf die Interpreterzeile #!/bin/sh folgte lediglich git status. Dieser Befehl prüft normalerweise den Zustand des Arbeitsverzeichnisses. In diesem Repository führte er jedoch zum zweiten Teil der Konstruktion.

Dieselbe Konfiguration definierte einen Filter namens ltr mit der Einstellung clean = .git/ltr. Die Datei .git/info/attributes ordnete diesen Filter über den Eintrag * filter=ltr allen Dateien zu. Solche Filter sind reguläre Git-Funktionen, mit denen sich Dateiinhalte beim Übergang zwischen Arbeitsverzeichnis und Git-Speicher umwandeln lassen. Auch eine Statusprüfung kann den clean-Filter aufrufen, um Änderungen am Dateiinhalt zu ermitteln.

Damit ergaben sich zwei Zugänge zum Nachlader: Ein git status konnte den Filter direkt erreichen. Ein Branchwechsel konnte zusätzlich den post-checkout-Hook starten, der seinerseits git status ausführte. Igumnov überprüfte dieses Verhalten in einem separaten Testrepository mit einem harmlosen Skript, das seine Aufrufe lediglich protokollierte. Dieser Test stützt den beschriebenen Mechanismus, belegt aber keine Ausführung des schädlichen Skripts beim Empfänger. (Habr: Как мне прислали предложение о работе, а внутри ZIP спрятали запуск вредоносного кода через Git (Evgeny Igumnov))

Der Nachlader sollte möglichst wenig auffallen

Das Skript .git/ltr enthielt eine zeitliche Koordination. Es schrieb Zeitstempel in .git/.clean_filter_last und nutzte .git/.clean_filter_watch.lock als Sperre. Erst wenn seit dem letzten Filteraufruf mindestens zwei Sekunden vergangen waren, sollte es weitergehen. Die Logik sollte verhindern, dass mehrere parallele Aufrufe den Download mehrfach anstoßen.

Anschließend wertete das Skript die Variable OSTYPE aus. Für darwin* und linux* sollte curl eine Datei von vercelscript.vercel.app laden und an sh übergeben. Für msys* und cygwin* war ein Pfad mit curl.exe und PowerShell vorgesehen; ein Standardzweig verwendete ebenfalls curl und sh. Die Konstruktion zielte damit auf mehrere Betriebssystemumgebungen.

Windows bietet gegen ein Shell-Skript dieser Art keinen grundsätzlichen Schutz: Git for Windows bringt eine Unix-Umgebung mit sh.exe und Bash mit, die Git zum Skriptaufruf nutzen kann. Dafür muss der Anwender nicht eigens ein Git-Bash-Fenster öffnen.

Ausgaben und Fehler des Hintergrundprozesses wurden nach /dev/null umgeleitet. Am Ende stand cat: Der Filter gab die empfangenen Dateidaten unverändert zurück. So konnte er für Git weiterhin wie ein funktionierender Inhaltsfilter erscheinen, während der Download im Hintergrund vorgesehen war.

Die riskante Grenze liegt vor dem ersten Git-Aufruf

Der Bericht nennt neben dem angeleiteten git checkout job auch weniger bewusste Auslöser. Eine Shell-Eingabeaufforderung könnte für ihre Branchanzeige git status aufrufen. Ebenso könnte die Git-Erweiterung von Visual Studio Code nach der Repository-Erkennung eine Statusprüfung anstoßen. Das Öffnen der README im Editor garantiert die Ausführung jedoch nicht: Editor-Einstellungen, Workspace-Vertrauen und Repository-Erkennung beeinflussen diesen Weg.

Für den Umgang mit fremden Projektarchiven folgt daraus eine konkrete Vorsichtsmaßnahme: Ein mitgeliefertes .git-Verzeichnis sollte vor der Nutzung als nicht vertrauenswürdige Konfiguration behandelt werden. Gerade git status eignet sich hier nicht als vermeintlich harmlose Erstprüfung. Sinnvoll ist zunächst eine Sichtung der Konfigurations- und Skriptdateien ohne Git-Aufruf, ohne automatische Repository-Integration und ohne Ausführung des Projekts. Muss das vollständige Repository untersucht werden, ist eine isolierte Umgebung ohne Zugangsdaten und mit kontrolliertem Netzwerkzugang die vorsichtigere Wahl.

Wer das Archiv bereits mit Entwicklungswerkzeugen geöffnet hat, sollte zwischen Fund und Ausführung unterscheiden. Die vorhandenen Dateien belegen die vorbereitete Downloadkette. Für die Bewertung eines möglichen Vorfalls ist zusätzlich entscheidend, ob der Filter tatsächlich lief und was der entfernte Server zu diesem Zeitpunkt auslieferte. Aus dem ZIP allein lässt sich diese zweite Stufe nicht bestimmen.