Detect Network Device Authentication in Google Chronicle
Adversaries may patch network device operating systems to add a hardcoded backdoor password, bypassing normal authentication for local accounts on routers, switches, and VPN appliances. SYNful Knock implanted a backdoor password in Cisco IOS router images, checking if login credentials match the backdoor password before passing them to normal authentication. SLOWPULSE modified Pulse Secure LDAP and 2FA authentication to accept a designated attacker-supplied password. Detection relies on network configuration integrity checks and unusual authentication behavior.
MITRE ATT&CK
- Technique
- T1556 Modify Authentication Process
- Sub-technique
- T1556.004 Network Device Authentication
- Canonical reference
- https://attack.mitre.org/techniques/T1556/004/
YARA-L Detection Query
rule t1556_004_network_device_auth_backdoor {
meta:
author = "Detection Engineering"
description = "Detects potential hardcoded backdoor authentication on network devices per T1556.004. Flags devices with more than 5 auth failures per hour or suspicious clean-success auth patterns with zero failures, consistent with SYNful Knock (Cisco IOS) and SLOWPULSE (Pulse Secure) implant behavior."
mitre_attack_tactic = "Defense Evasion, Persistence, Credential Access"
mitre_attack_technique = "T1556.004"
severity = "HIGH"
priority = "HIGH"
reference = "https://attack.mitre.org/techniques/T1556/004/"
events:
$e.metadata.event_type = "USER_LOGIN"
(
$e.principal.hostname /(?i)(router|switch|fw|vpn|asa|ios|junos|nexus|palo|fortigate|srx|mx[0-9])/ or
$e.metadata.product_name /(?i)(cisco|juniper|palo alto|fortinet|f5|checkpoint)/ or
$e.metadata.vendor_name /(?i)(cisco|juniper networks|palo alto networks|fortinet)/
)
(
$e.security_result.action = "ALLOW" or
$e.security_result.action = "BLOCK"
)
$host = $e.principal.hostname
$src = $e.principal.ip
match:
$host, $src over 1h
outcome:
$success_count = count_distinct($e.metadata.id) if $e.security_result.action = "ALLOW"
$failure_count = count_distinct($e.metadata.id) if $e.security_result.action = "BLOCK"
$unique_users = count_distinct($e.principal.user.userid)
condition:
$e and (
$failure_count > 5
or ($success_count > 5 and $failure_count = 0)
or ($unique_users > 3 and $success_count > 0 and $failure_count = 0)
)
}Chronicle YARA-L 2.0 rule that matches USER_LOGIN UDM events from network infrastructure devices identified by hostname regex patterns and vendor/product metadata, groups events over a 1-hour sliding window per (hostname, source IP) pair, and fires on three distinct suspicious conditions: high failure volume (>5 failures/hour indicating credential testing), clean-success anomaly (>5 successes with zero failures indicating a backdoor credential that always works), or multi-user clean-success (3+ distinct users authenticating from one source with no failures, consistent with a shared backdoor credential used across sessions).
Data Sources
Required Tables
False Positives & Tuning
- Chronicle UDM normalization may map TACACS+ proxy pass-through authentication records and direct device login events to the same USER_LOGIN type with the AAA proxy's IP as principal.ip, causing legitimate TACACS infrastructure to appear as a high-success source triggering the clean-success condition.
- Network devices that emit repeated authentication events for background system processes, SNMP polling authentication, or BGP/routing-protocol peer session re-establishments may produce dense success-only event streams that match the $success_count > 5 and $failure_count = 0 condition.
- During planned network OS upgrades or bulk configuration pushes via automation pipelines, the management orchestrator may authenticate to dozens of devices per minute from a single IP, and the $unique_users > 3 condition may fire if multiple service accounts are used across the push.
Other platforms for T1556.004
Testing Methodology
Validate this detection against 3 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 1Verify Cisco IOS Image Hash (Integrity Check)
Expected signal: SSH authentication event in network device syslog. Network device syslog entry for privileged exec command execution. If syslog forwarding is configured, Splunk/Sentinel will capture the authentication and command events.
- Test 2Simulate Failed Network Device Authentication (Syslog Testing)
Expected signal: Network device syslog entries: 'Authentication failed for user testuser from <IP>'. If forwarded to SIEM: Splunk index=network_syslog with authentication failure events. Five events in rapid succession should trigger the failure rate detection.
- Test 3Check Network Device Syslog Collection
Expected signal: Test syslog message appearing in SIEM with source IP of the test host. The message mimics a Cisco IOS login success event and should match the network device authentication detection patterns.
References (5)
- https://attack.mitre.org/techniques/T1556/004/
- https://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis/
- https://tools.cisco.com/security/center/resources/integrity_assurance.html
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1556.004/T1556.004.md
- https://www.mandiant.com/resources/blog/mandiant-identifies-new-pulse-connect-secure-vulnerabilities
Unlock Pro Content
Get the full detection package for T1556.004 including response playbook, investigation guide, and atomic red team tests.