Detect Disable Crypto Hardware in CrowdStrike LogScale
Adversaries disable a network device's dedicated hardware encryption accelerator, forcing the device to fall back to slower, software-based cryptographic operations. Hardware Security Modules (HSMs) and onboard crypto ASICs in routers, switches, and firewalls are purpose-built to perform encryption at line rate and resist tampering. Disabling them degrades cryptographic performance and may enable exploitation of weaker software cipher implementations. This technique is typically executed after gaining privileged access to network device management interfaces (via T1078.004, T1021.004, or T1601) and is most dangerous when combined with T1600.001 (Reduce Key Space) to both disable hardware protections and downgrade cipher strength, enabling adversaries to decrypt intercepted VPN or IPSec traffic.
MITRE ATT&CK
- Tactic
- Defense Evasion
- Technique
- T1600 Weaken Encryption
- Sub-technique
- T1600.002 Disable Crypto Hardware
- Canonical reference
- https://attack.mitre.org/techniques/T1600/002/
LogScale Detection Query
#event_simpleName=SyslogMessage
| ImageFileName = /no crypto|encryption des|esp-des|modulus 512|modulus 768|null-encryption|ip ssh version 1/i OR Message = /no crypto|encryption des|esp-des|modulus 512|modulus 768|null-encryption|ip ssh version 1/i
| case {
Message = /null-encryption|no crypto engine/i | RiskLevel := "Critical";
Message = /encryption des|esp-des|rc4/i | RiskLevel := "High";
Message = /modulus 512|modulus 768|group 1 /i | RiskLevel := "High";
* | RiskLevel := "Medium"
}
| table([@timestamp, ComputerName, Message, RiskLevel])CrowdStrike Falcon LogScale CQL query for T1600.002 detection. Detects attempts to disable hardware cryptographic acceleration on network devices by monitoring sys
Data Sources
Required Tables
False Positives & Tuning
- Scheduled network maintenance windows where administrators update crypto engine firmware or replace hardware security modules
- Hardware accelerator failures triggering automatic software fallback — the CRYPTO_ENGINE-4-ACCEL_FAIL syslog message may fire during genuine hardware faults
- Lab, staging, or development network devices where hardware crypto acceleration is intentionally disabled to reduce cost or simplify testing
- Vendor-initiated diagnostic procedures where TAC engineers disable hardware acceleration to isolate performance issues
- Automated configuration management tools (Ansible, NAPALM, NSO) pushing approved baseline configurations that include software crypto fallback settings
Other platforms for T1600.002
Testing Methodology
Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Cisco IOS — Disable Hardware Crypto Accelerator via CLI
Expected signal: Cisco IOS syslog: PARSER-5-CFGLOG_LOGGEDCMD message containing 'no crypto engine accelerator' with the username and timestamp. SYS-5-CONFIG_I message indicating configuration was modified from the terminal. CRYPTO_ENGINE syslog facility messages indicating accelerator state change. TACACS+ command accounting record (if configured) with the exact command, user, and source IP.
- Test 2Cisco IOS — Configure Software-Only Crypto Engine
Expected signal: Cisco IOS syslog: PARSER-5-CFGLOG_LOGGEDCMD with 'crypto engine software' command text. SYS-5-CONFIG_I indicating terminal configuration change. Running config inspection shows 'crypto engine software' statement present. TACACS+ accounting records the command with username attribution.
- Test 3Cisco IOS — Simulate Hardware Accelerator Fault Leading to Software Fallback
Expected signal: Cisco IOS debug output forwarded as syslog: CRYPTO_ENGINE debug messages including accelerator state and statistics. The `show crypto engine accelerator statistics` output shows whether hardware or software is performing crypto operations — if software counters are incrementing while hardware counters remain static, hardware is disabled. Look for CRYPTO_ENGINE-4-ACCEL_FAIL or CRYPTO_ENGINE-6-KEY_DELETED messages in syslog if hardware fault is present.
- Test 4Python — Audit Script to Detect Software Crypto Fallback via SNMP
Expected signal: SNMP query generates UDP traffic to port 161 on the target device. Network flow logs (NetFlow, IPFIX) record the SNMP polling connection. If the device has SNMP access logging enabled, a log entry records the SNMP GET request including the source IP and OID queried. cipSecGlobalHwAuthFails counter incrementing indicates the hardware crypto engine is failing to authenticate packets and falling back to software.
- Test 5Juniper JunOS — Disable IPSec Hardware Offload
Expected signal: Juniper JUNOS syslog: UI_COMMIT_COMPLETED message indicating configuration was committed. UI_CMDLINE_READ_LINE messages logging individual configuration commands if command logging is enabled. Juniper RT_FLOW messages may show changed processing statistics post-commit. TACACS+ accounting records the configuration session if configured. The `show security ipsec statistics` output will show changes in hardware vs software packet processing counters.
References (9)
- https://attack.mitre.org/techniques/T1600/002/
- https://community.cisco.com/t5/security-blogs/attackers-continue-to-target-legacy-devices/ba-p/4169954
- https://attack.mitre.org/techniques/T1600/001/
- https://attack.mitre.org/techniques/T1601/
- https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/s1/sec-s1-cr-book/sec-cr-c4.html
- https://www.cisco.com/c/en/us/support/docs/security/secure-shell-ssh/4145-ssh.html
- https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/xe-16/sec-ike2-vpn-xe-16-book/sec-cfg-ikev2-flex.html
- https://www.cisecurity.org/benchmark/cisco
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1600.002/T1600.002.md
Unlock Pro Content
Get the full detection package for T1600.002 including response playbook, investigation guide, and atomic red team tests.