ATT&CK Resource Development Tactic (TA0042) Guide: Spotting Attacker Infrastructure Before It Is Used

Before an adversary sends the first phishing email, it registers domains, rents servers, creates or hijacks accounts, buys tools and stages payloads, and the Resource Development tactic (TA0042) in MITRE ATT&CK describes that preparation. ATT&CK v20 defines it as the adversary "trying to establish resources they can use to support operations", including infrastructure, accounts and capabilities. Most of it happens outside your network, so it is often skipped in detection programmes. Yet some of it is visible: lookalike domains in Certificate Transparency logs and registration feeds, hijacked supplier accounts, and payloads staged on public services. This guide maps the nine Resource Development techniques, explains what defenders can realistically see, and sets out monitoring, takedown and hardening practices. It is written for threat intelligence analysts, SOC teams and brand and domain owners.

Key takeaways

• Resource Development is mostly invisible but not entirely. ATT&CK states that much of this activity takes place outside the visibility of the target organisation; external monitoring of domains, certificates and hosting is the exception that pays off.
• Domains, tools and malware lead the procedure data. In the v20 dataset Tool (T1588.002) has 112 recorded uses, Domains (T1583.001) 66, Malware (T1587.001) 43 and Upload Malware (T1608.001) 39.
• The only mapped mitigation is M1056 Pre-compromise. MITRE says these techniques cannot be easily mitigated with preventive controls, so defence relies on early detection, takedown and making your own assets hard to borrow.
• AI is now part of the tactic. v20 includes Obtain Capabilities: Artificial Intelligence (T1588.007), Generate Content (T1683) and Stage Capabilities: AI Result Poisoning (T1608.007).
• Your accounts and domains are someone else's resources. Hijacked mailboxes (T1586), compromised servers (T1584.004) and expired or dangling domains are reused against your customers and partners.

How the attack works

Resource Development sits between Reconnaissance and Initial Access. The adversary decides what it needs for the operation and acquires it by buying, building or stealing. The nine techniques in v20 cover three kinds of resource.

ATT&CK notes that domains are chosen to resemble legitimate ones, using homoglyphs or a different top-level domain, and that domain hijacking can follow compromise of the registrant's email account or social engineering of a registrar help desk. Access purchased from brokers (T1650) can include planted web shells or remote access. For hijacked accounts specifically, see the MITRE ATT&CK T1586 Compromise Accounts Guide.

Where it shows up

• Phishing campaigns: newly registered lookalike domains with fresh TLS certificates, often obtained free and automatically, hosting credential harvesting pages. See the Typosquatting and Lookalike Domains Guide.
• Ransomware operations: purchased access from initial access brokers and obtained tools (T1588.002) such as commercial remote management software and red team frameworks.
• Espionage: compromised network devices and small office routers chained as relays to hide command and control (T1584.008).
• Supply chain and code signing: stolen or fraudulently obtained code signing certificates used to make malware appear legitimate (T1588.003). In the MSI signing keys leak (2023), firmware image signing and Intel Boot Guard private keys were published after a ransomware breach; no malicious use was reported, but any holder could sign firmware that would look genuine.
• Dangling DNS and expired domains: subdomains pointing at deprovisioned cloud resources, or expired domains still trusted by applications, taken over and reused. See the Subdomain Takeover and Dangling DNS Guide.
• AI-assisted operations: generated phishing content and voice clones (T1683), and web content crafted so AI search summaries cite attacker-controlled pages (T1608.007).

Impact

Resource Development causes no direct damage to the target, but it decides how convincing and resilient the attack will be. A well-aged lookalike domain with a valid certificate and good reputation passes filters that a new one would not. A hijacked partner mailbox defeats sender authentication completely. Bought access removes the initial access phase entirely, which shortens the time from first contact to ransomware. For the organisation whose assets are borrowed, the harm is reputational and sometimes legal: its domains, servers or accounts become part of attacks on others.

Detection

v20 attaches a detection strategy to each technique (for example DET0895 for Acquire Infrastructure and DET0839 for Stage Capabilities). Their analytics use internet scan and domain registration data rather than internal logs, and note that detection effort is often best focused on related later stages such as Initial Access and Command and Control. What defenders can monitor:

How Certificate Transparency helps

RFC 9162 (Certificate Transparency Version 2.0, an Experimental RFC published December 2021 that obsoletes RFC 6962) describes logs as append-only, publicly auditable records of issued TLS certificates, and monitors as parties that fetch log entries to spot certificates for domains they care about. Because browsers expect publicly trusted certificates to be logged, an adversary who wants an HTTPS phishing site usually leaves a public record, often days before the campaign. Watching CT logs for your brand strings, with fuzzy matching for homoglyphs and added words such as "login" or "support", is one of the few early warnings available for this tactic. See the Certificate Transparency Guide.

