Lesson 16 — Threat Intelligence with Copilot
Threat intelligence helps analysts understand adversaries, campaigns, infrastructure, malware, indicators and behaviours beyond the immediate alert.
Security Copilot can summarise Microsoft Defender Threat Intelligence content, prioritise threats using organisational exposure and help transform intelligence into hunting and response questions.
This lesson explains how to enrich indicators, evaluate freshness and confidence, use Sentinel threat intelligence and avoid turning infrastructure overlap into unsupported attribution.

What you will learn
This lesson develops a complete threat-intelligence enrichment and validation workflow.
Threat-intelligence workflow
↓
Use Security Copilot and Defender Threat Intelligence to summarise context
↓
Review reports, profiles, infrastructure and related indicators
↓
Check freshness, confidence, provenance and relevance
↓
Compare external intelligence with internal Defender and Sentinel evidence
↓
Separate observed facts, assessment and attribution
↓
Translate validated intelligence into hunts, analytics and response priorities
↓
Review agent-generated briefings or hunts
↓
Document findings, limitations and operational actions
Threat-intelligence evidence domains
| Domain | Evidence | Investigation question |
|---|---|---|
| Actor and campaign | Profiles, reports, targeting, malware, infrastructure and observed behaviour. | Who or what operation may be relevant? |
| Indicator | IP, domain, URL, hash, certificate, email or other observable. | What artefact can be enriched or matched? |
| Infrastructure | Hosting, DNS, certificates, services and historical relationships. | How are systems and artefacts connected? |
| TTP | MITRE ATT&CK tactics, techniques, tools and procedures. | What behaviour should analysts detect or hunt? |
| Internal exposure | Affected technologies, vulnerabilities, assets, incidents and identities. | Why does this intelligence matter here? |
| Operational action | Hunts, analytics, blocks, briefings and remediation priorities. | What should the organisation do next? |
Learning objectives
- Distinguish actors, campaigns, IOCs and IOAs.
- Use Defender Threat Intelligence with Copilot.
- Enrich IPs, domains, URLs, hashes and certificates.
- Manage Sentinel threat indicators.
- Use threat-intelligence and hunting agents.
- Evaluate freshness, confidence and provenance.
- Avoid unsupported attribution.
What is threat intelligence?
Threat intelligence turns observed artefacts, adversary behaviour and contextual research into information that supports detection, investigation, hunting and response.
Indicators are observations
IP addresses, domains, URLs, hashes, certificates and email artefacts are observable indicators that may be associated with threat activity.
Indicators are not attribution
A matching indicator can support an investigation without proving who operated the infrastructure or why it appeared.
Threat actors
Threat-actor profiles describe tracked groups, motivations, targeting, tools, infrastructure and observed behaviours.
Attack campaigns
Campaigns group related operations, infrastructure, malware and victim patterns observed over time.
Tactics, techniques and procedures
TTPs describe how adversaries operate and can remain useful after specific indicators expire.
Indicators of compromise
IOCs are artefacts associated with known or suspected malicious activity, such as domains, hashes and IP addresses.
Indicators of attack
IOAs describe behaviours and patterns that may reveal attacker activity even when the exact IOC is new.
Microsoft Defender Threat Intelligence
Defender TI supports infrastructure analysis, actor and campaign research, IOC enrichment, incident response and threat hunting.
Use Copilot in Defender TI
Security Copilot can answer questions about actors, campaigns and other threat intelligence using threat analytics, intelligence profiles, articles and Defender TI content.
Summarise the latest threats
Copilot can summarise current threats relevant to the organisation and help prioritise them according to exposure context.
Threat analytics
Threat analytics combines Microsoft research, reports, indicators and organisational exposure context.
Threat analytics indicators
The Indicators section can expose IOCs associated with tracked threats where licensing and access allow.
Intel profiles
Profiles bring together actor, campaign, malware and infrastructure context for investigation.
Articles and reports
Research content provides background, chronology, targeting and known behaviours that support interpretation.
Infrastructure analysis
Use passive DNS, certificates, WHOIS-style context and related infrastructure to understand relationships.
IP investigation
Review hosting, ownership, observed services, related domains, historical resolutions, reputation and freshness.
Domain investigation
Review registration context, name servers, certificates, subdomains, resolutions and related infrastructure.
URL investigation
Separate the full URL path and parameters from the underlying domain and hosting infrastructure.
File-hash investigation
Review malware family, prevalence, detections, related campaigns and where the file appeared internally.
Certificate investigation
Certificates can link infrastructure, but shared or automated certificate services can create false relationships.
Email artefacts
Sender domains, reply-to domains, URLs, attachments and authentication results can become threat-intelligence pivots.
Freshness matters
Infrastructure can change ownership, be sinkholed, cleaned or reused, so last-seen and first-seen dates affect confidence.
Confidence matters
Record the source, confidence, reliability and reason an indicator is considered relevant.
Relevance matters
A globally malicious indicator may not be related to the organisation’s current incident.
Prevalence matters
A rare indicator can be interesting, while a common cloud or CDN address may require much stronger context.
Shared infrastructure
Cloud hosts, CDNs, VPNs, proxies and compromised websites can serve legitimate and malicious traffic simultaneously.
False attribution risk
Infrastructure overlap alone rarely proves two campaigns share the same operator.
Separate observed from assessed
Distinguish what was directly observed from the analyst’s interpretation and external reporting.
Use organisational exposure
Prioritise threats that affect technologies, vulnerabilities, identities and business services actually present in the environment.
Connect intelligence to incidents
Enrich incident entities and determine whether the external context changes severity, scope or next steps.
Connect intelligence to hunting
Translate actor behaviours, malware traits and indicators into proactive hunting hypotheses.
Connect intelligence to vulnerability management
Prioritise exploitable vulnerabilities that are associated with active campaigns and exposed assets.
Microsoft Sentinel threat intelligence
Sentinel ingests and manages threat indicators to support matching, analytics, hunting and incident enrichment.
ThreatIntelligenceIndicator table
The ThreatIntelligenceIndicator table stores threat-indicator records used in Sentinel threat-intelligence workflows.
ThreatIntelIndicators table
The newer ThreatIntelIndicators table can also hold threat-intelligence indicator data depending on integration and schema.
Use the correct table
Confirm which table and schema contain the indicators in the specific workspace before generating KQL.
Threat intelligence feeds
Sentinel can ingest indicators from Microsoft Defender Threat Intelligence, TIP integrations and STIX or TAXII feeds.
Bulk indicator import
Approved indicators can be imported in bulk using supported CSV or STIX JSON workflows.
Add incident entities to TI
Selected incident entities can be added as threat indicators when the type is supported and governance permits.
Matching analytics
Threat-intelligence matching can generate alerts and incidents when observed activity matches known indicators.
Indicator lifecycle
Indicators need created, valid-from, expiration, last-seen, confidence, tags and ownership information.
Expire stale indicators
Old indicators can create noise or false positives when they no longer represent hostile infrastructure.
Avoid indefinite blocking
Blocking every historical IOC forever can disrupt legitimate services and reduce detection quality.
Use allow and block carefully
Response actions should account for shared infrastructure, business dependencies and confidence.
Security Copilot with Sentinel
Sentinel incidents and data can be combined with other enabled Security Copilot sources for broader threat context.
Generate hunting queries
Copilot can assist with KQL hunting queries based on threat intelligence and investigation questions.
Validate generated KQL
Check table names, indicator types, joins, time ranges, entity normalisation and returned matches.
Threat Hunting Agent
The Security Copilot Threat Hunting Agent can support natural-language hunting workflows from hypothesis through investigation and action.
Threat Intelligence Briefing Agent
The Threat Intelligence Briefing Agent can produce regular customised briefings from relevant threat-intelligence sources.
Briefings need configuration
Useful briefings depend on correct scope, topics, organisational priorities, permissions and source access.
Agent output needs review
Automated briefings and hunts can omit nuance, overstate relevance or repeat low-confidence reporting.
Build a threat brief
Include what changed, why it matters, affected technologies, observed indicators, likely TTPs and recommended actions.
Separate strategic intelligence
Strategic intelligence explains trends, motivations and business implications.
Operational intelligence
Operational intelligence describes campaigns, targeting, infrastructure and likely timing.
Tactical intelligence
Tactical intelligence focuses on adversary TTPs and detection opportunities.
Technical intelligence
Technical intelligence includes indicators and artefacts used for matching and enrichment.
Map to MITRE ATT&CK
Use ATT&CK mappings to organise behaviours, but verify each technique against observed evidence.
Do not force ATT&CK mappings
A tool or command can support several techniques and should not be mapped without contextual evidence.
Use multiple sources
Corroborate important findings across Microsoft research, internal telemetry and approved external intelligence.
Record source provenance
Document where each claim, IOC and attribution statement originated.
Protect intelligence handling
Some reports, indicators and investigations may have sharing restrictions or sensitivity requirements.
Share at the right level
Executives need relevance and impact, while hunters need indicators, TTPs and queryable details.
Create detection opportunities
Convert validated intelligence into analytics rules, hunts, watchlists, blocks or exposure-management actions.
Measure intelligence value
Track whether intelligence improved prioritisation, detections, hunt results, response speed or risk reduction.
Close the feedback loop
Feed internal observations back into investigations, detections and approved intelligence platforms.
Final analyst judgement
Threat intelligence supports prioritisation and hypotheses; attribution and response remain human decisions.
Example threat-intelligence prompt
Include:
1. Current and historical IP resolutions
2. Hosting, certificate and registration context
3. Related domains, URLs, files, malware and campaigns
4. First-seen, last-seen, freshness and confidence information
5. Threat actors or campaigns that Microsoft associates with the infrastructure
6. Internal Defender XDR or Sentinel sightings
7. Relevant MITRE ATT&CK techniques
8. Confirmed facts, external assessment and unsupported attribution
9. Recommended hunting and detection pivots
10. Limitations and confidence level
Do not attribute the activity to an actor based only on shared infrastructure.
Agent Foskett investigation: “The IP belonged to three different attackers…”
↓
Security Copilot summarised three campaigns associated with the address
↓
The first draft implied the user had been targeted by all three actors
↓
Agent Foskett checked the infrastructure history
↓
The IP belonged to a large cloud-hosting provider
↓
Different customers had used the same address at different times
↓
Two campaign references were months old
↓
The current certificate and domain relationship matched only one recent phishing operation
↓
Internal telemetry showed one sign-in and no related malware or endpoint activity
↓
The IP match increased investigation priority
↓
It did not prove attribution or compromise
↓
The user’s session was investigated separately
↓
The final report recorded shared infrastructure, one relevant campaign and low-confidence actor attribution
↓
The intelligence became useful only after time and ownership were added
Threat-intelligence validation checklist
| Area | Question | Validation action |
|---|---|---|
| Observable | Is the exact IP, domain, URL, hash or certificate selected? | Normalise and confirm the artefact. |
| Freshness | When was it first and last observed? | Compare intelligence with incident time. |
| Ownership | Is the infrastructure dedicated or shared? | Review hosting, certificates and DNS history. |
| Confidence | How reliable is the source and assessment? | Record confidence and provenance. |
| Relevance | Does the intelligence relate to this organisation or incident? | Compare with internal telemetry. |
| Attribution | Is the actor link based on more than one indicator? | Require behavioural and contextual corroboration. |
| Sentinel | Which indicator table and schema are in use? | Confirm workspace data before KQL. |
| Expiry | Is the indicator still valid? | Review expiration and last-seen dates. |
| Action | Could blocking disrupt legitimate services? | Assess shared infrastructure and business impact. |
| Output | Are facts, assessment and uncertainty separated? | Review and approve the final intelligence report. |
Key takeaways
- Microsoft Defender Threat Intelligence supports triage, incident response, threat hunting, vulnerability management and infrastructure analysis.
- Security Copilot can answer questions about actors, campaigns and threat intelligence using Defender TI reports, profiles and articles.
- Threat analytics helps prioritise threats according to organisational exposure.
- Indicators connect observed artefacts to known or suspected threat activity but do not prove attribution.
- Freshness, ownership, confidence, provenance and relevance determine indicator value.
- Microsoft Sentinel stores and uses threat indicators for matching, analytics, hunting and enrichment.
- Analysts should confirm whether ThreatIntelligenceIndicator or ThreatIntelIndicators is the relevant workspace table.
- The Threat Hunting Agent and Threat Intelligence Briefing Agent can accelerate hunting and recurring intelligence workflows.
- Agent-generated output and ATT&CK mappings still require analyst validation.
- Attribution and operational response remain human decisions supported by multiple sources.
What Agent Foskett checked
- Exact IP address
- Hosting provider
- DNS history
- Certificates
- First and last seen
- Campaign dates
- Internal telemetry
- Shared infrastructure
- Attribution confidence
- Recommended hunts
Best practices
- Normalise indicators.
- Check freshness.
- Record provenance.
- Evaluate confidence.
- Confirm infrastructure ownership.
- Correlate internal evidence.
- Expire stale indicators.
- Validate KQL and agents.
- Avoid single-IOC attribution.
- Translate intelligence into action.
Related Agent Foskett resources
Continue the Microsoft Security Copilot Academy
How do you use Microsoft Security Copilot for threat intelligence?
Security Copilot can use Microsoft Defender Threat Intelligence reports, profiles, articles and infrastructure context to answer questions about actors, campaigns and threats relevant to an organisation.
Microsoft Sentinel threat intelligence
Microsoft Sentinel can ingest and manage threat indicators for matching analytics, hunting, incident enrichment and response using supported feeds and integrations.
Threat intelligence validation
Analysts should validate indicator freshness, confidence, provenance, infrastructure ownership and internal relevance before attribution, blocking or detection changes.
