Missbrauch von CI/CD-Pipelines: Das Problem, das niemand beachtet

Präambel

In den 2025 und 2026 beobachteten wir ein branchenweites Muster. Die Angreifer hörten auf, Produktionsserver direkt anzugreifen, und begannen stattdessen, die Automatisierung ins Visier zu nehmen, die auf diesen Servern bereitgestellt wird. Kompromittierte Entwicklerzugangsdaten, eine veränderte Workflow-Datei und plötzlich werden alle Geheimnisse in einer CI/CD-Umgebung an einen vom Angreifer kontrollierten Endpunkt gestreamt. Wir haben dies bei Vorfällen mit Beteiligung großer Open-Source-Projekte, Fortune 500 Unternehmen und kritischer Infrastrukturtools beobachtet.

Die Angriffskette ist trügerisch einfach:

Gestohlene Entwicklerzugangsdaten → Modifizierte Workflow-Datei → Abgegriffene CI-Geheimnisse → Seitliche Ausbreitung in Cloud und Produktion

Heute stellen wir cicd-abuse-detector als Open Source zur Verfügung, eine sofort einsatzbereite CI-Vorlage, die auf regulären Ausdrücken basierende Signalextraktion und LLM-Analyse verwendet, um verdächtige Änderungen an CI/CD-Pipelines zu erkennen. Es funktioniert über GitHub Actions, GitLab CI und Azure DevOps hinweg und basiert auf realen Angriffstechniken, die in der öffentlichen Sicherheitsforschung dokumentiert sind.

Wichtigste Erkenntnisse

• CI/CD-Umgebungen sind besonders wertvolle Ziele, da ein einziger kompromittierter Workflow gleichzeitig Cloud-Anmeldeinformationen, Paketregistrierungstoken, Codesignaturschlüssel, Bereitstellungsschlüssel und OIDC-Token exfiltrieren kann.
• Das Tool extrahiert über 50 reguläre Ausdrücke und Metadatensignale aus den Diffs und übergibt diese dann zusammen mit dem vollständigen Diff an Claude zur strukturierten Bedrohungsanalyse. Kein Python, keine weiteren Abhängigkeiten außer Bash und der Claude Code CLI.
• Die Erkennungsmuster wurden anhand von Angriffswerkzeugen wie Nord Stream und Gato-X sowie anhand realer Vorfälle wie ArtiPACKED und HackerBot-Clawgetestet.
• Das Projekt enthält 19 bösartige und vier harmlose Beispiel-Diffs, die nach spezifischen Vorfällen modelliert wurden, sowie eine automatisierte Testsuite, die jedes Signal validiert.

Warum CI/CD-Pipelines ein Top-Ziel sind

Wenn Sie sich die Zeit nehmen, GitHub Actions- oder GitLab CI-Konfigurationen zu überprüfen, werden Sie feststellen, wie viel Vertrauen in diesen Dateien konzentriert ist. Ein typischer Deployment-Workflow benötigt gleichzeitig Zugriff auf AWS-Zugangsdaten, npm-Publish-Tokens, Docker-Hub-Passwörter und ein GitHub-Token mit Schreibberechtigungen. Die Angriffsfläche ist nicht ein Server mit einer CVE-Schwachstelle, sondern eine YAML-Datei.

Erfassung von Anmeldeinformationen im großen Maßstab

Ein Angreifer, der über gestohlene Entwicklerzugangsdaten verfügt, modifiziert einen Workflow, um im CI-Umfeld verfügbare Geheimnisse zu exfiltrieren. Die GhostAction-Kampagne im September 2025 demonstrierte dies in großem Umfang, indem sie 327 GitHub-Nutzer in 817 Repositories kompromittierte. 3.325 Geheimnisse wurden durch eingeschleuste Workflow-Dateien gestohlen, die Anmeldeinformationen per POST an Angreifer-Endpunkte sendeten.

Der Shai-Hulud npm-Wurm verbreitete sich noch weiter. Dieser sich selbst verbreitende Angriff sammelte GitHub Personal Access Tokens über gh auth token, führte TruffleHog zur geheimen Aufklärung aus und nutzte kompromittierte Tokens, um unbemerkt bösartigen Code in andere Pakete desselben Entwicklers einzuschleusen. Allein in der ersten Welle wurden über 46.000 Schadsoftwarepakete veröffentlicht.

Ausnutzung privilegierter Trigger

