Gheist Campaign: Using Stolen GitHub Tokens to Plant Exfiltration Workflows
Gheist uses stolen GitHub tokens to plant malicious Actions workflows, covertly exfiltrating data via the platform itself.
The Gheist campaign reveals a new supply chain threat: attackers steal GitHub tokens to gain repository write access, then plant malicious GitHub Actions workflows that use GitHub-hosted runners for data collection and exfiltration. Because they parasitize legitimate CI, use GitHub IPs, and can trigger on push, pull_request, or schedules, they are extremely hard to detect. Defense should focus on token lifecycle governance and workflow auditing.
GitHub, the world's largest code hosting platform, has made its Actions automation pipelines a standard component of CI/CD. But this convenient mechanism is now being weaponized by attackers. The recently exposed "Gheist" campaign demonstrates how attackers use stolen GitHub tokens to turn repositories into covert data exfiltration channels.
The Core of the Attack Chain: From Token Theft to Workflow Injection
The first step of the Gheist campaign is obtaining a valid GitHub token (personal access token or OAuth token). Once such credentials leak, attackers gain write access to the target repository. Unlike traditional direct code theft, Gheist's intent is more stealthy—it plants malicious GitHub Actions workflow files in the repository, leveraging the platform's own automation capabilities to carry out data exfiltration.
The ingenuity of this technique lies in its "parasitic" nature: the malicious workflow exists under the guise of a normal CI script, runs on GitHub-provided infrastructure, and its traffic originates from GitHub's IP ranges, making it very difficult for traditional network perimeter defenses to distinguish it from legitimate build activity.
GitHub tokens fall mainly into two categories: personal access tokens (PATs) and OAuth tokens. PATs are manually created by users to replace passwords for Git operations or API calls, with permissions finely controlled via scopes (such as repo, workflow, admin:org, etc.). OAuth tokens are obtained through the OAuth app authorization flow and represent temporary authorization granted by a user or organization to a third-party application. Both types of tokens are transmitted as Bearer tokens in HTTP headers, and once leaked, attackers can directly call the GitHub API or clone/push code within the validity period. Particularly dangerous is that tokens with the workflow scope allow modification of Actions workflow files—precisely the key prerequisite for the Gheist attack.
How the Exfiltration Workflow Operates
Once triggered, the workflow executes a series of collection actions, packaging sensitive information in the repository—environment variables, access keys, configuration files, and even hardcoded credentials in repository history—and sending it back to an attacker-controlled endpoint. Because the workflow runs on GitHub's hosted runners, attackers need neither to build their own C2 infrastructure nor to maintain a persistent foothold in the target network.
Even more concerning is the design of the trigger mechanism. Attackers can bind the workflow to push, pull_request, or scheduled tasks, meaning that an apparently ordinary code commit could quietly initiate the data exfiltration process. Victims are almost certain not to notice anything unusual in their daily development.
GitHub Actions workflows are defined by YAML files in .github/workflows/ at the repository root, each containing triggers (on), jobs (jobs), and steps (steps). Steps can execute shell commands, call prebuilt Actions, or run custom scripts. Workflows execute on GitHub-hosted runners (Ubuntu, Windows, or macOS virtual machines) that come preinstalled with common toolchains and can access repository secrets (referenced via ${{ secrets.NAME }}). Attackers exploit exactly these features to insert data collection and exfiltration steps into legitimate workflows without directly touching the target network.
Why This Type of Attack Is Hard to Detect
The stealth of the Gheist campaign comes from three layers. First, the workflow files themselves are plaintext YAML, but they exist in the form of normal automation scripts and are easily overlooked during review as infrastructure code. Second, data exfiltration blends into GitHub Actions' normal outbound traffic, and log analysis tools that do not specifically model workflow behavior can hardly identify it. Third, after a token is stolen, the attacker's operations are completely identical at the permission level to those of a legitimate developer, lacking behavioral anomaly signals.
This also explains why this type of attack is regarded in community discussions as a new blind spot in supply chain security—defense efforts have long focused on dependency packages and build artifacts, while detection capabilities for "the build process itself being tampered with" are relatively weak.
GitHub Actions' audit log records key operations performed by organization members, such as the creation, modification, and deletion of workflow files, as well as the generation and use of tokens. But by default, audit logs are visible only to organization owners and have a limited retention period (180 days for GitHub Enterprise Cloud). In addition, workflow run logs record the output of each step, but if attackers encode or obfuscate the exfiltrated data, it remains difficult to identify directly. Therefore, relying solely on platform logs is insufficient to detect Gheist-type attacks; static analysis of workflow files and behavioral modeling of outbound traffic are needed.
Recommendations: From Token Governance to Workflow Auditing
Against such threats, defense should start with the credential lifecycle. Shortening the validity period of GitHub tokens, assigning scopes according to the principle of least privilege, and mandating fine-grained tokens can all significantly reduce the blast radius after credential leakage. At the same time, it is recommended to enable change approval for workflow files in sensitive repositories, so that any added or modified Actions configuration undergoes manual review.
At the auditing level, all workflow files in repositories can be regularly scanned, with focus on anomalous outbound addresses, suspicious secrets access patterns, and scheduled tasks not approved by the CI owner. GitHub's own audit logs should also be incorporated into monitoring, especially sudden changes in the source IPs of token usage.
Fine-grained PATs are an improved credential introduced by GitHub in 2022, allowing permissions to be precisely limited to specific repositories and specific operations (such as content read only, Actions write only), and supporting shorter validity periods (up to 1 year, customizable). Compared with the coarse-grained scopes of classic PATs (such as repo covering read/write access to all repositories), fine-grained tokens can greatly reduce the impact scope after leakage. GitHub also recommends enabling SAML SSO and mandatory token expiration policies for organizations, and enabling branch protection rules requiring approval for workflow file changes (requires GitHub Enterprise) for highly sensitive repositories.
The Next Battleground of Supply Chain Security
The Gheist campaign reminds us that CI/CD pipelines have become part of the attack surface. When attackers can borrow the platform's own execution capabilities, the traditional model of "trust inside, defend outside" ceases to hold. For development teams, governing workflow files as production code may be more urgent than they imagine.
According to Hacker News community discussions, this campaign currently has limited discussion热度 on public channels (19 points, zero comments), which means related intelligence has not yet spread widely, and security teams should proactively investigate suspicious workflow configurations in their own repositories.
One-line Summary
Gheist uses stolen GitHub tokens to plant malicious Actions workflows, covertly exfiltrating data via the platform's own capabilities.
Paragraph Summary
The Gheist campaign reveals a new supply chain threat: attackers first steal GitHub tokens to gain repository write access, then plant malicious GitHub Actions workflow files in repositories, using GitHub-hosted runners to perform data collection and exfiltration. Because the malicious workflows parasitize legitimate CI processes, traffic originates from GitHub IP ranges, and triggers can be bound to push, pull_request, or scheduled tasks, traditional perimeter defenses and log analysis can hardly identify them. Defense should shift to token lifecycle governance (least privilege, short validity periods, fine-grained tokens) and workflow file change approval and regular auditing. The campaign has low public discussion, so security teams need to proactively investigate suspicious configurations.
Related articles
T3 Code: The Open-Source AI Coding Assistant's Comeback Story
T3 Code is an open-source AI coding assistant that unifies subscriptions like Codex and Claude, with powerful remote control and parallel task management.
Never Elected, Yet Ruled New York for 30 Years: The Ultimate Case Study in the Mechanics of Power
Robert Caro's biographies reveal how unelected Robert Moses ruled New York for 30 years through legal drafting and public authorities, and how Lyndon Johnson built leverage as a "powerless" Senate Majority Leader. Unpacking the underlying logic of accumulating and sustaining power.
The CPython 3.10 Recursion Trap and Synthetic Recovery in TokenGuard, an LLM Circuit Breaker
TokenGuard's author recounts a recursion crash caused by OrderedDict.pop in CPython 3.10 and introduces v0.3.0's Loop Nudge synthetic recovery, inline DLP scanning, and other new LLM agent circuit-breaker capabilities.