GitHub: Repository-Exfiltration und Massen-Klonen erkennen

Kurz gesagt. Quellcode verlässt GitHub auf fünf Wegen: über git.clone/git.fetch, über repo.download_zip, indem ein Repository öffentlich gemacht wird (repo.access), indem es übertragen wird (repo.transfer*) oder indem es in ein persönliches Konto geforkt wird. Die ersten beiden setzen Git-Events bzw. Archiv-Ereignisse voraus. Für Klonvorgänge heißt das: Enterprise Cloud und ein Aufbewahrungsfenster von 7 Tagen. Das gesuchte Muster ist ein Akteur oder Token, der viele verschiedene Repositories innerhalb einer Stunde von einer einzigen IP-Adresse abruft. Sehen Sie dieses Muster, behandeln Sie jedes Secret in der Historie dieser Repositories als geleakt.

Die Frage „Was haben sie mitgenommen?“ folgt direkt auf „Wie sind sie hereingekommen?“. Sie entscheidet, ob Sie es mit einem Datenleck, einem Erpressungsversuch oder einem Supply-Chain-Risiko zu tun haben (gestohlener Code legt Ihre Infrastruktur offen und enthält oft Zugangsdaten). Diebstahl von Repositories in großem Stil ist ein reales Muster. Im Mai 2026 meldete GitHub selbst unbefugten Zugriff auf seine internen Repositories, nachdem das Gerät eines Mitarbeiters über eine manipulierte VS-Code-Erweiterung eines Drittanbieters kompromittiert worden war.

Die fünf Exfiltrationswege und ihre Spuren

ATT&CK ordnet die ersten beiden Wege T1213.003 Data from Information Repositories: Code Repositories zu. Ein Repository öffentlich zu machen entspricht T1567 Exfiltration Over Web Service, eine Übertragung T1537 Transfer Data to Cloud Account.

Massen-Klonen: git.clone lesen

GitHub beschreibt git.clone als das Klonen eines Repositorys und weist darauf hin, dass das Ereignis in der Weboberfläche nicht verfügbar ist, sondern nur über die REST-API, Streaming oder Exporte. Ein Klon-Ereignis liefert Ihnen den Akteur, das Repository (repository, repository_public), den Zeitpunkt, das Transportprotokoll (transport_protocol_name: http oder ssh) und, sofern vorhanden, actor_ip, Land, User-Agent sowie den hashed_token der verwendeten Zugangsdaten.

So sieht Normalbetrieb aus: Ein Entwickler klont eine Handvoll Repositories, an denen er arbeitet, von seiner üblichen IP-Adresse und mit seinem üblichen User-Agent git/2.x. CI-Systeme rufen immer wieder dieselben Repositories ab.

So sieht Diebstahl aus:

• Breite. Viele verschiedene Repositories, auch solche, in die der Akteur nie gepusht hat.
• Tempo. Klonvorgänge im Sekundenabstand – das ist ein Skript, kein Mensch.
• Herkunft. Eine IP-Adresse, die der Akteur nie benutzt hat, oft bei einem Hosting-Anbieter, in einem für das Token neuen Land.
• Zugangsdaten. Derselbe hashed_token, den der Entwickler verwendet, aber ein anderer User-Agent.

Die Regel git-clone-burst des Analyzers gruppiert git.clone nach Akteur und IP-Adresse und schlägt bei 10 verschiedenen Repositories innerhalb von 60 Minuten an. Dieser Schwellenwert ist bewusst konservativ gewählt. Ein neuer Mitarbeiter, der am ersten Tag das Monorepo und seine Satelliten klont, kann ihn auslösen. Deshalb listet der Befund die Repositories und die IP-Adresse auf, damit Sie schnell entscheiden können.

Wenn es keine Git-Events gibt

Ohne Git-Events weist der Analyzer in seinen Hinweisen zur Abdeckung darauf hin („Die Erkennung von Massen-Klonen ist blind“). Das ist unter GitHub Free und Team der Normalfall, weil dort weder die API noch Git-Events verfügbar sind. Ihre Optionen:

• Prüfen Sie repo.download_zip im regulären Log. Archiv-Downloads werden dort protokolliert.
• Nutzen Sie die Seite Traffic des Repositorys. Jeder mit Push-Zugriff sieht dort vollständige Klonvorgänge der letzten 14 Tage, allerdings nur als aggregierte Zahlen ohne Akteur oder IP-Adresse. Siehe Viewing traffic to a repository.
• Behandeln Sie alles, was die gestohlenen Zugangsdaten lesen konnten, als offengelegt. Das ist die einzige vertretbare Annahme.

