AN0984: Analytic 0984
Detects renamed binaries or scripts placed into trusted paths like /usr/bin or /lib with mismatched metadata or unexpected creation/modification times.
Analyst context for executives and security teams
This analytic matters because trusted Linux paths such as /usr/bin and /lib are commonly assumed to contain legitimate operating system or package-managed content. A renamed binary or script placed there can blend into normal administration and weaken incident response confidence. The business question is whether the organization can distinguish expected system files from unexpected additions or modifications in trusted directories before they become an operational or audit issue.
Executive priority
Prioritize this as a Linux integrity and readiness control: confirm which teams own monitoring of trusted system paths, how quickly unexpected file changes are reviewed, and whether evidence is available for incident response and compliance inquiries. The value is not just alerting—it is being able to prove that critical Linux hosts have baseline-aware monitoring for suspicious file placement or metadata mismatch in sensitive directories.
Technical view
For SOC and detection engineering, validate collection and correlation for Linux file creation, modification, ownership, permissions, timestamps, path, filename, and file metadata in trusted locations such as /usr/bin and /lib. Because the official object provides no tactic mapping or detailed detection logic, implementation should focus on comparing observed files against known-good package or host baselines and identifying renamed binaries or scripts whose metadata or creation/modification times do not match expectations.
Likely telemetry
- Linux file creation events in trusted paths such as /usr/bin and /lib
- Linux file modification events, including timestamp changes
- File metadata: owner, group, permissions, size, hashes where available, and executable/script indicators
- Package or host baseline data for expected files in trusted directories
- Process execution telemetry for newly created or recently modified binaries/scripts in those paths
Detection direction
- Validate that telemetry covers trusted Linux paths, not only user-writable or temporary directories.
- Tune detections against approved package manager activity, operating system updates, and planned maintenance to reduce false positives.
- Compare files in /usr/bin, /lib, and similar trusted locations against known-good baselines to identify unexpected names, metadata mismatches, or unusual creation/modification times.
- Escalate findings when file placement in trusted paths is paired with execution, unusual ownership or permissions, or absence from expected package inventory.
- Identify blind spots where endpoint telemetry, file integrity monitoring, or package inventory is not deployed on Linux servers.
Mitigation priorities
- Establish and maintain baselines for trusted Linux directories on critical hosts.
- Restrict write access to trusted system paths to authorized administrative processes and accounts.
- Use change control or maintenance records to separate legitimate updates from unexplained file changes.
- Deploy or validate file integrity monitoring or equivalent endpoint telemetry for sensitive Linux directories.
- Ensure incident response playbooks include preservation and review of file metadata, hashes, ownership, permissions, and related execution history.
Analyst notes and limits
This is a detection analytic object, not a technique object. No ATT&CK tactics, relationships, aliases, or detailed detection procedure were supplied. Treat it as guidance for validating Linux trusted-path integrity monitoring rather than as evidence of a specific adversary behavior chain.
The supplied ATT&CK fields only state that the analytic detects renamed binaries or scripts in trusted Linux paths with mismatched metadata or unexpected creation/modification times. No official detection logic, relationship context, data source list, or mitigation text was provided, so local baselines and environment-specific telemetry are required to operationalize it.
Analytic 0984
Detects renamed binaries or scripts placed into trusted paths like /usr/bin or /lib with mismatched metadata or unexpected creation/modification times.
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 | 729c40eccc43… |
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 AN0984Open 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.