Miasma Strikes: Analyzing the Red Hat npm Worm & Credential Heist
Has anyone else started digging into the Miasma campaign? The latest report regarding the compromise of @redhat-cloud-services packages is concerning, specifically because it appears to be a resurgence of the 'Mini Shai-Hulud' tactics.
We’re seeing install-time execution leading straight to credential harvesting. The worm capability is particularly aggressive—it’s not just stealing local .npmrc or AWS keys, but attempting to self-propagate through connected CI/CD pipelines. The encrypted exfiltration makes network detection slightly harder if you aren't inspecting SSL traffic closely.
I’ve started checking our dev environments for the malicious package versions. If you use Red Hat npm packages, I recommend auditing your package-lock. immediately.
Here is a quick bash snippet to check for the affected scope in your current project:
grep -A 5 -B 5 "@redhat-cloud-services" package-lock. | grep -E "version|resolved"
For SIEM detection, we are looking for suspicious child processes spawned by `npm` or `node` that shouldn't be there (e.g., unexpected PowerShell or Bash interactions post-install):
DeviceProcessEvents
| where Timestamp > ago(24h)
| where InitiatingProcessFileName has "node"
| where FileName in~("powershell.exe", "bash", "sh")
| where ProcessCommandLine has_any("enc", "base64", "curl")
Is anyone else seeing indicators of this in their environment? How are you handling transitive dependency validation for scoped packages like this?
We caught this in our staging environment yesterday. The worm component was trying to reach out to a non-standard C2 over port 443, but the JA3 fingerprint was off compared to normal npm traffic. We’ve temporarily blocked the @redhat-cloud-services scope at the registry level until Red Hat issues a full advisory. Recommend checking your CI/CD runner logs for any unsigned script executions during the install phase.
This highlights the danger of implicit trust in scoped packages. Just because it says @redhat-cloud-services doesn't mean it's actually Red Hat publishing it if the account was hijacked. We're implementing npm audit --force and requiring strict dependency pinning in our pipelines. Also, SBOM generation is now mandatory before any merge to main. If you aren't using a Software Bill of Materials yet, now is the time.
From a pentester's perspective, the worm mechanic is the most dangerous part. Once it grabs a dev's GitHub token or AWS keys, it automates the spread. I'd suggest checking for any new ssh keys or scheduled tasks on developer workstations. The 'Mini Shai-Hulud' reference implies it's burrowing deep—standard AV might miss it if it's living entirely in memory or obfuscated within a legitimate node_modules folder.
Don't overlook the Docker build cache. Even after cleaning your source, the worm can persist in intermediate layers and reinfect fresh builds. I recommend auditing your final images for configuration drift, specifically checking if the .npmrc was modified to point to a malicious registry.
You can validate your running images with this command:
docker run --rm --entrypoint cat .npmrc
If you see any registry entries pointing outside the official Red Hat source, treat the build environment as compromised.
Good insights. To supplement the checks, don't forget to inspect the local npm logs for preinstall anomalies. Since this executes at install time, the _logs folder often retains script execution records that deviate from standard package behavior.
You can audit recent suspicious installations on Linux environments with:
grep -r "preinstall" ~/.npm/_logs/ -l | xargs ls -lt
This helps spot packages that executed scripts immediately upon download, which is a common indicator in this specific supply chain attack.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access