Gheist Uses Stolen GitHub Tokens to Steal Private Repository Secrets via Actions Logs
An automated campaign dubbed 'Gheist' is exploiting stolen GitHub tokens to inject malicious workflows into private repositories, exfiltrating sensitive secrets from GitHub Actions logs before deleting the evidence.
Intelligence analysis by Gemini 2.5 Flash
Cloud security company Wiz has identified and tracked the 'Gheist' campaign since September 15, which leverages stolen GitHub tokens to plant workflows that print a repository's secrets into its GitHub Actions logs. These logs are then downloaded by attackers, who target private repositories and GitHub Enterprise environments, bypassing existing public repository safeguards.
Imagine you have a secret diary where you keep all your important passwords. A sneaky person, called Gheist, steals your special pen that lets them write in your diary. They secretly add a note that makes your diary loudly read out all your passwords, but in a secret code. They quickly write down the coded passwords, then erase their note and run away. Your public diaries have a guard who stops suspicious notes, but your private ones don't, so Gheist can easily steal from them.
Analysis
The 'Gheist' campaign represents a sophisticated and automated threat targeting the integrity of software development workflows on GitHub. By exploiting stolen GitHub tokens, attackers gain unauthorized access to private repositories, where they inject malicious GitHub Actions workflows. These workflows are designed to systematically extract sensitive information, such as API keys, database credentials, and other secrets, which are often stored within repositories for automated processes. The method of exfiltration—printing secrets into GitHub Actions logs and then downloading them—is particularly insidious because it leverages legitimate platform functionality, making detection challenging and avoiding outbound connections that might trigger traditional network security alerts.
The Gheist Campaign
The core of the Gheist operation involves creating new branches, typically named ci-sync- followed by random characters, and committing a file named .github/workflows/sync-check.yml. This workflow, once triggered, is engineered to print the job's environment variables and all accessible secrets, encoded in base32. This encoding is crucial as it bypasses GitHub's default log masking, allowing the full secret values to be exposed. After the secrets are printed and downloaded via GitHub's API, the attackers swiftly delete the workflow run, leaving minimal forensic traces. Wiz has identified over 13,500 such planted branches across more than 850 compromised accounts, indicating a widespread and persistent attack.
GitHub's Safeguards and Limitations
GitHub has implemented safeguards, such as holding potentially malicious workflow runs for approval, but these are currently limited to public repositories on GitHub.com and do not extend to private repositories or GitHub Enterprise Server environments. This critical gap allows the Gheist campaign to operate effectively in the very environments where the most sensitive organizational data resides. The attackers' ability to bypass secret masking through base32 encoding further underscores the limitations of current platform-level protections against determined adversaries. The campaign's ongoing nature, with observed changes and new variants, suggests a continuous adaptation to potential defenses.
Attack Vectors and Connections
The stolen GitHub tokens fueling the Gheist campaign originate from various sources, including infostealer logs and tokens exposed in previous supply-chain attacks, such as the compromise of the Trivy vulnerability scanner. This highlights the interconnectedness of cyber threats, where one breach can facilitate subsequent attacks. Furthermore, the campaign shows overlaps with other malicious activities; some compromised accounts were also used in a scheme to rename repositories to spread malware, and others were linked to the PolinRider malware, which researchers associate with North Korea. The discovery of a new variant targeting self-hosted runners to search for credentials on victim machines indicates an evolving threat landscape, aiming for deeper system compromise beyond just repository secrets.
Key points
- The 'Gheist' campaign uses stolen GitHub tokens to inject malicious workflows into private repositories.
- Attackers exfiltrate sensitive secrets by printing them into GitHub Actions logs, encoded in base32 to bypass masking.
- The campaign targets private repositories and GitHub Enterprise Server, as GitHub's public repository safeguard does not apply to them.
- Stolen tokens originate from infostealers and prior supply-chain attacks, with some accounts linked to other malware campaigns like PolinRider.
- Wiz has tracked over 13,500 planted branches from more than 850 compromised accounts since September 15.
GitHub's existing safeguard for public repositories and its reported response to Wiz's findings, including the disappearance of many compromised accounts, suggest that platform providers can effectively mitigate such threats. This could lead to the expansion of similar security features to private repositories and GitHub Enterprise, enhancing overall developer ecosystem security.
The Gheist campaign's success in bypassing current GitHub safeguards for private repositories and its links to other sophisticated malware campaigns like PolinRider and Megalodon indicate a persistent and evolving threat. This could lead to more widespread data breaches, supply chain compromises, and a continued struggle for organizations to secure their development environments.
