AN0563: Analytic 0563
CLI-based execution of interface and routing discovery commands (e.g., `show ip interface`, `show arp`, `show route`) over Telnet, SSH, or console.
Analyst context for executives and security teams
This analytic is about recognizing command-line discovery activity on network devices, where someone uses Telnet, SSH, or console access to inspect interfaces, ARP tables, and routing information. For leaders, the practical issue is not the commands alone; administrators use them legitimately. The risk is whether the organization can distinguish authorized network troubleshooting from suspicious reconnaissance on routers, switches, or other network devices that support business connectivity.
Executive priority
Prioritize this as a network infrastructure visibility and access-governance question. Security and operations leaders should ask whether network-device CLI activity is logged, attributable to named users or approved admin paths, retained for investigations, and reviewable during incidents or audits. If those logs are absent or unactionable, the organization may have limited ability to validate misuse of privileged network access or reconstruct activity affecting routing and connectivity.
Technical view
SOC, detection engineering, and IR teams should validate whether CLI sessions to network devices over Telnet, SSH, and console produce usable records of executed commands such as interface, ARP, and route discovery. Because no official detection logic is provided, treat this as a coverage-validation analytic: confirm command accounting, session source, authenticated identity, device, timestamp, and command text where available. Tuning should account for legitimate network administration, maintenance windows, approved jump hosts, and change tickets.
Likely telemetry
- Network device command accounting or audit logs
- AAA/TACACS+/RADIUS authentication and authorization records where deployed
- SSH and Telnet session logs to network devices
- Console access logs or terminal server logs where available
- Network device syslog events
Detection direction
- Baseline normal network-administration command usage by user, device, source, and time window before alerting on discovery commands alone.
- Correlate CLI discovery commands with authentication identity, access method, source host, and whether the session aligns to approved operational activity.
- Treat Telnet-based administration as higher-risk evidence than encrypted/managed access where local policy discourages or prohibits Telnet.
- Look for unusual combinations such as new admin source, unexpected account, off-hours session, broad device coverage, or discovery commands outside a related change record.
- Account for false positives from routine troubleshooting, monitoring validation, network changes, and incident response activity.
Mitigation priorities
- Ensure network-device administrative access is attributable through centralized identity and AAA controls where supported.
- Prefer managed, auditable administrative paths and reduce unaudited access methods, especially where Telnet or unmanaged console access remains in use.
- Enable and retain network-device syslog, authentication, and command accounting sufficient for incident reconstruction.
- Restrict administrative access to approved users, management networks, and controlled jump hosts.
- Align detection reviews with change-management processes so legitimate discovery activity can be separated from suspicious activity.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Network Devices and describes CLI-based execution of interface and routing discovery commands over Telnet, SSH, or console. No ATT&CK tactic, relationship context, or official detection logic was supplied, so this take focuses on defensive validation, telemetry readiness, and operational interpretation rather than a specific ATT&CK technique chain.
This assessment is limited to the official STIX fields, external reference, and absence of relationships provided. It does not establish adversary use, impact, attribution, or existing detection coverage. Local device models, logging configuration, identity controls, and administrative workflows are required to determine actual risk and detection quality.
Analytic 0563
CLI-based execution of interface and routing discovery commands (e.g., `show ip interface`, `show arp`, `show route`) over Telnet, 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 | 0dbe2770c8d9… |
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 AN0563Open 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.