AN1360: Analytic 1360
Defenders may observe attempts to disable dedicated crypto hardware on network devices, often visible through anomalous CLI commands, unexpected firmware or configuration updates, and degraded encryption performance. Suspicious indicators include commands that alter hardware acceleration settings (e.g., disabling AES-NI or crypto engines), modification of system image files, or logs showing fallback from hardware to software encryption. Network traffic analysis may also reveal a sudden downgrade in throughput or cipher negotiation behavior consistent with the absence of hardware acceleration.
Analyst context for executives and security teams
This analytic highlights a defensive concern on network devices: attempts to disable or bypass dedicated cryptographic hardware. For leaders, the practical issue is not just a configuration change; it can reduce encryption performance, alter cipher behavior, and weaken confidence that critical network infrastructure is operating as designed. Because the ATT&CK object provides no tactic or relationship context, this should be treated as a coverage-validation item for network device hardening, monitoring, and incident response rather than evidence of a specific campaign.
Executive priority
Prioritize this where network devices support business-critical encrypted traffic, remote access, site-to-site connectivity, or regulated data flows. Leaders should ask whether teams can prove that crypto acceleration settings, firmware or system image integrity, and encryption performance baselines are monitored. This is relevant to resilience, audit evidence, and incident decision-making because degraded or altered encryption behavior may affect availability, performance, and trust in infrastructure controls.
Technical view
For SOC, detection engineering, and IR teams, validate visibility on network devices for anomalous CLI commands, configuration or firmware updates, system image modification, logs indicating fallback from hardware to software encryption, and unexpected changes in throughput or cipher negotiation. Since the official object does not provide a detection query or tactic mapping, build detections around locally approved administrative baselines and known-good device behavior rather than assuming a universal signature.
Likely telemetry
- Network device CLI command history and administrator session logs
- Configuration change logs for crypto acceleration or hardware engine settings
- Firmware, system image, and file integrity change records
- Device system logs showing crypto engine status or fallback to software encryption
- Network performance metrics, including sudden throughput degradation on encrypted paths
Detection direction
- Baseline approved crypto hardware settings and alert on changes outside authorized maintenance windows.
- Correlate suspicious CLI activity with firmware, system image, or configuration changes on the same device.
- Tune for legitimate administrative activity to reduce false positives, especially during upgrades, troubleshooting, or hardware replacement.
- Look for performance or cipher negotiation changes as supporting evidence, not as standalone proof, because congestion, routing changes, or normal maintenance can also affect throughput.
- Validate that network device logs are centrally collected; this analytic is weak if CLI history, configuration diffs, and device health logs are not retained.
Mitigation priorities
- Maintain approved configuration baselines for network device crypto hardware and acceleration settings.
- Restrict and monitor privileged administrative access to network devices.
- Use formal change control for firmware, system image, and crypto-related configuration updates.
- Collect and retain network device logs sufficient for incident response and compliance evidence.
- Monitor encrypted-path performance and device crypto engine health for unexplained degradation.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Network Devices and describes observable signs of attempts to disable dedicated crypto hardware. It does not include a formal detection query, tactic mapping, related technique, adversary attribution, or relationship context. The strongest use is as a prompt to validate telemetry, baselines, and change-control evidence for network infrastructure.
This take is limited to the official STIX fields and external reference provided. It does not establish active exploitation, business impact, attribution, or guaranteed detectability. Local device models, logging capabilities, encryption architectures, and change-management practices are required to determine actual risk and coverage.
Analytic 1360
Defenders may observe attempts to disable dedicated crypto hardware on network devices, often visible through anomalous CLI commands, unexpected firmware or configuration updates, and degraded encryption performance. Suspicious indicators include commands that alter hardware acceleration settings (e.g., disabling AES-NI or crypto engines), modification of system image files, or logs showing fallback from hardware to software encryption. Network traffic analysis may also reveal a sudden downgrade in throughput or cipher negotiation behavior consistent with the absence of hardware acceleration.
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 | 4aff87397d2a… |
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 AN1360Open 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.