Attacks use stolen credentials to insert a secret stealer into GitHub Actions

Since Tuesday, attackers with stolen credentials of 4,837 GitHub accounts have introduced a secret stealer in the continuous integration (CI) flows of repositories to which those accounts could write, according to the technical analysis published by the firm Aikido Security. The malicious code was designed to exfilter any secret or credential in the scope of GitHub Actions executions and to pivote into cloud accounts using OIDC tokens and other credentials that he recovered from the runner.

The facts confirmed by Aikido and other firms that have published complementary analyses are clear on several points: the attacker opened initial tests using the "docs: dependence audit notes" from branches called wfx-docs in at least 61,764 visible public repositories for Aikido; in 1,806 of those repositories the stealer came to be executed and presumably exfiltered data; and in total 4,837 accounts were used to open the evidence. SafeDep, who made an independent sweep, counted 8,093 repositories that received malicious commitments in the window they analyzed, indicating that the actual reach can be greater because both counts only consider default branches and public repositories visible to each researcher.

Technically, the attack followed a repetitive pattern: to open a PR from wfx-docs to check if the account attacked had a writing permit; if the check was positive, a step (workflow) or a post-installation hook in npm was added to it that executed a script, the sum of which is SHA-256, 89695abb392d5cfd4972672961e644b46baa98aa1ed7173c2a2816c762735cf. This binary / script attempts to collect keys and tokens from multiple local sources of the runner - variables and secret of Actions, GITHUB _ TOKEN, tokens in runtime, instance metadata in self-hosted runners, AWS / Azure / GCP configuration files, SSH keys, workflow devices and even residual secrets in process memory - and then exfilters HTTP POST to observed servers (e.g. 194.150.166 [.] 244: 8080, 18.143.168 [in 1580], according to a 153.80 channel.

Once the stealer obtained valid OIDC or tokens credentials, it could exchange them for AWS / GCP / Azure sessions and, in the case of AWS, create long-term access keys and modify trust policy to provide access to external accounts. In Azure, the creation of federated credentials with prefixes such as wfx-ci- has been observed that allow persistent federated authentication from workflows. Several of these operations are designed to withstand key rotations.

The technical indicators provided by Aikido - branch names (wfx-docs, chore / [a-z0-9] {8}, ci-check- [0-9] {4}), specific PR title, frequent commit messages (e.g. "ci: refresh build cache," "chore: add ci helper," "chore: add dependence audit workflow") and the SHA-256 print of the payload - allow to detect campaign prints. Aikido also stresses that any account used to open one of these PRs should be considered compromised even if the stealer was not executed, because the possession of credentials has been demonstrated by the ability to create branches and PRs from them.

Practical impact and scope: In addition to individual repositories, the attacker reached automated publication pipelines and packages. Aikido identifies a malicious version in Packagist (digitalelvis / neuronai-studio v3.14.3) and two versions of a Go module that contain the stealer in its workflow (github.com / onuragtas / docker-env v1.0.278 and v1.0.280). In some cases the source code or binaries were not altered; the risk came from the presence of the payload in workflow files or from the hooks of npm postinstall that would have been executed on developer machines. Those who installed packages with that post-install or executed npm install in affected repositories must take commitment of the machine and act accordingly.

What is known with uncertainty: the analyses have not publicly identified how the credentials of the 4,837 accounts were initially obtained; nor is there a conclusive attribution of the actor. Aikido points to an overlap with accounts affected in the wave known as GhostAction in October, but does not automatically attribute both events to the same operator because the infrastructures and methods show differences and because stolen credentials can be shared among several attackers.

Real consequences that those responsible must assume include loss of secrets and possible escalation to entire cloud environments (key creation, policy modification, federation incorporation). In repositories where the stealer was run, everything the workflow could read must be considered compromised including secret actions, variables, tokens OIDC, and roles / credentials in AWS / Azure / GCP.

Specific measures and prioritization: First, treat any account that opened a test as committed. Check immediately personal access tokens, OAuth grants, SSH keys and sessions. Activate the authentication of two factors (2FA) in accounts with writing permissions. In affected repositories, rotate and replace all the secrets and variables that the workflow could read and consider regenerating any accessible API key from the run.

To search for back doors in the cloud review the following events and objects (suggested detection forms): in Azure AD, seek federated credentials with wfx-ci- * prefix; in AWS CloudTrail look for AssumeRoleWithWebIdentity or sessions whose name contains wfx- * followed by CreateAccessKey or UpdateAssumeRolePolicy; in GCP trace GenerateAccessToken and SignJwt from their workload identity pool. Also inspect the Vault log for JWT login from the GitHub OIDC emitter. These searches match the signals that Aikido and SafeDep have highlighted.

If your repository received the malicious commit but the workflow did not come to be executed, it still revokes the author's credentials and rotes secrets: Aikido clarifies that the mere ability to push commits confirms account control. If you run a npm install in a copy containing the malicious hook, treat the machine as compromised: do a reinstall from scratch, revoke locally stored credentials and rotate API and tokens used from that environment.

To reduce surface in the future, apply the hardening practices for GitHub Actions: grant as little privilege as possible to tokens, limit GITHUB _ TOKEN's permissions and enable OIDC authentication with audit; use self-hosted runners with isolation and without accessible metadata if not necessary; and set up rules to block commitments or PRs from suspicious branches or messages. GitHub maintains documentation on hardening and OIDC that can serve as a practical guide: GitHub - Security hardening with OpenID Connect and GitHub - Security hardening for GitHub Actions.

In addition, audit STS and OIDC activities in cloud suppliers; for example, the AWS API for AssumeRoleWithWebIdentity and its use are documented here: AWS STS - AssumeRoleWithWebIdentity. These searches help to detect attempts to exchange tokens and create keys that the stealer takes advantage of.

Abstract: The campaign has shown an automated and effective pattern: use of stolen credentials to insert a stealer into workflows and hooks that exfilter secrets and climb to cloud environments. If your organization uses GitHub Actions, any repository in which an account has opened the trial PR should be considered at risk until the revocation of credentials, the rotation of secrets and the audit of cloud and runners. The lack of a clear attribution and the possibility that the actor persists through federation imply that the response must be broad and rapid.