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
- Tabletop Exercise Scenario
- Facilitator’s Script
- Participant Handout
- After‑Action Report (AAR) ← this article
Before We Begin – What an AAR Actually Is
An After‑Action Report is where a tabletop exercise turns into something real. It’s the moment where the conversation becomes clarity, and clarity becomes improvement. This AAR captures not just what happened in the scenario, but how the team thought, reacted, hesitated, and learned, because that’s where the real value sits.
Note: This AAR is based on a fictional tabletop exercise created for this Incident Response series.
After‑Action Report (AAR)
Tabletop Exercise: Identity Compromise via MFA Fatigue & OAuth Persistence
Facilitator: Tayven
Date: Fictional
Participants: Priya (SOC Analyst) Jordan (Incident Manager) Sam (ICT Manager) Morgan (ELT Representative) Taylor (Scribe)
1. Executive Summary
This tabletop exercise walked the team through a compressed identity compromise involving MFA fatigue, malicious OAuth persistence, and a delayed SOC response due to business‑hour coverage. The team handled the scenario with confidence and clarity. They communicated well, recognised the identity‑based attack patterns quickly, and made sound decisions under time pressure.
The exercise also surfaced several governance and automation gaps that would meaningfully affect a real incident. None of these gaps were surprising, they’re the kind of issues that only become visible when you slow down and walk through the scenario together. That’s the value of a tabletop: it reveals how the organisation actually works, not how we assume it works.
Overall, the exercise met its objectives and produced realistic, in‑scope recommendations aligned with organisational constraints.
2. Scenario Recap
At 06:12, the user received repeated MFA prompts and accidentally approved one while half‑asleep. The attacker authenticated into Microsoft 365, registered a malicious OAuth application, created inbox rules to hide alerts, and accessed OneDrive files.
Automation detected the OAuth anomaly at 06:45, but the SOC didn’t see it until their shift began at 08:00. SOC escalated quickly, and containment was completed by 08:12. During the Hot Wash, the team discovered that the end user had reused their password across multiple services and that the password appeared in a known third‑party breach.
3. Objectives
The exercise was designed to test five core capabilities:
- Test identity threat detection and response
- Validate SOC shift‑start workflows
- Assess escalation and communication pathways
- Identify governance and training gaps
- Map findings to NIST CSF 2.0 categories
4. Incident Overview (Anonymous Team Reflection)
The team approached the scenario with honesty and realism, quickly grounding the discussion in the human factors that make identity incidents possible. An early acknowledgement of how easily MFA fatigue can lead to accidental approval set the tone for a candid, productive session.
Analysts demonstrated strong technical instincts, especially around recognising OAuth persistence and understanding when escalation is warranted. A brief pause before escalation sparked a useful conversation about confidence, urgency, and how analysts balance validation with action.
Coordination remained steady throughout. Communication was clear, and when regulatory questions surfaced, the team openly acknowledged uncertainty, which led to a valuable discussion about reporting thresholds and policy clarity.
Operationally, the team brought practical insight into access revocation, mailbox rule detection, and containment workflows. Occasional off‑topic tangents revealed useful context about how ICT thinks during incidents. A reminder that cross‑functional perspectives add value even when they pull the conversation sideways.
Leadership expectations were represented accurately, creating healthy pressure for the SOC to articulate what they knew, what they didn’t, and what they needed next. Documentation improved as the exercise progressed, shifting from general discussion to clear decision capture.
Overall, the team demonstrated strong collaboration, solid technical reasoning, and a willingness to be honest about gaps. Exactly what a tabletop is meant to reveal.
5. Strengths Identified
Identity Awareness The team didn’t just recognise the attack pattern, they understood the attacker’s intent. That’s the difference between reacting and responding.
SOC Workflow Once the shift began, the SOC moved with clarity. The handoff from automation to analyst was smooth and confident.
Communication The conversation flowed naturally. No one dominated, and no one disappeared. That balance is rare in tabletop sessions.
Leadership Alignment Leaderships questions sharpened the team’s thinking. They forced the SOC to articulate uncertainty clearly, a skill that matters in real incidents.
Engagement Everyone stayed present. No passengers. That alone makes a tabletop successful.
6. Areas for Improvement
After‑Hours Alerting The gap wasn’t surprising, but seeing it play out in real time made the risk impossible to ignore.
OAuth Governance Self‑consent boundaries were fuzzier than expected. This is a governance issue, not a technical one.
Inbox Rule Monitoring The team realised how invisible mailbox rule manipulation can be and how dangerous that invisibility is.
Password Hygiene Password reuse wasn’t a shock, but it was a reminder that governance and user behaviour are inseparable.
Training The MFA fatigue training is outdated. The scenario made that clear.
Escalation Criteria The ELT notification threshold exists informally, but informally isn’t enough.
7. Recommendations (Realistic & In‑Scope)
These recommendations are achievable within existing constraints and directly address the gaps surfaced in the exercise.
Policy & Governance
These changes create the guardrails that make the technical fixes stick.
- Restrict OAuth self‑consent
- Document ELT escalation thresholds
- Add password reuse prevention to the credential policy
Technology
Small, targeted improvements that close the attacker’s foothold.
- Enable breached‑password detection
- Enable number matching for MFA
- Improve alert prioritisation for high‑risk identity anomalies
- Add automated detection for suspicious inbox rule creation
Process
Process gaps are where incidents slow down. These fixes tighten the response flow.
- Formalise shift‑start alert review workflow
- Add an “MFA fatigue response” section to the IRP
- Ensure scribe captures decisions, not just discussion
Training
The human layer needs reinforcement, this scenario made that clear.
- Deliver updated MFA fatigue awareness training
- Provide role‑based training for SOC analysts on OAuth threats
- Reinforce user guidance on unexpected MFA prompts
8. NIST CSF 2.0 Category Mapping
- PR.AA – Identity & Access Control
- PR.AT – Awareness & Training
- DE.AE – Anomalies & Events
- DE.CM – Continuous Monitoring
- RS.AN – Analysis
- RS.CO – Communications
- RS.MI – Mitigation
- GV.OC – Oversight & Culture
- GV.RM – Risk Management Strategy
- ID.AM – Asset & Data Visibility
- ID.IM – Improvement
- RC.CO – Recovery Communications
9. Remediation Register
The following items form the initial remediation register and will be tracked through the security governance process.
| Issue | Recommendation | Owner | Priority | Timeline |
|---|---|---|---|---|
| MFA fatigue risk | Update user training | Jordan | Medium | 30 days |
| OAuth self‑consent | Restrict app consent | Sam | High | 14 days |
| Inbox rule visibility | Add monitoring alerts | Priya | High | 21 days |
| Password reuse | Enable breached‑password detection | Sam | High | 30 days |
| ELT escalation | Document thresholds | Morgan | Medium | 45 days |
| MFA fatigue approvals | Enable number matching for MFA | Sam | High | 14 days |
10. Next Steps
- Update IRP and identity playbook
- Implement remediation items
- Schedule follow‑up tabletop in six months
- Validate improvements through a focused identity‑threat drill
Conclusion
This exercise showed the team at their best: collaborative, thoughtful, and willing to be honest about what works and what doesn’t. Identity compromises move fast and leave little room for hesitation, but the conversations that matter, the ones that actually improve capability, only happen when the room feels safe enough for people to speak openly. That psychological safety is what makes a tabletop valuable, and it’s what turned this scenario into a meaningful improvement opportunity for the whole organisation.
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 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 Write a Post-Incident Review (PIR) Report (With Real-World Example)
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
