Has the Gheist campaign stolen secrets from my GitHub repositories, and what should I do?

Look for ci-sync branches

Check every repository you or your clients run, including private repositories and GitHub Enterprise Server. With the GitHub CLI, for one repository:

gh api --paginate "repos/OWNER/REPO/branches?per_page=100" --jq '.[].name' | grep -E '^ci-sync-[0-9a-z]{6}$'

Or across a whole organisation:

gh repo list ORG --limit 1000 --json nameWithOwner --jq '.[].nameWithOwner' |
 while read -r r; do
  gh api --paginate "repos/$r/branches?per_page=100" --jq '.[].name' |
   grep -E '^ci-sync-[0-9a-z]{6}$' | sed "s|^|$r |"
 done

On GitHub Enterprise Server, set GH_HOST to your server first. Any match needs the reactive steps below, even if the run has gone.

Put a reviewer in front of production secrets

Add required reviewers to every deployment environment that holds production secrets. GitHub documents that a job cannot access environment secrets until a reviewer approves it. Never approve a held or pending sync-check run.

Tie cloud OIDC trust to protected branches or environments

If workflows sign in to your cloud with OpenID Connect, make the trust policy accept only protected branches or named environments, never any branch. For example, an AWS trust policy condition such as:

"token.actions.githubusercontent.com:sub": "repo:ORG/REPO:environment:production"

Combined with required reviewers, a pushed ci-sync branch can then no longer assume the role.

Cut down write access and long-lived tokens

Anyone with write access to a repository can read every secret configured in it, so audit write access across people, automation accounts and integrations, and remove what is not needed. Prefer GitHub Apps or short-lived fine-grained tokens over classic personal access tokens.

Harden runners and developer machines

Run self-hosted runners as short-lived machines, without access to the Docker socket and without open access to cloud metadata. Check developer machines for infostealer malware, because stolen tokens are the entry point for this campaign.

Confirm the commit

For each ci-sync branch, check the commit. A match has the message ci: sync config, is unsigned and only adds .github/workflows/sync-check.yml.

gh api "repos/OWNER/REPO/commits/ci-sync-xxxxxx" \
 --jq '.commit.message, .commit.verification.verified, .files[].filename'

Then compare the workflow file's blob SHA with the known values in the IOC table below:

gh api "repos/OWNER/REPO/contents/.github/workflows/sync-check.yml?ref=ci-sync-xxxxxx" --jq .sha

The list is not exhaustive: versions that list deployment environments differ per repository, so a different SHA does not clear the branch.

Search the GitHub audit log

Look for activity whose user agent contains gheist (the full value has not been published), and for workflow runs on ci-sync branches that were deleted within a minute of finishing. Runs can last several minutes, so measure from when the run finished, not when it started. In private repositories and on GitHub Enterprise Server, this pattern of a run completing and then being deleted is how the campaign shows up.

Check cloud sign-ins from workflows

In your cloud logs, such as AWS CloudTrail, look for OIDC role assumptions whose subject contains ci-sync-. The default subject only includes the branch when the job does not use a deployment environment, so also review environment-based sign-ins around the same times. Then look for unusual use of any credentials those roles or secrets could reach, including listing or reading secrets stores.

Check self-hosted runners

On any self-hosted runner that could have run a ci-sync job, look for the helper files .gdmp_pat, .gdmp_patg and .gdmp_sweep. gdmp-pivot is not a file: it is a header the job writes to its log, so search job logs and runner diagnostic logs for it. The runner job searches for 31 types of credential, including private keys, process environments, cloud instance role credentials, runner credential files and Kubernetes service account tokens.

find / -xdev \( -name .gdmp_pat -o -name .gdmp_patg -o -name .gdmp_sweep \) 2>/dev/null
grep -rl "gdmp-pivot" /path/to/actions-runner/_diag 2>/dev/null

Replace the runner path with your own install folder. Exported job logs from GitHub are worth searching too, if you still have them.