Network Boundary Bridging (T1599) is listed under the Defense Impairment tactic in MITRE ATT&CK, for the Network Devices platform. The adversary compromises a device that enforces a boundary, and then uses it to let traffic cross that boundary.
Your segmentation is only as strong as the devices that implement it. If someone controls the firewall, the rules on the firewall are whatever they say they are.
How attackers use it
MITRE describes devices such as routers and firewalls creating boundaries between trusted and untrusted networks. They do this by restricting traffic types to enforce organizational policy, through prohibited IP addresses, layer 4 ports, or deep packet inspection to identify applications. The devices can be directly addressable or transparent, and MITRE says their mode of operation has no bearing on how an adversary can bypass them once compromised.
When an adversary takes control of such a device, they can bypass its policy enforcement and pass normally prohibited traffic across the trust boundary without hindrance. With enough rights on the device, they can reconfigure it to allow the traffic they want.
That then supports other goals. MITRE names command and control via Multi-hop Proxy and exfiltration of data via Traffic Duplication. Adversaries may also target internal devices responsible for segmentation and use them with Internal Proxy for the same purposes.
Where a border device separates two organizations, MITRE adds that the adversary can also facilitate lateral movement into new victim environments. That is the concern for managed service providers and partner connections.
The one sub-technique is Network Address Translation Traversal (T1599.001), where the device's NAT configuration is changed.
How to detect it
MITRE's detection strategy is about behavior that contradicts your segmentation or access policy. Observable signs include:
- Sudden changes to access control lists or firewall rules.
- Unusual cross-boundary traffic flows, such as east-west communication across separated VLANs.
- Simultaneous ingress and egress anomalies.
The key idea is multi-event correlation. A configuration change on a router or firewall, followed by unexpected traffic patterns, especially from unusual sources, is a strong indicator.
What to collect:
- Device configuration change logs, and a stored baseline configuration to compare against.
- Management plane login logs, including from where and by whom.
- Flow records at the boundary, so you can see which segments are talking.
An example: if a rule is added at 02:00 by an account that normally works days, and traffic starts flowing from a restricted segment to the internet within the hour, that sequence deserves a human looking at it today.
How to reduce the risk
MITRE lists these mitigations.
- Multi-factor Authentication. Use it for user and privileged accounts. Most embedded network devices support TACACS+ or RADIUS. Follow vendor best practice for access control hardening.
- Password Policies. Follow NIST guidance when creating password policies.
- Privileged Account Management. Restrict administrator accounts to as few people as possible, following least privilege. Prevent credential overlap between administrator and privileged accounts across systems, in particular between network and non-network platforms such as servers or endpoints.
- Credential Access Protection. Some embedded network devices store local account passwords in plain text or encrypted formats. Where available, make sure local passwords are always encrypted, per vendor recommendations.
- Filter Network Traffic. If you identify a compromised device being used to bridge a boundary, block the malicious packets using an unaffected device in the path, such as a firewall or router that has not been compromised. Keep monitoring to confirm the blocks work.
Two simple additions: keep device management on a separate management network, and make sure an out-of-band copy of each device configuration exists so you can compare it with what is running.
Check your own environment
On a Cisco IOS device (read-only, vendor syntax varies, so check your platform's documentation), these commands are a start:
show running-config | section access-list
show ip access-lists
show archive log config all
The last one works only if configuration change logging has been enabled. If it returns nothing, that is itself a finding.
Then review:
- Who can log in to boundary devices, and does each login require a second factor?
- Is the running configuration compared with a stored baseline on a schedule?
- Are changes to rules tied to a ticket?
- Do you have a second device in the path that could block traffic if the first was compromised?
Quick check
Why does MITRE stress correlating events for this technique?
A configuration change alone may be routine, and odd traffic alone may be noise. A change followed by unexpected cross-boundary flows is the strong signal.
What does MITRE say to do once a boundary device is known to be compromised?
Block the malicious packets using an unaffected device in the path, and keep monitoring to make sure the blocks are effective.
