Wiz Research has been responding to the s1ngularity incident since news first broke on August 26th. At this point, active attacks seem to have lulled. This gives us an opportunity to step back and share what we’ve discovered in this incident, and the work we’ve done in response. 

In this post, we’ll explore the impact of this attack to date, dissect the role of AI, and provide guidance on reviewing relevant GitHub logs based on novel TTPs. For a detailed account of the initial incident, refer to our previous blog post.

A quick recap

An attacker compromised an npm publishing token for nx packages via a vulnerable GitHub Action. They abused that access to distribute new, malicious versions of a variety of Nx packages. The end result was thousands of corporate secrets leaked publicly across GitHub, enabling follow on attacks.

The malware directly extracted environment variables, as well as GitHub and npm tokens, and published them in public s1ngularity-repository GitHub repositories. The malware also abused locally configured AI CLIs to identify additional files for exfiltration. While GitHub eventually disabled these repositories, there was a sufficient window to retrieve the files.

A second phase abused the leaked GitHub tokens to expose private repositories (renamed to s1ngularity-repository-#5letters#) by making them public on the victims’ GitHub profiles. These repositories often contained additional secrets.

A third attack occurred later, publishing repositories with the description of S1ngularity, and impacting a single victim organization across two compromised user accounts. 

A s1ngular(ity) impact

The s1ngularity incident evokes a string of recent Github Actions related supply chain compromises, including Ultralytics and tj-actions. However, those cases felt a bit like near misses: the cryptomining payload of Ultralytics presented less of a threat, while tj-actions’s noisy approach, lack of exfiltration from private repositories, and rapid detection defanged a massive possible scope of impact. The impact narrowly avoided in those prior incidents seems manifest in the s1ngularity attack. 

In Phase 1 of this attack, over 1,700 users had secrets publicly leaked. Each of those users would have at least a GitHub token in the leaked data, as it was a prerequisite for the repository to be created. Wiz Research was able to collect data for over a thousand of these cases, enabling our informed response on behalf of our customers and the industry. Multiple reports echo our own data: over 2,000 unique, verified secrets were leaked. An unknown, broader pool of Nx users may have run the malware, resulting in secrets gathered and persisted to disk, but without exfiltration. 

The malware additionally attempted to exfiltrate potentially sensitive files. More on that later, but suffice to say we observed over 20,000 files leaked across our sample, across 250 cases impacting 225 distinct users (some of whom had multiple repositories created over multiple runs of the malicious package). 

Looking specifically at GitHub tokens, we found that almost 90% remained valid the morning (UTC) of the 28th, over 24 hours after the repositories with leaked secrets had been removed by GitHub. Validity rate very slowly dropped over the next twenty four hours, with almost 80% of leaked GitHub tokens still valid the evening of the 29th. Some time between then and the evening of the 30th, GitHub conducted a revocation campaign. Following this effort, roughly 5% of leaked GitHub keys remain valid. 

In Phase 2, at least 480 compromised accounts (⅔ were organizations) published over 6,700 private repositories publicly with a s1ngularity-repository-#5letters# naming scheme. In one case, a single organization had over 700 repositories leaked. Wiz identified thousands of valid credentials in these formerly-private repositories. GitHub eventually removed these repositories as well.

In Phase 3, starting the evening of August 31st, two compromised users publicly uploaded over 500 repositories (suffixed with _bak, and with S1ngularity as the description) belonging to a single organization. 

Wiz’s response

Prior to this incident, Wiz already offered detection opportunities for similar attacks, primarily through our Wiz Code features. However, this incident often generated artifacts in user repositories, outside of organization logs or visibility. Even with Nx leaving issues to notify victims in the repositories created in Phase 1, that information wasn’t making its way to the relevant organizational stakeholders. 

In parallel to expanding our detection content, Wiz’s Threat Exposure and Customer Incident Response Teams worked in concert to analyze the leaked data and notify victims directly. This white glove reporting reached over 50 major impacted organizations. The vast majority told us that this was the first indication they had received of this attack impacting them. 

What does it mean for malware to be AI-powered?

Much has been made of the role of AI in this attack, however analysis to date has remained high level. For a breakdown of the payload, we recommend the Socket blog post, in addition to our own. We also spoke with DarkReading about the reasons to integrate AI in this attack. In short, AI offers improved flexibility and novelty, potentially bypassing detection. However, it trades off against consistency, as there are more preconditions and the complexity opens more opportunities for the malware to fail.

So far, we’ve discussed “Phase 1” as a monolith. However, there were actually at least three distinct payloads across the dozen-plus malicious versions of Nx packages. This accounts for the presence of three distinct names for the repositories created with the leaked data: s1ngularity-repository, s1ngularity-repository-0, and s1ngularity-repository-1.

All three variants share code for identifying the presence of popular AI CLIs (Claude, Gemini, and Amazon Q): 

However, the prompt used evolved over the course of the attack. We will focus on the main Nx package, but similar patterns apply across all impacted packages. 
In Nx versions 20.9.0, 20.11.0, and 21.5.0, producing “s1ngularity-repository”:

In versions 21.6.0 and 21.7.0, producing “s1ngularity-repository-0”:

In versions 20.12.0 and 21.8.0, producing “s1ngularity-repository-1”:

The evolution of the prompt shows the attacker exploring prompt tuning rapidly throughout the attack. We can see the introduction of role-prompting, as well as varying levels of specificity on techniques. These changes had a concrete impact on the success of the malware. The introduction of the phrase “penetration testing”, for example, was concretely reflected in LLM refusals to engage in such activity.

How effective was the AI file identification?

Our sample of impacted repositories serves as a representative model of the overall victim pool.

The AI file identification required several conditions to be successful:

1. Presence of one of more AI CLIs, with functional configuration and credentialing

2. Valid response from LLM, without task rejection

3. Useful response from LLM, successfully identifying sensitive files

We saw significant fall off at every step of this funnel.

Presence of one of more AI CLIs: roughly 50% of all victims had at least one AI CLI installed. The majority of those had Claude installed. A smaller portion, roughly 15%, had Gemini installed. For Q, it was 5%. Roughly 15% had two or more AI CLIs, and 1% had all three configured. Configuration was a recurring issue, with common examples being Credit issues (Claude), credential issues, --dangerously-skip-permissions requiring approval (Claude),  and MCP configuration issues.

Task refusal: LLM model providers generally build safety guardrails to mitigate malicious use of their APIs. These guardrails are not deterministic, but almost a quarter of Claude interactions were rejected. Similar behavior was observed in Q, which uses Claude models. Gemini demonstrated rejection at a lower rate. 

Successful execution: almost a quarter of Gemini interactions were foiled by default restrictions to workspace directories. In many other cases, across all tools, the search for sensitive files was only performed against Nx’s directory, consistently exfiltrating 14-15 non-sensitive Nx files. 

Overall, AI only exfiltrated data successfully in under a quarter of cases. We saw under 100 unique valid secrets across 20,000 exfiltrated files. The majority of these secrets were for AI services (Langsmith, Anthropic, OpenAI), and cloud platforms (AWS, Azure, Vercel). We have yet to observe any successful cryptocurrency related exfiltration.

Attacker tactics

One element of this attack that bears discussion is the choice of exfiltration mechanism. In the attacker’s initial compromise of Nx’s npm token, they appear to have leveraged webhook.site for remote exfiltration. However, they went on to make the deliberate choice to only exfiltrate data when the gh CLI was present and they could create a repository on the victim account.

Why? We believe that, as with the tj-actions attack, the attacker has optimized for their operational security. Both exfiltration mechanisms significantly limit their exposure, as they do not need to acquire any infrastructure. Webhook.site was useful in the initial compromise, but limits anonymous users to 100 records, requiring the attacker to use an alternative exfiltration mechanism given the large pool of victims. 

New TTPs and investigation opportunities

In addition to the IOCs and recommended actions from our first post, we wanted to share additional TTPs, observations on the attacker, and investigation opportunities. 

Note: Wiz customers can refer to the Threat Center entry for this incident, which surfaces the relevant controls, queries, and detections.

For Phase 1, you should investigate your GitHub Audit Logs for the s1ngularity string within repo.create event’s repo field. 

In Phase 2, we have observed:

• The attacker leveraged TOR when accessing victim accounts. 

• The attacker using a single threaded python script to publish repositories, with the following User Agents:

  • python-requests/2.32.3

  • python-requests/2.32.4

• In your GitHub Audit Logs, you can review for:

  • the s1ngularity string within repo.access event’s repo field

  • a single user cloning a wide set of repositories in a short timeframe 

Organizations should also check their GitHub Audit Logs for the org_credential_authorization.deauthorize event by the “github-staff” actor_id. This event is tied to GitHub’s mass revocation of compromised credentials.

Conclusion

While the first burst of activity has concluded, we expect this incident to have a long tail. The leaked secrets each present the opportunity for further attacks on victim organizations or the supply chain at large. For example, we see over 40% of leaked npm tokens from the first phase still are valid, almost 100 unique tokens. In addition, for organizations impacted in the second phase, there is further attack surface in the exposure of any secrets in these formerly private repositories. 

Not only is the impacted data here presenting future risk, we can also see a clear pattern in the threat landscape. From Ultralytics, to tj-actions, and now on to Nx - attackers are clearly awake to the potential to escalate small GitHub Actions misconfigurations and build them into massive and messy supply chain attacks.