Nila Kartika Wati
In a sophisticated and highly automated offensive operation, a threat actor has successfully infiltrated the software supply chain by compromising over 850 GitHub accounts and injecting malicious workflows into more than 13,500 repositories. The campaign, dubbed "Gheist" by cloud security firm Wiz, represents a significant evolution in how attackers leverage stolen session tokens to harvest sensitive credentials at scale, turning legitimate CI/CD automation features into a potent data exfiltration mechanism.
While the incident highlights the resilience of modern platform-level security controls, it also serves as a stark reminder of the persistent vulnerability of private enterprise environments. As the campaign continues to evolve, it underscores the critical need for robust token management and stricter oversight of automated workflows in the software development lifecycle (SDLC).
The Chronology of the Gheist Campaign
The Gheist campaign first emerged on the radar of security researchers on September 15, 2024. Over the subsequent weeks, attackers systematically abused stolen access tokens—likely obtained through earlier supply chain compromises and widespread infostealer malware—to compromise a staggering number of public and private repositories.
The Initial Phase (Mid-September)
Beginning in mid-September, the threat actors began systematically scanning and injecting malicious GitHub Actions workflows. By utilizing stolen tokens, the attackers were able to bypass standard authentication hurdles, allowing them to create branches and commit malicious code across a broad spectrum of projects. From small personal open-source projects to complex private enterprise repositories, no target appeared to be off-limits.
The Escalation (Late September to Mid-October)
By October, the campaign had matured significantly. Researchers observed two distinct variants of the attack tool running in parallel. The first variant focused on broad exfiltration, while the second introduced more sophisticated capabilities, such as targeting deployment-specific secrets—often the "keys to the kingdom" for production environments. During this period, the attackers were also observed using stolen cloud credentials to enumerate Amazon Web Services (AWS) Secrets Manager, indicating a clear pivot from simple repository access to broader cloud infrastructure compromise.
Response and Disruption (October 24–25)
Following a coordinated reporting effort to GitHub, the platform began purging the compromised accounts. As of October 24, approximately two-thirds of the implicated accounts had been neutralized. Despite this progress, Wiz researchers confirmed on October 25 that the campaign remains active and continues to shift its tactics to avoid detection.
Anatomy of the Attack: Weaponizing Automation
The brilliance—and the danger—of the Gheist campaign lies in its use of GitHub’s own features to facilitate the theft. By weaponizing GitHub Actions, the attackers transformed a tool designed for continuous integration and delivery into a sophisticated credential harvesting engine.
Workflow Injection and Log Exfiltration
The attack flow was deceptively simple yet highly effective:
- Branch Creation: Using stolen access tokens, the attackers created new branches in targeted repositories.
- Workflow Injection: They committed a malicious GitHub Actions workflow file (
.github/workflows/) into these branches. - Secret Exfiltration: The workflow was designed to print repository secrets—such as API keys, cloud provider tokens, and encryption keys—into the workflow’s own execution logs.
- API-Driven Harvesting: The attackers then leveraged GitHub’s API to download these logs remotely.
- Clean-up: Within seconds, the attackers deleted the workflow run, leaving virtually no trace in the repository’s history or UI, effectively bypassing many standard audit procedures.
This method eliminated the need for an external command-and-control (C2) server, as the data exfiltration was handled entirely through GitHub’s own infrastructure, significantly complicating detection efforts.
The Role of GitHub’s "Approval Hold" Control
A critical turning point in the campaign was the impact of a security control introduced by GitHub on July 28, 2024. This feature mandates that potentially malicious workflow runs in public repositories be placed on hold until a repository collaborator manually approves them.
Success in Public Repositories
Wiz observed that every public Gheist run they examined remained in an action_required state. Because the attackers could not provide the necessary manual approval, the malicious workflows were prevented from executing in these public contexts. This control effectively neutralized the threat for the vast majority of open-source projects targeted by the attackers.
The Private Repository Gap
However, the security landscape changes dramatically when moving from public to private repositories. The current GitHub security architecture does not extend this "approval hold" requirement to private repositories or instances of GitHub Enterprise Server. In these environments, the attackers found an open door. The malicious workflows were permitted to complete their execution on the attacker-created branches before the runs were deleted, allowing the exfiltration of sensitive environment-scoped secrets that are often used for production deployments.
Implications for Enterprise Security
The Gheist campaign is a masterclass in modern supply chain exploitation. It highlights that even when an organization has secured its perimeter, the "soft underbelly" of developer tooling and automated workflows remains a prime target for sophisticated actors.
The Threat of "Buggy" but Dangerous Tools
Wiz noted that the attackers were not just using a single script, but were actively iterating on their tools. One variant of the attack included a job designed to search self-hosted runners for credentials and other sensitive files. While researchers described this specific job as "buggy," its mere presence signals an intent to move laterally from code repositories into the underlying build infrastructure.
The Persistence of Stolen Tokens
The root cause of the Gheist campaign—the availability of stolen access tokens—remains a systemic issue. Sources for these tokens include:
- Infostealer Logs: Malware campaigns that scrape browser cookies and session tokens from developer machines.
- Supply Chain Compromises: Incidents like the March 2024 compromise of the Trivy security scanner, which provided the attackers with a treasure trove of valid credentials.
Once these tokens are in the wild, they grant attackers the same level of access as the developer or automation system, making detection nearly impossible without specialized behavioral analytics.
Official Responses and Remediation Strategies
GitHub has been actively involved in mitigating the fallout of the Gheist campaign, primarily through the removal of compromised accounts and the refinement of their platform-wide security policies. However, the burden of defense ultimately falls on the organizations utilizing these platforms.
Recommendations for Security Teams
To mitigate the risk of similar campaigns, organizations should adopt a "zero-trust" approach to their GitHub environment:
- Implement Principle of Least Privilege (PoLP): Ensure that GitHub tokens are scoped as narrowly as possible. Avoid using broad "repo" or "admin" scopes for automation tasks.
- Rotate Secrets Regularly: If an account or a repository is suspected of being compromised, rotate all secrets, keys, and tokens immediately, regardless of whether there is evidence of exfiltration.
- Monitor CI/CD Logs: Security teams should implement automated monitoring for suspicious workflow activity, specifically looking for workflows that print environment variables or secrets to logs.
- Restrict Self-Hosted Runners: If possible, minimize the use of self-hosted runners, or ensure they are isolated from sensitive internal networks and audited frequently.
- Enforce Approval Policies: For sensitive repositories, organizations should consider enforcing strict branch protection rules that require manual approval for all code changes, including changes to CI/CD configuration files.
Conclusion: The New Frontier of Supply Chain Defense
The Gheist campaign serves as a sobering reminder that the security of the software supply chain is a moving target. As platforms like GitHub introduce sophisticated protections, attackers respond with equally sophisticated methods of abuse. By shifting from traditional network-based attacks to the weaponization of legitimate automation, the Gheist actors have demonstrated that the most dangerous vulnerability in an organization may not be a firewall misconfiguration, but a single, over-privileged session token.
As we look toward the future, the integration of AI-driven threat detection and more granular, policy-based access controls for CI/CD pipelines will be essential. The Gheist campaign is likely just one of many such operations, and the ability to detect, contain, and remediate these threats in real-time will be the defining challenge for enterprise security teams in the years to come.
Layla Zulfa
Reynand Wu
Rifan Muazin
Basiran
