Lesson 40 — Investigating Entities in Microsoft Sentinel
The alert names one user.
The user leads to an IP address.
The IP leads to another alert.
The second alert leads to a device nobody had looked at yet.
That is why investigators follow entities.
What you will learn
Use incident entities as pivots into the wider evidence.
Learning objectives
- Explain why entities are central to Microsoft Sentinel investigations.
- Investigate users, hosts, IP addresses and other supported entities.
- Use entity information, timelines and insights to build context.
- Pivot from an entity into related alerts and underlying telemetry.
- Use entity relationships to expand or challenge the current incident scope.
The investigation
Lesson 39 established what each alert actually observed.
Now we ask a different question:
What else has each person, device, address or resource been doing?
What is an entity?
In Microsoft Sentinel, entities are identifiable objects extracted from security data and mapped into alerts and incidents. They give the analyst meaningful investigation pivots instead of leaving evidence as disconnected fields in a log row.
Entities come from the alerts
Sentinel incidents inherit entities identified in their contributing alerts. Good entity mapping therefore makes detections much more useful during investigation.
This is why entity mapping mattered when we built analytics rules earlier in the Academy.
An entity is a pivot — not a verdict
An IP address appearing in an incident does not automatically make that IP malicious. A user attached to an alert is not automatically compromised.
The entity tells you where to look next.
The Agent Foskett entity workflow
Start with identity
Make sure you know exactly which entity you are investigating. Similar display names, reused hostnames and shared infrastructure can mislead an analyst.
Use the identifying information available for the entity before drawing conclusions.
Then ask why it matters
Is this a privileged account? A production server? A shared NAT address? A service identity? A known scanner?
Technical identity plus environmental context determines how useful the entity is as an investigation pivot.
Entity information, timeline and insights
| Area | What it gives the analyst |
|---|---|
| Info | Identifying and contextual information about the entity. |
| Timeline | Notable activity involving the entity, including alerts, bookmarks, anomalies and supported activities. |
| Insights | Contextual and behavioural findings generated from available security data. |
In current Sentinel experiences, this context can be exposed within incident investigation or through fuller entity views. In the Defender portal, Sentinel context is increasingly integrated with Defender entity experiences.
User entity
A user can connect identity, email, cloud and endpoint evidence.
Investigate sign-ins, privilege, group membership changes, unusual behaviour, associated alerts and other activity around the incident window.
Host or device entity
A device can connect processes, files, users, network connections and endpoint alerts.
Ask who used it, what executed, what changed and whether the same device appears elsewhere in the incident.
IP address entity
An IP address can connect authentication, network and threat-intelligence evidence.
Determine whether it is internal or external, shared infrastructure, expected for the user, associated with other alerts or connected to known threat context.
Cloud resource and application context
Cloud resources and application identities can reveal access paths that are easy to miss when an investigation focuses only on human users and endpoints.
Ask what permissions exist, what actions occurred and which identity performed them.
Example — follow the user
The user did not answer the investigation. The user expanded it.
Use the entity timeline
The entity timeline can show activity beyond the alert you started with. That is valuable because the current incident may represent only part of the entity's recent security story.
Look for earlier alerts, anomalies, bookmarks and actions that change your understanding of the incident.
Related alerts can change scope
An entity timeline may reveal alerts that are not currently part of the incident.
That does not mean they automatically belong in the case. Review them, validate the relationship and expand the incident only when the evidence supports it.
Example — investigate the user with KQL
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
SigninLogs
| where UserPrincipalName =~ "alex@contoso.com"
| where TimeGenerated > ago(24h)
| summarize SignIns = count(),
IPAddresses = make_set(IPAddress, 20),
Applications = make_set(AppDisplayName, 20)
by ResultType
| order by SignIns descThis query does not try to prove compromise. It asks a focused entity question: what sign-in activity has this user generated recently?
Pivot with a question
Do not run queries simply because you have an entity.
Ask something first: Has this IP accessed other users? Has this account used another device? Has this host contacted the same domain before?
One pivot creates another
A user query may expose an IP. The IP may expose another account. That account may expose another device.
This is how an investigation grows from the original alert into the true scope of the activity.
Entity chaining
Each relationship should be supported by evidence. The goal is not to create the biggest possible graph. The goal is to discover the relationships that explain the incident.
Behavioural insights add context
Sentinel entity insights and UEBA can help expose unusual behaviour, peer deviations, sign-in patterns and other contextual information.
Use these findings to generate investigation questions and identify activity worth validating.
Insights are not conclusions
An anomaly is evidence that something differs from an expected pattern.
It may be malicious, administrative, operational or simply new. Validate the underlying activity before assigning intent.
Compare the entity with itself
| Question | Why it matters |
|---|---|
| Has this user used this IP before? | Tests whether the network origin is unusual for the identity. |
| Has this device seen this user before? | Tests whether the user-device relationship is expected. |
| Has this IP appeared in other alerts? | May reveal broader targeting or recurring infrastructure. |
| Has this entity behaved similarly before? | Provides historical context for the current activity. |
| Does this entity appear in another incident? | May expose related activity outside the current case. |
Compare the entity with its peers
Behaviour that is normal for one administrator may be highly unusual for another user.
Peer and historical context can help distinguish routine operations from activity that deserves deeper investigation.
Know when to stop expanding
Entity pivoting can continue indefinitely if every relationship becomes another branch.
Stop when additional pivots no longer help answer the incident's key questions, change scope or affect the response decision.
Defender portal investigation
Microsoft is consolidating Sentinel investigation into the Microsoft Defender portal. Current Defender incident experiences bring together correlated alerts, assets, evidence and investigation context, while Sentinel information also appears within relevant entity experiences.
Portal layouts evolve. The durable skill is knowing how to identify an entity, understand its context, inspect its history and pivot into related evidence.
Common mistake — entity equals malicious
An entity is part of the evidence set, not automatically an indicator of compromise.
Determine its role before applying a verdict.
Common mistake — pivot without a question
Randomly opening every related object produces noise.
Every pivot should test a hypothesis, establish scope or answer a specific investigation question.
Common mistake — stop at the first entity
The entity named in the alert may only be the beginning.
Follow meaningful relationships until you understand the relevant users, devices, infrastructure and resources.
Common mistake — ignore normal context
Historical activity can be just as important as suspicious activity.
Knowing that a user routinely signs in through a particular address can prevent a false conclusion.
Agent Foskett investigation exercise
The user appears in a suspicious sign-in alert and an inbox-rule alert.
- Confirm the identity and determine whether the account is privileged or business-critical.
- Review the entity's activity around the incident time.
- Identify every IP address associated with the suspicious period.
- Determine whether those IPs appear against other users.
- Identify devices associated with the account.
- Look for related alerts or incidents involving those entities.
- Write one hypothesis that explains the relationships.
- Write one piece of evidence that would weaken that hypothesis.
Best practices
- Confirm exactly which entity you are investigating.
- Use entity context before assigning meaning.
- Review timelines and insights for relevant history.
- Pivot with specific questions.
- Validate relationships against raw telemetry.
- Follow shared entities across alerts and incidents.
- Use historical and peer behaviour as context.
- Stop expanding when new pivots stop changing the investigation.
Agent Foskett takeaway
An alert gives you a starting point.
An entity gives you a direction.
Follow the user. Follow the device. Follow the address. Let the relationships show you how far the incident really reaches.
Related Agent Foskett learning
Continue learning
Investigating Entities in Microsoft Sentinel
Microsoft Sentinel entity investigation helps analysts pivot from incident alerts into users, hosts, IP addresses and other security objects. Entity information, timelines, behavioural insights, related alerts and underlying telemetry can reveal relationships that expand or refine the known scope of an incident.
Microsoft Sentinel Lesson 40
This Agent Foskett Microsoft Sentinel Academy lesson teaches a practical entity-investigation workflow: identify the entity, review its context and history, ask targeted questions, validate relationships and follow meaningful pivots until the incident's true scope is understood.
