What Happened
Between late 2024 and early 2025, three separate credential-harvesting campaigns targeted npm, PyPI, and Docker Hub within a 48-hour period. These attacks followed a common pattern: compromised packages and developer tools turned developer workstations into credential collection points.
Two campaigns stand out:
TeamPCP deployed malicious packages that, once installed, harvested authentication tokens and credentials from local development environments. The packages appeared to function normally, making detection difficult until after credential theft occurred.
Shai-Hulud infected developer environments directly, converting them into persistent credential collection systems. Once established, these compromised workstations continuously exfiltrated secrets as developers worked.
The clustering of these attacks suggests either coordinated action or multiple threat actors independently exploiting the same vulnerability window.
Timeline
Initial Compromise Period (specific dates not disclosed)
- Malicious packages uploaded to npm, PyPI, and Docker Hub
- Packages passed initial automated security scans
- Downloads began accumulating across developer teams
Active Harvesting Phase (48-hour window)
- TeamPCP packages executed credential collection routines
- Shai-Hulud established persistence on infected developer workstations
- Tokens for cloud providers, git repositories, and package registries exfiltrated
- No immediate alerts triggered — developers continued normal workflows
Detection (timeline varies by organization)
- Some organizations detected anomalous network traffic from developer machines
- Others discovered the breach only after downstream supply chain indicators appeared
- Package maintainers eventually flagged and removed malicious versions
Which Controls Failed or Were Missing
Workstation Monitoring
Most organizations treat developer workstations as standard endpoints. You might run EDR, enforce disk encryption, and require VPN for network access. However, you may not monitor for supply chain indicators like:
- Outbound connections to unexpected package registries
- Credential file access patterns
- Environment variable enumeration
- SSH key reads outside normal git operations
The attacks succeeded because developer workstations had legitimate reasons to access credentials, connect to external services, and run arbitrary code. Your endpoint controls weren't calibrated to detect credential harvesting that mimicked normal development activity.
Package Verification
The malicious packages functioned as intended, providing the utility they advertised. Your dependency scanning tools likely checked for known CVEs but didn't check for:
- New packages from unverified publishers
- Packages requesting filesystem permissions beyond their stated function
- Network activity to non-standard endpoints
- Obfuscated code sections in straightforward utilities
Credential Scoping
Developer workstations held credentials with broad access:
- Cloud provider keys with production permissions
- Git tokens that could push to protected branches
- Package registry credentials that could publish new versions
- Service account tokens with cross-environment access
These credentials existed on workstations because developers needed them. However, you likely didn't have:
- Time-limited credentials that expired after hours
- Scope-limited tokens that couldn't access production
- Separate credential sets for development versus release workflows
- Audit logs showing which workstation accessed which credential when
Supply Chain Visibility
You probably can't answer these questions right now:
- Which developer workstations have published to your package registries in the last 30 days?
- What credentials exist on each workstation, and when were they last rotated?
- Which workstations have installed packages from publishers you don't recognize?
- What would you see if a workstation started exfiltrating credentials tonight?
What the Relevant Standards Require
PCI DSS v4.0.1
If your developers handle cardholder data or have access to systems that do:
Requirement 8.3.2 mandates multi-factor authentication for all access to the cardholder data environment. This includes developer access to production systems, but most implementations don't extend MFA requirements to the credentials stored on developer workstations.
Requirement 10.2.2 requires logging of actions taken by individuals with administrative access. If your developers can deploy to production from their workstations, those actions need logging — but the standard doesn't explicitly address credential harvesting from the workstation itself.
Requirement 12.6.3.1 requires security awareness training that addresses phishing and social engineering. The training should now include supply chain attacks targeting developer environments, though most programs still focus on email-based threats.
NIST CSF v2.0
ID.AM-2 (Identify: Asset Management) requires you to inventory software platforms and applications. Developer workstations are assets, but are you inventorying the credentials and secrets they contain?
PR.DS-6 (Protect: Data Security) calls for integrity checking mechanisms. For developer workstations, this means monitoring not just the OS and applications, but the packages, tools, and credentials in the development environment.
DE.CM-1 (Detect: Continuous Monitoring) requires network monitoring. But are you monitoring outbound connections from developer workstations to package registries and external services? Most network monitoring focuses on servers, not endpoints.
ISO/IEC 27001:2022
Control 8.1 (User endpoint devices) requires organizations to protect information stored on, processed by, or accessible via user endpoint devices. Developer workstations store credentials that provide access to production systems — they're not just endpoints, they're privileged access infrastructure.
Control 8.23 (Web filtering) addresses blocking access to known malicious sites. But the malicious packages came from legitimate registries. You need filtering that understands package ecosystem behavior, not just URL reputation.
Lessons and Action Items for Your Team
1. Treat Developer Workstations as Privileged Infrastructure
This week:
- Inventory which developer workstations can publish packages, deploy code, or access production
- Document what credentials exist on each workstation and what they can access
- Identify workstations that hold credentials with production access
This month:
- Implement EDR rules that flag credential file access outside normal patterns
- Set up network monitoring for outbound connections to package registries
- Create alerts for environment variable enumeration or SSH key reads
2. Scope Credentials to Minimum Necessary Access
This week:
- Audit developer credentials that have production access — do they need it?
- Identify service accounts that developers use directly from workstations
- Find long-lived tokens that haven't been rotated in 90+ days
This month:
- Implement time-limited credentials that expire daily or weekly
- Create separate credential sets for development versus release workflows
- Require MFA for any credential that can modify production or publish packages
3. Verify Packages Before Installation
This week:
- List your approved package registries and publishers
- Document which teams can install packages from public registries
- Identify packages currently in use from publishers you don't recognize
This month:
- Implement package verification that checks publisher reputation and history
- Set up alerts for new packages from first-time publishers
- Create an approval workflow for packages that request filesystem or network access beyond their stated purpose
4. Build Supply Chain Visibility
This quarter:
- Deploy logging that captures which workstation published which package when
- Implement audit trails showing credential access from developer machines
- Create dashboards showing package installation patterns across your developer fleet
- Run tabletop exercises simulating credential theft from a developer workstation
The attacks on npm, PyPI, and Docker Hub weren't sophisticated. They succeeded because developer workstations sit in a security blind spot — treated as endpoints when they function as supply chain infrastructure. Close that gap.
