Gheist Hackers Abuse GitHub Tokens to Steal Repository Secrets

An ongoing and evolving campaign underway for more than a month has been using stolen GitHub tokens to plant workflows that print a repository’s secrets into its own workflow log, download the log through the GitHub API, and then delete the run within seconds.

The campaign, dubbed “Gheist” after the user agent carried in the tool’s API requests, has been ongoing since September 15, and while a control put in place by GitHub in July is now blocking exploitation in public repositories, the protection doesn’t extend to private repositories and GitHub Enterprise environments, according to Wiz researchers Rami McCarthy and Hila Ramati.

Google-owned Wiz has recovered more than 13,500 branches from more than 850 compromised accounts that included personal projects and enterprises’ private repositories, McCarthy and Ramati wrote in a report. About two-thirds of involved accounts are no longer on GitHub, likely because of Wiz reporting the activity to GitHub operators, they added.

Printing Secrets

During an attack, the tool creates a branch named “ci-sync-“ along with six random characters for each repository and commits a GitHub workflow that prints the repository secrets onto its own log. The commit is unsigned and made to appear to be written by the token’s owner. Pushing this kicks off the workflow.

“In enterprise organizations, we saw the tool cycle through tokens of several users and automation accounts within minutes, clone private repositories before planting the workflow, and hours later, cloud credentials from the same organization used to enumerate AWS Secrets Manager,” McCarthy and Ramati wrote.

An Evolving Threat

They also noted the payload has continued to evolve, with two variants that have been seen working in parallel. One includes support for all deployment environments in the repository, which means secrets in those environments, which are often production credentials, print as well.

On October 19, one variant began pushing another job, this one for self-hosted runners, which are machines in GitHub Actions that organizations run and manage themselves to execute CI/CD workflows as an alternative to using virtual machines provided by GitHub.

The aim is to search the runner machines for a broad range of credentials, including 31 types of tokens – including keys for AI players like Anthropic, Hugging Face, Groq, and Nvidia – as well as private keys, Terraform state, and shell history. Attackers also search for instance-role credentials from Amazon Web Services as well as metadata from Google Cloud Platform (GCP) and Microsoft’s Azure, GitHub Action and GitLab runner credential files, and the Kubernetes service account token.

A ‘Buggy’ Runners Scheme

“However, this job is buggy: it looks for the wrong runner key file, its URL-credential regex is broken, and it doesn’t collect GCP or Azure tokens,” McCarthy and Ramati wrote.

Gheist operators were hindered by the control GitHub instituted July 28. The control puts possibly malicious workflow runs in public repositories until a collaborator approves them, and the researchers wrote that every public Gheist run they checked, across all variants, sits as action_required. The malicious payloads never ran, showing that the control worked, they added.

However, the hold doesn’t apply to private repositories or GitHub Enterprise Server, McCarthy and Ramati wrote.

Using Compromised Credentials

Wiz researchers also found that other campaigns are using the same accounts as those in Gheist, spotlighting how already compromised credentials can be passed from one campaign to another. Wiz researchers could trace such credentials to sources such as infostealer logs and tokens exposed in previous supply-chain attacks like the compromise of the Trivy vulnerability scanner in March.

On October 6, 391 accounts renamed 1,461 repositories that are cracked software and spread malware. Many of the 391 accounts also were used by Gheist, and the renaming wiped out 610 ci-sync branches.

Some of Gheist’s victims also appear to be infected with PolinRider, a supply-chain malware linked to North Korea-nexus threat actors. On October 19 and 20, three victims re-pushed their Gheist commits with a loader appended to vite.config.js. In addition, 57 accounts from Gheist’s first phase were also victims of the Megalodon malware in May.