T1599

Network Boundary Bridging

Defense Evasion Last updated:

This detection identifies adversary activity consistent with MITRE ATT&CK T1599 (Network Boundary Bridging), where threat actors compromise perimeter network devices — routers, firewalls, or internal segmentation appliances — and reconfigure them to allow prohibited traffic to cross trust boundaries. Detection focuses on unauthorized ACL modifications, NAT rule changes, routing table manipulation, and firewall policy changes sourced from network device syslog and configuration audit trails ingested into SIEM. Because this technique targets network infrastructure rather than endpoints, primary telemetry comes from CommonSecurityLog (CEF-formatted device logs), Syslog, and network device AAA/TACACS+ audit streams. High-severity modifications include permit-any rules, deletion of blocking ACLs, addition of bypass NAT entries, and introduction of static routes to previously isolated segments.

What is T1599 Network Boundary Bridging?

Network Boundary Bridging (T1599) maps to the Defense Evasion tactic — the adversary is trying to avoid being detected in MITRE ATT&CK.

This page provides production-ready detection logic for Network Boundary Bridging, covering the data sources and telemetry it touches: Microsoft Sentinel - CommonSecurityLog (CEF), Microsoft Sentinel - 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
Defense Evasion
Technique
T1599 Network Boundary Bridging
Canonical reference
https://attack.mitre.org/techniques/T1599/
Microsoft Sentinel / Defender
kusto 
let SuspiciousKeywords = dynamic(["permit ip any any", "no access-list", "access-group removed", "nat bypass", "ip route 0.0.0.0", "no ip access-group", "access-list extended permit", "shutdown", "policy deleted", "rule removed", "bypass", "clear access-list", "no firewall"]);
let NetworkVendors = dynamic(["Cisco", "Palo Alto Networks", "Fortinet", "Check Point", "Juniper Networks", "SonicWall", "WatchGuard", "F5", "Barracuda"]);
CommonSecurityLog
| where DeviceVendor in~ (NetworkVendors)
| where Activity has_any ("ACL-change", "config-change", "policy-change", "route-change", "nat-change", "firewall-change", "configuration")
    or Message has_any (SuspiciousKeywords)
| where DeviceAction !in~ ("deny", "blocked", "drop", "reject")
| extend ChangeType = case(
    Message has_any ("access-list", "ACL", "access-group"), "ACL_Modification",
    Message has_any ("nat", "NAT", "overload"), "NAT_Rule_Change",
    Message has_any ("ip route", "route add", "static route", "gateway"), "Route_Modification",
    Message has_any ("policy", "rule", "filter"), "Policy_Change",
    Message has_any ("shutdown", "no shutdown", "interface"), "Interface_Change",
    "Other"
)
| extend RiskScore = case(
    Message has "permit ip any any", 100,
    Message has "no access-list", 95,
    Message has "nat bypass", 95,
    Message has "ip route 0.0.0.0", 90,
    Message has "access-group removed", 85,
    Message has "clear access-list", 80,
    Message has "policy deleted", 75,
    70
)
| where RiskScore >= 75
| project TimeGenerated, DeviceVendor, DeviceProduct, DeviceAddress, ChangeType, RiskScore, Activity, Message, SourceUserName, SourceIP, Computer
| order by RiskScore desc, TimeGenerated desc

Detects unauthorized or suspicious configuration changes on perimeter network devices by querying CommonSecurityLog for CEF-formatted events from firewalls and routers. Focuses on ACL deletions or permit-any rules, NAT bypass entries, static route additions to isolated segments, and policy removals — all of which could allow prohibited traffic to cross trust boundaries. Risk-scored to surface highest-severity changes first.

high severity medium confidence

Data Sources

Microsoft Sentinel - CommonSecurityLog (CEF) Microsoft Sentinel - Syslog

Required Tables

CommonSecurityLog

