Gheist Campaign Uses Stolen GitHub Tokens to Exfiltrate Secrets via Workflows

Security researchers at Wiz Research have uncovered an automated exfiltration campaign dubbed Gheist that leverages stolen GitHub tokens to compromise private repositories and harvest embedded secrets. Operating via a custom automated tool identified by its unique API user-agent string, the attacker takes valid developer credentials, enumerates every repository accessible to that user account, and systematically plants malicious branches containing backdoor workflows. Analysis of the operation has uncovered more than 13,500 planted branches across 850 compromised GitHub accounts.

How the Gheist GitHub Campaign Abuses CI/CD Pipelines

The attack chain relies on developer access credentials—such as personal access tokens (PATs) or OAuth tokens—that were harvested through infostealers, compromised developer workstations, or exposed environment files. Once the attacker inputs a stolen GitHub token into the Gheist tool, the automation takes over the exfiltration pipeline:

1. Repository Enumeration: The tool queries the GitHub API using the stolen credential to list all accessible personal, shared, and organization-owned repositories, regardless of whether they are public or private.
2. Branch Injection: For every repository accessible to the token, Gheist automatically creates a new branch and commits a custom GitHub Actions workflow file (located under .github/workflows/).
3. Workflow Execution & Secret Harvesting: When GitHub Actions detects the newly committed workflow file on the branch, the platform automatically provisions a runner and executes the defined jobs. These malicious jobs access the repository’s configured secrets—such as cloud provider access keys, database connection strings, and internal API keys—and print them directly into the workflow’s standard output execution log.
4. Log Collection: The Gheist tool monitors the execution status via the GitHub API, retrieves the resulting build logs containing the dumped secrets, and exfiltrates them back to the attacker’s infrastructure.

This technique is particularly effective because GitHub Actions workflows run with implicit access to repository-scoped secrets by design. While GitHub attempts to automatically mask standard secret values in build logs, attackers routinely bypass naive string-masking filters by base64-encoding environment variables or outputting secrets character-by-character before writing them to the log stream.

Blast Radius and Organizational Impact

The primary danger of the Gheist campaign is lateral movement and secondary supply chain compromise. Developer tokens frequently carry elevated or broad read/write permissions across multiple sensitive repositories within an organization. By automating token exploitation at scale, the attackers turn a single leaked credential into a broad sweep of an enterprise’s entire repository footprint.

When secrets are extracted from CI/CD environments, the blast radius extends far beyond GitHub itself. Harvested environment variables typically include AWS access keys, Azure service principal credentials, database passwords, and third-party API keys (such as Stripe, Slack, or enterprise SaaS integrations). With these credentials in hand, an attacker can pivot from source code repositories into live cloud infrastructure, production databases, and internal communications networks without needing to exploit further software vulnerabilities.

Furthermore, because the Gheist tool creates real branches and triggers standard CI/CD workflow executions, affected organizations risk burning through GitHub Actions runner minutes and polluting repository audit histories while active exfiltration occurs quietly in the background.

Detection and Remediation Guidance

Organizations relying on GitHub for source code management and continuous integration should treat potential token exposures as critical incidents. Because the Gheist tool explicitly uses a consistent user-agent string during API interactions, security teams have direct opportunities for threat hunting and eviction.

Immediate Action Items

• Search API and Audit Logs for Gheist User-Agent: Query GitHub Enterprise audit logs and organization traffic logs for API requests containing the Gheist user-agent string. Identify all user accounts associated with those requests.
• Audit Active Repository Branches: Run automated scripts across organization repositories to search for unrecognized branches created recently, specifically looking for new commits containing modified or added files within .github/workflows/.
• Revoke and Rotate Impacted Credentials: Immediately revoke any personal access tokens, deployment keys, or OAuth authorisations associated with compromised accounts. Treat all repository secrets and environment variables accessible to those tokens as exposed, and rotate associated cloud and infrastructure API keys immediately.

Long-Term Hardening

• Enforce Fine-Grained Personal Access Tokens: Transition the organization away from legacy “classic” GitHub PATs. Enforce fine-grained PAT policies that restrict token lifetime, require explicit resource path definitions, and grant read-only access by default.
• Restrict GitHub Actions Execution: Configure organization-level GitHub Actions permissions to prevent untrusted pull requests or newly pushed branches from automatically executing workflows without explicit approval.
• Implement Strict Workflow Permissions: Set the default GITHUB_TOKEN permissions to read-only across all repositories and require workflows to explicitly grant minimum required permissions (permissions: contents: read).
• Deploy Secret Scanning and Pre-commit Hooks: Implement continuous secret scanning across all repositories to prevent developers from committing hardcoded credentials, mitigating the impact even if a workflow execution log is exposed.