T1600: Weaken Encryption
Adversaries may compromise a network device’s encryption capability in order to bypass encryption that would otherwise protect data communications.[1]
Encryption can be used to protect transmitted network traffic to maintain its confidentiality (protect against unauthorized disclosure) and integrity (protect against unauthorized changes). Encryption ciphers are used to convert a plaintext message to ciphertext and can be computationally intensive to decipher without the associated decryption key. Typically, longer keys increase the cost of cryptanalysis, or decryption without the key.
Adversaries can compromise and manipulate devices that perform encryption of network traffic. For example, through behaviors such as Modify System Image, Reduce Key Space, and Disable Crypto Hardware, an adversary can negatively effect and/or eliminate a device’s ability to securely encrypt network traffic. This poses a greater risk of unauthorized disclosure and may help facilitate data manipulation, Credential Access, or Collection efforts.[2]
Analyst context for executives and security teams
Weaken Encryption is a network-device defense-impairment technique where an adversary compromises the device capabilities that should protect traffic confidentiality and integrity. For leaders, the issue is not just “bad crypto”; it is whether routers, switches, firewalls, or similar devices can still be trusted to protect sensitive communications after compromise.
Executive priority
Prioritize this where network devices carry regulated, credential-bearing, operationally sensitive, or business-critical traffic. The business decision value is to confirm whether encryption assurance depends only on policy statements, or whether teams have evidence that device images, cipher strength, key space, and crypto hardware status remain intact. This is material for resilience, incident scoping, compliance evidence, and risk acceptance because weakened encryption can enable unauthorized disclosure and support credential access, collection, or data manipulation.
Technical view
ATT&CK lists this as an enterprise technique for Network Devices under defense-impairment. SOC, detection engineering, and IR teams should validate controls around the parent behavior and its supplied sub-techniques: Reduce Key Space and Disable Crypto Hardware. Because ATT&CK provides no official detection text for T1600, teams should anchor validation on available device evidence, configuration/state comparison, image integrity checks, and any related detection strategy content from DET0339 if available internally.
Likely telemetry
- Network device configuration history and change records for encryption settings, cipher strength, and key-size-related parameters
- Network device system image, firmware, or operating image integrity evidence
- Device logs or operational status showing crypto hardware availability, failure, disablement, or fallback behavior
- Encrypted session negotiation metadata where available, such as observed cipher or key strength indicators
- Administrative access logs and configuration command audit trails on routers, switches, firewalls, or other network devices
Detection direction
- Validate whether monitoring can detect unexpected weakening of encryption settings rather than only device availability or interface status.
- Compare current network-device encryption configuration and operational state against a known-good baseline, including key strength and crypto hardware status where exposed.
- Tune detections to distinguish approved maintenance, software upgrades, hardware failures, and policy-driven crypto changes from unexplained downgrades or disablement.
- Use the relationship context to include sub-technique coverage for Reduce Key Space and Disable Crypto Hardware; do not assume parent-technique coverage if those cases are not explicitly tested.
- Account for a major blind spot: ATT&CK does not provide official detection logic for this technique, so local device models, logging depth, and configuration-management evidence will determine practical coverage.
Mitigation priorities
- Maintain authoritative baselines for network-device images, encryption settings, and supported cryptographic capabilities.
- Require controlled change management and review for encryption-related configuration changes on network devices.
- Prioritize integrity validation of device software/images and verification that dedicated crypto hardware remains enabled and functioning where present.
- Include network-device encryption posture in incident response triage when device compromise is suspected, especially before relying on affected devices for secure communications.
- Retire or risk-manage legacy network devices when they cannot provide sufficient evidence of trusted encryption capability or configuration integrity.
Analyst notes and limits
This take is based on ATT&CK T1600, its official description, Cisco external references, and supplied relationships to DET0339, T1600.001 Reduce Key Space, and T1600.002 Disable Crypto Hardware. The supplied object supports Network Devices and defense-impairment framing only.
ATT&CK provides no official detection text for T1600 in the supplied fields, and the DET0339 relationship is named but not described. Local platform types, device telemetry, crypto configuration standards, and image-integrity processes are required to determine actual exposure and coverage.
Weaken Encryption
Adversaries may compromise a network device’s encryption capability in order to bypass encryption that would otherwise protect data communications.[1]
Encryption can be used to protect transmitted network traffic to maintain its confidentiality (protect against unauthorized disclosure) and integrity (protect against unauthorized changes). Encryption ciphers are used to convert a plaintext message to ciphertext and can be computationally intensive to decipher without the associated decryption key. Typically, longer keys increase the cost of cryptanalysis, or decryption without the key.
Adversaries can compromise and manipulate devices that perform encryption of network traffic. For example, through behaviors such as Modify System Image, Reduce Key Space, and Disable Crypto Hardware, an adversary can negatively effect and/or eliminate a device’s ability to securely encrypt network traffic. This poses a greater risk of unauthorized disclosure and may help facilitate data manipulation, Credential Access, or Collection efforts.[2]
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1600.001 | Reduce Key Space Sub-technique | Reduce Key Space subtechnique of this object. |
| Enterprise | T1600.002 | Disable Crypto Hardware Sub-technique | Disable Crypto Hardware subtechnique of this object. |
All related ATT&CK context
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 | 2.0 | Current bundle | 549d130fc0f5… |
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]
Cisco Synful Knock Evolution
Graham Holmes. (2015, October 8). Evolution of attacks on Cisco IOS devices. Retrieved October 19, 2020.
Open source URL -
[2]
Cisco Blog Legacy Device Attacks
Omar Santos. (2020, October 19). Attackers Continue to Target Legacy Devices. Retrieved October 20, 2020.
Open source URL -
[3]
mitre-attack T1600Open 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.