Detect Managed Edge Device Hijacked Into Adversary Operational Relay Box (ORB) Network in Google Chronicle
T1584.008 describes adversaries compromising third-party network devices — SOHO routers, branch-office firewalls, and VPN appliances — not to gain access to that device's own network, but to fold it into an Operational Relay Box (ORB) network used to proxy traffic for later operations against unrelated targets. Volt Typhoon's KV-Botnet, APT28's Moobot-based Ubiquiti EdgeRouter network (dismantled by the FBI's Operation Dying Ember), and Flax Typhoon's Raptor Train all followed the same pattern: identify an internet-facing edge device with weak or default management credentials or an unpatched CVE, take administrative control, and quietly repurpose it as a relay so that later malicious traffic appears to originate from an unremarkable residential or small-business IP rather than adversary-owned infrastructure. The existing T1584.008 base detection in this corpus is threat-intelligence-driven — it flags inbound connections FROM IPs a feed has already attributed to a known ORB network, which is necessarily reactive and blind to newly hijacked devices that have not yet been attributed. This detection instead targets organizations that own and administer their own fleet of edge devices (branch routers, site-to-site VPN concentrators, perimeter firewalls) with syslog export to a SIEM, and looks for the behavioral fingerprint of a device being actively hijacked: an administrative authentication to the device's management plane, followed within a short window by a configuration change consistent with enabling relay capability (a new port-forward or NAT rule, a newly created local administrator account, or an unscheduled firmware change), followed by that same device beginning to carry a high fan-out of external-to-external sessions — traffic where neither the source nor the destination is the organization's own address space, meaning the device itself has become the relay hop rather than a traffic endpoint. Because this correlates management-plane change activity with a genuine change in traffic shape on the same device, it catches the moment of hijack itself rather than waiting for the device's IP to appear on someone else's threat feed, and it complements rather than replaces the existing TI-driven T1584.008 rule.
MITRE ATT&CK
- Tactic
- Resource Development
YARA-L Detection Query
rule edge_device_orb_relay_fanout {
meta:
author = "Detection Engineering"
description = "Detects an edge network device carrying a high fan-out of external-to-external sessions, consistent with the device having been hijacked into an adversary ORB relay network."
mitre_attack_tactic = "Resource Development"
mitre_attack_technique = "T1584.008"
severity = "HIGH"
priority = "HIGH"
events:
$e.metadata.event_type = "NETWORK_CONNECTION"
$e.security_result.action = "ALLOW"
not net.ip_in_range_cidr($e.principal.ip, "10.0.0.0/8")
not net.ip_in_range_cidr($e.principal.ip, "172.16.0.0/12")
not net.ip_in_range_cidr($e.principal.ip, "192.168.0.0/16")
not net.ip_in_range_cidr($e.target.ip, "10.0.0.0/8")
not net.ip_in_range_cidr($e.target.ip, "172.16.0.0/12")
not net.ip_in_range_cidr($e.target.ip, "192.168.0.0/16")
$device = $e.observer.hostname
match:
$device over 1h
outcome:
$session_count = count($e.metadata.id)
$distinct_peers = count_distinct($e.target.ip)
condition:
$e and $distinct_peers >= 15
}Chronicle YARA-L 2.0 rule matching NETWORK_CONNECTION UDM events for allowed sessions where both principal.ip and target.ip are non-RFC1918, aggregated per observer.hostname (the edge device) over a one-hour window using net.ip_in_range_cidr for genuine CIDR evaluation. This is the relay-fanout arm only; pair with a companion YARA-L rule over USER_LOGIN and SETTING_MODIFICATION UDM event types, matched over the same $device within a 30-minute window, to reproduce the full three-signal correlation used in the KQL and SPL rules.
Data Sources
Required Tables
False Positives & Tuning
- Site-to-site VPN and SD-WAN devices whose normal function resembles external-to-external relay
- Legitimate administration performed through a properly ticketed change window
- Cloud-hosted network virtual appliances designed to terminate and forward many external client sessions
Other platforms for THREAT-Infra-EdgeDeviceORBRelayHijack
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 1Simulate Admin-Login-Plus-Config-Change Syslog Sequence (Linux, CEF Emitter)
Expected signal: The syslog forwarder/agent (rsyslog, syslog-ng, or the SIEM's own collector) picks up both CEF lines from the local syslog daemon and forwards them to the SIEM's edge-device log source, where they should populate as two CommonSecurityLog rows for DeviceName LAB-EDGE-01 with Activity fields containing 'Authentication Success' and 'Configuration Changed' respectively, 5 seconds apart.
- Test 2Generate External-to-External Relay Fan-Out via SSH Dynamic Port Forward (Linux)
Expected signal: The lab jump host's own firewall/session log should show at least six distinct outbound sessions to the listed public IPs, all originating from the jump host itself rather than the original test host — this is the external-to-external relay signature from the jump host's perspective. If the jump host is itself onboarded as a monitored edge device, its CommonSecurityLog entries should show DeviceAction allow with SourceIP and DestinationIP both public.
- Test 3Simulate Full Three-Signal Hijack Sequence End-to-End (Linux)
Expected signal: CommonSecurityLog (or equivalent) shows an Authentication-Success entry and a Configuration-Changed entry for LAB-EDGE-02 ten seconds apart, plus at least 16 distinct external-to-external session pairs originating from the jump host, all within the same lookback window.
References (7)
- https://attack.mitre.org/techniques/T1584/008/
- https://attack.mitre.org/tactics/TA0042/
- https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a
- https://www.justice.gov/opa/pr/justice-department-conducts-court-authorized-disruption-botnet-controlled-russian
- https://www.microsoft.com/en-us/security/blog/2023/05/24/volt-typhoon-targets-us-critical-infrastructure-with-living-off-the-land-techniques/
- https://blog.lumen.com/routers-roasting-on-an-open-firewall-the-KV-botnet-investigation/
- https://github.com/redcanaryco/atomic-red-team/tree/master/atomics/T1584.008
Response Playbook
Triage
- Confirm the admin login is not attributable to a known, ticketed maintenance window — check the change-management system for an open or recently closed ticket referencing this device before treating it as suspicious
- Pull the admin login's source IP and compare it against the organization's known management-jump-host or MSP-VPN egress ranges; a management login from an unrecognized IP, foreign geography, or residential ASN is a strong indicator the credentials themselves were compromised
- Review the exact configuration change: a new port-forward or NAT rule pointing at an internal management IP, a newly created local admin account with a generic or default-looking username, or a firmware push outside the normal patch cadence are each individually higher-risk than a routine ACL tweak
- Inspect the external-to-external session pairs flagged in the relay-fanout arm — check whether the destination IPs cluster around known scanning infrastructure, bulletproof hosting, or residential proxy marketplaces, versus a benign explanation like a legitimate site-to-site VPN partner network
- Check the device's current running configuration against its last known-good backup (if configuration backups are retained) to identify the full scope of unauthorized changes, not just the one that logged the keyword match
- Determine whether the device also terminates a VPN tunnel, hosts a management API, or is otherwise reachable from the internet on a port beyond the flagged one — adversaries who hijack one device for relay often simultaneously widen its own attack surface for future re-entry
- Cross-reference the device model and firmware version against recent CVE disclosures and CISA/FBI/NSA joint advisories for that vendor, since the initial access into the device itself typically exploits a known, patchable vulnerability or a still-default credential
Containment
- Isolate the device from the internet-facing interface immediately if relay traffic is confirmed malicious — apply an outbound deny rule at the upstream ISP or carrier edge if the device's own management plane cannot be trusted to enforce its own ACLs
- Force a credential reset for every local and remote-management account on the device, and rotate any shared secrets (SNMP community strings, RADIUS/TACACS+ shared keys, site-to-site VPN pre-shared keys) that could have been read or altered during the compromise window
- Revert the configuration to the last verified known-good backup rather than attempting to manually remove only the flagged change, since an adversary who has had administrative access may have made other, still-undetected modifications
- If the device cannot be quickly remediated in place, replace it with a factory-reset unit or a spare, re-provisioned entirely from a trusted configuration template rather than trusting an in-place restoration of a device that has had unauthorized root/admin access
- Notify any site-to-site VPN or MSP partners whose traffic transits this device, since a hijacked relay node may have exposed their traffic to interception or been used to pivot toward their environment as well
Evidence Collection
- Full CommonSecurityLog / syslog history for the device across the entire retention window, not only the alerting window, since the initial compromise (exploitation or credential theft) typically precedes the observed admin-login-plus-config-change event by hours to weeks
- A complete export of the device's running and startup configuration at time of detection, diffed against the last known-good backup to scope every unauthorized change, not only the one that triggered the alert
- NetFlow/IPFIX or firewall session records for the full external-to-external relay window, to build a complete list of the peer IPs the device relayed for and support downstream victim notification if any of those destinations belong to other organizations
- Any available packet capture at the WAN interface during a confirmed-active relay window, since payload content (even if encrypted) can reveal protocol fingerprints distinguishing legitimate VPN traffic from adversary C2 or scanning traffic being proxied
- Vendor support-bundle or tech-support-file export from the device itself (where supported), which typically includes process lists, active connection tables, and crash/error logs beyond what is forwarded to the SIEM
Escalation Criteria
- !The admin login source IP is confirmed to be outside the organization's or MSP's known management ranges and cannot be attributed to any authorized user or ticketed change
- !The relayed external-to-external peer IPs include known scanning, C2, or ORB-network infrastructure per threat intelligence correlation with the existing T1584.008 base rule
- !The same admin-login-plus-config-change-plus-relay-fanout pattern appears on more than one edge device in the fleet within the same time window, indicating a scripted, at-scale hijack campaign rather than a single opportunistic compromise
- !The device sits in a sensitive path — a branch office serving a regulated business unit, a partner-facing extranet gateway, or a device with a site-to-site tunnel into a higher-trust environment
- !The device model and firmware match a CVE under active exploitation per a current CISA KEV entry or vendor security advisory, indicating this may be part of a broader vendor-wide exploitation wave rather than an isolated incident
Investigation Guide
Related Techniques
Forensic Artifacts
- >
CommonSecurityLog / CEF-forwarded syslog entries showing the admin-login, config-change, and allowed-traffic records that this detection correlates — the primary artifact set this rule depends on - >
The device's running and startup configuration files, and any retained configuration backups, for config-diffing to scope the full extent of unauthorized changes - >
NetFlow/IPFIX or firewall session logs covering the relay window, establishing the complete set of external peer IPs the device relayed traffic for - >
Vendor tech-support-file or support-bundle exports (where the device supports generating one), which often retain process and connection-table data beyond what reaches the SIEM - >
WHOIS/ASN and Shodan/Censys history for both the admin-login source IP and the relayed external peer IPs, to distinguish a legitimate remote-admin session from an adversary-controlled one and to characterize the ORB network the device may have joined
Tuning Guidance
Before enabling in alerting mode, populate the known-management-IP allowlist (jump hosts, MSP VPN egress ranges, NOC subnets) referenced in the first hunting query and, where the platform supports it, fold that allowlist directly into the primary rule so that logins from recognized management sources are excluded up front rather than merely reviewed after the fact — this is the single highest-leverage tuning step, since it eliminates the majority of routine-administration false positives. Confirm which of the organization's edge devices are legitimate site-to-site VPN hubs, SD-WAN concentrators, or cloud NVAs whose designed function structurally resembles external-to-external relay, and add them to a suppression list or raise their DistinctExternalPeerPairs threshold individually rather than raising the global threshold, which would reduce sensitivity everywhere. Validate that each vendor integration's Activity/Message field text actually contains the login and config-change keywords this rule matches on — run the fleet-wide unattributed-change hunting query first to confirm keyword coverage before trusting an absence of alerts as an absence of activity. Because DeviceAction/Activity keyword matching is inherently vendor- and firmware-version-dependent, review and extend the keyword lists whenever a new device model or vendor is onboarded into the fleet.
Hunting Queries
30-day fleet-wide hunt for configuration-change events on any managed edge device that were NOT immediately preceded by a login from a known, allowlisted management IP (jump host, MSP VPN egress, or NOC range). Because legitimate administration should almost always originate from a small, well-known set of management IPs, a config change attributable only to an unrecognized source is the earliest possible signal of a hijack in progress — well before the relay-fanout traffic signal has had time to accumulate. The output should be used both to catch early-stage hijacks and to build out the KnownManagementIPs allowlist that the primary detection's admin-login arm implicitly depends on.
// Hunt: fleet-wide inventory of every config-change event NOT preceded by a login from a known management IP range, to find devices changed via unattributed access even without the relay-fanout signal yet appearing
let KnownManagementIPs = dynamic(["198.51.100.10", "198.51.100.11"]); // replace with actual jump-host/MSP-VPN egress ranges
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where Activity has_any ("configuration changed", "port forward", "nat rule", "user added", "firmware")
| join kind=leftanti (
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where SourceIP in (KnownManagementIPs)
| project DeviceName, TimeGenerated
) on DeviceName
| summarize UnattributedChangeCount = count(), Changes = make_set(Activity, 10) by DeviceName
| sort by UnattributedChangeCount descindex=network (sourcetype=cisco:asa OR sourcetype=fortinet_utm OR sourcetype=sonicwall OR sourcetype=juniper OR sourcetype=mikrotik OR sourcetype=ubnt)
(Activity="*config*" OR Activity="*port forward*" OR Activity="*nat rule*" OR Activity="*user added*" OR Activity="*firmware*")
| eval DeviceHostName=coalesce(host, device_name)
| where NOT src_ip IN ("198.51.100.10", "198.51.100.11")
| stats count as UnattributedChangeCount, values(Activity) as Changes by DeviceHostName
| sort - UnattributedChangeCount37-day baseline-versus-current-week hunt comparing each edge device's own historical external-to-external relay volume against its most recent week, independent of whether a config-change event was ever logged for that device. This catches hijacks where the config change itself was never captured in CommonSecurityLog (for example, made via a local console session, or via a management protocol the SIEM integration does not parse for Activity text) but the resulting relay traffic still shows a clear step-change from the device's own baseline.
// Hunt: devices whose external-to-external relay volume this week is a significant step-change from their own 30-day baseline, independent of any correlated admin-login event
CommonSecurityLog
| where TimeGenerated > ago(37d)
| where DeviceAction =~ "allow"
| where isnotempty(SourceIP) and isnotempty(DestinationIP)
| where ipv4_is_private(SourceIP) == false and ipv4_is_private(DestinationIP) == false
| extend Period = iff(TimeGenerated > ago(7d), "CurrentWeek", "BaselineWindow")
| summarize PeerPairs = dcount(strcat(SourceIP, "->", DestinationIP)) by DeviceName, Period
| evaluate pivot(Period, sum(PeerPairs))
| extend BaselineDailyAvg = BaselineWindow / 30.0
| extend CurrentDailyAvg = CurrentWeek / 7.0
| where CurrentDailyAvg > (BaselineDailyAvg * 5) and CurrentDailyAvg > 5
| project DeviceName, BaselineDailyAvg, CurrentDailyAvg, StepChangeRatio = round(CurrentDailyAvg / max_of(BaselineDailyAvg, 0.1), 1)
| sort by StepChangeRatio descindex=network (sourcetype=cisco:asa OR sourcetype=fortinet_utm OR sourcetype=sonicwall OR sourcetype=juniper OR sourcetype=mikrotik OR sourcetype=ubnt) action=allowed earliest=-37d
| eval DeviceHostName=coalesce(host, device_name)
| where NOT cidrmatch("10.0.0.0/8", src_ip) AND NOT cidrmatch("172.16.0.0/12", src_ip) AND NOT cidrmatch("192.168.0.0/16", src_ip)
| where NOT cidrmatch("10.0.0.0/8", dest_ip) AND NOT cidrmatch("172.16.0.0/12", dest_ip) AND NOT cidrmatch("192.168.0.0/16", dest_ip)
| eval PeerPair=src_ip."->".dest_ip
| eval Period=if(_time > relative_time(now(), "-7d"), "CurrentWeek", "BaselineWindow")
| stats dc(PeerPair) as PeerPairs by DeviceHostName, Period
| stats sum(eval(if(Period="CurrentWeek", PeerPairs, 0))) as CurrentWeek, sum(eval(if(Period="BaselineWindow", PeerPairs, 0))) as BaselineWindow by DeviceHostName
| eval BaselineDailyAvg=round(BaselineWindow/30, 2), CurrentDailyAvg=round(CurrentWeek/7, 2)
| eval StepChangeRatio=round(CurrentDailyAvg/max(BaselineDailyAvg, 0.1), 1)
| where CurrentDailyAvg > (BaselineDailyAvg * 5) AND CurrentDailyAvg > 5
| sort - StepChangeRatioAtomic Red Team Tests
Uses the standard `logger` utility to emit synthetic CEF-formatted syslog messages to the local syslog daemon, mimicking a Cisco-ASA-style admin authentication success followed 5 minutes later by a port-forward configuration change on the same simulated device hostname. Validates that the SIEM's CEF parser correctly extracts DeviceVendor, DeviceName, Activity, and SourceIP into CommonSecurityLog (or the platform-equivalent normalized table) and that the admin-login-to-config-change join logic in the primary detection fires on the timing window.
Command
logger -p local4.info "CEF:0|Cisco|ASA|9.16|106100|Authentication Success|5|src=203.0.113.45 duser=admin msg=Login succeeded dvc=LAB-EDGE-01"
sleep 5
logger -p local4.info "CEF:0|Cisco|ASA|9.16|305013|Configuration Changed|5|src=203.0.113.45 duser=admin msg=Port forward rule added dvc=LAB-EDGE-01"
echo 'Synthetic admin-login-plus-config-change sequence emitted'Cleanup
trueExpected Telemetry
The syslog forwarder/agent (rsyslog, syslog-ng, or the SIEM's own collector) picks up both CEF lines from the local syslog daemon and forwards them to the SIEM's edge-device log source, where they should populate as two CommonSecurityLog rows for DeviceName LAB-EDGE-01 with Activity fields containing 'Authentication Success' and 'Configuration Changed' respectively, 5 seconds apart.
Expected Detection
The AdminLogins and ConfigChanges sub-queries should each independently match one of the two synthetic events, and the 30-minute correlation join should link them since they are only 5 seconds apart. This test validates the login-to-change correlation arm in isolation; it will not by itself trigger the full rule, which also requires the RelayFanout arm — pair with the second atomic test to exercise the complete three-signal correlation.
Uses the test host as a stand-in relay by opening an SSH SOCKS dynamic port-forward (`ssh -D`) to a lab jump host, then issuing curl requests through that SOCKS proxy to several distinct, unrelated public IP-literal endpoints. This produces a genuine external-to-external session pattern through the intermediary (the SSH jump host's own outbound connections have neither source nor destination equal to the internal network), reproducing the relay-fan-out shape the detection's third arm targets. Requires an authorized lab jump host and only public, non-sensitive destinations.
Command
ssh -f -N -D 1080 [email protected]
for ip in 93.184.216.34 151.101.1.140 104.16.132.229 172.67.74.226 198.41.214.162 199.36.158.100; do
curl --socks5-hostname 127.0.0.1:1080 --max-time 5 -s -o /dev/null "https://$ip/" || true
done
pkill -f 'ssh -f -N -D 1080'
echo 'Relay fan-out simulation via SSH SOCKS proxy complete'Cleanup
pkill -f 'ssh -f -N -D 1080' 2>/dev/null; trueExpected Telemetry
The lab jump host's own firewall/session log should show at least six distinct outbound sessions to the listed public IPs, all originating from the jump host itself rather than the original test host — this is the external-to-external relay signature from the jump host's perspective. If the jump host is itself onboarded as a monitored edge device, its CommonSecurityLog entries should show DeviceAction allow with SourceIP and DestinationIP both public.
Expected Detection
The RelayFanout sub-query should count at least 6 distinct SourceIP/DestinationIP pairs for the jump host within the lookback window. Six is below the default MinDistinctExternalPeerPairs threshold of 15, so lower the threshold temporarily in a lab copy of the rule to validate the counting logic end-to-end, or repeat the loop with a larger destination list to exceed the production threshold. This test validates the relay-fanout arm in isolation; pair with the first atomic test's synthetic login/config-change events on the same DeviceHostName within the correlation window to exercise the full three-signal rule.
Combines the admin-login/config-change CEF emission and the relay fan-out generation into a single timed sequence against the same simulated device hostname, reproducing the complete hijack pattern the primary detection correlates: login, followed by a config change within the correlation window, followed by external-to-external relay traffic. This is the closest lab reproduction of the full rule logic without requiring a physical or virtual edge device under test.
Command
DEVICE=LAB-EDGE-02
logger -p local4.info "CEF:0|Fortinet|FortiGate|7.0|0100032001|Admin login\u00a0successful|5|src=203.0.113.99 duser=admin msg=Authentication success dvc=$DEVICE"
sleep 10
logger -p local4.info "CEF:0|Fortinet|FortiGate|7.0|0100044546|Configuration changed|5|src=203.0.113.99 duser=admin msg=New admin account created dvc=$DEVICE"
ssh -f -N -D 1081 [email protected]
for ip in 93.184.216.34 151.101.1.140 104.16.132.229 172.67.74.226 198.41.214.162 199.36.158.100 203.0.113.7 198.51.100.23 192.0.2.55 5.161.65.106 172.67.74.152 104.21.34.99 151.101.65.140 93.184.216.35 172.67.75.1 104.16.133.229; do
curl --socks5-hostname 127.0.0.1:1081 --max-time 5 -s -o /dev/null "https://$ip/" || true
done
pkill -f 'ssh -f -N -D 1081'
echo 'Full three-signal hijack simulation complete'Cleanup
pkill -f 'ssh -f -N -D 1081' 2>/dev/null; trueExpected Telemetry
CommonSecurityLog (or equivalent) shows an Authentication-Success entry and a Configuration-Changed entry for LAB-EDGE-02 ten seconds apart, plus at least 16 distinct external-to-external session pairs originating from the jump host, all within the same lookback window.
Expected Detection
The full correlated rule should fire: the admin-login-to-config-change join matches on the 10-second gap, the relay-fanout arm exceeds the default 15-distinct-peer-pair threshold with 16 destinations, and the final join between the suspicious-admin-change result and the relay-fanout result should surface LAB-EDGE-02 as a positive detection. If it does not fire, check first that the CEF parser mapped both DeviceName fields to the identical string and that the SIEM's ingestion delay has not pushed the relay traffic outside the same evaluation window as the login/config-change pair.