GLOBAL CYBERSECURITY BULLETIN — Cloud security researchers have uncovered and disrupted a sprawling, highly automated campaign that systematically targeted thousands of GitHub repositories. Dubbed "Gheist," the operation utilized stolen access tokens to plant malicious, secret-stealing GitHub Actions workflows across more than 13,500 individual branches.

The campaign underscores a dangerous evolution in software supply chain attacks, where threat actors are moving away from traditional malware hosting and toward the weaponization of native development platform features. By turning GitHub Actions—a legitimate continuous integration and continuous deployment (CI/CD) automation tool—into a credential-harvesting engine, the attackers attempted to extract high-value production secrets at a massive scale.

Main Facts: The Anatomy of the Gheist Campaign

The Gheist campaign represents a calculated attempt at mass exploitation leveraging stolen credentials. According to telemetry and analysis published by cloud security firm Wiz, the operation began attracting attention in mid-September. The threat actors systematically swept through personal projects, open-source repositories, and private corporate codebases using valid authentication tokens harvested from previous infostealer infections and historic supply chain breaches.

Key Highlights of the Operation:

• Massive Scale: The attackers infiltrated over 850 compromised user accounts, creating malicious branches and injecting automated workflows across more than 13,500 distinct repository branches.
• The Mechanism: Using stolen personal access tokens (PATs) and OAuth tokens, the attackers committed a customized GitHub Actions workflow designed to print repository secrets directly into the build logs.
• C2-Less Exfiltration: Instead of relying on traditional command-and-control (C2) infrastructure to exfiltrate data, the scripts used GitHub’s own application programming interface (API) to download the execution logs containing exposed secrets, promptly deleting the run seconds later to cover their tracks.
• Mixed Motivations: Beyond credential harvesting, Wiz researchers noted that some of the compromised accounts were concurrently leveraged for cryptomining operations and general malware distribution.
• Platform Defenses: A recent security control implemented by GitHub in late July—which halts unapproved workflow runs in public repositories—successfully thwarted the public-facing aspects of the attack, though private repositories and enterprise servers remained vulnerable.

Chronology of the Threat: From Inception to Disruption

Understanding the timeline of the Gheist campaign reveals how modern threat actors stitch together disparate attack vectors—ranging from endpoint infostealers to automated cloud resource enumeration—into cohesive, high-speed campaigns.

March – September 2024: The Supply Chain Catalyst

The groundwork for the Gheist campaign was laid months prior through foundational security incidents. Wiz identified that the primary sources of the stolen tokens utilized in the campaign stemmed from widespread infostealer logs and previous high-profile software supply chain compromises. Notably, incidents such as the March compromise of the widely used Trivy security scanner populated underground marketplaces and log repositories with valid, high-privilege GitHub tokens.

September 15, 2024: Wiz Identifies the Gheist Campaign

Wiz researchers formally began tracking the Gheist campaign on September 15, observing a sudden surge in anomalous API requests and automated branch creation across diverse GitHub accounts. The researchers noted that the threat actors wasted no time; the moment a token was acquired, automated scripts queried every repository, organization, and project the token could access, regardless of whether it belonged to an individual hobbyist or a Fortune 500 enterprise.

July – October 2024: The Impact of Platform Controls

A critical turning point in the timeline involves GitHub’s proactive security measures. On July 28, GitHub rolled out a security control designed to mitigate workflow abuse in public repositories. This mechanism places potentially malicious or unverified workflow runs originating from fork or newly created branches in public repositories on an action_required hold until explicitly approved by a repository collaborator.

When Gheist actors attempted to execute their harvesting workflows in public repositories, every single instance encountered this roadblock. However, because this specific protection did not extend to private repositories or self-hosted GitHub Enterprise Server deployments, the attackers found uncontested success behind closed doors.

October 24, 2024: Remediation and Evolution

Following coordinated disclosures and incident response efforts, roughly two-thirds of the implicated accounts were rendered unavailable or scrubbed from GitHub by October 24. Despite these takedowns, Wiz warned that the Gheist campaign remains active, with operators continuously modifying their toolsets, iterating on their scripts, and adapting to platform-level defenses.

Supporting Data: Technical Mechanics and Tool Variants

The technical execution of the Gheist campaign highlights a sophisticated understanding of developer platforms and cloud infrastructure. The attackers operated primarily through two parallel script variants, designed to maximize the extraction of sensitive data from both standard repositories and complex enterprise environments.

The Workflow Trick

The core exploit relied on a deceptively simple YAML-based GitHub Actions workflow. When committed to a newly generated attacker branch, the workflow executed commands designed to echo environment variables and repository secrets into the standard output stream of the build log.

