Supply Chain Rot: Miasma Malware Hits npm & GitHub Actions
Just saw the alerts regarding the Miasma malware family. It looks like the threat actors behind Mini Shai-Hulud and Hades are evolving rapidly, expanding their reach from traditional infostealers to complex supply chain attacks.
The latest wave specifically targets the npm ecosystem. Researchers have flagged malicious releases in the following packages:
LeoPlatformRStreams
What's concerning is the shift towards GitHub Actions abuse. They aren't just poisoning the package code; they are attempting to manipulate CI/CD workflows to maintain persistence or exfiltrate data from the build environment.
For immediate triage, you should scan your package-lock. files. I recommend running a quick grep on your build servers:
grep -Ei "leoplatform|rstreams" package-lock.
Additionally, if you are monitoring for this behavior via SIEM, keep an eye out for node.exe spawning unexpected child processes like PowerShell or making outbound C2 connections on non-standard ports.
How is everyone handling GitHub Actions security in the wake of this? Are you relying on Dependabot, or have you moved to strict pinned commit SHAs for third-party actions?
We've moved to pinned commit SHAs for all critical actions a while ago. It's a bit of a maintenance headache when updating, but it completely neutralizes the tag-substitution attack vector that these groups love. Regarding the npm packages, we use a private registry proxy (like Artifactory) that blocks LeoPlatform and RStreams by policy. Public registry access should be a red flag in most corporate environments anyway.
From a SOC perspective, this is tricky because the malicious npm packages often obfuscate the initial payload. We've started correlating npm install events with DNS requests. If a dev machine hits the registry and immediately hits a new, suspicious endpoint, we auto-isolate. I'd suggest adding the package hashes to your EDR exclusion lists—don't just block by name, as they often typo-squat.
The propagation to the Go ecosystem mentioned in the report is the real kicker here. It shows they are diversifying beyond JavaScript environments. If you're running mixed-language stacks, make sure your SBOM tooling covers both go.sum and package-lock. automatically. Don't wait for the audit to find the overlap.
Great points on SHAs and DNS correlation. To add to that, we've started enforcing strict network segmentation for our CI/CD runners, treating them like untrusted zones. Even if a malicious package executes, its ability to exfiltrate data is limited.
We also pre-scan package manifests for unusual registry endpoints. This simple bash check helps catch typosquatting attempts before they even hit the registry:
npm view repository.url -- | grep -v "github.com\|gitlab.com"
Has anyone looked into isolating these specific npm packages in a sandbox to map out the full kill chain?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access