Stolen GitHub Tokens Turn Build Workflows Into Secret Stealers
Researchers at Aikido Security, SafeDep and StepSecurity have documented a campaign using stolen GitHub tokens to plant a credential stealer in repositories. Aikido calls the campaign wfx-loot and traces the activity to 10 November. It counted 4,837 compromised accounts that opened probe pull requests in 61,764 repositories. SafeDep counted malicious commits in 8,093 repositories in its own search window. The two counts measure different stages of the campaign. Aikido’s disclosure · SafeDep’s analysis
Look past the pull request
The attacker tests repository access with a pull request titled docs: dependency audit notes from a branch called wfx-docs. A probe identifies a repository worth investigating. To find evidence that the stealer ran, check later pushes by the same account, including automation accounts that can bypass branch protection. Researchers found the payload in existing and newly created workflows, ordinary shell scripts used by CI and npm lifecycle hooks. Aikido’s campaign timeline · StepSecurity’s repository analysis
An attacker may revert a change and delete the associated Actions run. Compare the repository’s audit and push records with the workflow history, and use retained runner or cloud logs to investigate any gap. StepSecurity documented a surviving run in which the stealer collected data from a self-hosted runner. A successful workflow status can coexist with malicious activity. StepSecurity’s investigation
Revoke the access that made the push possible
Preserve evidence, stop suspicious workflows and revoke the GitHub token used to make the unauthorised push. If the payload ran, rotate credentials the job could access, including registry and deployment tokens and secrets available on self-hosted runners. Review cloud audit logs for unexpected use of workload identities, newly created access keys and changes to role trust policies. Removing a malicious commit does not remove access the attacker established in a cloud account. SafeDep’s recovery guidance · StepSecurity’s cloud checks · BlackTree’s GhostAction recovery coverage
Before resuming automated publishing, review packages and container images produced by suspect jobs. SafeDep found the payload in specific releases on Packagist and the Go module proxy. In the Go examples it was present in workflow files, which the Go build process does not execute. Check the exact artefact and how it was used before drawing conclusions about downstream exposure. SafeDep’s package findings
