DET0075: Internal Proxy Behavior via Lateral Host-to-Host C2 Relay
This detection strategy matters because internal proxy behavior can let an intruder relay command-and-control traffic through already compromised systems i...
Analyst context for executives and security teams
This detection strategy matters because internal proxy behavior can let an intruder relay command-and-control traffic through already compromised systems instead of communicating directly from every host to the internet. For leaders, the key issue is whether the organization can see unusual host-to-host relay patterns inside the environment, not only north-south internet traffic.
Executive priority
Prioritize validation of internal network visibility and incident response playbooks for command-and-control scenarios. If monitoring is focused only on perimeter egress, teams may miss lateral C2 relay activity that affects containment decisions, evidence collection, and business continuity during an intrusion.
Technical view
DET0075 is a detection strategy for ATT&CK T1090.001 Internal Proxy under command and control. Because the object has no official detection text and no platforms of its own, validation should be tied to the related technique context: internal host-to-host traffic that appears to relay C2 communications across compromised systems, including environments involving ESXi, Linux, macOS, and network devices where those platforms are in scope locally.
Likely telemetry
- Internal network flow records showing host-to-host connections
- Firewall, proxy, and network device logs for east-west and egress traffic
- DNS and outbound connection metadata from internal systems
- Endpoint network connection telemetry where available
- Authentication and asset context to identify whether communicating hosts normally interact
Detection direction
- Confirm whether monitoring covers east-west traffic, not just internet-bound egress.
- Look for internal systems acting as unexpected relay points between other hosts and external destinations.
- Baseline normal host-to-host communication so high-volume administrative, backup, monitoring, or proxy services do not create excessive false positives.
- Correlate network observations with endpoint process and asset role context where available.
- Treat detections as triage leads: the supplied ATT&CK object does not provide a specific analytic, threshold, or guaranteed detection method.
Mitigation priorities
- Improve network segmentation and restrict unnecessary host-to-host connectivity.
- Limit outbound access to approved systems and destinations where business operations allow.
- Ensure network devices, servers, and virtualization environments have logging sufficient for relay-path reconstruction.
- Prepare IR procedures to identify pivot hosts, map communication paths, and contain without disrupting critical services unnecessarily.
- Use detection validation exercises to confirm SOC visibility across internal relay scenarios.
Analyst notes and limits
The strongest decision point is coverage: can the SOC reconstruct internal relay paths during command-and-control investigations? This object is useful for assessing detection engineering gaps around Internal Proxy behavior, but implementation must be adapted to local topology, asset roles, and logging sources.
The supplied ATT&CK detection strategy has no official description, no official detection text, no tactics, and no platforms listed for the strategy itself. Platform and tactic context comes from the relationship to T1090.001 Internal Proxy. No active exploitation, actor attribution, or detection efficacy is asserted.
Internal Proxy Behavior via Lateral Host-to-Host C2 Relay
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.001 | Internal Proxy Sub-technique | This object detects Internal 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 | ecd42f746f50… |
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 DET0075Open 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.