Gheist attackers abuse stolen GitHub tokens to steal secrets

Wiz researchers have linked a campaign named Gheist to attackers who leveraged stolen GitHub access tokens to seed secret-stealing workflows across more than 13,500 branches in repositories reachable by those tokens. The researchers traced the operation back to over 850 compromised accounts, with targets ranging from personal projects to private enterprise repositories.

They also connected the theft to earlier supply-chain compromises, including the March breach of the Trivy security scanner, and noted that some compromised accounts were used for malware distribution and cryptomining.

Attackers used the stolen tokens to create branches and commit a GitHub Actions workflow that printed repository secrets into its own log. They then downloaded the log via GitHub’s API and deleted the run seconds later, avoiding a need for external command-and-control servers.

A key obstacle was a GitHub control introduced on 28 July that places potentially malicious workflow runs in public repositories on hold until a collaborator approves them; Wiz found every public Gheist run examined remained in an action_required state, preventing execution. The protection did not apply to private repositories or GitHub Enterprise Server, where workflows completed on attacker-created branches before runs were removed.

In enterprise environments, Wiz observed attackers cycling user and automation account tokens to clone private repositories, with hours later cloud credentials from the same organisations used to enumerate AWS Secrets Manager. Two tool variants ran in parallel—one adding deployment-environment support and exposing environment-scoped secrets (often production credentials) and another with a bugged job that searched self-hosted runners for credentials and other sensitive files. By 24 October, roughly two-thirds of implicated accounts were no longer available on GitHub, though Gheist was deemed ongoing and evolving.