Gheist campaign abuses stolen GitHub tokens to plant sync-check workflows and dump secrets from private repositories

Linha do tempo

1. darkreading.com ↗ · pub. 26/10/2026 15:01 · coletado 26/10 16:00 só resumo do feed

   'Gheist' supply chain attack weaponizes stolen GitHub tokens to harvest cloud secrets from thousands of repositories

   ler a análise desta fonte ocultar

   An ongoing supply chain attack dubbed Gheist is abusing stolen GitHub tokens to harvest credentials, cloud secrets and other sensitive data from thousands of developer repositories, according to Dark Reading. The available article text is limited to the headline and standfirst, so the initial access method, attribution, scale and indicators are not stated. Defenders with GitHub-hosted code and cloud-connected pipelines should treat this as an active credential-theft campaign.

   Technical Details

   • The campaign uses stolen GitHub tokens to access repositories and extract secrets, including cloud credentials.
   • It is described as ongoing and affects thousands of developer repositories.

   Remediation

   The article text provided does not list remediation steps. Standard precautions apply: review and rotate GitHub tokens and any cloud secrets stored in repositories or CI/CD, and audit repository access logs for anomalous activity.

2. infosecurity-magazine.com ↗ · pub. 26/10/2026 12:00 · coletado 26/10 12:01

   Gheist campaign abuses stolen GitHub tokens to plant secret-stealing Actions workflows across 13,500+ branches

   ler a análise desta fonte ocultar

   Wiz has tracked a campaign dubbed Gheist since September 15, in which attackers used stolen GitHub access tokens to plant secret-stealing workflows on more than 13,500 branches. Wiz recovered the branches from more than 850 compromised accounts. The attackers targeted every repository the tokens could reach, from personal projects to private enterprise repositories. Tokens came from infostealer logs and earlier supply chain compromises, such as the March compromise of the Trivy security scanner. A GitHub control introduced July 28 blocked execution in public repositories, but private repositories and GitHub Enterprise Server remain exposed, and Wiz says the campaign is ongoing and evolving.

   Technical Details

   • The attackers used the tokens to create branches and commit a GitHub Actions workflow that printed repository secrets into its own log. They downloaded the log through the GitHub API and deleted the run seconds later, so no external C2 server was needed.
   • The July 28 GitHub control holds potentially malicious workflow runs in public repositories until a collaborator approves them. Every public Gheist run Wiz examined, across all variants, stayed in the action_required state.
   • The control does not cover private repositories or GitHub Enterprise Server. There, Wiz observed workflows completing on attacker-created branches before the runs were removed.
   • In enterprise organizations, the attackers cycled through user and automation account tokens and cloned private repositories. Hours later, cloud credentials from the same organizations were used to enumerate AWS Secrets Manager.
   • Two variants ran in parallel. One added support for deployment environments, exposing environment-scoped secrets that are often production credentials. It later gained a job that searched self-hosted runners for credentials and sensitive files, which Wiz described as "buggy".
   • Some of the compromised accounts were also used for malware distribution and cryptomining.
   • As of October 24, roughly two-thirds of the implicated accounts were no longer available on GitHub, likely reflecting response after Wiz reported the campaign.

   Remediation

   The article states no explicit remediation steps. It implies that stolen or compromised GitHub tokens remain the underlying risk, and that private repositories and GitHub Enterprise Server lack the approval-hold protection.

