AN1154: Analytic 1154
Reading of sensitive files like .bash_history, /etc/shadow, or private key directories by unauthorized users or unusual processes.
Analyst context for executives and security teams
This analytic matters because unauthorized or unusual access to Linux sensitive files can be an early warning that credentials, private keys, or privileged account data are at risk. For executives and security leaders, the decision value is not simply whether a rule exists, but whether the organization can prove it can see access to files such as shell history, /etc/shadow, and private key directories on Linux systems that support critical services.
Executive priority
Prioritize this as a validation point for Linux server monitoring, privileged access governance, and incident readiness. Leaders should ask which Linux assets hold sensitive authentication material, whether access to those files is logged, and whether SOC/IR teams have a documented escalation path when an unusual process or unauthorized user reads them. This can also support audit evidence around access control monitoring and protection of privileged credentials.
Technical view
The supplied ATT&CK analytic is scoped to Linux and describes reads of sensitive files such as .bash_history, /etc/shadow, and private key directories by unauthorized users or unusual processes. Because no official detection logic, tactics, or relationship context were supplied, defenders should treat this as a detection engineering requirement: define the sensitive file paths relevant to the environment, identify expected users and processes, and alert on deviations. SOC teams should validate that Linux file access telemetry can distinguish user, process, file path, host, timestamp, and privilege context.
Likely telemetry
- Linux file access auditing for sensitive paths
- Process execution and parent/child process context
- User identity, UID/GID, and privilege escalation context
- Host and asset criticality metadata
- Authentication and session logs tied to the accessing user
Detection direction
- Confirm that Linux auditing or equivalent telemetry records read access to sensitive files, not only file modifications.
- Build allowlists for expected administrative tools, service accounts, backup processes, and security tooling to reduce false positives.
- Tune for unusual process names, unexpected parent processes, non-administrative users, or access outside normal maintenance windows.
- Correlate file access with login/session activity and recent privilege changes to support triage.
- Watch for blind spots on unmanaged Linux hosts, ephemeral systems, containers or minimal images, and systems where audit policies do not capture read events.
Mitigation priorities
- Inventory Linux systems that store sensitive account data, shell history, or private keys.
- Restrict file and directory permissions to the minimum required users and processes.
- Harden privileged access workflows and review service account access to sensitive paths.
- Enable and test Linux audit coverage for read access to high-value files and directories.
- Document SOC escalation and IR collection procedures for suspected credential or key exposure.
Analyst notes and limits
This object is a detection analytic, not a full technique description. The official description is narrow and Linux-specific: reading sensitive files by unauthorized users or unusual processes. Since no relationships or official detection logic were supplied, the Glexia take focuses on validation questions, telemetry requirements, and operational readiness rather than asserting a specific ATT&CK tactic or threat behavior chain.
No official detection content, tactics, related techniques, groups, software, campaigns, or mitigations were supplied. Local file paths, authorized process baselines, service account behavior, and logging capability must be validated in the customer environment before this can be converted into reliable production detection logic.
Analytic 1154
Reading of sensitive files like .bash_history, /etc/shadow, or private key directories by unauthorized users or unusual processes.
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 | 857597a1c22c… |
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 AN1154Open 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.