Cybersecurity & Information Security

Microsoft Sentinel: Incident Investigation Guide for Junior Analysts

7 min readPublished: August 5, 2026

Professional visual illustration on incident investigation in Microsoft Sentinel in the field of SIEM and detection

Quick answer

Incident investigation in Microsoft Sentinel begins by understanding the case story: which Alerts were grouped, who are the Entities, what is the Severity, and what is the detection source. The analyst then verifies users and assets, checks Evidence and Timeline, runs supplementary KQL, documents decisions, and performs escalation or response. An incident is a work case — not proof that the attack succeeded — therefore classification must rely on evidence and context.

Microsoft Sentinel centralizes Detection, Investigation, and Response around Incidents. An Incident can be generated from an Analytics rule, an alert imported from another product, or by grouping several Alerts related to the same activity. It inherits properties such as Severity, Status, MITRE ATT&CK tactics, and Entities identified in the alerts.

The screen provides a lot of information, but a good investigation is not an automatic transition between Tabs. The analyst needs to define an investigation question, identify what is known and what is missing, and use the interface tools to collect evidence. This guide is suitable for lab data or an organizational environment where permissions exist.

Microsoft is unifying the SOC experience within the Microsoft Defender portal. According to current documentation, support for Sentinel via the Azure portal is expected to end after March 31, 2027, so it is better to learn the core workflow and get familiar with the Defender portal instead of relying on a fixed button location.

Before the Investigation: Basic Preparations

An analyst needs appropriate permissions to view, assign, and modify an Incident. Microsoft states Sentinel Responder as one of the required roles for investigation. Permissions should follow the principle of Least Privilege, and in a real organization, it is important to separate viewing sensitive data from response actions such as asset isolation or user disablement.

Ensure that the Incident includes useful Entities. Entity mapping in an Analytics rule allows the system to identify an Account, Host, IP, URL, File, or Process. Without mapping, graphical investigation and contextual links will be limited. Additionally, check that Data connectors are healthy and there is no significant Ingestion delay.

Before opening an Incident, define an SLA or Triage target, Owner, and escalation criteria. An Incident without an Owner may wait even when Severity is high.

Step 1: Reading the Incident Queue

Initial prioritization is performed in the incident queue. Don't settle for Severity alone. Check Created time, Last activity, Product, Tactics, number of Alerts, Entities, Owner, and Status. Connect this to asset criticality and user identity. A Medium incident on a Privileged account may receive higher Priority than a High incident on an isolated asset in a lab.

Initial Question	What to Check	Why it Matters
What happened?	Title, Alert providers, Tactics, Description	Defines an initial hypothesis
To whom did it happen?	Account, Host, IP, Cloud resource	Determines Scope and criticality
When?	First/Last activity, Created time	Defines investigation window
Is it still active?	New Alerts, Sessions, Network activity	Affects urgency and Containment
Who is handling it?	Owner, Status, Tasks	Prevents duplication and waiting

Step 2: Opening the Incident and Understanding the Story

Read the Summary and the list of Alerts. Several Alerts can be products of the same Rule or different products. Check if Alert grouping has consolidated logical activity or created too broad an Incident. Pay attention to the Time range: a late Alert can extend the Incident and hide the start of the activity.

Open each key Alert and read its Detection source, Description, Query or Evidence, Threshold, and Entities. Ask: What condition was actually triggered? Is it based on an Indicator, anomaly, behavior, or Correlation? What is the level of certainty? What data was not checked?

Avoid title bias. An Alert named “Compromised account” still requires verification. A dramatic name is not Evidence.

Step 3: Entities and Relationships

Entities are the anchors of the investigation. Start with the central account, Host, or IP and check Insights: previous activity, additional Alerts, group membership, Sign-ins, Related hosts, and Threat intelligence. Don't rely solely on the graph; it shows relationships that the system managed to map, not the entire reality.

For each Entity, build a short investigation card: identifier, type, Owner, criticality, Last known good, unusual activity, and data sources. When similar names exist, ensure you are tracking the Object ID or SID and not just the Display name.

Questions for a User Account

Is the account Privileged or a Service account?
Was MFA enforced and what was the authentication result?
Are the IP, device, and country known?
Are there failures, Resets, Consent, or permission changes?
Does the user confirm the activity through a reliable communication channel?

Questions for a Host

Is the workstation managed and up-to-date?
What is the Process tree and is the Command line unusual?
Are there Connections, Files, or Persistence indicators?
Does an additional Alert from EDR or Network sensor support the story?
Will isolating the workstation affect a critical service?

Step 4: Evidence and Timeline

