A recent automated attack campaign known as Gheist has been exploiting stolen GitHub tokens to infiltrate private repositories and extract sensitive information. Cybersecurity firm Wiz has reported that the attackers create workflows that reveal repository secrets in GitHub Actions logs, which they subsequently download before erasing the evidence.
While GitHub has measures to halt suspicious workflow executions in public repositories, these protections do not extend to private repositories or GitHub Enterprise Server. The malicious workflows are deployed on new branches labeled with a prefix of ‘ci-sync-‘ followed by six random alphanumeric characters. Simply deleting the branch or the initiated run does not mitigate the risk, as any secrets accessible to the repository must be rotated, and the associated token must be revoked.
Wiz has been monitoring the Gheist campaign since September 15, identifying it by the user agent ‘gheist’ used in API requests. So far, they have discovered over 13,500 branches linked to more than 850 compromised accounts, which range from individual projects to private enterprise repositories. Although the analysis does not specify how many organizations had their secrets compromised, it highlights significant risks.
In private repositories, GitHub’s audit logs capture the runs initiated by these malicious branches, which are deleted shortly thereafter by the Gheist user agent. Moreover, AWS CloudTrail logs indicate that the organization’s legitimate workflows have been executed on these branches, indicating unauthorized access to AWS roles through GitHub Actions.
Within enterprise environments, the attackers swiftly cycled through tokens from various users and automation accounts, cloning private repositories and implementing the harmful workflows. Subsequently, cloud credentials from the affected organizations were utilized to access AWS Secrets Manager, although the source of the credentials remains unclear.
As of October 24, the Gheist campaign is still ongoing, with many of the involved accounts now inactive on GitHub, suggesting a possible counteraction.
GitHub’s documentation states that any user with write access can view all configured secrets in a repository, making a stolen token with such access highly dangerous. The tool establishes a ‘ci-sync-‘ branch where it commits a file named ‘.github/workflows/sync-check.yml’ with the commit message ‘ci: sync config.’ This commit is unsigned and includes the token owner’s name, and upon pushing, the workflow is triggered.
The workflow exposes the job’s environment and all accessible secrets, encoded in base32. Although GitHub does mask secrets in logs, this may not be guaranteed once a value is modified. Wiz reports that the encoded secrets do not match the original values, allowing them to be fully printed.
The malicious workflow sets an empty permissions block, limiting the GITHUB_TOKEN, which the attackers do not utilize, yet still enabling the job to access secrets.
In a recent variant, the tool targets self-hosted runners, which are machines organizations use to manage GitHub Actions jobs. This job is designed to search the runner for various credentials, including AWS instance roles and Kubernetes service account tokens, although Wiz notes that this version is not functioning as intended.
Some of the origins of the stolen tokens can be traced back to infostealer logs and previous supply-chain attacks, such as the March breach of the Trivy vulnerability scanner.
To verify the integrity of your repositories, Wiz recommends:
- Searching for branches starting with ‘ci-sync-‘ followed by six characters, which contain changes to a new ‘.github/workflows/sync-check.yml’ file.
- Reviewing GitHub audit logs for workflow runs on ‘ci-sync-*’ branches that were deleted shortly after execution, and monitoring for activity from the ‘gheist’ user agent.
- If using OIDC to sign into a cloud provider, check for suspicious role assumptions or token exchanges involving ‘ci-sync-‘ branches.
- On self-hosted runners, inspect for specific files and indicators mentioned in their analysis.
If a ‘ci-sync’ branch is discovered, Wiz suggests:
- Rotating all relevant secrets that the repository could access.
- Revoking the tokens that initiated the commits and checking their owners’ devices for malware.
- If the branch executed on a self-hosted runner, treat the machine as compromised.
- Avoid approving any held sync-check runs or executing code from ‘ci-sync’ branches.
To minimize the impact of stolen tokens, organizations should enforce strict review processes for production secrets, limit OIDC trust policies, utilize GitHub Apps or short-lived tokens instead of personal access tokens, and operate self-hosted runners as temporary machines devoid of Docker socket access.
Stay informed about these developments by following us on Google News, Twitter, and LinkedIn for more exclusive insights.
