Gheist’s GitHub token abuse blocked in public repos, still works in private/enterprise
The claim
The authors assert that GitHub’s recent workflow hold effectively stops Gheist’s malicious runs in public repositories, but the campaign continues to exfiltrate secrets from private and enterprise repositories.
Published as: “Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles”
So what
Organizations must assume that compromised GitHub tokens can still leak secrets from private repositories despite new GitHub defenses.
The five-minute version
Wiz tracked an automated campaign (Gheist) that injects a sync-check workflow into every repository a stolen GitHub token can reach, printing all repository secrets to the workflow log and downloading them via the GitHub API. They recovered over 13,500 malicious branches across more than 850 compromised accounts and observed two evolving tool variants. GitHub’s new approval-hold feature prevented the payload from running in public repositories, but it does not apply to private or Enterprise Server repos, where the attack still succeeds and even harvests cloud credentials. The evidence comes from real-world telemetry, audit logs, and cloud trail data, and the write-up includes detection and mitigation guidance.
What they found 3
- 13,500 malicious branches were planted across 850 compromised accounts.
“We have recovered more than 13,500 planted branches from more than 850 compromised accounts”
- Approximately two-thirds of the compromised accounts disappeared from GitHub by October 24.
“roughly 2⁄3 of implicated accounts are no longer available on GitHub”
- GitHub’s approval-hold prevented malicious runs in public repositories.
“The control worked, and the malicious payloads never ran”
What undercuts it the paper’s own results
- However, that job is buggy: it looks for the wrong runner key file, its URL-credential regex is broken, and it doesn't collect GCP or Azure tokens.
Stated limits 3
- The self-hosted runner job is buggy and fails to collect GCP or Azure tokens.
- GitHub’s approval hold does not apply to private repositories or GitHub Enterprise Server.
- Overlap with other campaigns (e.g., Lure repositories, Free compute) may inflate the observed footprint.
What’s new here 4
- First large-scale observation of automated GitHub Actions workflow injection using stolen tokens.
- Identification of two parallel tool variants (A and B) with evolving payloads, including a self-hosted runner job.
- Demonstration that GitHub’s new “approval hold” stops the attack in public repositories but not in private/enterprise environments.
- Practical hunting and remediation steps for defenders, including branch-name indicators and OIDC role-assumption checks.
Artifacts & methods 4
- sync-check.yml workflowprimitive
- gheist user agentprimitive
- ci-sync- branch naming patternprimitive
- Wiz detection rules (e.g., New Workflow Completed And Deleted In Short Time Span)system