Gheist Campaign Exploits Stolen GitHub Tokens to Leak Repository Secrets Through Actions Logs

An automated campaign dubbed Gheist is using stolen GitHub tokens to plant workflows that print repository secrets into GitHub Actions logs, which attackers then download and delete, according to an analysis by cloud security firm Wiz. The attacks have succeeded in private repositories and GitHub Enterprise environments.

A GitHub safeguard that pauses suspicious workflow runs stopped every public-repository run Wiz checked, but it does not cover private repositories or GitHub Enterprise Server.

Each workflow sits on a new branch named ci-sync- followed by six random characters. Deleting the branch or the run it started does not undo the exposure - every secret the repository could read should be rotated, and the token that pushed the branch revoked.

Wiz has tracked the campaign since September 15 and named it Gheist after the user agent the attackers' tool sends with GitHub API requests. The company has recovered more than 13,500 planted branches from over 850 compromised accounts, ranging from personal projects to private repositories of enterprise organizations. Wiz's analysis does not say how many organizations had secrets exposed.

In private repositories and on GitHub Enterprise Server, audit logs show runs on the planted branches finishing and then being deleted by the gheist user agent, while AWS CloudTrail logs show the organization's own workflows also running on those branches and assuming AWS roles. In enterprise organizations, the tool cycled through tokens from several users and automation accounts within minutes and cloned private repositories before planting the workflow. Wiz's analysis does not say where later-used cloud credentials came from or who used them.

As of October 24, the campaign was still running and changing, and about two-thirds of the accounts involved were no longer available on GitHub. Wiz reported the activity to GitHub and says their disappearance likely reflects a response.

Anyone with write access to a GitHub repository can read every secret configured in it, according to GitHub's documentation - a stolen token with that access is enough. For each repository a token can reach, the tool creates a ci-sync- branch and commits one file, .github/workflows/sync-check.yml, with the message ci: sync config. The workflow prints the job's environment and every secret it can read, encoded in base32; Wiz says the encoded text no longer matches the original secret, so GitHub's log masking does not apply and it prints in full.

The tool then downloads the log through GitHub's API and deletes the run seconds later. Because the secrets leave through GitHub itself, there is no attacker server or outbound connection to block. One version of the tool also runs a job for each deployment environment in the repository, so environment-limited secrets - often production credentials, according to Wiz - print too.

Since July 28, GitHub has held workflow runs it identifies as potentially malicious until a collaborator with write access approves them. GitHub says the hold currently applies to public repositories on github.com only, and GitHub Enterprise Server does not have it at this time. Every public Gheist run Wiz checked was still waiting for approval, so its payload never ran.

Around October 19, one version of the tool began pushing a second job meant for self-hosted runners, apparently targeting only repositories with such a runner registered. The job searches the runner machine for credentials, including 31 types of tokens: private keys, process environments, AWS instance role credentials, runner credential files, and the Kubernetes service account token. Wiz describes the job as buggy, and its analysis reports no successful run.

The sources Wiz could trace for the stolen tokens include infostealer logs and tokens exposed in earlier supply-chain attacks, such as the March compromise of the Trivy vulnerability scanner. Other attackers also use the same accounts: on October 6, 391 accounts, many also used by Gheist, renamed about 1,461 repositories to appear to be cracked software and spread malware, wiping 610 of the planted branches. Some victims also appear infected with PolinRider, malware researchers have linked to North Korea; on October 19 and 20, three of them re-pushed their Gheist commits with a loader added to a vite.config.js file. Megalodon, a campaign that pushed secret-stealing workflows into thousands of GitHub repositories in May, had also hit 57 of the accounts.

Wiz recommends looking for branches named ci-sync- followed by six characters where the only change is a new .github/workflows/sync-check.yml file with the commit message ci: sync config; checking GitHub audit logs for workflow runs on ci-sync-* branches deleted within a minute of finishing and for activity from the gheist user agent; checking cloud audit logs for role assumptions or token exchanges whose subject includes a ci-sync- branch; and, on self-hosted runners, looking for the files .gdmp_pat, .gdmp_patg and .gdmp_sweep and the string gdmp-pivot in job logs.

For an affected repository, Wiz advises rotating every repository, organization, and environment secret the repository could use; revoking the tokens that pushed the commits and checking their owners' devices for infostealers; treating a self-hosted runner that ran a ci-sync branch, and its cloud instance role, as compromised; and not approving held sync-check runs or running code from ci-sync branches. To make a stolen token less useful, Wiz also recommends requiring reviewers on environments holding production secrets, limiting OIDC trust policies to protected branches or environments, using GitHub Apps or short-lived fine-grained tokens instead of personal access tokens, and running self-hosted runners as short-lived machines without Docker socket access or open access to cloud metadata.

Source: The Hackers News