Security researchers have uncovered an automated, highly organized threat campaign dubbed Gheist that targets developer infrastructure by mass-abusing compromised GitHub credentials.

Tracked since mid-September, the campaign has planted secret-dumping workflows across more than 13,500 branches spanning over 850 stolen GitHub accounts, affecting everything from open-source hobby projects to private enterprise repositories.

How the Gheist Attack Works

Rather than relying on an external command-and-control (C2) server, Gheist operates entirely within GitHub's own ecosystem by exploiting built-in features and execution logs:

• Token Hijacking: The threat actors leverage stolen Personal Access Tokens (PATs) and compromised credentials sourced from infostealers or prior supply-chain breaches.

• Automated Planting: For every repository accessible to a stolen token, the tool creates a uniquely named branch (ci-sync-[random-hex]) and commits a malicious GitHub Actions workflow file named .github/workflows/sync-check.yml.

• Bypassing Log Masking: GitHub automatically redacts sensitive secrets in workflow logs only when they appear verbatim. The Gheist workflow circumvents this by passing environment and secret variables through a base32 -w 120 encoding pipe, printing the raw secrets in clear text under a different format.

• Environment Matrix Abuse: For repositories configured with deployment environments, the tool leverages job matrices to extract sensitive, environment-scoped production secrets as well.

• Data Harvesting: The malicious workflow executes, dumps the encoded secrets into the action's logs, and the tool uses the GitHub API to download the logs before swiftly deleting the run traces.

Overlaps and Advanced Objectives

Researchers noted that the compromised accounts tied to Gheist are often shared or repurposed across multiple malicious operations, including:

• Cryptomining: Brief instances where compromised accounts spun up "Windows RDP Runner" repositories to hijack GitHub Actions for free compute power.

• Malware Distribution: Overlaps with campaigns like PolinRider, where threat actors injected malicious loaders into JavaScript build configuration files (vite.config.js).

While recent security hardening by GitHub—such as holding suspicious workflow runs for manual approval in public repositories—has significantly mitigated public exposure, private enterprise environments and internal repositories remain prime targets.

Recommended Incident Response & Mitigation

If organizations or developers discover evidence of ci-sync-* branches or anomalous workflow runs, security experts recommend taking immediate action:

• Rotate All Secrets: Instantly rotate every repository, organization, and environment secret that the affected repositories could access. Deleting the malicious branch or workflow run does not reverse prior exposure.

• Revoke Tokens: Revoke the compromised tokens responsible for the pushes and scan the original owners' devices for infostealer malware.

• Check Self-Hosted Runners: If a ci-sync branch executed on a self-hosted runner, treat the physical/virtual host and its cloud instance role (e.g., AWS/GCP/Azure IAM roles) as completely compromised.

• Harden CI/CD Policies: Restrict OpenID Connect (OIDC) trust trust-policies to protected branches, avoid using broad personal access tokens, and ensure self-hosted runners run in ephemeral, highly restricted environments without direct Docker socket or open metadata access.