ATT&CK T1599 Network Boundary Bridging Guide

Network Boundary Bridging (T1599) is what happens when the router or firewall that separates trusted from untrusted networks is itself compromised, so the segmentation you rely on is quietly rewritten by the adversary. ATT&CK v20 places T1599 in the Defense Impairment tactic (TA0112) for network devices, with one sub-technique, T1599.001 Network Address Translation Traversal. Once an attacker holds enough rights on a boundary device, they can permit traffic the policy forbids, translate addresses to reach hosts that are not routable from outside, or tunnel traffic to their own infrastructure. This page covers how adversaries do this, the cases ATT&CK and government advisories record, the configuration and flow telemetry that exposes it, the v20 mitigations and how to test. It is written for network security engineers and detection teams; it assumes you already manage your devices to a baseline such as the one in the CIS Control 12 Network Infrastructure Management Guide.

Key takeaways

The device becomes the attacker's policy engine. ATT&CK describes adversaries reconfiguring a compromised boundary device to pass normally prohibited traffic, then using it for command and control through T1090.003 Multi-hop Proxy or exfiltration through T1020.001 Traffic Duplication.
Configuration drift is the primary signal. The August 2025 joint advisory on PRC state-sponsored network compromises lists new ACL entries, GRE or IPsec tunnels, static routes, mirroring sessions and management services on high ports as changes to hunt for.
NAT is both a barrier and a tool. T1599.001 abuses NAT rules to reach non-routable internal addresses (RFC 1918 space) or to obscure traffic so flow monitoring sees the wrong addresses.
Most v20 mitigations are about who can log in. M1026, M1027, M1032 and M1043 protect device administration; M1037 tells you to block bridged traffic from an unaffected device in path.
Credentials are the usual way in. Cisco Talos found stolen legitimate credentials in all but one of the Salt Typhoon intrusions it investigated, so device admin accounts, SNMP strings and AAA shared secrets are the front line.

What T1599 is

ATT&CK defines Network Boundary Bridging as compromising perimeter network devices, or internal devices responsible for segmentation, to bypass restrictions on traffic routing between trusted and untrusted networks. Boundary devices enforce policy by IP address, layer 4 port or deep packet inspection. ATT&CK makes the point that whether the device is directly addressable or transparent makes no difference: with enough rights, the adversary changes the policy. ATT&CK also notes that adversaries may target internal segmentation devices in conjunction with internal proxies.

Bridging method	What changes on the device	What it achieves
ACL or firewall rule change	New permit entries for attacker addresses or ports	Direct access through the boundary, often to management services
NAT traversal (T1599.001)	New or modified static NAT, port address translation or destination NAT rules	Reach hosts on non-routable internal addresses; disguise source or destination in flow data
Tunnels and routes	GRE, mGRE or IPsec tunnels, static routes, policy-based routing	Carry internal traffic to attacker infrastructure, bypassing inspection points
Traffic mirroring	SPAN, RSPAN or ERSPAN sessions	Copy traffic out of a segment (ATT&CK T1020.001 Traffic Duplication)
Peering abuse	Use of trusted provider or peer links	Move data across organisational boundaries that are filtered loosely
Image modification	Patched operating system with a custom NAT or forwarding function	Bridging that is invisible in the running configuration (see T1601)

How adversaries use it: real cases

APT41 (G0096): ATT&CK v20 records APT41 using a tool called NATBypass to bypass firewall restrictions and reach compromised systems over RDP, citing DCSO CyTec research from December 2022. See the APT41 Threat Actor Profile.
Indian Critical Infrastructure Intrusions (C0043): v20 records the campaign using FRP (S1144) to bridge network boundaries and overcome NAT, citing Recorded Future and Dragos. Recorded Future's reporting notes the group likely co-opted internet-facing DVR and IP camera devices for command and control.
Salt Typhoon (G1045): v20 records the group abusing peer connections to exfiltrate data, citing the August 2025 joint advisory (CISA AA25-239A). That advisory describes actors adding attacker-controlled IPs to ACLs (often an ACL named 20, or 50 or 10 if 20 was taken), creating GRE, mGRE or IPsec tunnels and static routes, moving SSH to high ports in 22x22 or xxx22 patterns, configuring SPAN, RSPAN or ERSPAN sessions and exploiting weak policy between peered providers. The Salt Typhoon telecom intrusions page covers the credential side: stolen configurations exposed SNMP community strings and weakly encrypted local passwords.
In-memory NAT on routers: Cisco's write-up of attacks on IOS devices describes 2013 incidents where modified in-memory code provided NAT-style access to hosts behind RFC 1918 addresses, and a later sample that injected modules for exfiltration and NAT. This is the T1599.001 pattern implemented through image modification rather than configuration.

