GitHub Actions Runner Backdoor

Vertrauenswürdiger Traffic als Tarnung

Die Angriffsmethode nutzt eine fundamentale Schwäche: Self-hosted Runner kommunizieren regulär mit github.com, was in den meisten Netzwerken als vertrauenswürdig eingestuft wird. Herkömmliche Netzwerk-Detektionssysteme erkennen lediglich normalen GitHub-Verkehr und schlagen keinen Alarm. Dadurch können Angreifer unbemerkt Command-and-Control-Kanäle aufbauen.

Self-hosted Runner laufen auf der eigenen Infrastruktur einer Organisation – auf physischen Servern oder Cloud-Instanzen. Das verschafft ihnen häufig Zugriff auf interne Netzwerke und potenziell gespeicherte Zugangsdaten. Per Design führen sie beliebigen Workflow-Code aus. Die Einrichtung erfolgt bewusst unkompliziert: Mit dem Skript ./config.sh und einem Registrierungstoken entsteht eine dauerhafte Verbindung zu GitHub. Diese Tokens lassen sich mit Administratorrechten auch über die GitHub-API generieren.

Anatomie eines realen Angriffs

Der Shai-Hulud-Fall veranschaulicht die Vorgehensweise: Nach einer initialen Kompromittierung, unter anderem über präparierte NPM-Pakete, bindet die Schadsoftware das kompromittierte System an die GitHub-Infrastruktur an. Die Malware erstellt ein neues öffentliches Repository mit einem charakteristischen Marker in der Beschreibung und aktiviert ausschließlich die Discussions-Funktion als späteren Kommunikationskanal.

Anschließend beschafft sich die Schadsoftware über die GitHub-API ein Runner-Registrierungstoken und installiert den offiziellen GitHub Actions Runner versteckt, beispielsweise im Verzeichnis ~/.dev-env. Der Runner startet persistent im Hintergrund mittels nohup und läuft mit Root-Rechten durch die explizite Konfiguration RUNNER_ALLOW_RUNASROOT=1.

Der eigentliche Backdoor-Mechanismus entsteht durch einen gezielt verwundbaren Workflow wie discussion.yaml, der den Text einer Discussion direkt in einen run-Befehl übernimmt. Durch Shell-Metazeichen lässt sich Command Injection auslösen: Angreifer posten eine Discussion, und der Runner führt die eingeschleusten Befehle aus. Für Persistenz über Job-Enden hinweg manipulieren Angreifer die Variable RUNNER_TRACKING_ID, indem sie diese auf 0 setzen, sodass GitHub die Prozesse nicht wie vorgesehen bereinigt.

Vielfältige Angriffsvektoren

Die Bedrohung beschränkt sich nicht auf Discussions. Entscheidend ist jeder nicht vertrauenswürdige Input, der auf persistenten self-hosted Runnern verarbeitet wird. Besonders riskante Trigger sind:

pull_request_target: Dieser Workflow läuft im Kontext des Base-Repositories mit potenziell privilegiertem Token- und Secret-Zugriff, wenn Workflows PR-Code auschecken oder ausführen.

issue_comment: Kommentare in öffentlichen Repositories bieten einen naheliegenden Injektionsvektor, wenn Text ohne Bereinigung verarbeitet wird.

Nicht granular eingeschränkte Events: Wenn Events nicht über „types“ präzise eingeschränkt werden, können Angreifer Workflows über unauffällige Aktionen triggern, etwa durch das Labeln von Issues oder das „Unanswering“ einer Discussion.

Persistente Systemdienste: Angreifer können Runner als Service konfigurieren, beispielsweise via ./svc.sh, um Neustarts zu überstehen und unauffälliger als regulärer systemd-Dienst zu laufen.

Erkennungsmerkmale und Gegenmaßnahmen

Zur Erkennung von Rogue Runnern dienen mehrere Indikatoren: Die Variable RUNNER_TRACKING_ID=0 ist ein starkes Indiz, da sie typischerweise den Prozess-Cleanup nach Job-Ende umgeht. Das Runner-Inventar sollte regelmäßig geprüft werden, wobei zu klären ist, wann und von wem Runner registriert wurden. Diese Registrierungen lassen sich über Audit-Log-Events wie „repo.register_self_hosted_runner“ nachvollziehen.

Weitere Hinweise liefern Runner-Prozesse aus versteckten Verzeichnissen wie ~/.dev-env, auffällige Runner-Namen, unerwartete Outbound-Verbindungen zu bislang unbekannten Repositories sowie Workflow-Dateien, in denen nicht vertrauenswürdiger Input über unsaubere Expression-Interpolation direkt in Run-Befehle einfließt.

Zur Härtung empfehlen Sicherheitsexperten klare präventive Maßnahmen: Self-hosted Runner sollten nicht in öffentlichen Repositories eingesetzt werden. Wo möglich, sind ephemere Runner sinnvoll, bei denen die Umgebung nach jedem Job verworfen wird. Der Einsatz über Runner Groups sollte mit Repository-Restriktionen strikt segmentiert werden, sodass nur definierte Repositories bestimmte Runner nutzen dürfen.

