Managed Edge Device Hijacked Into Adversary Operational Relay Box (ORB) Network
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.
What is THREAT-Infra-EdgeDeviceORBRelayHijack Managed Edge Device Hijacked Into Adversary Operational Relay Box (ORB) Network?
Managed Edge Device Hijacked Into Adversary Operational Relay Box (ORB) Network (THREAT-Infra-EdgeDeviceORBRelayHijack) maps to the Resource Development tactic — the adversary is trying to establish resources they can use to support operations in MITRE ATT&CK.
This page provides production-ready detection logic for Managed Edge Device Hijacked Into Adversary Operational Relay Box (ORB) Network, covering the data sources and telemetry it touches: Network Device: Network Device Configuration Change, Network Device: Network Device Authentication, Network Traffic: Network Connection Creation, CommonSecurityLog (CEF-forwarded edge device syslog). The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Resource Development
let LookbackWindow = 24h;
let CorrelationWindow = 30m;
let MinDistinctExternalPeerPairs = 15;
let EdgeDeviceVendors = dynamic(["Cisco", "Fortinet", "SonicWall", "Ubiquiti", "MikroTik", "Juniper Networks", "pfSense", "Netgear", "TP-Link", "Palo Alto Networks", "DrayTek", "Zyxel"]);
let AdminAuthKeywords = dynamic(["login succeeded", "authentication success", "admin login", "web ui login", "user logged in", "ssh login", "successful login"]);
let ConfigChangeKeywords = dynamic(["configuration changed", "config saved", "port forward", "nat rule", "virtual server", "user added", "user created", "new admin account", "firmware", "schedule created", "cron job added"]);
let AdminLogins = CommonSecurityLog
| where TimeGenerated > ago(LookbackWindow)
| where DeviceVendor in~ (EdgeDeviceVendors)
| where Activity has_any (AdminAuthKeywords) or Message has_any (AdminAuthKeywords)
| where isnotempty(SourceIP)
| project LoginTime = TimeGenerated, DeviceHostName = DeviceName, DeviceVendor, AdminSourceIP = SourceIP, SourceUserName, LoginActivity = Activity;
let ConfigChanges = CommonSecurityLog
| where TimeGenerated > ago(LookbackWindow)
| where DeviceVendor in~ (EdgeDeviceVendors)
| where Activity has_any (ConfigChangeKeywords) or Message has_any (ConfigChangeKeywords)
| project ChangeTime = TimeGenerated, DeviceHostName = DeviceName, DeviceVendor, ChangeActivity = Activity, ChangeMessage = Message;
let SuspiciousAdminChange = AdminLogins
| join kind=inner ConfigChanges on DeviceHostName, DeviceVendor
| where ChangeTime between (LoginTime .. LoginTime + CorrelationWindow)
| project DeviceHostName, DeviceVendor, LoginTime, AdminSourceIP, SourceUserName, LoginActivity, ChangeTime, ChangeActivity, ChangeMessage;
let RelayFanout = CommonSecurityLog
| where TimeGenerated > ago(LookbackWindow)
| where DeviceVendor in~ (EdgeDeviceVendors)
| where DeviceAction =~ "allow"
| where isnotempty(SourceIP) and isnotempty(DestinationIP)
| where ipv4_is_private(SourceIP) == false and ipv4_is_private(DestinationIP) == false
| summarize ExternalToExternalSessions = count(), DistinctExternalPeerPairs = dcount(strcat(SourceIP, "->", DestinationIP)), FanoutWindowStart = min(TimeGenerated), FanoutWindowEnd = max(TimeGenerated) by DeviceHostName = DeviceName, DeviceVendor
| where DistinctExternalPeerPairs >= MinDistinctExternalPeerPairs;
SuspiciousAdminChange
| join kind=inner RelayFanout on DeviceHostName, DeviceVendor
| where FanoutWindowStart >= LoginTime
| project DeviceHostName, DeviceVendor, LoginTime, AdminSourceIP, SourceUserName, LoginActivity, ChangeTime, ChangeActivity, ChangeMessage, ExternalToExternalSessions, DistinctExternalPeerPairs, FanoutWindowStart, FanoutWindowEnd
| sort by DistinctExternalPeerPairs desc Correlates three signals on the same managed edge device within a 24-hour window: (1) an administrative authentication to the device's management interface, (2) a configuration change (port-forward/NAT rule, new local admin account, or firmware change) within 30 minutes of that login, and (3) the same device subsequently carrying at least 15 distinct external-to-external session pairs — traffic where both the source and destination are public addresses, meaning the device is relaying rather than terminating the connection. Each arm alone produces routine noise (admins do make legitimate config changes; some edge devices legitimately relay traffic for site-to-site tunnels); the conjunction of an unattributed admin change immediately followed by a step-change in relay-shaped traffic is what distinguishes a hijack event from routine administration. Requires the edge device to forward CEF/syslog into CommonSecurityLog with Activity/Message text carrying recognizable login and config-change keywords, which most Cisco, Fortinet, SonicWall, Ubiquiti, MikroTik, Juniper, pfSense, and Palo Alto integrations provide out of the box.
Data Sources
Required Tables
False Positives
- Legitimate MSP or in-house network administration: a scheduled maintenance window where an admin logs in and makes a genuine port-forward or NAT change, coinciding by chance with an unrelated increase in external-to-external traffic on a device that also serves as a site-to-site VPN hub
- Site-to-site VPN concentrators and SD-WAN edge devices whose entire normal function is to relay traffic between two external-facing networks, which will structurally resemble the external-to-external fan-out signal even without any compromise
- Firmware auto-update processes that log as a 'firmware' configuration-change event on a normal patch cycle, with no associated suspicious admin login
- A newly deployed or re-IP'd device whose CommonSecurityLog Activity/Message text does not yet match the vendor-specific keyword set tuned into this rule, causing under- rather than over-alerting rather than false positives directly, but worth noting during rollout
- Cloud-hosted network virtual appliances (NVAs) that legitimately terminate many external client sessions and forward them onward as part of their designed function (e.g., a cloud proxy or CASB gateway) rather than a hijacked SOHO device
Sigma rule & cross-platform mapping
The detection logic for Managed Edge Device Hijacked Into Adversary Operational Relay Box (ORB) Network (THREAT-Infra-EdgeDeviceORBRelayHijack) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: network_connection
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides for THREAT-Infra-EdgeDeviceORBRelayHijack
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
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.
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
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 desc index=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 - UnattributedChangeCount 37-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 desc index=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 - StepChangeRatio Atomic 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
true Expected 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; true Expected 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; true Expected 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.