Wiz Finds Gheist Campaign Using Stolen GitHub Tokens to Steal Repository Secrets
Summary
Wiz says Gheist planted 13,500+ branches across 850+ compromised accounts, using stolen GitHub tokens to expose secrets in Actions logs. GitHub’s approval hold stopped checked public runs but does not cover private repositories or GitHub Enterprise Server.
Key points
- Wiz has tracked Gheist since September 15 and recovered more than 13,500 planted branches across more than 850 compromised accounts; it does not know how many organizations had secrets exposed.
- The tool uses stolen tokens to create ci-sync- branches and workflows that print readable repository secrets in base32-encoded form, which can bypass log masking.
- The tool downloads the workflow logs through GitHub's API and deletes the runs seconds later, so the secret data leaves through GitHub rather than an attacker-controlled server.
- Audit logs and AWS CloudTrail showed completed and deleted runs in private repositories and GitHub Enterprise Server, including organizational workflows assuming AWS roles.
- GitHub's approval hold applies to public repositories on github[.]com only. Every public Gheist run Wiz checked remained awaiting approval, so its payload did not run.
- A version introduced around October 19 attempted to search self-hosted runners for credentials; Wiz describes it as buggy and reports no successful run.
- Wiz says the campaign was still active as of October 24. It advises rotating secrets readable by affected repositories and revoking the token that pushed the branch.
Article Details
- Attack Vectors
- Attackers used stolen GitHub tokens with write access to create ci-sync- branches in reachable repositories and commit a workflow file that started automatically.
- The workflow encoded readable repository secrets in base32 and printed them to GitHub Actions logs, where the attackers downloaded the logs through GitHub's API before deleting the runs.
- In private repositories and GitHub Enterprise Server environments, workflows ran without approval; some also ran for deployment environments and exposed their secrets.
- In enterprise organizations, the tool cloned private repositories before planting workflows and cycled through tokens from multiple users and automation accounts.
- Hours later, cloud credentials from one affected organization were used to enumerate AWS Secrets Manager; Wiz's analysis does not establish where the credentials came from or who used them.
- A version of the tool attempted to search self-hosted runners for credentials, but Wiz described the job as buggy and reported no successful run.
- Defensive Notes
- Rotate every secret the affected repository could read and revoke the token that pushed the branch.
- Use OIDC with short-lived tokens instead of stored cloud keys; GitHub's documentation notes that the token subject includes the branch name by default only when the job does not use a deployment environment.
- Require reviewer approval before jobs can read deployment-environment secrets.
- GitHub's workflow-run hold applies to flagged runs in public repositories on github.com; it does not cover private repositories or GitHub Enterprise Server, according to the article.
MITRE ATT&CK
T1078 · Valid AccountsThe campaign used stolen GitHub tokens to access repositories and push workflow branches.T1213.003 · Code RepositoriesIn enterprise organizations, the tool cloned private code repositories before planting workflows.T1567 · Exfiltration Over Web ServiceThe attackers downloaded logs containing encoded secrets through the GitHub API, using GitHub itself as the channel through which the data left.
Malware
Vendors
Amazon Web Servicesaudit logs show runs on the planted branches finishing and then being deleted by the gheist user agent. AWS CloudTrail logs show the organization's own workflows also running on those branches and assuming AWSGitHubAn automated campaign is using stolen GitHub tokens to plant workflows that print a repository's secrets into its GitHub Actions logs, which the attackers then download before deleting the runs. The attacks have
Products
AWS Secrets Managerthe workflow. Hours later, cloud credentials from the same organization were used to enumerate AWS Secrets Manager. Wiz's analysis does not say where those credentials came from or who used them.GitHub Actionscampaign is using stolen GitHub tokens to plant workflows that print a repository's secrets into its GitHub Actions logs, which the attackers then download before deleting the runs. The attacks have succeeded inGitHub Enterprise ServerA GitHub safeguard that pauses suspicious workflow runs stopped every public-repository run Wiz checked, but it does not cover private repositories or GitHub Enterprise Server.