PolinRider's Multi-Vector Assault: From npm to Chrome Extensions
Just caught wind of the latest activity from the 'Contagious Interview' crew—now tracked as PolinRider. They've significantly escalated their operations, publishing 108 unique malicious packages spanning npm, Packagist, and Go, alongside browser extensions for Chrome.
The core issue here isn't just the volume, but the method. The threat actors are compromising legitimate maintainer accounts. This bypasses the usual 'new account' red flags and allows them to inject malware directly into trusted supply chains. Once a maintainer is compromised, they can swap out legitimate code for malicious payloads, often involving data exfiltration or reverse shells.
Since this campaign is active and spans multiple ecosystems, standard YARA rules might miss the variation in obfuscation. I recommend auditing your package-lock. and go.sum files for any unexpected additions recently, particularly focusing on packages that were updated without a corresponding issue or PR in your repo.
Here is a quick Python snippet to help audit your local package-lock. for packages with suspicious install scripts (a common vector in these attacks):
import
import sys
def audit_package_lock(file_path):
try:
with open(file_path, 'r') as f:
data = .load(f)
if 'packages' not in data:
print("Invalid package-lock. structure")
return
print(f"[*] Auditing {file_path}...")
for path, details in data['packages'].items():
# Check for lifecycle scripts often used in malicious packages
if 'scripts' in details:
scripts = details['scripts']
if any('pre' in k for k in scripts.keys()):
print(f"[!] Suspicious lifecycle script in '{path}': {details.get('version')}")
except Exception as e:
print(f"Error: {e}")
if __name__ == "__main__":
audit_package_lock('package-lock.')
The Chrome extension angle is concerning too, as it gives them persistent access to the browser session of developers.
Is anyone else seeing anomalies in their CI/CD pipelines where dependencies are resolving to different IP ranges than usual, or are we mostly looking at local dev environment compromises?
Good catch on the maintainer account vector. We noticed something similar in our SOC logs last week—standard npm installs resolving to weird IP geolocations. We've locked down our build servers to only allow installing from our private Artifactory registry.
For detection, we're running this KQL query in Sentinel to catch child processes spawned by Node during installs:
DeviceProcessEvents
| where InitiatingProcessFileName == "npm.exe" or InitiatingProcessFileName == "node.exe"
| where ProcessCommandLine contains "install"
| where FileName in ("powershell.exe", "cmd.exe", "bash")
| project DeviceName, FileName, ProcessCommandLine, InitiatingProcessAccountName
If npm is spawning a shell, it's usually game over.
The Chrome extension part is what worries me most. If they can get a malicious extension signed and pushed, they have access to internal tickets, Jira, and emails directly from the browser.
We've enforced Group Policy to prevent extension installation from the Web Store for most users, requiring admin approval. It's a pain for productivity, but given the 'Contagious Interview' history of targeting developers, it's a necessary trade-off. I'd recommend checking your browser telemetry for extensions with broad 'host_permissions'.
Just audited our internal Packagist mirror. While we didn't find the PolinRider specific packages, we did find three packages relying on obscured eval() calls in composer scripts.
It highlights that while we need to hunt for these specific IoCs, we really need to be automating static analysis on every pull request. Tools like Phan or Psalm with strict security rulesets can catch some of this PHP obfuscation before it hits the repo.
The maintainer compromise vector makes reputation checks nearly useless. We're pivoting to strict provenance enforcement and requiring code reviews for all dependency updates. A quick way to spot anomalies in your CI/CD is to disable auto-scripts and verify signatures manually:
npm config set ignore-scripts true
Has anyone analyzed if these packages are stripping the provenance signatures during the hijack, or are they managing to forge them?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access