Detecting and Mitigating Hide Infrastructure (MITRE ATT&CK T1665)

Hide Infrastructure (T1665) describes how adversaries conceal their command and control (C2) servers from defenders and researchers. MITRE places it in the Command and Control tactic and lists ESXi, Linux, macOS, Network Devices and Windows as platforms.

The goal is to delay discovery. Infrastructure that is hard to identify, scan or take down stays useful for longer.

How attackers use it

MITRE describes three broad approaches.

Masking the source and destination. C2 networks may use proxies or VPNs to disguise IP addresses and blend in with normal traffic. An adversary may use a virtual private cloud to spoof an IP address that sits closer to the victim's own ranges. That can also get past security controls that depend on geolocation of the source IP.

Filtering who gets to see the server. Adversaries may block or redirect traffic from incident responder or security appliance user agents. Filtering by IP address and geo-fencing can also keep automated sandboxes and researchers away. MITRE links this to Virtualization/Sandbox Evasion (T1497).

Borrowing trust. Resource Development activity such as Acquire Infrastructure (T1583) and Compromise Infrastructure (T1584) can support this. MITRE gives the example of widely trusted hosting services or domains, such as prominent URL shortening providers or marketing services, that make C2 traffic harder to tell from the ordinary.

The technique page records several real patterns, among them proxies built from compromised residential endpoints in the same ISP range as the victim, chains of jump hosts, C2 hostnames set to match legitimate hostnames in the victim environment, and hard-coded domains that masquerade as well-known cloud or CDN services.

How to detect it

MITRE notes this technique cannot be easily mitigated with preventive controls because it abuses normal system features, so detection carries the weight. Its strategy covers several data sources:

• DNS, proxy and user-agent logs. Look for resolutions to short-lived domains, odd WHOIS registration data, and signs that known defensive or responder IP addresses are being filtered.
• Host firewall and proxy settings on Linux. Watch iptables, nftables and proxy configurations that deny or redirect requests from scanning agents or defensive tools.
• macOS unified logs. Look for manipulation of proxy configuration, DNS resolution or filtering rules, and trusted domains that later resolve to malicious C2 infrastructure.
• Network telemetry. Anomalous tunnels, encrypted sessions to suspicious domains, and activity where the source IP does not match the expected geography.
• Virtual machine DNS and network logs. Domains controlled by an adversary, or selective responses such as dropped requests from security scanners.

How to reduce the risk

MITRE offers no formal mitigation entry, since the technique abuses system features. Practical steps follow from the detection guidance:

• Log DNS and proxy traffic centrally and keep it long enough to look back.
• Flag first-seen domains and hosts that talk to them, instead of relying only on known-bad lists.
• Review egress to trusted hosting and URL shorteners from servers that have no reason to use them.
• Alert on changes to proxy, DNS and firewall settings on endpoints.

Check your own environment

• Can you answer which internal hosts contacted a newly registered domain this week?
• Do your servers have a deny-by-default egress policy, or can they reach anything?
• Are DNS and proxy logs forwarded off the host?
• Who is allowed to change local proxy and resolver settings?

Quick check

Sources

• MITRE ATT&CK, Hide Infrastructure (T1665): https://attack.mitre.org/techniques/T1665