T1600.002 Splunk · SPL

Detect Disable Crypto Hardware in Splunk

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/

SPL Detection Query

Splunk (SPL)
spl
index=network_devices OR index=syslog OR index=firewall sourcetype=syslog
| eval msg=lower(_raw)
| eval DisableHWCrypto=if(match(msg, "(no crypto engine accelerator|no hardware-based crypto|no crypto-engine|no crypto engine onboard|hardware crypto disabled)"), 1, 0)
| eval ForceSoftwareCrypto=if(match(msg, "(crypto engine software|software crypto only|crypto engine integrated|software-based encryption)"), 1, 0)
| eval AcceleratorFault=if(match(msg, "(accelerator disabled|vpn acceleration disabled|crypto_engine-4-accel_fail|crypto engine failure)"), 1, 0)
| eval ConfigLogged=if(match(msg, "(cfglog_loggedcmd|sys-5-config_i|parser-5-cfglog|crypto_engine-6-key_deleted)"), 1, 0)
| eval CryptoEngineKeyword=if(match(msg, "(crypto engine|crypto-engine|hardware accelerat|onboard accelerat)"), 1, 0)
| eval SuspicionScore=DisableHWCrypto + ForceSoftwareCrypto + AcceleratorFault
| where SuspicionScore > 0 OR (ConfigLogged=1 AND CryptoEngineKeyword=1)
| eval RiskLevel=case(
    SuspicionScore >= 2, "HIGH",
    SuspicionScore == 1 AND ConfigLogged=1, "HIGH",
    SuspicionScore == 1, "MEDIUM",
    ConfigLogged=1 AND CryptoEngineKeyword=1, "LOW",
    true(), "INFO"
  )
| table _time, host, source, RiskLevel, DisableHWCrypto, ForceSoftwareCrypto, AcceleratorFault, ConfigLogged, SuspicionScore, _raw
| sort - _time
critical severity medium confidence

Detects hardware crypto acceleration disable activity on network devices using syslog data. Evaluates raw syslog messages against four indicator categories — explicit disable commands, forced software crypto mode, accelerator fault messages, and configuration change log entries — then computes a suspicion score and risk level. The risk level helps analysts triage: HIGH events with SuspicionScore >= 2 represent explicit adversary action; MEDIUM events with score 1 may be hardware faults requiring validation; LOW events are config log entries touching crypto engine settings that need review against change records.

Data Sources

Network Device: Network Device ConfigurationNetwork Device: Network Device CommandCisco IOS SyslogJuniper JUNOS SyslogPalo Alto PAN-OS Syslog

Required Sourcetypes

syslog

False Positives & Tuning

  • Scheduled network maintenance windows where administrators update crypto engine firmware or swap hardware security modules
  • Hardware accelerator failures triggering automatic software fallback — CRYPTO_ENGINE-4-ACCEL_FAIL fires on genuine hardware faults and should be correlated with change tickets
  • Lab, staging, and development devices with hardware acceleration intentionally disabled
  • Vendor TAC diagnostic sessions that disable hardware acceleration to isolate performance problems
  • Configuration management automation (Ansible, NSO) applying approved baseline templates containing software crypto settings
Download portable Sigma rule (.yml)

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Unlock Pro Content

Get the full detection package for T1600.002 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections