Lesson 25 — IOC Enrichment
Indicators of compromise become useful only when analysts add timing, ownership, reputation, relationships, internal sightings and confidence.
Microsoft Threat Intelligence, Defender entity pages, Microsoft Sentinel and Security Copilot can accelerate enrichment across IP addresses, domains, URLs, file hashes, certificates and email artefacts.
This lesson explains how to turn a raw observable into a validated investigation pivot without mistaking external reputation for proof of internal compromise.
What you will learn
This lesson develops a complete IOC enrichment and validation workflow.
IOC enrichment workflow
↓
Identify the indicator type and original source
↓
Review first seen, last seen and expiration
↓
Use Microsoft Threat Intelligence and Defender entity enrichment
↓
Review reputation, ownership, relationships and sandbox context
↓
Search Defender XDR and Sentinel for internal sightings
↓
Compare timestamps, entities and behaviour
↓
Look for shared infrastructure and legitimate alternatives
↓
Assign confidence and document uncertainty
↓
Choose hunt, detect, block, contain, monitor or dismiss
↓
Recheck the indicator when material evidence changes
IOC enrichment domains
| Domain | Evidence | Core question |
|---|---|---|
| Identity | Indicator type, exact value, normalisation and source. | What observable are we enriching? |
| Freshness | First seen, last seen, publication date and expiration. | Is the intelligence still current? |
| External context | Reputation, hosting, relationships, actors and campaigns. | What do intelligence sources assess? |
| Internal evidence | Devices, users, messages, applications and resources. | Where has the organisation observed it? |
| Confidence | Source reliability, corroboration, relevance and alternatives. | How strongly does the evidence support the assessment? |
| Action | Hunt, detect, block, contain, monitor or dismiss. | What should the organisation do next? |
Learning objectives
- Distinguish observables from validated indicators.
- Enrich IPs, domains, URLs, hashes and certificates.
- Evaluate freshness, provenance and confidence.
- Search for internal Defender and Sentinel sightings.
- Use Microsoft Threat Intelligence and entity pages.
- Validate Sentinel threat-intelligence records.
- Make safer hunt, block and containment decisions.
What is IOC enrichment?
IOC enrichment adds context to an observable such as an IP address, domain, URL, file hash, certificate or email artefact.
Observable versus indicator
An observable is a value seen in data. It becomes an indicator only when threat context and assessment are added.
IOC is not a verdict
A reputation label or external association does not prove internal compromise.
Start with the exact value
Normalise the indicator and preserve its complete form before enrichment.
Indicator type matters
IP addresses, domains, URLs, hashes and certificates require different enrichment questions.
Freshness matters
Infrastructure ownership, reputation and relationships can change over time.
First seen
First-seen dates help determine when an indicator entered intelligence or internal telemetry.
Last seen
Last-seen dates help determine whether the activity is current, historical or stale.
Expiration
Indicators should have a defined validity period so old intelligence does not create permanent noise.
Confidence
Confidence expresses how strongly the source supports the assessment.
Source reliability
A high-confidence claim from an unreliable source should still be treated cautiously.
Provenance
Record where the indicator, reputation and actor association originated.
Internal relevance
An indicator matters more when it appears in the organisation’s own evidence.
Internal sightings
Search Defender XDR and Sentinel for devices, users, messages, applications and resources that observed the indicator.
Prevalence
Determine whether the indicator is rare, common or widely used in legitimate activity.
Shared infrastructure
Cloud hosting, CDNs, proxies, VPNs and compromised websites can serve both legitimate and malicious activity.
Dedicated infrastructure
Dedicated infrastructure can strengthen an association but still requires timing and behavioural evidence.
Historical ownership
An IP or domain may have belonged to a different customer or campaign when earlier reports were written.
Sinkholes and takedowns
Infrastructure can be seized, sinkholed or remediated, making old malicious labels misleading.
IP address enrichment
Review ownership, ASN, hosting, geolocation, services, passive DNS, reputation and internal connections.
Private IP addresses
Private addresses require internal asset context rather than public reputation.
NAT and proxy context
One public IP can represent many users, devices or applications.
IPv4 and IPv6
Check whether related activity uses both address families.
Domain enrichment
Review registration, name servers, passive DNS, certificates, subdomains, age and related infrastructure.
Domain age
A newly registered domain can increase suspicion but does not prove malicious intent.
Subdomain context
A malicious subdomain can exist beneath a legitimate or compromised parent domain.
URL enrichment
Preserve the full path, parameters, redirects, referrer and final destination.
URL path matters
Different paths on the same domain can host unrelated content.
Redirect chains
Tracking services and URL shorteners can hide the final destination.
File-hash enrichment
Review hash type, detections, malware family, prevalence, signer, origin and internal sightings.
SHA256 preference
SHA256 is generally stronger for precise file identification than weaker legacy hashes.
File names are weak
Identical filenames can refer to unrelated files.
Digital signatures
A valid signature can identify a publisher but does not guarantee the file is safe.
Certificate enrichment
Review subject, issuer, serial number, validity dates, SANs, fingerprints and related infrastructure.
Certificate reuse
Shared certificates and automated certificate services can create misleading relationships.
Email indicator enrichment
Review sender domains, reply-to domains, envelope sender, URLs, attachments and authentication context.
SPF pass is not legitimacy
SPF can correctly authenticate an attacker-controlled domain.
Message identifiers
Use Network Message ID and attachment hashes to correlate email evidence reliably.
User-agent enrichment
User agents can add context but are easy to spoof and should not be used alone.
Application identifiers
App IDs, service principals and OAuth consent can become important cloud indicators.
Resource indicators
Cloud resource IDs, storage endpoints and service URLs need tenant and subscription context.
Microsoft Threat Intelligence
Microsoft Threat Intelligence provides infrastructure, actor, campaign, reputation and relationship context in Defender workflows.
Entity-page enrichment
Defender entity pages can surface threat-intelligence insights for IPs, domains, URLs and files.
Reputation scores
Reputation helps prioritise investigation but must be compared with internal evidence and timing.
Attributed threat reports
Actor or campaign associations should be treated as assessments, not automatic attribution.
Infrastructure relationships
Passive DNS, certificates, hosting and related domains can reveal useful pivots.
Sandbox analysis
File and URL sandbox results can provide behavioural context but still require source review.
Security Copilot enrichment
Security Copilot can summarise intelligence, relationships, internal sightings and recommended pivots.
Ask for evidence separation
Require Copilot to separate direct observations, external assessments and analyst inference.
Ask for freshness
Request first seen, last seen, publication date and current relevance.
Ask for internal sightings
Request Defender XDR and Sentinel matches with timestamps and entities.
Ask for source attribution
Require the source for every reputation, campaign and actor claim.
Ask for alternative explanations
Request shared hosting, legitimate software, scanners, CDNs and administrative uses.
Ask for confidence
Require confidence separately for reputation, relationship and attribution.
Microsoft Sentinel threat intelligence
Sentinel stores and uses threat indicators for hunting, analytics, workbooks and incident enrichment.
ThreatIntelIndicators
The current Sentinel threat-intelligence indicator table uses the STIX-aligned ThreatIntelIndicators schema.
ThreatIntelObjects
ThreatIntelObjects can contain additional STIX object types and relationships where supported.
Legacy table awareness
Older content may reference ThreatIntelligenceIndicator, so queries should be updated and validated.
STIX context
STIX represents indicators, threat actors, malware, relationships and other intelligence objects.
Indicator ingestion
Sentinel can ingest intelligence from Microsoft, TIP integrations, APIs and supported feeds.
Defender TI connector
The Defender Threat Intelligence connector can bring Microsoft indicators into a Sentinel workspace.
TIP integration
Threat-intelligence platforms can send approved indicators into Sentinel through supported integrations.
Add incident entities
Supported entities discovered during investigation can be added to Sentinel threat intelligence.
Indicator matching
Analytics and hunts can compare internal events with threat-intelligence indicators.
Matching does not prove compromise
A match can be stale, shared, mistyped or unrelated to the incident.
Normalise indicator types
Ensure IPs, domains, URLs and hashes are compared using compatible formats.
Case and formatting
Domains, URLs and hashes can require consistent casing, schemes and punctuation handling.
Defang and refang carefully
Indicators copied from reports may be defanged and must be normalised safely.
Remove duplicates
Multiple feeds can provide the same indicator with different confidence and expiration.
Merge context carefully
Do not combine conflicting source assessments into one stronger conclusion.
Traffic Light Protocol
Respect TLP handling and sharing restrictions associated with threat intelligence.
Privacy and sensitivity
Internal sightings can expose user, device and customer information.
Blocking decisions
Before blocking, evaluate confidence, business use, shared infrastructure and likely impact.
Detection decisions
Use enriched context to improve analytics without creating excessive false positives.
Hunting decisions
Use indicators as pivots into broader behaviour-based hunting.
Containment decisions
Containment should be driven by confirmed internal evidence, not reputation alone.
Document enrichment
Record indicator, type, source, freshness, internal sightings, confidence and final decision.
Recheck important indicators
High-impact indicators should be re-enriched when the investigation or response changes.
Final analyst judgement
Enrichment supports prioritisation and pivots; the analyst decides whether the indicator is relevant, malicious and actionable.
Example IOC-enrichment prompt
Include:
1. Normalised indicator value and type
2. First seen, last seen, publication date and expiration
3. Registration, hosting, DNS, certificate and infrastructure relationships
4. Reputation scores and attributed reports with source names
5. Internal sightings across devices, users, email, network and cloud activity
6. Related URLs, IP addresses, files, certificates and campaigns
7. Shared-infrastructure and legitimate-use explanations
8. Confirmed observations, external assessments and analyst inference
9. Confidence for relevance, maliciousness and attribution
10. Recommended hunting, detection, blocking and monitoring actions
Do not recommend containment based only on external reputation.
Agent Foskett investigation: “The hash wasn’t the evidence…”
↓
Security Copilot described it as malicious
↓
The initial response recommendation was to isolate every matching device
↓
Agent Foskett reviewed the report date
↓
The intelligence was eighteen months old
↓
The hash belonged to a signed remote-support utility
↓
The utility had once been abused by an attacker
↓
Internal sightings showed the same hash on 214 managed devices
↓
All installations came from the approved software-deployment service
↓
No suspicious parent process, network destination or user activity was present
↓
The hash match was real
↓
The compromise conclusion was not
↓
The file was added to a monitored software inventory
↓
A behaviour-based hunt looked for unauthorised execution and unusual destinations
↓
The hash had started the investigation
↓
The context had decided the verdict
IOC enrichment validation checklist
| Area | Question | Validation action |
|---|---|---|
| Value | Is the indicator complete and correctly normalised? | Preserve the original and reviewed form. |
| Type | Is it an IP, domain, URL, hash, certificate or other observable? | Apply type-specific enrichment. |
| Freshness | When was it first and last seen? | Compare with the incident timeline. |
| Source | Who made the assessment? | Record provenance and reliability. |
| Ownership | Is the infrastructure shared, dedicated or historical? | Review hosting, DNS and certificates. |
| Internal sightings | Where did the organisation observe it? | Search Defender XDR and Sentinel. |
| Behaviour | Does surrounding activity support malicious use? | Review processes, users, messages and network events. |
| Confidence | Are relevance, maliciousness and attribution rated separately? | Document each conclusion independently. |
| Impact | Could blocking disrupt legitimate services? | Assess prevalence and dependencies. |
| Action | Is the chosen response supported by internal evidence? | Approve hunt, detect, block or contain deliberately. |
Key takeaways
- Threat indicators associate observables with assessed malicious activity, but a match does not prove compromise.
- Freshness, expiration, provenance, ownership and internal relevance determine indicator value.
- Microsoft Threat Intelligence is integrated into Defender investigation workflows.
- Defender entity pages can expose threat-intelligence enrichment for IPs, domains, URLs and files.
- Security Copilot can summarise intelligence, relationships and internal sightings but still requires source review.
- Microsoft Sentinel now uses the STIX-aligned ThreatIntelIndicators table for current indicator workflows.
- Shared infrastructure and legitimate dual-use tools create common false-positive risks.
- Indicator matching should lead into behaviour-based hunting rather than automatic attribution.
- Blocking and containment decisions require business-impact and internal-evidence review.
- The final indicator assessment remains a human analyst decision.
What Agent Foskett checked
- Hash type
- Threat-report date
- Digital signature
- Software publisher
- Internal prevalence
- Deployment source
- Parent processes
- Network destinations
- User context
- Final response decision
Best practices
- Normalise the value.
- Check freshness.
- Record provenance.
- Search internal sightings.
- Review ownership.
- Inspect surrounding behaviour.
- Separate confidence levels.
- Consider business impact.
- Prefer behaviour-based pivots.
- Keep judgement human.
Related Agent Foskett resources
Continue the Microsoft Security Copilot Academy
How do you enrich indicators with Microsoft Security Copilot?
Security Copilot can summarise reputation, infrastructure relationships, threat reports, internal sightings and recommended pivots for IP addresses, domains, URLs, files and other observables.
Microsoft Defender Threat Intelligence enrichment
Microsoft Threat Intelligence is integrated into Defender investigation workflows, including entity-page enrichment for IP addresses, domains, URLs and files.
Microsoft Sentinel ThreatIntelIndicators
Microsoft Sentinel stores current STIX-aligned threat indicators in the ThreatIntelIndicators table for hunting, analytics, workbooks and incident enrichment.
