DET0563: Detection Strategy for Defense Impairment via Prevent Command History Logging across OS platforms.
MITRE ATT&CK DET0563: Detection Strategy for Defense Impairment via Prevent Command History Logging across OS platforms. Detection Strategy details, with detection…
Security context for executives and security teams
DET0563 is a MITRE detection strategy for identifying attempts to prevent command history logging, related to ATT&CK technique T1690. The business significance is that command history is often one of the fastest ways responders reconstruct what happened on Linux, macOS, ESXi, and network-device administrative sessions. If that record is impaired, investigations take longer, containment decisions become less certain, and audit evidence may be incomplete.
Executive priority
Treat this as an incident-response and resilience visibility issue, not just a logging detail. Leaders should ask whether administrative activity on the related platforms is centrally captured even when local command history is missing or altered. Priority should go to environments where privileged shell or device administration is business-critical and where loss of local history would materially slow containment, root-cause analysis, or compliance evidence production.
Technical view
The supplied ATT&CK object has no official description or detection logic, but it detects T1690: Prevent Command History Logging under defense-impairment. SOC and IR teams should validate whether they can detect suspicious interruption, redirection, or absence of expected command history artifacts, especially around administrative sessions on ESXi, Linux, macOS, and network devices. Detection should not rely only on local history files because the behavior itself is intended to impair that source; teams should compare local history expectations against independent telemetry such as process execution, session, audit, and centralized administrative logs.
Likely telemetry
- Shell and terminal session records where available
- Process execution telemetry and command-line metadata
- File and configuration change events involving user command history locations or shell history settings
- Environment-variable or shell startup/profile configuration changes where collected
- Authentication and privileged session logs for administrative users
Detection direction
- Validate that detections do not depend solely on local command history files, since the related technique is specifically about impairing that evidence source.
- Look for mismatches between authenticated administrative sessions and missing, truncated, redirected, or unexpectedly disabled command history artifacts.
- Correlate command-history anomalies with process execution, privilege use, remote access, and configuration-change telemetry to reduce false positives from legitimate administrator preferences or managed baseline changes.
- Tune for platform differences across ESXi, Linux, macOS, and network devices; each may expose different shell, audit, and administrative logging sources.
- Establish known-good baselines for administrative accounts and managed images so detection engineering can distinguish approved shell-history configuration from suspicious defense impairment.
Mitigation priorities
- Centralize administrative and endpoint telemetry so investigations do not depend only on per-user local command history.
- Restrict and monitor changes to shell startup files, history settings, and administrative logging configuration on relevant platforms.
- Ensure privileged access workflows preserve independent session or command accountability where feasible.
- Document expected logging behavior for Linux, macOS, ESXi, and network-device administration so SOC teams can identify deviations.
- Test incident-response playbooks against scenarios where local command history is unavailable, incomplete, or intentionally impaired.
Additional notes and limits
This take is based on the supplied detection-strategy metadata and its relationship to T1690. Because MITRE provided no official detection text for DET0563 in the supplied fields, the guidance focuses on validation questions, telemetry dependencies, and conservative detection design rather than a specific analytic.
The detection strategy object does not specify platforms, tactics, a description, or official detection logic. Platform and tactic context comes from the related T1690 technique only. Local operating procedures, logging configuration, and available telemetry are required to determine actual coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Detection Strategy for Defense Impairment via Prevent Command History Logging across OS platforms.
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1690 | Prevent Command History Logging | This object detects Prevent Command History Logging. |
All related ATT&CK context
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 | d0595511c46c… |
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-attackDET0563Open source URL
- [2]mitre-attackDET0563Open source URL
- [3]mitre-attackDET0563Open 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.