Lesson 37 — Reading an Incident Before You Touch Anything
The incident looks bad.
A privileged account is involved. There is a suspicious IP address. The severity is High.
Your cursor is already heading towards a response action.
Stop. Read the case first.
What you will learn
Perform a disciplined first read before containment or remediation.
Learning objectives
- Perform a repeatable first-pass review of a Sentinel incident.
- Separate incident facts from assumptions and hypotheses.
- Establish chronology, scope and affected assets before responding.
- Identify which alerts and evidence deserve deeper investigation.
- Recognise when immediate containment is justified and when more evidence is required.
The investigation
A High-severity incident appears at 02:14.
It involves a Global Administrator, an unfamiliar IP address and three correlated alerts.
The temptation is obvious: disable the account immediately.
But what if the sign-in was blocked? What if the IP belongs to an approved service? What if the account never successfully authenticated?
Your first job is orientation
Microsoft's current incident investigation guidance recommends reviewing the incident properties and the overall attack story before diving into individual details.
Read — do not react
The incident title, severity and recommendations are useful orientation, but they are not a forensic conclusion.
Your first read should establish what Sentinel and Defender actually observed before you decide what those observations mean.
Response is not forbidden
If evidence shows an active destructive attack or immediate risk to critical assets, containment may be urgent.
The principle is not “never respond quickly.” It is: do not take disruptive action merely because the incident looks frightening.
The Agent Foskett first-read workflow
Step 1 — read the summary
Start with the incident description, severity or priority information, status, assignment, categories, first and last activity times and impacted assets.
In the Defender portal, the incident summary and details provide this orientation before you open every alert.
Ask: why is this here?
Can you explain in one sentence why the incident exists?
If you cannot, you are not ready to remediate it. Identify the detections or correlated activity that caused the case to be created.
Step 2 — establish the time boundary
| Question | Why it matters |
|---|---|
| When was the first suspicious activity? | Gives you the earliest known point in the incident story. |
| When was the last activity? | Helps determine whether the behaviour may still be active. |
| How long does the incident span? | Separates a burst of activity from a longer campaign. |
| Are there gaps between alerts? | May reveal separate phases or missing telemetry. |
| Did activity occur before the first alert? | The first detection is not necessarily the beginning of the attack. |
The first alert is not always the first event
A detection fires when its conditions are met. The underlying behaviour may have started minutes, hours or days earlier.
Use the alert chronology as an index into the evidence, not as proof of the attack's true start time.
Step 3 — read the alerts in order
Microsoft's Defender incident experience presents incident alerts chronologically so analysts can understand how the attack played out over time.
For each alert, note its detection source, severity, impacted assets, activity times and why it was correlated into the incident.
Build a first-pass alert table
| Time | Alert | Source | Asset | Initial question |
|---|---|---|---|---|
| 02:03 | Unfamiliar sign-in properties | Identity detection | Admin account | Did authentication succeed? |
| 02:08 | Suspicious inbox activity | Email / cloud detection | Same user | What changed? |
| 02:14 | Suspicious process | Endpoint detection | Device-27 | Is the device related to the identity activity? |
This table does not prove an attack chain. It gives the analyst a structured set of questions to test.
Step 4 — identify the affected assets
Current Defender incident investigation exposes affected assets such as devices, users, mailboxes and apps. Incident cases can also expose cloud resources and other supported asset types.
Write down which assets are involved and which alerts connect them.
Criticality changes priority
A privileged administrator, domain controller, executive mailbox or production cloud resource may increase the business impact of the same technical behaviour.
Asset importance helps prioritise the investigation, but it still does not prove malicious intent.
Step 5 — separate evidence from interpretation
| Evidence | Interpretation / hypothesis |
|---|---|
| Sign-in from IP 203.0.113.50 at 02:03 | “The attacker logged in.” |
| Mailbox rule created at 02:08 | “The attacker established persistence.” |
| PowerShell process at 02:14 | “The attacker moved to the endpoint.” |
The right-hand statements might eventually be true. At first read, they are hypotheses. Your investigation must connect them to evidence.
Write down what you know
Use precise language: “The alert reports…”, “The log shows…”, “The account was observed…”.
Avoid turning an alert label into a statement of fact before validating the underlying activity.
Write down what you do not know
Unknowns are valuable. They define the investigation.
Did the sign-in succeed? Is the IP expected? Did the mailbox rule forward externally? Did the PowerShell command execute? Are these events actually connected?
Step 6 — check what has already happened
The current Defender incident experience includes activities, investigations, evidence and response information. Before taking action, determine whether automation or another analyst has already acted.
Activities matter
The Activities view records manual and automated actions associated with an incident, including case changes and automation activity.
This is especially important during handover: the incident may have changed since the alert originally fired.
Evidence can already have verdicts
Supported evidence in Defender can carry verdicts such as malicious, suspicious or clean, together with remediation status.
Use those verdicts as investigation context, then understand which product or investigation produced them.
Step 7 — create the question list
A good investigation query answers a question. It should not be random exploration of whichever table you remember first.
- Did the suspicious authentication succeed?
- Has this IP been used by the account before?
- Which other users were seen from the same IP?
- What changed in the mailbox?
- Is Device-27 normally used by this account?
- What exactly did the suspicious process execute?
- Was there related activity before 02:03?
Step 8 — choose the first pivot
Choose the evidence item most likely to reduce uncertainty.
For our scenario, confirming whether the suspicious sign-in succeeded may change the entire investigation. That is a better first pivot than randomly hunting across every endpoint in the tenant.
Use the incident to stay scoped
The incident provides alerts, assets, evidence and chronology. Use those objects to decide where to pivot next.
If new evidence expands the scope, expand deliberately — and record why.
A simple first-pass investigation note
High-severity incident involving one privileged user, one device and an unfamiliar IP. Three alerts span 11 minutes. Current evidence shows suspicious identity, mailbox and endpoint activity, but the relationship between the events has not yet been validated. First priority: confirm authentication outcome and establish whether the IP is expected for the user.
That is far more useful to the next analyst than: “Looks compromised — investigating.”
What should make you accelerate?
Evidence of active destructive behaviour, confirmed credential theft, ongoing attacker control, attack disruption indicators, critical-asset impact or rapidly expanding scope can justify immediate containment.
Even then, capture enough context to explain what prompted the action.
What should make you slow down?
A scary title with weak evidence, a single low-confidence signal, known security testing, expected administration or an alert whose underlying action failed may require investigation before disruptive response.
Urgency should come from risk and evidence — not typography.
The five-minute discipline
Five minutes is not a fixed SLA. It is a mindset: orient yourself before you start changing the environment.
Common mistake — severity becomes verdict
“High” becomes “confirmed compromise” in the analyst's mind.
Severity helps prioritise. Investigation establishes what actually happened.
Common mistake — the first alert becomes the story
The analyst investigates whichever alert appears first on screen and ignores the rest of the incident.
Read the chronology and relationships before selecting the strongest pivot.
Common mistake — immediate disruptive action
The analyst isolates a device or disables a user without understanding whether the action is necessary, whether automation already responded, or what evidence should be preserved.
Containment should be deliberate and explainable.
Common mistake — random hunting
The analyst opens Logs and starts querying familiar tables without a question.
Write the unknown first. Then query the evidence needed to answer it.
Agent Foskett investigation exercise
High severity. Four alerts. One privileged account. Two IP addresses. One endpoint. Activity spans 36 minutes. One automated investigation is complete and one remediation action is pending approval.
- Write a one-sentence description of why the incident exists without declaring compromise.
- Record first and last activity times.
- Put the four alerts in chronological order.
- List the affected assets and which alerts connect to them.
- Identify any evidence verdicts and remediation actions already present.
- Write five unanswered questions.
- Choose the single first pivot that would reduce uncertainty the most.
- State what evidence would justify immediate containment.
Best practices
- Orient before acting.
- Read the complete incident, not just its title.
- Establish chronology and scope.
- Separate facts, hypotheses and unknowns.
- Check automation and analyst activity already performed.
- Choose pivots that answer explicit questions.
- Make disruptive actions evidence-based and explainable.
Agent Foskett takeaway
The first task is not to prove the alert right.
The first task is to understand what the evidence actually says.
Read first. Question second. Pivot third. Act when the evidence earns it.
Related Agent Foskett learning
Continue learning
How to Read a Microsoft Sentinel Incident Before Responding
A strong Microsoft Sentinel incident investigation begins with orientation: review the incident summary, chronology, alerts, affected assets, evidence, automated actions and unanswered questions before choosing an investigative pivot or disruptive response action.
Microsoft Sentinel Lesson 37
This Agent Foskett Microsoft Sentinel Academy lesson teaches a disciplined first-pass incident workflow that separates observed evidence from assumptions and turns the initial incident read into a focused investigation plan.
