A threat intelligence feed full of indicators is worth little until someone asks the question that matters: has any of this already touched our systems, and what did it touch? MITRE D3FEND names that question Identifier Activity Analysis (D3-IAA) and defines it as "Taking known malicious identifiers and determining if they are present in a system." It sits under the Detect tactic as a child of Identifier Analysis (D3-ID) and analyses the Identifier artefact: IP addresses, domain names, hostnames, URLs and file hashes. This card explains how D3-IAA works, which ATT&CK techniques D3FEND relates it to, how security analytics platforms implement it, and how to prove that indicator matching and retrospective search actually find what they should. It is for detection engineers, threat intelligence analysts and threat hunters.
Key takeaways
- It answers "where", not "is it bad". Reputation techniques judge an identifier; D3-IAA takes identifiers already judged malicious and finds the hosts, processes, files and accounts that interacted with them.
- Look back as well as forward. A new indicator should be matched against stored telemetry, not only against new events, because the activity it describes may predate the report.
- Precise but short lived. D3FEND notes the analysis is high precision but adversaries change hashes, IP addresses and domains quickly, the bottom of David Bianco's Pyramid of Pain.
- Coverage depends on the fields you log. D3FEND lists network traffic, process activity, file activity and registry settings as the activity data of interest; a missing field is a blind spot.
- D3FEND relates it to four ATT&CK techniques. All are inferred through the URL sub-artefact of Identifier: Drive-by Compromise, Malicious Link, Spearphishing Link and Spearphishing via Service.
D3-IAA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-IAA (d3f:IdentifierActivityAnalysis) |
| Tactic | Detect |
| Parent technique | Identifier Analysis (D3-ID) |
| Digital artefact | Identifier (D3FEND relation: analyzes). Sub-artefacts in D3FEND include IP Address, Domain Name, Hostname, URL, MAC Address and Digital Fingerprint (which includes File Hash) |
| D3FEND reference | David Bianco, "The Pyramid of Pain" |
| Typical data sources | DNS logs, proxy and firewall logs, process creation events, file events, registry events, email logs, cloud audit logs |
| Effort | Low with built-in matching rules; medium to high for retrospective search across long retention |
| Main limitation | Only finds what the indicator set already names; quality of results equals quality of the indicators |
How it works
D3FEND describes D3-IAA as taking identifiers, typically known malicious indicators of compromise from open and closed sources, and determining which artefacts have interacted with them. Its example source is VirusTotal, which holds malware hashes and IP addresses used by threat actors. In practice the work has four stages.
- Collect indicators: from commercial and open feeds, sharing communities, government advisories and your own incident findings, usually through a threat intelligence platform. STIX 2.1 (an OASIS Standard since June 2021) is the common exchange format, and its Sighting object records that an indicator was seen. See the STIX and TAXII Guide.
- Normalise: map each indicator type to the log fields that can contain it, for example a domain to DNS query names and proxy request hosts, and a SHA-256 to process and file event hashes.
- Match: run continuous matching on new events and a retrospective search across retained data when a new indicator arrives.
- Pivot: for every hit, follow the activity D3FEND lists: the network connections, processes, files and registry settings that reference the identifier, and the user or service account behind them.
Where identity fits
The pivot step usually ends at an identity. A host that resolved a known command and control domain will have a logged-on user and often a service account or token in use; a matched cloud IP address in an audit log names the access key or workload identity that made the call. Scoping which credentials were exposed is the job of D3-CCSA Credential Compromise Scope Analysis, and identity-focused indicators are covered in Threat Intelligence for Identity and NHI.
ATT&CK techniques D3FEND relates to D3-IAA
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-IAA. The rows below are inferred through a shared digital artefact: D3-IAA analyzes Identifier, and these techniques produce or access a URL, which D3FEND models as a kind of Identifier. D3FEND labels such relations inferred and experimental (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via sub-artefact) | What identifier activity analysis finds |
|---|---|---|---|
| T1189 | Drive-by Compromise | Produces URL | Hosts whose proxy or DNS logs show a visit to a known compromised or malicious site |
| T1204.001 | User Execution: Malicious Link | Accesses URL | Users who clicked a link later reported as malicious |
| T1566.002 | Phishing: Spearphishing Link | Produces URL | Every mailbox that received a message with the reported URL, and who opened it |
| T1566.003 | Phishing: Spearphishing via Service | Produces URL | Endpoints that reached a malicious URL shared through chat or social media |
D3FEND also relates the ICS technique T0817 Drive-by Compromise through the same artefact. In practice D3-IAA is used far more widely than these four rows, for any technique that leaves a known identifier in logs, but that wider use is an NHI Mgmt Group view, not a D3FEND mapping. See MITRE ATT&CK T1189 Drive-by Compromise and MITRE ATT&CK T1566 Phishing for the techniques themselves.
Where it is implemented
Platforms are listed alphabetically and named only as examples of a class.
| Implementation class | Example feature | Identifier types and data | Fits when |
|---|---|---|---|
| SIEM indicator matching | Elastic Security indicator match rules (rule type threat_match) map source fields to indicator fields, for example destination.ip to threat.indicator.ip and file.hash.sha256 to threat.indicator.file.hash.sha256; the default indicator index query covers indicators from the last 30 days | Any field you map | You manage your own indicator index |
| SIEM indicator matching | Microsoft Sentinel's built-in Microsoft Defender Threat Intelligence Analytics rule matches Microsoft indicators (domains and IPv4, and URLs in CEF logs) against tables including CommonSecurityLog, DnsEvents, OfficeActivity, AzureActivity and the ASIM DNS and network session tables, grouping alerts per indicator over 24 hours | Domains, IPv4, URLs | You want vendor-curated indicators with no index to manage |
| Threat intelligence platform | Sightings, scoring, expiry and push of indicators to detection tools | All types | Several feeds need de-duplication and lifecycle control |
| EDR and endpoint IOC scanning | Sweep of live endpoints for hashes, file paths, registry keys and connections | Host artefacts | Telemetry retention is short or fields are missing; see the IOC Scanners Guide |
| Hunt notebooks and queries | Analyst-driven searches in KQL, SPL or similar | Any logged field | One-off advisories and incident scoping |
Availability: Elastic documents that indicator match rules do not support look-back times over 24 hours or cold and frozen data tiers, so long retrospective searches need a separate query. Microsoft documents that its matching rule needs the relevant data connector and Content hub solution installed, and that it does not require a premium Defender Threat Intelligence licence.
Implementation steps
- Inventory fields against indicator types. For each type (IP, domain, URL, hash, file path, registry key) list the log sources and fields that carry it, and fill the gaps that matter, such as SHA-256 in process events or DNS query logging on resolvers.
- Choose feeds deliberately. Prefer fewer, scored feeds relevant to your sector over volume. Assess them with the Threat Intelligence Feed Evaluation Guide.
- Set indicator lifetimes. Give IP and domain indicators short expiry and hashes longer expiry, reflecting how fast each changes; expired indicators should stop alerting but stay searchable.
- Enable continuous matching. Turn on built-in matching rules or write your own, mapping each indicator type to its fields, with severity raised where traffic was allowed rather than blocked.
- Add retrospective search. On arrival of a high-confidence indicator, run a scheduled search back across retained data, for example 90 days (an NHI Mgmt Group suggestion, not a standard), and record the result as a sighting.
- Pilot and tune. Run for two weeks, review hits, and remove indicators that match shared infrastructure such as content delivery networks or large cloud providers.
- Feed results back. Record sightings and false positives in the intelligence platform so feed scores and expiry improve.
How to verify it works
- Planted indicator test: add a benign domain, IP address or file hash that you know appears in yesterday's logs to the indicator set as a test indicator, and confirm the matching rule alerts with the right host and user.
- Retrospective test: repeat with an identifier last seen 30 or more days ago to prove the look-back search reaches it.
- Field coverage check: measure the share of events per source where the mapped field is populated, for example DNS query names and process SHA-256.
- Advisory drill: take a recent public advisory, load its indicators, and time how long the team takes to answer "seen or not seen" across the estate.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Time from indicator receipt to estate-wide "seen or not seen" answer | Under 4 hours for high-priority advisories | The core value of D3-IAA |
| Planted test indicators detected | 100% | Proves mapping and rules work end to end |
| Indicator types with mapped, populated fields | All types in use | Unmapped types fail silently |
| Matches closed as false positive | Falling month on month | Shows feed and expiry tuning |
| Active indicators past expiry | Zero | Stale indicators create noise and cost |
Limits, bypasses and failure patterns
- Indicators change faster than feeds: D3FEND's considerations cite the Pyramid of Pain: hashes are trivial and IP addresses very easy for an adversary to change, so a clean result never proves absence. Pair D3-IAA with behavioural detection.
- Shared infrastructure: IP addresses of cloud and content delivery providers appear in feeds and match huge volumes of benign traffic.
- Short look-back: matching only new events misses activity that happened before the report was published.
- Retention gaps: if DNS or proxy logs are kept for 7 days and advisories arrive 30 days after an intrusion, the evidence is gone.
- No pivot: alerting on the hit without following process, file and account activity leaves the scope unknown.
- Trusting a single source: one feed's false positive becomes your block list. Score and corroborate.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring for indicators of attack and compromise |
| NIST SP 800-53 Rev 5 | SI-5 Security Alerts, Advisories, and Directives; PM-16 Threat Awareness Program | Receiving and acting on threat information |
| NIST CSF 2.0 | ID.RA-02, DE.AE-07, DE.AE-02 | Receiving threat intelligence; integrating it into analysis; analysing adverse events |
| MITRE ATT&CK | M1019 Threat Intelligence Program | The programme that supplies the identifiers; see M1019 Threat Intelligence Program |
| MITRE D3FEND | D3-ID, D3-IAA | Parent and technique |
Related countermeasures
- Identifier Reputation Analysis (D3-IRA): judges whether an identifier is malicious before or as it is used. See D3-IRA Identifier Reputation Analysis.
- File Hash Reputation Analysis (D3-FHRA): the hash-specific reputation check. See D3-FHRA File Hash Reputation Analysis.
- Homoglyph Detection (D3-HD): finds lookalike domains that can then be searched for with D3-IAA. See D3-HD Homoglyph Detection.
Practitioner checklist
- Map every indicator type you ingest to the log fields that can contain it.
- Log DNS queries, proxy requests and process SHA-256 hashes across the estate.
- Set expiry per indicator type and keep expired indicators searchable.
- Run retrospective searches when high-confidence indicators arrive.
- Raise severity where matched traffic was allowed rather than blocked.
- Pivot every hit to processes, files, registry and the identity involved.
- Plant a test indicator monthly and record detection.
- Record sightings and false positives back in the intelligence platform.
- Exclude shared cloud and CDN infrastructure from blocking lists unless corroborated.
Standards and references
- MITRE D3FEND: Identifier Activity Analysis (D3-IAA)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-4, SI-5)
- OASIS: STIX Version 2.1
- Elastic Docs: Indicator match rules
- Microsoft Learn: Use matching analytics to detect threats (Microsoft Sentinel)
- Microsoft Learn: Sysmon
- David Bianco: The Pyramid of Pain
Related NHI Mgmt Group resources: MITRE D3FEND Guide · Indicators of Compromise vs Indicators of Attack Guide · Threat Hunting Guide · MISP Threat Sharing Guide · STIX and TAXII Guide