DET0325: External Proxy Behavior via Outbound Relay to Intermediate Infrastructure
DET0325 is a detection strategy for identifying behavior where outbound traffic is relayed through intermediate external infrastructure, associated with AT...
Analyst context for executives and security teams
DET0325 is a detection strategy for identifying behavior where outbound traffic is relayed through intermediate external infrastructure, associated with ATT&CK technique T1090.002 External Proxy. The business concern is not simply “proxy use”; it is that command-and-control traffic may be intentionally routed through third-party or intermediary systems to make direct adversary infrastructure harder to see, block, or attribute. For leaders, this makes egress visibility, proxy governance, and incident response evidence quality important to operational resilience.
Executive priority
Prioritize validating whether the organization can explain unusual outbound relay patterns across relevant environments, especially where Linux, macOS, ESXi, or network devices are in scope from the related technique. This supports incident decision-making, managed detection quality, audit evidence for network monitoring controls, and risk discussions about gaps in egress logging. Because the ATT&CK object has no official detection text or platform list of its own, leadership should treat this as a coverage-validation prompt rather than proof that current tooling detects the behavior.
Technical view
SOC and detection teams should map DET0325 to T1090.002 External Proxy under command-and-control context. Validate whether telemetry can show hosts or network devices making outbound connections to intermediate infrastructure that appears to relay traffic rather than communicate directly with expected services. Focus on evidence that connects source asset, destination, timing, volume, protocol, and any proxy or firewall decision logs. Tuning should distinguish sanctioned proxy, VPN, CDN, and remote administration patterns from unusual relay behavior, especially when the same destination or connection pattern is rare for the asset or environment.
Likely telemetry
- Firewall and secure web gateway outbound connection logs
- Proxy logs showing source, destination, method, user or device identity where available
- NetFlow or equivalent network flow records
- DNS query and response logs for destinations involved in outbound communications
- IDS/IPS or network detection alerts related to command-and-control or proxy-like behavior
Detection direction
- Confirm that outbound egress monitoring covers the environments relevant to the related technique: ESXi, Linux, macOS, and network devices, where applicable locally.
- Baseline approved proxy, VPN, remote access, CDN, and business relay services before escalating proxy-like outbound traffic.
- Look for rare or anomalous external destinations, unusual ports or protocols, repeated beacon-like connections, or traffic patterns inconsistent with the asset’s role.
- Correlate network telemetry with asset inventory and identity context so analysts can separate sanctioned infrastructure from suspicious relays.
- Review blind spots where direct internet egress, unmanaged network devices, encrypted traffic, or incomplete DNS/proxy logging could hide intermediary communications.
Mitigation priorities
- Establish or validate egress control policy so systems use approved outbound paths rather than arbitrary external relays.
- Ensure proxy, firewall, DNS, and flow logging are retained and searchable for incident response timelines.
- Restrict and monitor direct outbound internet access from servers, virtualization infrastructure, and network devices where business operations allow.
- Maintain asset ownership and expected-communication baselines to support fast triage of unusual relay behavior.
- Use incident response playbooks that preserve network evidence and quickly determine whether an observed proxy path is sanctioned, misconfigured, or suspicious.
Analyst notes and limits
The supplied ATT&CK detection-strategy object has no official description, no official detection text, no tactics, and no platforms. The only behavioral context comes from its relationship to T1090.002 External Proxy, which describes adversaries using intermediary proxies or traffic redirection to avoid direct command-and-control connections. Treat this take as defensive validation guidance derived from that relationship, not as a complete MITRE-authored analytic.
No active exploitation, attribution, impact, or guaranteed detection coverage is stated or implied. Platform references come from the related T1090.002 technique, not from DET0325 itself. Local architecture, sanctioned proxy use, logging coverage, and business-approved relay services must be reviewed before determining risk or detection quality.
External Proxy Behavior via Outbound Relay to Intermediate Infrastructure
No official description is available in the imported ATT&CK source object.
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.
Techniques used
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 | T1090.002 | External Proxy Sub-technique | This object detects External Proxy. |
All related ATT&CK context
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 | 346600b99377… |
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 DET0325Open 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.