In this module
IR0.2 How Investigators Think
You've run tools. You've looked at PECmd output, scrolled through SigninLogs, stared at a Defender XDR incident graph. You know what a process tree is and how to pivot from one table to another. What you may not have been taught explicitly is the reasoning layer sitting above all of that — the layer that separates extracting data from interpreting it. This subsection makes that layer explicit.
Figure IR0.2 — The five-step reasoning chain. Every artefact in every module is processed through these five steps. Step 3 is what the tool does. Steps 1, 2, 4, and 5 are what the investigator does.
Tool operators versus investigators
The difference is not skill level. It is approach. Two analysts with identical tools and identical access can produce wildly different investigations, and the gap is entirely in the reasoning layer.
Consider the alert that would fire halfway through the incident from IR0.1. Defender XDR throws a detection: "Suspicious PowerShell command line observed on DESKTOP-NGE042." Two analysts pick it up.
The tool operator opens Advanced Hunting, queries DeviceProcessEvents for the device, finds the PowerShell execution, copies the command line, notes the execution time, adds a line to the ticket: "PowerShell executed at 15:09 with encoded command, needs investigation." They've run a tool. They've reported output. The ticket has words in it. The investigation has not moved forward.
The investigator opens the same query, finds the same record, and thinks: that timestamp is suspicious — it's seventeen minutes after an Entra ID sign-in for the same user from a residential IP in Bucharest. Is this the attacker post-authentication, or is it Claire running PowerShell herself from the same workstation on a shared session? To distinguish, I need to know the parent process and the user context. They add columns to the query — InitiatingProcessFileName, AccountName, AccountDomain — and run it again. The parent is outlook.exe. Not cmd.exe, not explorer.exe, not a legitimate automation tool. Outlook. Which means PowerShell was launched from Claire's email client. Which means an attachment or embedded link triggered it. The investigator's next move is to correlate against EmailAttachmentInfo and EmailEvents around 15:09. The investigation has moved forward by one concrete step, in the direction of the answer.
Same tool. Same data. Same alert. The difference is that the investigator ran two steps before opening the query (what am I testing, what would prove or disprove it) and one step after (what does this finding mean for the next query). The tool operator skipped to step 3, ran it, stopped.
This is not about being cleverer or more experienced. It's about having the pattern. The pattern is the five-step chain in Figure IR0.2. You can teach it. You can run it on every artefact. By module IR3 it becomes automatic. By Phase 4 it is how you think without noticing.
The five steps, explicitly
Each step has a specific job. Running the chain in the wrong order produces a bad investigation, even if all five steps are present.
Step 1 — Hypothesis. A hypothesis is an informed guess about what happened, stated as a testable proposition. "The attacker used a stolen session token to access Claire's mailbox" is a hypothesis. "Something bad happened in the mailbox" is not a hypothesis — it's not testable. The hypothesis must be specific enough that evidence can either confirm or contradict it.
A good hypothesis has two properties. It points at a specific mechanism (stolen session token, not just "the attacker got in"). And it names a specific data source that could confirm or deny it (Entra ID sign-in logs, not just "the logs").
Step 2 — Evidence. Given the hypothesis, what artefact would prove or disprove it? This step is the one most responders skip. They jump from hypothesis to extracting data without pausing to ask what, specifically, they're looking for. The consequence is the artefact collector pattern — pulling everything, looking at everything, interpreting nothing.
For the mailbox-access hypothesis, the evidence is: a sign-in entry in SigninLogs from an unusual IP with a token issuance pattern matching AiTM, a conditional access evaluation showing the session was allowed, and a MailItemsAccessed entry in the Unified Audit Log showing which messages the attacker read. Three specific data sources. Three specific queries. If those queries return nothing relevant, the hypothesis is wrong and you refine it.
Step 3 — Extract. Run the query, run the tool, pull the artefact. This is the step most tools are designed for and most training focuses on. It is also the least cognitively demanding step. Once steps 1 and 2 are done properly, step 3 is execution — and the better the tool, the faster step 3 completes.
The investigator's value in step 3 is not in running the query. It's in noticing when the query returned data shaped differently from what step 2 predicted. If you expected five sign-in events and got fifty, the volume itself is a finding. If you expected entries from one IP and got entries from three, that's a finding. The step 3 output is not just the data — it's the delta between expected data and observed data.
Step 4 — Interpret. The three-statement pattern: what does this evidence prove, what does it not prove, and what does it tell you about the next step? This is the pattern that prevents the most common investigation error — over-interpreting what a single artefact can tell you.
Prefetch shows that powershell.exe executed at 14:32. Proves: PowerShell was executed on this device at this time, and this was the first execution since Prefetch last rebuilt its cache. Does not prove: who executed it, what it did, what script ran, what the parameters were, what the session context was. Next step: correlate the execution timestamp with the Security event log (logon events around 14:32) to identify the active user session, and with the PowerShell ScriptBlock log (Event ID 4104) to see what commands were executed.
Every finding gets three statements. The discipline is what keeps investigations honest. A responder who says "Prefetch shows PowerShell executed — the attacker ran PowerShell" has collapsed steps 1, 4, and 5 into a conclusion that the evidence does not support. A responder who runs the three statements explicitly every time builds a case that holds up in the report, in the audit, and in the courtroom if it comes to that.
Step 5 — Next step. Given what the evidence proves and doesn't prove, what is the next hypothesis to test? This step generates the next cycle of the chain. The investigation is not a single pass — it is the chain run repeatedly, each cycle narrowing the scope of what you don't yet know.
The skill in step 5 is prioritisation. At any moment in an investigation you have multiple open hypotheses and multiple possible next steps. The good responder picks the one that will either resolve the highest uncertainty, preserve the most volatile evidence, or change the containment calculus the most. The bad responder picks the one that's easiest to run.
The three-statement discipline, in practice
The three-statement pattern is the hardest habit to build. It is also the one that most cleanly separates junior and senior responders in their written output.
Run it on every finding. Every time. Not just on the ones you think are important, and not just in the final report — in real time, as you are looking at the evidence.
Here is the same pattern applied to different artefact types from the NE incident.
Finding — SigninLogs entry at 14:36 from 203.0.113.47 (Bucharest residential IP). Proves: an authentication request reached Entra ID from that IP at that time and was accepted. Does not prove: that the authenticated principal was the attacker (could be Claire using a VPN, could be a legitimate travel scenario — though in this case neither is true), or that the session token was actually replayed after this entry. Next step: check the RawTokenNumber / session-identifier fields against earlier sign-ins to confirm token replay versus fresh authentication, and check the conditional access evaluation details to see why MFA was not interactively challenged.
Finding — Inbox rule created at 14:46 named "RSS Feeds" with keyword filter for "invoice," "payment," "PO." Proves: a rule with those parameters exists on Claire's mailbox and was created at that time. Does not prove: that the rule was created by the attacker rather than by Claire herself (rules can be created legitimately), or that the rule has been acted on. Next step: pull the UserId field from the rule-creation audit event to confirm it was the stolen session that created it, and query MessageTrace for emails matching the keywords that landed in Claire's mailbox after 14:46 to confirm the rule is filtering real traffic.
Finding — LSASS access event on DESKTOP-NGE042 at 15:14 from explorer.exe. Proves: a process named explorer.exe accessed the LSASS process at that time, and the access pattern is consistent with credential harvesting (specific access mask). Does not prove: that the accessing process was actually Explorer rather than a malicious payload injected into a legitimate explorer.exe instance (reflective DLL injection leaves the parent process name intact). Next step: capture memory from the device while evidence is still volatile, and use Volatility 3 windows.malfind to identify injected code regions in the explorer.exe process space.
Notice what the pattern produces. It produces report sentences you can defend. It produces follow-up steps that are specific, scoped, and testable. It produces investigation notes that another responder can pick up tomorrow without losing context. Most importantly, it produces a shared language for you to challenge your own conclusions — if you can't write all three statements about a finding, you haven't interpreted it yet, and the right action is to go back to step 2, not to move forward to a conclusion.
A worked example — one cycle of the chain against the NE incident
This is the chain run in real time against the first PowerShell alert in Claire's incident. Follow the reasoning. Notice where it pauses to think, and notice what happens at the boundaries between steps.
It is 15:15 in the NE scenario from IR0.1. A Defender XDR alert has just fired: "Suspicious PowerShell command line detected on DESKTOP-NGE042." The analyst who picks it up knows from the running incident record that an Entra ID sign-in anomaly was confirmed at 14:42 and a BEC reply was sent at 14:58. They open Advanced Hunting.
Step 1 — Hypothesis. The attacker, having obtained session access at 14:36, has moved to Claire's workstation and executed PowerShell. Specifically — if the AiTM campaign pattern holds — the execution will be a loader that stages a second-stage payload, probably loaded reflectively to avoid disk-level detection.
Step 2 — Evidence. Four data points would confirm the hypothesis. First, the PowerShell process creation event in DeviceProcessEvents showing the command line and parent process. Second, the ScriptBlock log (Event ID 4104 on the endpoint, which also lands in DeviceEvents in Defender XDR) showing what was executed. Third, a correlating network connection from DeviceNetworkEvents showing outbound traffic immediately after execution, consistent with a beacon phoning home. Fourth, the email events around the PowerShell execution time to identify how the attacker triggered the execution.
Step 3 — Extract. The analyst runs:
DeviceProcessEvents
| where DeviceName == "DESKTOP-NGE042"
| where Timestamp between (datetime(2026-11-19T15:00:00Z) .. datetime(2026-11-19T15:30:00Z))
| where FileName =~ "powershell.exe"
| project Timestamp, FileName, ProcessCommandLine,
InitiatingProcessFileName, InitiatingProcessCommandLine,
AccountName, AccountDomain
| order by Timestamp ascThe query returns one row. PowerShell executed at 15:09:14 with command line powershell.exe -nop -w hidden -enc SQBFAFgAIAAoA... (the Base64 payload runs to about 1,200 characters). Parent process: outlook.exe. Account: NORTHGATEENG\c.morrison.
Step 4 — Interpret. Proves: PowerShell was executed on DESKTOP-NGE042 at 15:09:14 by Claire's user account, launched from Outlook, with flags that indicate deliberate evasion (-nop disables profile loading, -w hidden suppresses the window, -enc runs a Base64-encoded command). The parent-process chain tells you the trigger: email-client attachment or embedded link. Does not prove: whether the encoded payload is malicious (encoded commands have legitimate uses too), or whether Claire herself or the attacker initiated the execution. The account name tells you the execution ran under Claire's context — consistent with both an attacker using her stolen credentials and Claire running something herself. Next step: decode the Base64 payload to see what it does, pull EmailAttachmentInfo for Claire's mailbox for the fifteen minutes before 15:09 to find the trigger, and check DeviceNetworkEvents for outbound connections from the PowerShell process or its children.
Step 5 — Next hypothesis. Given the payload was launched from Outlook, the most productive next direction is email — specifically, which message arrived shortly before 15:09, what attachment or link did it carry, and was it sent from an external sender or (more telling) from a compromised internal account. The analyst forms the next hypothesis: the PowerShell execution was triggered by an email Claire received between 15:00 and 15:09 that came from her own compromised mailbox — the attacker sending her an email from her own account to get her to run the loader. They move to the next cycle.
This cycle took about three minutes to think through and execute. A tool operator would have extracted the same data and written "PowerShell ran, needs investigation" on the ticket. The investigator has a hypothesis about the trigger, a specific next query to test it, and the beginning of a narrative that will end at "the attacker sent Claire an email from her own compromised mailbox to socially engineer her into running their loader." That narrative is the investigation.
The four anti-patterns
Every responder falls into these at some point. The reasoning chain is the tool that keeps you out of them.
The artefact collector. Runs every available tool against every available data source, collects thousands of lines of output, submits the stack as "the investigation." No hypothesis was tested. No evidence was interpreted. No narrative was built. The executive reading the report cannot tell what happened or what to do. This pattern is caused by skipping step 1 — starting at extraction instead of at a hypothesis. The fix: every tool you run begins with "I am testing the hypothesis that X."
The premature conclusion. Finds one suspicious artefact — a single failed logon from an unfamiliar IP — and declares a compromise. No corroborating evidence. No alternative explanation considered. Escalates the organization's incident response on a single data point that turns out, after two more cycles of the chain, to be a service account on a new VPN exit node. This pattern is caused by collapsing step 4 into step 1 — jumping to a conclusion without applying the three-statement discipline. The fix: every finding gets all three statements, explicitly, before any conclusion.
The tool-first investigator. Asks "which tool should I run?" before asking "what question am I trying to answer?" The tool choice should follow from the hypothesis, not precede it. If the hypothesis is "the attacker created persistence via a scheduled task," the correct extraction is the Task Scheduler event log (Event ID 4698) or the registry key under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache. A full memory dump is the wrong answer to this question. This pattern is caused by skipping steps 1 and 2 entirely. The fix: you do not open a tool until you can state what hypothesis the tool is testing.
The single-source investigator. Investigates the cloud or the endpoint but not both, producing the one-sided investigations described in IR0.1. This is the pattern this course is primarily designed to prevent. The fix is in the four-column scoping framework introduced in IR0.1's Artifact Footer — every investigation begins with all four environments present on the page, even if the evidence for some of them ends up being "no visibility, declared as scoping gap."
The four patterns are not rare. They are the default behavior that emerges when the reasoning chain is not explicit. Every responder will recognize themselves in at least one. The course's job is to make the chain explicit enough that you catch yourself falling into a pattern before the investigation is compromised.
The situation. You are forty minutes into the Claire investigation. You have confirmed the stolen session (SigninLogs), the inbox rule (UnifiedAuditLog), the BEC reply (MessageTrace), and the PowerShell execution at 15:09 (DeviceProcessEvents). The Base64 payload decoded to a small .NET loader that calls out to a domain-fronted C2. You have two competing hypotheses about what to investigate next.
The choice. Hypothesis A: the loader was triggered by an email the attacker sent to Claire from her own compromised mailbox. Testing this means pulling EmailEvents and EmailAttachmentInfo for the fifteen minutes before 15:09, filtering for senders matching Claire's address, examining message content. Hypothesis B: the loader was triggered by Claire opening a file she had previously downloaded from the AiTM phishing page itself. Testing this means examining browser download history, the Downloads folder on DESKTOP-NGE042, and DeviceFileEvents for writes to user-profile paths in the hour before 15:09.
Which do you test first, and why?
The correct call. Hypothesis A, first. Three reasons. First, it has the highest prior probability — the attacker-sending-from-your-own-account technique is common in AiTM campaigns specifically because it bypasses user suspicion. Second, the evidence is in a cloud data source that has long retention (Exchange Online audit is 180 days in E5) and will not decay while you investigate other things. Third, if Hypothesis A is confirmed, it immediately tells you to pivot to the mailbox to find what other emails the attacker sent from Claire's account — a scope-expansion finding that changes the investigation. Hypothesis B is worth testing regardless (both might be true) but it's a slower path to a scope-changing finding and the endpoint evidence is more volatile, so you can test it opportunistically while Hypothesis A's query is running.
The operational lesson. When you have two hypotheses, rank them by the size of the scope change their confirmation would produce, not by the effort required to test them. Cheap-to-test hypotheses that confirm narrow findings eat investigation time. Expensive-to-test hypotheses that would change the containment calculus if confirmed are worth running first. This is step 5 of the chain — prioritisation by scope change, not by tool availability.
The myth. Tools are the job. If you know KAPE, EZTools, Volatility, and KQL, you can do incident response. The rest is pattern recognition from experience.
The reality. Tools are the last twenty per cent of the investigation. The first eighty per cent is knowing which question to ask, which artefact would answer it, and what the answer means in the context of the attack. A responder with Notepad, grep, and the reasoning chain will out-investigate a responder with a £50,000 forensic suite who can't articulate what they're testing. Tools extract data. Investigators interpret it. The tool-first view is how organizations end up paying for expensive platforms and still getting shallow investigation reports — the tools are fine; the reasoning layer is missing. This course teaches the reasoning layer. The tools come second, in IR1, once you know what you'll ask them to do.
Try it: run the five-step chain against a real alert
Pick an alert from your current queue and walk it through the five steps explicitly
Setup. Open any security alert from your current environment — a sign-in anomaly, a malware detection, a DLP hit, a Conditional Access policy block. If you don't have an active queue to draw from, use a test alert or a write-up of a published incident (Microsoft Security Blog is a good source). What you need is one specific alert with one specific evidence source behind it.
Task. Write down, on paper or in a note, the five steps explicitly. One sentence per step. Step 1: state the hypothesis the alert points to. Step 2: name the specific artefact or artefacts that would prove or disprove the hypothesis. Step 3: identify which tool extracts each artefact (don't run it yet — just name the tool). Step 4: for each named artefact, write what a typical finding in that artefact would prove and what it would not prove. Step 5: given those possible findings, state what the next hypothesis would be.
Expected result. A five-sentence investigation plan for one alert. The whole exercise should take ten to fifteen minutes. The output looks like: "Hypothesis — the user's account was compromised by AiTM session theft. Evidence — SigninLogs entry showing unusual IP and token replay pattern. Extraction — KQL against SigninLogs in the last 24h for this user. Interpretation — a match on both IP anomaly and token replay pattern would prove the session was obtained anomalously, but would not prove any subsequent malicious activity in the mailbox. Next — if session anomaly confirmed, test the hypothesis that the attacker created mailbox persistence via inbox rules."
Debugging branch. If step 1 is hard, the alert itself may be ambiguous — go back and state what the alert mechanism is actually detecting rather than what it "probably means." If step 2 is hard, you may not know the evidence schema well enough for that alert type — that's a Phase 2 or Phase 3 module gap, note it. If step 4 is hard — specifically the "does not prove" clause — you are likely over-interpreting the evidence. That's the most common failure mode and the most important to catch.
You should be able to do the following without looking back at the text.