Varonis Threat Labs has assisted several organizations that experienced breaches relating to secondary consequences of a Shai-Hulud compromise, months after the initial compromise occurred.
This is manifesting as cloud compromises stemming from exfiltrated secrets obtained during the Shai-Hulud 2.0 campaign in November 2025. In some cases, this was the first time that impacted organizations learned they were exposed by Shai-Hulud.
In this blog, we’ll highlight the Shai Hulud campaign, what our forensics experts are seeing now, the implications, and and how to check if your organization is affected.
What is the Shai Hulud Campaign?
Shai-Hulud is the name given to a specific threat campaign that first occurred in September 2025, and references to the giant sandworms seen in the fictional Dune series. After the initial campaign, an additional wave dubbed Shai-Hulud 2.0 followed in November 2025.
The Shai-Hulud cyberattack involved a self-replicating worm that compromised a large number of NPM repositories, leading to further downstream compromises. Reported by CISA, the initial wave of this attack compromised over 500 packages.
The secondary wave infected over 700+npm packages and 25,000 GitHub repositories.
A lurking threat — what the Shai-Hulud campaign did
The Shai-Hulud campaign aimed to rapidly self-propagate and then to harvest and exfiltrate sensitive credentials. Harvested credentials were published publicly, but also used to publish more backdoored NPM packages, where circumstances allowed, to further propagate the campaign.
With the attack well documented and very visible, victims who had one of their maintained NPM packages backdoored were quick to remediate. Victims who had secrets stolen but were not maintaining their own NPM packages and didn’t expose their own GitHub accounts may have found themselves in a situation where it wasn't immediately evident that they were affected. These victims will have had their secrets posted to the public repository of a previous victim.
CI/CD attack surface
An area that was prone to being overlooked or missed completely was CI/CD pipelines that utilized an infected NPM package. There were containers and serverless solutions that downloaded and ran the infected packages as part of an automated workflow.
If you had any automated workflow that ran a compromised package at the time, there is a possibility that secrets were publicly exposed.
The key takeaway is that infections of this sort were transient; they lasted only while the containers ran, and there was a narrow time frame for the infection to occur. If a backdoored package hadn’t been baked into a source container image, the infection wouldn't have reoccurred once the maintainer remediated it (which happened relatively swiftly as the campaign became known).
You may be thinking — what is the big deal, no harm no foul? The answer, like many things in incident response, it depends:
- Did the environment that ran the backdoored package have access to any secrets or credentials as part of its workflow?
- If it did, those same secrets have been sitting in a public GitHub repository for the world to see (and harvest).
TruffleHog
One of the things the worm did during the campaign was use TruffleHog to steal secrets and credentials.
TruffleHog is a legitimate tool that is described as a discovery, classification, validation and analysis tool. It scans an environment for all sorts of secrets that may be stored/accessible, and can validate them against what they authenticate to to see if they work.
Shai-Hulud deployed TruffleHog to harvest secrets from the environment it had infected.
There is a hog in the pipeline
Varonis addressed several cases following the Shai-Hulud campaigns, including Azure applications that used legitimate secrets to obtain access. This scenario was concerning because it indicated that application secrets had been compromised and were being used by threat actors.
In some cases, our investigations were hampered by a lack of logging. Many services used in CI/CD pipelines don’t log by default, or incur high costs for verbose logging. It is not unusual for critical logging for some of these services to be disabled.
Despite these restrictions, we identified in one case that the compromise of the applications appeared to date back to November, specifically starting near the same date as Shai-Hulud's second wave in November 2025. In addition, we could see the first suspect’s access had come from internal IP ranges within the cloud infrastructure of victims, and importantly, the user-agent of the requests was TruffleHog in the HTTPS requests to authenticate to the application.
That same day, we also observed similar requests being logged, but from external IP addresses. This posed a vital question: why were we suddenly seeing a TruffleHog user agent attempting to authenticate to Azure applications from an internal IPv6 range?
The leading theory was that a container had been compromised to run TruffleHog. Given the date, we realized that the initial requests likely represented the execution of a compromised NPM package within a container as part of the Shai-Hulud campaign.
While the Shai-Hulud campaign was unfolding, we were able to conclusively prove Shai-Hulud was the cause of the initial compromise by identifying the compromise secret in the data that had been collected by third parties from public repositories.
Implications
The implications of the breaches behind the Shai-Hulud campaign are that any secrets available to environments running on a compromised NPM package were likely publicly exposed.
The credentials leaked during the campaign are actively being used for further malicious activity, even months after the fact. The purpose and intent of the follow-on action are as varied as the applications to which the stolen secrets relate.
The level of privilege that the secrets allow access to will dictate the action on the objective by threat actors, including, but not limited to:
- Data exfiltration
- Resource creation
- Lateral movement into other environments
It only takes one successful execution to leak critical secrets, which could then open multiple attack surfaces. This means that a CI/CD pipeline that executed at the wrong time will have exposed the secrets it had access to.
Hunting the hog
There are a few key considerations when trying to hunt for a Shai-Hulud compromise:
- With a significant timelapse since the Shai-Hulud campaigns originated, logs from the original compromise may have rolled if not preserved
- There will effectively be at least two compromises to search for:
- The initial Shai-Hulud compromise that targeted the secrets
- Follow on activity that focuses on whatever the secrets related too
Initial Shai-Hulud compromise
To hunt for initial Shai-Hulud compromise it will be necessary to search the authentication logs for your applications/services for the period beginning 24thst November 2025.
The key thing to look for will be TruffleHog as a User Agent as the Shai-Hulud campaign did not change the default value for the User Agent when carrying out its validation attempts.
Depending on the setup of your environment, you may see the first attempts from internal IP ranges if the compromise happened in a container, for example, or it may be external if the authentication is needed to go out via the internet from a public endpoint.
In any case, if you see successful authentications with a successful TruffleHog user agent on or around this date it is very likely you have been the victim of Shai-Hulud.
Follow on activity
Hunting for follow-on activity will be harder, as there will be no defined time frame. Again, it will be necessary to check authentication logs for the Truffle Hog User Agent, as well as look for authentications from unknown IP addresses that started on or after November 24, 2025.
It is important to note that follow-on activity may not use TruffleHog, so searching the User-Agent string will not necessarily be sufficient, although we did see external attempts to authenticate using TruffleHog in the cases we investigated.
Remediation and recommendations
To remediate the effects of the Shai-Hulud campaign:
- Ensure that whatever was compromised is rebuilt from a known, reliable source
- Rotate any secrets that were accessible to whatever was compromised
- Assess what was accessible with the secrets that were stolen, and investigate for further follow-up on the compromise
Recommendations:
- Ensure that appropriate logging is configured for any CI/CD pipelines to allow adequate investigation and alerting
- Inventory what packages are used in your pipeline, so you know if you are affected if there is a similar campaign in the future
- Adhere to the principles of least privilege and make sure no part of the CI/CD pipeline has excessive permissions
- Consider implementing minimum release age settings to allow the ecosystem to detect malicious or broken packages
- Use container scanning functions to identify vulnerabilities or issues with container images
- Do not store plaintext secrets in .env files
- Ensure regular rotation of secrets
- When rotating secrets during a security incident, keeping a copy of the old secret can aid investigations into whether the secret was publicly exposed
Don’t wait for a breach to occur
As we uncover new attack methods and threat actor groups, it’s more important than ever that you’re confident your security solution is built to protect against them.
The same experts behind Varonis Threat Labs can monitor your data 24×7 through Varonis Managed Data Detection and Response service. Learn more about our MDDR service and explore more threat research content.
