AN0056: Analytic 0056
Executable or binary files created without symbol tables or with stripped sections, especially by non-user shell processes or compilers invoked outside standard dev paths.
Analyst context for executives and security teams
This analytic matters because stripped Linux executables can reduce visibility for defenders and responders. The ATT&CK object focuses on binary files created without symbol tables or with stripped sections, especially when produced by non-user shell processes or compilers running outside normal development paths. For leaders, the value is not treating every stripped binary as malicious, but verifying whether the organization can distinguish expected software build activity from unusual executable creation on Linux systems.
Executive priority
Prioritize this as a Linux visibility and incident-readiness question: do security teams have enough file, process, and build-environment telemetry to explain when and where stripped executables are created? This is useful for SOC tuning, IR triage, compliance evidence around endpoint monitoring, and control prioritization for servers where unexpected executable creation could affect business continuity. Because no tactic, technique relationship, or official detection logic is supplied, this should be treated as a coverage-validation analytic rather than a standalone risk conclusion.
Technical view
SOC and detection teams should validate whether Linux telemetry can identify executable or binary file creation, determine whether symbol tables or sections are missing/stripped, and correlate the file event to the creating process. The most relevant context from the object is whether creation is performed by non-user shell processes or by compilers invoked outside standard development paths. Detection engineering should establish local baselines for legitimate build systems, package installation, CI/CD runners, and developer workstations before alerting on stripped binaries broadly.
Likely telemetry
- Linux file creation and modification events for executable or binary paths
- Process creation telemetry showing parent/child process lineage
- Command-line telemetry for compiler, linker, strip, or build-related utilities where available
- File metadata or binary analysis results indicating missing symbol tables or stripped sections
- User, service account, and working-directory context for the creating process
Detection direction
- Validate that Linux endpoint logging can connect a newly created executable to the process and user or service account that created it.
- Tune against expected development and software packaging activity; stripped binaries are common in legitimate production software and should not be treated as inherently malicious.
- Give higher review priority to stripped executable creation by non-user shell processes or compiler activity outside approved development paths, as described by the ATT&CK object.
- Use environment-specific allowlists for standard build directories, CI/CD systems, package managers, and sanctioned compiler workflows.
- Document blind spots where file content inspection, binary metadata extraction, or process command-line collection is unavailable.
Mitigation priorities
- Inventory where Linux executable creation is expected, including developer hosts, build servers, CI/CD runners, and package management workflows.
- Restrict or monitor compiler and build-tool use on systems that are not intended for development or software build activity.
- Improve endpoint telemetry so file creation, process lineage, command line, user context, and binary metadata can be reviewed during triage.
- Create response playbooks for unexpected executable creation on Linux systems, including preservation of the binary, process tree, user context, and surrounding file activity.
- Use the analytic as supporting evidence for monitoring maturity rather than as a standalone control requirement, because ATT&CK does not provide official detection logic for this object.
Analyst notes and limits
The supplied object is a detection analytic for Linux only. It describes a behavioral signal around stripped executables and unusual creation context, but provides no official detection query, no tactic mapping, and no relationship context. The strongest practical use is to drive telemetry validation and tuning around Linux binary creation and build-tool activity.
No official detection text, ATT&CK tactic, related technique, software, group, campaign, or mitigation relationships were supplied. Any judgment about maliciousness, prevalence, exploitation, or coverage requires local environment baselines and telemetry review.
Analytic 0056
Executable or binary files created without symbol tables or with stripped sections, especially by non-user shell processes or compilers invoked outside standard dev paths.
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 | 99a4dba1accb… |
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 AN0056Open 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.