Auf Runner-Systemen sollten grundsätzlich keine sensiblen Daten wie Secrets, SSH-Schlüssel oder API-Token gespeichert werden, da Workflow-Auslöser Zugriff auf die Runner-Umgebung haben könnten. Die Netzwerkzugriffe von Runnern sollten stark begrenzt werden, insbesondere Zugriffe auf Metadaten-Services, Produktionsdatenbanken oder andere kritische interne Ziele.

Unterschätzte Angriffsfläche

Self-hosted Runner stellen eine häufig übersehene Angriffsfläche dar. Sie führen per Design Workflow-Code aus, halten persistente Verbindungen zu GitHub und laufen häufig mit weitreichenden Berechtigungen. Der Shai-Hulud-Fall demonstriert, wie Angreifer diese Eigenschaften nutzen, um Backdoors zu etablieren, die im normalen CI/CD-Traffic untergehen.

Sicherheitsanbieter haben bereits auf die Bedrohung reagiert: Spezielle Erkennungsregeln adressieren gezielt Persistenzversuche über RUNNER_TRACKING_ID-Manipulation und das Umgehen des Prozess-Cleanups nach Job-Ende.

Trusted traffic as camouflage

The attack method exploits a fundamental weakness: self-hosted runners regularly communicate with github.com, which is classified as trusted in most networks. Conventional network detection systems only recognize normal GitHub traffic and do not raise the alarm. This allows attackers to establish command-and-control channels unnoticed.

Self-hosted runners run on an organization’s own infrastructure – on physical servers or cloud instances. This often gives them access to internal networks and potentially stored access data. By design, they execute arbitrary workflow code. The setup is deliberately straightforward: the ./config.sh script and a registration token create a permanent connection to GitHub. These tokens can also be generated with administrator rights via the GitHub API.

Anatomy of a real attack

The Shai-Hulud case illustrates the approach: After an initial compromise, including via prepared NPM packages, the malware connects the compromised system to the GitHub infrastructure. The malware creates a new public repository with a characteristic marker in the description and activates only the Discussions function as a later communication channel.

The malware then obtains a runner registration token via the GitHub API and installs the official GitHub Actions Runner hidden, for example, in the ~/.dev-env directory. The runner starts persistently in the background using nohup and runs with root privileges through the explicit configuration RUNNER_ALLOW_RUNASROOT=1.

The actual backdoor mechanism is created by a deliberately vulnerable workflow such as discussion.yaml, which transfers the text of a discussion directly into a run command. Command injection can be triggered using shell metacharacters: attackers post a discussion, and the runner executes the injected commands. For persistence across job ends, attackers manipulate the RUNNER_TRACKING_ID variable by setting it to 0 so that GitHub does not clean up the processes as intended.

Multiple attack vectors

The threat is not limited to discussions. Any untrusted input processed on persistent self-hosted runners is critical. Particularly risky triggers are:

pull_request_target: This workflow runs in the context of the base repository with potentially privileged token and secret access when workflows check out or execute PR code.

issue_comment: Comments in public repositories provide an obvious injection vector when text is processed without cleanup.

Non-granularly restricted events: If events are not precisely restricted via “types,” attackers can trigger workflows via inconspicuous actions, such as labeling issues or “unanswering” a discussion.

Persistent system services: Attackers can configure runners as services, for example via ./svc.sh, to survive restarts and run more inconspicuously than regular systemd services.

Identifying characteristics and countermeasures

There are several indicators that can be used to identify rogue runners: The variable RUNNER_TRACKING_ID=0 is a strong indicator, as it typically bypasses process cleanup after the job has ended. The runner inventory should be checked regularly to clarify when and by whom runners were registered. These registrations can be tracked via audit log events such as “repo.register_self_hosted_runner.”

Further clues are provided by runner processes from hidden directories such as ~/.dev-env, conspicuous runner names, unexpected outbound connections to previously unknown repositories, and workflow files in which untrusted input flows directly into run commands via unclean expression interpolation.

To harden systems, security experts recommend clear preventive measures: Self-hosted runners should not be used in public repositories. Where possible, ephemeral runners are useful, as the environment is discarded after each job. Use via runner groups should be strictly segmented with repository restrictions so that only defined repositories are allowed to use certain runners.

Sensitive data such as secrets, SSH keys, or API tokens should never be stored on runner systems, as workflow triggers could have access to the runner environment. Network access by runners should be severely restricted, especially access to metadata services, production databases, or other critical internal targets.

Underestimated attack surface

Self-hosted runners are an often overlooked attack surface. By design, they execute workflow code, maintain persistent connections to GitHub, and often run with far-reaching permissions. The Shai Hulud case demonstrates how attackers exploit these characteristics to establish backdoors that are lost in normal CI/CD traffic.

Security vendors have already responded to the threat: Special detection rules specifically address persistence attempts via RUNNER_TRACKING_ID manipulation and bypassing process cleanup after job completion.