Maintainer Account Hijacking: The Core of PolinRider's 108-Package Spree
Just caught the update on The Hacker News regarding the PolinRider campaign. It seems the threat actors behind the infamous "Contagious Interview" operation have scaled up significantly. We’re looking at 108 distinct malicious artifacts now spread across four major ecosystems: npm, Packagist (PHP/Composer), Go modules, and even the Chrome Web Store.
What’s particularly alarming is the persistence of the attack vector. They aren't just typosquatting; they are actively compromising maintainer accounts to inject malware into legitimate projects. This makes detection via static name-matching nearly impossible.
For those running SOC or DevSecOps, I recommend tightening CI/CD pipelines. You should be blocking packages that were published very recently or lack established adoption. Here is a quick Python snippet you can drop into your pipeline to sanity-check package creation dates against an age threshold:
import requests
from datetime import datetime, timedelta
def check_package_age(registry_url, package_name, days_threshold=30):
# Example logic for npm registry
try:
resp = requests.get(f"{registry_url}/{package_name}")
data = resp.()
time_str = data.get('time', {}).get('created')
if time_str:
created_date = datetime.strptime(time_str, "%Y-%m-%dT%H:%M:%S.%fZ")
if datetime.utcnow() - created_date < timedelta(days=days_threshold):
return f"WARN: Package {package_name} is too new ({created_date})"
except Exception as e:
return f"ERROR checking {package_name}: {e}"
return "OK"
While PolinRider is active, I suggest enforcing --ignore-scripts flags during dependency installation where possible, though this breaks some builds.
Is anyone else seeing IOCs related to the Chrome extensions in their environment? I’m curious how others are handling browser extension governance at scale.
We caught a similar attempt last month targeting our internal NPM registry. The best defense we found was strictly pinning dependency versions in package-lock. and treating that file as part of the code review process. If the hash changes in the PR, it needs a manual sign-off.
For the Chrome extensions, we pushed a Group Policy update to block developer mode installs and force a whitelist. It's aggressive, but necessary given how these extensions blend malicious behavior with supposed functionality.
From a blue team perspective, the Chrome extensions are the hardest to catch. Standard EDR often ignores the browser process. We've been hunting for this behavior using KQL to look for suspicious file writes from the Chrome process:
DeviceFileEvents
| where InitiatingProcessFileName == "chrome.exe"
| where FolderPath contains "AppData\\Local\\Google\\Chrome\\User Data"
| where FileName !endswith ".tmp"
| project Timestamp, DeviceName, FileName, SHA256
If you see Chrome dropping binaries or scripts outside of its cache directories, that’s a huge red flag.
Great thread. For the Go modules, remember that go.sum provides a layer of integrity checking. If you have GOPROXY set to a private enterprise proxy like Athens or Sonatype Nexus, you can automate the rejection of modules that don't pass provenance checks using sigstore/cosign.
Don't forget to audit your CI runners too. If the maintainer account is compromised, the CI pipeline running the go build might be executing the malware as part of the build steps.
Solid insights. Since the root vector is hijacked accounts, we should audit our CI/CD pipelines for credential leakage. Attackers often harvest tokens from build logs or history. You can quickly scan your repos for exposed secrets using TruffleHog:
trufflehog filesystem --directory ./ --only-verified
This helps prevent the initial compromise of the maintainer account.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access