Most intrusions only succeed once a compromised host can talk out: to fetch tools, to reach a command and control server, or to send data away, and outbound traffic filtering is the control that decides whether it can. MITRE D3FEND names this countermeasure Outbound Traffic Filtering (D3-OTF) and defines it as "Restricting network traffic originating from a private host or enclave destined towards untrusted networks." It sits under the Isolate tactic as a child of Network Traffic Filtering (D3-NTF), which in turn sits under Network Isolation (D3-NI). This card covers how egress filtering works, the ATT&CK techniques D3FEND relates to it, where to enforce it on hosts, networks and cloud platforms, how to verify it and where it is bypassed. It is written for network, cloud and endpoint engineers turning an allow-all outbound default into a deliberate policy. The shared design model for all directions is on the D3-NTF Network Traffic Filtering card.
Key takeaways
- The default is open. Windows Firewall allows outbound traffic unless a rule blocks it, AWS security groups ship with an allow-all outbound rule, Azure network security groups allow Internet outbound by default and Google Cloud has an implied allow egress rule.
- D3FEND lists four rule strategies. Block everything by default, limit destination hosts, limit destination transport or application protocols, and restrict outbound content.
- Servers are the easy win. Most servers need a short, known list of outbound destinations, so default-deny egress for server tiers is achievable long before user devices.
- Allowed destinations become the attack path. Filtering pushes attackers to permitted cloud services, proxies and DNS, so egress rules must be paired with inspection and DNS controls.
- Verify with real outbound attempts. A scheduled test that tries blocked destinations and protocols from each tier, and checks the drop is logged, is the only reliable evidence.
D3-OTF at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-OTF (d3f:OutboundTrafficFiltering) |
| Tactic | Isolate |
| Parent technique | Network Traffic Filtering (D3-NTF) |
| Sibling | Inbound Traffic Filtering (D3-ITF) |
| Digital artefact (relation: filters) | Outbound Network Traffic |
| D3FEND examples of outbound traffic | An intranet desktop user connecting to www.example.com; an internal mail server connecting to an external mail server |
| D3FEND implementations | iptables (Linux), Windows Firewall, pf (BSD) |
| D3FEND reference | Microsoft patent "Automatically generating rules for connection security" |
| Main limitation | Permitted destinations and protocols remain usable for command and control and exfiltration |
How it works
D3FEND describes outbound filtering as firewall rule sets that limit the traffic permitted to egress a host or network, deployed either on hosts through kernel-level software or in-line on network links, each with benefits and disadvantages. It lists four strategies for building rule sets, which work best combined:
- Block everything by default: a final deny rule for outbound traffic, with allow rules by exception (NIST SP 800-53 SC-7(5)).
- Limit destination hosts: allow only the addresses, service tags or host names a workload needs, such as update servers, package registries and partner APIs.
- Limit destination transport or application protocols: allow HTTPS through the proxy, DNS only to internal resolvers, SMTP only from mail relays.
- Restrict content outbound: D3FEND's examples are strings formatted as social security numbers or proprietary data, which is data loss prevention territory at a proxy or gateway.
Host and network enforcement complement each other. A host firewall can scope a rule to a program path or service, which a network device cannot see; a network or cloud firewall keeps working when an attacker with administrator rights changes the host's rules.
Where identity fits
Egress rules are one of the few controls that limit a stolen non-human credential after the fact. An API key or cloud token taken from a server is far less useful if that server, and the key's permitted callers, can only reach the services the key is meant for. The same reasoning applies to AI agents calling tools and models; see the Agent Egress Control and Network Isolation Guide.
ATT&CK techniques D3FEND relates to D3-OTF
Relationship type: inferred only. D3FEND has no hand-made ATT&CK mapping for D3-OTF. The D3FEND site derives the relations below because D3-OTF filters Outbound Network Traffic, the artefact each technique uses, and labels them inferred and experimental (checked November 2026). Each ID was checked against ATT&CK v20.
| Tactic | Techniques | Egress control that interferes |
|---|---|---|
| Command and Control | T1071.001 Web Protocols, T1071.002 File Transfer Protocols, T1071.003 Mail Protocols, T1071.004 DNS | Protocol allowlist; DNS only to internal resolvers; SMTP only from relays |
| Command and Control | T1090.002 External Proxy, T1090.003 Multi-hop Proxy, T1090.004 Domain Fronting | Forced proxy with TLS inspection where lawful; block anonymiser categories |
| Command and Control | T1573.001 Symmetric Cryptography, T1573.002 Asymmetric Cryptography | Default deny for unknown destinations and ports |
| Command and Control | T1102 Web Service, T1568 Dynamic Resolution, T1219 Remote Access Tools, T1095 Non-Application Layer Protocol, T1105 Ingress Tool Transfer, T1572 Protocol Tunneling, T1571 Non-Standard Port, T1001, T1008, T1104, T1132 | Destination allowlists, block ICMP and raw protocols outbound, block unapproved remote access tool domains |
| Exfiltration | T1048.001, T1048.002, T1048.003 Exfiltration Over Alternative Protocol; T1567.001 to Code Repository; T1567.002 to Cloud Storage | Block non-business protocols; allow only sanctioned code and storage tenants through the proxy |
| Execution, Persistence, Stealth | T1204.001 Malicious Link; T1197 BITS Jobs | Web filtering; restrict BITS destinations to update sources |
Technique guides on this site: T1071 Application Layer Protocol, T1090 Proxy, T1048 Exfiltration Over Alternative Protocol and T1567 Exfiltration Over Web Service.
Where it is implemented
Cloud platforms are listed alphabetically; the defaults are as each vendor's documentation states them in November 2026.
| Platform | Outbound default | How to move to default deny | Evidence source |
|---|---|---|---|
| AWS security groups | Default outbound rule allows all traffic; stateful | Replace the allow-all outbound rule with specific destinations, prefix lists or proxy addresses | VPC Flow Logs |
| Azure network security groups | AllowInternetOutBound (priority 65001) before DenyAllOutBound (65500); stateful | Add a custom deny for Internet at a lower priority number (custom range 100 to 4096) with allows above it | Network flow logs |
| Google Cloud VPC firewall rules | Implied allow egress; stateful | Add an egress deny rule for 0.0.0.0/0 with higher-priority allows | Firewall rules logging (per rule) |
| Linux hosts | No filtering until rules are loaded | nftables or iptables policy on the output hook, which sees locally generated packets | Log statements to journal |
| Windows hosts | Outbound allowed unless a rule blocks it | Set the profile's outbound action to block and add program or service scoped allow rules through Group Policy or MDM | Event 5157 (Audit Filtering Platform Connection), firewall log |
| Network boundary | Product specific | Zone policy with explicit egress allows and a logged final deny; forward proxy for web | Session and proxy logs |
Two platform notes from the documentation: Azure rule changes apply only to new connections, so existing sessions survive a new deny; and Microsoft advises turning off firewall profiles rather than stopping the MpsSvc service when Windows Firewall must be disabled, so a stopped service is itself an anomaly worth alerting on. Platform detail is in the Cloud Egress Filtering, Windows Defender Firewall Guide and Linux Firewall Guide pages.
Implementation steps
- Collect outbound flows. Use flow logs and proxy logs to list destinations and protocols per workload group for a representative period.
- Start with servers. Define allowlists for server tiers: update sources, registries, time, internal DNS, monitoring and named partner APIs.
- Route web access through a proxy. Allow servers and users to reach the internet on 80 and 443 only via the proxy, and block direct outbound.
- Lock down DNS. Allow DNS (UDP and TCP 53) only to internal or protective resolvers, and set a policy for DNS over TLS (TCP 853) and DNS over HTTPS; see the Encrypted DNS Enterprise Guide.
- Audit, then enforce. Log would-be denies for an agreed period, fix legitimate gaps, then switch the final rule to deny in rings, keeping the prior rule set for rollback.
- Extend to user devices. Apply host outbound rules for high-risk protocols (SMB 445 to the internet, direct SMTP, unsanctioned remote access tools) before attempting full default deny.
- Handle dynamic addressing. D3FEND notes users are not tied to one IP address; link IP address management or identity data to the filtering logic, or use tags and identity-aware rules.
How to verify it works
| Test (run per tier) | Expected result |
|---|---|
| Direct HTTPS to an internet address, bypassing the proxy | Dropped; log shows source host and rule |
| DNS query to an external public resolver on 53, and a DoT connection on 853 | Both dropped |
| Outbound SMB 445 and SMTP 25 from a non-mail host | Dropped |
| Connection on a non-standard port to an allowed provider | Dropped unless explicitly allowed |
| Upload to an unsanctioned cloud storage tenant through the proxy | Blocked or alerted by the proxy policy |
| Allowed destination (for example an update server) | Succeeds, proving the test host is otherwise healthy |
Suggested measures (targets are local choices, not standards): percentage of server workloads with default-deny egress; count of allow-all outbound rules in cloud accounts; percentage of internet-bound web traffic through the proxy; outbound deny volume per tier, investigated when it changes sharply; time to detect a new allow-all outbound rule.
Limits, bypasses and failure patterns
- Permitted services carry command and control. Popular cloud, collaboration and code hosting services are usually allowed, which is why attackers use T1102 Web Service and T1567; restrict to sanctioned tenants where the proxy can see them.
- Non-standard ports. D3FEND warns that connections on non-standard transport ports circumvent filtering that does not identify the application protocol from content.
- DNS as a channel. If any host can resolve any name, DNS tunnelling (T1071.004) survives a strict IP egress policy; combine with D3-DNSDL DNS Denylisting and resolver analytics.
- Allowlist rot. Business requirements drive rule sets, as D3FEND notes, and exceptions accumulate; review allow rules with owners and expiry dates.
- Cloud default rules left in place. A tight rule set in one security group or network security group is undone if another attached group still allows all outbound traffic.
- Host-only enforcement. An attacker with local administrator rights can change host rules (ATT&CK T1686), so keep a network or cloud-layer egress control for servers.
Framework mapping
| Framework | Reference |
|---|---|
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection; SC-7(5) Deny by Default, Allow by Exception; AC-4 Information Flow Enforcement |
| NIST CSF 2.0 | PR.IR-01; DE.CM-01 |
| CIS Controls v8.1 | 4.4 and 4.5 firewalls on servers and end-user devices; 13.10 application layer filtering |
| ISO/IEC 27001:2022 Annex A | A.8.20 Networks security; A.8.23 Web filtering |
| ATT&CK mitigation | M1037 Filter Network Traffic |
Related countermeasures
- Network Traffic Filtering (D3-NTF): the parent. See D3-NTF Network Traffic Filtering.
- Inbound Traffic Filtering (D3-ITF): the sibling. See D3-ITF Inbound Traffic Filtering.
- DNS Allowlisting (D3-DNSAL): the name-resolution equivalent of default-deny egress. See D3-DNSAL DNS Allowlisting.
- Forward Resolution IP Denylisting (D3-FRIDL): blocks lookups that resolve to known bad addresses. See D3-FRIDL Forward Resolution IP Denylisting.
Practitioner checklist
- Replace allow-all outbound defaults on every server security group, network security group and VPC network.
- Force web egress through a proxy and block direct outbound 80 and 443.
- Allow DNS only to approved resolvers and set a DoH and DoT policy.
- Block outbound SMB, direct SMTP and unsanctioned remote access tools from user devices.
- Scope host allow rules to programs or services where possible.
- Give each allow rule an owner and expiry date.
- Log outbound denies to the SIEM and alert on new allow-all rules.
- Run scheduled outbound block tests per tier and keep the evidence.
Standards and references
- MITRE D3FEND: Outbound Traffic Filtering (D3-OTF)
- NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-7)
- AWS: Control traffic to your AWS resources using security groups
- Microsoft Learn: Azure network security groups overview
- Google Cloud: VPC firewall rules
- Microsoft Learn: Windows Firewall overview
- nftables wiki: Netfilter hooks
Related NHI Mgmt Group resources: Cloud Egress Filtering · Host-Based Firewall Guide · Protective DNS Guide · MITRE D3FEND Guide