TTX-08 · Scenario card
Phishing Tabletop Exercise: When MFA Isn't Enough
A ready-to-run phishing tabletop exercise: an adversary-in-the-middle kit steals finance sessions despite MFA. 8 timed injects, questions and a scoring rubric.
A phishing tabletop exercise walks your team through a realistic credential-theft incident, one inject at a time, so you can test detection, containment and notification decisions before an attacker forces them. This scenario uses an adversary-in-the-middle phishing kit that steals session cookies from finance users despite multi-factor authentication (MFA), hides its tracks with an inbox rule, then phishes your partners from a trusted mailbox.
It suits organisations that have MFA everywhere and assume that closes the phishing question. It tests session revocation, scoping, the hand-off between security and finance, and the awkward decision of whether to warn external partners and report a breach. If this is your first exercise, read how to run a tabletop exercise before you start.
Scenario at a glance
| Threat | Adversary-in-the-middle phishing, session-cookie theft, hidden forwarding rule and internal phishing from a compromised mailbox |
| Difficulty | Foundational |
| Duration | 2 hours including a 20-minute hotwash |
| Audience | Technical, finance and communications |
| Recommended participants | Security or IR lead, SOC analyst, email and identity administrator, service desk lead, finance director, accounts payable lead, communications lead, privacy or legal counsel |
| Prerequisites | Phishing response playbook, overview of email and identity configuration, list of key suppliers and partners with contact details |
| MITRE ATT&CK techniques | T1566.002 Spearphishing Link, T1557 Adversary-in-the-Middle, T1114.003 Email Forwarding Rule |
Exercise objectives
- Confirm how a reported phishing email is triaged and escalated, and how quickly the organisation can find every recipient and every click.
- Test whether the team knows that a password reset alone does not end a session-hijack, and who can revoke sessions and tokens across all affected accounts.
- Validate the procedure for finding and removing malicious inbox and forwarding rules, and for working out which emails were forwarded outside.
- Agree how external partners who received phishing from your domain are warned, by whom and through which channel.
- Rehearse the decision on whether the incident is a reportable personal-data breach, using documented criteria rather than instinct.
- Identify the control improvements (phishing-resistant MFA, conditional access, forwarding restrictions) that leadership would need to approve.
Starting situation
Read this aloud to players:
It is Wednesday, 09:10. The finance team is working through quarter-end invoice approvals. The organisation uses cloud email and single sign-on, and every employee has MFA with push notifications on their phone.
Yesterday afternoon, several people in finance received an email that appeared to come from your e-signature provider, asking them to review a "Q3 supplier agreement". Nobody reported it at the time. This morning, one accounts payable clerk mentions to a colleague that the document link "just went back to the login page".
Injects timeline
| # | Time | Inject | Delivered to | What players should address |
|---|---|---|---|---|
| 1 | T+00:00 | An AP clerk reports the e-signature email to the service desk; it went to 23 finance staff | Service desk → SOC | Triage, recipient search, escalation |
| 2 | T+00:20 | Proxy logs show five users visited the lookalike domain; all five completed MFA | SOC analyst → IR lead | Credential and session compromise, scope |
| 3 | T+00:45 | Sign-in logs show sessions for two of the five users from a hosting-provider IP, with no MFA prompt | Identity administrator | Session revocation, token theft, containment |
| 4 | T+01:05 | A hidden inbox rule on the AP lead's mailbox forwards emails containing "invoice" or "remittance" to an external address | Email administrator → IR lead | Forwarding rules, data exposure, scoping |
| 5 | T+01:25 | Two suppliers reply to a "change of payment details" email sent from the AP lead's real mailbox | Finance director | Internal phishing, payment fraud risk |
| 6 | T+01:40 | A partner's security team says 40 of their staff received a phishing link from your AP lead | Communications / IR lead | Partner notification, reputation |
| 7 | T+02:00 | Forwarded emails included remittance advices with suppliers' bank details and contact names | Privacy / legal | Breach assessment, notification clocks |
| 8 | T+03:00 | The CFO asks whether this must be reported, and why MFA did not stop it | Executive (CFO) | Reporting decision, control investment |
Module 1 — Detection and triage (T+00:00 to T+00:45)
Inject 1. The service desk logs a ticket from an accounts payable clerk: "I think this e-signature email might be fake. The link looked odd." The email came from a lookalike domain that differs from the real provider by one letter. A quick search shows it reached 23 people in finance and procurement yesterday afternoon.
Inject 2. The SOC checks web proxy logs. Five users visited the lookalike domain. The page was a pixel-perfect copy of your single sign-on login, and identity logs show all five completed a successful MFA push approval at the same time as their visit. One of the five is the accounts payable lead.
Inject 3. The identity administrator reviews sign-in logs. For two of the five users, including the AP lead, there are new sessions from an IP address belonging to a cloud hosting provider in another country. These sessions never triggered an MFA prompt. The attacker appears to be replaying stolen session cookies.
Discussion questions:
- Who decides that a reported phishing email is an incident rather than a ticket? What is the threshold?
- Can you search and purge the email from all 23 mailboxes quickly? Who has the rights to do it?
- Why did MFA not stop this? Does everyone in the room understand how an adversary-in-the-middle kit works?
- What does containment look like: password reset, session revocation, refresh-token revocation, MFA re-registration? Who performs each, and in what order?
- Do you treat all five users as compromised, or only the two with suspicious sessions?
Module 2 — Persistence and spread (T+01:05 to T+01:40)
Inject 4. While reviewing the AP lead's mailbox, the email administrator finds an inbox rule named "." that forwards any message containing "invoice" or "remittance" to an external webmail address and marks the original as read. The rule was created 14 minutes after the first suspicious sign-in. No one knows how many emails have been forwarded.
Inject 5. Two suppliers reply to an email sent from the AP lead's genuine mailbox this morning: "Please confirm the new bank details for our upcoming payments." The AP lead did not write it. The finance director learns that one supplier has already updated its records to send a refund to the new account.
Inject 6. A long-standing partner's security team calls the IR lead. Forty of their staff received an email from your AP lead with a link to "view the shared remittance file". Two of their people clicked. They ask what happened, whether your domain is still sending phishing and what indicators they should block.
Discussion questions:
- How do you find every malicious rule, forwarding setting and OAuth app consent across all five accounts, not just the one you found?
- Can message trace show exactly which emails were forwarded, and how far back can you look?
- Who contacts the suppliers who received the fraudulent bank-change request, and by what channel? (Compare the business email compromise scenario.)
- Should the AP lead's mailbox be disabled outright, even though it is quarter-end?
- Who speaks to the partner's security team? What can you share, and under which traffic light protocol marking?
- Do you proactively warn every external contact the compromised mailboxes emailed today?
Module 3 — Exposure and reporting (T+02:00 to T+03:00)
Inject 7. The email administrator reconstructs the forwarding history: 61 emails were forwarded over roughly 18 hours. Most are routine invoices, but several are remittance advices containing supplier bank details and named contacts, and one thread includes an employee's expense claim with a home address.
Inject 8. The CFO joins the call: "I need a straight answer. Do we have to report this to anyone? And we spent money on MFA last year; why did it not stop this?" The CFO wants a recommendation before the end of the day.
Discussion questions:
- Does the forwarded data include personal data? Who assesses the risk, and when did the organisation become "aware" for any notification clock?
- Do you need to tell the suppliers whose bank details were exposed, and the employee whose address was forwarded?
- Should you report to law enforcement or your national cyber authority? Does your cyber-insurance policy require notice?
- How do you explain adversary-in-the-middle phishing to the CFO in two sentences, without blaming staff?
- Which control changes would you ask for: phishing-resistant MFA for finance, conditional access, blocking external auto-forwarding?
Discussion questions
Consolidated themes for the hotwash and for facilitators who need prompts:
- Containment: Did the team revoke sessions and tokens, or only reset passwords? Is that sequence written in the playbook?
- Scoping: How confident is the team that it found every affected account, rule and forwarded message? What evidence supports that confidence?
- Finance and security hand-off: When did finance learn it was a target, and did anyone freeze payment-detail changes?
- External communications: Who owns warnings to suppliers and partners, and is there a template?
- Regulatory judgement: Was the breach decision documented with its reasoning and timestamp?
- Control gaps: Which improvements need an executive decision rather than an IT ticket?
Curveballs / optional injects
Use one or two if the group is moving quickly or needs more pressure:
- The attacker registered a new MFA method on one account, so even after revocation they can sign in again.
- A third finance user reports a new phishing email, this time from a supplier's genuine mailbox, suggesting the supplier is compromised too.
- The external forwarding address turns out to be a common webmail provider, and legal asks whether you can request a takedown.
- A staff member posts on social media that "the whole finance team got hacked" before any internal message has gone out.
Facilitator notes
Expected decisions. A well-prepared team escalates the reported email to an incident within inject 1 or 2, purges the message from all mailboxes, and treats every user who completed MFA on the fake page as compromised. It revokes sessions and refresh tokens, not just passwords, reviews registered MFA methods, and hunts for rules and consents across all five accounts. Finance freezes payment-detail changes for the affected suppliers and calls them on known numbers. Someone owns partner notifications, and the breach decision is made against written criteria with legal and privacy in the room.
Common pitfalls.
- The team resets passwords and closes the ticket, leaving stolen sessions active.
- Only the reporting user's mailbox is checked; the other recipients who clicked are ignored.
- Nobody knows how long message-trace or audit logs are retained, so the scope of forwarding cannot be proven.
- Partners find out from their own security team rather than from you.
- The reporting question is answered as "it was only emails" without anyone reading what the emails contained.
Adapting the audience. For a technical group, expand Module 1 with the actual steps in your identity platform and ask players to name the console and role needed for each action. For a finance-heavy group, compress Module 1 into a briefing and spend longer on injects 5 and 7. You can run this scenario live with players' phones through the exercise runner, which also exports the after-action notes. For more on writing your own variations, see designing tabletop injects.
Evaluating the exercise
| Capability | What good looks like | Red flags |
|---|---|---|
| Triage and escalation | Reported email becomes an incident quickly; all recipients and clickers identified | Treated as a single user's ticket; no recipient search |
| Account containment | Sessions and tokens revoked, MFA methods reviewed, in a known order by named people | Password reset only; nobody sure who can revoke sessions |
| Scoping | Rules, forwarding and app consents checked on every affected account; forwarded mail listed | One mailbox checked; log retention unknown |
| Payment fraud prevention | Bank-detail changes frozen; suppliers called back on known numbers | Suppliers contacted by replying to the same email thread |
| External notification | Partners warned promptly with useful indicators; one owner | Partners learn from their own SOC; conflicting messages |
| Breach decision | Decision made against criteria, with reasoning and timestamp recorded | "It was only emails"; no one reviewed the content |
Related
Frequently asked questions
What is a phishing tabletop exercise?
A phishing tabletop exercise is a facilitated discussion in which IT, security, finance and communications staff walk through a realistic phishing incident, inject by inject, and decide what they would do. It tests detection, escalation, account containment, scoping and notification decisions without touching production systems, and it exposes gaps in playbooks before a real attacker does.
How can phishing bypass multi-factor authentication?
Adversary-in-the-middle phishing kits sit between the user and the real login page. The victim enters their password and approves MFA as normal, the kit relays everything to the genuine service, and it captures the resulting session cookie. The attacker then replays that cookie and is signed in without needing the password or MFA again, until the session is revoked.
Is resetting the password enough after a phishing compromise?
No. If the attacker holds a stolen session token, a password reset may not end their access. Containment should also revoke active sessions and refresh tokens, review MFA methods registered to the account, remove malicious inbox rules and OAuth app consents, and check for mail forwarding. The exercise should test whether your team knows each step and who performs it.
Who should attend a phishing tabletop exercise?
Include the security or IR lead, an email or identity administrator, a SOC analyst, the finance director and an accounts payable representative, communications, legal or privacy, and the service desk. Finance matters because attackers target people who handle invoices and payments, and communications matters once phishing emails start leaving your own domain.