Gheist Campaign Steals GitHub Secrets via Stolen Tokens and Log Exfiltration
An automated campaign dubbed Gheist is exploiting stolen GitHub tokens to exfiltrate sensitive secrets from private repositories by embedding malicious workflows that print secrets into logs.
A sophisticated automated campaign, identified as Gheist by cloud security firm Wiz, is actively targeting private GitHub repositories and GitHub Enterprise environments by leveraging compromised OAuth tokens. The attackers inject malicious workflows into new branches, designed to print a repository's secrets directly into GitHub Actions logs. These logs are then downloaded by the threat actors before the workflow runs are deleted, effectively exfiltrating sensitive data.
Wiz has been tracking this campaign since September 15, observing over 13,500 planted branches across more than 850 compromised accounts, ranging from personal projects to enterprise-level organizations. While a GitHub safeguard pauses suspicious workflow runs in public repositories, this protection does not extend to private repositories or GitHub Enterprise Server, leaving those environments vulnerable. The campaign uses a specific user agent, 'gheist,' in its GitHub API requests, which is how Wiz derived the campaign's name.
The attack vector begins with a stolen GitHub token that possesses write access to a repository. The threat actor then creates a new branch, typically named 'ci-sync-' followed by random characters, and commits a malicious workflow file named '.github/workflows/sync-check.yml'. The commit message is usually 'ci: sync config'. This action triggers the workflow, which is programmed to print all accessible secrets, encoded in base32, to the job's logs. Although GitHub masks secrets in logs, the base32 encoding bypasses this protection, allowing the secrets to be displayed in full.
One variant of the tool further enhances its exfiltration capabilities by running a separate job for each deployment environment within the repository. This allows the attackers to capture secrets specific to different environments, including potentially critical production credentials. The workflow itself is configured with an empty permissions block, limiting the scope of the default GITHUB_TOKEN but not preventing the exfiltration of repository secrets. After the secrets are logged and downloaded, the threat actor deletes the workflow run, often within seconds, to obscure their activity.
GitHub's audit logs for private repositories and GitHub Enterprise Server have shown workflow runs on these malicious branches completing and subsequently being deleted by the 'gheist' user agent. In enterprise settings, the tool has been observed cycling through multiple user and automation account tokens rapidly, cloning private repositories before planting the malicious workflow. In some instances, cloud credentials from the same organization were later used to enumerate AWS Secrets Manager, indicating a potential secondary compromise or exploitation of existing access.
The sources of the stolen tokens used in the Gheist campaign are varied, including infostealer logs and tokens previously exposed in other supply-chain attacks. The campaign has also shown signs of overlap with other malicious activities. For example, some compromised accounts were also involved in a campaign that renamed repositories to spread malware, and a subset of victims appear to have been infected with PolinRider malware, linked to North Korea, with some re-pushing their Gheist commits with added malicious loaders.
As of October 24, the campaign was still active and evolving, though approximately two-thirds of the involved accounts were no longer accessible on GitHub, suggesting a response from the platform. Wiz has reported the activity to GitHub. The campaign's persistence and the diverse methods of token acquisition highlight the ongoing challenges in securing code repositories against sophisticated threat actors.