In this section
Cloud Investigation Methodology: Hypothesis-Driven Cloud IR with NIST SP 800-61 Rev 3
Scenario
Two analysts receive the same alert: anomalous sign-in for j.morrison@northgate-eng.co.uk from a VPS IP address. The first analyst queries SigninLogs, confirms the anomalous IP, resets the password, revokes sessions, closes the ticket. The second analyst runs the same query but asks a different question: "If the attacker authenticated successfully, what did they do with the access?" She pivots to OfficeActivity for inbox rules, to MailItemsAccessed for email reading, to CloudAppEvents for file downloads, to AuditLogs for directory changes. She finds the service principal credential that the first analyst's remediation left untouched. Same alert. Same tools. Same data. The difference is the reasoning chain — the sequence of questions that turns a single finding into a complete investigation.
Estimated time: 40 minutes.
Figure IR0.3. The five-step reasoning chain applied to cloud evidence. Each step generates the next question. The chain continues across evidence domains until the investigation covers identity, email, files, and directory. The three-statement discipline prevents premature closure.
Why methodology matters more than tools
The difference between an investigation that finds the service principal persistence and one that stops at the password reset is not the tooling. Both analysts have Sentinel. Both have Defender XDR. Both can write KQL. The difference is the reasoning chain — the systematic sequence of questions that drives the investigation from a single finding through every evidence domain until the picture is complete.
Cloud investigation is particularly vulnerable to premature closure because each finding feels complete. The sign-in log shows the anomalous authentication. The analyst resets the password. The finding is real, the remediation is correct, and the ticket closes. But the finding answered only the first question (did the attacker authenticate?) and ignored the four that follow (what did they do with the access? what did they change? what survives the password reset? what data was exposed?).
The methodology this course teaches prevents premature closure by making the reasoning explicit. Every finding passes through five steps, and the fifth step always generates the next hypothesis. The investigation continues until the hypothesis chain is exhausted across all four evidence domains.
The five-step reasoning chain
The chain is the same one experienced investigators use instinctively. Making it explicit forces the discipline that prevents shortcuts.
Step 1: Hypothesis. What do you think happened? This is not a guess — it's a directed question based on the evidence you have so far. "The attacker replayed a stolen session token from a foreign IP" is a hypothesis. "Something suspicious happened" is not.
Step 2: Evidence source. Which specific log source would prove or disprove the hypothesis? In cloud investigation, this means choosing the right table. SigninLogs for authentication events. MailItemsAccessed for email access. OfficeActivity for mailbox manipulation. AuditLogs for directory changes. The wrong table produces no results and wastes investigation time. The right table produces the evidence.
Step 3: Query. Run the KQL, the PowerShell, or the Graph API call. Extract the data. This step is mechanical — once you know which table to query and what you're looking for, the query writes itself. This course teaches the queries for every investigation scenario, but the skill is in steps 1, 2, 4, and 5, not step 3.
Step 4: Interpret. What does the result prove? What does it not prove? This is where most investigations fail. A sign-in log entry proves the attacker authenticated. It does not prove what they did after authenticating. A MailItemsAccessed record proves the attacker accessed emails. It does not prove what specific content they read (the log records the items accessed, not the content). The three-statement discipline forces the investigator to articulate what the finding proves, what it doesn't prove, and what the next step is.
Step 5: Next step. What question follows from this finding? If the sign-in log proves the attacker authenticated, the next question is: what did they do with the access? That generates a new hypothesis ("the attacker read email looking for payment information"), which sends you to a new evidence source (MailItemsAccessed), which produces a new finding, which generates a new question. The chain continues until all four evidence domains are covered and no more questions remain.
The three-statement discipline
Every finding in this course is documented with three statements. This isn't a template for reports — it's a thinking discipline that prevents the two most common investigation errors: overclaiming (stating that evidence proves more than it does) and premature closure (stopping the investigation before all domains are covered).
Statement 1: What this proves. The factual claim the evidence supports. "The sign-in log proves that a non-interactive authentication succeeded for j.morrison@northgate-eng.co.uk from IP 185.220.101.42 at 14:36:18 UTC on 15 March 2026." Specific. Timestamped. Attributable to a specific evidence source.
Statement 2: What this does not prove. The limitation. "This sign-in log does not prove what the authenticated session was used to do. It does not prove whether email was accessed, files were downloaded, or directory changes were made. It proves authentication, not activity." This statement prevents overclaiming and identifies the investigation gap.
Statement 3: What I need to check next. The next hypothesis. "Check MailItemsAccessed for email access during this session. Check OfficeActivity for inbox rule creation. Check CloudAppEvents for SharePoint file access. Check AuditLogs for directory modifications." This statement prevents premature closure by making the next steps explicit.
Applying the chain: a worked example
Start with the alert: anomalous sign-in for j.morrison from IP 185.220.101.42.
Cycle 1 — Identity domain. Hypothesis: the attacker replayed a stolen token. Evidence source: SigninLogs.
Finding: non-interactive sign-in, MFA satisfied from original session, location Romania, different UserAgent than Morrison's normal browser. Statement 1: proves authentication from attacker infrastructure. Statement 2: does not prove what the session was used for. Statement 3: check MailItemsAccessed.
Cycle 2 — Email domain. Hypothesis: the attacker read email. Evidence source: OfficeActivity.
Finding: 47 MailItemsAccessed records with bind operations across the inbox and sent items. Statement 1: proves the attacker accessed email content. Statement 2: throttling means the actual number of emails accessed may be higher. Statement 3: check OfficeActivity for inbox rule creation.
Cycle 3 — Email manipulation. Hypothesis: the attacker created persistence in the mailbox. Evidence source: OfficeActivity.
Finding: inbox rule "." created at 14:46, routing emails from supplier@construction-vendor.com to RSS Subscriptions and marking as read. Statement 1: proves mailbox manipulation consistent with BEC setup. Statement 2: does not prove a BEC email was sent. Statement 3: check OfficeActivity for Send operations and EmailEvents for outbound mail.
Cycle 4 — Directory persistence. The chain continues into AuditLogs for app registrations and service principal credentials. Each cycle moves to a new evidence source, answers a new question, and generates the next hypothesis. The investigation isn't complete until the chain has covered all four evidence domains: identity (how they got in), email (what they did with the mailbox), files (what data they accessed), and directory (what persistent access they created).
NIST SP 800-61 Rev 3 as the reporting framework
Your investigation produces findings. Those findings need to be communicated to stakeholders who use specific vocabulary: executives, regulators, insurers, legal counsel, law enforcement. NIST SP 800-61 Revision 3, published April 2025, provides that vocabulary.
Revision 3 is a significant restructure from Revision 2. The old four-phase lifecycle (Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident) is retired. Revision 3 aligns incident response activities with the six CSF 2.0 Functions: Govern, Identify, Protect, Detect, Respond, Recover. The operational work is the same — you still detect, contain, investigate, and recover — but the reporting framework maps differently.
This matters because the people who evaluate your investigation reports expect current vocabulary. An insurer's assessor, a regulatory body's reviewer, and an external auditor all reference the current NIST framework. Using Revision 2 terminology doesn't invalidate your investigation, but it signals that your IR program hasn't been updated since 2024.
This course references NIST SP 800-61 Rev 3 throughout. Module 10 covers cloud IR reporting in detail, including how to map investigation findings to the CSF 2.0 Functions for regulatory notifications and executive reports. The framework isn't the investigation — it's the language you use to describe the investigation to people who weren't in the room.
Section 0.4 covers the cloud investigation toolkit and lab setup.