3. thehackernews.com ↗ · pub. 26/10/2026 04:49 · coletado 26/10 07:00

   Gheist campaign uses stolen GitHub tokens to plant workflows that leak private repository secrets via Actions logs

   ler a análise desta fonte ocultar

   An automated campaign tracked by Wiz as Gheist uses stolen GitHub tokens to push workflows that print a repository's secrets into GitHub Actions logs. The attackers download the logs and then delete the runs. Wiz has recovered more than 13,500 planted branches from more than 850 compromised accounts, and the attacks succeeded in private repositories and GitHub Enterprise environments. As of October 24 the campaign was still active and evolving. A GitHub safeguard that holds suspicious workflow runs stopped every public-repository run Wiz checked, but it does not cover private repositories or GitHub Enterprise Server.

   Technical Details

   • Wiz has tracked the campaign since September 15 and named it after the gheist user agent that the attackers' tool sends with GitHub API requests.
   • For each repository a token can reach, the tool creates a branch named ci-sync- plus six random characters. It commits one file, .github/workflows/sync-check.yml, with the message ci: sync config. The commit is unsigned and carries the token owner's name, and the push starts the workflow.
   • The workflow prints the job environment and every readable secret encoded in base32, which defeats GitHub's log masking. One version also runs a job per deployment environment, exposing environment-scoped secrets that are often production credentials. The workflow sets an empty permissions block, which does not stop it from reading secrets.
   • The tool downloads the log through the GitHub API and deletes the run seconds later. Secrets leave through GitHub itself, so there is no attacker server or outbound connection to block.
   • In enterprise organizations the tool cycled through tokens from several users and automation accounts within minutes and cloned private repositories before planting the workflow. Hours later, cloud credentials from the same organization were used to enumerate AWS Secrets Manager. Wiz does not say where those credentials came from or who used them. AWS CloudTrail showed the organization's own workflows running on the planted branches and assuming AWS roles.
   • Since July 28, GitHub has held flagged workflow runs for approval, but only on public repositories on github.com. Every public Gheist run Wiz checked was still waiting for approval, so its payload never ran.
   • Around October 19, one version began pushing a second job aimed at self-hosted runners. It searches for 31 types of credentials, including private keys, AWS instance role credentials and the Kubernetes service account token. Wiz calls it buggy and reports no successful run.
   • Stolen tokens were traced to infostealer logs and to tokens exposed in earlier supply-chain attacks such as the March compromise of the Trivy scanner.
   • The same accounts are used by other actors. On October 6, 391 accounts renamed about 1,461 repositories to look like cracked software and spread malware, wiping 610 planted branches. Some victims appear infected with PolinRider, which researchers link to North Korea. On October 19-20, three of them re-pushed Gheist commits with a loader added to vite.config.js. 57 of the accounts were also hit by the Megalodon campaign in May.
   • Wiz says Gheist is distinct from GhostAction, whose new variant ran in public repositories until GitHub began blocking it on October 9 (per GitGuardian).
   • Detection: look for ci-sync-[0-9a-z]{6} branches that add only sync-check.yml. In audit logs, look for runs on those branches deleted within a minute of finishing, and for the gheist user agent. In cloud audit logs, look for OIDC role assumptions whose subject includes a ci-sync- branch. On self-hosted runners, look for the files .gdmp_pat, .gdmp_patg and .gdmp_sweep, and the string gdmp-pivot in job logs.

   Remediation

   • Deleting the branch or run does not undo the exposure. Rotate every repository, organization and environment secret the repository could read, and revoke the tokens that pushed the commits.
   • Check the token owners' devices for infostealers.
   • Treat any self-hosted runner that ran a ci-sync branch, and its cloud instance role, as compromised.
   • Do not approve held sync-check runs and do not run code from ci-sync branches.
   • Require reviewers on environments that hold production secrets, and limit OIDC trust policies to protected branches or environments.
   • Use GitHub Apps or short-lived fine-grained tokens instead of personal access tokens.
   • Run self-hosted runners as short-lived machines without Docker socket access or open access to cloud metadata.
