T1599.001: Network Address Translation Traversal
Adversaries may bridge network boundaries by modifying a network device’s Network Address Translation (NAT) configuration. Malicious modifications to NAT may enable an adversary to bypass restrictions on traffic routing that otherwise separate trusted and untrusted networks.
Network devices such as routers and firewalls that connect multiple networks together may implement NAT during the process of passing packets between networks. When performing NAT, the network device will rewrite the source and/or destination addresses of the IP address header. Some network designs require NAT for the packets to cross the border device. A typical example of this is environments where internal networks make use of non-Internet routable addresses.[1]
When an adversary gains control of a network boundary device, they may modify NAT configurations to send traffic between two separated networks, or to obscure their activities. In network designs that require NAT to function, such modifications enable the adversary to overcome inherent routing limitations that would normally prevent them from accessing protected systems behind the border device. In network designs that do not require NAT, adversaries may use address translation to further obscure their activities, as changing the addresses of packets that traverse a network boundary device can make monitoring data transmissions more challenging for defenders.
Adversaries may use Patch System Image to change the operating system of a network device, implementing their own custom NAT mechanisms to further obscure their activities.
Analyst context for executives and security teams
Network Address Translation Traversal matters because a compromised router or firewall can be reconfigured to quietly bridge networks that the business believes are separated. For leaders, the issue is not just “a NAT rule changed”; it is whether segmentation, protected access paths, monitoring assumptions, and incident containment plans still hold when a boundary device is under adversary control.
Executive priority
Prioritize this where routers, firewalls, or other boundary devices enforce separation between trusted and untrusted networks, including environments using private address space that requires NAT to cross boundaries. Executives should ask whether NAT changes are governed, logged, reviewed, and tied to named privileged users. This technique is especially relevant to resilience and audit evidence because unauthorized NAT changes can undermine segmentation controls and make traffic monitoring harder to interpret.
Technical view
ATT&CK places this sub-technique under Network Boundary Bridging for Network Devices with a defense-impairment tactic. SOC, IR, and network teams should validate whether NAT configuration changes on routers and firewalls are centrally logged, baselined, and correlated with privileged account activity. Since ATT&CK does not provide official detection text here, use the related detection strategy context conservatively: focus on unauthorized or unexpected NAT translations that permit traffic between separated networks or obscure source/destination visibility.
Likely telemetry
- Network device configuration change logs for NAT, firewall, and routing policy updates
- Privileged authentication and administrative session logs for routers and firewalls
- Configuration backups or rulebase snapshots showing before-and-after NAT state
- Network flow records showing translated source or destination addresses across boundary devices
- Firewall or router traffic logs for ingress, egress, and lateral flows crossing segmented networks
Detection direction
- Baseline approved NAT rules and alert on additions, deletions, or modifications that create new paths between separated networks.
- Correlate NAT changes with privileged account usage, MFA events where available, and approved change windows to reduce false positives from legitimate network operations.
- Review translated traffic patterns for flows that bypass expected segmentation or make monitoring attribution difficult because addresses are rewritten at the boundary.
- Treat boundary-device configuration drift as a detection input, not only a compliance finding, because this technique directly targets the assumptions behind network separation.
- Account for blind spots where devices do not export detailed configuration diffs, where NAT logs are not retained, or where monitoring sees only post-translation addresses.
Mitigation priorities
- Apply privileged account management to network devices: least privilege, role separation, accountable administration, and logging of privileged use.
- Enforce strong password policies and multi-factor authentication for administrative access to boundary devices where supported.
- Protect credentials used to administer routers, firewalls, and other network devices to reduce the chance of unauthorized configuration control.
- Filter network traffic so segmentation policy does not rely on NAT behavior alone; validate ingress, egress, and lateral restrictions against approved business paths.
- Maintain reviewed configuration baselines and change-control evidence for NAT and boundary rules so IR teams can quickly distinguish authorized changes from suspicious drift.
Analyst notes and limits
This object is a sub-technique of T1599 Network Boundary Bridging. The supplied relationships identify mitigations for privileged access, password policy, MFA, network traffic filtering, and credential access protection, plus a related detection strategy DET0163. The practical defensive question is whether the organization can prove that NAT behavior on boundary devices matches intended segmentation policy.
MITRE provides no official detection text for this object in the supplied fields. This take therefore avoids claiming specific detection coverage and depends on local evidence such as device logging capability, configuration management maturity, flow visibility, and change-management quality.
Network Address Translation Traversal
Adversaries may bridge network boundaries by modifying a network device’s Network Address Translation (NAT) configuration. Malicious modifications to NAT may enable an adversary to bypass restrictions on traffic routing that otherwise separate trusted and untrusted networks.
Network devices such as routers and firewalls that connect multiple networks together may implement NAT during the process of passing packets between networks. When performing NAT, the network device will rewrite the source and/or destination addresses of the IP address header. Some network designs require NAT for the packets to cross the border device. A typical example of this is environments where internal networks make use of non-Internet routable addresses.[1]
When an adversary gains control of a network boundary device, they may modify NAT configurations to send traffic between two separated networks, or to obscure their activities. In network designs that require NAT to function, such modifications enable the adversary to overcome inherent routing limitations that would normally prevent them from accessing protected systems behind the border device. In network designs that do not require NAT, adversaries may use address translation to further obscure their activities, as changing the addresses of packets that traverse a network boundary device can make monitoring data transmissions more challenging for defenders.
Adversaries may use Patch System Image to change the operating system of a network device, implementing their own custom NAT mechanisms to further obscure their activities.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1599 | Network Boundary Bridging | This object subtechnique of Network Boundary Bridging. |
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 3ef72728bfe8… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
RFC1918
IETF Network Working Group. (1996, February). Address Allocation for Private Internets. Retrieved October 20, 2020.
Open source URL -
[2]
mitre-attack T1599.001Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.