Archiv-Downloads

repo.download_zip protokolliert, dass ein Quellcode-Archiv eines Repositorys als ZIP-Datei heruntergeladen wurde. Das ist eine unauffälligere Alternative zu git clone: kein Git-Client, ein normaler Browser- oder curl-User-Agent, und das Ereignis erscheint im regulären Audit-Log. archive-download-burst schlägt bei 5 verschiedenen Repositories innerhalb einer Stunde für einen Akteur an. Archive enthalten keine Git-Historie, was die Beute des Angreifers etwas einschränkt: Secrets, die in späteren Commits gelöscht wurden, stehen nicht in einem ZIP des aktuellen Stands.

Öffentlich gemachte oder übertragene Repositories

Diese Wege sind laut, doch Angreifer nutzen sie für Erpressung und für Aktionen nach dem Muster „leaken und verschwinden“:

• repo.access mit visibility: public: Privater Code ist innerhalb von Sekunden für jeden herunterladbar. Selbst wenn Sie die Änderung schnell zurücknehmen, sollten Sie davon ausgehen, dass er gespiegelt wurde.
• repo.transfer_start / repo.transfer / repo.transfer_outgoing: Repository, Issues und Historie gehen an einen anderen Inhaber über.
• repo.destroy in großer Zahl (drei oder mehr innerhalb einer Stunde lösen repo-mass-delete aus) geht oft mit einer Lösegeldforderung einher. Ein gelöschtes Repository lässt sich in der Regel innerhalb von 90 Tagen wiederherstellen (für Fork-Netzwerke gibt es Ausnahmen). Prüfen Sie das, bevor Sie mit irgendjemandem verhandeln.

Umfang bestimmen: von „geklont“ zu „offengelegt“

Sobald Sie die Liste der Repositories haben, geht es nicht mehr um Erkennung, sondern um die Auswirkungen:

1. Exportieren Sie die Liste (im Analyzer über die Entitäten des Befunds oder über Ereignisse, gefiltert auf git.clone und die IP-Adresse des Angreifers → Ereignisse CSV).
2. Durchsuchen Sie die gesamte Historie jedes Repositorys nach Secrets, einschließlich gelöschter Dateien und alter Commits. Der Angreifer hat die Historie ebenfalls.
3. Rotieren Sie alle gefundenen Zugangsdaten, beginnend mit Cloud-Schlüsseln und Datenbank-Verbindungszeichenfolgen. Handelt es sich um Cloud-Schlüssel, fahren Sie mit dem Weg in die Cloud fort.
4. Erfassen Sie das Wissen über Ihre Infrastruktur. Terraform, Helm-Charts und CI-Vorlagen zeigen dem Angreifer Ihr Netzwerk. Prüfen Sie, was sie preisgeben.
5. Bereiten Sie sich auf Offenlegung und Erpressung vor. Rechtliche und kommunikative Entscheidungen hängen davon ab, was der Code enthielt (Kundendaten in Fixtures, lizenzierten Code, sicherheitskritische Komponenten).

Vorbeugen und früher erkennen

• Streamen Sie das Audit-Log (Enterprise Cloud), damit Git-Events das Sieben-Tage-Fenster überdauern. Siehe Audit-Log-Streaming.
• Aktivieren Sie die IP-Anzeige und eine IP-Zulassungsliste. Klonversuche von einem VPS schlagen dann fehl, statt zu gelingen.
• Lassen Sie die Richtlinie für das Forken privater Repositories deaktiviert und alarmieren Sie bei private_repository_forking.enable.
• Halten Sie Secrets aus Repositories heraus: Aktivieren Sie Secret Scanning und Push-Schutz. Der Analyzer markiert secret_scanning_push_protection.bypass.

FAQ

Kann ich sehen, wer mein privates GitHub-Repository geklont hat?

In einer Organisation unter GitHub Enterprise Cloud ja: Ereignisse vom Typ git.clone protokollieren Akteur, Repository, Zeitpunkt und (bei aktivierter IP-Anzeige) die Quell-IP-Adresse und den Token-Hash. Sie werden sieben Tage aufbewahrt und sind nicht im Export aus der Weboberfläche enthalten. In anderen Plänen liefert das Audit-Log keine Einträge pro Klonvorgang.

Verwandte Artikel

• GitHub-Token geleakt: Sofortmaßnahmen und Untersuchung
• GitHub-Audit-Log exportieren: der Abschnitt zu Git-Events
• Die fiktive Fallstudie northwind-labs: 38 Repositories, von einem VPS aus geklont
• Glossar: Git-Events