T1584 Compromise Infrastructure: Defending Against Hijacked Routers, Domains and ORBs

Attackers increasingly avoid buying their own servers: they hijack other people's routers, websites, DNS records and cloud resources, so their traffic arrives from addresses and domains your controls already trust, and some of that hijacked infrastructure may be yours. MITRE ATT&CK tracks this as T1584 Compromise Infrastructure, a Resource Development (TA0042) technique with eight sub-techniques: domains, DNS servers, virtual private servers, servers, botnets, web services, serverless and network devices. The defender job has two halves. Outward, you need to recognise traffic from compromised edge devices and operational relay box (ORB) networks. Inward, you need to make sure your own subdomains, DNS, edge devices and web servers do not become someone else's attack infrastructure. This guide is for SOC, threat intelligence, network and cloud platform teams. For the tactic overview, see the ATT&CK Resource Development Tactic Guide.

Key takeaways

• Your assets can be the infrastructure. A dangling CNAME, an end-of-life router or an unpatched web server you own can be hijacked under T1584 and used against your customers, partners or other victims.
• ORB networks defeat IP reputation. Volt Typhoon used hundreds of hijacked end-of-life Cisco and NETGEAR SOHO routers (the KV botnet) to hide its origin, so attacker traffic came from ordinary residential and small business addresses.
• Prevention is mostly hygiene on your own estate. ATT&CK v20 lists only M1056 Pre-compromise and says the technique cannot easily be mitigated with preventive controls; the controls that work are replacing end-of-life devices, removing dangling DNS and locking registrar accounts.
• Detect by behaviour, not by source. Sign-ins and admin actions from residential or geographically close addresses look normal; correlate on impossible combinations, new device fingerprints and credential use instead.
• Takedown is a partnership. The KV botnet disruption needed a court-authorised operation, and DOJ noted the fixes are reversed by a router restart, so replacement, not cleanup, is the lasting answer.

What T1584 covers in ATT&CK v20

ATT&CK v20 (technique version 1.6) describes adversaries compromising third-party infrastructure (physical or cloud servers, domains, network devices, and web and DNS services) instead of buying, leasing or renting it. The description notes that compromised infrastructure helps operations blend in with traffic seen as normal, can support proxy and proxyware services or botnets, and can be chosen for physical proximity to a target to gain access through T1669 Wi-Fi Networks.

Buying or renting infrastructure, including leasing an ORB network someone else built, is the sibling technique T1583 Acquire Infrastructure. The MITRE ATLAS counterpart for AI systems is AML.T0128 Compromise Infrastructure. Using compromised infrastructure to disguise traffic is covered under T1090 Proxy Defensive Guide and T1665 Hide Infrastructure.

Real cases

Volt Typhoon and the KV botnet

On 31 January 2024 the US Department of Justice announced that a court-authorised operation in December 2023 had disrupted the KV botnet: hundreds of US-based SOHO routers hijacked by the PRC state-sponsored actor known as Volt Typhoon and used to conceal the origin of further hacking, including against US critical infrastructure. DOJ stated that the vast majority were Cisco and NETGEAR routers that had reached end of life and no longer received security patches. The operation deleted the malware and blocked communication with the botnet's controllers, but DOJ noted those steps are temporary and a router restart reverses them, and advised owners to replace end-of-life routers. ATT&CK v20 adds that Volt Typhoon used SOHO devices often located in the same geographic area as the victim, which defeats location-based anomaly rules. See the Volt Typhoon Threat Actor Profile and the Operational Relay Box Networks Guide.

Salt Typhoon and network devices as pivot points

The Salt Typhoon Telecom Intrusions 2025 breach page, based on Cisco Talos analysis published in February 2025, shows compromised routers used as infrastructure inside and between telecom networks. Stolen legitimate device credentials were the initial access route in nearly every case investigated; the group then harvested configurations, captured SNMP, TACACS and RADIUS traffic for more secrets, and moved device to device, including from one telecom's device into another's. The non-human credential lesson is direct: SNMP community strings, AAA shared secrets and local device accounts are machine credentials that turned a router into reusable attack infrastructure. See the Salt Typhoon Threat Actor Profile.

Subdomain takeover of your own names

ATT&CK's T1584.001 description covers subdomain hijacking where DNS entries point to non-existent or deprovisioned resources. Microsoft's guidance on Azure explains the impact: once an attacker claims the deprovisioned resource name, they control content on your subdomain, can obtain a valid TLS certificate for it, can harvest session cookies scoped to the parent domain, and with MX records could receive email sent to it. That is phishing and session theft from a domain your users and your allowlists trust. See the Subdomain Takeover and Dangling DNS Guide.

Signals: seeing compromised infrastructure in use

ATT&CK v20 detection strategies for T1584 (DET0885 for the parent, DET0863 for domains, DET0859 for network devices, plus strategies for each other sub-technique) rely on internet scan data, domain registration data and passive and active DNS, and note that much of this activity is outside the target's visibility. DET0863 adds that subdomain IP addresses that look abnormal, such as originating in a different country from the root domain, may indicate a malicious subdomain created through domain shadowing. The table maps these to what a SOC can actually monitor; the right-hand column is NHI Mgmt Group guidance.

Reducing exposure: controls on your own estate

These are NHI Mgmt Group recommendations built on the sources above. They focus on making your infrastructure hard to compromise and on recognising other people's compromised infrastructure.

