Exfiltration zu Code-Repositories erkennen: Datenabfluss per git push

Mit der Exfiltration verlassen die Daten das Netz - und Angreifer bevorzugen Wege, die im Rauschen des Alltags untergehen. Code-Hoster sind dafür ideal: Der Verkehr zu GitHub oder GitLab ist in Entwicklungsumgebungen normal und wird selten blockiert. Was die automatisierte Sammlung zusammengetragen und die Archivierung verpackt hat, lässt sich so als scheinbar harmloser git push nach draußen bringen. Dieser Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite; den Abfluss im Überblick behandelt der Beitrag zu Datenabfluss erkennen.

Was der Angreifer tut

Der Abfluss über einen Code-Hoster läuft auf der Ebene des Prinzips, nicht als Anleitung, in wenigen Schritten ab:

• Ziel-Repository anlegen. Auf einem öffentlichen Hoster entsteht ein - oft privates - Repository, das als Ablageort dient.
• Remote verknüpfen. Auf dem Opfer-System wird das Repository per git remote add als externe Remote eingetragen oder direkt als URL angesprochen.
• Daten pushen. Die gesammelten und oft archivierten Dateien werden per git push oder über die API des Hosters hochgeladen.
• Im Rauschen verstecken. Weil Git-Verkehr zu GitHub und GitLab alltäglich ist, fällt der Abfluss am Perimeter kaum auf.

Für die Erkennung ist entscheidend: Jeder dieser Schritte läuft über ein Werkzeug mit sichtbarer Kommandozeile - git, die GitHub-CLI oder ein Transferwerkzeug - und nennt die Zieladresse im Klartext. Genau daran setzen die Regeln an.

Welche Logquellen die Technik zeigt

• Prozess-Telemetrie. Event 4688 und Sysmon Event 1 zeigen git, gh, curl oder PowerShell samt Kommandozeile im Klartext - mit remote add, push und der Zieladresse. Die wichtigste Quelle.
• Netzwerk- und Proxy-Logs. Der ausgehende Verkehr zu github.com, gitlab.com oder deren API-Hosts zeigt Ziel und Volumen; ein großer Push an einen privaten Account fällt hier auf.
• Werkzeug-Kontext. git, gh und curl sind legitime Werkzeuge; Grundlagen zu ihrem Missbrauch stehen unter Living off the Land.
• Kontext statt Einzelzeile. Exfiltration folgt auf Sammeln und Archivieren; Grundlagen zur Endpunkt-Telemetrie unter Sysmon einrichten.

Das Muster im Log

Das klarste Signal ist ein git remote add auf einen öffentlichen Hoster, das kurz vor einem Push auftaucht - die Vorbereitung des Ablageorts. Das zweite Signal ist ein git push, der eine vollständige https-URL in der Kommandozeile trägt, statt eine eingerichtete Remote zu nutzen. Das dritte ist ein Transferwerkzeug wie curl oder die GitHub-CLI, das eine API- oder Gist-Adresse anspricht. Legitime Treffer stammen von Entwicklern und CI-Jobs auf bekannten Hosts. Auffällig wird es, wenn Git-Aktivität von einem System ausgeht, auf dem sonst nicht entwickelt wird, oder aus einem Dienstkonto heraus. Der Blick auf Werkzeug, Zieladresse und Kontext trennt den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Wege: die externe Remote, den direkten Push an eine URL und den Upload über ein Transferwerkzeug. Die dritte ist die spezifischste.

1. Externe Git-Remote hinzugefügt (T1567.001). git remote add auf GitHub, GitLab oder Bitbucket. Die Regel steht auf level: medium.

title: Externe Git-Remote hinzugefuegt
id: 82505755-bfe9-4496-9726-b51b498c7d37
status: experimental
description: |
  Erkennt das Hinzufuegen einer externen Git-Remote auf einen oeffentlichen Code-Hoster wie GitHub,
  GitLab oder Bitbucket. Vor dem Abzug legt ein Angreifer ein Ziel-Repository an und verknuepft es als
  Remote, um die gesammelten Daten anschliessend dorthin zu pushen. Ein git remote add auf einen
  externen Hoster ist der vorbereitende Schritt dieser Exfiltration.
references:
  - https://attack.mitre.org/techniques/T1567/001/
author: blue-team.net
tags:
  - attack.exfiltration
  - attack.t1567.001
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\git.exe'
  sel_cmd:
    CommandLine|contains: 'remote add'
  sel_host:
    CommandLine|contains:
      - 'github.com'
      - 'gitlab.com'
      - 'bitbucket.org'
  condition: sel_img and sel_cmd and sel_host
falsepositives:
  - Entwickler, die legitim ein externes Repository als Remote einrichten - bekannte Entwickler-Hosts und Konten als Baseline ausnehmen
level: medium

2. Direkter Git-Push an eine URL (T1567.001). git push mit einer vollständigen https-Adresse in der Kommandozeile. Die Regel steht auf level: medium.

title: Direkter Git-Push an eine URL
id: aecfa41c-0493-4922-9c00-ea628ad8ec84
status: experimental
description: |
  Erkennt einen Git-Push, der direkt an eine URL gerichtet ist, statt an eine benannte Remote. Ein
  Push mit einer vollstaendigen https-Adresse in der Kommandozeile umgeht die eingerichteten Remotes
  und ist ein ungewoehnlicher Weg, Daten an ein externes Repository zu schicken. In Verbindung mit der
  Exfiltration zu Code-Repositories ist das ein deutliches Signal.
