Gheist Campaign Abuses Stolen GitHub Tokens to Exfiltrate Secrets Through Actions Logs
A newly documented automated campaign is turning one of GitHub's most mundane features — the Actions build log — into an exfiltration channel. According to an analysis published by cloud security firm Wiz and reported by The Hacker News, attackers are using stolen GitHub tokens to commit malicious workflow files that print a repository's secrets into its Actions logs. The operators then download those logs and delete the workflow runs, leaving little obvious trace behind.
The activity, tracked as Gheist, has reportedly succeeded against private repositories as well as GitHub Enterprise environments — a notable detail, since private repos and enterprise tenants are often assumed to be shielded from this class of abuse by default.
How the Attack Chain Works
The technique is deceptively simple, which helps explain its effectiveness. Rather than attempting to crack secret storage directly, the attackers borrow the repository's own CI/CD pipeline as a confused deputy:
- Token compromise. The campaign relies on stolen GitHub tokens — credentials that grant programmatic access to repositories, organizations, or automation. How the tokens were originally obtained is not detailed in the reporting, but leaked tokens in scripts, logs, third-party integrations, and developer machines remain a common source.
- Workflow injection. With a valid token, the attacker pushes a workflow file into the repository. GitHub Actions workflows are code, and code committed with sufficient permissions executes automatically on the platform's runners.
- Secret printing. The planted workflow references the repository's configured secrets and writes their values into the job output. Because Actions logs are designed to capture build output, the secrets land in the log stream.
- Log retrieval and cleanup. The attackers download the resulting logs, then delete the workflow runs, reducing the chance that a casual review of the Actions history surfaces the malicious job.
Why the Log Channel Matters
CI/CD platforms are increasingly the soft underbelly of software supply chains. Workflows routinely hold credentials for package registries, cloud providers, deployment targets, and signing infrastructure. Once an attacker can author a workflow, the secrets available to that workflow become reachable — not through a storage breach, but through ordinary, sanctioned platform behavior.
The cleanup step is what makes Gheist harder to spot. Deleting a run removes it from the visible Actions timeline, so a repository owner who inspects only the current workflow list may see nothing amiss. Detection therefore depends on audit logs, webhook telemetry, and monitoring for workflow creation events rather than on the run history alone.
GitHub's Safeguard and Its Limits
According to the reporting, GitHub operates a safeguard that pauses in certain circumstances when suspicious workflow activity is detected. That control is meaningful, but the campaign's reported success in private and enterprise contexts indicates it is not a complete barrier. Organizations should treat platform-side protections as one layer among several rather than as a substitute for their own monitoring and credential hygiene.
What Defenders Should Do
Wiz's findings point toward a set of practical controls for teams that rely on GitHub Actions:
- Inventory and rotate tokens. Treat personal access tokens and GitHub App credentials as high-value secrets. Enforce short expiration, scope them narrowly, and rotate anything that may have been exposed in logs, repositories, or third-party tooling.
- Restrict who can push workflows. Limit write access to
.github/workflows/and require review for changes to workflow files. A stolen token with repo write access is far less dangerous if workflow modifications require a second approver. - Monitor for workflow creation. Alert on new or modified workflow files, especially those introduced outside normal business hours or by accounts with unusual behavior. Audit log streaming to a SIEM is the most reliable way to catch run deletions.
- Minimize secret exposure to workflows. Use environment-scoped secrets, require manual approval for protected environments, and prefer short-lived OIDC-based cloud credentials over long-lived static keys that a rogue workflow could print.
- Review Actions history for gaps. Deleted runs and missing run IDs are themselves a signal. Baseline normal workflow activity so anomalous gaps stand out.
The Bigger Picture
Gheist is a reminder that supply chain attacks do not always require a compromised dependency or a zero-day. Sometimes the attacker simply logs in with a credential that was already loose and asks the platform to do the work. As CI/CD systems accumulate more privilege, the logs they produce become an attractive target — both for attackers exfiltrating data and for defenders hunting for evidence.
The full technical analysis is available via The Hacker News.
