WFX-Loot Campaign Stealthily Infiltrates Thousands of GitHub Repositories to Steal Secrets
A sophisticated threat actor known as 'wfx-loot' has compromised tens of thousands of GitHub repositories, leveraging stolen credentials to inject malware that exfiltrates sensitive GitHub Actions and cloud credentials.
A clandestine campaign, dubbed 'wfx-loot' by security researchers at Aikido, is actively compromising GitHub repositories by exploiting stolen user credentials. Since November 10th, the threat actor has initiated probe pull requests across more than 61,000 repositories, with malware successfully running in over 1,800 of them to siphon critical GitHub Actions secrets and cloud credentials. The campaign's name originates from the attacker's own internal labels: 'wfx' for the malware and 'loot' for the data it steals.
The scale of the operation is significant, with Aikido observing 4,837 compromised accounts opening these malicious pull requests. Alarmingly, over 10,000 of these requests targeted repositories the compromised account did not own, highlighting the cascading risk posed by stolen tokens that grant write access to multiple projects within an organization or through collaborator permissions. The majority of these malicious pull requests remain open, leaving a substantial attack surface vulnerable.
GitHub Actions, a popular automation tool for software development, often stores sensitive keys for cloud accounts and package registries within its workflow configurations. The 'wfx-loot' actor meticulously inserts a shell script, approximately 1,500 lines long, into existing workflows or creates new ones on disposable branches. This script is designed to execute during the npm install process or similar build steps. To evade detection, the attacker quickly reverts the malicious changes and deletes the workflow run and its logs within a minute, often leaving only a skipped run entry in the workflow history.
The stolen data includes not only GitHub Actions secrets but also cloud and SSH credential files, shell histories, and tokens for AI tools such as OpenAI, Anthropic, Cursor, and Copilot. The attacker then leverages these credentials to gain unauthorized access to major cloud platforms like AWS, GCP, and Azure. A particularly insidious tactic involves creating long-lived AWS access keys and forging passing status checks to bypass branch protection rules. Furthermore, the attacker rewrites AWS role trust policies to allow access from any AWS account and adds federated identity credentials to Azure applications, enabling persistent access even after token rotation.
Evidence suggests the payload was automatically distributed through compromised automated publishing triggers, embedding itself into packages like digitalelvis/neuronai-studio on Packagist and github.com/onuragtas/docker-env in Go modules. While the Go module versions only contained the malicious code within a workflow file that Go builds do not execute, the Packagist package's inclusion warrants immediate attention. Aikido advises that any machine that installed or opened the affected Packagist package should be treated as compromised.
Identifying a potential compromise involves looking for specific indicators such as a 'wfx-docs' branch, the 'docs: dependency audit notes' probe pull request, or commits with titles like 'ci: refresh build cache,' 'chore: add ci helper,' or 'chore: add dependency audit workflow.' However, the absence of these artifacts does not guarantee security, as the campaign directly exfiltrates data to attacker-controlled servers via HTTP. The script's configuration for private repositories also suggests the campaign may be active in environments beyond public scrutiny.
Notably, repositories previously affected by the October 'GhostAction' campaign were disproportionately targeted by 'wfx-loot,' with the latter even injecting its payload into GhostAction's own workflow files. While Aikido assesses these campaigns are likely from different actors, the overlap indicates a persistent and evolving threat landscape targeting CI/CD pipelines. The persistence of the AWS trust policy changes and Azure federated credentials means that manual intervention is required to remove these lingering access mechanisms from cloud environments.