False Positives

  • Authorized network engineers performing scheduled maintenance during approved change windows — validate against change management system (ServiceNow/Jira)
  • Automated network management tools (Cisco DNA Center, Ansible AWX, SolarWinds NCM) pushing approved configuration templates
  • Security operations performing penetration test or red team exercises with pre-authorized network changes
  • Firewall rule cleanup projects legitimately removing outdated ACL entries as part of hygiene programs

Sigma rule & cross-platform mapping

The detection logic for Network Boundary Bridging (T1599) 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:
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1599 Sigma rules on detection.fyi

Platform-specific guides for T1599

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-03-20 Research depth: deep
References (5)

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.

  1. Test 1Add iptables rule to permit forwarding between network segments on Linux firewall

    Expected signal: Syslog events showing iptables rule addition, kernel sysctl change in /proc/sys/net/ipv4/ip_forward, auditd records if audit rules on iptables binary, and Linux auth logs showing sudo elevation.

  2. Test 2Add static route to bridge isolated network segment on Linux router

    Expected signal: Auditd records of 'ip route' command execution, kernel routing table modification in /proc/net/route, syslog if routing daemon is logging, and file modification event on /etc/network/routes.

  3. Test 3Flush iptables security rules to allow all inter-segment traffic

    Expected signal: Syslog or auditd records capturing: (1) iptables -F FORWARD command execution with sudo, (2) iptables -P FORWARD ACCEPT policy change, (3) sysctl net.ipv4.ip_forward=1. If network device sends SNMP traps, a linkDown/warmStart trap may fire.

Response Playbook

Triage

  1. Step 1: Identify the source IP/user that made the configuration change. Cross-reference against the authorized network administrator list and verify against active change management tickets (ServiceNow, Jira) for the timestamp.
  2. Step 2: Pull the full device syslog for the affected network device for the 2-hour window surrounding the alert. Look for additional configuration commands, authentication events (TACACS+/RADIUS), and any commands that enumerate routing tables or ACLs (show run, show access-list).
  3. Step 3: Compare the current device running configuration against the last known-good baseline in your configuration management database (CMDB). Use 'show run | diff' or equivalent to identify all delta changes.
  4. Step 4: Determine what traffic the rule change would now allow. Map source and destination networks to internal asset inventory to understand which sensitive systems are now reachable across the breached boundary.
  5. Step 5: Check AAA/TACACS+/RADIUS authentication logs for the source account. Verify whether the account login occurred from an authorized management jump host or an unexpected IP address, and whether MFA was used.
  6. Step 6: Review NetFlow or firewall session logs for traffic matching the newly permitted patterns — if the rule was added for attack purposes, adversarial traffic may already be transiting the boundary.

Containment

  1. Immediately revert the unauthorized configuration change on the affected network device. Re-apply the last known-good ACL/policy from configuration backup. Verify restoration with 'show access-list' or equivalent.
  2. If the source account cannot be confirmed as authorized, disable the account in AAA/TACACS+ and force re-authentication. If an admin account was compromised, rotate all credentials for that device.
  3. Place the affected device under enhanced monitoring — capture all subsequent configuration commands and authentication events for 72 hours post-incident.
  4. If traffic has already transited the boundary, segment or isolate the destination network segment. Treat systems that received new inbound connections as potentially compromised.
  5. Engage network team to perform emergency ACL audit across all perimeter and segmentation devices to check for similar unauthorized changes on adjacent equipment.

Evidence Collection

  1. Export full running configuration from the affected device before any remediation: 'show running-config' (Cisco), 'show configuration' (Juniper). Hash the output for chain of custody.
  2. Collect TACACS+/RADIUS authentication logs for the device for the 48 hours preceding the alert. Export as raw syslog with timestamps preserved.
  3. Extract NetFlow/IPFIX records for all traffic crossing the affected boundary segment for the period between rule change and detection. Focus on new source-destination pairs not present in baseline.
  4. Pull the full device syslog to capture all commands entered in the session that made the change — Cisco IOS logs each command under event %SYS-5-CONFIG_I.
  5. If available, collect packet captures from the firewall inspection point for any suspicious traffic patterns identified in NetFlow analysis.
  6. Document the diff between current running config and last CMDB backup with timestamps for forensic record.

