Gheist Attackers Stumble in Attempt to Abuse GitHub Tokens

A recent campaign targeting GitHub repositories has been disrupted after attackers were found planting secret-stealing workflows across more than 13,500 branches across repositories using stolen access tokens.

In research published October 25, Wiz said it had tracked the campaign, dubbed Gheist, since September 15 and recovered the branches from more than 850 compromised accounts. The operation targeted every repository the stolen tokens could reach, from personal projects to private enterprise repositories.

Wiz identified infostealer logs and earlier supply chain compromises, such as the March compromise of the Trivy security scanner , as sources of the stolen tokens. Some of the accounts were also being used for malware distribution and cryptomining.

Workflow Trick Meets GitHub Approval Hold

The attackers used the tokens to create branches and commit a GitHub Actions workflow that printed repository secrets into its own log. They then downloaded the log through GitHub's application programming interface (API) and deleted the run seconds later, so the campaign needed no external command-and-control (C2) server.

The campaign's main obstacle has been a GitHub control introduced July 28 that places potentially malicious workflow runs in public repositories on hold until a collaborator approves them. Wiz said every public Gheist run it examined, across all variants, remained in an action_required state, preventing the malicious workflows from executing.

The protection does not extend to private repositories or GitHub Enterprise Server. In those environments, Wiz observed workflows completing on attacker-created branches before the runs were removed.

Private Repositories Remain Exposed

In enterprise organizations, Wiz observed the attackers cycling through user and automation account tokens and cloning private repositories. Hours later, cloud credentials from the same organizations were used to enumerate Amazon Web Services' Secrets Manager.

Two variants of the tool ran in parallel. One added support for deployment environments, exposing environment-scoped secrets that are often production credentials. It later gained a job that searched self-hosted runners for credentials and other sensitive files, though Wiz described the job as "buggy."

As of October 24, roughly two-thirds of implicated accounts were no longer available on GitHub, which Wiz said likely reflected response activity after it reported the campaign to GitHub. However, the researchers said Gheist remained ongoing and continued to evolve.

The campaign demonstrates how stolen GitHub tokens can turn legitimate automation features into a credential theft mechanism, while newer platform controls can disrupt some abuse without eliminating the underlying risk from compromised credentials.