For the wider pattern of edge appliance compromise, see the Edge Device Exploitation by Threat Actors Guide and the Salt Typhoon Threat Actor Profile.

What to detect and where

ATT&CK v20 gives two detection strategies: DET0006 for the parent technique and DET0163 for NAT traversal. Their data components and log sources are in the first two columns; the third is NHI Mgmt Group's practical guidance.

Strategy and data component	Log source (v20)	What to look for
DET0006 Network Traffic Flow	NSM flow data	Flows between segments that policy says cannot talk; prohibited ports crossing a boundary; new east-west paths
DET0006 Network Traffic Content	Network device syslog	ACL or firewall rule modification; new route injection
DET0163 Network Traffic Content	Network device configuration	NAT table additions, updates or deletions outside change control
DET0163 Network Traffic Flow	NSM flow data	Address translation inconsistent with intended policy, such as an external address mapped to an internal management host

Configuration diffing is the core control

Every bridging method changes configuration or image. Pull running configurations on a schedule (at least daily for boundary devices), diff them against an approved baseline and route any difference to a reviewer. The joint advisory's hunting list is a good starting rule set: ACLs, static routes, tunnels, AAA and TACACS+ server settings, packet capture and SPAN definitions, and running containers. The Network Device Syslog and Configuration Change Detection Guide covers the collection pipeline.

Flow checks from an independent vantage point

A compromised boundary device can lie about its own traffic. Collect flow data from a device that is not the one being watched: an upstream router, a tap, or cloud VPC flow logs on the other side. The advisory lists specific signals: SSH on 22x22 or xxx22 ports and HTTPS on 18xxx ports reachable from outside the management VRF, TACACS+ flows to unapproved addresses, FTP or TFTP from devices to unapproved destinations, unexpected GRE or IPsec tunnels between autonomous systems, and SNMP SET operations.

AAA command accounting

Send every configuration command to an external TACACS+ server. A change that appears in the configuration diff but has no matching accounting record means either an unauthorised access path or tampering with accounting, and both deserve escalation.

Mitigations

ATT&CK v20 maps five mitigations to T1599 and the same five to T1599.001:

Mitigation	v20 guidance (summarised)	Practical step
M1026 Privileged Account Management	Restrict administrator accounts; prevent credential overlap between network and non-network platforms	Separate network admin identities from server and domain admin identities
M1027 Password Policies	Follow NIST guidelines when creating password policies	Unique local passwords per device, held in a vault
M1032 Multi-factor Authentication	Use MFA; most devices support TACACS+ or RADIUS	MFA at the AAA server or the management jump host
M1043 Credential Access Protection	Store local passwords encrypted where the device supports it	The joint advisory recommends Cisco Type 8 password hashing and Type 6 key encryption, avoiding Type 5 and Type 7
M1037 Filter Network Traffic	Block bridged traffic using an unaffected device in path, and keep monitoring	Plan containment points in advance so a second device can enforce policy

NHI Mgmt Group recommends these additional controls, drawn from the joint advisory's mitigations:

Isolate the management plane: put SSH, HTTPS, SNMP, TACACS+ and RADIUS in a dedicated management VRF with no route leakage, and default-deny management ACLs. See the Network Device Management Plane Hardening Guide.
Log denied traffic: end ACLs with an explicit deny with logging so blocked attempts are visible.
Protect routing: routing authentication, strict eBGP prefix filtering and alerts on new static routes or policy routing to unusual tunnel endpoints.
Turn off what you do not use: SNMPv1 and v2c, Telnet, HTTP management and Cisco Smart Install, and outbound VTY connections.
Segment in depth: do not let one device be the only boundary between the internet and crown-jewel networks. See M1030 Network Segmentation.

