Gheist Campaign Plants Secret-Stealing Workflows Across 13,500 GitHub Branches Using Stolen Tokens

A campaign dubbed Gheist has targeted GitHub repositories using stolen access tokens, according to research published October 25 by Wiz. The company has tracked it since September 15 and recovered more than 13,500 branches from over 850 compromised accounts. The attackers went after every repository the tokens could reach, from personal projects to private enterprise code. Wiz traced the tokens to infostealer logs and earlier supply chain compromises, including the March compromise of the Trivy security scanner.

The attackers used the tokens to create branches and commit a GitHub Actions workflow that printed repository secrets into its own log. They then downloaded the log through GitHub's API and deleted the run seconds later, so no external command-and-control server was needed. One variant added support for deployment environments, which can expose production credentials. It later gained a job that searched self-hosted runners for sensitive files, though Wiz called that job "buggy".

A GitHub control introduced July 28 largely blunted the campaign. It holds potentially malicious workflow runs in public repositories until a collaborator approves them, and every public Gheist run Wiz examined stayed in an action_required state. That protection does not cover private repositories or GitHub Enterprise Server. There, Wiz saw workflows complete on attacker-created branches before the runs were removed. In enterprise organisations, attackers cloned private repositories, and hours later cloud credentials from the same organisations were used to enumerate Amazon Web Services' Secrets Manager.