AN0021: Analytic 0021
Adversary manipulates dependencies/dev tools used by developers or CI: a package manager (npm/yarn/pnpm, pip/pipenv, nuget/dotnet, chocolatey/winget, maven/gradle) or a compiler/IDE downloads or restores content; files are written under project paths and execution paths (node_modules, packages, .nuget, .gradle, .m2, %AppData%\npm, %UserProfile%\.cargo\bin, temp build dirs). First run of newly written components triggers scripts (preinstall/postinstall), shell/PowerShell spawning, or loader DLLs, followed by network egress to non-approved registries/CDNs.
Analyst context for executives and security teams
This analytic is relevant because developer workstations and CI build paths can become a business-critical entry point when dependencies, package managers, IDEs, or compilers download and execute newly restored content. For leaders, the decision value is whether software delivery environments have enough visibility to distinguish expected package restore activity from suspicious first-run scripts, shell or PowerShell spawning, DLL loading, and network egress to unapproved registries or CDNs on Windows systems.
Executive priority
Prioritize this where Windows developer endpoints or CI systems are material to product delivery, internal tooling, or regulated software change processes. The key business question is whether security teams can prove which package sources are approved, which build tools are allowed to execute scripts, and whether SOC/IR teams can reconstruct dependency-driven execution during an incident. This supports resilience, supply-chain risk management, and audit evidence around software build integrity.
Technical view
Validate monitoring around Windows package and build tooling named in the analytic, including npm/yarn/pnpm, pip/pipenv, nuget/dotnet, chocolatey/winget, maven/gradle, compilers, and IDE-driven restore activity. Focus on file writes under project and execution paths such as node_modules, packages, .nuget, .gradle, .m2, %AppData%\npm, %UserProfile%\.cargo\bin, and temporary build directories, followed by first-run execution behavior. Detection engineering should correlate new dependency files with preinstall/postinstall scripts, shell or PowerShell child processes, loader DLL activity, and outbound connections to registries or CDNs that are not approved for the environment.
Likely telemetry
- Windows process creation telemetry, including parent-child relationships from package managers, build tools, compilers, and IDEs
- File creation and modification events in dependency, package cache, project, user profile, and temporary build directories
- Command-line telemetry for install, restore, build, and script execution activity
- PowerShell and shell execution telemetry spawned by developer or CI tooling
- DLL load telemetry where available for newly written components or build-related paths
Detection direction
- Baseline normal dependency restore and build behavior for Windows developer and CI assets before alerting on all package-manager activity.
- Correlate file writes in dependency paths with immediate execution, script hooks, shell or PowerShell spawning, DLL loads, and outbound network activity.
- Tune detections around unapproved or unusual registries/CDNs rather than treating all public package traffic as equally suspicious.
- Separate interactive developer activity from automated CI activity; expected parent processes, working directories, and schedules will differ.
- Watch for blind spots where endpoint telemetry excludes project directories, package caches, user profile paths, or temporary build directories.
Mitigation priorities
- Define and maintain approved package registries, mirrors, and CDNs for developer and CI environments.
- Restrict or monitor dependency script execution where operationally feasible, especially install-time hooks that spawn shells or PowerShell.
- Harden Windows developer endpoints and CI agents with least privilege, controlled build tooling, and clear separation between development and production credentials.
- Ensure package manager caches, project dependency paths, and temporary build locations are included in endpoint visibility and retention policies.
- Require change control or documented exceptions for new package sources and build toolchain changes.
Analyst notes and limits
The supplied object is a detection analytic, not a technique, and does not specify ATT&CK tactics or relationships. Its strongest value is as a validation checklist for Windows software development and CI telemetry around dependency restore, first execution, and outbound package-source behavior.
Official detection content is not provided, and no relationships are supplied. This take is limited to the official description, Windows platform field, external reference, and object metadata. Local package manager usage, approved registry policy, CI architecture, and endpoint logging coverage are required to determine applicability and detection quality.
Analytic 0021
Adversary manipulates dependencies/dev tools used by developers or CI: a package manager (npm/yarn/pnpm, pip/pipenv, nuget/dotnet, chocolatey/winget, maven/gradle) or a compiler/IDE downloads or restores content; files are written under project paths and execution paths (node_modules, packages, .nuget, .gradle, .m2, %AppData%\npm, %UserProfile%\.cargo\bin, temp build dirs). First run of newly written components triggers scripts (preinstall/postinstall), shell/PowerShell spawning, or loader DLLs, followed by network egress to non-approved registries/CDNs.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 5051e735f0b1… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0021Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.