AN0022: Analytic 0022
Developer or CI invokes package managers/compilers (apt/yum + build-essential, npm/yarn/pnpm, pip/pip3, gem, cargo, go, maven/gradle). These write executable or script files into PATH or project dirs and immediately execute embedded lifecycle hooks (preinstall/postinstall, setup.py, npm scripts) that spawn shells or curl/wget, followed by egress to unfamiliar registries or domains.
Analyst context for executives and security teams
This analytic highlights a Linux software-build and package-install behavior that can turn normal developer or CI activity into a security decision point. Package managers and compilers often create executable files and run install/build hooks automatically; when those hooks spawn shells or download tools and then connect to unfamiliar registries or domains, defenders need to separate expected engineering activity from potentially unsafe dependency or build-chain behavior.
Executive priority
Prioritize this as a software supply chain and CI/CD visibility question. Leaders should ask whether Linux developer workstations and build runners produce enough evidence to prove what package managers ran, what scripts they executed, and where they connected afterward. The business value is not just alerting; it is being able to support incident response, audit evidence, and dependency-risk decisions when a build process reaches unfamiliar external services.
Technical view
For SOC, detection engineering, and IR teams, validate monitoring around Linux package manager and compiler executions such as apt, yum, npm, yarn, pnpm, pip, pip3, gem, cargo, go, maven, and gradle. Focus on child-process behavior from install or lifecycle hooks, especially shells, curl, or wget, followed by outbound network activity to registries or domains that are not already understood for the environment. Because no official detection logic is supplied, teams should build environment-specific baselines for normal CI and developer package activity before escalating anomalies.
Likely telemetry
- Linux process execution telemetry with parent/child process relationships
- Command-line arguments for package managers, compilers, shells, curl, and wget
- File creation or modification events for executable or script files in PATH and project directories
- CI runner or build job logs showing package installation and lifecycle script execution
- Network connection, DNS, proxy, or egress logs for registry and domain access
Detection direction
- Validate that telemetry preserves process lineage from package manager or compiler invocation to lifecycle hooks and spawned shells/download utilities.
- Baseline approved registries, repositories, package mirrors, and build-time domains for Linux developer and CI environments.
- Tune detections to account for legitimate build steps that commonly run scripts or download dependencies, using project, runner, repository, and destination context to reduce false positives.
- Prioritize investigation when executable/script writes in PATH or project directories are closely followed by shell execution or curl/wget egress to unfamiliar destinations.
- Review blind spots in ephemeral CI runners, short-lived containers, developer laptops, and environments where command-line, DNS, or proxy logs are not retained.
Mitigation priorities
- Establish approved package sources, registries, and repository mirrors for Linux build and developer workflows.
- Require logging and retention for CI job activity, process execution, file writes, and network egress relevant to package installation and builds.
- Apply egress controls or review gates for build systems that contact unfamiliar registries or domains.
- Harden CI/build environments so lifecycle-script execution and downloaded content are observable and attributable to a job, project, and user or service account.
- Use local baselines and exception management so normal engineering workflows are documented rather than hidden by noisy alerts.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Linux and describes suspicious package/build lifecycle behavior, but it has no tactic mapping, no relationship context, and no official detection text. Treat this as guidance for coverage validation and analytic design rather than a complete rule.
Assessment is limited to the official STIX fields and the single MITRE external reference provided. No claims are made about active exploitation, threat actors, prevalence, impact, or guaranteed detection. Local CI/CD architecture, developer workflows, package sources, and logging coverage are required to determine priority and detection fidelity.
Analytic 0022
Developer or CI invokes package managers/compilers (apt/yum + build-essential, npm/yarn/pnpm, pip/pip3, gem, cargo, go, maven/gradle). These write executable or script files into PATH or project dirs and immediately execute embedded lifecycle hooks (preinstall/postinstall, setup.py, npm scripts) that spawn shells or curl/wget, followed by egress to unfamiliar registries or domains.
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 | fb9831e83ecd… |
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 AN0022Open 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.