Adversary infrastructure is built to look harmless to the people and tools that check it: scanners get a 404, sandboxes get nothing, and your sign-in logs show a home broadband address in your own city. MITRE ATT&CK v20 tracks this as T1665 Hide Infrastructure, a Command and Control technique on Windows, Linux, macOS, ESXi and network devices. It covers filtering traffic from defensive tools, masking malicious domains from scanners and researchers, using proxies and VPNs to blend with normal traffic and bypass conditional access or geolocation checks, and borrowing trusted services such as URL shorteners and marketing platforms that later redirect to malicious infrastructure. This guide covers the procedure examples ATT&CK records, what defenders can actually observe, the v20 detection strategy, practical controls and how to test them. It is for SOC, threat intelligence, email security and identity teams. For proxy chains specifically see the T1090 Proxy Defensive Guide; for C2 overall, the Command and Control (C2) Guide.
Key takeaways
- The goal is to fail your checks quietly. Hide Infrastructure is less about encryption than selection: who gets the real content, and who gets a harmless page.
- Location is no longer evidence. ATT&CK records APT29 using residential endpoints in the same ISP range as the victim, and Quad7 Activity rotating compromised small office router addresses.
- Trusted services front malicious ones. Microsoft reports Star Blizzard hiding domains behind email marketing platform links, link shorteners and open redirects before an Evilginx server.
- Identity controls carry the most weight. Phishing-resistant MFA and device-bound access remove the value of a clean-looking IP address and a convincing redirect chain.
- Detection needs your own vantage points. Detonation from realistic, rotating egress, click-time URL analysis and internal telemetry see what external scanners are deliberately denied.
How adversaries hide infrastructure
| Method | What it does | Examples recorded in ATT&CK v20 or cited sources |
|---|---|---|
| Filtering defenders | Serves real content only to intended targets; scanners, sandboxes and researchers get errors or decoys by IP, geography, user agent or browser checks | TA571 gates using IP filtering and geofencing (Proofpoint); Star Blizzard server-side checks for automation tools such as Selenium and PhantomJS (Microsoft); SocGholish filtering cited in the technique |
| Blending source addresses | Routes traffic through residential proxies, VPNs, cloud regions or compromised devices near the victim | APT29 using compromised residential endpoints in the victim's ISP range and, in the SolarWinds compromise, VPN IPs from the victim's country; Quad7 Activity rotating SOHO IPs during password spraying; ZIRCONIUM using an ORB network |
| Chaining hops | Uses chains of jump hosts or devices so the operator never connects directly | JumbledPath using a chain of jump hosts to reach compromised devices |
| Masquerading names | Gives C2 hosts and domains names that match the victim or well-known services | APT29 setting C2 hostnames to match legitimate hostnames in the victim environment; DarkGate hard-coding domains that imitate Akamai CDN or Amazon Web Services |
| Borrowing trusted platforms | Uses public cloud, URL shorteners, marketing services or reverse proxy DNS to present benign content first | Operation Digital Eye using public cloud infrastructure; Star Blizzard using HubSpot and MailerLite generated subdomains and a reverse proxy DNS provider (Microsoft) |
| Hiding commands in errors | Puts C2 inside responses that look like failures | UPSTYLE requesting a non-existent page and receiving hidden commands in the resulting error message |
T1665 depends on Resource Development: T1583 Acquire Infrastructure and T1584 Compromise Infrastructure supply the domains, VPS, cloud accounts and hijacked devices, and filtering researchers overlaps with T1497 Virtualization/Sandbox Evasion. See T1583 Acquire Infrastructure, T1584 Compromise Infrastructure and MITRE ATT&CK T1497 Virtualization/Sandbox Evasion. AI crawlers and agents can be cloaked against in the same way; see AML.T0134 AI Targeted Cloaking.
Cases worth knowing
- Salt Typhoon and JumbledPath: the Salt Typhoon telecom intrusions analysis, based on Cisco Talos research, describes access mostly through stolen network device credentials, movement from one telecom's devices into another's, and JumbledPath capturing packets across chains of devices while clearing logs, with access lasting more than three years in one case. ATT&CK records JumbledPath's jump host chains under T1665.
- Star Blizzard: Microsoft's December 2023 report, updated into 2025, describes redirector servers running scripts that detect automation before deciding whether to continue a redirect, campaign subdomains on email marketing platforms, a DNS provider acting as a reverse proxy to mask VPS addresses, and, in 2024, domains spread across registrars, chained link shorteners and open redirects. Microsoft notes the actor abandons techniques once they are made public.
- TA571: Proofpoint's October 2023 report describes 404 TDS URLs and up to two gates per campaign that filtered by IP address and geofencing and validated recipients, so only targeted users received the payload and sandboxes and researchers did not.
- APT29: ATT&CK records the group using residential proxies in the victim's ISP range and, during the SolarWinds compromise, hostnames matching the victim's own. See the APT29 (Midnight Blizzard) Threat Actor Profile.
What to detect and where
ATT&CK v20 ships one detection strategy, DET0411. Its analytics cover Windows (connection events 5156 and 5157 with DNS data on short-lived domains, unusual registration data or short TTLs), Linux (iptables or nftables changes that block selected IPs, and responses altered by user agent or geography), macOS (changes to DNS or proxy settings), network devices (tunnels and proxy traffic to unusual destinations and geography mismatches) and ESXi (VM-level DNS to rapidly changing domains and selective dropping of scanner traffic). Much of T1665 happens on the adversary's side, so the practical question is which parts touch your telemetry.
| Observable | Where you see it | Practical use |
|---|---|---|
| Sign-ins from residential, VPN or anonymising addresses near your users, with new devices | Identity provider logs, SaaS audit logs | Pair IP reputation with device and session signals; never trust location alone |
| Different content for your sandbox and for a user, or URLs that return 404 to scanners | Email security, URL detonation, proxy logs | Detonate from realistic egress and user agents; revisit URLs at click time |
| Redirect chains through shorteners, marketing platforms or open redirects ending at a young domain | Proxy logs, email gateway URL rewriting, browser telemetry | Score the final destination, not the first hop |
| C2 hostnames or certificates imitating your naming convention or a major CDN | DNS, TLS SNI and certificate logs, Certificate Transparency | Watch for look-alikes of your own host and brand names |
| Host firewall rules that block security vendor or responder ranges | Linux auditd, configuration management, EDR | Matches the v20 Linux analytic; also catches tampering on your own servers used as infrastructure |
| Your own routers, cameras or servers relaying third-party traffic | Flow logs for device segments | Prevents your estate becoming someone else's hiding place |
Supporting guides: the Operational Relay Box Networks Guide, the Newly Registered Domains Guide, the Certificate Transparency Monitoring Guide for Web Teams and the SocGholish and Fake Browser Update Malware Guide.
Mitigations and practical controls
ATT&CK v20 lists no mitigation object for T1665, because most of the behaviour happens on infrastructure the defender does not own. The controls below are NHI Mgmt Group recommendations drawn from the cited vendor and government reporting.
- Bind access to identity and device, not network location: phishing-resistant MFA and compliant device requirements, as Microsoft recommends for Star Blizzard, defeat both residential proxies and Evilginx-style adversary-in-the-middle pages. See the Phishing-Resistant MFA Guide.
- Restrict non-human identities by network and workload: API keys, service accounts and integration tokens should be usable only from known egress ranges or through workload identity, since they cannot do interactive MFA.
- Analyse URLs at click time and from realistic vantage points: rewrite links, re-check at click, and run detonation from rotating residential-like egress with ordinary browser fingerprints so gates see a plausible target.
- Treat trusted-platform links as untrusted until resolved: follow shorteners, marketing redirects and open redirects to the final destination before scoring.
- Filter and inspect egress: block uncategorised and newly registered destinations for servers and route user traffic through logging proxies. See M1037 Filter Network Traffic and M1021 Restrict Web-Based Content.
- Do not become infrastructure: patch or retire end-of-life edge devices and rotate network device credentials and SNMP strings, the lesson of the Salt Typhoon intrusions. See the Edge Device Security Guide.
- Report abuse: notify platforms, registrars and reverse proxy providers; Microsoft reported that the DNS provider Star Blizzard used took action once notified.
Rolling it out and testing
- Run conditional access rules that block anonymous and high-risk network sign-ins in report-only mode for two weeks, then enforce for administrators and service accounts first, keeping the previous policy for rollback.
- Compare sandbox verdicts from your current egress with verdicts from a residential-style egress on a sample of suspicious URLs; a gap shows how much cloaking you miss.
- In an authorised exercise, send test phishing through a shortener and a redirect chain to a test domain you own and confirm the gateway resolves and scores the final hop.
- Test the Linux analytic by adding a benign firewall rule in a lab and confirming the alert.
Choosing an approach: small organisations should start with phishing-resistant MFA, device compliance and a secure email gateway with click-time protection. Large organisations should add multi-vantage detonation, look-alike domain and certificate monitoring, and intelligence that tracks proxy networks and redirect services as entities.
Detection and measurement
- Location-independent access: share of users, administrators and service accounts protected by phishing-resistant MFA or workload identity.
- Cloaking gap: percentage of suspicious URLs whose verdict changes between standard and residential-style detonation.
- Redirect resolution: share of inbound links resolved to the final destination before delivery or click.
- Look-alike detection time: time from certificate issuance or domain registration of a look-alike to alert.
- Edge hygiene: number of end-of-life internet-facing devices, trending to zero.
Common failure patterns
- Trusting geolocation: "same country, same ISP" rules pass attacker traffic that was built to match them.
- Sandboxing from a data centre range: gates recognise it and serve nothing, and the URL is marked clean.
- Scoring only the first hop: a trusted shortener or marketing domain carries the reputation of the platform, not the destination.
- Static IP blocklists: rotating SOHO and residential addresses make them stale within days and risk blocking real customers.
- Unmanaged edge devices: your own routers and appliances join relay chains, as the Salt Typhoon analysis shows for telecom networks.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK v20 | T1665; DET0411; related T1090, T1583, T1584, T1497 | Technique, detection strategy, enabling techniques |
| MITRE D3FEND (related techniques) | D3-UGLPA User Geolocation Logon Pattern Analysis; D3-RPA Relay Pattern Analysis; D3-DNRA Domain Name Reputation Analysis | Logon location patterns, relay behaviour, domain reputation |
| NIST SP 800-53 Rev. 5 | SC-7(5); SC-7(8); SI-4(4); SI-4(13) | Egress control, proxies, traffic and event pattern analysis |
| NIST CSF 2.0 | DE.CM-01; DE.AE-02; PR.IR-01 | Monitor, analyse, protect networks |
| CIS Controls v8.1 | 9.3 Maintain and Enforce Network-Based URL Filters; 6.5 Require MFA for Administrative Access | URL filtering and strong authentication |
| ISO/IEC 27001:2022 Annex A | 5.7 Threat intelligence; 8.23 Web filtering; 8.16 Monitoring activities | Intelligence, filtering, monitoring |
Practitioner checklist
- Enforce phishing-resistant MFA and device compliance, starting with administrators.
- Restrict service accounts and API keys to known egress ranges or workload identity.
- Resolve redirect chains and re-check URLs at click time.
- Detonate suspicious URLs from realistic, rotating egress and compare verdicts.
- Monitor look-alike domains and certificates for your hostnames and brands.
- Alert on host firewall changes that block selected IP ranges.
- Retire or patch end-of-life edge devices and rotate device credentials.
- Expire proxy IP indicators automatically and track infrastructure as entities.
Standards and references
- MITRE ATT&CK: Hide Infrastructure (T1665)
- MITRE ATT&CK: Proxy (T1090)
- Microsoft: Star Blizzard increases sophistication and evasion in ongoing attacks
- Proofpoint: TA571 Delivers IcedID Forked Loader
- Cisco Talos: Weathering the storm, Salt Typhoon analysis
- MITRE D3FEND: Relay Pattern Analysis
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: ATT&CK Command and Control Tactic · Operational Relay Box Networks Guide · Salt Typhoon Threat Actor Profile · MITRE ATT&CK T1078 Valid Accounts Guide · MITRE ATT&CK T1568 Dynamic Resolution · MITRE ATT&CK T1573 Encrypted Channel · MITRE ATT&CK T1104 Multi-Stage Channels