Safeguard
Application Security•

Compromised Third-Party Infrastructure: T1584 Guide for Defenders

MITRE T1584 describes adversaries compromising other people servers, domains and devices. Learn what to watch for and how to keep yours off the list.

Safeguard Security Team
6 min read

Compromise Infrastructure (T1584) is a resource development technique. MITRE tags it PRE, since it happens before the target is engaged. It has eight sub-techniques: Domains, DNS Server, Virtual Private Server, Server, Botnet, Web Services, Serverless and Network Devices.

Think of it as the opposite of Acquire Infrastructure. The adversary does not pay for anything. They take what someone else already runs.

There is a second reading that matters for you. Every organization is a possible supplier of compromised infrastructure to somebody else. A forgotten server of yours is another group's launch pad.

How attackers use it

MITRE describes the infrastructure as physical or cloud servers, domains, network devices, and third-party web and DNS services. Instead of buying, leasing or renting, an adversary compromises it and uses it in other phases of the lifecycle. They may also compromise many machines to form a botnet.

According to the page, compromised infrastructure lets adversaries stage, launch and execute operations. It helps traffic blend in as normal, for example contact with high-reputation or trusted sites. MITRE gives several examples of how it is used:

  • Together with digital certificates, to blend in and support staged information gathering and phishing campaigns.
  • To support proxy and proxyware services, or a botnet.
  • To gain initial access through Wi-Fi networks, by compromising infrastructure that sits close to a target.
  • To enable follow-on operations. MITRE adds that adversaries may compromise the infrastructure of other adversaries before targeting.

Trust is the common thread. The victim domain, server or device already has a good reputation, and the adversary borrows it.

How to detect it

MITRE offers several ideas, and they split into two groups.

Looking outward, for your own exposure and for hunting:

  • Internet scans may proactively discover compromised infrastructure. Consider looking for identifiable patterns such as services listening, certificates in use, SSL/TLS negotiation features, or other response artifacts associated with adversary command and control software.
  • Monitor for anomalous changes to domain registrant information or domain resolution information that may indicate the compromise of a domain. MITRE cautions that benign registration and resolution changes are common, so efforts may need to be tailored to specific domains of interest.
  • Monitor DNS registry data that may point to compromise of third-party infrastructure.

Looking inward, at the stages that follow:

  • MITRE says much of the activity is outside the visibility of the target organization. Detection effort should go to related stages of the lifecycle, such as command and control.

A simple, concrete practice is to keep a baseline for the domains you own. Record the registrant contact, the name servers, and every DNS record. A weekly diff catches changes you did not make. That is a general approach built on the registrant and resolution monitoring that MITRE describes.

For your own servers, ask what an outside observer sees. If you can find an unexpected listening service on your own address space with a scan, so can an adversary.

How to reduce the risk

MITRE lists one mitigation, Pre-compromise. It says the technique cannot be easily mitigated with preventive controls because it happens outside the scope of enterprise defenses.

What you can do falls on the owner side. These are general practices, not part of the MITRE entry.

  • Inventory everything you expose: servers, domains, subdomains and network devices. Retire what has no owner.
  • Patch and replace internet-facing equipment on a schedule. Unsupported appliances are favorite targets.
  • Lock down the accounts that control your domains and DNS, because MITRE notes that domain hijacking may come from taking over the email account of the registrant or social engineering a registrar help desk.
  • Remove DNS records that point to resources you no longer run. MITRE names dangling records as the root of subdomain hijacking.
  • Protect cloud consoles that manage DNS and servers with strong authentication.

If you receive a report that your infrastructure is being used against others, treat it as an incident. Do not just reboot the server.

It helps to split your response by role, because the same technique asks different questions of different teams.

For the network team: know every device you expose, keep firmware current, retire unsupported hardware and keep management interfaces off the internet. Edge devices come up again and again in MITRE's sub-technique pages, and they are the part of the estate that gets the least attention.

For the DNS and domain owners: keep a baseline of records, registrants and name servers, and diff it on a schedule. Protect the registrar login and the email account behind it.

For the cloud team: inventory servers, functions and storage, tie each to an owner and watch audit logs for new resources. A forgotten function or VPS is a resource someone else may eventually run.

For the security operations team: treat reports from outsiders seriously. If a researcher or another organization tells you your infrastructure is hosting something harmful, begin an investigation the same day.

None of these steps stops an adversary from compromising someone else. Together they make sure it is not you, and that if it is, you find out from your own monitoring first.

Check your own environment

  • List every domain and subdomain you own, with its registrar, registrant contact and name servers. Does every one have a named owner?
  • Find DNS records that point to services you cancelled. A CNAME to a deprovisioned resource is the classic hijack opportunity.
  • Linux or macOS, read-only: dig +short NS example.com and dig +short CNAME app.example.com (replace with your names).
  • Run whois example.com and compare the registrant and name server fields with what you expect.
  • Review which internet-facing devices are past end of support.
  • Look at your own certificate transparency listings for names you did not request.

Quick check

Does an adversary pay for infrastructure in T1584?

No. They compromise infrastructure that already belongs to someone else, which is what separates it from Acquire Infrastructure.

Why is compromised infrastructure attractive?

It carries the reputation of its owner, so traffic blends in with normal contact to trusted sites.

What does MITRE suggest monitoring for domains?

Anomalous changes to registrant or domain resolution information, tuned to the domains that matter most, because benign changes are common.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.