Der Trigger pull_request_target ist eine der gefährlichsten Funktionen in GitHub Actions. Anders als bei einem regulären Pull-Request-Trigger werden Workflows im Kontext des Basis-Repositorys mit Zugriff auf Geheimnisse ausgeführt, allerdings kann Code aus einem nicht vertrauenswürdigen Fork ausgeführt werden. Die Orca-Studie „Pull Request Nightmare“ demonstrierte dies anhand von Repositories, die von Google, Microsoft und NVIDIA verwaltet werden.

Im Februar 2026 durchsuchte eine automatisierte Kampagne namens HackerBot-Claw systematisch öffentliche Repositories nach genau dieser Fehlkonfiguration. Es wurden fünf verschiedene Exploitation-Techniken eingesetzt, darunter vergiftete Go init() -Funktionen, Branch-Name-Command-Injection, dateinamenbasierte Injection, direkte Skript-Injection und KI-Prompt-Injection gegen Claude-basierte Code-Reviewer. Im schwerwiegendsten Fall wurde das Trivy-Repository von Aqua Security vollständig kompromittiert, was zu einem nachgelagerten Lieferkettenangriff führte, bei dem 33.000 Geheimnisse auf fast 7.000 Maschinen offengelegt wurden. Wie dokumentiert, wurde dieser Lieferkettenangriff durch kompromittierte Token ermöglicht, die noch Wochen nach ihrem Diebstahl gültig waren.

Der Rest der Taxonomie

Neben dem Sammeln von Zugangsdaten und der Ausnutzung von Triggern umfasst das Bedrohungsmodell vier weitere Kategorien, die in der öffentlichen Forschung immer wieder auftauchen:

• Berechtigungsausweitung, bei der das Hinzufügen von Berechtigungen wie „write-all“ oder „id-token: write“ den Wirkungsbereich einer Kompromittierung vergrößert.
• Runner-Targeting, Umleitung von Jobs an selbstgehostete Runner, die häufig Netzwerkzugriff auf die interne Infrastruktur haben, oder Angabe von vom Angreifer kontrollierten Container-Images
• Manipulation der Lieferkette durch veränderliche Aktionsreferenzen (Verwendung von @main anstelle von SHA-fixierten Versionen), Remote-Skriptausführung (curl | bash), Sperrdatei-Registry-Swaps und Abhängigkeitsvergiftung
• Umgehung der Verteidigung durch Manipulation des Commit-Zeitstempels, wodurch bösartige Dateien alt und vertrauenswürdig erscheinen. KL4R10N dokumentierte diese Technik in Kampagnen mit Verbindungen zu Nordkorea, bei denen rückdatierte Commits auf eine Infrastruktur verwiesen, die zum angegebenen Zeitpunkt nicht existierte.

Jede dieser Techniken ist einer bestimmten MITRE ATT&CK- Technik zugeordnet: T1552 (Unsecured Credentials), T1195 (Supply Chain Compromise), T1070.006 (Timestomp) und T1059 (Command and Scripting Interpreter).

Funktionsweise des Detektors

Wir wollten, dass die Vorlagen ohne Python, benutzerdefinierte Laufzeitumgebungen oder komplexe Abhängigkeiten funktionieren. Alles läuft mit Standard-Shell-Dienstprogrammen auf einem standardmäßigen ubuntu-latest-Runner, und das einzige installierte Tool ist die Claude Code CLI über npm, die sich um Authentifizierung, Wiederholungsversuche und Modellrouting kümmert.

Stufe 1: Filtern und Differenzieren

Wenn ein Pull Request geöffnet wird (oder ein Push auf einem geschützten Branch landet), identifiziert der Workflow geänderte Dateien über drei Ebenen von CI/CD-relevanten Pfaden hinweg. Die erste Ebene umfasst zentrale CI-Dateien wie Workflow-Definitionen, Pipeline-Konfigurationen und Makefiles. Der zweite Teil umfasst Build- und Release-Artefakte wie Dockerfiles, Paketmanifeste, Sperrdateien und Signierungs- oder Bereitstellungsskripte. Die dritte Ebene lädt Konfigurationen der Entwicklerumgebung wie .vscode/tasks.json und .devcontainer herunter. Dateien.

Die Unterschiede zwischen den Dateien werden einzeln analysiert und auf 10.000 Zeichen begrenzt. Wir führen dies dateiweise und nicht global durch, da eine einzelne Begrenzung der kombinierten Differenz einen Umgehungsvektor darstellt. Ein Angreifer kann eine bösartige Workflow-Änderung mit einer großen, harmlosen Dockerfile-Änderung versehen, um die Zeichenbegrenzung des Exploits zu überschreiten.

Phase 2: Signalextraktion

