Gheist campaign uses stolen GitHub tokens to plant secret-dumping workflows

TLDR

• Wiz recovered over 13,500 planted branches from over 850 compromised accounts in the Gheist campaign.¹
• GitHub's approval hold blocks public-repository runs but not private repositories or GitHub Enterprise Server, where Wiz saw runs complete.¹²
• Wiz says deleting the run or branch does not undo exposure: rotate every secret the repository could read.¹²

Wiz Research has tracked Gheist since 15 September, describing it as a campaign of mass abuse of compromised GitHub tokens. The tool commits a workflow named sync-check to every repository a token can access, the workflow seeks to print the repository's secrets into its own log, and the tool then downloads the log through the GitHub API and deletes the run seconds later.¹ The campaign takes its name from the user agent "gheist" that the tool's API requests carry.¹ Wiz recovered more than 13,500 planted branches from more than 850 compromised accounts, ranging from personal projects to private repositories of enterprise organisations.¹ Each branch is named ci-sync- plus six random characters and carries the commit message "ci: sync config".¹ The workflow prints the job's environment and secrets encoded in base32; GitHub masks secrets in logs only when they appear verbatim, so the encoded text prints in full, and because the secrets leave through GitHub's own API there is no attacker domain or outbound connection to block.¹²

Since 28 July, GitHub has held potentially malicious workflow runs in public repositories until a collaborator approves them, and every public Gheist run Wiz checked was held, so its payload never ran.¹ The Hacker News quotes GitHub as saying the hold "currently applies to public repositories on github.com only" and that GitHub Enterprise Server does not have it.² In private repositories and on GitHub Enterprise Server, Wiz says audit logs show runs on ci-sync-* branches completing and then being deleted by the gheist user agent, and AWS CloudTrail shows the organisations' own workflows running on those branches and assuming AWS roles.¹ In enterprise organisations the tool cycled through the tokens of several users and automation accounts within minutes and cloned private repositories before planting the workflow; hours later, cloud credentials from the same organisation were used to enumerate AWS Secrets Manager.¹

The sources differ on scale. Dark Reading reports that Wiz researcher Rami McCarthy estimates the campaign affected "on the scale of a dozen companies", while adding that Wiz has not seen consistent or automated abuse beyond mass cloning of repositories and the core credential theft.³ The Hacker News notes that Wiz's analysis does not say how many organisations had secrets exposed, nor where the cloud credentials used against AWS Secrets Manager came from.² Wiz traced the stolen tokens to infostealer logs and to tokens exposed in earlier supply-chain compromises, such as the March compromise of Trivy.¹²

Around 19 October one version of the tool began pushing a second job aimed at self-hosted runners; Wiz describes it as buggy, and The Hacker News says the analysis reports no successful run.¹² As of 24 October Wiz said the attack was ongoing and evolving, and that roughly two-thirds of the implicated accounts were no longer available on GitHub, which it says likely indicates response activity after it reported the campaign to GitHub.¹ The Hacker News and Dark Reading both report Wiz's findings; Dark Reading adds comment from McCarthy and from staff at Cloudsmith and Secure.com, and neither presents separate technical analysis of the campaign.²³

Why it matters: the approval hold does not cover private repositories or GitHub Enterprise Server, so secrets exposed there need rotating rather than only removing the branches and runs.¹²