Metrics that show it is working

• Time to detect lookalikes: median hours from certificate or domain registration to analyst triage.
• Time to takedown: median hours from confirmed malicious site to removal or browser blocklisting.
• Own-domain hygiene: count of dangling DNS records and expiring domains found and fixed each quarter.
• Pre-delivery blocks: share of phishing domains blocked at DNS or proxy before the first user click.

Prevention and hardening

You cannot stop an adversary buying a domain, but you can make your own assets hard to borrow, make lookalikes less useful and shorten their lifetime.

Phased rollout

1. Inventory: list every domain, subdomain, brand string and executive name worth monitoring, and which registrar holds each domain.
2. Lock down your own: registrar MFA and locks, DMARC enforcement, CAA records, dangling DNS clean-up.
3. Monitor: start CT and new registration monitoring with fuzzy matching; triage manually for a month to tune noise.
4. Integrate: feed confirmed lookalikes into DNS, proxy and mail blocklists automatically.
5. Takedown and review: agree the evidence and approval needed for takedown requests; review false takedowns and remove blocks quickly when a domain proves benign.

Decision guidance

• Build or buy monitoring: small organisations can use free CT search and DMARC reporting; organisations with consumer brands or high phishing volume usually need a commercial brand protection or takedown service.
• Defensive registration: register the handful of variants most likely to fool customers; registering every permutation is not sustainable.
• Intelligence depth: infrastructure pivoting and dark web monitoring need trained analysts; without them, focus on your own domain hygiene and fast blocking.

Framework mapping

Where identity fits

Several Resource Development techniques are identity attacks on someone else: hijacked email, social and cloud accounts (T1586) and purchased access (T1650), which is often a set of valid credentials or a session. Registrar, DNS provider and certificate authority accounts are also high-value identities, because control of them lets an attacker redirect your domains or issue certificates. Treat them as privileged accounts with phishing-resistant MFA and named owners. See the Infostealer Threat Guide for how stolen credentials reach access brokers.

Lessons from incidents

• An expired trusted domain is a ready-made resource: in ForcedLeak (reported to Salesforce in July 2025, published September 2025), Noma Labs found that a domain trusted by Salesforce's content security policy had expired, registered it for about USD 5 and showed that a prompt-injected Agentforce agent could send CRM data to it. No attacker exploitation was reported, and Salesforce secured the domain and enforced Trusted URLs. The lesson is to monitor expiry of every domain your applications trust, not only the ones you market.

Common failure patterns

• Ignoring the tactic entirely: no external monitoring, so the first sign of a lookalike domain is a successful phish.
• Letting domains lapse: expired domains still referenced in code, allow lists or old marketing are re-registered by others.
• Registrar accounts on a shared mailbox password: one phished account can redirect the whole domain.
• Blocking without feedback: lookalikes found but never fed into DNS, proxy and mail controls.
• DMARC stuck at p=none: spoofing remains possible years after monitoring began.

Practitioner checklist

• Inventory domains, subdomains and brand strings, with an owner and registrar for each.
• Enable registrar MFA, registrar lock and registry lock on critical domains.
• Monitor Certificate Transparency and new registrations for brand lookalikes.
• Publish CAA records and monitor CT for certificates on your own domains.
• Enforce DMARC at p=reject, including on parked domains.
• Find and remove dangling DNS records; track expiry of domains your applications trust.
• Feed confirmed malicious domains into DNS, proxy and mail blocklists automatically.
• Agree a takedown process with evidence requirements and target times.
• Monitor infostealer and broker sources for your domains and tenants, and act on exposures.

Standards and references

• MITRE ATT&CK: Resource Development (TA0042)
• MITRE ATT&CK: Acquire Infrastructure (T1583)
• MITRE ATT&CK: Stage Capabilities (T1608)
• MITRE ATT&CK: Acquire Access (T1650)
• IETF: RFC 9162 Certificate Transparency Version 2.0
• NCSC: Active Cyber Defence Takedown Service
• CISA: Protective Domain Name System Resolver
• MITRE D3FEND: Domain Registration Takedown

Related NHI Mgmt Group resources: MITRE ATT&CK T1586 Compromise Accounts Guide · Typosquatting and Lookalike Domains Guide · Certificate Transparency Guide · MITRE ATT&CK Guide for Defenders