GitHub Account Hijack: wfx-loot Campaign Steals Secrets

What is the wfx-loot GitHub campaign?

wfx-loot is a campaign in which an attacker uses stolen GitHub credentials to push a malicious workflow into repositories those accounts can write to, stealing GitHub Actions secrets and cloud credentials ^[1]. Aikido Security, which first reported it, named it after the attacker's own name for the malware ("wfx") and the word used for stolen secrets ("loot") ^[1]. SafeDep also credits Aikido with the first report ^[5].

StepSecurity calls the same stealer "wfx" and stresses a key point: the attacker does not exploit a bug in GitHub Actions ^[2]. Instead it uses valid tokens for real developer and bot accounts, opening pull requests and pushing commits the way a developer would ^[2][4].

Aikido believes the main goal is CI secrets rather than spreading through software packages, although the payload did reach at least one Packagist and one Go package through automated publishing triggers ^[1]. BleepingComputer, relying on Aikido's analysis, reports that some of the compromised accounts belonged to large organisations ^[3].

How big is the wfx-loot attack?

Aikido counts 4,837 compromised accounts that opened probe pull requests in 61,764 repositories, with the stealer running in at least 1,806 repositories ^[1]. Figures differ slightly between researchers because each searched GitHub at a different time while the campaign was still active.

• Aikido: 4,837 accounts, 61,764 repositories; 10,431 pull requests went into repositories the account does not own; 92% still open; at least 50 compromised users publish packages to npm, Go, Packagist, PyPI or crates ^[1].
• Aikido (summary figure): at least 1,835 repositories ran the payload and had credentials taken; BleepingComputer uses this number ^[1][3].
• StepSecurity: more than 63,000 probe pull requests as of 07:40 UTC on 12 November, about 90% still open ^[2].
• SafeDep: 8,093 repositories received malicious commits between 10 and 12 November, a figure that, as SecurityWeek notes, does not necessarily mean the stealer executed ^[5][4].

Aikido warns its execution count may understate impact, because the run logs were deleted in affected repositories ^[1].

How does the wfx-loot stealer work?

For each repository a stolen token can write to, the attacker probes, pushes the payload, then cleans up within about a minute ^[1].

1. Probe: a pull request titled "docs: dependency audit notes" from a branch named wfx-docs adds a tiny notes file. "The pull request does nothing by itself," StepSecurity says; it only shows that the token has write access ^[2][4].
2. Payload: a shell script of about 1,500 lines arrives in one of three ways: injected into an existing workflow ("ci: refresh build cache"), as a script plus an npm postinstall hook ("chore: add ci helper"), or as a new workflow on a throwaway chore/ branch ("chore: add dependency audit workflow") ^[1].
3. Clean-up: the attacker reverts the change and deletes the workflow run and its logs ^[1]. A missing run number is often the only trace ^[1].

The script collects GitHub Actions secrets and tokens, the full runner environment, credential files for AWS, Azure, Google Cloud, Docker, Kubernetes, npm, PyPI, SSH and more, shell histories, and keys for AI providers and developer tools ^[1][3]. It even reads the memory of running processes on the runner ^[1][4]. Aikido found that the copies it analysed sent the stolen data only by HTTP POST to attacker-controlled servers ^[1]. StepSecurity later saw a change: from about 05:30 UTC on 12 November, new copies sent data only through Telegram, so blocking the published server addresses alone no longer stops them ^[2].

Why is rotating secrets not enough?

Because the stealer tries to plant backdoors that survive credential rotation ^[1][2]. Aikido describes three persistence tricks ^[1]:

• Forged status checks: Aikido says it posts fake "success" checks using the names of a repository's required checks, which can clear branch-protection merge gates ^[1]. StepSecurity found this feature switched off in all 101 samples it examined ^[2].
• AWS trust policy rewrite: it can set a role's trust policy to allow any AWS account ^[1].
• Azure federated identity injection: it can add federated credentials named wfx-ci-… to Azure AD applications, letting workflows in the compromised repository authenticate without a stored secret ^[1].

It can also mint GitHub OIDC tokens and exchange them for AWS, Google Cloud and Azure sessions, chain into other IAM roles and create long-lived AWS access keys ^[1][3]. That is why StepSecurity says to "remove the persistence, because rotation alone does not" ^[2].