4. wiz.io ↗ · pub. 25/10/2026 14:55 · coletado 25/10 16:00 primeiro registro

   Gheist campaign abuses stolen GitHub tokens to plant sync-check workflows and dump repository secrets

   ler a análise desta fonte ocultar

   Since September 15, 2026, Wiz Research has tracked Gheist, a campaign that mass-abuses compromised GitHub tokens. It commits a workflow named sync-check to every repository each token can reach, prints the repository secrets into the workflow log, downloads the log through the GitHub API and deletes the run seconds later. Wiz recovered more than 13,500 planted branches from more than 850 compromised accounts, covering personal projects through to enterprise private repositories. A GitHub control introduced on July 28, 2026 holds workflow runs in public repositories until a collaborator approves them, which blocked exploitation there. Successful exploitation and follow-on activity were still observed in private repositories and GitHub Enterprise environments, including AWS Secrets Manager enumeration hours after the secrets were dumped. The campaign is ongoing and evolving, and the stolen accounts overlap with other actors such as PolinRider and Megalodon.

   Technical Details

   • For each repository the tool creates a branch named ci-sync- plus six random characters. It commits .github/workflows/sync-check.yml with the message ci: sync config, unsigned and authored as the token owner. The push event triggers the workflow.
   • The workflow runs env | base32 -w 120 and echo -n '${{ toJSON(secrets) }}' | base32 -w 120. GitHub masks secrets only when they appear verbatim, so base32-encoded values print in full. permissions: {} restricts only the job's GITHUB_TOKEN, not the secrets context.
   • When a repository has deployment environments, the tool lists them in a job matrix, so environment-scoped (often production) secrets are printed too.
   • Secrets leave through GitHub's own API, so there is no attacker domain or outbound connection to block. API requests carry the user agent gheist.
   • Tool A uses a hexadecimal branch suffix and the plain payload.
   • Tool B (first run September 28) uses a base36 suffix, added timeout-minutes: 6 and the environment matrix, and modifies the payload per repository. On October 19 it added echo X | base32 -w 120, which prints LAFA==== as a separator. Hours later it pushed a second job, sync-host, with runs-on: self-hosted, apparently only to repositories with a registered self-hosted runner.
   • The sync-host job writes .gdmp_pat, .gdmp_patg and .gdmp_sweep and logs each stage under a ===== gdmp-pivot: <stage> ===== header. It collects:
     • host details and crontab;
     • a recursive search for 31 token formats (including Anthropic, Hugging Face, Groq and NVIDIA keys), private keys, .env files, Terraform state and shell history;
     • process environments from /proc/*/environ;
     • a container with the host root filesystem mounted via the Docker socket, used to repeat the search on the host;
     • AWS instance-role credentials and GCP/Azure metadata;
     • GitHub Actions and GitLab runner credential files;
     • the Kubernetes service account token.
   • The job is buggy: it looks for the wrong runner key file, its URL-credential regex is broken, and it does not collect GCP or Azure tokens.
   • Every public Gheist run Wiz checked sits at action_required, so those payloads never ran. The hold does not apply to private repositories or GitHub Enterprise Server. There, audit logs show runs on ci-sync-* branches completing and being deleted by the gheist user agent, and CloudTrail shows the organizations' own workflows running on those branches and assuming AWS roles.
   • In enterprise organizations the tool cycled through tokens of several users and automation accounts within minutes and cloned private repositories before planting the workflow.
   • Roughly two thirds of implicated accounts are no longer available on GitHub, likely due to response activity after Wiz reported them.
   • Credential sources that could be traced were infostealer logs and tokens exposed in earlier supply-chain compromises such as the Trivy compromise in March.
   • Overlaps with other campaigns using the same accounts:
     • Lure repositories: on October 6, 391 accounts renamed about 1,461 repositories to cracked-software lures.
     • Cryptomining: on October 18, 25 accounts each created a "Windows RDP Runner" repository to abuse Actions for free compute.
     • PolinRider (DPRK-linked): on October 19-20, three victims re-pushed their Gheist commits with a loader appended to vite.config.js, and in two cases an api.js run by package.json.
     • Megalodon: 57 accounts from Gheist's first phase were also Megalodon victims in May.
   • Gheist is distinct from GhostAction, which uses different workflow files.

   Remediation

   • Hunt for branches matching ^ci-sync-[0-9a-z]{6}$ whose only change is .github/workflows/sync-check.yml with the commit message ci: sync config.
   • In GitHub audit logs, look for runs on ci-sync-* branches deleted within a minute of completion and any activity from the gheist user agent.
   • With OIDC, check cloud audit logs for role assumptions or token exchanges whose subject includes a ci-sync- branch.
   • On self-hosted runners, look for .gdmp_pat, .gdmp_patg, .gdmp_sweep and the string gdmp-pivot in job logs.
   • Rotate every repository, organization and environment secret available to an affected repository, since deleting the run or branch does not undo exposure.
   • Revoke the tokens that pushed the commits and check their owners' devices for infostealers.
   • Treat any self-hosted runner host and its instance role as compromised if a ci-sync branch ran on it.
   • Do not approve held sync-check runs and do not run code from ci-sync branches.
   • Harden by requiring reviewers on production environments, scoping OIDC trust to protected branches or environments, using GitHub Apps or short-lived fine-grained tokens instead of PATs, and running ephemeral self-hosted runners without Docker socket or unrestricted metadata access.