Dependency Confusion Is Still Working — and Attackers Are Using It to Map Environments
A newly documented malicious npm campaign used 33 packages distributed through a dependency confusion technique to collect reconnaissance data from developer workstations and build systems. According to Microsoft Security researchers, the operation focused on profiling environments rather than immediately deploying destructive payloads or stealing large volumes of data.
Organizations that rely on npm, automated build pipelines, and internal package ecosystems should view this as a supply-chain visibility problem as much as a malware problem. Reconnaissance often comes first. Once attackers understand what environments they have reached, more targeted follow-on activity becomes possible.
What changed?#
Microsoft reported a dependency confusion campaign involving 33 malicious npm packages that were designed to gather information from developer and build environments. The operation used a known supply-chain attack pattern: publishing packages in a way that can cause package managers or build processes to retrieve attacker-controlled code instead of the intended internal dependency.
The notable detail is the objective. The reported activity focused on collecting information about the environments where the packages executed. That makes the campaign less about immediate disruption and more about intelligence gathering.
This distinction matters because reconnaissance activity is easy to underestimate. Security teams often prioritize malware that steals secrets, deploys ransomware, or establishes persistence. Profiling activity can appear less urgent. In practice, environment mapping frequently helps attackers identify where valuable credentials, cloud access, deployment systems, or sensitive workloads exist.
For organizations running large development operations, the attack surface extends beyond individual laptops. Build runners, CI/CD infrastructure, testing environments, package mirrors, and automation systems can all reveal useful operational details when exposed to malicious code.
What is dependency confusion?#
Dependency confusion is a software supply-chain attack technique that abuses the way package resolution works.
In a typical scenario, an organization maintains internal packages that are expected to remain private. An attacker publishes a package using the same or a similar name in a public repository. Under certain configurations, automated tooling may resolve and install the public package instead of the intended internal dependency.
The result is simple: attacker-controlled code executes inside a trusted development or build workflow.
The technique is not new. What continues to make it effective is that package management complexity often grows faster than governance. Large organizations accumulate internal registries, mirrors, build systems, temporary projects, legacy configurations, and third-party integrations. Small mistakes in package resolution rules can create opportunities for abuse.
Why does a reconnaissance-focused campaign matter?#
Because environment knowledge is valuable.
A malicious package does not need to immediately steal credentials to create risk. Learning how an environment is structured can help an attacker decide whether additional operations are worth pursuing.
Examples of potentially useful reconnaissance include:
- Build system characteristics
- Host and operating system details
- Development environment configuration
- Network information
- Package ecosystem information
- Indicators of cloud or enterprise infrastructure
The practical consequence is that defenders should not evaluate malicious npm activity solely by asking whether data was stolen. A package that collects information may still represent a meaningful security event because it reveals organizational structure and attack opportunities.
This is one reason software supply-chain defense increasingly emphasizes detection, provenance, and visibility rather than relying exclusively on perimeter controls.
How does this compare to direct secret theft?#
| Attack objective | Immediate impact | Long-term risk |
|---|---|---|
| Credential theft | Often visible and urgent | Direct account compromise |
| Data exfiltration | Immediate exposure | Regulatory and operational consequences |
| Reconnaissance and profiling | May appear low severity | Enables targeted follow-on attacks |
Reconnaissance campaigns frequently generate less attention because the damage is not immediately measurable. That can be a mistake. Good intelligence collection reduces attacker uncertainty, which improves the effectiveness of later operations.
What should security teams check?#
The first priority is visibility into package consumption and build activity.
Organizations should determine whether development and build environments can install packages from public sources when private dependencies are expected. Dependency resolution behavior should be reviewed rather than assumed.
Useful operational checks include:
- Review package naming practices for internal dependencies.
- Audit package source and registry configuration across CI/CD systems.
- Investigate unexpected package downloads from public repositories.
- Monitor build environments for execution of newly introduced dependencies.
- Maintain inventories of approved package sources.
- Review detection coverage for supply-chain and package-manager activity.
The broader lesson aligns with a trend seen across open source security discussions: prevention alone is insufficient. Teams need evidence about what packages were installed, where they executed, and what they attempted to do.
Related reading:
- OpenSSF’s April signal: make security artifacts operational: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational
- 100% package test coverage is the point, not the slogan: https://gigatap.top/en/articles/100-package-test-coverage-is-the-point-not-the-slogan
- Compromised npm packages put CI/CD secrets at risk: https://gigatap.top/en/articles/compromised-npm-packages-put-cicd-secrets-at-risk
What not to overclaim#
The Microsoft report describes a campaign that used malicious npm packages for reconnaissance. That alone does not automatically mean every affected environment experienced credential theft, persistence, lateral movement, or successful compromise.
The available information supports a narrower conclusion: attackers attempted to gather information from environments that executed the packages.
That distinction is important for incident response. Security teams should investigate based on evidence rather than assuming the worst-case outcome. At the same time, reconnaissance activity should not be dismissed as harmless simply because the observed objective was information collection.
FAQ#
Was this a new dependency confusion technique?#
Based on the reported information, the significance lies less in a new technique and more in the continued effectiveness of dependency confusion as an operational attack path. The campaign demonstrates that organizations remain vulnerable when package trust boundaries are unclear.
Who should care about this report?#
Organizations running npm-based development workflows, internal package ecosystems, automated build infrastructure, or CI/CD environments should pay attention. The risk is not limited to developers; build systems and automation pipelines are also potential targets.
Does a reconnaissance package automatically mean a breach occurred?#
No. Reconnaissance indicates that information gathering was attempted. Determining whether additional compromise occurred requires investigation, logging, telemetry, and evidence from the affected environment.