AN0863: Analytic 0863
A compromised package/update (deb/rpm/tarball/AppImage/vendor updater) is installed, writing/overwriting files in /usr/local/bin, /usr/bin, /opt, or ~/.local; first run executes unexpected shells/curl/wget and connects to unapproved hosts. Correlate package/updater execution → file writes/replace → first-run child processes → egress.
Analyst context for executives and security teams
This analytic matters because Linux software installation and update paths are trusted business processes. If a compromised package or updater writes into common executable locations and then launches unexpected network-capable tools on first run, it can turn normal software maintenance into an initial foothold or persistence risk. Leaders should treat this as a control and telemetry validation problem: can the organization prove what installed or updated Linux binaries, what changed on disk, what ran next, and where it connected?
Executive priority
Prioritize this where Linux systems support critical services, developer workstations, build environments, or operational infrastructure. The business decision value is in confirming that software supply-chain and update activity is observable enough for incident response, audit evidence, and rapid containment. If teams cannot correlate package or updater execution with file replacement, first-run process behavior, and outbound connections, they may be unable to distinguish legitimate maintenance from suspicious installation activity during an incident.
Technical view
For SOC, detection engineering, and IR teams, validate Linux coverage for the analytic pattern described by MITRE: package or updater execution followed by writes or overwrites in /usr/local/bin, /usr/bin, /opt, or ~/.local; then first-run child processes such as unexpected shells, curl, or wget; then egress to unapproved hosts. Because no ATT&CK tactic or formal detection logic is supplied, local implementation should focus on correlation across process execution, file modification, and network connection telemetry rather than single-event alerts.
Likely telemetry
- Linux process execution telemetry for package managers, vendor updaters, archive installers, AppImage execution, and child processes
- File creation, overwrite, rename, and permission-change events in /usr/local/bin, /usr/bin, /opt, and ~/.local
- Command-line telemetry showing unexpected shell, curl, or wget execution after installation or first run
- Network connection or proxy/DNS telemetry showing egress to unapproved hosts
- Software installation or update logs where available
Detection direction
- Build correlation logic that links installer/updater execution to executable-path file writes, then to first-run child processes and outbound connections.
- Tune allowlists carefully for approved repositories, vendor update services, expected post-install scripts, and sanctioned administrative activity.
- Pay attention to blind spots on Linux endpoints that lack file integrity monitoring, command-line capture, or outbound network attribution by process.
- Avoid relying only on package manager logs, because the object explicitly includes deb/rpm/tarball/AppImage/vendor updater scenarios.
- Use investigation playbooks to confirm package source, file hash provenance where available, owner/user context, destination host reputation or approval status, and whether the changed binary is newly executed.
Mitigation priorities
- Strengthen governance for approved Linux software sources, repositories, vendor updaters, and manual installer use.
- Restrict or review write access to common executable locations and user-local execution paths where operationally feasible.
- Ensure endpoint and network telemetry can correlate installer activity, file writes, child process execution, and egress.
- Maintain an approved-destination model for update and package infrastructure so unapproved egress can be triaged quickly.
- Prepare IR procedures for isolating affected Linux hosts, preserving installer artifacts and modified files, and validating whether other systems received the same package or update.
Analyst notes and limits
This is a detection analytic object, not a technique description. The supplied ATT&CK fields identify Linux as the platform and describe a behavioral chain involving compromised packages or updates, executable-path file replacement, unexpected first-run child processes, and outbound connections. No relationships, tactics, aliases, labels, or official detection text were supplied, so the take focuses on defensive validation and operational readiness rather than attribution or campaign context.
The object does not provide formal detection logic, data source mappings, ATT&CK tactic mapping, related techniques, mitigations, or examples. Any production detection must be adapted to local Linux software deployment practices, approved repositories, updater behavior, endpoint telemetry depth, and network egress policy.
Analytic 0863
A compromised package/update (deb/rpm/tarball/AppImage/vendor updater) is installed, writing/overwriting files in /usr/local/bin, /usr/bin, /opt, or ~/.local; first run executes unexpected shells/curl/wget and connects to unapproved hosts. Correlate package/updater execution → file writes/replace → first-run child processes → egress.
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 | 98b20737fffa… |
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 AN0863Open 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.