AN0879: Analytic 0879
Detects execution of capture commands via CLI (`monitor capture`, `debug packet`, etc.) or unauthorized CLI access followed by logging configuration changes on Cisco/Juniper/Arista gear.
Analyst context for executives and security teams
This analytic matters because packet-capture or debug commands on network infrastructure can expose sensitive traffic and may indicate misuse of privileged device access. For leaders, the practical question is whether the organization can see and explain administrative CLI activity on Cisco, Juniper, and Arista devices before it becomes an outage, data exposure, or incident-response blind spot.
Executive priority
Prioritize this as a network-infrastructure monitoring and privileged-access assurance issue. It supports resilience and audit readiness by validating that high-risk administrative actions on routers, switches, and similar network devices are logged, reviewed, and tied to authorized change activity. The main business risk is not the command string alone, but unmanaged or unexplained CLI access to critical network devices.
Technical view
SOC and detection teams should validate whether device CLI logs, AAA authentication records, command accounting, and configuration-change logs are collected for supported network devices. The analytic is scoped to detecting capture/debug-style CLI execution such as `monitor capture` or `debug packet`, and unauthorized CLI access followed by logging configuration changes on Cisco, Juniper, or Arista gear. Because no official detection logic is provided, teams should implement environment-specific matching against network-device command logs and correlate with approved admin sessions and change windows.
Likely telemetry
- Network device CLI command accounting logs
- AAA authentication and authorization records for device administration
- Configuration-change logs from Cisco, Juniper, and Arista devices
- Session metadata for administrative access to network devices
- Change-management records for approved packet capture, debugging, or logging changes
Detection direction
- Confirm that command accounting captures full CLI commands, not only login/logout events.
- Create detections for packet-capture and packet-debug command patterns relevant to the organization’s Cisco, Juniper, and Arista platforms.
- Correlate capture/debug command execution with user identity, source address, device role, and approved change tickets.
- Review cases where CLI access is followed by logging configuration changes, especially outside approved maintenance windows.
- Tune for legitimate network troubleshooting to reduce false positives while still requiring evidence of authorization.
Mitigation priorities
- Enforce strong administrative access control for network devices, including centralized authentication and role-based authorization where available.
- Require command accounting and retention for privileged network-device activity.
- Restrict packet-capture and debug capabilities to authorized administrators and approved operational workflows.
- Use change-management evidence to distinguish expected troubleshooting from suspicious or unauthorized activity.
- Regularly test whether SOC and incident-response teams can retrieve device command history during investigations.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique, and no tactic or relationship context is provided. The strongest use of this object is as a validation checklist for network-device administrative telemetry and detection engineering around high-risk CLI activity.
Official detection logic is not provided, and the object does not include relationships, adversary context, or claims of exploitation. Local device models, logging configuration, AAA design, and change-management practices are required to determine practical coverage and alert quality.
Analytic 0879
Detects execution of capture commands via CLI (`monitor capture`, `debug packet`, etc.) or unauthorized CLI access followed by logging configuration changes on Cisco/Juniper/Arista gear.
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 | 128952e7923a… |
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 AN0879Open 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.