> Gheist turns GitHub Actions into a secret extraction service

A threat actor dubbed Gheist is turning compromised GitHub accounts into credential-harvesting platforms. By planting malicious GitHub Actions workflows in private repositories, the attackers can expose repository and environment secrets, then retrieve them through GitHub APIs before deleting evidence of the activity. Tracked since September 15 by Wiz Research, the campaign has left more than 13,500 malicious branches across over 850 compromised accounts, spanning personal projects and private enterprise repositories. The campaign’s weapon is GitHub Actions, the platform’s automation service, which attackers are using to turn stolen access into harvested credentials. The automation creates a branch, adds a workflow named “sync-check” that attempts to print secrets into execution logs, retrieves those logs through the GitHub API, and deletes the workflow run seconds later. “Because the secrets leave through GitHub’s own API, there is no attacker domain or outbound connection to block,” Wiz researchers said in a blog post. GitHub has introduced a control that holds potentially malicious workflow runs in public repositories for collaborator approval. Wiz reported that this measure successfully prevented the public-repository Gheist runs from executing. However, the protection does not extend to private repositories or GitHub Enterprise Server, where the researchers observed successful execution and subsequent activity. Base32 encoding used for bypassing secret masking Gheist actors were seen taking advantage of a gap between GitHub Actions’ secret-masking mechanism and the way workflows can access sensitive values. GitHub masks secret values when they appear verbatim in logs. However, a Gheist-created workflow encodes these secrets in base32 before printing them, so they no longer match the original values. Consequently, they appear in logs without being masked. In repositories that use deployment environments, such as production, Gheist created multiple workflow jobs to target environment-specific secrets. This potentially exposed not only secrets stored at the repository level but also sensitive credentials used to run production systems. Gheist subsequently evolved to target self-hosted GitHub Actions runners. Its added sync-host job attempts to search runner hosts for API tokens, private keys, environment files, cloud credentials, and other sensitive data. It also attempts to access the Docker socket, cloud instance metadata, and Kubernetes service-account tokens. Wiz noted that the evolved variant contains implementation bugs, so successful extraction of every targeted credential should not be assumed. A broader cloud security problem Wiz observed cloud credentials from the same organization being used hours after the malicious workflows ran to enumerate AWS Secrets Manager. CloudTrail records also showed workflows on attacker-created branches assuming AWS roles, providing evidence of execution even where GitHub logs were unavailable. Wiz traced likely credential sources to infostealer logs and tokens exposed in earlier supply-chain compromises, including the March Trivy compromise. The researchers also identified overlaps between affected accounts and other malicious activity, including repositories renamed to distribute cracked-software lures and attempts to abuse GitHub Actions for free computing resources. Security teams were advised to search for branches matching “ci-sync-,” followed by six random characters, commits titled ci: sync config, and workflow runs that complete and are deleted shortly afterward. They should also investigate cloud role assumptions associated with these branches, revoke compromised tokens, and rotate every repository, organization, and environment secret accessible to affected workflows. Deleting a branch or run does not reverse a credential exposure, the researchers warned.