T1583: Acquire Infrastructure
MITRE ATT&CK T1583: Acquire Infrastructure Technique details for PRE, with detection guidance, relationships and mapped CVEs.
Security context for executives and security teams
Acquire Infrastructure is an early-stage adversary behavior: before an intrusion, an actor may obtain domains, servers, VPS/cloud resources, DNS services, web services, serverless infrastructure, ads, or botnet access to support later targeting. For leaders, the significance is that some risk is visible before compromise if teams monitor external infrastructure patterns, brand/domain abuse, suspicious hosting, and threat intelligence indicators. This technique matters because adversary-controlled or abused third-party infrastructure can make phishing, proxying, command-and-control, and other operations look like normal Internet or cloud activity.
Executive priority
Treat this as a pre-compromise risk and readiness issue, not only a SOC alerting problem. Executives should ask whether the organization has a defined process for identifying infrastructure that may be preparing to target the business, including lookalike domains, suspicious DNS changes, malicious or deceptive ads, abuse of common web services, and infrastructure linked by threat intelligence. Priority should be given to controls and evidence that reduce attack surface, support incident triage, and demonstrate proactive monitoring during audits or post-incident reviews. Because ATT&CK maps this to Resource Development on platform PRE, success depends heavily on external visibility, threat intelligence, and pre-compromise mitigation rather than endpoint telemetry alone.
Technical view
MITRE does not provide official detection text for T1583, but the relationship set includes DET0895, Detection of Acquire Infrastructure, and mitigation M1056, Pre-compromise. SOC, threat intelligence, and detection engineering teams should validate coverage across the related sub-techniques: Domains, DNS Server, Virtual Private Server, Server, Botnet, Web Services, Serverless, and Malvertising. Practical validation should focus on whether teams can correlate external infrastructure observations with internal security events, such as phishing reports, DNS/proxy activity, authentication anomalies, and command-and-control investigations. The relationship context shows multiple groups using this behavior, but that should be used for intelligence context and prioritization, not as proof of local targeting.
Likely telemetry
- Threat intelligence reporting and infrastructure enrichment for domains, IPs, hosting providers, web services, DNS servers, and serverless endpoints
- Domain registration, passive DNS, certificate transparency, DNS resolution, and registrar-related data where available
- External attack surface and Internet scan data relevant to servers, VPS/cloud infrastructure, and exposed services
- Email security, phishing-reporting, and URL analysis evidence for newly observed or suspicious domains and web services
- Web proxy, secure web gateway, firewall, and DNS logs showing connections to newly acquired or suspicious infrastructure
Detection direction
- Start with inventory: confirm which T1583 sub-technique categories the organization can observe externally and which require third-party threat intelligence or managed detection support.
- Tune for context rather than single indicators. Newly registered domains, VPS/cloud hosting, public web services, or serverless infrastructure can be legitimate, so detections should combine reputation, timing, naming similarity, DNS/certificate changes, campaign context, and internal touchpoints.
- Correlate pre-compromise infrastructure findings with internal telemetry such as phishing submissions, DNS/proxy logs, authentication events, and endpoint/network investigations.
- Account for blind spots: infrastructure can be rapidly provisioned, modified, and shut down; common web services and residential or other proxy infrastructure may blend with normal traffic; and PRE-stage activity may occur before any endpoint event exists.
- Use relationship-driven context carefully. Known groups mapped to this technique can inform threat intelligence requirements, but local detection should be based on observed infrastructure behavior and organization-specific exposure.
Mitigation priorities
- Prioritize M1056 Pre-compromise measures: reduce exposed attack surface, identify adversarial preparation efforts, and increase the cost of using infrastructure against the organization.
- Implement or validate brand/domain monitoring, suspicious domain triage, and processes for rapid blocking or takedown referral where appropriate.
- Maintain external attack surface visibility so suspicious infrastructure can be compared against legitimate organizational assets, partners, and cloud services.
- Ensure email, DNS, proxy, firewall, and cloud logging are retained and searchable for incident response when suspicious infrastructure is identified.
- Define escalation paths between threat intelligence, SOC, incident response, legal/brand protection, and cloud/security operations for infrastructure-related findings.
Additional notes and limits
This object is a parent technique with rich sub-technique context. The strongest defensive value comes from mapping the organization’s visibility against Domains, DNS Server, VPS, Server, Botnet, Web Services, Serverless, and Malvertising rather than treating Acquire Infrastructure as one generic alert. External references supplied by MITRE include reporting on leased criminal hosting, free-trial cloud resource abuse, residential/proxy infrastructure, external detection using scan data, and infrastructure hunting, which supports a threat-intelligence and pre-compromise monitoring emphasis.
Official ATT&CK detection text is not provided for T1583 in the supplied fields. The object is platform PRE, so many observations occur outside the defended environment and may require external data sources, threat intelligence, or third-party monitoring. Relationships to groups show reported use, but they do not establish current activity against any specific organization. Local business risk, telemetry availability, and control effectiveness must be validated in the organization’s own environment.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Acquire Infrastructure
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.