Security teams can detect Acquire Infrastructure by tracking the registration or use of new domains, hosting, cloud assets or compromised infrastructure that later supports phishing, command and control or malware delivery. Look for suspiciously similar naming, short-lived assets, unusual geographic placement, and infrastructure created near campaign activity.
What security teams should look for first
Acquire Infrastructure is usually visible before it becomes useful: new domains, hosting, cloud assets, CDN endpoints, or compromised systems appear, then get repurposed for phishing, command and control, or malware delivery. The best early signal is not just “new infrastructure,” but infrastructure that is unusually similar to a target brand, created close to campaign activity, or used only briefly.
That means analysts should correlate asset registration, DNS changes, certificate issuance, cloud provisioning, and first-seen network activity rather than treating each event as isolated. Suspicious geographic placement, disposable registrations, and fast turnover are especially important when the infrastructure is meant to blend into normal internet noise.
When the activity aligns with staging, delivery, or beaconing, Command and Control (C2) Guide helps teams connect infrastructure acquisition to downstream C2 behaviour, including beaconing and redirector patterns.
How to separate malicious acquisition from ordinary asset growth
The practical challenge is volume. Organisations continuously add domains, cloud resources, and test infrastructure, so a useful detection strategy needs context, not just raw novelty. The question is whether the new asset has properties that fit adversary tradecraft: short lifespan, naming that imitates a real service, hosting patterns that do not match the organisation, or links to known malicious delivery behaviour.
Look for combinations rather than single indicators. A newly registered domain is not enough on its own, but a newly registered domain that resolves to a fast-changing host, sits behind privacy-heavy registration, and is used in phishing infrastructure becomes much more meaningful. The same is true for cloud assets that appear suddenly, are externally exposed, and are provisioned in a way that does not match normal engineering workflows.
Infrastructure review is easier when the underlying environment is well governed, and Infrastructure as Code Security Guide gives practitioners a useful lens for spotting drift, unusual provisioning, and template-driven abuse.
Detection logic that scales across domains
Good detection programs treat Acquire Infrastructure as an enrichment problem. Build alerts around first-seen domains, certificate patterns, hosting reuse, lookalike naming, and infrastructure adjacency to known campaign windows. Add passive DNS, WHOIS, cloud telemetry, and threat intel so analysts can pivot from a single suspicious asset to the broader infrastructure set.
Teams should also examine whether the same actor-controlled footprint supports more than one phase of an operation. Infrastructure acquired for phishing may later support payload hosting, redirect chains, or C2 failover, so the detection logic should preserve history across domains, IPs, and providers. That makes it easier to identify campaign infrastructure even when individual components are replaced.
For cloud-heavy environments, AI Infrastructure Workload Identity Guide is relevant because it highlights how modern infrastructure sprawl creates reusable identity and access patterns that defenders can monitor for abnormal provisioning and service reuse.
Risk and Threat Considerations
Acquire Infrastructure matters because the attacker does not need to keep using the same asset for long. Once a domain, host, or cloud resource is acquired and put into service, it can be rotated, abandoned, or repurposed to evade blocklists and dilute attribution. That makes the control problem partly one of timing, because by the time an asset is widely visible, it may already have served its operational purpose.
Failure mechanism: Defenders miss the acquisition phase when they focus only on active malicious traffic and do not correlate registration, provisioning, and first-use telemetry across domains, hosts, and cloud services. Short-lived or lookalike infrastructure then survives long enough to support phishing, payload delivery, or C2 before it is blocked.
Impact: The organisation sees later-stage abuse but loses the chance to disrupt the campaign early, which increases delivery success, weakens attribution confidence, and can leave compromised infrastructure or related accounts available for repeat use.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1583 — Acquire Infrastructure | This subject is the acquisition of domains, hosting, and cloud assets for operations. |
| Recommendation — Map observed infrastructure patterns to T1583 and hunt for staging activity in your detection pipeline. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Detecting malicious infrastructure depends on monitoring domain, DNS, hosting, and cloud anomalies. |
| DE.AE-02 — Adverse Events Analyzed | Suspicious infrastructure must be correlated and analysed to determine whether it supports an attack. | |
| Recommendation — Monitor infrastructure telemetry for first-seen and lookalike assets tied to hostile activity. Correlate infrastructure events with campaign timing and determine whether they indicate malicious support. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Acquired infrastructure often exploits exposed or unmanaged assets that need continuous discovery and review. |
| CIS-13 — Network Monitoring and Defense | Network monitoring is central to spotting beaconing, redirectors, and malicious hosting after acquisition. | |
| Recommendation — Continuously inventory and review externally exposed assets to catch suspiciously new infrastructure. Use network monitoring to surface newly active infrastructure and suspicious outbound patterns. | ||
Practitioner Guidance
What to prioritise: Correlate first-seen infrastructure with campaign timing, domain similarity, DNS behaviour, and cloud provisioning events. If the asset appeared close to suspicious activity and matches hostile naming or hosting patterns, treat it as part of an active operation, not as a standalone anomaly.
What to verify: Confirm who registered or provisioned the asset, when it was created, how quickly it began serving traffic, and whether it is connected to other known malicious endpoints. Preserve the evidence needed to reconstruct the infrastructure chain before it is decommissioned or rotated.
Practitioner takeaway: The most useful detection is usually correlation across time and infrastructure type, because Acquire Infrastructure is often a preparatory step that becomes obvious only when registration, hosting, and malicious use are analysed together.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org