Evidence centralizes findings that the system linked to the Incident. Check source, time, and value. Distinguish between Raw event, Alert evidence, and Enrichment. An Indicator appearing in Threat Intelligence is not sufficient if a connection to the asset's activity is not found.

The Timeline organizes Alerts, bookmarks, and actions. Use it to identify initiation, spread, and response, but also build your own Timeline when there are sources outside Sentinel. Normalize UTC, document Event time versus Ingestion time, and mark gaps.

Tasks can ensure that the analyst checks required steps: user verification, Sign-in search, Host check, contacting IT, and adding Classification. A completed Task does not mean the outcome is good; a Ticket should include what was checked and what was found.

Step 5: Supplementary Log Search

The Incident interface provides context, but supplementary Query in Logs is usually the core of the investigation. Start from an Entity and time window, expand slightly before and after the activity, and look for supporting or contradicting events.

let TargetUser = "student@contoso.example";
let StartTime = datetime(2026-08-01 08:30:00);
let EndTime = datetime(2026-08-01 10:30:00);
SigninLogs
| where TimeGenerated between (StartTime .. EndTime)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType, ResultDescription
| order by TimeGenerated asc

After Authentication, check Audit, Endpoint, DNS, or Cloud activity according to the story. Do not expand to all tables without a purpose. Each Query should answer a question: Was there success? Was a Session created? Was a permission change performed? Did the workstation create an unusual Process or Connection?

Scenario: Suspect User and IP

The Incident includes an Alert for a Sign-in from a new country and another Alert for an Inbox rule created.
Triage identifies that the user works in finance and that the activity started outside regular hours.
In Entities, the IP, account, and application are checked. The IP is not a known VPN, and the account is not supposed to work from the identified country.
KQL shows several failures, success with an unusual MFA method, and a Mailbox change afterward.
The analyst checks Audit logs, Sessions, OAuth consents, and additional user activity. They contact the user through a verified channel.
After confirming that the activity is not theirs, the incident is classified as True Positive and escalated to IR. Containment actions are performed according to Playbook and authorization.
The Ticket documents Timeline, Queries, Evidence, actions, owners, and recommendations for improving Detection.

Classification, Response, and Closure

Classification should distinguish between True Positive, False Positive, and Benign Positive, according to the organizational model. Add a Reason and Comment explaining the evidence. Closure without justification harms Tuning and metrics.

If a response is required, perform it according to the Playbook: cancelling Sessions, Reset credentials, isolating Endpoint, blocking an Indicator, preserving evidence, or contacting teams. Irreversible actions or those with business impact require appropriate approval.

Before closure, ensure the Scope has been checked, that the activity is not continuing, that all Tasks have been completed, that lessons learned have been conveyed to the Detection owner, and that Actions have been opened to fix the Root cause.

Investigation Checklist

Owner and Priority defined.
Logic of each Alert, not just the title, was read.
Accounts, Hosts, and IPs verified using stable identifiers.
Evidence and Timeline checked with correct time zones.
Supplementary Queries performed against relevant sources.
Facts, assumptions, and interpretations separated.
Classification and Severity updated with justification.
Response actions documented with time and executor.
Follow-up tasks for Tuning or Hardening created.

Common Mistakes

Assuming all Alerts in an Incident belong to the same attack.
Relying on the Investigation graph without checking Raw logs.
Ignoring Ingestion delay or missing data source.
Closing a False Positive just because the user is known.
Running broad searches without an investigation question.
Performing significant Containment without understanding business impact.
Closing an Incident without providing feedback to the Rule owner.

Summary and CTA

Build a simulated Incident in the lab with an Account, IP, and two Alerts. Write five investigation questions, one Query for each question, and a short Timeline. The goal is not to click all options in the interface, but to show how each action changes a decision. Then move to the Analytics Rule article to understand how a quality Incident starts with detectable Detection.

FAQ

Can a Sentinel Incident include multiple Alerts?

Yes. An Incident may group Alerts from the same Rule or from different sources according to Grouping settings and the platform.

What is the importance of Entity mapping?

Mapping allows Sentinel to identify Accounts, Hosts, IPs, and other entities, display context and relationships, and support investigation. Without Mapping, some capabilities are limited.

Should I work in the Azure portal or Defender portal?

Microsoft's direction is the Defender portal, and documentation indicates that support for Sentinel via the Azure portal will end after March 31, 2027. The investigation process is more important than the button locations.

When is an Incident closed as a False Positive?

Only after evidence has been collected showing that the Detection was triggered by activity that does not represent the threat the rule was designed to identify. The Root cause should be documented, and Tuning should be considered.

Is it possible to respond automatically from Sentinel?

Yes, using Automation rules and Playbooks according to connection and permissions. Automation should be tailored to the level of certainty and potential impact.