GhostAction Hacking Wave Fizzles, But Attackers Lurk on in GitHub

The supply chain attack campaign’s shift toward developer endpoints and cloud access signals what could be next for the cybercrime outfit.

A new wave of GhostAction attacks has largely failed, but this supply chain campaign operator is well-positioned to cause more chaos down the line.

GhostAction, an ongoing campaign in which attackers target GitHub by compromising developer accounts and injecting GitHub Actions workflow files into repositories.

Workflows tell GitHub Actions what code to execute when events occur (such as when a commit is pushed or pull request is opened); these malicious workflows rely on GitHub’s high trust in these files (by design), seizing repository secrets, package publishing tokens, GitHub personal access tokens, credentials embedded in source code, and much more.

The idea is that an initial compromise could be leveraged into more compromises and access points across repositories, CI/CD systems, and cloud environments, not unlike many supply chain worms observed in the wild lately, albeit functioning differently.

The campaign was first documented last year, and attackers continue to deploy GhostAction against organizations. What has changed is an apparent escalation of the technique beginning this month. During an earlier Oct. 8-12 wave, attackers pushed the security-audit.yml workflow into roughly 30,000 repositories, using compromised accounts to distribute credential-stealing code at scale. But GitGuardian on Oct. 27 published research highlighting further escalation. GitGuardian’s Gaetan Ferry wrote that between Oct. 13 and 21, GhostAction’s operator “pushed 72,000 commits to 23,000 public repositories,” noting that 8,000 of them were new targets.

Various Payloads Targeting Compromised Developers

During this latest wave of the campaign, GitGuardian observed that once a developer account is compromised, the operator would deploy different payloads depending on which runner the repositories were hosted on. Runners are the systems that execute GitHub Actions workflows. Many organizations use GitHub-hosted runners, while others configure self-hosted runners that run inside their own environments.

These payloads include one called “seven workflows,” which searches GitHub runner repositories and wikis for credentials including AI-provider API keys; the “Security-audit.yml” file seen in earlier GhostAction attacks that searches GitHub-hosted source code and Git history for credentials; self-hosted runner payloads targeting self-hosted CI runners; a payload targeting GitHub runners and AWS-requesting GitHub OIDC tokens (in order to assume AWS roles and achieve cloud account access); and the font stealer payload, which is the most notable workflow payload seen in recent attacks, due to its provenance.

The font stealer family installs a Node.js credential stealer on local developer machines, disguised as a VS Code task. The technique appears to be copied from PolinRider, a campaign that hides obfuscated loaders in developer repositories to steal credentials and has been associated with North Korea. The attacker also added PolinRider loaders between Oct. 22 and 26 to repositories already impacted by GhostAction. Ferry says that out of the five payloads, only the PolinRider-styled local stealer had a chance to successfully run, but GitGuardian has no evidence that any run actually occurred.

GitGuardian could not assess whether there was overlap between GhostAction and PolinRider, but hypothesized that GhostAction’s operator possibly copied a public PolinRider launcher in order to target an overlapping set of victims.

Jenn Gile, cofounder of OpenSourceMalware (which previously covered the GhostAction attacks this month and detected signs of the PolinRider copycat a few weeks ago), tells Dark Reading that the PolinRider clone illustrates some of the inner workings of the GhostAction group.

“What we’re seeing looks like imitation, not evolution. The fake-font technique in GhostAction is a copy of what DPRK’s PolinRider campaign has been using nearly all of 2026,” she says in an email. “The multiple payloads are real, but they’re variations on a theme (five workflow versions over about ten days in one repo we examined), not a new capability. Historically, we might have called this evolution because it took real skill to figure out. But this looks a lot like a LLM helping the threat actor test different variants.”

All of that said, GitHub identified and prevented execution of the malicious workflows, GitGuardian noted. However, importantly, the attackers still demonstrated persistent access to nearly 1,800 compromised accounts, many of which had already been used in earlier GhostAction activity; “1,382 of the 1,792 compromised accounts had already been used on Oct. 8, so the same stolen tokens keep working,” according to Ferry.

A ‘Failed’ Wave of Attacks, But Still Plenty to Worry About Long Term

Ferry tells Dark Reading that the campaign has been “highly ineffective on the malicious workflows side.” But even if there’s no sign this wave succeeded, the nature of the payloads (such as the one aimed at gaining cloud access) also shows where the attackers may intend to pivot next, toward internal networks where there are fewer platform-level protections that could thwart their efforts.

“We expect new waves to appear in the near future, with revised payloads,” he explains. “This ‘fail early and adapt fast’ strategy has already been observed for this threat actor.”

Given that targeted accounts or repositories remain compromised, repo owners should look for and delete the files that GitGuardian lists in the IoC section of the blog, on every branch. And, if signs of compromise are detected, users should revoke the account’s tokens across the board and rotate every credential committed in the affected repository or its history, as well as every Actions secret and wiki credential.