How T1584 compromise infrastructure shows up before an intrusion lands
A SOC lead sees a domain, IP address or web server in proxy logs and cannot tell whether it belongs to the organization, a vendor or a third party. That uncertainty is the core problem of T1584 Compromise Infrastructure. In MITRE ATT&CK, T1584 sits under the Resource Development tactic (TA0042), where the adversary is establishing resources to support operations. The technique covers adversaries taking over infrastructure they do not own, such as domains, DNS servers, web services, servers and virtual private servers, and it has 8 sub-techniques. This page uses ATT&CK version 20.0, so mappings should be checked against that version before they are relied on.
Adversaries take over existing infrastructure because it is cheaper to borrow than to build, and because traffic to a known, legitimate-looking host is less likely to be blocked or questioned. The activity usually happens before the victim is touched, so the first visible trace is often a name or address that resolves, responds or is referenced in an alert, not a payload. It can surface as a lookalike domain resolving in DNS, a web server returning content tied to an unrelated brand, or an IP address with a registration history that does not match the organization's own assets. It is hard to see from inside the victim network because the infrastructure is not the victim's. Most of the relevant records live in external registries, passive DNS datasets and third-party hosting, so an internal sensor sees only the connection, not the context.
The practical decision is which external sources your team will check and how often. Confirm with your threat intelligence and DNS providers what passive DNS, domain registration and hosting data you can access, how far back it goes and whether it can be queried in bulk. Then decide who owns the question of whether an unknown asset is yours, and write down the evidence needed to close it, such as ownership records you control and inventory of your own domains and hosts. Treat unexplained infrastructure as a lead for investigation rather than a verdict, because a third party's compromised server can look identical to an attacker's server from the outside.
Which telemetry reveals T1584 and which open-source tool collects it
This table maps each ATT&CK data component referenced for T1584 to the signal it provides and the open-source collector that can gather it. Read it as a starting point: confirm each mapping against the detection strategies in the ATT&CK version you target, because data component IDs and detection content change between releases.
| Data component | Signal to look for | Open-source collector | What to confirm |
|---|---|---|---|
| Response Content (DC0104) | Content served by attacker-controlled sites that resembles a victim's own pages, forms or login flows, seen in proxied or inspected web traffic | Zeek HTTP logs, Suricata HTTP metadata, Security Onion case views | Whether TLS inspection is in scope and where your sensors sit relative to outbound web traffic |
| Domain Registration (DC0101) | Newly registered or lookalike domains that resemble your brands, partners or identity providers | Scheduled registration feed checks alongside Security Onion or Wazuh alert correlation, with feed data stored as log events | Which registration feed you license or query, and how often it is refreshed |
| Response Metadata (DC0106) | Certificate, server header and hosting attributes on infrastructure that mimics your services | Zeek SSL and X.509 logs, Suricata TLS metadata, Security Onion dashboards | Whether certificate transparency data is ingested and how long metadata is retained |
| Passive DNS (DC0096) | Historical resolutions showing a domain pointing to hosting ranges that also serve suspicious content | Passive DNS feed ingested into Security Onion or Wazuh as enrichment, plus Zeek DNS logs from your own resolvers | Feed licensing terms, coverage in your regions and retention limits |
| Active DNS (DC0103) | Current resolution records for suspect domains, including changes that move infrastructure between providers | Zeek DNS logs, scheduled lookups written as events to Wazuh | Whether active lookups are permitted under your policy and which resolvers you query from |
| Network Traffic Content (DC0085) | Connections from your users or servers to newly observed or low-reputation infrastructure carrying unusual payloads or headers | Suricata rules and EVE logs, Zeek connection and protocol logs, Security Onion as the collection platform | Sensor placement, storage capacity and whether encrypted payloads are visible at the sensor |
Detection ideas for compromised infrastructure in DNS and network logs
T1584 Compromise Infrastructure covers adversaries who take over servers, domains or hosting that a defender already trusts, so the signals often look like normal traffic to a known destination. The ideas below pair DNS and network telemetry with a baseline of what is legitimate for your environment. Each one needs tuning against your own change calendar and vendor footprint before it becomes an alert.
Newly observed domains reached by internal hosts
Track domains that internal hosts resolve for the first time, or domains whose registration changed recently. Flag repeated lookups or connections to a domain that has no history in your passive DNS or proxy baseline, especially when it appears alongside a known business application. Tune the age window to your environment, for example a short look-back for finance or healthcare systems where new vendor domains are rare. Expect false positives from new SaaS onboarding, marketing tools and CDN edge names, so route hits to an enrichment step that checks registrar and hosting data before analyst review. Confirm the registration data source your SIEM can query.
Sudden changes in DNS resolution
For a short list of critical services, such as identity providers, mail relays and update servers, record the expected answer set from Active DNS and passive DNS over time. Alert when a name that has resolved to the same provider network starts returning addresses in a different autonomous system, country or hosting range. Legitimate causes include CDN re-mapping, provider migrations, load balancer changes and failover, so correlate each change with change tickets and maintenance windows before escalating. Keep the watchlist short so analysts can review each hit.
Changes in TLS and HTTP response metadata
On trusted hosts and their known endpoints, baseline the certificate issuer, subject alternative names, key type and HTTP server headers that appear in Zeek or Suricata metadata. Alert when a previously stable endpoint presents a new issuer, a certificate for unexpected names, or a server banner that changes without a deployment record. Certificate renewals, reverse proxy upgrades and vendor-managed certificates create routine changes, so match each alert to certificate inventory and patch records. The strongest signal is a change that appears on several metadata fields at once, not on one field alone.
Outbound connections to formerly legitimate infrastructure
Maintain a history of destinations that internal assets contacted during normal operation, then flag new outbound sessions from a server to an address or hostname that was legitimate for a partner or vendor but has since shifted. This pattern matters because the destination may still look trusted by reputation feeds. Compare session volume, port, protocol and byte counts against the historical profile, not just the destination. False positives come from vendor re-hosting, data center moves and acquisitions, so ask the vendor or account owner to confirm migrations before closing an alert.
Detection strategy mapping and version control
Map every DNS and network rule to the ATT&CK detection strategy and data component it depends on, such as Response Content, Domain Registration or Passive DNS, and record the ATT&CK version the mapping targets. Releases can rename, deprecate or revoke techniques, so a rule that cited a retired detection needs review after each update. Ask your SIEM team to confirm which data components your sensors actually capture before promising coverage. Gaps in this mapping are the most common reason a detection looks complete on paper but never fires.
How to validate that T1584 detections fire
This sequence gives the team a repeatable way to prove that T1584 detections fire on a controlled infrastructure change, from the moment the change is made to the alert arriving in the SOC queue. The output is a dated record of which data sources logged what, which detection IDs fired, and where coverage is missing.
Define the benign test host and domain
The detection engineer and the SOC lead agree on a benign test host inside the cyber range and a controlled test domain or server that the team owns and can change at will. Nothing in the test should touch production names, third-party infrastructure or real customer data. The written test plan names the ATT&CK version being targeted, such as Enterprise ATT&CK 20.0, so later results map to a fixed reference. The step is complete when both owners sign off on the plan and the test assets are listed in the range inventory.
Confirm baseline telemetry before the change
Before anything changes, the team confirms that each relevant data source is collecting. For T1584 this usually means certificate transparency or other response content feeds, domain registration records, response metadata from the controlled server, and passive or active DNS where the range provides it. The engineer checks that each source reaches the log platform, such as Wazuh, Security Onion or Zeek, with healthy timestamps. The step closes with a baseline snapshot showing that every source is present, so any later silence can be attributed to the detection rather than to a broken feed.
Simulate the ownership or hosting change
A team member, following the written plan, makes a controlled change to the test domain or server, such as changing its registrar contact or moving it to a different range-hosted address. The change is logged in the test record with the exact time, the person responsible and the expected data components it should touch. No attack commands or evasion steps are used, only the controlled administrative change. The step is complete when the change is confirmed on the range side and the timestamp is recorded.
Record expected log entries per data source
Before reviewing results, the engineer lists the log entries each data source should produce for the change, one row per data component: Response Content, Domain Registration, Response Metadata, Passive DNS and Active DNS where in scope. Each row states the expected field or record type and the platform where it should appear. Writing expectations first prevents the team from reading success into noise. The step closes with a reviewed expectation table that the SOC lead has approved.
Check which detections fire and when
The engineer queries the log platform for the window around the change and compares what arrived against the expectation table. For each rule or analytic that should fire, the team notes the detection ID, the timestamp of the triggering event, the source it came from and the delay until the alert was created. Rules that should fire but do not are marked as misses, and rules that fire without a matching change are marked as noise. The step is complete when every expected detection has a recorded outcome.
Confirm alerts reach the SOC queue
The SOC analyst checks that each generated alert appears in the ticketing or case queue with the correct severity, asset and context, and that it was assigned according to the runbook. The team confirms that notifications, such as email or chat integrations, behaved as designed. A detection that fires in the log platform but never reaches an analyst is recorded as a routing gap. The step closes when each alert is either acknowledged in the queue or logged as a gap with an owner.
Record gaps by data component and retest
The team writes a validation record that lists timestamps, data sources, detection IDs, alert outcomes and gaps grouped by data component. Each gap gets an owner and a fix, such as a new collector, a tuned rule or a corrected routing path, followed by a retest of the same change. The record names the ATT&CK version and the detection strategy version used, because ATT&CK releases can rename or deprecate techniques. The step is complete when the record is filed and the retest results are linked to the original run.
Preventive controls that reduce exposure to T1584
The ATT&CK mitigation Pre-compromise (M1056) asks defenders to watch the infrastructure they own before an adversary can use it. The cards below cover the controls that most directly limit how T1584 Compromise infrastructure can succeed against an organization's domains, DNS and hosted assets. Each control should be confirmed against the organization's own registrar, DNS, certificate and inventory tooling.
Domain lock and registrar monitoring
Registrar account takeover is a common route to hijacking a domain, so confirm that registrar accounts use strong multi-factor authentication and that registry lock or equivalent transfer protection is enabled on every production domain. Alert on changes to nameservers, contacts and registrar settings, and reconcile those alerts against change tickets. Ask the registrar which lock options and notification settings it supports for each top-level domain you hold. Registrar changes without a ticket are the first signal to investigate.
DNS zone change auditing
Adversaries who control a victim's DNS records can redirect users or issue certificates for names the victim never intended. Keep an authoritative record of every zone, log all changes to zone files and provider consoles, and forward those logs to the central monitoring platform. Review record types that point to third-party services, such as CNAME records to decommissioned hosting, since dangling records are a frequent weakness. Confirm which audit logs your DNS provider exposes and how long it retains them.
Certificate transparency watching
Certificate transparency logs record publicly issued certificates, so a certificate issued for your domain by a party you did not authorize is visible to anyone monitoring those logs. Subscribe to alerts for your primary domains and subdomains, and compare new issuances against your certificate inventory. Confirm that your certificate authorities restrict issuance through CAA records where that fits your operations. Treat unexpected issuance as a potential sign of hijacked infrastructure rather than routine noise.
Asset and domain inventory
Defenders cannot watch assets they have not recorded. Maintain a single inventory of registered domains, subdomains, IP ranges, cloud accounts and third-party hosted services, with an owner and expiry date for each entry. Reconcile the inventory against DNS zones and certificate records every review cycle to find forgotten assets. Expired domains and abandoned cloud resources are the entries most likely to be taken over, so flag them first.
Domain expiry and renewal control
Lapsed domain registrations can be re-registered by anyone, and an adversary who obtains a previously trusted domain can reuse its reputation. Track renewal dates for every domain in the inventory, enable auto-renewal with a monitored payment method, and assign a named owner who receives expiry warnings. Ask your registrar how far in advance it sends expiry notices and what grace and redemption periods apply to your domains.
Ownership and change governance
Many compromises begin with a stale account or a former contractor who still controls a registrar, DNS or hosting login. Review who holds administrative access to registrar, DNS and hosting consoles, remove access during offboarding, and require a second approver for changes to production records. Document the process for emergency changes so that urgent edits are still recorded and reviewed afterward.
What the SOC does when a T1584 alert fires
When a T1584 alert fires, the first decision is whether the infrastructure in question belongs to the organization at all. Confirm ownership of the domain or server before anything else: check the registrant and registrar records, the hosting account or cloud subscription that should own the address, and the change history of any DNS zone under your control. If the domain is yours, look for an unauthorized change, such as a new nameserver, a redirected record or a certificate issued for a host you did not expect. If it is not yours, the alert is a third-party compromise signal and the work shifts to scoping which of your hosts contacted it. Record what you confirmed and by whom, because that record becomes the starting point for every later step.
Next, compare what the infrastructure is serving with the last known good baseline. Pull the response content and response metadata for the affected host or domain, including status codes, headers, TLS certificate details, page hashes and redirect targets, and set them against the values captured during a known clean period. Review registration and passive DNS history for recent changes in ownership, registrar or resolution. Then scope the blast radius: query your DNS resolver and proxy logs and network sensor data for every internal host that resolved or connected to the infrastructure during the suspect window. Decide containment based on what is confirmed: block the domain or address at DNS and egress, sinkhole it if you need to observe callers, or stop trusting the affected certificate. Where the infrastructure belongs to a third party, contact the registrar or hosting provider with your evidence and request a takedown or review, and keep a written log of every request and reply.
Preserve evidence before you remediate. Export the raw logs, packet captures where you have them, response snapshots, certificate chains and DNS query records with hashes and timestamps, and store them in write-once storage under chain of custody. Confirm the retention period in your own log platform before the window closes, since many resolver and proxy logs roll over quickly. Escalate to legal and privacy contacts if the scope includes customer data or regulated systems, and tell your compliance lead what evidence exists for any control that depends on this detection. Close the alert only after you can state who owned the infrastructure, which hosts were exposed, what was blocked or reported, and which detection rule needs tuning. Confirm the escalation paths, provider contacts and evidence retention periods in your runbook with your registrar, hosting provider and log platform owners before you need them.
Rehearsing T1584 detection in a private cyber range
A private cyber range for T1584 should separate the simulated adversary infrastructure from the monitored enterprise segment, with every boundary crossing logged. The aim is to produce realistic-looking DNS and web responses inside a closed environment, so the sensors see the same data categories they would see in production without any traffic leaving the range. Design the topology with the detection data sources in mind, not only the hosts.
- Segmented network: Place the simulated enterprise, the scripted third-party host and the sensor stack in separate zones, with egress limited to the range's own resolvers.
- Simulated DNS: Run an internal authoritative and recursive service that can serve records for a benign test domain, so Active DNS and Passive DNS style data can be captured and replayed.
- Monitored sensor stack: Feed network telemetry into open-source tooling such as Zeek, Suricata, Wazuh or Security Onion, and confirm each sensor records the fields your detection logic needs.
- Scripted third-party host: Stand up a controlled web host whose content and certificate metadata can be changed on a schedule, so the exercise can show how a change is seen.
- Baseline capture: Record a clean baseline before any change so analysts can tell a deliberate change from normal noise.
Before the first run, confirm with your platform team which ATT&CK version your mappings target and which data components your sensors actually populate.
Injects are scripted events that the exercise control team introduces on a set schedule. For T1584, the most useful injects change the observable state of a benign third-party host, such as its hosting provider, its response headers or its registration details, without involving any real adversary tooling. Each inject should map to one data component and one expected alert, so the result of every step can be scored.
- Simulated change of hosting: Move the scripted host's records to a different simulated network block on a test domain, then check whether the Active DNS and network sensors record the shift.
- Changed response content: Alter page content or script references on the third-party host, and verify that Response Content collection flags the difference against the baseline.
- Registration change: Update the test domain's registration fields in the lab registry, then confirm whether Domain Registration data reaches the case management queue.
- Certificate or metadata swap (illustrative): Replace the host's certificate in the range, and check whether Response Metadata analytics raise a review item.
- Benign control inject: Include one change that should not trigger an alert, so the team can measure false positives.
Keep the injects written in a control sheet that the blue team never sees in advance.
Good results are defined before the exercise starts, not after the logs are read. Agree in writing what counts as a detection, how quickly analysts must raise it, and what evidence the handoff must contain. Use these criteria to score each inject, and record gaps as detection engineering tasks rather than as individual blame.
- Detection threshold: State which alert, analytic or saved search must fire for each inject, and which fields it must show.
- Timing window: Agree the maximum time from inject to first analyst review, and the maximum time from review to triage decision. Set these values with the SOC lead and record them in the exercise plan.
- Handoff criteria: Define the minimum contents of a handoff, such as the affected domain, the before and after records, the sensor source and the analyst's confidence.
- Response decision: Specify whether the expected outcome is containment of the domain, a blocklist update, a stakeholder notification or a documented no-action decision.
- Scoring and follow-up: Assign a named owner to each gap, with a retest date, and keep the scored results with the detection's version record.
Confirm these criteria with your SOC, legal and communications leads before the exercise, and retest any detection after each change to its rule logic.
Questions detection engineers ask about T1584
How does T1584 Compromise infrastructure differ from T1583 Acquire infrastructure?
T1584 covers adversaries taking over infrastructure that someone else owns or operates, while T1583 covers infrastructure the adversary sets up or buys for itself. The difference matters for detection because a compromised server or site already has a legitimate history, reputation and owner, so simple newness checks on domains or hosts will miss it. For T1584, focus on changes to existing assets: unexpected content in web responses, altered metadata on servers that were previously stable, and redirects or injected resources on sites your organization depends on. For T1583, newly registered domains and fresh hosting are the stronger signals. Review both technique pages together and map sub-techniques to the data components each one references in ATT&CK version 20.0.
Which data sources should we onboard first for T1584 detection?
Start with the sources that show change on assets you already trust. In practice, that means Response Content (DC0104), Response Metadata (DC0106) and Network Traffic Content (DC0085), because they reveal altered pages, headers and payloads on the infrastructure your users and systems actually contact. Domain Registration (DC0101), Passive DNS (DC0096) and Active DNS (DC0103) come next, since they show ownership changes, new name resolution and records pointing to unfamiliar hosts. Confirm in the ATT&CK version you target which data components the T1584 detection strategies reference, because these mappings change between releases. Your first milestone should be a short list of business-critical external dependencies you can monitor continuously.
How do we avoid false positives from CDN and cloud migrations?
Treat planned infrastructure changes as a known input to the detection, not as noise to suppress after the fact. Maintain an allowlist of expected providers, IP ranges, certificate issuers and content hashes, and tie every entry to a change ticket with an owner and an expiry date. Alert on deviation from the expected baseline rather than on any change, so that a CDN cutover generates a review item only when the new origin, certificate or resource set falls outside the approved profile. Rehearse a migration in your cyber range before production so the baseline and alert logic are tested against the change pattern you expect. Expect tuning to continue for several change cycles.
How do we pin T1584 detections to a specific ATT&CK version?
Record the ATT&CK version, the STIX bundle and the detection strategy IDs in every detection's metadata, and store them in version control next to the rule. MITRE publishes ATT&CK content in STIX 2.1 format in the mitre-attack/attack-stix-data repository, with one bundle per domain and version, so you can reference the exact bundle you tested against. Releases can rename, deprecate or revoke techniques, and ATT&CK v18 replaced technique-page detections with detection strategies and analytics, so a rule written against an older page may no longer map cleanly. Schedule a review each time MITRE publishes a new release, and check the ATT&CK updates page for changes that affect T1584 and its sub-techniques.
How should we measure detection coverage for T1584?
Measure coverage by sub-technique and by data source, not by a single pass or fail count for the whole technique. For each of the 8 T1584 sub-techniques, record which data components are onboarded, which analytics are deployed, and whether each analytic has been validated in the cyber range against a documented test case. Track gaps where a sub-technique depends on a data source you do not collect yet, and note the ATT&CK version each mapping targets. A simple matrix with these columns gives security leadership a defensible view of what is covered, what is partially covered and what remains open, and it gives auditors the traceable evidence they ask for. Confirm the exact sub-technique count against the version you deploy.
Can our own team run T1584 detection without outside help?
Yes, many teams can, provided they already operate a log pipeline and have analysts who can read ATT&CK detection strategies. The work breaks into four parts: onboarding the data sources, writing or adapting analytics, validating them in a test environment, and running the response process. Your team owns the decisions about which assets matter and what a baseline deviation means, because only your organization knows its supplier and partner relationships. Where skills or capacity are thin, a fixed-scope engagement can cover planning, implementation, tuning and a cyber range rehearsal, with the deliverables and timeline agreed in writing before work starts. Ask any provider to name the data sources, versions and validation evidence in the written scope.
How DeployOpen builds T1584 detections and range exercises
DeployOpen approaches T1584 Compromise infrastructure as a fixed-scope engagement inside the client's own environment, with detection logic, range exercises and documentation agreed in writing before work starts. Each step is tied to the telemetry, sub-techniques and ATT&CK version the client confirms.
How we scope
- Written scope names which T1584 sub-techniques and telemetry sources are in and out of the engagement.
- We confirm which ATT&CK version the detection mappings target before any rule work starts.
- Scope records the log sources, tooling and access the client will provide, and who owns each one.
How we build
- We draft detection logic for Response Content, Domain Registration and Response Metadata signals in plain language first.
- Detections are built on open-source tooling the client already runs or agrees to adopt, such as Wazuh, Zeek or Suricata.
- Each detection is tested against sample telemetry in a private cyber range before it reaches production.
How we hand over
- Deliverables include detection rule files, mapping tables to ATT&CK identifiers and validation results.
- Runbooks describe triage, escalation and response steps for each T1584 detection the client receives.
- Range exercise reports record what was tested, which gaps remain and which owner will close them.
How we support
- Ongoing support is available as a retainer for tuning detections as ATT&CK releases change mappings.
- Retainers can cover periodic re-validation of T1584 detections against updated ATT&CK content.
- Ask for the support scope, response expectations and review cadence in the written quote.
