Most security teams already buy reputation feeds and block lists, yet still miss the phishing link on a domain registered yesterday that looks almost exactly like their own. MITRE D3FEND groups the analysis of IP addresses, domain names, URLs, file hashes and similar identifiers under Identifier Analysis (D3-ID), a technique in the Detect tactic with eight child techniques. Each child catches something the others miss: reputation lookups find what is already known to be bad, URL analysis and homoglyph detection judge identifiers nobody has rated yet, and identifier activity analysis searches your own telemetry for where an identifier has already been. This guide explains how the family fits together, how to choose and combine the children, where each sits in a mail, web and endpoint pipeline, and how to measure it. It is written for detection engineers, SOC leads and threat intelligence teams. Each child has its own page on this site; this page does not repeat them. For D3FEND itself see the MITRE D3FEND Guide.
Key takeaways
- Identifier Analysis judges the name, not the behaviour. D3FEND defines it as analysing identifier artefacts such as IP addresses, domain names or URLs, which makes it fast and cheap but easy for an attacker to sidestep by changing the identifier.
- The family has eight children in two levels. Identifier Reputation Analysis contains four reputation children (domain name, file hash, IP and URL); URL Analysis, Homoglyph Detection and Identifier Activity Analysis sit directly under D3-ID.
- Reputation and structural analysis cover different gaps. Reputation knows yesterday's bad identifiers; URL analysis and homoglyph detection judge today's new ones. Use both.
- Activity analysis turns intelligence into scope. Searching logs for a bad identifier tells you who already touched it, which reputation checks at the gateway cannot.
- D3FEND's ATT&CK links for D3-ID are narrow and inferred. They centre on phishing, malicious links and drive-by compromise, and the site labels them inferred and experimental.
What D3FEND means by Identifier Analysis
In the D3FEND ontology D3-ID sits directly under Defensive Technique and enables the Detect tactic. Its definition is analysing identifier artefacts such as IP address, domain names, or URL(I)s. Across the children D3FEND relates the family to six digital artefacts that it analyses: IP Address, Domain Name, URL, File Hash, Email and the general Identifier class.
The practical limit of the family is well described by David Bianco's Pyramid of Pain, which D3FEND cites for Identifier Activity Analysis. Hash values sit at the bottom because changing one bit produces a new hash; IP addresses are easy to change; domain names are harder, because they must be registered, paid for and hosted, but still not difficult. Identifier Analysis therefore works best as a fast first filter and a scoping tool, paired with behavioural techniques higher up the pyramid such as Process Analysis and network traffic analysis.
The child techniques
Every child technique in the D3FEND ontology under D3-ID, as of November 2026. Indented names are children of the row above.
| D3FEND technique | Artefact analysed | One-line purpose |
|---|---|---|
| D3-IRA Identifier Reputation Analysis | Identifier (parent of the four below) | Analyse the reputation of an identifier |
| D3-DNRA Domain Name Reputation Analysis | Domain Name | Score a domain using known history, age and associations |
| D3-FHRA File Hash Reputation Analysis | File Hash | Check whether a file's hash is known good, known bad or unknown |
| D3-IPRA IP Reputation Analysis | IP Address | Score an IP address using known abuse and hosting context |
| D3-URA URL Reputation Analysis | URL | Check a full URL against known phishing and malware listings |
| D3-UA URL Analysis | URL | Judge a URL as benign or malicious from its structure and components |
| D3-HD Homoglyph Detection | Email, URL | Detect strings built to look like a trusted name using different characters |
| D3-IAA Identifier Activity Analysis | Identifier | Take known malicious identifiers and find where they appear in your systems |
The children fall into three working groups. Known-bad lookups (IRA and its four children) depend on a feed or service. Structural judgement (UA and HD) works on identifiers no feed has rated, using the identifier itself. Retrospective search (IAA) runs over your own logs and is the bridge from threat intelligence to incident scope.
How to choose and combine the children
| Question you need answered | Child technique | Where it usually runs | Main weakness |
|---|---|---|---|
| Is this domain, IP, URL or hash already known to be bad? | IRA family (DNRA, IPRA, URA, FHRA) | Mail gateway, web proxy, protective DNS, EDR, SIEM enrichment | New or rotated identifiers have no reputation yet |
| Does this unrated URL look malicious? | UA | Mail and web gateways, browser isolation, sandbox triage | False positives on long or unusual legitimate URLs |
| Is this name pretending to be ours or a supplier's? | HD | Mail gateway display name and sender checks, domain monitoring | Needs an accurate list of protected names |
| Has anyone here already contacted this identifier? | IAA | SIEM, DNS and proxy logs, EDR telemetry, mail trace | Only as good as log retention and coverage |
A sensible combination, which is our recommendation rather than a D3FEND requirement, layers them in the order an identifier is met:
- At the edge: URL reputation and domain reputation on every inbound link and outbound web request, with URL analysis for links that have no reputation.
- On sender and link names: homoglyph detection against a maintained list of your own domains, brands, executives and key suppliers.
- On files: file hash reputation as a fast verdict before sandboxing or behavioural analysis, never as the only check.
- In the SOC: enrich every alert with IP, domain and hash reputation so analysts see context without pivoting between tools.
- After new intelligence arrives: identifier activity analysis across DNS, proxy, mail and endpoint logs for the retention period, to find earlier contact.
Implementation roadmap
- Inventory where identifiers are already checked. List each control that does a reputation, URL or lookalike check, which feeds it uses, and whether its verdicts are logged. Most organisations find overlap at the edge and gaps in the SOC.
- Centralise identifier logging. DNS queries, proxy requests, mail URLs and process network connections must reach the SIEM with timestamps and a host or user, or IAA cannot work. See the DNS Security Guide.
- Define protected names. Build the homoglyph reference list: your registered domains, product names, executive names and the domains of suppliers who invoice you.
- Normalise before comparing. Parse URLs into their components before analysis. RFC 3986 (STD 66) defines the generic syntax as scheme, authority (userinfo, host, port), path, query and fragment, and warns in Section 7.6 that userinfo placed before the host can make a URI look as though it points to a trusted name when it does not. Convert internationalised domain names to a single form before matching.
- Run new blocking in monitor mode. Log what URL analysis and homoglyph rules would block for two to four weeks, review false positives with business owners, then enforce in stages with an allow-list process and a named owner who can roll back.
- Automate retrospective search. When a feed or incident adds an identifier, run IAA automatically against stored logs and open a case for any hit.
Registration data helps several children. RDAP, specified for JSON responses in RFC 9083 (Internet Standard, STD 95), returns domain events such as registration and expiration with dates, which supports domain age checks in DNRA and lookalike triage in HD.
ATT&CK techniques D3FEND relates to Identifier Analysis
D3FEND relates D3-ID to offensive techniques through the artefacts it analyses and states that these mappings are "inferred, experimental, and will improve as the knowledge graph grows". For the parent the Enterprise list is short:
| Tactic | ATT&CK v20 technique | Child most involved (our reading) |
|---|---|---|
| Initial Access | T1566.001 Spearphishing Attachment | FHRA, URA for embedded links |
| Initial Access | T1566.002 Spearphishing Link | URA, UA, HD |
| Initial Access | T1566.003 Spearphishing via Service | URA, UA |
| Initial Access | T1189 Drive-by Compromise | DNRA, URA, IPRA |
| Execution | T1204.001 Malicious Link | URA, UA |
| Lateral Movement | T1534 Internal Spearphishing | URA, IAA |
| Collection | T1114.001 Local Email Collection | HD (D3FEND relates HD to Email) |
The attacker side of this picture is infrastructure acquisition: registering lookalike domains and staging link targets. ATT&CK models that under Resource Development as T1583.001 Domains and T1608.005 Link Target, which D3FEND does not list for D3-ID; the ATT&CK Resource Development Tactic Guide covers that tactic. See the MITRE ATT&CK T1566 Phishing and T1583 Acquire Infrastructure guides.
Where identity fits
Identifier Analysis is a strong control for one identity problem: credential phishing. Lookalike sign-in pages and consent phishing links are the main way user and administrator credentials are stolen, and HD plus URA catch many of them before a user types anything. The same checks apply to machine traffic: a workload or CI runner that suddenly resolves a newly registered domain, or a service account whose API calls come from an IP with a poor reputation, is worth an alert. Enrich identity provider sign-in logs with IP reputation and compare against the IP ranges where your non-human identities normally run. See the Threat Intelligence for Identity and NHI Guide.
Detection and measurement
Useful detections include first-seen domains with a young registration date contacted by more than one host, display names matching an executive from an external domain, IAA hits on identifiers older than the gateway block, and reputation verdicts that changed from unknown to malicious after delivery. Metrics we suggest at NHI Mgmt Group:
- Coverage: percentage of inbound mail URLs, outbound web requests and DNS queries that receive a reputation verdict.
- Unknown share: percentage of identifiers with no reputation, which shows how much depends on UA and HD.
- Retro-hit rate: IAA hits per new batch of indicators, and the median age of the earliest hit.
- Time to retro-search: time from an identifier entering the platform to the completed log search.
- Lookalike detection: number of homoglyph domains of protected names found before first use against you.
- False positive rate: user-reported or analyst-closed false blocks per thousand verdicts.
Framework mapping
| Framework | Reference | Link to D3-ID |
|---|---|---|
| NIST CSF 2.0 | ID.RA-02, DE.AE-07 | Threat intelligence received and integrated into analysis |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Network monitoring and analysis of adverse events |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring, SI-8 Spam Protection, SI-5 Security Alerts, Advisories, and Directives | Gateway and SOC identifier checks |
| NIST SP 800-53 Rev. 5 | PM-16 Threat Awareness Program | Sharing and consuming indicators |
| NIST SP 800-150 | Guide to Cyber Threat Information Sharing | Sourcing, scoping and using indicators |
| ISO/IEC 27001:2022 Annex A | 5.7 Threat intelligence, 8.16 Monitoring activities | Intelligence and monitoring controls |
Common failure patterns
- Treating reputation as the whole control. A clean verdict on a domain registered an hour ago is not evidence it is safe; unknown should trigger URL analysis or sandboxing, not delivery by default.
- Hash lists as malware defence. As the Pyramid of Pain notes, a one-bit change defeats a hash match. Use FHRA for speed and triage, with behavioural detection behind it.
- Stale indicator lists. IP addresses are reassigned to legitimate tenants on shared hosting and cloud platforms; indicators without an expiry cause false positives and analyst fatigue.
- Retrospective search with short retention. IAA cannot find contact older than your DNS and proxy log retention, which is often shorter than an intruder's dwell time.
- Homoglyph rules with no protected list. Without an owned list of brands, domains and executives, lookalike detection either fires on everything or on nothing. See the Typosquatting and Lookalike Domains Guide.
- Comparing raw strings. Matching URLs without parsing them misses userinfo tricks, encoded characters and internationalised names.
Practitioner checklist
- Map each of the eight D3-ID children to a control, feed and owner.
- Send DNS, proxy, mail URL and endpoint connection logs to the SIEM with enough retention for retrospective search.
- Route identifiers with no reputation to URL analysis or sandboxing rather than default allow.
- Maintain a protected-names list for homoglyph detection, including key suppliers.
- Parse URLs and normalise internationalised names before any comparison.
- Give every indicator a source, a confidence and an expiry date.
- Run identifier activity analysis automatically when new indicators arrive.
- Enrich identity provider sign-in logs, including those of non-human identities, with IP reputation.
Standards and references
- MITRE D3FEND: Identifier Analysis
- NIST: SP 800-150 Guide to Cyber Threat Information Sharing
- IETF: RFC 3986 Uniform Resource Identifier (URI): Generic Syntax
- IETF: RFC 9083 JSON Responses for the Registration Data Access Protocol (RDAP)
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Phishing
- David Bianco: The Pyramid of Pain
Related NHI Mgmt Group resources: MITRE D3FEND Guide · Threat Intelligence Guide · IOC Scanners Guide · Email Security Guide · MISP Threat Sharing Guide