Most organisations exercise ransomware, yet the attacks that actually open the door are identity attacks: a convincing call to the help desk, a replayed session cookie, a new secret quietly added to a service principal. General scenario packs usually carry one identity scenario at most, so the hard identity decisions are never rehearsed: who may reset an executive's MFA, who can disable a production service principal at 2am, and how a federation trust is checked. This template gives [Organisation] six ready-to-run identity scenarios with timed injects, discussion questions, expected decisions and evaluation points, covering the help desk, the identity provider (IdP), non-human identities (NHIs), suppliers and AI agents. It is for exercise planners, incident leads, identity teams and SOC managers, and it complements the broader Tabletop Exercise Scenario Pack, whose IdP admin compromise and leaked cloud key scenarios are not repeated here.
How to use this template
- Pick one or two scenarios per session. Each runs in 60 to 90 minutes. Running all six in a day produces fatigue, not learning.
- Replace every [placeholder] with your real systems, role names and thresholds. Exercises built on generic names test nothing.
- Bring the people who own the decisions: help desk lead, identity platform owner, application owners for the NHIs involved, and someone who can authorise a production outage.
- Run it as a no-fault discussion. The aim is to find gaps in process and authority, not to grade individuals.
- Record outcomes in the Tabletop Exercise After Action Report Template and track actions to closure. Method and facilitation are covered in the Tabletop Exercise Guide.
1. Purpose
1.1 To test whether [Organisation] can detect, decide on and contain identity-led attacks against workforce accounts, the identity provider, non-human identities and delegated third-party access, and whether the right people hold the authority to act quickly.
1.2 Each scenario tests three things: whether the detection exists and reaches someone, whether the decision owner is clear, and whether containment removes every form of access (sessions, tokens, MFA methods, credentials and trusts), not only the password.
2. Scope
2.1 In scope: [workforce IdP], [help desk platform], [cloud platforms], [CI/CD], [key SaaS applications], service accounts, service principals, API keys, OAuth applications and AI agents with delegated access.
2.2 Out of scope unless chosen: live technical testing. For hands-on validation of the same detections, see the Purple Team Exercise Plan Template.
3. Roles and exercise rules
| Role | Who | Responsibility in the exercise |
|---|---|---|
| Facilitator | [Name] | Delivers injects, keeps time, asks follow-up questions |
| Incident lead | [Name] | Makes or escalates decisions as in a real incident |
| Help desk lead | [Name] | Explains verification and reset steps as actually performed |
| Identity platform owner | [Name] | Explains what can be revoked, how fast and by whom |
| Application and NHI owners | [Names] | Decide on disabling or rotating machine credentials and the outage it causes |
| SOC lead | [Name] | Describes what alerts exist and what the analyst would see |
| Legal, privacy, communications | [Names] | Notification and messaging decisions |
| Scribe | [Name] | Records decisions, times, gaps and actions |
3.2 Rules: answer as the organisation works today, not as the policy says it should; say "we do not know" when that is the truth; the facilitator may pause to capture a gap.
4. Scenario index
| No. | Scenario | Primary audience | ATT&CK |
|---|---|---|---|
| 5.1 | Help desk MFA reset of an administrator | Help desk, identity, SOC | T1078 Valid Accounts; T1621 Multi-Factor Authentication Request Generation |
| 5.2 | Session cookie replay after adversary in the middle phishing | SOC, identity, finance | T1539 Steal Web Session Cookie |
| 5.3 | New secret added to a privileged service principal | Identity, cloud, application owners | T1098.001 Additional Cloud Credentials |
| 5.4 | Rogue federated identity provider added to the tenant | Identity, executive | T1484.002 Trust Modification |
| 5.5 | Supplier administrator account used against [Organisation] | Third-party risk, identity, legal | T1199 Trusted Relationship |
| 5.6 | AI agent OAuth token used outside the agent | AI platform, identity, data protection | T1528 Steal Application Access Token; T1550.001 Application Access Token |
5. Scenario scripts
5.1 Help desk MFA reset of an administrator
Objectives: test caller verification for privileged users; test how quickly a fraudulent reset is spotted and reversed; confirm who can order an emergency lock of an administrator account. Participants: help desk lead, identity owner, SOC, [IT director].
Summary: a caller claiming to be [named cloud administrator], travelling with a broken phone, asks the help desk to reset MFA. They know the employee ID, manager's name and recent project details. CISA's advisory on Scattered Spider (AA23-320A) describes exactly this pattern: attackers persuading help desk staff to reset passwords or MFA, then registering their own MFA to keep access.
| Time | Inject | Discussion questions |
|---|---|---|
| T+0 | Help desk agent resets MFA after the caller answers knowledge questions. | What does our procedure require for a privileged user? Could the agent have refused? |
| T+20m | The IdP logs "User registered security info" for the administrator from a new country. | Does any alert fire on a new MFA method for a privileged account? Who sees it? |
| T+45m | The real administrator, in the office, reports they cannot sign in. | Who decides this is an incident? How do we lock the account and revoke sessions out of hours? |
| T+2h | Logs show the attacker created a new access key for a cloud automation identity. | Is this now an NHI incident too? Who owns that identity? |
Expected decisions: lock the account, revoke sessions and remove attacker MFA methods; treat any NHI credentials the account created or could read as compromised; move privileged resets to a verified, in-person or manager-attested process. Evaluation points: time from fraudulent reset to detection; whether new MFA registration on admins is alerted; whether NHI follow-on was considered. See the Help Desk Social Engineering Incident Playbook and the Help Desk Identity Verification Policy Template. The Co-op breach reportedly began with a social-engineered password reset.
5.2 Session cookie replay after adversary in the middle phishing
Objectives: test whether responders know a password reset does not end a stolen session; test mailbox rule and payment fraud checks. Participants: SOC, identity, [finance controller], communications.
| Time | Inject | Discussion questions |
|---|---|---|
| T+0 | A finance user reports a "document share" login page that asked for MFA twice. | What do we check first: sign-in logs, sessions, mailbox rules? |
| T+30m | The SOC resets the user's password. One hour later, the same session is still reading mail from a hosting provider address. | Why did the reset not work? What revokes refresh tokens and sessions in [IdP]? |
| T+3h | An inbox rule forwarding invoices to an external address is found. | Which suppliers were emailed? Who calls them, and how? |
Expected decisions: revoke sessions and refresh tokens, remove rules and app consents, check for new MFA methods, warn finance to verify payment changes by phone. Evaluation points: whether the team knew access tokens can stay valid after revocation until they expire; time to session revocation. See the Session Token Theft Response Playbook.
5.3 New secret added to a privileged service principal
Objectives: test NHI ownership, detection of credential additions and the authority to cause a production outage. Participants: identity, cloud platform, [application owner], SOC.
| Time | Inject | Discussion questions |
|---|---|---|
| T+0 | The audit log shows "Add service principal credentials" on [integration app] by an account that is not the deployment pipeline. | Does any rule watch for credential additions outside the pipeline? Who owns this application? |
| T+1h | The new secret signs in from an address outside [Organisation] and reads [data store]. | Can we remove only the new secret, or must we disable the whole principal? What breaks? |
| T+2h | The owner says disabling it stops order processing. | Who authorises the outage? What is the fallback? |
| T+1d | A second application shows the same pattern from the same actor. | How do we sweep all applications for unexpected credentials? |
Expected decisions: remove the unknown credential, rotate the legitimate ones, investigate the account that added it, sweep all applications for credentials added outside automation. Evaluation points: owner found within [30 minutes]; credential-level containment possible without full outage. See the MITRE ATT&CK T1098.001 Account Manipulation guide.
5.4 Rogue federated identity provider added to the tenant
Objectives: test whether trust changes in the IdP are monitored and who can roll them back. Participants: identity, SOC, [CISO], [CIO].
Summary: CISA's AA23-320A describes actors adding a federated identity provider to a victim's single sign-on tenant with automatic account linking, so they can sign in as other users even after password changes.
| Time | Inject | Discussion questions |
|---|---|---|
| T+0 | The audit log shows "Set federation settings on domain" by a global administrator who is on leave. | Is a federation change alerted? Who reviews it? |
| T+2h | Sign-ins for three executives arrive through the new federation with no MFA prompt. | How do we remove the trust without locking out legitimate users? Do we have break-glass accounts that do not depend on federation? |
| T+6h | The board chair asks whether email can be trusted. | What do we tell executives, and through which channel? |
Expected decisions: remove the rogue trust, review all identity provider configuration changes, investigate the administrator account, use out-of-band communication. Evaluation points: alert existed; break-glass worked. See the Golden SAML and Federation Trust Abuse Defence Guide and the Identity Provider Tenant Compromise Playbook.
5.5 Supplier administrator account used against [Organisation]
Objectives: test visibility of delegated third-party access and contractual contacts. Participants: third-party risk, identity, legal, [supplier relationship owner].
| Time | Inject | Discussion questions |
|---|---|---|
| T+0 | [Managed service provider] announces a breach of its own systems. | Which of their accounts, tokens and remote tools can reach us? Where is that list? |
| T+3h | A supplier admin account creates a new user in [Organisation]'s tenant. | Can we suspend all supplier access at once? What service stops if we do? |
| T+1d | The supplier asks to restore access to meet a contractual service level. | What evidence do we require first? |
Expected decisions: suspend supplier accounts and tokens, remove identities they created, reinstate with time-bound access. See the Compromised MSP Playbook.
5.6 AI agent OAuth token used outside the agent
Objectives: test ownership and revocation of agent credentials acting on behalf of users. Participants: AI platform owner, identity, data protection, SOC.
| Time | Inject | Discussion questions |
|---|---|---|
| T+0 | The agent's OAuth client is seen calling [mail and file APIs] from an address that is not the agent's hosting environment. | Do we know the agent's expected sources? Which users granted it access? |
| T+1h | The token's scopes include read access to all files of [120] users who consented. | Do we revoke the grant for everyone, or rotate the client secret first? Who owns the agent? |
| T+4h | Files containing personal data were downloaded. | Does a personal data breach notification clock start? Who decides? |
Expected decisions: rotate the client credential, revoke grants and tokens, scope down permissions before reinstating, assess notification. See the OAuth Token Theft Incident Playbook and AI agent incident exercises.
6. Facilitator guide
- Before: confirm the named systems exist and that the audit events in the injects are ones your platform records; swap them for your IdP's equivalents where needed.
- During: ask "how would you know?" before "what would you do?". Push for times and names, not intentions.
- Add twists if the room moves too easily: the decision owner is unreachable, the break-glass account fails, or the affected NHI has no owner on record.
- After: hold a 20-minute hot debrief, then write the after action report within [five working days].
7. Evaluation
| Measure | Evidence | Rating |
|---|---|---|
| Detection existed and reached a named person | Alert name and route | [Met / partly / not met] |
| Decision owner identified within the inject window | Scribe log | [ ] |
| Containment removed sessions, tokens, MFA methods and credentials | Steps described | [ ] |
| NHI owners found and able to act | Inventory entry | [ ] |
| Notification decision made with a stated basis | Legal note | [ ] |
Implementation guidance
- Start with 5.1 and 5.3. They test the help desk and NHI ownership, two areas that need different people in the room and are rarely exercised together.
- Validate injects against your logs before the session. Activity names here are from Microsoft Entra ID audit logs ("User registered security info", "Add service principal credentials", "Set federation settings on domain"); use your IdP's equivalents.
- Run quarterly, rotating scenarios (our recommendation), so each is exercised at least once a year.
- Feed results into detection work. Each "no alert" finding becomes a detection use case; see the Identity Detection Use Case Catalogue Template.
- Use free public material to extend the pack: CISA's Tabletop Exercise Packages provide objectives, scenarios, discussion questions and an after action report template, and the NCSC's Exercise in a Box offers free tabletop and micro exercises.
| Exercise activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Running the exercise | ID.IM-02 | IR-3 |
| Identity detection tested | DE.CM-03 | SI-4 |
| Response decisions tested | RS.MA-01 | IR-4 |
References: CISA: AA23-320A Scattered Spider · CISA: Tabletop Exercise Packages · NCSC: Exercise in a Box · Microsoft Learn: Microsoft Entra audit log activity reference · NIST: SP 800-61 Rev. 3 · MITRE ATT&CK: T1484.002 Trust Modification
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Scattered Spider Threat Actor Profile · Identity Incident Response Playbook · Cyber Incident Exercises Beyond Tabletop Guide · ITDR Guide