Escalation Criteria

  • ! Escalate immediately if the configuration change was made from an IP address outside the authorized network management infrastructure (jump hosts, NOC subnets) — indicates credential compromise or insider threat.
  • ! Escalate if NetFlow analysis confirms that traffic has already traversed the newly opened boundary, particularly if destined for high-value segments (domain controllers, payment systems, industrial control networks).
  • ! Escalate if multiple network devices show simultaneous or sequential unauthorized configuration changes — indicates coordinated attack campaign against network infrastructure.
  • ! Escalate if the affected boundary device separates a DMZ or external network from internal trusted networks — the impact radius is enterprise-wide.
  • ! Escalate to incident response if the compromised account is a shared service account or a privileged network admin account used across multiple devices.

Investigation Guide

Forensic Artifacts

  • > Network device running configuration snapshot (show running-config) — captures all ACL, NAT, and routing changes
  • > TACACS+/RADIUS authentication logs — records who authenticated to the device management plane and from which IP
  • > Network device syslog — Cisco IOS logs config changes under %SYS-5-CONFIG_I with source IP
  • > NetFlow/IPFIX records — reveals traffic patterns that changed after configuration modification
  • > SNMP trap logs — configuration change traps (coldStart, warmStart, linkDown, linkUp, authenticationFailure)
  • > Configuration management database (CMDB) baseline — enables diff comparison to identify all changes
  • > AAA server database — authorization records for configuration commands
  • > Firewall session table snapshots before and after the change — identifies new permitted sessions

Tuning Guidance

This detection generates the highest false positive volume during scheduled maintenance windows. Integrate with change management systems to suppress alerts where a matching approved change ticket exists. Create an allow-list of authorized management source IPs (jump hosts, NOC consoles) and TACACS+/RADIUS server IPs to filter legitimate administrative sessions. Exclude known automation tool service accounts (Ansible, Terraform, SolarWinds) by username. Set the risk score threshold to 80+ in environments with high change velocity. For hunting queries, establish 30-day baselines for inter-segment traffic volume before alerting on anomalies. Consider restricting detection to off-hours changes (evenings, weekends) to further reduce noise while preserving coverage for adversarial activity.

Hunting Queries

Hunts for administrative logins to network devices from public IP addresses, which may indicate compromised management plane access from external attacker infrastructure.

Hunting — KQL
kql 
// Hunt for network devices receiving logins from non-management IPs
let AuthorizedMgmtSubnets = dynamic(["10.0.0.0/8", "172.16.0.0/12", "192.168.1.0/24"]);
CommonSecurityLog
| where DeviceVendor in~ ("Cisco", "Palo Alto Networks", "Fortinet", "Juniper Networks", "Check Point")
| where Activity has_any ("login", "authentication", "logon", "ssh", "telnet", "console")
| where DeviceAction has_any ("success", "accept", "passed", "authenticated")
| extend SourceIPParsed = iff(isnotempty(SourceIP), SourceIP, DeviceAddress)
| where not(ipv4_is_private(SourceIPParsed))
    or not(SourceIPParsed matches regex @"^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)")
| project TimeGenerated, DeviceVendor, DeviceProduct, DeviceAddress, SourceIPParsed, SourceUserName, Activity, Message
| order by TimeGenerated desc
Hunting — SPL
spl 
index=network (sourcetype=cisco:ios OR sourcetype=cisco:asa OR sourcetype=pan:log OR sourcetype=juniper:junos)
| search ("login" OR "authentication" OR "SSH" OR "telnet" OR "console" OR "accepted")
| rex field=_raw "from\s+(?P<src_ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})"
| eval is_private=if(match(src_ip, "^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)"), "yes", "no")
| where is_private="no" AND isnotnull(src_ip)
| stats count by host, src_ip, user, is_private
| sort - count

Hunts for coordinated, multi-device configuration changes from a single user account within a 30-minute window — a pattern consistent with an adversary systematically disabling boundary controls across network infrastructure.

