Gheist: Stolen GitHub Tokens Make Your Actions Logs Print Your Secrets, Then Delete the Evidence

The attacker does not need to break into your cloud. They need one GitHub token that can push a branch, and a workflow that prints what the repository already knows. Wiz Research reports an automated campaign it calls Gheist, after the user agent in the attackers' API requests. It uses stolen GitHub tokens to plant workflows that print repository secrets into Actions logs, then downloads the logs and deletes the runs within seconds.

It is the same family of problem we covered in the GhostAction articles, but with a quieter method: nothing is sent to an outside server. The secrets leave through GitHub's own logs.

What Wiz reports

According to The Hacker News's account of the Wiz analysis, the campaign has been running since 15 September. Wiz recovered more than 13,500 planted branches from over 850 compromised accounts, and says it was still active and changing as of 24 October.

The mechanism. A planted workflow prints the repository's secrets, including secrets limited to deployment environments, which are often production credentials. The attackers then fetch the logs and delete the runs.
Where it worked. Wiz says attacks succeeded in private repositories and in GitHub Enterprise environments. In enterprise organisations the tool cycled through several user and automation tokens within minutes and cloned private repositories.
Where it did not. GitHub's July safeguard holds suspicious workflow runs for approval. Per GitHub, it applies only to public repositories on github.com. Every public run Wiz checked was held, so the payload never ran.
Where the tokens came from. Wiz points to infostealer logs and to tokens exposed in earlier supply-chain attacks, including a March compromise of the Trivy scanner.
What followed. Hours after repository cloning, cloud credentials from the same organisations were used to enumerate AWS Secrets Manager. Wiz has not identified where those credentials came from.
A variant. A version aimed at self-hosted runners searches for credentials, but Wiz describes it as buggy and reports no successful runs.

What is not known

How many organisations had secrets exposed. Wiz has not said.
Where the AWS credentials used for Secrets Manager enumeration came from. It may be the same campaign or not.
Who is behind it. The reporting does not attribute it, and some of the accounts were also used by other attackers for unrelated activity such as spreading malware.
What GitHub has done beyond the July safeguard. Wiz reported the activity, and about two-thirds of the involved accounts were no longer available by 24 October, but the reporting does not say what GitHub changed.

Why this evades the usual advice

Most workflow-injection advice assumes the secret has to reach an attacker's server, so it points to egress controls and approval of outside contributors. Here the secret goes into a log that the attacker can read with the stolen token, and the evidence is deleted afterwards. Environment-scoped secrets, which teams often treat as the safer tier, were exposed too, because the planted workflow ran in the repository's own context.

It also shows how little protection an Actions secret provides against someone who can push a branch. Anyone who can create a workflow file can read every secret that workflow is allowed to see.

What to do

Look for branches and runs you did not create. Review recent branches, workflow files and deleted-run activity in the audit log across your organisation, especially private repositories and any GitHub Enterprise Server instance, which the July safeguard does not cover.
Revoke the tokens that pushed them. Revoke rather than rotate, then revoke sessions, OAuth grants and SSH keys on the affected accounts and enrol phishing-resistant authentication.
Rotate every secret the repository could reach. That includes repository, organisation and environment secrets, and any cloud credentials. Replace the credential at the provider first, then update GitHub.
Treat self-hosted runners that ran planted code as compromised, together with the cloud instance role they use.
Put people between a push and your production secrets. Require reviewers on environments that hold production credentials, and restrict workflow changes to reviewed branches.
Narrow federated trust. Limit cloud OIDC trust policies to protected branches or specific environments, so a planted branch cannot assume your cloud role.
Stop using personal access tokens where you can. Prefer GitHub Apps or short-lived fine-grained tokens, and find which long-lived tokens in infostealer-prone developer machines could still be live.
Check the cloud side. Look for Secrets Manager enumeration and unfamiliar API calls from the days after any suspicious GitHub activity.

The handover after rotation

A large rotation means new credentials reaching the engineers who store them in GitHub or the cloud. If you paste them into a pull request, an issue or the same chat the attacker may be reading, you create the next leak. Send each value once, to the one person who needs it, over a channel that does not keep it.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.

It is not a CI security tool. It cannot find planted branches, revoke tokens, scrub logs or limit what a workflow can read. Use GitHub, your cloud provider and your scanner for that, and a one-time link for the moment one person gives another a replacement credential.