Series Introduction
This article is part of my Incident Response series, where I use the same fictional identity compromise across every piece to keep the entire workflow aligned. The goal is to show how a single incident can be documented, analysed, simulated, and improved, exactly the way a real organisation would handle it. The series covers how to report an incident, how to run a tabletop exercise, how to facilitate it, what supporting documents to provide, and how to write the After‑Action Report that turns discussion into measurable improvement.
Articles in the series:
- Post‑Incident Review (PIR) Example ← this article
- Tabletop Exercise Scenario
- Facilitator’s Script
- Participant Handout
- After‑Action Report (AAR)
A PIR isn’t just paperwork. It’s where the real learning happens. It’s the document that turns an incident into improvement. To show you what a mature, well‑structured PIR looks like in practice, here’s a full example based on a realistic MFA fatigue and OAuth compromise scenario.
This example is fully aligned to NIST CSF 2.0, including the new GOVERN function, and demonstrates how to map findings, remediation actions, and IRP updates to CSF subcategories.
Note: The PIR below is based on a fictional scenario created for this series.
Post‑Incident Review (PIR)
Incident: Compromised Microsoft 365 Account via MFA Fatigue and OAuth Persistence
Severity: Medium (justification in Section 3.4)
PIR Completion: Within 5 Business Days
Facilitator: Incident Lead
Participants: SOC, ICT Management, Risk Advisor, User, ELT Representative
1. Executive Summary
A staff member was targeted with an MFA fatigue attack early in the morning. After receiving repeated MFA prompts, the user accidentally approved one, allowing the attacker to authenticate into Microsoft 365. The attacker immediately registered a malicious OAuth application, created inbox rules to suppress alerts, and accessed files stored in OneDrive.
Because the SOC operates 8am–5pm, automated alerts generated before business hours were not reviewed until the shift began. Containment actions were executed promptly at 08:12, preventing lateral movement or privilege escalation.
During the next‑day Hot Wash, the team discovered that the user had reused their Microsoft 365 password across multiple external services. Credential checks confirmed the password had been exposed in a known third‑party breach, significantly increasing the likelihood of targeted MFA fatigue attacks.
The incident was contained quickly, but several identity governance and detection gaps were identified across GOVERN (GV), IDENTIFY (ID), PROTECT (PR), and DETECT (DE) functions.
2. Incident Timeline
06:12–06:14 User receives repeated MFA prompts. Attacker executes MFA fatigue attack. User accidentally approves one.
06:14 Successful MFA approval recorded. Attacker gains access to Microsoft 365.
06:16–06:26 Attacker registers a malicious OAuth application (Mail.ReadWrite, Files.ReadWrite, offline_access). Attacker creates inbox rules to hide alerts. Attacker accesses and downloads OneDrive files (approx. 12 files over a ~10‑minute window). Attempts SharePoint and Teams access.
06:30 Impossible travel event logged. Categorised as low‑fidelity due to overly broad geolocation thresholds.
06:45 Defender for Cloud Apps generates automated alert for unusual OAuth token activity. Alert queued for SOC review.
08:00 SOC shift begins. Analyst reviews queued alert immediately.
08:05 Triage confirms suspicious OAuth app, inbox rule creation, unusual file access, and MFA approval at 06:14.
08:12 Incident escalated to Incident Lead. Account locked. OAuth tokens revoked.
08:20 Malicious OAuth app deleted. Unauthorised mailbox rules removed.
08:35 Initial scoping confirms:
- no privilege escalation
- no password change
- no lateral movement
- limited attacker access window (~10 minutes)
08:50 Forensic export of mailbox and OneDrive logs initiated.
09:10 User contacted. Confirms accidental MFA approval.
09:30 ELT notified (first available time). Risk Advisor engaged.
10:15 Preliminary findings delivered to ICT Management and Risk Advisor.
14:00 Incident formally classified as Medium Severity.
Next Business Day – 09:00 Hot Wash reveals password reuse + external breach exposure.
Within 5 Business Days PIR completed.
3. Impact Assessment
3.1 Data Accessed
- Approximately 12 OneDrive files accessed and downloaded over a ~10‑minute window.
- The downloaded files did not contain sensitive, regulated, or personally identifiable information.
- No evidence of mass exfiltration or automated sync abuse.
- No SharePoint or Teams compromise.
- No mailbox export or bulk mail access.
3.2 Business Impact
- No operational downtime.
- No customer‑facing disruption.
- Moderate reputational risk due to identity compromise.
- Elevated identity‑related risk requiring governance review.
3.3 Regulatory Impact
- No mandatory reporting thresholds met.
- Risk Advisor notified to confirm regulatory position.
3.4 Severity Justification
The incident was classified as Medium Severity because:
- attacker access was limited and contained quickly
- no privileged accounts were compromised
- no regulated or high‑sensitivity data was confirmed accessed
- no regulatory reporting was triggered
- no business operations were disrupted
4. Root Cause Analysis (RCA)
Primary Cause
- User approved an MFA push during an MFA fatigue attack.
Contributing Causes
- Password reuse across multiple external services (PR.AC).
- Password found in a known third‑party breach (ID.IM).
- OAuth self‑consent enabled for standard users (GV.OC).
- No alerting on inbox rule creation (DE.AE).
- Impossible travel alert misconfigured (DE.AE).
- No SOC coverage before 8am (RS.CO).
Underlying Systemic Causes
- Insufficient identity governance (GV.OC, GV.RM).
- Gaps in conditional access policy (PR.AC).
- Lack of user awareness around MFA fatigue (PR.AT).
- No automated password breach monitoring (ID.IM).
5. Response Evaluation
What Worked Well
- Automated alerting detected OAuth anomaly (DE.AE).
- SOC acted immediately at shift start (RS.CO).
- Containment completed within 12 minutes of human review (RS.MI).
- No lateral movement or privilege escalation (PR.AC).
- ELT notified promptly at first available time (RS.CO).
What Did Not Work Well
- User approved MFA prompt (GV.OC).
- Password reuse + breached credentials (PR.AC, ID.IM).
- OAuth self‑consent enabled (GV.OC).
- Inbox rule creation not monitored (DE.AE).
- Impossible travel alert thresholds too broad (DE.AE).
- No automated revocation of suspicious OAuth apps (RS.MI).
6. Lessons Learned
Identity Risks Are Now the Primary Attack Vector
This incident reinforces that attackers increasingly target cloud identity layers rather than endpoints. MFA alone is no longer sufficient; identity governance, OAuth controls, and behavioural detection must be treated as core security capabilities (GV.OC, PR.AC, DE.AE).
User Behaviour Remains a Critical Weakness
Password reuse and MFA fatigue susceptibility significantly increased the likelihood of compromise. Even with strong technical controls, user behaviour can undermine security unless supported by continuous training and automated safeguards (GV.OC, ID.IM, PR.AT).
OAuth Governance Must Be Strengthened
OAuth persistence is a preferred attacker technique because it bypasses traditional MFA and survives password resets. Organisations must treat OAuth governance as a mandatory identity control, not an optional enhancement (GV.OC, PR.AC).
Automation Must Be Tuned, Not Trusted Blindly
The impossible travel alert was logged but deprioritised due to overly broad thresholds. High‑risk identity anomalies require precise tuning to avoid false negatives and ensure timely escalation (DE.AE).
Continuous Improvement (ID.IM) Is Essential
This incident demonstrates the importance of feeding lessons learned back into governance, detection, and training. Identity‑centric incidents evolve quickly, and the IRP must evolve with them (GV.RM, ID.IM, RC.IM).
7. Remediation Actions (With CSF 2.0 Subcategory Mapping)
| Action | Owner | Target Date | Status | CSF Mapping |
|---|---|---|---|---|
| Enforce password breach detection | IAM Lead | 30 days | In Progress | ID.IM |
| Enforce password uniqueness | IAM Lead | 30 days | In Progress | PR.AC |
| Enable number‑matching MFA | ICT Security | 14 days | In Progress | PR.AC |
| Disable OAuth self‑consent for standard users | IAM Lead | 7 days | In Progress | GV.OC / PR.AC |
| Enable inbox rule creation alerts | SOC Manager | 14 days | In Progress | DE.AE |
| Tune impossible travel thresholds | SOC Manager | 14 days | In Progress | DE.AE |
| Implement automated OAuth token revocation rules | SOC Manager | 30 days | In Progress | RS.MI |
| Update risk register | Risk Advisor | 7 days | In Progress | GV.RM |
| Add identity governance review to quarterly meetings | ICT Management | Next quarter | Scheduled | PR.AT |
| Add MFA fatigue awareness module | Training Lead | Next quarter | In Progress | PR.AT |
| Add password hygiene refresher | Training Lead | Next quarter | In Progress | PR.AT |
| Add identity‑centric phishing simulations | Training Lead | Next quarter | In Progress | PR.AT |
| Implement mandatory annual cyber security training for all staff | Training Lead | Next quarter | In Progress | PR.AT |
8. IRP Updates Required
These updates map directly to the organisation’s IRP template (Section 2.8 Continuous Improvement) and align with the GOVERN, IDENTIFY, PROTECT, DETECT, and RESPOND functions defined earlier in the IRP series.
- Add OAuth governance to Govern → GV.OC
- Add risk register updates to Govern → GV.RM
- Add password breach monitoring to Identify → ID.IM
- Add conditional access and MFA improvements to Protect → PR.AC
- Add inbox rule and impossible travel detection to Detect → DE.AE
- Add OAuth revocation and escalation steps to Respond → RS.MI / RS.CO
9. Final Assessment
This incident reflects a broader shift in the threat landscape: attackers increasingly target identity layers, exploiting human behaviour and cloud‑native features rather than traditional endpoints. MFA fatigue, OAuth persistence, and breached credentials form a modern attack chain that bypasses legacy controls entirely.
Once remediation actions are completed, the organisation will have a significantly stronger identity posture, with improved governance, more precise detection logic, and a more resilient authentication model. The improvements identified in this PIR materially reduce the likelihood and impact of similar incidents and reinforce the organisation’s commitment to continuous improvement under NIST CSF 2.0, especially the GOVERN and IDENTIFY functions.
Continue Reading
This is part of an ongoing series. If you want the full picture, the rest of the articles are worth your time.
How to Create a Participant Handout for a Cybersecurity Tabletop Exercise
How to Write an After Action Report (AAR) for Cyber Tabletop Exercises
How to Run a Cybersecurity Tabletop Exercise: Facilitator Script with Discussion Prompts
How to Run a Cybersecurity Tabletop Exercise: A Complete Example Scenario and Facilitation Guide
How to Build an Incident Response Plan: A Complete NIST CSF 2.0 Example
How to Write a Modern Incident Response Plan (IRP) Using NIST CSF 2.0
The Evolution of Incident Response: Updating the Classic NIST IRP to the 2026 Framework
