Stolen GitHub tokens fuelled a campaign that planted malicious GitHub Actions workflows to steal repository and cloud credentials.

A sophisticated and automated cyberattack campaign has weaponized the legitimate continuous integration and continuous deployment (CI/CD) features of software development platforms to harvest sensitive enterprise and personal data on a massive scale. Tracked under the moniker "Gheist" by cloud security researchers at Wiz Research, the ongoing operation systematically exploits stolen personal access tokens and OAuth credentials to hijack active GitHub accounts. By planting malicious automation scripts known as GitHub Actions workflows into private and enterprise repositories, the threat actor has managed to bypass traditional perimeter security controls, extract high-value repository secrets and cloud environment keys, and rapidly sanitize the operational footprint to evade immediate detection.

The campaign underscores a rapidly evolving threat vector in modern software supply chain security: the abuse of trusted developer tools. As organizations increasingly rely on cloud-native automation services to accelerate software delivery, adversaries are shifting their focus away from traditional malware deployment and toward the subversion of native platform utilities. This allows malicious actors to operate within authorized parameters, leveraging legitimate APIs and native execution environments to quietly siphon off corporate intellectual property and deeply integrated cloud infrastructure keys.

The Anatomy of the Gheist Operation

First detected by Wiz Research on September 15, the Gheist campaign has exhibited a high degree of automated execution. Rather than manually inspecting compromised repositories or deploying heavy malicious payloads, the threat actor utilizes a streamlined, API-driven methodology designed to operate swiftly and quietly.

The attack sequence typically begins with the unauthorized acquisition of GitHub user tokens, which researchers attribute to prior supply-chain compromises—such as the high-profile March security incidents involving infostealer logs and the Trivy vulnerability scanner backdoor—as well as credential stuffing and leaked authentication tokens. Once an account is accessed, the threat actor’s automation script creates a specialized working branch within the target repository.

Within this rogue branch, the attackers inject a malicious workflow file explicitly named "sync-check." This workflow is engineered to leverage the native functionality of GitHub Actions, an automation framework trusted by millions of developers to build, test, and deploy code. The workflow script executes commands designed to print hidden repository and environment secrets directly into the execution logs.

Crucially, the threat actor evades detection by immediately retrieving these logs through the official GitHub application programming interface (API) and then deleting the workflow run and the malicious branch mere seconds after execution. Because the data exfiltration occurs entirely within GitHub’s native ecosystem, no external command-and-control server is contacted, and no anomalous outbound network traffic is generated that traditional security firewalls or endpoint detection and response (EDR) tools could easily flag and block.

"Because the secrets leave through GitHub’s own API, there is no attacker domain or outbound connection to block," Wiz researchers noted in their public technical breakdown of the campaign.

Bypassing Secret Masking via Base32 Encoding

A key technical hurdle for attackers attempting to steal secrets from CI/CD pipelines is secret-masking. Modern platforms like GitHub automatically scan execution logs for known secret values, replacing them with a string of asterisks (***) if they appear verbatim. This safety mechanism is designed to prevent accidental exposure of sensitive keys during normal debugging and build processes.

To circumvent this protection, the operators behind the Gheist campaign introduced a data encoding phase into their malicious workflows. Before printing sensitive variables to the build logs, the automation script translates the secrets into Base32 encoding. Because the encoded string no longer matches the raw cryptographic signature or plain-text format of the original credential, GitHub’s automated masking engine fails to recognize it as sensitive data. The encoded string is subsequently written to the logs in plain sight, retrieved via the GitHub API by the threat actor, and successfully decoded off-site to recover the original password, token, or API key.

The scale and scope of this technique expanded significantly as the campaign progressed. Initially focused on standard repository-level secrets, the Gheist workflows evolved to target deployment environments—such as staging and production environments—by spawning multiple concurrent workflow jobs designed to harvest environment-specific keys. Furthermore, the threat actor began targeting self-hosted GitHub Actions runners. By executing an additional "sync-host" job, the malicious workflows actively scan host machines for local API tokens, private Secure Shell (SSH) keys, local configuration files, Docker socket endpoints, cloud instance metadata, and Kubernetes service-account tokens.

Scale of the Campaign and Ecosystem Impact