Hunting — KQL
kql 
// Hunt for rapid sequential config changes across multiple network devices — coordinated attack pattern
CommonSecurityLog
| where DeviceVendor in~ ("Cisco", "Palo Alto Networks", "Fortinet", "Juniper Networks", "Check Point", "SonicWall")
| where Message has_any ("configuration", "config", "access-list", "ACL", "policy", "nat", "route")
| where DeviceAction !in~ ("deny", "blocked", "drop")
| summarize ChangeCount = count(), DevicesAffected = dcount(DeviceAddress), DeviceList = make_set(DeviceAddress, 20), SampleMessages = make_set(Message, 5) by SourceUserName, bin(TimeGenerated, 30m)
| where DevicesAffected >= 2 or ChangeCount >= 5
| project TimeGenerated, SourceUserName, ChangeCount, DevicesAffected, DeviceList, SampleMessages
| order by DevicesAffected desc, ChangeCount desc
Hunting — SPL
spl 
index=network (sourcetype=cisco:ios OR sourcetype=cisco:asa OR sourcetype=pan:log OR sourcetype=juniper:junos)
| search ("config" OR "access-list" OR "nat" OR "route" OR "policy")
| search NOT ("blocked" OR "denied" OR "dropped")
| bucket _time span=30m
| stats count as change_count, dc(host) as devices_changed, values(host) as device_list by _time, user
| where devices_changed >= 2 OR change_count >= 5
| sort - devices_changed

Hunts for high-volume traffic flows crossing network segment boundaries using NetFlow data. Establishes cross-segment communication baselines and surfaces new or anomalously high inter-segment flows that may indicate an adversary actively exploiting a bridged boundary.

Hunting — KQL
kql 
// Hunt for new traffic flows crossing previously inactive or low-traffic network boundaries
CommonSecurityLog
| where DeviceVendor in~ ("Cisco", "Palo Alto Networks", "Fortinet", "Check Point")
| where Activity has_any ("allow", "permit", "accept", "pass", "forward")
| where isnotempty(SourceIP) and isnotempty(DestinationIP)
| extend SrcSegment = strcat(split(SourceIP, ".")[0], ".", split(SourceIP, ".")[1])
| extend DstSegment = strcat(split(DestinationIP, ".")[0], ".", split(DestinationIP, ".")[1])
| where SrcSegment != DstSegment
| summarize FlowCount = count(), DestPorts = make_set(DestinationPort, 10), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by DeviceAddress, SrcSegment, DstSegment, SourceIP
| where FlowCount > 100
| extend DurationMinutes = datetime_diff("minute", LastSeen, FirstSeen)
| project DeviceAddress, SrcSegment, DstSegment, SourceIP, FlowCount, DurationMinutes, DestPorts, FirstSeen
| order by FlowCount desc
Hunting — SPL
spl 
index=network sourcetype=netflow OR sourcetype="cisco:netflow"
| eval src_segment=mvindex(split(src_ip, "."), 0)+"."+mvindex(split(src_ip, "."), 1)
| eval dst_segment=mvindex(split(dest_ip, "."), 0)+"."+mvindex(split(dest_ip, "."), 1)
| where src_segment!=dst_segment
| bucket _time span=1h
| stats count as flow_count, dc(dest_port) as unique_ports, values(dest_port) as ports by _time, src_ip, dest_ip, src_segment, dst_segment
| where flow_count > 500
| sort - flow_count

Atomic Red Team Tests

Test 1 Add iptables rule to permit forwarding between network segments on Linux firewall
linux

Simulates an adversary adding a permissive iptables FORWARD rule on a Linux-based firewall/router to allow traffic to pass between two previously isolated network interfaces, effectively bridging the security boundary.

Command

bash 
# Save current rules for cleanup
sudo iptables-save > /tmp/iptables_backup.rules

# Add permissive forwarding rule between two interfaces
sudo iptables -I FORWARD -i eth0 -o eth1 -j ACCEPT
sudo iptables -I FORWARD -i eth1 -o eth0 -j ACCEPT

