Skip to content
attack.paths
Sign in
← RegistryDossier · 6 steps · 5 edges

Self-hosted runner takeover → persistent CI compromise

A public repo with self-hosted GitHub runners accepts external PRs. First malicious PR runs on the runner; the workflow drops a runner-hook that fires before every future job.

Filed by AD Knowledge Base
§ Kill-chainDrag · zoom · scroll

§ Context

Assumed environment: target uses self-hosted runners on its own infra and forgot to restrict PRs from forks (the warning at runner registration time is often ignored).

§ Steps

  1. 01
    Wait for legitimate jobsInitial Access
    T1078— Valid Accounts
  2. 02
    Workflow runs on the runnerExecution
    T1059— Command and Scripting Interpreter
  3. 03
    Find a public repo with self-hosted runnerReconnaissance
    W-RECON-GITHUB-DORK— GitHub / GitLab Dorking
  4. 04
    Open PR with a workflowPrivilege Escalation
    CI-RUNNER-TAKEOVER— Self-Hosted Runner Takeover
  5. 05
    Drop ACTIONS_RUNNER_HOOK_JOB_STARTED scriptPersistence
    CI-RUNNER-PERSIST— Runner Persistence (custom hook)
  6. 06
    Exfil all future job secretsCredential Access
    CI-SECRET-IN-LOG— Secret Echo to Build Log

§ References

§ Frequently asked

What is the "Self-hosted runner takeover → persistent CI compromise" attack path?
A public repo with self-hosted GitHub runners accepts external PRs. First malicious PR runs on the runner; the workflow drops a runner-hook that fires before every future job. It chains 6 steps drawn from real-world offensive-security techniques.
What starting position does this attack require?
The first step is Wait for legitimate jobs (T1078) — a initial access primitive. Assumed environment: target uses self-hosted runners on its own infra and forgot to restrict PRs from forks (the warning at runner registration time is often ignored).
What is the final impact of this kill-chain?
The final step lands on Exfil all future job secrets (CI-SECRET-IN-LOG), which falls under Credential Access. From here, an operator typically pivots into post-exploitation or maintains persistence.
How can defenders detect or prevent this attack?
Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.

§ Related dossiers