Every alert carries identifiers, addresses, domains, links and file hashes, and the fastest way to triage them is to ask what the rest of the world already knows about each one. MITRE D3FEND names this countermeasure Identifier Reputation Analysis (D3-IRA) and defines it as "Analyzing the reputation of an identifier." It sits under the Detect tactic as a child of Identifier Analysis (D3-ID) and is the parent of four techniques: IP Reputation Analysis, Domain Name Reputation Analysis, File Hash Reputation Analysis and URL Reputation Analysis. This card is the umbrella view: what the four have in common, which ATT&CK techniques D3FEND relates to the family, how to run one reputation pipeline across all identifier types, and how to verify it. Identifier-specific detail lives on each child page, linked below. Basic threat intelligence concepts are in the Threat Intelligence Guide.
Key takeaways
- One pattern, four identifier types. IP addresses, domain names, URLs and file hashes are all looked up against prior knowledge and returned as a score, category or list match. The pipeline, allow lists and verification can be shared.
- D3FEND gives the definition, not the method. D3-IRA has a one-line definition and one patent reference ("Finding phishing sites"); the practice comes from the child techniques and from product documentation.
- Inferred ATT&CK links are about links and lures. D3FEND's inferred relations for D3-IRA are Malicious Link (T1204.001), Drive-by Compromise (T1189), Spearphishing Link (T1566.002) and Spearphishing via Service (T1566.003).
- Identifiers have different lifetimes. A file hash never changes meaning, a domain can be re-registered, and an IP address can be reassigned within hours. Expiry rules must differ by type.
- False positives are the main cost. Shared infrastructure, cloud ranges and popular domains appear in malicious data constantly; warninglists and trusted lists are part of the control, not an extra.
D3-IRA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-IRA (d3f:IdentifierReputationAnalysis) |
| Tactic | Detect |
| Parent technique | Identifier Analysis (D3-ID), with siblings Homoglyph Detection, Identifier Activity Analysis and URL Analysis |
| Child techniques | D3-IPRA IP Reputation Analysis, D3-DNRA Domain Name Reputation Analysis, D3-FHRA File Hash Reputation Analysis, D3-URA URL Reputation Analysis |
| Digital artefacts | Identifiers analysed by the children: IP Address, Domain Name, File Hash, URL |
| D3FEND reference | "Finding phishing sites" (patent US8839418B2) |
| Typical outputs | Reputation score, category, first-seen and last-seen dates, source attribution, alert enrichment |
| Main limitation | Only identifies what has been seen and reported before |
The four child techniques
| Child | Identifier | Where it is usually applied | Lifetime of a verdict |
|---|---|---|---|
| D3-IPRA IP Reputation Analysis | IPv4 or IPv6 address | Mail connections, sign-ins, edge firewalls and WAFs, flow records | Short: addresses are reassigned and shared |
| D3-DNRA Domain Name Reputation Analysis | Domain name | DNS resolvers, mail links, proxy logs | Medium: domains expire, are sold and re-registered |
| D3-URA URL Reputation Analysis | Full URL including path | Mail and chat link scanning, browsers, web proxies | Short to medium: paths on shared hosts change quickly |
| D3-FHRA File Hash Reputation Analysis | Cryptographic hash of a file | Endpoint protection, mail attachments, sandbox and EDR enrichment | Long: a hash always identifies the same bytes, but a one-byte change defeats it |
The lifetime column is NHI Mgmt Group's practical guidance, not a D3FEND statement. It drives expiry: hash entries can stay for years, IP entries should age out in weeks unless re-observed.
ATT&CK techniques D3FEND relates to D3-IRA
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-IRA. The D3FEND site shows the relations below as inferred and experimental, derived through the identifier artefacts the family analyses, chiefly the URL (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | What identifier reputation contributes |
|---|---|---|
| T1566.002 | Spearphishing Link | Reputation of the linked URL and domain at delivery and at click time |
| T1566.003 | Spearphishing via Service | The same lookups for links sent through chat, social and collaboration services |
| T1204.001 | Malicious Link | Blocking or warning when a user opens a link with a bad verdict |
| T1189 | Drive-by Compromise | Reputation of the sites and redirect chain a browser is sent to |
The child D3-IPRA has no ATT&CK relation in D3FEND, because no ATT&CK technique in the graph acts on the IP Address artefact. Deeper treatment of the phishing techniques is in MITRE ATT&CK T1566 Phishing.
Where it is implemented
Platforms are listed alphabetically; the order is not a ranking. These examples show products that handle several identifier types in one place.
| Implementation class | Example feature (vendor or project documentation) | Identifier types |
|---|---|---|
| Cloud threat detection | Amazon GuardDuty threat entity lists, matched against CloudTrail, VPC Flow Logs and Route 53 Resolver DNS query logs, in plain text, STIX and several CSV formats | IP address, domain, SHA-256 file hash |
| Endpoint protection | Microsoft Defender for Endpoint custom indicators with Allow, Audit, Warn, Block execution and (files and certificates) Block and remediate actions, limited to 15,000 indicators per tenant | File hash, IP address, URL and domain, certificate |
| Threat intelligence platform | MISP warninglists flag indicators that are likely false positives, with list types string, substring, hostname, cidr and regex, and lists such as public-dns-v4, rfc1918, tor-exit-nodes and cloud provider ranges | Any attribute type |
| Mail and DNS-based lists | DNS-based lists queried in the RFC 5782 format, returning an A record in 127.0.0.0/8 and an optional TXT reason | IP address and domain name |
A SIEM or SOAR enrichment step usually ties these together: every alert's identifiers are extracted, looked up in each source, and the verdicts with their source and age are written onto the alert. See the STIX and TAXII Guide for feed exchange formats.
Implementation steps
- Extract identifiers consistently. Normalise case, strip URL tracking parameters for lookup (keep the original for evidence), refang defanged indicators, and record the field each identifier came from.
- Register sources per identifier type. For each source record identifier types, categories, update interval, licence and an owner. One source per type is a weak design; two independent sources catch more.
- Load allow lists first. Own domains and egress addresses, partners, public resolvers, CDN and cloud ranges, and common software hashes. Apply them before threat matching.
- Set expiry by type. For example hashes long-lived, domains and URLs months, IP addresses weeks (NHI Mgmt Group examples, not a standard), renewed only when re-observed.
- Start with enrichment and audit. Write verdicts onto alerts and use Audit or Count actions for two to four weeks before any block.
- Block selectively. Promote high-confidence categories per identifier type to block; keep low-confidence categories as scoring inputs.
- Roll back cleanly. Keep a fast path to remove a wrong indicator from every enforcing control at once, since the same bad entry is often pushed to mail, proxy and endpoint together.
How to verify it works
- Per-type synthetic test: monthly, add one controlled test indicator of each type (a lab address, a test domain you own, a test URL, the hash of a harmless test file) to the threat list and confirm the alert fires in each control that should see it.
- Source health: confirm each feed updated within its expected interval and each list is loaded and active; for DNS-based lists, check the RFC 5782 test entries.
- Enrichment coverage: sample alerts and confirm every identifier carries a verdict, a source and an age, not a blank.
- Retrospective check: after each confirmed incident, look up its identifiers as of the incident date and record whether any source knew them.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Identifier types passing the monthly synthetic test | 4 of 4 | Each child technique proven end to end |
| Alerts with reputation enrichment on every identifier | Above 95% | Analysts get context without manual lookups |
| Enforcing matches later judged benign | Falling each quarter | Cost of false positives |
| Incidents whose identifiers were known to a source beforehand | Tracked per incident | Whether the sources see your attackers |
Limits, bypasses and failure patterns
- Novel infrastructure: new domains, fresh hosts and recompiled files have no reputation. Pair reputation with behaviour: see D3-IAA Identifier Activity Analysis and D3-HD Homoglyph Detection.
- Trusted platforms as hosts: lures placed on reputable cloud storage, collaboration or code hosting domains inherit the platform's good domain reputation. URL-level verdicts are needed, not domain-level ones.
- Stale entries: an indicator never expired blocks a reassigned address or a re-registered domain years later.
- One indicator in many places: a bad entry pushed to mail, proxy and endpoint at once causes a wide outage, and removing it from only one control leaves the others blocking.
- Lookup privacy: sending internal URLs or file hashes to public lookup services can disclose internal names or unreleased files. Review what leaves the organisation.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring with threat context applied |
| NIST SP 800-53 Rev 5 | PM-16 Threat Awareness Program; SI-5 Security Alerts, Advisories, and Directives | Receiving and using threat intelligence |
| NIST CSF 2.0 | ID.RA-02, DE.AE-07 | Threat intelligence received and integrated into analysis |
| MITRE D3FEND | D3-ID, D3-IRA and children D3-IPRA, D3-DNRA, D3-FHRA, D3-URA | Family position |
Practitioner checklist
- Normalise and refang identifiers before lookup, and keep the original for evidence.
- Register every reputation source with identifier types, categories, update interval and owner.
- Apply allow lists and warninglists before threat matching.
- Set expiry rules per identifier type.
- Enrich alerts with verdict, source and age for every identifier.
- Run new indicator sets in Audit or Count before blocking.
- Keep one removal path that clears a wrong indicator from every control.
- Run a monthly synthetic test per identifier type.
Standards and references
- MITRE D3FEND: Identifier Reputation Analysis (D3-IRA)
- IETF: RFC 5782 DNS Blacklists and Whitelists
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- AWS: GuardDuty trusted and threat lists
- Microsoft Learn: Defender for Endpoint indicators overview
- MISP Project: misp-warninglists
Related NHI Mgmt Group resources: Threat Intelligence Guide · Threat Intelligence Feed Evaluation Guide · MISP Threat Sharing Guide · IOC Scanners Guide · MITRE D3FEND Guide