# Conceptual representation of secret-printing workflow logic observed in Gheist
name: CI-Check
on: [push, workflow_dispatch]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Dump Secrets
        env:
          SECRET_TOKEN: $ secrets.PROD_API_KEY 
        run: |
          echo "Dumping environment configuration..."
          echo $SECRET_TOKEN > leaked_secrets.txt
          # API call to fetch and delete logs executed programmatically

Rather than transmitting these logs to an external server—which might trigger network-layer intrusion detection systems (IDS)—the automation script utilized GitHub’s REST API to fetch the run logs locally, parsed the sensitive strings, and deleted the workflow run history within seconds. This left minimal forensic artifacts within the standard web UI.

Variant Analysis and Enterprise Infiltration

Wiz documented two distinct variants of the tool running in parallel throughout the campaign:

1. Deployment Environment Targeting: The first variant added native support for GitHub deployment environments. Because developers frequently store high-value production credentials (such as AWS IAM keys, production database passwords, and signing certificates) within environment-scoped secrets rather than repository-wide secrets, this variant allowed attackers to target crown-jewel assets.
2. Self-Hosted Runner Enumeration: The second variant incorporated a job specifically engineered to scan self-hosted CI/CD runners. These runners often possess persistent access to local networks, internal tooling, and cached cloud credentials. Although Wiz noted that this specific job implementation was occasionally "buggy," its inclusion signals an intent to pivot from cloud-hosted environments directly into corporate internal networks.

Following successful secret extraction within enterprise organizations, Wiz observed threat actors pivoting directly to cloud environments. Within hours of repository compromise, cloud credentials harvested from the GitHub workflows were actively used to enumerate Amazon Web Services (AWS) Secrets Manager, illustrating a seamless pipeline from code repository compromise to cloud infrastructure takeover.

Official Responses and Ecosystem Reactions

The discovery of the Gheist campaign has triggered renewed urgency across the software development and cybersecurity communities regarding the secure management of API tokens, personal access tokens (PATs), and CI/CD pipeline permissions.

Platform Security Enhancements

GitHub’s implementation of the July 28 control mechanism proved to be the single most effective barrier against the public-facing component of the Gheist campaign. By requiring manual collaborator approval for workflow runs on untrusted or newly created branches in public repositories, GitHub effectively neutralized mass automated exploitation in the open-source ecosystem.

However, security advocates have publicly urged platform operators to extend these protective holds to private repositories and enterprise server instances, noting that enterprise codebases represent the highest-value targets for financially and espionage-motivated threat actors.

Guidance from Security Researchers

Wiz and other leading security organizations have issued comprehensive remediation guidelines for organizations and individual developers affected by the incident:

• Token Revocation and Rotation: Any organization flagged as potentially compromised must immediately revoke all active GitHub PATs, OAuth tokens, and GitHub Actions secrets.
• Audit CI/CD Run Logs: Security teams are advised to review historical GitHub Actions audit logs for anomalous branch creation, sudden workflow deletions, and unusual API query patterns.
• Transition to Fine-Grained Tokens: Developers are strongly encouraged to phase out legacy personal access tokens in favor of fine-grained PATs that adhere strictly to the principle of least privilege, limiting access scopes to specific repositories and necessary permissions.
• Monitor Cloud Environments: Because the Gheist attackers rapidly pivoted from GitHub secrets to AWS Secrets Manager, organizations must enforce tight monitoring and anomaly detection on cloud credential usage following any suspected developer account compromise.

Implications: The New Frontier of Software Supply Chain Risk

The Gheist campaign serves as a watershed moment for software supply chain security, illustrating a fundamental shift in how adversaries view developer platforms.

For years, supply chain security focused heavily on dependency confusion, malicious npm or PyPI packages, and compromised build dependencies. Gheist demonstrates that attackers no longer need to trick developers into installing malicious libraries if they can subvert the native automation infrastructure that compiles, tests, and deploys the software in the first place.

The Weaponization of Native Features

By turning GitHub Actions—a feature relied upon by millions of developers worldwide to streamline software delivery—into a native credential-theft mechanism, the Gheist threat actors highlighted the inherent risks of "living off the cloud." When platform features are designed for maximum convenience and automation, they can frequently be repurposed by attackers to bypass traditional perimeter security controls.

The Persistent Threat of Credential Theft

Ultimately, the campaign underscores the fragility of authentication models reliant solely on static access tokens. Whether a token is stolen from an infected developer workstation via an infostealer or leaked through an earlier supply chain compromise, its misuse can cascade rapidly across connected cloud services.

As software engineering becomes increasingly cloud-native and automated, security postures must evolve beyond perimeter defenses. Securing the modern software development lifecycle (SDLC) now requires treating GitHub repositories, CI/CD runners, and associated cloud secret stores as critical enterprise infrastructure demanding the same rigorous Zero Trust architecture applied to corporate production environments.