# Enable IP forwarding
sudo sysctl -w net.ipv4.ip_forward=1

# Verify rule was added
sudo iptables -L FORWARD -n -v

Cleanup

bash 
sudo iptables-restore < /tmp/iptables_backup.rules
sudo sysctl -w net.ipv4.ip_forward=0
rm /tmp/iptables_backup.rules

Expected Telemetry

Syslog events showing iptables rule addition, kernel sysctl change in /proc/sys/net/ipv4/ip_forward, auditd records if audit rules on iptables binary, and Linux auth logs showing sudo elevation.

Expected Detection

SIEM alert on network boundary configuration change — syslog sourced from host showing iptables ACCEPT rule addition to FORWARD chain, correlated with ip_forward=1 sysctl change.

Test 2 Add static route to bridge isolated network segment on Linux router
linux

Simulates an adversary adding a static route on a Linux-based router to enable routing to a previously unreachable network segment, effectively making an isolated segment reachable from the attacker's foothold.

Command

bash 
# Document current routing table
ip route show > /tmp/route_backup.txt

# Add static route to isolated segment (adjust subnet to match lab environment)
sudo ip route add 10.20.30.0/24 via 192.168.1.1 dev eth0

# Persist across reboot (simulating adversary persistence)
echo '10.20.30.0/24 via 192.168.1.1 dev eth0' | sudo tee -a /etc/network/routes

# Verify route added
ip route show | grep 10.20.30

Cleanup

bash 
sudo ip route del 10.20.30.0/24 via 192.168.1.1 dev eth0
sudo sed -i '/10.20.30.0\/24/d' /etc/network/routes
rm /tmp/route_backup.txt

Expected Telemetry

Auditd records of 'ip route' command execution, kernel routing table modification in /proc/net/route, syslog if routing daemon is logging, and file modification event on /etc/network/routes.

Expected Detection

Alert on suspicious static route addition sourced from syslog or auditd — new route to private subnet added by non-root user via sudo, correlated with subsequent network traffic to previously unreachable segment in NetFlow.

Test 3 Flush iptables security rules to allow all inter-segment traffic
linux

Simulates a high-impact adversary action of completely removing boundary enforcement rules from a Linux firewall, equivalent to a 'permit ip any any' ACL wipe on a Cisco device. This models APT-style attacks where adversaries flush firewall policies after compromising network infrastructure.

Command

bash 
# Backup current rules
sudo iptables-save > /tmp/pre_test_rules.rules

# Flush all FORWARD chain rules (removes inter-segment filtering)
sudo iptables -F FORWARD

# Set default FORWARD policy to ACCEPT
sudo iptables -P FORWARD ACCEPT

# Enable IP forwarding to allow traffic between interfaces
sudo sysctl -w net.ipv4.ip_forward=1

# Confirm — should show empty FORWARD chain with ACCEPT policy
sudo iptables -L FORWARD -n -v

Cleanup

bash 
sudo iptables -P FORWARD DROP
sudo iptables-restore < /tmp/pre_test_rules.rules
sudo sysctl -w net.ipv4.ip_forward=0
rm /tmp/pre_test_rules.rules

Expected Telemetry

Syslog or auditd records capturing: (1) iptables -F FORWARD command execution with sudo, (2) iptables -P FORWARD ACCEPT policy change, (3) sysctl net.ipv4.ip_forward=1. If network device sends SNMP traps, a linkDown/warmStart trap may fire.

Expected Detection

High-severity alert on complete FORWARD chain flush correlated with ip_forward enablement — risk score 95+ in SIEM detection. Additional alert may fire from NetFlow when previously blocked inter-segment traffic begins flowing.

Related Detections

Tactic Hub

TA0005Defense Evasion

Sub-techniques (1)

Related Techniques

T1599.001Network Address Translation TraversalT1090.003Multi-hop ProxyT1020.001Traffic DuplicationT1090.001Internal ProxyT1021.001Remote Desktop ProtocolT1556.003Pluggable Authentication ModulesT1110Brute Force

Same Tactic: Defense Evasion

Popular Detections