• Replace end-of-life edge devices: DOJ's KV botnet guidance is to remove and replace end-of-life SOHO routers, including those used by home workers and small branches with corporate access. Track device end-of-life dates in the asset inventory; see the End-of-Life Home Routers Guide and the Edge Device Security Guide.
• Eliminate dangling DNS: Microsoft recommends Azure DNS alias records, which become empty record sets when the target resource is deleted; the asuid.{subdomain} TXT domain verification record for App Service so no other subscription can validate the custom domain; delete locks on resources with custom DNS entries; and a "Remove DNS entry" step in decommissioning. Microsoft Defender for App Service includes dangling DNS detection, and Microsoft publishes the Get-DanglingDnsRecords PowerShell tool for inventory. Apply the same principle on every cloud and CDN you use.
• Lock registrar and DNS hosting accounts: phishing-resistant MFA, registrar and registry locks on key domains, role-separated access and no shared mailbox as the owner contact. See the Domain Registrar Compromise Playbook.
• Protect device credentials as NHIs: rotate SNMP community strings and AAA shared secrets, move to SNMPv3, remove weak local password types, and manage device admin accounts through central authentication with MFA, as the Salt Typhoon lessons recommend.
• Harden public web servers and CMS: patch quickly, remove unused plugins, use file integrity monitoring and restrict admin interfaces, so your site does not become a watering hole or C2 relay.
• Do not rely on IP reputation alone: ORB traffic comes from clean residential addresses. Use phishing-resistant MFA, device compliance checks in access policies so that a correct password from a new address is still not enough. See the Residential Proxy Networks and Abuse Guide.

Where identity fits

Compromised infrastructure is mainly a way to use stolen identities without being noticed. Password spraying from Quad7 routers, token replay through residential addresses close to the victim, and device admin logins with stolen credentials all turn on identity. Two NHI angles are specific to T1584. First, the credentials that control infrastructure (registrar API keys, DNS provider tokens, cloud roles that can create or delete DNS records, router SNMP and AAA secrets) are high-value non-human identities and should be inventoried, scoped and rotated like any other privileged secret. Second, when infrastructure is decommissioned, the identities and DNS records tied to it must be removed together; an orphaned record or key is how your asset becomes someone else's. See the Cloudflare API tokens security guide for one DNS provider's token model.

Responding when your infrastructure is the one compromised

1. Contain the asset. For a taken-over subdomain, remove or repoint the DNS record first, then revoke any certificates issued for it. For a compromised edge device, isolate it and fail over before investigating.
2. Preserve evidence. Export DNS zone history, registrar audit logs, CT entries, device configurations and AAA logs before changes overwrite them. See the Edge Device Compromise Investigation Playbook.
3. Rotate exposed secrets. Device passwords, SNMP strings, AAA secrets, registrar and DNS API keys, and any session cookies scoped to the affected domain.
4. Replace rather than clean where support has ended. As DOJ noted for the KV botnet, remediated end-of-life routers remain vulnerable to reinfection.
5. Report. Notify your national CERT or law enforcement where state-sponsored use is suspected (DOJ pointed router owners to the FBI's IC3 and CISA), and tell affected partners.
6. Close the process gap. Add the missing step (DNS cleanup on decommission, EOL replacement, registrar lock) to the change process and verify it on the next decommission.

Measuring it

• Dangling records: number of DNS records pointing at unclaimed or deleted resources across all zones (target zero, checked weekly).
• End-of-life edge exposure: count of internet-facing or corporate-connected routers, VPNs and appliances past vendor end of support.
• Registrar protection: percentage of critical domains with registry or registrar lock and phishing-resistant MFA on the account.
• Device credential hygiene: percentage of network devices on SNMPv3 and central AAA with no shared or weak local passwords.
• Time to remediate takeover: median time from detection of a hijacked subdomain to record removal.

Common failure patterns

• Decommissioning the resource but not the DNS record. The cloud app is deleted, the CNAME stays, and the name becomes available to anyone who claims the resource.
• Treating home and branch routers as out of scope. The KV botnet was built from end-of-life SOHO routers; any of them carrying corporate traffic is part of your attack surface.
• Trusting geography. Volt Typhoon used devices near the victim, so "sign-in from the same city" rules let it through.
• Static device secrets. As in the Salt Typhoon Telecom Intrusions 2025, unrotated SNMP strings and AAA secrets turn one router compromise into many.
• No owner for registrar accounts. The domain owner contact is a former employee's mailbox, which ATT&CK describes as a route to registration hijacking.

Framework mapping

Practitioner checklist

• Scan every DNS zone weekly for records pointing to deleted or unclaimed cloud resources and remove them.
• Add "remove DNS records and keys" to every decommissioning runbook.
• Replace end-of-life routers and edge devices that carry corporate traffic, including home-worker devices where you supply them.
• Apply registrar locks and phishing-resistant MFA to registrar and DNS hosting accounts; review owner contacts.
• Rotate SNMP and AAA secrets, move to SNMPv3 and central AAA, and alert on new device accounts or SSH keys.
• Monitor CT logs for certificates on your own subdomains you did not request.
• Correlate identity signals beyond IP reputation to catch ORB and residential proxy sources.
• Subscribe to government and vendor ORB and C2 indicator feeds and check whether your own IPs appear.

Standards and references

• MITRE ATT&CK: T1584 Compromise Infrastructure
• MITRE ATT&CK: T1584.001 Domains
• MITRE ATT&CK: T1584.008 Network Devices
• US Department of Justice: U.S. Government Disrupts Botnet People's Republic of China Used to Conceal Hacking of Critical Infrastructure
• Microsoft Learn: Prevent dangling DNS entries and avoid subdomain takeover
• MITRE ATT&CK: M1056 Pre-compromise
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Operational Relay Box Networks Guide · Residential Proxy Networks and Abuse Guide · Subdomain Takeover Response Playbook · Volt Typhoon Threat Actor Profile · Edge Device Exploitation by Threat Actors Guide