Contagious Interview Evolved: PolinRider's 108-Package Offensive
Just caught the latest report on PolinRider. The shift from the standard 'Contagious Interview' malware droppers to a full-blown supply chain attack is concerning. With 108 malicious packages now spanning npm, Packagist, Go, and even the Chrome Web Store, this isn't just targeting developers anymore—it's hitting the broader ecosystem via maintainer account hijacking.
What stands out is the cross-platform persistence. By compromising legitimate maintainer accounts, they bypass the usual 'new account' red flags. For those of us in SOC or DevSecOps, standard typosquatting detection won't catch this because the package names and authors are historically trusted.
We’ve updated our CI/CD pipelines to block unsigned commits, but that doesn't help if the maintainer's key is already stolen. I’m currently auditing our dependency tree for any suspicious pre-install scripts.
If you want to do a quick check on your node environment for recently modified binaries that might indicate tampering, you can run:
# Find JS files modified in the last 24 hours within node_modules
find ./node_modules -type f -name "*.js" -mtime -1 -exec ls -lh {} \;
Has anyone else observed artifacts related to the Chrome extensions in this campaign? I'm trying to determine if they are using the C2 domains previously associated with the BeaverTail loader.
We saw a similar spike last month with the npm packages. We implemented a dependency-lock policy using npm ci in production builds and added a step to hash-check all binaries against an allowlist.
For the browser extensions, if you are managing enterprise devices, enforce this via Group Policy to block unknown extensions immediately:
# Get all installed extensions for a user
Get-ChildItem "HKCU:\Software\Google\Chrome\Default\Extensions"
If you see IDs you don't recognize in your registry, investigate immediately. The Chrome component of PolinRider is nasty because it bypasses standard network filtering by running in the user's browser context.
The maintainer account compromise angle is the real headache here. It suggests they are phishing developers with legitimate-looking offers (the 'Contagious Interview' M.O.), getting 2FA codes, and then pushing updates.
We started using a private npm proxy (Nexus/Artifactory) that freezes versions. Even if a maintainer pushes a malicious update, our internal cache doesn't pull it until we manually vet the changelog. It adds latency to updates but stops the bleeding in events like this.
Good catch on the base64 obfuscation in the Python snippet. I'd also recommend looking for unusual DNS requests. The PolinRider loaders often reach out to DDNS domains for C2.
Here is a basic KQL query if you are using Sentinel to spot potential beaconing from your dev workstations:
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemotePort in (80, 443, 8080)
| where InitiatingProcessFileName in ("node.exe", "go.exe", "chrome.exe")
| summarize count() by RemoteUrl, InitiatingProcessFileName
| where count_ < 5
Low connection counts to unique URLs from build agents are usually a smoking gun for these supply chain payloads.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access