references:
  - https://attack.mitre.org/techniques/T1567/001/
author: blue-team.net
tags:
  - attack.exfiltration
  - attack.t1567.001
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\git.exe'
  sel_push:
    CommandLine|contains: 'push'
  sel_url:
    CommandLine|contains: 'https://'
  condition: sel_img and sel_push and sel_url
falsepositives:
  - Automatisierte CI- und Deployment-Jobs, die direkt an eine URL pushen - bekannte Jobs und Konten als Baseline ausnehmen
level: medium

3. Upload zu einem Code-Repository-Dienst (T1567.001). curl, PowerShell oder die GitHub-CLI mit einer API- oder Gist-Adresse. Die Regel steht auf level: high.

title: Upload zu einem Code-Repository-Dienst per Transferwerkzeug
id: aeb5d5d3-86d7-4000-b224-5f8cd0fabd7c
status: experimental
description: |
  Erkennt den Upload zu einem Code-Repository-Dienst ueber ein Transferwerkzeug - curl, PowerShell
  oder die GitHub-CLI, die eine API- oder Gist-Adresse von GitHub oder GitLab ansprechen. Angreifer
  nutzen diese Dienste als unauffaelligen Ablageort, weil der Datenverkehr zu bekannten
  Entwicklerplattformen selten blockiert wird. Ein Transferwerkzeug mit einer solchen Zieladresse ist
  ein deutliches Signal der Web-Service-Exfiltration.
references:
  - https://attack.mitre.org/techniques/T1567/001/
author: blue-team.net
tags:
  - attack.exfiltration
  - attack.t1567.001
logsource:
  product: windows
  category: process_creation
detection:
  sel_tool:
    Image|endswith:
      - '\curl.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\gh.exe'
  sel_dest:
    CommandLine|contains:
      - 'api.github.com'
      - 'uploads.github.com'
      - 'gist.github.com'
      - 'gitlab.com/api'
      - 'gh gist'
      - 'gh release upload'
  condition: sel_tool and sel_dest
falsepositives:
  - Legitime Automatisierung, die ueber die GitHub- oder GitLab-API arbeitet - bekannte Skripte und Konten als Baseline ausnehmen
level: high

Härtung: der Angriff, der ins Leere läuft

• Ausgehend filtern. Den Zugriff auf Code-Hoster am Proxy auf die Konten und Systeme begrenzen, die ihn wirklich brauchen - Arbeitsplätze ohne Entwicklung müssen GitHub nicht erreichen.
• Werkzeuge einschränken. Per Anwendungssteuerung festlegen, wer git, die GitHub-CLI und curl ausführen darf.
• PowerShell härten. Script Block Logging und Constrained Language Mode machen API-Uploads per Invoke-RestMethod sichtbar und auswertbar.
• DLP am Ausgang. Große oder archivierte Uploads zu externen Diensten erkennen und zurückhalten, bevor sie das Netz verlassen.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem isolierten System mit aktivem Sysmon und einem Test-Repository:

• Für Regel 1 mit git remote add backup https://github.com/test/test.git eine externe Remote eintragen. In Event 4688 muss git mit remote add und dem Hoster erscheinen.
• Für Regel 2 einen git push https://github.com/test/test.git ausführen und den Eintrag in der Prozess-Telemetrie prüfen.
• Für Regel 3 mit curl oder Invoke-RestMethod eine harmlose Datei an api.github.com senden und das Erscheinen in Event 1 bzw. im Script Block Logging kontrollieren.
• Breiter wird der Test mit den Fällen zu T1567 aus Atomic Red Team.

Fehlalarme und Tuning

• Entwickler und CI. git push, remote add und API-Aufrufe gehören zum Alltag der Entwicklung. Bekannte Entwickler-Hosts, CI-Konten und Skripte als Baseline ausnehmen.
• Ort entscheidet. Git-Aktivität von einem Nicht-Entwickler-System oder aus einem Dienstkonto heraus wiegt deutlich schwerer - nach Kontext priorisieren.
• API-Upload ist spezifisch. Ein Transferwerkzeug mit einer api.github.com- oder Gist-Adresse hat außerhalb bewusster Automatisierung selten einen Grund - diese Treffer hochpriorisieren.
• Kette schlägt Einzelzeile. Sammeln, Archivieren und folgender Push zusammen betrachtet sind aussagekräftiger als ein Git-Aufruf allein - die Korrelation schärft die Bewertung.

Fazit

Exfiltration zu Code-Repositories nutzt erlaubte Entwicklerdienste als unauffälligen Ausgang: externes Repository anlegen, Remote verknüpfen, Daten per git push oder API hochladen. Die verlässlichen Signale sind ein git remote add auf einen öffentlichen Hoster, ein Push an eine vollständige URL und ein Transferwerkzeug, das die GitHub- oder GitLab-API anspricht. Die wirksamste Härtung filtert den ausgehenden Zugriff, schränkt die Werkzeuge ein und setzt DLP am Ausgang. Verwandt ist der Abfluss zu Cloud-Speichern und per rclone; die weiteren Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Exfiltration.