Gheist uses stolen GitHub tokens to plant workflows that encode repository secrets in base32, print them into GitHub Actions logs, then download the logs and delete the runs. [2]

The secrets leave through GitHub’s own service. There is no separate collection server to block. [2]

Wiz, whose findings were reported by The Hacker News, found that GitHub’s suspicious-workflow safeguard stopped every public-repository run it checked, while private repositories and GitHub Enterprise Server lacked that protection. [2]

The private runs finished, then were deleted. Their audit records survived the cleanup. [2]

Wiz has tracked the campaign since September 15, recovering planted branches from more than 850 compromised accounts. That is an account count, not a count of organisations whose secrets were exposed. The published analysis does not establish the latter. [2]

The workflow’s permissions setting offers another detail worth reading twice. It contains an empty permissions block, limiting the job’s own GITHUB_TOKEN. The stolen token has already supplied the access needed to plant the workflow, and the setting does not prevent the job from reading repository secrets. [2]

GitHub masks secrets in logs, but its documentation says masking is not guaranteed after a value has been encoded or otherwise changed. Gheist prints the base32 version. The original value’s mask no longer matches. [2]

For the person recovering a repository, deleting the planted branch leaves the central problem intact: credentials have already been copied. Wiz advises rotating every repository, organisation and environment secret the affected repository could access, alongside revoking the token that pushed the commit. [2]

A separate Microsoft 365 campaign disclosed by Huntress shows the same recovery problem in another system. Attackers replayed stolen sign-in tokens, then registered their own authentication methods and devices. Revoking the stolen session could leave those routes available. In both campaigns, the stolen token bought permission to create something that outlasted it. [1] [2]

For GitHub, the concrete traces include branches beginning `ci-sync-`, a new `.github/workflows/sync-check.yml` file and runs deleted within a minute of finishing. Cloud audit records can preserve evidence too: Wiz observed organisations’ existing workflows assuming cloud roles from the planted branches. Its analysis does not establish the origin of credentials later used to enumerate cloud secrets. [2]

Production environment approvals would have interrupted the secret-reading step. GitHub’s documented control prevents a job from reading an environment’s secrets until a required reviewer approves it. Where production credentials sit behind that approval, possession of a repository write token alone cannot release them. [2]