12 minhigh
Batten Down Your Packages: Mitigation Guidance for Supply Chain Compromise
Google Threat Intelligence Group (GTIG) and Mandiant report a significant escalation in open source software supply chain compromises throughout 2025 and early 2026, with malicious package detections increasing 1,444% year-over-year. Threat actors including UNC6780 (TeamPCP), MIDNIGHT NEPTUNE, and UNC4899 have exploited package registries (PyPI, npm, Docker Hub), GitHub Actions triggers, and developer social engineering to deploy credential stealers, backdoors, and cryptocurrency theft mechanisms. The integration of AI into development workflows further accelerates this threat vector as AI coding agents unwittingly incorporate malicious dependencies into legitimate projects.
Conf:high
Detection / Hunteropenrouter
What Happened
Hackers are increasingly targeting the open source software that developers rely on, compromising legitimate code packages to sneak in malware. In 2025 and early 2026, the number of malicious open source packages detected grew by over 1,400% compared to the previous year. Several major incidents occurred, including the compromise of a widely used JavaScript package called axios (downloaded over 100 million times per week), and a cryptocurrency theft of approximately $1.4 billion from a web3 organization after a developer was tricked into running malicious code. Organizations that use open source code—which is nearly all of them—should implement cooling-off periods for new package updates, maintain inventories of their software dependencies, use private package registries, and disable automatic installation scripts. The rise of AI-assisted coding tools makes this threat worse, as AI agents may automatically incorporate compromised packages into projects without human review.
Key Takeaways
- Open source supply chain compromises grew exponentially in 2025-early 2026, with malicious package counts increasing 1,444% from 2024 to 2025 per OpenSSF data
- UNC6780 (TeamPCP) conducted large-scale compromises across PyPI, npm, and Docker Hub using pull_request_target GitHub Actions trigger abuse to steal credentials via SANDCLOCK and pivot from compromised AI software to broader networks
- North Korean actor MIDNIGHT NEPTUNE compromised the axios npm package (100M+ weekly downloads) via social engineering of a maintainer account, deploying WAVESHAPER.V2 backdoor through a malicious dependency
- UNC4899 stole approximately $1.4B USD in cryptocurrency by socially engineering a developer at a web3 organization and injecting malicious code into frontend smart contract functionality
- AI integration into development workflows (vibe coding, AI coding agents, MCP packages) is accelerating supply chain risk as threat actors plant malicious resources that AI agents unwittingly incorporate into projects
Affected Systems
- PyPI package registry
- npm package registry
- Docker Hub
- GitHub Actions CI/CD pipelines
- Node.js (npm/pnpm) development environments
- Python (pip) development environments
- Notepad++ (compromised update hosting, June-December 2025)
- DAEMON Tools installers (compromised, early 2026)
- axios npm package (compromised, March 2026)
- Web3/cryptocurrency platforms and multi-signature wallets
- Automotive dealership websites
- eCommerce websites
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Threat actor compromises open source package maintainer account via social engineering, credential theft, or abuse of pull_request_target GitHub Actions trigger to obtain repository secrets and write permissions
- Execution: Attacker publishes malicious package version containing dropper code or malicious dependency that deploys backdoors (e.g., WAVESHAPER.V2) or credential stealers (e.g., SANDCLOCK)
- Propagation: Malicious package spreads through downstream dependency ecosystems as other packages and projects automatically update or install the compromised version
- Credential Access: Malicious install scripts or post-installation hooks execute on developer workstations and CI/CD runners to steal API tokens, SSH keys, and session credentials
- Lateral Movement: Attacker uses stolen credentials to pivot from compromised development environments or AI software to broader network infrastructure
- Impact: Stolen credentials monetized through direct sale, ransomware/extortion partnerships, or targeted cryptocurrency theft (e.g., $1.4B USD in UNC4899 campaign)
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules (YARA, Sigma, Snort/Suricata, KQL, SPL, EQL) are provided in this article. The article focuses on mitigation guidance, hardening recommendations, and threat trend analysis rather than specific detection logic.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Medium | EDR can detect post-execution malicious activities from supply chain compromises (e.g., credential stealer behavior, unauthorized code execution from install scripts), but distinguishing malicious package install scripts from legitimate development activity is challenging. The article recommends EDR across infrastructure and developer workstations. |
| Network Visibility | Medium | Network monitoring can detect suspicious egress flows to external repositories or unrecognized IPs, and egress filtering can block unauthorized C2 connections. However, malicious packages often communicate through legitimate package registry domains, making network-level detection difficult without deep inspection. |
| Detection Difficulty | Hard | Open source supply chain compromises blend with legitimate development activity. Malicious package updates appear identical to normal updates, install scripts execute in expected contexts, and AI coding agents may automatically incorporate compromised packages. Detection requires correlating telemetry across CI/CD pipelines, package registries, developer endpoints, and network flows—often with behavioral analysis rather than simple signature matching. |
Required Log Sources
- CI/CD pipeline and workflow execution logs
- Package registry access and publication logs
- GitHub Actions workflow trigger logs (especially pull_request_target events)
- Developer workstation EDR telemetry
- Network egress and proxy logs
- Authentication logs for package registry and version control systems
- SBOM generation and vulnerability scanning outputs
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for newly published package versions that were installed within hours of their release, as supply chain compromises often rely on rapid propagation before detection. Packages installed within a 24-hour window of publication may warrant additional scrutiny. | Package manager logs, CI/CD pipeline build logs, artifact repository access logs | Execution | High — legitimate rapid adoption of new package versions is common, especially for popular packages or security patches. |
| Consider hunting for GitHub Actions workflows using the pull_request_target trigger with write permissions or secrets access, as this trigger has been explicitly abused in multiple supply chain campaigns to obtain repository credentials. | GitHub Actions workflow execution logs, repository audit logs, CI/CD pipeline configuration change logs | Initial Access | Medium — pull_request_target has legitimate uses, but its combination with elevated permissions is a strong indicator of risk. |
| Consider hunting for npm or pip install processes that spawn unexpected child processes or initiate network connections to non-registry domains, as malicious install scripts often execute post-installation commands to steal credentials or download secondary payloads. | EDR process telemetry, network connection logs, DNS resolution logs from developer workstations and CI/CD runners | Credential Access | Medium — some legitimate packages run post-install scripts for compilation or configuration, but network connections to non-registry endpoints are unusual. |
| Consider hunting for authentication events using long-lived static tokens (PATs, API keys) from unrecognized IP addresses or regions, as compromised supply chain credentials are often used from attacker-controlled infrastructure. | Authentication logs, identity provider logs, version control system access logs | Credential Access | Low to Medium — developer travel or VPN usage may generate alerts, but unrecognized region access with static tokens warrants investigation. |
| Consider hunting for anomalous CI/CD workflow modifications or triggers (e.g., repository_dispatch) that bypass standard code-review gates, as attackers may modify pipelines to harvest credentials or publish unauthorized packages. | CI/CD configuration change logs, workflow trigger logs, version control commit history | Persistence | Low — unauthorized workflow modifications outside of standard review processes are inherently suspicious. |
Control Gaps
- Traditional signature-based antivirus will not detect malicious packages that execute through legitimate package manager processes
- Network firewalls may not block connections to legitimate package registry domains used for C2 or data exfiltration
- Static code analysis tools may not flag malicious install scripts embedded in third-party dependencies
- Automated dependency update tools (e.g., Dependabot without cooldowns) can accelerate propagation of compromised packages before community detection
- SAML SSO cannot enforce continuous session security for programmatic CLI connections, allowing stolen tokens to persist without re-challenge
- AI coding agents that automatically integrate dependencies bypass human code review controls
Key Behavioral Indicators
- Package install processes (npm, pip) spawning unexpected child processes or network connections
- GitHub Actions workflows using pull_request_target trigger with elevated permissions or secrets access
- Newly published package versions installed within hours of release without cooling period
- Authentication using long-lived static tokens from unrecognized IP addresses or geographic regions
- Unauthorized CI/CD workflow modifications or anomalous trigger types bypassing code review
- Shell-escape characters or command-substitution patterns in untrusted input variables within pipeline logs
- Post-installation scripts attempting to access credential stores, SSH keys, or environment variables containing secrets
False Positive Assessment
High — Many of the described attack techniques (package installation, CI/CD workflow execution, dependency updates) are indistinguishable from normal development activity at the technical level. Distinguishing malicious package updates from legitimate ones, and malicious install scripts from legitimate post-installation hooks, requires behavioral analysis and contextual correlation across multiple telemetry sources. Cooling periods and allow-list approaches will generate false positives for legitimate urgent updates.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider enforcing cooldown controls on package managers (e.g., minimumReleaseAge of at least 24 hours for npm/pnpm) to quarantine freshly published packages until the security community has time to identify malicious releases.
- Consider disabling automatic lifecycle scripts in npm by setting ignore-scripts=true in repository-level .npmrc files, and configuring native allowlists such as pnpm's onlyBuiltDependencies to restrict execution to verified tools only.
- If applicable, consider auditing npm package maintainer accounts for stale or expired recovery email domains, as attackers can purchase these domains to intercept password resets and take over package registry accounts.
- Consider reviewing GitHub Actions workflows for use of the pull_request_target trigger and restricting it to only necessary workflows with minimal permissions and no secrets access.
- Evaluate whether your Python project environments pull dependencies directly from public PyPI; if so, consider configuring a secure private --index-url to ensure consistent quarantine and vetting of upstream packages.
Infrastructure Hardening
- Consider transitioning third-party integrations and build-system processes away from static, long-lived PATs to short-lived system tokens via federated OIDC for automated machine integrations.
- If supported by your platform, consider restricting Personal Access Tokens globally and mandating FIDO2 hardware-backed SSH keys for all command-line repository actions.
- Consider utilizing ephemeral, single-use CI/CD runners that are purged immediately after completing a build task to prevent persistent attacker presence between build phases.
- Evaluate implementing network micro-segmentation with allow-list-only firewall rules to block unauthorized outbound traffic from CI/CD runners and disrupt potential C2 activities.
- Consider integrating Google's Assured Open Source Software or equivalent provenance-verified artifact sources into internal workflows to defend against dependency confusion and malicious hijacking.
- If using Dependabot, consider enabling native cooldown features (available July 2026) to delay automated update PRs for upstream compromise discovery.
User Protection
- Consider enforcing strict token expiration policies (e.g., maximum 7-day lifespan) for all personal access tokens and programmatic API keys to limit the window of credential compromise.
- Consider deploying EDR tools across both infrastructure and developer workstations to detect post-execution malicious activities from supply chain compromises.
- Consider isolating CI/CD runners in restricted network segments with strict egress filtering to block unauthorized connections to external domains even if an exploit is triggered.
- Evaluate whether developer CLI sessions are adequately secured; SAML SSO only verifies identity during initial token creation, so consider hardware-backed credential controls for programmatic access.
Security Awareness
- Consider deploying ongoing training initiatives focused on supply chain hazards, social engineering techniques, and internal procedures for reporting incidents.
- Consider incorporating tabletop exercises covering upstream package takeover, dependency confusion exploits, automated pipeline harvesting, and developer workstation compromise scenarios into existing security exercise programs.
- Consider educating development teams on the risks of AI coding agents automatically incorporating unvetted dependencies, and establish review procedures for AI-suggested package additions.
- If applicable, consider forming a Change Advisory Board to manage the rollout of all enterprise software and hardware with pre-deployment risk reviews and post-deployment monitoring.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping5 techniques
Tactic
Initial Access
Tactic
Execution
Tactic
