GitHub Disrupts Gheist Attackers' Secret-Stealing Workflow Scheme

More than 13,500 branches were used to plant secret‑stealing workflows across repositories reachable with stolen access tokens, researchers found.

How Gheist turned GitHub automation into a credential siphon

Wiz, which published its findings on October 25, tracked a campaign it dubbed Gheist that began on September 15. Attackers used stolen GitHub access tokens to create branches and commit malicious GitHub Actions workflows that printed repository secrets into the workflow's own log. The operators then downloaded the log using GitHub's API and deleted the run seconds later — a sequence that allowed the campaign to operate without any external command‑and‑control (C2) infrastructure.

The researchers recovered the planted branches from more than 850 compromised accounts and observed the operation target every repository the tokens could reach, from personal projects to private enterprise repositories. The campaign left traces beyond credential theft: some of the compromised accounts were also being used for malware distribution and cryptomining.

Why a July 28 GitHub control blunted public‑repo abuse

Gheist repeatedly ran into a GitHub control introduced on July 28 that places potentially malicious workflow runs in public repositories on hold until a collaborator approves them. Wiz reported that every public Gheist run it examined remained in an action_required state across all variants, which prevented those malicious workflows from executing in public repositories.

That control, however, does not extend to private repositories or GitHub Enterprise Server. In those environments, Wiz observed attacker‑created branches where workflows completed before the runs were removed — allowing thieves to capture secrets in settings not covered by the July 28 restriction.

Private repositories, enterprise tokens, and cloud credential follow‑on

Wiz observed that within enterprise organizations attackers cycled through user and automation account tokens to clone private repositories. Hours after accessing repositories, cloud credentials harvested from the same organizations were used to enumerate Amazon Web Services' Secrets Manager, indicating a rapid pivot from repository access to cloud reconnaissance and credential harvesting.

Two variants of the Gheist tooling ran in parallel. One variant added support for deployment environments, exposing environment‑scoped secrets — which the researchers noted are often production credentials. That variant later gained a job designed to search self‑hosted runners for credentials and other sensitive files; Wiz described that search job as "buggy," but present nonetheless.

Where the stolen tokens came from

Wiz linked the token theft to infostealer logs and earlier supply‑chain compromises. The researchers explicitly pointed to the March compromise of the Trivy security scanner as one of the supply‑chain incidents that supplied tokens. These sources helped fuel Gheist's broad sweep: the operation targeted every repository reachable with the stolen tokens, indiscriminately capturing secrets from small personal projects up to private enterprise codebases.

What this means for enterprise security teams, developers, and maintainers

• Enterprise security teams: Expect rapid pivots from repository access to cloud reconnaissance. In the Gheist instances Wiz observed, tokens that allowed repository cloning were followed within hours by Amazon Web Services' Secrets Manager enumeration using harvested cloud credentials.
• Developers and maintainers (personal and open source): Public repositories benefited from the July 28 hold; private repositories did not. Teams should be aware that workflows committed by compromised accounts can exfiltrate secrets via their own logs and then be promptly deleted to cover tracks.
• Platform and automation owners (GitHub Enterprise Server operators): The July 28 control does not apply to private or self‑hosted environments; operational defenders should assume that attacker‑created branches can run to completion in those contexts unless additional controls are enforced.

As of October 24, roughly two‑thirds of implicated accounts were no longer available on GitHub, a change Wiz said likely reflected response activity after it reported the campaign to GitHub. But the researchers warned that Gheist remained ongoing and continued to evolve — illustrating that platform controls can disrupt operational techniques without removing the underlying risk posed by compromised credentials.

The Gheist campaign is a reminder that legitimate automation capabilities can be abused at scale when adversaries obtain tokens and that platform protections, while effective in some contexts, are not universal. The observable arc here — token theft from infostealers and supply‑chain compromises, mass planting of workflows, and rapid cloud enumeration — poses a straightforward operational question for defenders: where does an organization draw additional protective controls around private repositories and enterprise GitHub instances to prevent the same sequence from repeating?

https://www.infosecurity-magazine.com/news/gheist-attackers-abuse-stolen/