Gheist Campaign Plants Unsigned Workflows in 850+ Accounts to Dump Secrets via Base32-Encoded Actions Logs

The campaign, tracked by Wiz since September 15 under the gheist user-agent, targeted private repositories and GitHub Enterprise Server instances where the post-July 28 approval hold does not apply. Attackers cycled through compromised tokens to clone repos, push unsigned commits from legitimate user names, and trigger workflows that set empty permissions blocks while emitting base32-encoded environment variables and secrets. GitHub's masking fails once values are transformed, enabling exfiltration without outbound connections.

Wiz recovered 13,500 branches across personal and enterprise accounts; AWS CloudTrail logs confirm the organization's own workflows executed on those branches and assumed roles, indicating secret exposure occurred before deletion. Two-thirds of affected accounts later vanished, consistent with GitHub remediation after Wiz disclosure. The technique exploits the fact that any write token can read all repo secrets per GitHub documentation, bypassing branch protections that do not cover new workflow files.

This pattern mirrors prior supply-chain token abuse but shifts focus to log-based exfiltration that leaves no external C2. GitHub Enterprise Server lacks the public-repo safeguard entirely, creating a persistent gap for organizations relying on self-hosted instances. Rotation of all readable secrets plus the pushing token is required because branch or run deletion does not revoke prior access.

Next steps include monitoring for ci-sync-* branches in audit logs and pushing GitHub to extend the suspicious-run hold to private and Enterprise environments. Without that change, the vector remains viable for any token theft.