AN1559: Analytic 1559
Detection of CLI commands that disable history logging such as 'no logging'. Anomalous lack of new commands in session logs while activity persists is a strong signal.
Analyst context for executives and security teams
This analytic matters because network device command history is often the evidence trail SOC and incident response teams need to understand what changed during an incident. Commands that disable history logging, such as “no logging,” or a suspicious gap in session logs while activity continues, can undermine accountability and delay recovery decisions.
Executive priority
Treat this as a control-assurance and resilience issue for network infrastructure. Leaders should ask whether network device administrative activity is centrally logged, protected from local tampering, and reviewed for gaps. The business risk is not just the command itself; it is losing reliable evidence during a network change, outage, or security investigation.
Technical view
For Network Devices, validate whether CLI session activity and configuration-related commands are captured in a way that can reveal attempts to disable logging and periods where expected command records stop while the session or device activity continues. Because no ATT&CK tactic or relationship context is supplied, this should be handled as a focused detection-quality analytic around logging integrity rather than mapped to a broader intrusion chain.
Likely telemetry
- Network device CLI command/session logs
- Centralized syslog or equivalent network device logging records
- Authentication and administrative session records for network devices
- Configuration change logs or audit records
- Evidence of continued device or session activity during gaps in command history
Detection direction
- Alert or review when CLI commands associated with disabling history or logging are observed, including the supplied example “no logging.”
- Correlate command-history gaps with active administrative sessions or other device activity to distinguish true logging suppression from normal inactivity.
- Tune against approved maintenance activity and known administrative procedures to reduce false positives.
- Validate that logs are forwarded off-device quickly enough that local logging changes do not erase the only evidence source.
- Check coverage specifically on Network Devices, since this analytic is platform-scoped there and no other platforms are supplied.
Mitigation priorities
- Prioritize centralized, tamper-resistant collection of network device administrative logs.
- Restrict who can change logging or history settings on network devices using role-based administration and change-control processes.
- Require review of logging configuration changes as part of network device hardening and audit evidence.
- Test incident response playbooks for scenarios where local device history is incomplete or intentionally disabled.
- Use periodic validation to confirm that expected CLI/session telemetry is still arriving from in-scope network devices.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique, and includes a concise description but no separate official detection text or relationship context. The practical value is in validating logging integrity and command-history continuity for network device administration.
No tactics, related techniques, groups, software, campaigns, or mitigations were supplied. This take does not assert active exploitation, attribution, prevalence, impact, or guaranteed detection coverage. Local device models, logging configuration, administrative workflows, and SIEM ingestion quality will determine how actionable this analytic is.
Analytic 1559
Detection of CLI commands that disable history logging such as 'no logging'. Anomalous lack of new commands in session logs while activity persists is a strong signal.
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 | d420d03ddd4c… |
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 AN1559Open 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.