How T1583 acquire infrastructure shows up before an intrusion
Most of T1583 Acquire infrastructure happens outside your network, so a SOC rarely sees an adversary buying a domain, renting a server or opening a hosting account. The signals you can use are indirect: a newly registered domain that imitates your brand, a hosting address that begins serving content about your staff, or DNS records that appear shortly before a phishing campaign. ATT&CK defines the Resource Development tactic (TA0042) as follows: "The adversary is trying to establish resources they can use to support operations." T1583 sits in that tactic and has 8 sub-techniques, each describing a type of infrastructure an adversary can acquire. The detection guidance on this page targets ATT&CK 20.0.
Acquisition usually comes early in an intrusion lifecycle. The infrastructure is then used for staging, delivery, and command and control, so the acquisition step gives you the earliest window to act, often well before any alert on the victim's endpoints or identities. The decision for your team is how much external visibility to fund. Domain registration data, passive DNS and certificate transparency logs can flag lookalike names, while your own DNS resolver and proxy logs show whether staff are already reaching those names. Confirm with each feed provider which fields, retention periods and update frequencies they guarantee before you build alerts on them.
Treat any single indicator as a lead, not a verdict. A lookalike domain may belong to a security researcher, a marketing agency or a typosquatter with no interest in your organization. Ask your team to define the evidence needed before escalation, such as a combination of a recent registration, matching branding and a resolution from inside your network. Also confirm which ATT&CK data components your current tooling maps to, since the detection strategies for Resource Development are built around external registration and DNS data. Record the ATT&CK version each rule targets so that future releases do not silently change what your alerts mean.
Which data sources reveal acquired infrastructure and which tool collects them
This table maps each data component ATT&CK references for T1583 to the signal it can reveal about adversary-acquired infrastructure, and the open-source collector or enrichment path that typically feeds it. Read each row as a question to answer in your own environment: can we collect this, and does it show the infrastructure before it is used against us? Data components are referenced in ATT&CK 20.0, so confirm availability and coverage in your own estate before relying on any row.
| Data component | Signal it can reveal | Open-source collection or enrichment path |
|---|---|---|
| Response Content (DC0104) | Web content served by newly registered or staged hosts, such as cloned pages, login forms or lure templates tied to your brand or sector | Zeek HTTP logs, Suricata alerts on HTTP content, and scheduled crawls of watchlisted domains ingested into Wazuh or Security Onion |
| Domain Registration (DC0101) | Newly registered domains resembling your names, suppliers or services, including registrant and registration date patterns | WHOIS or RDAP enrichment fed into a Wazuh or Security Onion lookup list, with scheduled comparisons against a brand watchlist |
| Response Metadata (DC0106) | Certificates, server banners and response headers that link acquired hosts to shared infrastructure or reused configurations | Certificate transparency monitoring and TLS metadata from Zeek SSL logs, correlated in Security Onion dashboards |
| Passive DNS (DC0096) | Historical resolutions showing when a domain or IP began pointing to hosts that were previously unrelated or newly provisioned | Passive DNS feeds ingested as lookup enrichment into Security Onion or Wazuh, or collected from resolver logs where the data sharing terms allow it |
| Active DNS (DC0103) | Current records such as MX, NS and A entries that show newly stood-up infrastructure before it appears in your own traffic | Scheduled DNS lookups run from a controlled collector, with results stored and compared over time in Wazuh or a SIEM lookup table |
| Network Traffic Content (DC0085) | Traffic from your network to newly acquired hosts, including suspicious TLS, HTTP and DNS patterns when outbound activity reaches those assets | Zeek network metadata and Suricata rule-based alerts forwarded to Security Onion or Wazuh, with retention sized to your monitoring policy |
Detection ideas for newly registered and suspicious domains
T1583 Acquire infrastructure is visible before an adversary touches a victim, but the signals sit outside most enterprise logs. The cards below pair network and DNS observations from your own estate with external registration and hosting metadata, so each idea can be tuned against the false positives your business generates every day.
Newly observed domains from internal hosts
Track domains that appear in resolver logs for the first time and resolve from internal hosts, especially from finance, administrative or executive endpoints. Under T1583, an adversary registering domains for later use is not yet touching your network, so the first internal lookup is often the earliest chance to see the infrastructure. Set a first-seen window, such as a rolling period you tune during a baseline, and require the domain to be absent from your allow history. Expect noise from marketing campaigns, new SaaS tenants and CDN hostnames that rotate often.
Lookalike domain matching
Compare newly registered and certificate-logged domains against your brand names, product names, executive names and internal naming conventions. Edit-distance, homoglyph and keyword matches surface typosquats an adversary may stage before a phishing campaign. Review high-scoring matches manually before escalation, since many are defensive registrations by your own legal or brand teams. Ask your registrar or threat intelligence provider which registration feeds they can supply, and confirm how they handle internationalized names.
Certificate and hosting metadata changes
Watch for certificates issued for your names or near-matches, and for hosting that changes shortly after registration, such as a new autonomous system, a new certificate authority or a sudden shift to a low-reputation provider. These attributes are often set up before a domain is used, which makes them useful for prioritizing alerts. Set thresholds on how many attributes change within a short window, and check against known renewal cycles from your own certificate inventory to avoid flagging routine renewals. Hosting moves are common during vendor migrations, so pair them with a domain match.
Infrastructure reuse across clusters
Group suspicious domains that share registrant details, name servers, hosting addresses, certificate fingerprints or page templates. When several unrelated-looking domains reuse the same operational pattern, they are more likely to belong to one adversary-controlled set. Tune the clustering to require at least two shared attributes so that a single shared host does not link unrelated tenants. Expect false positives from shared hosting providers, reseller platforms and agencies that manage many client domains, so keep an allow list of known shared infrastructure and review it each quarter.
How to validate that T1583 detections fire
This sequence proves, in a private cyber range, that each T1583 detection fires on benign look-alike infrastructure acquisition, how quickly it alerts, how well it is enriched, and where it produces false positives. The output is a validated detection baseline and a tuning backlog that the SOC can trust.
Agree scope and written rules
The detection owner, SOC lead, range operator and a legal or compliance contact agree in writing which T1583 sub-techniques are in scope, which benign look-alike infrastructure may be acquired, which domains and address space are off limits, and who may stop the exercise. Nothing is acquired outside the range boundary. The step is done when the signed scope document names the ATT&CK version under test, the detection IDs and the stop conditions.
Map detections to data components
The team lists each detection that claims coverage of T1583 and its sub-techniques, then records which data components it depends on, such as Domain Registration (DC0101), Passive DNS (DC0096), Active DNS (DC0103), Response Content (DC0104) and Response Metadata (DC0106). For each one they confirm that the feeds exist in the range and in production. The output is a coverage matrix that shows any detection with no working telemetry source.
Prepare benign look-alike infrastructure
The range team stages harmless, clearly labeled infrastructure that mirrors the observable shape of acquisition activity, using reserved or internal namespaces where possible. Each asset is logged in a register with its owner, creation time and planned teardown. The step is complete when the register is reviewed and every asset is confirmed to be inert and inside the agreed boundary.
Run the emulation under observation
The range operator carries out the agreed scenario while a second engineer watches the SIEM and sensor consoles and timestamps every step in a shared log. Deviations from the written plan are stopped and recorded. The output is an event timeline that links each emulated action to the moment it was performed, which later allows measurement of time to alert.
Confirm each detection logic fires
The detection engineer checks, for every mapped detection, whether an alert was produced for the matching emulated action. Results are recorded as fired, partially fired or missed, with the rule identifier and version. Missed detections are assigned to a root cause, such as missing data, a field mismatch or a logic gap. The step is done when every in-scope detection has a recorded result.
Measure alert time and enrichment quality
The team compares the emulation timestamps with alert creation times to measure time to alert for each detection. They then review whether the alert carries the fields an analyst needs, such as registrar, name server, certificate or hosting context, and whether enrichment from threat intelligence or asset inventory was attached. Each alert receives a quality rating. The output is a table of latency and enrichment gaps per detection.
Record false positives and tune
The team reviews alerts raised during the exercise and during a baseline period of normal activity to identify false positives, especially from legitimate domain registration, certificate issuance and hosting changes. Tuning changes are proposed, peer reviewed and tested again against the same emulation record. The step closes when each change is linked to a before and after result and the backlog for the next validation cycle is approved.
Tear down and document the baseline
The range operator removes every emulated asset, verifies removal against the asset register and documents any residue. The detection owner publishes a validation report that names the ATT&CK version tested, the detections, their results, latency, enrichment and false positive findings, and the open actions. The report is the artifact that proves the detections were exercised and is the input to the next review cycle.
Why most T1583 evidence sits outside the victim network
Most of the work behind T1583 Acquire infrastructure happens on infrastructure the victim does not own or operate. Domains are registered with registrars, hosting is rented from providers, and certificates are issued by certificate authorities before any packet reaches the victim. The defender therefore sees the result, not the acquisition itself: a domain that resolves to an unfamiliar address, a certificate issued for a lookalike name, or a server that answers with unexpected content at the point of contact. Detection planning should start from that reality and accept that the strongest signals are the ones the victim can observe from its own mail gateways, proxies, DNS resolvers and network sensors when a suspicious resource is first touched.
MITRE organizes this visibility through detection strategies, identified by DET IDs, and analytics that sit beneath them. ATT&CK v18 replaced the detections previously written into technique pages with these strategies and made major updates to data components, identified by DC IDs, and deprecated some data sources. For T1583, the relevant data components include Response Content, Domain Registration, Response Metadata, Passive DNS and Active DNS. Ask your team to map each analytic to the specific component it needs, then confirm with your telemetry owners which of those components you collect today. A gap in one component often means the analytic cannot run as written, even when the technique is listed as covered.
Detection mappings should name the ATT&CK version they target, such as the version your team is currently running in its rule library. Releases can rename, deprecate or revoke techniques and sub-techniques, and the release cadence includes v19 on April 28, 2026 and v20 on October 13, 2026. A rule written against an older numbering can silently stop matching what the framework describes. Record the version in each rule's metadata, review the T1583 mapping at every release, and treat changes to sub-technique scope as a trigger for re-testing in the cyber range rather than a documentation-only update.
Preventive controls that reduce exposure to acquired infrastructure
The ATT&CK mitigation Pre-compromise (M1056) describes actions defenders can take before an adversary uses acquired infrastructure against them. The controls below sit at your network edge, in your DNS resolvers and in your change processes, and they work together: each one narrows what a new or unknown domain can reach inside your environment.
Limit unvetted outbound destinations
Pre-compromise is largely about deciding which destinations your systems may reach at all. Build an egress policy that allows only the categories of destinations your business needs, and deny the rest by default for servers and privileged workstations. Infrastructure acquired for an intrusion often sits on fresh domains and newly assigned addresses, so a default-deny posture on servers blocks much of the traffic that would otherwise reach it. Confirm the exact mitigation wording and its scope on the Pre-compromise page before you cite it in an audit.
Filter DNS with category and reputation feeds
Route internal DNS queries through resolvers that you control, and apply category or reputation blocking to them. Open-source resolvers such as Unbound or Pi-hole, or the DNS filtering already in your estate, can enforce these lists. Review which resolvers your servers actually use, since hard-coded public resolvers bypass your filtering. Log every query and response so that blocked and allowed lookups feed your detection work on Response Content and Passive DNS data. Confirm which feed licenses and update cadences your tooling supports.
Allowlist domains for new registrations
Newly registered domains are a common pattern in infrastructure acquisition. Ask your DNS or proxy team to hold outbound access to domains registered recently at a more restrictive level, such as requiring review before a server or service account can resolve them. The age threshold is a local decision that you should set and document, based on your own traffic patterns. Pair the rule with a request workflow so that legitimate vendors and SaaS endpoints are added quickly, and record every approval for later review.
Segment systems that call external services
Place internet-facing and third-party integration workloads in network zones that can reach only the specific endpoints they need. This limits the damage if a system begins talking to infrastructure an adversary has prepared. Document each zone's allowed destinations as firewall rules or proxy policy, and review them when a vendor changes its hosting. Confirm with your network team which firewalls and proxies can enforce destination-based rules on your segments.
Monitor certificate and registration changes
Some infrastructure acquisition shows up in public certificate transparency logs and domain registration records before it shows up in your traffic. Maintain a watchlist of domains that resemble your brands, vendors and key suppliers, and review alerts from it on a schedule. Open-source tools such as certificate transparency monitors can help, but confirm their coverage and licensing before you rely on them. This control supports the Domain Registration and Response Metadata telemetry used in the detection sections.
Govern third-party hosting and vendor changes
Your own controls rely on knowing which vendors and hosting providers you depend on. Keep a register of external endpoints for each business service, with an owner and a review date. When a vendor announces a new domain or IP range, the change should pass through the same approval path as any new destination. Make sure the register also names the ATT&CK version your detection mappings target, since techniques can be renamed or revoked between releases.
Triage and response when a T1583 detection fires
When a T1583 detection fires, the first job is to confirm whether the domain or IP address is genuinely attacker-controlled before anyone blocks or reports it. Pull the registration record, the hosting or autonomous system details, the first-seen date in your passive DNS history, and the Response Content you captured for the site. A newly registered domain that mimics a supplier, a bank or a internal brand is a strong lead, but shared hosting, CDN front ends and legitimate parked domains can produce the same signals. Record each check and its result so the verdict can be defended later to an auditor or a customer's security team.
Next, establish which internal hosts resolved or connected to the infrastructure and what they did afterward. Query your resolver logs and proxy or firewall telemetry for the indicator over a window that covers the first-seen date, then identify the user, device and process involved for each hit. Treat a hit from a security scanner, a threat intelligence feed or a sandbox as a different case from a hit by an end user's browser. Scope related indicators by pivoting on shared registrant details, name server sets, certificate fingerprints and hosting ranges, but limit the blast radius of the pivot to what you can verify. Confirmed hosts move into the incident workflow, and their credentials and sessions are reviewed as a separate task.
Then decide the containment action: block at the DNS resolver, the secure web gateway or the perimeter, sinkhole the domain to an internal address so that callbacks become visible, or submit a takedown request to the registrar, hosting provider or abuse contact. Each option has different consequences, and a blocked domain that a legitimate service also uses can disrupt business operations, so confirm the business owner has signed off. Preserve the raw logs, the Response Content and the decision record in a case file with timestamps, then feed every confirmed indicator back into detection content, noting the ATT&CK version your rule targets, so that the next match is faster and the false positive is documented.
Rehearsing T1583 detection in a private cyber range
The range should reproduce the visibility points a production team relies on for T1583 signals, without exposing any real external infrastructure. Internal DNS resolvers log queries from lab hosts, an egress proxy records outbound web requests, and sensors such as Zeek or Suricata observe the traffic that crosses the boundary. A SIEM such as Wazuh or Security Onion collects these sources in one place so analysts can correlate them. Keep the range isolated, and use reserved or lab-owned names for every simulated domain so that nothing in the exercise touches a real third party.
- Internal DNS resolver: Forward query logs to the SIEM with hostnames, client addresses and response codes preserved.
- Egress proxy: Log destination hosts, paths, user agents and TLS server names for each outbound request.
- Network sensors: Run Zeek or Suricata on the boundary segment to capture DNS, HTTP and TLS metadata.
- SIEM: Use Wazuh or Security Onion to normalize sources and retain them for the exercise window.
- Isolation controls: Confirm that the range cannot resolve or reach production or public infrastructure.
Before the exercise, confirm that each log source reaches the SIEM and that the fields named above are populated, because missing fields are the most common reason a rehearsed detection fails.
Injects are scripted events that the exercise control team introduces into the range to create the signals a defender would see if a adversary were preparing infrastructure. The scenarios below are illustrative and should be adapted to the organization's own threat model. Each inject should have a known time, a known source and an expected log footprint, so that the blue team can be scored on what it saw rather than on what it guessed.
- Look-alike domain inject (illustrative): A lab-owned name differing from an internal brand name by one character is resolved and requested by a single internal client.
- Newly registered domain inject (illustrative): A domain registered within the exercise window is queried and then used for an outbound request through the proxy.
- Infrastructure reuse inject (illustrative): Two separate lab hosts contact the same hosting address and the same TLS server name within a short period.
- Benign look-alike control (illustrative): A harmless, legitimately registered lab name that resembles an internal name, to measure false positives.
- Timing variation: Repeat injects at different intervals to test whether correlation rules still fire.
Record each inject in a timeline before it runs, so the scoring compares the expected and observed evidence.
Good detection means analysts can connect an inject to its telemetry quickly and accurately, and good response means the playbook moves from triage to containment without confusion. Success criteria should be written before the exercise and tied to the ATT&CK version the detection targets. Detection content should name the data components it depends on, such as Response Content (DC0104), Domain Registration (DC0101) and Response Metadata (DC0106), and the ATT&CK version used for the mapping. Measure results against the criteria rather than against a generic pass or fail.
- Detection coverage: Each inject produces at least one alert or hunt result that names the correct host and domain.
- Triage speed: Analysts record the time from alert to a documented decision, and the exercise lead compares it with the agreed target.
- False positive handling: The benign control is either suppressed by documented logic or reviewed and closed with a reason.
- Response actions: The playbook steps, such as blocking the domain at the resolver and isolating the host, are executed and logged.
- Lessons recorded: Gaps in telemetry, rule logic and escalation are assigned owners and retested.
Ask your team to confirm the success thresholds with management before the exercise, because they should reflect your own risk appetite and staffing.
Questions detection engineers ask about T1583
How do I tune lookalike domain matching for T1583 without flooding the queue?
Start with a narrow set of high-value brand terms and common typosquat patterns, then measure which alerts analysts actually act on before widening the net. Lookalike matching on newly registered domains produces volume quickly, so tuning is mostly about scoping. Pair domain registration signals with resolution and certificate observations, since a domain that is registered but never resolves carries different weight than one that serves content. Record every suppression with a reason and an owner so the tuning stays reviewable. Confirm which registration and passive DNS feeds your environment can legally and practically consume, because feed coverage limits what any rule can see.
Which data components should I prioritize first for T1583?
Prioritize Domain Registration (DC0101) and Response Content (DC0104), since they give the most direct view of infrastructure being set up before any intrusion occurs. Response Metadata (DC0106) helps confirm what a hosted service returns, and Passive DNS (DC0096) and Active DNS (DC0103) add resolution history. Network Traffic Content (DC0085) matters later, when acquired infrastructure starts appearing in your own traffic. Map each component to a data source you already collect, note gaps in writing, and check the current component definitions against the ATT&CK version you target, because data components were updated in ATT&CK v18.
How should I handle coverage across the 8 T1583 sub-techniques?
Treat each sub-technique as a separate coverage line rather than assuming the parent technique is covered. Build a table with one row per sub-technique, the data components that support it, the detection strategy or analytic you have, and the known blind spots. Some sub-techniques depend heavily on third-party visibility, so mark those honestly as partial. Review the table whenever you upgrade ATT&CK versions, because sub-technique lists can change between releases. Confirm the exact list of sub-techniques in the version you publish against, not in a remembered copy.
How do I version detection mappings across ATT&CK releases?
Put the ATT&CK version number in every rule, mapping file and coverage report, and never publish a mapping without it. Releases can rename, deprecate or revoke techniques, so a rule that mapped cleanly last year may point at an obsolete identifier now. Keep a changelog that records the version you moved to, which IDs changed, and which rules you re-tested. Use the official release notes as the reference for each change, and pull the STIX bundle for the version you target so your mapping can be checked by script. Schedule a review after each release rather than waiting for an audit to reveal drift.
How do I measure whether a T1583 detection actually fired in the cyber range?
Define the expected alert before the exercise, including the rule name, the data source, and the time window in which it should appear. During the exercise, have the emulation team log each action with a timestamp so you can match it against alerts in your SIEM. Record three outcomes: alert fired, alert fired but was not triaged, and no alert. Review gaps with the detection owner and feed the results back into rule tuning and the coverage table. Keep the range logs and SIEM exports together so the result can be reproduced later. Pure alert counts do not prove detection quality, so judge the outcome against the expected alert.
What does the ATT&CK Pre-compromise mitigation mean for T1583 in practice?
Pre-compromise (M1056) is a mitigation that acknowledges much of this activity happens outside your network, so you cannot block it directly. In practice, your controls are detection of infrastructure that targets your brand or staff, and response plans for takedown or reporting. Assign an owner for external monitoring, define which indicators trigger escalation, and document how you request takedowns through your providers. Confirm the mitigation text and its mapped techniques in the ATT&CK version you use, since mappings can shift between releases.
Can my own team run T1583 detection rehearsals without outside help?
Yes, a team with detection engineering and SOC experience can run rehearsals internally, provided it has a private range, clear rules of engagement, and a documented scope. The main work is planning the exercise, coordinating the emulation, and reviewing results afterward. Outside help is most useful for scoping, independent review of coverage claims, or building a repeatable range environment. DeployOpen plans, implements and supports self-hosted platforms and cyber ranges inside the client's own infrastructure, with fixed-scope engagements agreed in writing before work starts. Ask any partner to confirm exactly which deliverables and environments are included.
How DeployOpen builds T1583 detections and range scenarios
DeployOpen treats T1583 Acquire infrastructure as a detection engineering and validation project inside your own environment, not a generic monitoring exercise. Work starts from a written scope that names the ATT&CK version, data sources and sub-techniques in play, then moves through build, range rehearsal and handover.
How we scope
- Confirm the ATT&CK version the detection mapping will target before any rule is written.
- Inventory which DNS, domain registration and certificate telemetry your organization can actually collect.
- Agree in writing which of the 8 sub-techniques are in scope and which are excluded.
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts.
How we build
- Map Response Content, Domain Registration and Response Metadata data components to your existing log sources.
- Write detection logic in Sigma and translate it to your SIEM, such as Wazuh or Security Onion.
- Tune thresholds against your own baseline of legitimate domain and hosting activity.
- Document the Pre-compromise mitigation as a control with owners and evidence expectations.
How we hand over
- Deliver detection rules, mapping tables and tuning notes in version-controlled form.
- Provide range scenario runbooks that describe expected alerts and analyst steps, without attack payloads.
- Record validation results per sub-technique, including known gaps and the telemetry needed to close them.
- Walk your SOC and threat intelligence staff through the handover and the open items list.
How we support
- Ongoing support is available as a retainer for rule maintenance after each ATT&CK release.
- Retainers can cover re-running range rehearsals when log sources or detection logic change.
- Review new ATT&CK releases for renamed, deprecated or revoked techniques affecting this mapping.
- Confirm retainer scope, cadence and responsibilities in writing alongside the original engagement.
