AN0926: Analytic 0926
Changes to NAT/firewall policies enabling outbound port forwarding from internal IPs to Internet-based proxy endpoints. Log spikes in outbound flows to CDN, VPS, or anomalous ASNs with few return packets.
Analyst context for executives and security teams
This analytic matters because changes to NAT or firewall policy can quietly turn network infrastructure into an outbound forwarding path from internal systems to Internet proxy endpoints. For leaders, the decision value is whether network-device change monitoring and outbound-flow visibility are strong enough to show when policy changes create unexpected external paths, especially to CDN, VPS, or unusual autonomous-system destinations with little meaningful return traffic.
Executive priority
Prioritize this as a network control-governance and SOC visibility issue. The business question is not just whether firewalls exist, but whether teams can prove who changed forwarding policy, why it changed, and whether resulting outbound traffic patterns are expected. This supports incident decision-making, audit evidence for change control, and resilience against misuse of network egress paths. Because ATT&CK supplies no tactic or relationship context for this analytic, priority should be calibrated against local exposure: number of managed network devices, frequency of NAT/firewall changes, and current egress monitoring maturity.
Technical view
Validate coverage on Network Devices for two evidence streams: configuration changes to NAT/firewall rules that enable outbound port forwarding from internal IPs, and outbound flow behavior showing spikes toward CDN, VPS, or anomalous ASN destinations with few return packets. SOC and detection engineering teams should correlate policy-change events with subsequent flow changes from affected internal IPs. Since no official detection logic is provided, local baselining is required to distinguish approved egress changes, load-balanced services, cloud migrations, or content-delivery traffic from suspicious policy-driven forwarding behavior.
Likely telemetry
- Network device configuration-change logs for NAT, firewall, and port-forwarding policy updates
- Administrator identity, source, timestamp, and change-ticket context for network-device modifications
- Firewall or router traffic logs showing outbound flows from internal IPs
- NetFlow/IPFIX or equivalent flow metadata including destination IP, port, byte and packet counts, and return traffic volume
- Destination enrichment such as ASN, hosting provider, CDN, VPS, or reputation/category context
Detection direction
- Alert or hunt on NAT/firewall policy changes that newly enable outbound port forwarding from internal IP ranges to Internet destinations.
- Correlate rule changes with post-change spikes in outbound flows to CDN, VPS, or locally anomalous ASNs, especially where return packets are low.
- Baseline expected CDN, cloud, and hosting-provider traffic to reduce false positives from legitimate application delivery, software updates, and business-approved cloud services.
- Tune detections around high-risk change conditions: no matching change ticket, unusual administrator account, unexpected device, nonstandard time window, or affected internal IPs not associated with approved services.
- Confirm telemetry is collected from the relevant Network Devices; endpoint-only monitoring will not reliably capture the policy-change aspect of this analytic.
Mitigation priorities
- Strengthen change control for NAT/firewall policy updates, including approval, documentation, and post-change review.
- Require centralized logging for network-device configuration changes and outbound flow records before relying on this analytic operationally.
- Restrict who can modify NAT/firewall and port-forwarding policies, and review privileged network-device access regularly.
- Maintain an inventory of approved outbound forwarding rules and expected external destinations, including CDN, VPS, and cloud-hosting dependencies.
- Use egress governance to limit unnecessary outbound forwarding from internal IPs and to make exceptions explicit and reviewable.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, AN0926, for Network Devices. Its value is in combining control-plane evidence, such as NAT/firewall policy changes, with data-plane evidence, such as outbound flow spikes to Internet infrastructure. There are no supplied relationships, tactics, aliases, or formal detection logic, so the take intentionally focuses on validation questions and evidence classes rather than asserting specific adversary behavior.
This assessment is constrained to the supplied official STIX fields and external reference. ATT&CK provides no official detection section, no tactic mapping, and no relationship context for this object. Local network architecture, approved egress patterns, device logging quality, and change-management data are required to determine severity and detection feasibility.
Analytic 0926
Changes to NAT/firewall policies enabling outbound port forwarding from internal IPs to Internet-based proxy endpoints. Log spikes in outbound flows to CDN, VPS, or anomalous ASNs with few return packets.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 1.0 | Current bundle | a35b412e1269… |
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]
mitre-attack AN0926Open 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.