Bevor das LLM irgendetwas sieht, scannen über 50 reguläre Ausdrücke jeden Diff nach bekannten gefährlichen Mustern. Diese Signale sind Empfehlungen. Sie stellen keine Kontrollinstanzen für die Analyse bereit, sondern liefern dem LLM eine vorselektierte Bedrohungsübersicht. Einige Beispiele:

Die Signalliste basiert auf realen Adversarial Tools, einschließlich Nord Stream und Gato-X, und wurde anhand von 19 bösartigen Beispiel-Diffs getestet, die nach spezifischen Vorfällen modelliert wurden.

Der Detektor funktioniert identisch auf GitHub Actions, GitLab CI und Azure DevOps. Hier sind die auf den jeweiligen Plattformen ausgelösten Erkennungen:

Phase 3: LLM-Analyse

Die Signalzusammenfassung, der vollständige Diff, das Autorenprofil und die Commit-Metadaten werden gebündelt und über die Claude Code CLI an Claude gesendet. Die Analyseaufforderung führt das Modell durch mehrere Bereiche:

1. Diff-Verständnis und dateibezogene Risikobewertung
2. Signalinterpretation im Kontext (ein Signal allein ist kein Urteil)
3. Zeitliche Analyse für rückdatierte Commits
4. Bewertung des Autorenvertrauens anhand des Kontoalters, der Beitragshistorie und der Organisationsmitgliedschaft
5. Schweregradkalibrierung anhand einer Signalkombinationstabelle mit über 60 Einträgen
6. Falsch-positive Erkennung (z. B. ist das Herunterladen bekannter Tools mit cURL keine Datenexfiltration).
7. Konkrete, umsetzbare Empfehlungen („Aktionen/Setup-Node@Main an eine bestimmte SHA anheften“ statt „sorgfältig prüfen“)

Das Ergebnis ist ein strukturiertes JSON-Urteil, das Schweregrad, Konfidenz, Begründung, Beweise und Empfehlungen enthält, die alle anhand eines JSON-Schemas validiert wurden.

Phase 4: Alarm und Tor

Abhängig vom Schweregrad des Urteils veröffentlicht der Workflow eine Schrittzusammenfassung, erstellt ein Ticket, sendet eine Slack-Benachrichtigung und schlägt optional die PR-Prüfung fehl, wenn der Schweregrad einen konfigurierten Schwellenwert erreicht.

Benachrichtigungen in Slack und GitHub Issues lösen zwar das Problem der sofortigen Meldung, bieten aber keine abfragbare Historie. Jedes Urteil, das der Detektor erzeugt (z. B. gutartig, verdächtig oder bösartig), können optional als strukturiertes Dokument in logs-cicd.abuse-default an Elasticsearch gesendet werden. Datenstrom. Der Workflow übermittelt das Ergebnis zusammen mit CI/CD-Metadaten (Plattform, Repository, Akteur, Ereignistyp, Ausführungs-URL) in einen einzigen Index, der alle drei unterstützten Plattformen umfasst.

Hier wird die plattformübergreifende Korrelation praktisch. Eine GitHub Actions-Benachrichtigung und eine GitLab CI-Benachrichtigung desselben Akteurs landen im selben Datenstrom und können mit einer einzigen ES|QL-Anweisung abgefragt werden:

FROM logs-cicd.abuse-* 
WHERE verdict.verdict IN ("malicious", "suspicious") AND @timestamp > NOW() - 7 days 
EVAL platform = cicd.platform, repo = cicd.repository, actor = cicd.actor, severity = verdict.severity
KEEP @timestamp, platform, repo, actor, severity
SORT @timestamp DESC

Das Schema umfasst cicd.platform, cicd.repository, cicd.actor und das vollständige Urteilsobjekt (Urteil, Schweregrad, Konfidenz, Zusammenfassung, Gründe, Beweise), wodurch das Erstellen von Erkennungsregeln unkompliziert wird. Eine koordinierte Kampagne, die innerhalb einer Stunde mehrere Repositories trifft, ein wiederholter Täter, der plattformübergreifend gemeldet wird, oder ein sprunghafter Anstieg kritischer Befunde, der eine Incident-Response-Seite erforderlich macht, können miteinander in Zusammenhang gebracht werden.

Validierung anhand realer Angriffe

Um die Abdeckung zu überprüfen, verglichen wir unsere Erkennungsmuster mit dem tatsächlichen Quellcode der Angriffswerkzeuge, veröffentlichten Forschungsergebnissen und öffentlichen Post-Mortem-Analysen.

Nord Stream: wörtliche Nutzdatenübereinstimmung