How do I check if my GitHub repositories were hit?

Search for the probe pull request and the attacker's commit messages since 10 November, then look for gaps in workflow run numbers ^[2][1].

1. Search pull requests for "docs: dependency audit notes" and branches named wfx-docs or chore/ followed by eight characters ^[1][2].
2. Search commits since 10 November for "ci: refresh build cache", "ci: restore", "ci: cleanup", "chore: add ci helper" and "chore: add dependency audit workflow" ^[2].
3. For each hit, open the Actions tab and look for a missing run number right after the commit; StepSecurity calls this the most reliable sign the stealer ran ^[2].
4. Note which account pushed the commits: that account's tokens are stolen ^[2]. If a probe pull request exists, the account is compromised even if no payload ran ^[1].

Do not rely on missing artefacts. Aikido says the absence of wfx-loot artifacts, wfx- cache entries or special step summaries does not mean data was not taken, because those channels were switched off in this campaign ^[1]. Aikido also suggests the payload may be deployed in private repositories as well as public ones ^[1].

What should I do if the stealer ran?

Assume every secret and cloud role available to the affected workflow is compromised, rotate them, and then hunt for persistence ^[1][2].

• Rotate: every repository, environment and organisation secret the job could reach, not just the ones the workflow names; npm, PyPI and other publishing tokens; and cloud keys stored as secrets ^[2].
• Check packages: look for package versions published after the malicious commit ^[2].
• AWS: look for trust policies allowing any AWS principal, IAM access keys created since 10 November, and CloudTrail sessions starting wfx- ^[2].
• Azure: delete federated identity credentials named wfx-ci-* on app registrations ^[2].
• Google Cloud, Vault, Kubernetes: review token generation and logins made with GitHub Actions sign-in tokens ^[2].
• GitHub: delete leftover branches, close probe pull requests, check nothing was merged on a forged check, and revoke the account's tokens, OAuth grants and SSH keys ^[2].
• Tokens, per GitHub's documentation: review your personal access tokens under Settings, Developer settings and delete any you do not recognise or need; GitHub recommends fine-grained tokens, only the minimal permissions necessary and an expiration date, because a classic token can access every repository you can access ^[6].

The npm hook also runs on developer machines: anyone who ran npm install during the short window ran the stealer locally and should rotate their own credentials too ^[2]. SecurityWeek sums up the advice from several security firms: revoke compromised tokens, rotate exposed secrets and check for unauthorised cloud changes ^[4]. For bot accounts, StepSecurity also suggests reviewing whether they need permission to bypass branch protection at all ^[2]. Strong sign-in protection makes stolen-account campaigns harder; see Two-Factor Authentication Explained: Which 2FA Method Is Safest?.

Which packages were affected?

Aikido lists a Packagist package and a Go module that picked up the payload through automated publishing ^[1].

• Packagist: digitalelvis/neuronai-studio version 3.14.3; Aikido says to treat any machine that installed or opened it as compromised ^[1].
• Go: github.com/onuragtas/docker-env v1.0.278 and v1.0.280; the payload is only in a GitHub Actions workflow file, the Go source and binaries are unchanged, and Go builds never run workflow files, but Aikido still recommends removing these versions ^[1].

Counts differ: SafeDep says three packages on Packagist and the Go module proxy ship the payload, and SecurityWeek mentions versions of two Go modules ^[5][4]. SafeDep adds that the payload did not run for typical consumers who install these packages with composer require or go get ^[5]. Check each researcher's current list before relying on any one of them.

Who is behind wfx-loot and how did they get the tokens?

None of the reports named here identifies the attacker, and StepSecurity says it has not established how the tokens were obtained ^[2][4].

StepSecurity found 173 probe pull requests, from 19 accounts, made through tokens issued to the Fly.io GitHub App; it said it could not determine how they were obtained and had no evidence that Fly.io's infrastructure was breached ^[2][4].

Aikido found overlap with accounts hit by the October GhostAction wave and saw wfx-loot injected into GhostAction workflow files in more than 100 repositories, but assessed the two as distinct campaigns likely run by different actors, since stolen credentials often end up with several groups ^[1]. It also noticed Indonesian-language comments in some newer malware versions ^[1]. Storing tokens carefully matters here; Password Managers Explained: How They Work and Whether They Are Safe covers the basics.