AN1457: Analytic 1457
Execution of `show version`, `show hardware`, or `show system` commands through CLI via SSH or console.
Analyst context for executives and security teams
AN1457 focuses on administrative CLI commands such as `show version`, `show hardware`, and `show system` run on network devices through SSH or console access. For leaders, the value is not that these commands are inherently malicious; it is that they can reveal device model, software version, and hardware details that matter for vulnerability prioritization, network resilience, and incident scoping. Organizations should know whether they can prove who ran these commands, on which devices, and whether the activity aligned with approved administration.
Executive priority
Prioritize this as a control-evidence question for critical network infrastructure. If command activity on routers, switches, firewalls, or similar network devices is not logged and attributable, incident responders may struggle to determine whether device inventory or version information was accessed during an investigation. This also affects audit readiness, vulnerability management, and business continuity because device version and hardware visibility often drive patching, lifecycle, and exposure decisions.
Technical view
The supplied analytic describes execution of `show version`, `show hardware`, or `show system` through CLI via SSH or console on Network Devices. Because ATT&CK provides no official detection logic or related techniques for this object, SOC and detection teams should validate whether network-device command execution is captured at all, especially for both remote SSH administration and physical or out-of-band console sessions. Detection content should be environment-aware: these commands are common for legitimate administration, troubleshooting, inventory checks, and change validation, so value comes from attribution, timing, device criticality, and deviation from normal admin workflows rather than command text alone.
Likely telemetry
- Network device command accounting logs, where enabled
- AAA/TACACS+/RADIUS accounting records tied to administrator identity
- SSH login and session records for network-device management access
- Console or out-of-band management access logs, where available
- Network device syslog events related to CLI access and command execution
Detection direction
- Confirm whether command-level logging exists for SSH and console access, not only login/logout events.
- Alerting on these commands alone may be noisy; tune using user identity, device criticality, time of day, source location, and approved change windows.
- Prioritize visibility for high-impact network devices because version and hardware discovery can affect vulnerability triage and incident scope.
- Look for blind spots where local accounts, break-glass access, console access, or out-of-band management bypass centralized accounting.
- Correlate CLI activity with configuration-change records and ticketing data to distinguish routine administration from unexpected discovery activity.
Mitigation priorities
- Enable centralized AAA and command accounting for network-device administration where supported.
- Centralize and retain network-device CLI, SSH, console, and syslog records for investigation and compliance evidence.
- Restrict management access to approved administrative paths and trusted networks.
- Use least-privilege administrative roles and named accounts to improve attribution.
- Align command monitoring with change-management processes so routine maintenance is explainable.
Analyst notes and limits
This object is a detection analytic, not a technique, and has no supplied tactic, relationship context, aliases, or official detection logic. The practical defensive focus is validating administrative command visibility on network devices and ensuring SOC/IR teams can separate expected operational use from unusual access patterns.
The source only states that `show version`, `show hardware`, or `show system` are executed through CLI via SSH or console on Network Devices. It does not provide detection pseudocode, data source mappings, adversary use, impact, or platform detail beyond Network Devices. Local device types, logging configuration, AAA architecture, and administrative workflows are required to turn this into reliable detection content.
Analytic 1457
Execution of `show version`, `show hardware`, or `show system` commands through CLI via SSH or console.
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 | cbe826d5dac0… |
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 AN1457Open 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.