GitHub Token Theft Campaign Disrupted: Gheist Operation Under Scrutiny
A significant campaign targeting GitHub repositories has recently been brought to a halt after researchers identified that attackers were implanting secret-stealing workflows across over 13,500 branches within various repositories. This malicious effort utilized stolen access tokens, calling into question the security protocols in place for managing sensitive credentials within software development environments.
According to a research report published on October 25 by Wiz, a cybersecurity firm, the campaign, which has been dubbed "Gheist," has been under surveillance since September 15. Wiz disclosed that they successfully recovered the infected branches from more than 850 compromised accounts. The attackers targeted not only personal projects but also private enterprise repositories, indicating a widespread and opportunistic approach to exploitation.
The investigation revealed that the stolen tokens were sourced from infostealer logs and earlier supply chain compromises, notably including the compromise of the Trivy security scanner in March. Some compromised accounts were further misused for distributing malware and engaging in cryptomining activities, underscoring the multifaceted nature of the threats that are emerging in the space of digital asset management.
Workflow Trick Meets GitHub Approval Hold
The attackers employed the stolen tokens to create numerous branches and commit a GitHub Actions workflow specifically designed to print repository secrets into its log. They then accessed this log via GitHub’s application programming interface (API), subsequently deleting the run just moments after creation. This execution strategy eliminated the need for an external command-and-control (C2) server, showcasing a sophisticated understanding of GitHub’s infrastructure.
However, the campaign faced an obstacle introduced by GitHub on July 28, which implemented a control mechanism that places potentially malicious workflow runs in public repositories on hold until a collaborator approves them. This safeguard meant that all public Gheist runs remained in an "action_required" state, effectively impeding the execution of the harmful workflows. Despite this success in containing the public-facing aspect of the campaign, the protection feature does not extend to private repositories or GitHub Enterprise Server environments. In those contexts, Wiz was able to observe workflows completing on attacker-created branches before the runs were subsequently removed, highlighting a vulnerability that remains critical.
The Threat to Private Repositories
Within enterprise organizations, Wiz found that attackers were cycling through user and automation account tokens while cloning private repositories. This activity escalated when, just hours later, cloud credentials from the same organizations were leveraged to inspect the secrets stored within Amazon Web Services’ Secrets Manager. The implication of this action denotes not just a breach of security, but also a potential exposure of highly sensitive and proprietary information.
Interestingly, two variants of the malicious tool operated concurrently. One variant was designed to support deployment environments, thereby exposing environment-scoped secrets, often linking to production credentials. A subsequent job within this variant attempted to search self-hosted runners for credentials and other sensitive files, although Wiz categorized this job as "buggy," indicating limitations in its effectiveness.
As of October 24, approximately two-thirds of the accounts implicated in the Gheist campaign were no longer accessible on GitHub. Wiz suggested that this reduction likely reflected proactive response actions taken post-reporting of the campaign to GitHub. Nonetheless, the researchers noted that the Gheist operation continues to persist and evolve, shedding light on the adaptive nature of cyber threats in contemporary frameworks.
In conclusion, the Gheist campaign serves as a distressing reminder of how stolen GitHub tokens can convert legitimate automation features into a tool for credential theft. While the implementation of newer platform controls has shown effectiveness in mitigating some of the abuse, the core issue of risk associated with compromised credentials remains unresolved. As the cybersecurity landscape continues to evolve, organizations must bolster their security measures to remain vigilant against such opportunistic threats, particularly those that exploit well-known systems and automated processes.