T1584.008 Elastic Security · Elastic

Detect Network Devices in Elastic Security

Adversaries may compromise third-party network devices that can be used during targeting. Network devices, such as small office/home office (SOHO) routers, may be compromised where the adversary's ultimate goal is not Initial Access to that environment, but rather to leverage these devices to support additional targeting. Once an adversary has control, compromised network devices can be used to launch additional operations, such as hosting payloads for Phishing campaigns, enabling Content Injection operations, or serving as proxy relay nodes in Operational Relay Box (ORB) networks. Real-world usage includes Volt Typhoon proxying traffic through geographically co-located SOHO routers to evade geo-anomaly detection, APT28 compromising Ubiquiti devices to harvest credentials from phishing pages, ZIRCONIUM/APT31 building large-scale ORB networks from compromised SOHO and IoT devices, and Leviathan using SOHO devices as C2 relay infrastructure. These techniques are particularly difficult to detect because the compromise occurs entirely outside the victim environment — detection must focus on the downstream observable: when compromised devices interact with the victim's perimeter.

MITRE ATT&CK

Tactic
Resource Development
Technique
T1584 Compromise Infrastructure
Sub-technique
T1584.008 Network Devices
Canonical reference
https://attack.mitre.org/techniques/T1584/008/

Elastic Detection Query

Elastic Security (Elastic)
eql
// T1584.008 — Compromised Infrastructure: Network Devices
// Requires Elastic Threat Intelligence module enrichment (logs-ti_*) to populate
// threat.enrichments fields on incoming events via ingest pipeline matching.
// Covers authentication, network flow, and HTTP events from compromised SOHO/ORB IPs.
any where
  event.category in ("authentication", "network", "network_traffic") and
  source.ip != null and
  not cidr(source.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8", "169.254.0.0/16") and
  threat.enrichments.matched.type == "ipv4-addr" and
  (
    threat.enrichments.indicator.description like~ "*SOHO*" or
    threat.enrichments.indicator.description like~ "*ORB*" or
    threat.enrichments.indicator.description like~ "*compromised router*" or
    threat.enrichments.indicator.description like~ "*network device*" or
    threat.enrichments.indicator.description like~ "*operational relay*" or
    threat.enrichments.indicator.description like~ "*relay box*" or
    threat.enrichments.indicator.provider like~ "*VoltTyphoon*" or
    threat.enrichments.indicator.provider like~ "*APT28*" or
    threat.enrichments.indicator.provider like~ "*APT31*" or
    threat.enrichments.indicator.provider like~ "*Leviathan*" or
    threat.enrichments.indicator.provider like~ "*RouterBotnet*" or
    threat.enrichments.indicator.provider like~ "*EdgeDevice*" or
    threat.enrichments.indicator.provider like~ "*CompromisedRouter*"
  )
high severity medium confidence

Detects inbound network connections and authentication events from IPs associated with known compromised SOHO/network device infrastructure using Elastic Threat Intelligence enrichment. Matches events where source.ip has been correlated against TI indicators tagged for ORB relay networks, VoltTyphoon, APT28, APT31, Leviathan, and generic compromised router/edge device infrastructure. Requires the Elastic Threat Intelligence module to be active and enriching events via the logs-ti_* ingest pipeline.

Data Sources

Elastic Threat Intelligence Module (logs-ti_*)Endpoint security telemetry (auditbeat, filebeat with system module)Network traffic logs (Packetbeat, firewall integrations via Elastic Agent)Authentication logs (Windows Event Logs, Linux PAM/auditd via Beats)Firewall/perimeter logs (Cisco ASA, Palo Alto, Fortinet via Elastic integrations)

Required Tables

logs-*auditbeat-*filebeat-*packetbeat-*logs-ti_abusech.*logs-ti_recordedfuture.*logs-ti_misp.*

False Positives & Tuning

  • Legitimate CDN or cloud hosting provider IPs that were previously part of a SOHO botnet but have since been cleaned and reassigned, with stale TI feed entries still marking them as malicious beyond their indicator expiry date
  • VPN exit nodes or residential proxy services operating commercially whose egress IPs overlap with SOHO/ORB compromise indicators because adversaries previously used or co-tenanted the same provider infrastructure
  • ISP dynamic address pools where a formerly compromised SOHO IP has been recycled and assigned to a new legitimate residential or business subscriber before the TI feed has aged out the indicator
  • Security researchers and threat intelligence platform crawlers operating from infrastructure that was once part of, or geographically adjacent to, known compromised SOHO or ORB network ranges
Download portable Sigma rule (.yml)

Other platforms for T1584.008


Testing Methodology

Validate this detection against 4 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 1Simulate SOHO Proxy Authentication via curl Through External Proxy

    Expected signal: Firewall logs record the connection originating from PROXY_IP (the relay device), not the actual test host. Network flow records show only the proxy-to-target leg of the connection. If PROXY_IP were in the threat intelligence feed tagged as SOHO/ORB infrastructure, the KQL ThreatIntelligenceIndicator join and SPL threat_intel_ips lookup would fire. Sysmon Event ID 3 on the test host shows the outbound connection to PROXY_IP:PROXY_PORT.

  2. Test 2Authentication Attempt from Residential ISP IP Address

    Expected signal: Web server access logs record the X-Forwarded-For IP (98.27.145.200) as the source. If authentication maps to Windows Security Event ID 4625 (failed logon) or 4624 (success), the IpAddress field should capture the forwarded residential IP. Azure AD SigninLogs would show the source IP in the IPAddress field. The residential IP hunting query (first hunting query) would flag this IP if it appeared in SigninLogs with a residential ASN classification.

  3. Test 3Scan for Exposed SOHO Management Ports on Local Network Segment

    Expected signal: Sysmon Event ID 3 (Network Connection) captures each connection attempt from the nmap process to each scanned port. Firewall logs on a production system would show the sequential port probe pattern. Network IDS/IPS systems should fire on port scanning signatures. The management port hunting query (second hunting query) would fire if this originated from an external IP targeting perimeter infrastructure.

  4. Test 4Validate Threat Intelligence Pipeline for SOHO/ORB Indicators

    Expected signal: DNS query to 1.1.1.1:53 generates Sysmon Event ID 22 (DNS Query) and Event ID 3 (Network Connection to 1.1.1.1:53). Firewall logs record the outbound UDP/TCP connection to 1.1.1.1:53. If /tmp/ti_test_soho.csv is loaded into the SIEM as a threat intelligence lookup, the connection source IP (1.1.1.1) matches the test TI entry tagged as SOHO/ORB.

Unlock Pro Content

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

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections