Sysdig erläutert in einer aktuellen Analyse, wie Bedrohungsakteure self-hosted Github-Actions-Runner missbrauchen, um dauerhaften Remote-Zugriff aufzubauen. Der Shai-Hulud-Wurm ist ein reales Beispiel. Er demonstrierte am 24. November 2025 genau diese Technik in großem Maßstab. Rogue-Runner werden installiert und diese nutzen verwundbare Workflows als Command-and-Control (C2)-Kanal. Das geschieht bei Traffic, der wie normale Github-Nutzung aussieht.
Self-hosted Runner laufen auf der Infrastruktur der Organisation (Server/Cloud-Instanzen) und bieten dadurch oft Zugriff auf interne Netze und potenziell „gecachte Secrets/Credentials“. Zudem führen sie per Design beliebigen Workflow-Code aus. Hinzu kommt, dass das Onboarding bewusst „low friction“ ist: Mit ./config.sh und einem Registrierungstoken entsteht eine langfristige Verbindung zu GitHub. Solche Tokens können (mit Admin-Rechten) auch über die GitHub-API erzeugt werden.
Fallstudie: Shai-Hulud als Backdoor über Rogue Runner
Sysdig beschreibt, wie Shai-Hulud nach einer initialen Kompromittierung (u. a. über trojanisierte NPM-Pakete) Github so ausnutzt, dass ein kompromittiertes System praktisch „von innen heraus“ an die GitHub-Infrastruktur angebunden wird: Die Malware legt ein neues öffentliches Repository mit einem festen Marker in der Beschreibung an und aktiviert bewusst nur „Discussions“ als späteren Kommunikationskanal. Anschließend beschafft die Malware per GitHub-API ein Runner-Registration-Token, installiert den offiziellen GitHub-Actions-Runner versteckt (z. B. in ~/.dev-env), startet ihn persistent im Hintergrund (z. B. via nohup) und hebt Schutzmechanismen aus, indem der Runner explizit mit Root-Rechten laufen darf (RUNNER_ALLOW_RUNASROOT=1).
Der eigentliche „Backdoor“-Mechanismus entsteht durch einen absichtlich verwundbaren Workflow (z. B. discussion.yaml), der den Text einer „Discussion“ direkt in einen run-Befehl übernimmt. Durch Shell-Metazeichen lässt sich so Command Injection auslösen: Angreifer posten eine „Discussion“, und der Runner führt die eingeschleusten Befehle aus. Um darüber hinaus Persistenz über Job-Enden hinweg zu erreichen, wird RUNNER_TRACKING_ID manipuliert (z. B. 0), sodass GitHub Prozesse nicht wie vorgesehen bereinigt.
Breitere Risikomuster: Es geht nicht nur um „Discussions“
Die Analyse macht deutlich: Entscheidend ist nicht der konkrete Trigger, sondern „untrusted“ Input, der auf persistenten self-hosted Runnern verarbeitet wird. Beispiele für besonders riskante Trigger-/Konfigurationsmuster sind:
- pull_request_target: läuft im Kontext des Base-Repos – mit potenziell privilegiertem Token- und Secret-Zugriff, wenn Workflows PR-Code auschecken/ausführen.
- issue_comment: Kommentare in öffentlichen Repos sind ein naheliegender Injektionsvektor, wenn Text ohne Sanitization verarbeitet wird.
- „Neglected“ Activity Types: wenn Events nicht granular über „types“ eingeschränkt werden, können Angreifer Workflows über weniger auffällige Aktionen triggern (z. B. Labeln von Issues oder „unanswering“ einer „Discussion“).
- Persistenter Systemdienst: Angreifer können Runner zudem als Service konfigurieren (z. B. via ./svc.sh), um Reboots zu überstehen und unauffälliger als „normaler“ Dienst (systemd) zu laufen.
Schritte zur Behebung des Problems
Um Rogue-Runner und persistente Bedrohungen zu erkennen, lohnt es sich, gezielt nach entsprechenden Signalen zu suchen. Ein besonders starkes Indiz ist die Variable RUNNER_TRACKING_ID=0, da diese typischerweise dazu dient, den üblichen Prozess-Cleanup nach Job-Ende zu umgehen. Zusätzlich sollte das Runner-Inventar regelmäßig geprüft werden, wobei auch die Fragen zu klären sind, wann und von wem Runner registriert wurden. Solche Registrierungen lassen sich über Audit-Log-Events wie „repo.register_self_hosted_runner” nachvollziehen. Weitere Hinweise können von Runner-Prozessen aus versteckten Verzeichnissen (z. B. ~/.dev-env) sowie von auffälligen Runner-Namen, unerwarteten Outbound-Verbindungen von Runner-Prozessen zu bislang unbekannten Repositories und von Workflow-Dateien geliefert werden, in denen „untrusted“ Input über unsaubere Expression-Interpolation direkt in Run-Befehle einfließt.
Zur Härtung und Eindämmung bieten sich klare präventive Maßnahmen an: Self-Hosted-Runner sollten nicht in öffentlichen Repositories eingesetzt werden. Wo möglich, sind ephemere Runner sinnvoll, bei denen die Umgebung nach jedem Job wieder verworfen wird. Auch wenn das keine „Single-Job“-Garantie bedeutet, erhöht es die Hürde deutlich. Außerdem sollte der Einsatz über Runner-Groups mit Repository-Restriktionen strikt segmentiert werden, sodass nur klar definierte Repositories bestimmte Runner nutzen dürfen. Um das Risiko weiter zu senken, sollten auf Runner-Systemen grundsätzlich keine sensiblen Daten wie Secrets, SSH-Schlüssel oder API-Token gespeichert werden, da Workflow-Auslöser im Zweifel Zugriff auf die Runner-Umgebung haben könnten. Schließlich ist es ratsam, die Netzwerkzugriffe von Runnern stark zu begrenzen und insbesondere Zugriffe auf Metadaten-Services, Produktionsdatenbanken oder andere kritische interne Ziele zu verhindern.
Fazit
Self-hosted Runner sind eine unterschätzte Angriffsfläche: Sie führen per Design Workflow-Code aus, halten persistente Verbindungen zu Github und laufen häufig mit weitreichenden Berechtigungen. Der Shai-Hulud-Fall zeigt, wie Angreifer diese Eigenschaften schnell nutzen können, um Backdoors zu etablieren, die im normalen CI/CD-Traffic untergehen.
#Sysdig