Where identity fits

Network devices run on machine credentials: SNMP community strings, TACACS+ and RADIUS shared secrets, local accounts used by monitoring and backup tools, and API tokens for controllers. Talos's Salt Typhoon analysis found attackers harvesting these from stolen configurations and from captured SNMP, TACACS and RADIUS traffic. Inventory every credential that can change device configuration, store it in a vault, rotate it after any suspected exposure and alert when a new local account or SSH key appears on a device. The Edge Device Security Guide covers this for edge appliances.

How to test

Baseline: export approved configurations for every boundary device and store them with a hash in version control.
Change detection: on a lab or non-production device, add a harmless ACL entry, a static NAT rule and a loopback-only GRE tunnel; confirm each produces a diff alert and that AAA accounting shows the commands.
Flow detection: generate test traffic across the test rule and confirm the independent flow source flags a policy violation.
Containment drill: rehearse M1037 by blocking the test flow at a second device and confirm the runbook names who can do this out of hours.
Roll back: remove the test entries, confirm the configuration matches the baseline hash again and close the test record.

Measure coverage with:

Percentage of boundary devices with automated daily configuration diffing.
Percentage of configuration changes with a matching change ticket and AAA accounting record.
Percentage of boundary devices whose traffic is also visible from an independent flow source.
Time from an unauthorised configuration change to analyst review.
Percentage of device credentials (local, SNMP, AAA secrets) rotated in the last 12 months.

Common failure patterns

Trusting the device's own logs. An adversary with configuration rights can also stop or redirect logging, so checks must come from outside the device.
Diffing only the startup configuration. Changes made to the running configuration and never saved, or reverted after use, are missed.
Shared admin credentials across network and server estates. One stolen domain or jump-host credential then opens every router; v20's M1026 guidance calls this out.
Management services reachable from data interfaces. The advisory's high-port SSH and HTTPS pattern only works when management is not confined to a management VRF.
No owner for peering policy. Interconnects with partners and providers are filtered loosely because no single team owns them.

Framework mapping

Framework	Reference	Why it applies
ATT&CK v20	T1599, T1599.001; TA0112; DET0006, DET0163; M1026, M1027, M1032, M1037, M1043	Technique, sub-technique, detection strategies and mapped mitigations
ATT&CK v20 related	T1090.003 Multi-hop Proxy; T1020.001 Traffic Duplication; T1601 Modify System Image	Techniques ATT&CK names as following or enabling bridging
NIST SP 800-53 Rev 5	SC-7 Boundary Protection; AC-4 Information Flow Enforcement; CM-3 Configuration Change Control; CM-6 Configuration Settings; SI-4 System Monitoring	Boundary policy, its change control and monitoring
NIST CSF 2.0	PR.IR-01; PR.PS-01; DE.CM-01	Network protection, configuration management and network monitoring
MITRE D3FEND	D3-NTA Network Traffic Analysis; D3-ITF Inbound Traffic Filtering	Defensive techniques that describe the flow analysis and filtering above

Related Defense Impairment techniques, each with its own page: MITRE ATT&CK T1686 Disable or Modify System Firewall, MITRE ATT&CK T1690 Prevent Command History Logging.

Practitioner checklist

List every device that enforces a trust boundary, including internal segmentation firewalls.
Automate daily running-configuration diffs for those devices against approved baselines.
Alert on ACL, NAT, route, tunnel, SPAN and AAA server changes outside change control.
Collect flow data from an independent vantage point for each boundary.
Confine management services to a management VRF with default-deny ACLs.
Enforce MFA and TACACS+ command accounting for device administration.
Vault and rotate local passwords, SNMP strings and AAA shared secrets.
Pre-plan which unaffected device enforces M1037 blocks during an incident.

MITRE ATT&CK T1599 Network Boundary Bridging: Detecting Control Tampering