The breadth of the Gheist operation highlights the systemic risks associated with credential hygiene in modern software development ecosystems. According to Wiz Research telemetry, the campaign has successfully planted over 13,500 malicious branches across more than 850 distinct compromised accounts. The affected assets range from small, individual personal projects to highly sensitive private repositories managed by corporate enterprises.

The operational overlap between Gheist and other concurrent cybercriminal activities has also complicated the response efforts of security analysts. Researchers identified instances where accounts targeted by Gheist were simultaneously repurposed for other malicious objectives, including the distribution of cracked software lures via repository renaming and the unauthorized utilization of GitHub Actions compute resources for cryptocurrency mining and resource abuse.

The campaign’s impact extends far beyond the boundaries of the GitHub platform itself. In several instances observed by security analysts, cloud credentials harvested during the workflow executions were actively utilized within hours to enumerate cloud resources, specifically targeting services like AWS Secrets Manager. Post-incident analysis of cloud audit logs, such as AWS CloudTrail, revealed that external identities associated with the attacker-created branches were successfully assuming powerful AWS Identity and Access Management (IAM) roles. This cross-platform escalation provided incontrovertible evidence of unauthorized execution even in scenarios where native GitHub activity logs had already been deleted by the automation script.

Platform Defenses and Institutional Response

In response to the growing wave of supply chain attacks and CI/CD exploitation, platform operators have continuously rolled out security enhancements. GitHub recently introduced a defensive control designed to hold potentially malicious workflow runs originating from public repositories pending manual approval from a designated repository collaborator or administrator.

Independent evaluations by Wiz Research confirmed that this specific mitigation successfully intercepted and blocked Gheist execution attempts targeting public repositories. However, significant security gaps remain. The current iteration of GitHub’s approval control does not automatically extend to private repositories or deployments running on GitHub Enterprise Server instances. Consequently, the researchers observed uninterrupted execution and successful credential harvesting across private environments where these restrictions were absent.

Security experts emphasize that traditional remediation steps—such as simply deleting an unauthorized branch or purging a completed workflow run—are fundamentally insufficient to mitigate an active compromise. Because the exfiltration occurs instantaneously upon execution, deleting the artifact does not invalidate the fact that the underlying secrets were already read, transmitted, and recorded by the attacker.

Mitigation Strategies and Recommendations for Security Teams

For organizations seeking to audit their development environments and protect their infrastructure against Gheist and similar automated supply-chain threats, cybersecurity specialists recommend a rigorous, multi-layered remediation protocol:

1. Threat Hunting and Log Analysis: Security operations centers (SOCs) should actively scan version control system logs for anomalous branch naming conventions—specifically branches matching the pattern ci-sync- followed by six randomized alphanumeric characters. Teams should also look for suspicious commit titles such as ci: sync config and automated workflow runs that complete and are purged within an extremely short timeframe.
2. Comprehensive Credential Revocation: If any indicator of compromise is identified, security teams must immediately revoke all personal access tokens, OAuth tokens, and SSH keys associated with the affected accounts.
3. Aggressive Secret Rotation: Because automated workflows can target broad environmental scopes, organizations must assume that every repository secret, organization-level secret, and production environment variable accessible to the affected workflows has been compromised. A full rotation of all related credentials is mandatory.
4. Cloud Infrastructure Auditing: Security personnel must investigate cloud audit logs (such as AWS CloudTrail, Azure Activity Logs, and Google Cloud Audit Logs) to identify any unauthorized role assumptions, unexpected API calls, or anomalous resource enumeration originating around the time of the suspicious workflow executions.
5. Hardening CI/CD Pipelines: Enterprises should enforce strict least-privilege principles for GitHub Actions, limit the scope of secrets accessible to automated workflows, mandate manual approval gates for all sensitive environments, and carefully audit the use of self-hosted runners to prevent lateral movement from the build environment into core cloud infrastructure.

As software development methodologies continue to converge with cloud infrastructure management, campaigns like Gheist serve as a stark reminder that the security of modern enterprises is inextricably linked to the integrity of their developer tooling. Mitigating these advanced threats will require continuous monitoring, stringent access controls, and a proactive approach to identity and secret management across the entire software development lifecycle.