Nord Stream ist das Open-Source-Tool von Synacktiv zur Extraktion von Geheimnissen in CI/CD-Systemen und unterstützt GitHub, GitLab und Azure DevOps. Wir haben den Quellcode des YAML-Generators (nordstream/yaml/github.py) abgerufen und seine Ausgabevorlagen mit unseren Beispiel-Diffs verglichen.

• Die GitHub-Payload-Vorlage verwendet env -0 | awk -v RS='0' '/^secret_/ {print $0}' | base64 -w0 | base64 -w0. Unser nord-stream-pipeline-exfil.diff enthält diese Zeile wörtlich, und unsere double_base64, env_null_dump, und env_secret_grep signalisieren, dass alle feuern.
• Die OIDC Azure-Vorlage verwendet azure/login@v1 mit id-token: write Berechtigungen, gefolgt vom az-Konto get-access-token | base64 -w0 | base64 -w0. Unser Diff erfasst genau diesen Ablauf und löst cloud_auth_action und id_token_write aus.
• Die Azure DevOps Pipeline-Techniken (addSpnToEnvironment für die Offenlegung von SPN-Anmeldeinformationen, DownloadSecureFile für den sicheren Dateidiebstahl, SSH-Task-Quellcode-Patching über ssh.js Modifikation) sind alle in nord-stream-azure-devops.diff vorhanden und werden durch plattformspezifische Signale erkannt.

ArtiPACKED: die Artefakt-Wettlaufbedingung

Die ArtiPACKED- Untersuchung der Palo Alto Unit 42 zeigte, dass das Hochladen des gesamten Checkout-Verzeichnisses als Artefakt die .git/config Datei mit den GITHUB_TOKEN nicht preisgibt. Da die v4 Artifact API Downloads während der Ausführung ermöglicht, kann ein Angreifer das Token extrahieren und verwenden, bevor der Job abgeschlossen ist.

Unser artifact-token-leak.diff bildet genau dieses Muster ab, indem es upload-artifact mit path: . (dem gesamten Arbeitsbereich) kombiniert. Das upload_artifact -Signal fängt es auf, und der LLM prüft, ob der Upload-Bereich das .git -Verzeichnis umfasst.

GITHUB_ENV-Einschleusung: LD_PRELOAD zu RCE

Die Untersuchungen von Legit Security zu Google Firebase und Apache zeigten, dass das Schreiben nicht vertrauenswürdiger Eingaben an $GITHUB_ENV es einem Angreifer ermöglicht, beliebige Umgebungsvariablen wie LD_PRELOAD und NODE_OPTIONS zu setzen und so die Ausführung von Code in privilegierten Arbeitsabläufen zu erreichen.

Unser github-env-injection.diff reproduziert diese Technik mit drei verschiedenen Payloads, darunter LD_PRELOAD das auf ein bösartiges Shared Object verweist, NODE_OPTIONS mit einer erforderlichen Injektion und $GITHUB_PATH Manipulation. Die Signale github_env_write, ld_preload, und github_path_write werden wie erwartet ausgelöst.

Ansteckendes Vorstellungsgespräch: IDE-Konfiguration als erster Zugriff

Die der DVRK zugeschriebene Kampagne „Contagious Interview“ zielt mit gefälschten Vorstellungsgesprächen auf Entwickler ab und verbreitet Repositories mit .vscode/tasks.json -Dateien, die sich beim Öffnen des Ordners automatisch ausführen. Die Präsentation ist ausgeblendet (reveal: never, echo: false), und die Nutzlast verwendet curl | node für die stille Ausführung.

Unser ide-config-poisoning.diff erfasst die gesamte Angriffskette, einschließlich des automatischen Ausführungsauslösers (runOn: folderOpen), der versteckten Präsentation, der curl | node Payload, des files.exclude Eintrags, der das .vscode Verzeichnis verbirgt, und eines trojanisierten Postinstall-Hooks mit base64-codierten URLs und eval() zur Codeausführung. Sechs Signale erfassen dies gleichzeitig.

Abwehrempfehlungen

Neben dem Einsatz des Detektors gibt es folgende Härtungsmaßnahmen, die sich direkt aus den von uns untersuchten Angriffsmustern ergeben haben:

• Alle Aktionen an SHA binden, nicht an Tags, nicht an Branches. SHA-fixierte Referenzen verhindern Angriffe auf rückwirkende Tag-Modifikationen wie tj-actions (CVE-2025-30066).
• Bereichsgeheimnisse sollten auf einzelne Schritte beschränkt werden, anstatt Umgebungsvariablen auf Jobebene zu verwenden. Jeder Schritt sollte nur Zugriff auf die Geheimnisse haben, die er tatsächlich benötigt.
• Verwenden Sie nach Möglichkeit kurzlebige, flüchtige Token, um die Angriffsfläche zu verringern.
• Vermeiden Sie pull_request_target es sei denn, dies ist unbedingt erforderlich. Falls Sie es unbedingt verwenden müssen, checken Sie den PR-Head-Code niemals im selben Workflow aus. Verwenden Sie ein separates workflow_run-triggered workflow für Operationen, die sowohl Geheimnisse als auch PR-Kontext benötigen.
• Legen Sie für jeden Workflow explizite Berechtigungen fest, da die Standard-Tokenberechtigungen viel zu weit gefasst sind. Setzen Sie permissions: {} auf Workflow-Ebene und fügen Sie spezifische Berechtigungen pro Job hinzu.
• Aktivieren Sie persist-credentials: false beim Checkout, da das Standardverhalten von actions/checkout GITHUB_TOKEN im Verzeichnis .git beibehält. Wenn Sie Artefakte hochladen, wird dieses Token mit ihnen hochgeladen.

Zusammenfassung

CI/CD-Pipelines haben sich zu einer wichtigen Angriffsfläche für Kompromittierungen der Lieferkette entwickelt. Dieselbe Automatisierung, die die moderne Softwarebereitstellung ermöglicht, wird von Angreifern ausgenutzt, um Zugangsdaten zu erlangen, Softwarepakete zu manipulieren und sich Zugang zur Cloud-Infrastruktur zu verschaffen. Die traditionelle Codeüberprüfung erfasst diese Muster nicht gut, da sie subtil, plattformspezifisch und so gestaltet sind, dass sie wie legitime DevOps-Änderungen aussehen.

Durch die Kombination von auf regulären Ausdrücken basierender Signalextraktion mit LLM-Schlussfolgerungen können wir diese Muster bereits im Pull-Request-Stadium erkennen, bevor sie in die Produktion gelangen. Das Repository enthält das vollständige Bedrohungsmodell, die Testsuite und Beispiel-Diffs, falls Sie sich eingehender mit den Details befassen oder es an Ihre eigene Umgebung anpassen möchten.

Für den Einstieg sollten Sie sich das cicd-abuse-detector-Repository ansehen, um Anweisungen zur Einrichtung, das vollständige Bedrohungsmodell und Beispieländerungen zu erhalten. Wir sind stets daran interessiert, von neuen Angriffsmustern und Erkennungsideen zu erfahren. Tausche dich mit uns in unserem Community-Slack aus und stelle Fragen in unseren Diskussionsforen.

CI/CD-Missbrauch durch MITRE ATT&CK

Wir verwenden das MITRE ATT&CK- Framework, um die Taktiken, Techniken und Verfahren abzubilden, die Angreifer gegen CI/CD-Pipelines einsetzen.

Taktiken

Techniken

Referenzen

In der obigen Studie wurde auf Folgendes Bezug genommen:

• https://github.com/elastic/cicd-abuse-detector
• https://github.com/synacktiv/nord-stream
• https://github.com/AdnaneKhan/Gato-X
• https://unit42.paloaltonetworks.com/github-repo-artifacts-leak-tokens/
• https://blog.gitguardian.com/ghostaction-campaign-3-325-secrets-stolen
• https://www.reversinglabs.com/blog/shai-hulud-worm-npm
• https://orca.security/resources/blog/pull-request-nightmare-github-actions-rce/
• https://orca.security/resources/blog/hackerbot-claw-github-actions-attack/
• https://www.stepsecurity.io/blog/hackerbot-claw-github-actions-exploitation
• https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0
• https://www.abstract.security/blog/contagious-interview-tracking-the-vs-code-tasks-infection-vector
• https://about.codecov.io/apr-2021-post-mortem/
• https://kl4r10n.tech/blog/when-git-history-lies
• https://www.synacktiv.com/en/publications/github-actions-exploitation-dependabot
• https://docs.anthropic.com/en/docs/claude-code

Über Elastic Security Labs

Elastic Security Labs ist der Threat-Intelligence-Zweig von Elastic Security, der sich der Schaffung positiver Veränderungen in der Bedrohungslandschaft verschrieben hat. Elastic Security Labs bietet öffentlich zugängliche Forschungsergebnisse zu neuen Bedrohungen mit einer Analyse der strategischen, operativen und taktischen Ziele von Angreifern und integriert diese Forschung dann mit den integrierten Erkennungs- und Reaktionsfunktionen von Elastic Security.

Folgen Sie Elastic Security Labs auf Twitter @elasticseclabs und sehen Sie sich unsere Forschungsergebnisse unter www.elastic.co/security-labs/ an.