AN0783: Analytic 0783
Detects sequential command-line compression utilities (e.g., gzip, tar, zip, 7z) followed by execution of unpacked files, especially in temp directories or under non-standard locations like /dev/shm or /tmp with ELF binaries.
Analyst context for executives and security teams
This analytic matters because compressed payload staging followed by execution from temporary or unusual Linux locations can indicate software deployment activity, admin troubleshooting, or malicious staging. For leaders, the decision value is whether the organization can distinguish legitimate Linux package/archive workflows from suspicious execution paths such as /tmp or /dev/shm before an incident becomes harder to scope.
Executive priority
Prioritize this as a Linux endpoint and server visibility question: do SOC and IR teams have enough command-line, process lineage, file, and execution telemetry to prove what was unpacked, where it ran from, and which account initiated it? It is most useful for resilience and audit readiness when applied to high-value Linux systems, shared infrastructure, and environments where temporary directories are commonly abused or poorly monitored.
Technical view
Validate detection logic for sequential use of command-line compression utilities such as gzip, tar, zip, and 7z followed by execution of extracted files. Focus on process chains, parent/child relationships, working directories, file paths, and execution from non-standard or temporary locations including /tmp and /dev/shm. Because no ATT&CK tactic or relationship context is supplied, treat this as a behavior-level analytic rather than a complete incident conclusion.
Likely telemetry
- Linux process creation events with full command line
- Parent/child process lineage
- File creation and extraction activity
- Execution path and working directory data
- ELF binary execution metadata
Detection direction
- Tune for ordered sequences: archive/compression utility use followed by execution of newly unpacked files.
- Increase priority when execution occurs from /tmp, /dev/shm, or other non-standard locations.
- Account for expected software installation, backup, build, and deployment workflows to reduce false positives.
- Validate that telemetry preserves command-line arguments and process lineage; without both, this analytic may lose key context.
- Correlate with asset criticality and user role before escalation because the supplied object does not provide tactic, technique, actor, or campaign context.
Mitigation priorities
- Ensure Linux endpoint monitoring captures process, command-line, file, and execution-path evidence on relevant servers and workstations.
- Restrict or monitor execution from temporary and shared-memory locations where operationally feasible.
- Define approved software deployment and archive-extraction workflows so SOC teams can distinguish normal administration from suspicious staging.
- Use incident response playbooks that preserve extracted files, process lineage, user context, and host timeline when this pattern appears.
- Review Linux hardening and access controls for systems where untrusted users or services can write to executable locations.
Analyst notes and limits
This is a detection analytic object, not a full ATT&CK technique. Its value is in validating whether Linux telemetry can connect archive extraction behavior to subsequent execution, especially from temporary or unusual directories. Local baselining is important because compression utilities are common in legitimate administration and deployment workflows.
The supplied ATT&CK fields provide no official detection text beyond the description, no tactics, no relationships, and no attribution or exploitation context. Conclusions about maliciousness, impact, or coverage require local telemetry, asset context, and investigation evidence.
Analytic 0783
Detects sequential command-line compression utilities (e.g., gzip, tar, zip, 7z) followed by execution of unpacked files, especially in temp directories or under non-standard locations like /dev/shm or /tmp with ELF binaries.
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 | 4d2c0ea2b44e… |
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 AN0783Open 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.