Lesson 17 — Evidence Correlation Techniques
Modern security incidents rarely exist inside one Microsoft security product.
An investigation can begin with a phishing email, continue through an Entra sign-in, move onto a Defender endpoint alert and finish with activity against a cloud resource or sensitive data.
This lesson explains how Security Copilot helps analysts connect users, devices, IP addresses, domains, alerts and cloud resources while avoiding false relationships created by weak identifiers, broad joins and time proximity.
What you will learn
This lesson develops a complete cross-product evidence-correlation workflow.
Evidence-correlation workflow
↓
Identify users, devices, IPs, domains, files and resources
↓
Normalise timestamps and identifiers
↓
Separate strong keys from weak names
↓
Use Security Copilot to propose cross-product relationships
↓
Review process logs, plugins and source records
↓
Validate temporal, causal, behavioural and contextual links
↓
Remove duplicates and unrelated events
↓
Assign confidence to every relationship
↓
Build a unified timeline with source attribution
↓
Approve the final human-validated incident story
Evidence-correlation domains
| Domain | Evidence | Investigation question |
|---|---|---|
| Identity | UPN, object ID, sign-ins, MFA, roles and mailbox activity. | Is this the same identity across products? |
| Device | Device ID, hostname, owner, OS and process activity. | Is this the same endpoint? |
| Network | IP, proxy, VPN, domain, URL and certificate context. | Does the infrastructure genuinely connect the events? |
| Network Message ID, sender, recipient, URL and attachment. | Did the message lead to later activity? | |
| Cloud | Resource ID, subscription, identity, permissions and activity logs. | Was the same actor involved in the resource activity? |
| Incident | Alerts, entities, timestamps, products and source evidence. | Do these records form one attack story? |
Learning objectives
- Correlate evidence across Microsoft security products.
- Use strong identifiers and stable keys.
- Normalise time and entity context.
- Distinguish proximity from causation.
- Control false joins and duplicate evidence.
- Assign confidence to relationships.
- Build a verified unified timeline.
What is evidence correlation?
Evidence correlation connects events, entities and artefacts from different sources to determine whether they belong to the same incident.
Correlation is not collection
Collecting many alerts and records does not prove they are related.
Start with a hypothesis
Define the suspected relationship before joining users, devices, IP addresses, domains and resources.
Use strong identifiers
Prefer immutable identifiers such as DeviceId, AccountObjectId, AlertId, IncidentId, NetworkMessageId and resource ID.
Names are weak keys
Usernames, hostnames, display names and resource names can change or collide.
Confirm the tenant
Cross-product evidence must come from the correct tenant, workspace, subscription and cloud environment.
Confirm the time zone
Normalise all evidence into one stated time zone before building a timeline.
Use event time and ingestion time carefully
Delayed ingestion can make evidence appear out of order.
Identity correlation
Correlate Entra sign-ins, user risk, MFA, audit logs, Defender identity alerts and mailbox activity.
User principal name
UPNs are useful but can change after renaming, mergers or domain changes.
Object ID
Account object IDs provide stronger identity correlation within a tenant.
Service principals
Workload identities need separate treatment from human users.
Device correlation
Use DeviceId, hostname, owner, OS and onboarding state to confirm the endpoint.
Reimaged devices
A reimaged device can create multiple records with the same or similar hostname.
Shared devices
Multiple users on one device can create misleading identity relationships.
Endpoint and identity
Correlate device logons, Entra sign-ins and Defender device activity using time, identity and device evidence.
IP address correlation
Review IP ownership, NAT, VPN, proxy, mobile carrier and cloud-hosting context.
Shared public IPs
Many users or systems can appear behind the same public IP.
IPv4 and IPv6
The same device can use different address families across products.
Domain correlation
Compare FQDNs, parent domains, subdomains, URLs, DNS history and certificates.
URL correlation
Preserve path and parameters because different URLs on the same domain can have different purposes.
Certificate correlation
Certificates can connect infrastructure but can also be shared through CDNs and automated services.
Email correlation
Use Network Message ID, sender, recipient, URLs, attachments and delivery evidence.
Message subjects are weak
Identical or similar subjects can appear across unrelated campaigns.
File correlation
Use SHA1, SHA256, path, origin, signer and prevalence.
File names are weak
The same filename can represent many different files.
Alert correlation
Review why alerts were grouped into one incident rather than assuming the grouping is correct.
Incident correlation
One incident can contain unrelated alerts, while one attack can be split across several incidents.
Cloud resource correlation
Use full resource IDs, subscription IDs, workload identity and resource relationships.
Resource names are weak
Different subscriptions can contain resources with identical names.
Sentinel correlation
Use workspace data, incident entities and logs to connect broader telemetry.
Defender XDR correlation
Defender XDR can correlate endpoint, identity, email and cloud-app evidence into incidents.
Cross-product entity pages
Entity pages provide pivots across users, devices, files, IPs and related alerts.
Security Copilot summary
Copilot can propose relationships across products, but the analyst must verify the joins.
Process log
Review which plugins and sources contributed to each correlation.
Source attribution
Record the source product for every major fact in the final timeline.
Temporal correlation
Events close together may be related, but time proximity alone is not enough.
Causal correlation
Look for evidence that one event led to another, not just that both occurred.
Behavioural correlation
Repeated techniques, commands, infrastructure and patterns can strengthen a relationship.
Contextual correlation
Business role, geography, ownership and change records can confirm or weaken the link.
Sequence validation
Check whether the proposed order is technically possible.
Session correlation
Use session IDs, logon IDs, process IDs and token context where available.
Authentication correlation
Match sign-ins with MFA, Conditional Access, device and session evidence.
Mailbox correlation
Connect phishing, forwarding, inbox rules, delegate access and sent mail.
Process correlation
Validate parent-child process relationships on the same device and session.
Network correlation
Match network connections to the process that owned them.
Cloud activity correlation
Connect identity, resource, API and data-access events.
Threat-intelligence correlation
Enrich indicators without treating external reputation as proof.
MITRE ATT&CK correlation
Map observed behaviours only when the evidence supports the technique.
Duplicate detection
Remove duplicate alerts and repeated entity records before estimating scope.
False relationship risk
Broad joins and common names can create convincing but incorrect attack stories.
One-to-many relationships
One user can access many devices and one IP can serve many users.
Many-to-one relationships
Many alerts can refer to one device, file or underlying event.
Correlation confidence
Assign confidence separately to each relationship.
Confirmed relationship
Direct identifiers or source records prove the connection.
Probable relationship
Multiple supporting facts indicate the connection, but direct proof is missing.
Possible relationship
The relationship is plausible but weakly supported.
Unsupported relationship
Available evidence does not justify linking the events.
Conflicting evidence
Record facts that weaken the proposed correlation.
Missing visibility
Document missing logs, permissions, workspaces or telemetry.
Use KQL carefully
KQL joins can create false matches when unstable fields or broad time windows are used.
Filter before joining
Reduce both sides before correlation to limit noise and row multiplication.
Use stable keys
Prefer DeviceId, AccountObjectId, AlertId and resource ID.
Validate join cardinality
Check whether one row is multiplying into many duplicates.
Inspect raw rows
Review representative events before summarising the relationship.
Build a unified timeline
Create one chronological view with source attribution and confidence.
Separate fact and inference
Confirmed evidence, inferred relationships and unresolved questions should be distinct.
Review with another analyst
Complex cross-product correlations benefit from peer review.
Update the hypothesis
Change the attack story when the evidence does not support the original relationship.
Document final scope
Record which users, devices, mailboxes, IPs, domains and resources are confirmed in scope.
Final analyst decision
Security Copilot can suggest relationships; the analyst approves the final incident story.
Example evidence-correlation prompt
Use Microsoft Defender XDR, Microsoft Entra and Microsoft Sentinel evidence.
Include:
1. User and object identifiers
2. Related devices and immutable Device IDs
3. Sign-ins, MFA and Conditional Access results
4. Email delivery, URLs and attachments
5. Endpoint processes, files and network connections
6. IP, domain and certificate context
7. Cloud resources and activity
8. Strong, probable, possible and unsupported relationships
9. Conflicting evidence and missing visibility
10. A unified timeline with source attribution
Do not correlate events based only on username, hostname, IP address or time proximity.
Agent Foskett investigation: “The same IP connected everything…”
↓
Security Copilot linked all three into one attack story
↓
The first draft showed phishing followed by account compromise and cloud access
↓
Agent Foskett checked the IP ownership
↓
The address belonged to the organisation’s secure web gateway
↓
Hundreds of users appeared behind the same public IP
↓
The phishing recipient never clicked the message
↓
The risky sign-in belonged to another user on a managed device
↓
The cloud access belonged to an approved service principal
↓
The shared IP created a convincing but false relationship
↓
Device IDs, object IDs and message evidence separated the events
↓
The investigation became three unrelated records
↓
The same infrastructure had hidden three different stories
Evidence-correlation validation checklist
| Area | Question | Validation action |
|---|---|---|
| Identity | Is the same object ID involved? | Confirm tenant and account identity. |
| Device | Is the same immutable Device ID involved? | Check reimage, rename and ownership. |
| Network | Is the IP dedicated or shared? | Review VPN, proxy, NAT and hosting context. |
| Is the same Network Message ID involved? | Confirm delivery and user interaction. | |
| Cloud | Is the same resource ID and identity involved? | Review subscription and activity logs. |
| Time | Are timestamps normalised and technically possible? | Check time zone and ingestion delay. |
| Join | Are stable identifiers used? | Avoid names and broad string matches. |
| Duplicates | Are repeated alerts inflating scope? | Deduplicate before counting. |
| Confidence | How strong is each relationship? | Label confirmed, probable, possible or unsupported. |
| Story | Does evidence support one attack chain? | Separate unrelated events and revise the hypothesis. |
Key takeaways
- Evidence correlation connects events and entities across Microsoft security products.
- Strong identifiers are more reliable than usernames, hostnames, subjects and resource names.
- Time proximity alone does not prove causation.
- Shared IP addresses, gateways, CDNs and cloud infrastructure can create false relationships.
- Microsoft Defender XDR, Sentinel, Entra and Defender for Cloud provide different parts of the evidence story.
- Security Copilot can propose relationships, but the process log and original records must be reviewed.
- Cross-product timelines require one stated time zone and source attribution.
- Duplicates and broad joins can inflate incident scope.
- Each relationship should have its own confidence level.
- The final incident story remains a human-validated conclusion.
What Agent Foskett checked
- Account object IDs
- Device IDs
- Network Message ID
- Public IP ownership
- Secure web gateway
- Sign-in user
- Cloud service principal
- Message click evidence
- Time normalisation
- Final incident scope
Best practices
- Start with strong identifiers.
- Confirm the tenant.
- Normalise time zones.
- Separate names from IDs.
- Review source attribution.
- Validate causal links.
- Control broad joins.
- Remove duplicates.
- Assign confidence.
- Revise the hypothesis.
Related Agent Foskett resources
Continue the Microsoft Security Copilot Academy
How do you correlate evidence with Microsoft Security Copilot?
Security Copilot can help connect identities, devices, IP addresses, domains, alerts and cloud resources across Microsoft Defender XDR, Sentinel, Entra and Defender for Cloud.
Cross-product security evidence correlation
Reliable correlation uses stable identifiers, normalised timestamps, source attribution and validated causal relationships rather than names, shared IP addresses or time proximity alone.
Evidence-correlation best practices
Analysts should remove duplicates, inspect process logs, review original records, assign confidence to each relationship and revise the attack story when the evidence does not support the original hypothesis.
