TTX-11 · Scenario card
Identity Provider Compromise Tabletop: Losing Your SSO
An identity provider compromise tabletop: MFA fatigue and help-desk fraud hand an attacker SSO super-admin. 9 injects on federation, break-glass and cutting SSO.
An identity provider compromise tabletop rehearses the worst day for a single sign-on (SSO) estate: an attacker holds super-admin rights in the platform that every other application trusts. In this scenario, MFA fatigue and a convincing call to the help desk give the attacker an administrator account. They add a rogue federated identity provider for persistence and start signing into your software-as-a-service (SaaS) applications.
This is an advanced scenario for technical, cloud and executive participants. It tests MFA reset procedures at the help desk, detection of identity configuration changes, break-glass access, and the decision to cut SSO for the whole organisation. Run the phishing and credential theft scenario first if your team has not exercised account compromise before.
Scenario at a glance
| Threat | Takeover of the corporate identity provider through MFA fatigue and help-desk social engineering, with a rogue federated trust and SaaS access |
| Difficulty | Advanced |
| Duration | 3 hours including a 30-minute hotwash |
| Audience | Technical, cloud and executive |
| Recommended participants | CISO, IR lead, identity and access management lead, cloud platform lead, service desk manager, SOC lead, SaaS application owners, CIO, COO |
| Prerequisites | Identity architecture diagram, list of SSO-connected applications, break-glass account procedure, help-desk identity verification procedure |
| MITRE ATT&CK techniques | T1621 Multi-Factor Authentication Request Generation, T1484.002 Trust Modification, T1078.004 Cloud Accounts |
Exercise objectives
- Test the help-desk procedure for verifying identity before resetting MFA, especially for privileged users.
- Confirm that changes to identity provider configuration, such as new admins and federation trusts, generate alerts that someone acts on.
- Validate that break-glass accounts exist, work without the identity provider and are known to the right people.
- Identify who has authority to disable SSO or federation for the whole organisation, and on what criteria.
- Rehearse scoping across SaaS applications that trust the identity provider, including tokens that outlive a session revocation.
- Agree how the business keeps operating and communicating while normal sign-in is unavailable.
Starting situation
Read this aloud to players:
It is Sunday, 23:50. Your organisation uses a cloud identity provider for single sign-on to around 120 applications, including email, collaboration, the CRM, the HR system, source code hosting and the cloud console. Most users approve MFA with a push notification.
The identity team has four people. Two of them hold super-admin rights. One, a senior identity engineer, is on holiday abroad this week.
Injects timeline
| # | Time | Inject | Delivered to | What players should address |
|---|---|---|---|---|
| 1 | T+00:00 | The on-holiday identity engineer receives 30 MFA pushes in ten minutes, then a call from "IT support"; they approve one | Identity engineer (controller) → SOC | MFA fatigue, user reporting |
| 2 | T+00:25 | The service desk resets MFA for the same engineer after a caller answers verification questions | Service desk manager | Help-desk verification, privileged resets |
| 3 | T+01:10 | Identity logs show a new external identity provider federated for your primary domain | SOC lead → IAM lead | Trust modification, persistence |
| 4 | T+01:30 | Sign-ins to the cloud console, source code hosting and CRM by users who are asleep, via the new federation | SOC lead → IR lead | Scope, SaaS access, severity |
| 5 | T+02:00 | The attacker creates two new super-admin accounts and disables the admin-change alert | IAM lead | Containment race, admin control |
| 6 | T+02:30 | The IR lead asks for a decision: cut SSO for all apps now, locking out every user and some customer services | CIO / incident commander | SSO shutdown decision, business impact |
| 7 | T+03:00 | The documented break-glass account fails: its password vault entry is stale, and one account was deleted last year | Cloud platform lead | Break-glass readiness, recovery access |
| 8 | T+06:00 | Evidence of bulk CRM exports and a new OAuth application with mail access | IR lead / legal | Data exposure, notification, token revocation |
| 9 | T+08:00 | Monday morning: 4,000 staff cannot sign in; the COO asks when normal work resumes | COO / executive team | Business continuity, communications, recovery plan |
Module 1 — Initial access (T+00:00 to T+01:10)
Inject 1. The senior identity engineer, on holiday in another time zone, is woken by a stream of MFA push notifications, around 30 in ten minutes. Then a caller claiming to be from the IT service desk says there is a sync fault and asks them to approve the next prompt to stop the alerts. Tired and confused, they approve one. They mention it in a team chat the next morning; nobody reports it tonight.
Inject 2. Twenty-five minutes later, the service desk takes a call from someone claiming to be the same engineer: they have a new phone while travelling and need their MFA reset. The caller knows the engineer's employee number, manager's name and office location. The analyst resets MFA and lets the caller register a new device.
Inject 3. At 01:00, a SOC analyst notices an unusual event in the identity provider audit log: a new external identity provider has been added and federated for your primary email domain. The change was made by the senior identity engineer's account. No change ticket exists.
Discussion questions:
- Would anyone have detected 30 MFA pushes to one user? Is there an alert, and who receives it?
- What verification does the service desk require before resetting MFA for a privileged user? Can publicly available information pass it?
- Does the identity team get notified when a super-admin makes a configuration change out of hours?
- At what point is this declared a major incident, and who is woken up?
- Why is a new federated identity provider so dangerous? Does everyone in the room understand it?
Module 2 — Spread and the SSO decision (T+01:30 to T+03:00)
Inject 4. Sign-in logs show successful sessions into the cloud console, the source code hosting platform and the CRM, for users who are asleep. All of them authenticated through the newly added federation, which lets the attacker assert any identity in your domain without a password or MFA.
Inject 5. While the IAM lead is on the bridge, two new super-admin accounts appear, and the alert rule for admin role changes is switched off. The IAM lead removes one of the new accounts; the attacker recreates it within minutes. It is now a race for control of the tenant.
Inject 6. The IR lead asks the CIO for a decision: "We can disable the rogue federation and all SSO integrations now. Every user and every connected app loses sign-in until we rebuild, including the customer support portal. Or we keep fighting inside the console and hope we win. I need a go or no-go in 15 minutes."
Inject 7. The cloud platform lead tries the documented break-glass account for the cloud console, which does not depend on SSO. The password in the vault is out of date. The second break-glass account listed in the procedure was deleted during a clean-up last year. The identity provider vendor's support line has a 30-minute queue.
Discussion questions:
- Who has the authority to disable SSO for the whole organisation at 02:30 on a Monday? Is that written down?
- What is the business impact of cutting SSO for each critical application? Who knows which apps fail closed and which fail open?
- Do you remove the rogue federation first, or the compromised admin accounts, or disable the tenant? What is the right order?
- Is there an escalation route to the identity provider vendor for a security emergency?
- How does the incident team communicate if collaboration tools use the same SSO? See out-of-band communications.
Module 3 — Exposure and recovery (T+06:00 to T+08:00)
Inject 8. With the tenant back under control, the IR lead reviews activity. The attacker ran several bulk exports from the CRM covering customer contacts, and registered a new OAuth application with permission to read all mailboxes. Revoking user sessions does not revoke the application's access token.
Inject 9. It is 08:00 on Monday. Around 4,000 staff cannot sign in to email, chat or business applications. The service desk queue is overflowing. The COO asks the executive team when people can work again, what customers are being told, and whether the organisation is safe to bring back online.
Discussion questions:
- How do you find and revoke every token, OAuth grant and API key issued while the attacker had control?
- Does the CRM export trigger personal-data breach obligations? Who decides, and when did the clock start?
- What is the order of restoration: which applications come back first, and on what evidence that they are clean?
- How do you tell 4,000 staff what is happening when email and chat are unavailable?
- Which controls must change before SSO is restored: phishing-resistant MFA for admins, stricter help-desk verification, alerting on federation changes?
Discussion questions
Consolidated themes for the hotwash and for facilitators who need prompts:
- Authority: Was it clear who could cut SSO, and did they have enough information to decide?
- Detection: Which of the attacker's actions were detected, how quickly, and by whom?
- Help desk: Would your verification procedure stop a well-prepared caller asking for a privileged MFA reset?
- Break-glass: When were break-glass accounts last tested, and who holds the credentials?
- Blast radius: Is there a current list of applications that trust the identity provider, and their failure modes?
- Recovery: What evidence is needed before trust is re-established? See recovery time objective.
Curveballs / optional injects
Use one or two if the group is moving quickly:
- The attacker changes the recovery email and phone for the organisation's identity provider tenant, complicating vendor support.
- A customer-facing app uses the same SSO for customer logins, so cutting SSO takes the product offline.
- The IAM lead's own account is one of those showing suspicious activity, and the team must decide whether to trust them.
- Source code hosting shows a new deploy key added to a production repository, raising supply chain concerns.
Facilitator notes
Expected decisions. A well-prepared team treats a new federation trust as a critical incident immediately and wakes a named incident commander. It removes the rogue identity provider and compromised admin accounts in a planned order, rather than one at a time while the attacker watches. The decision to cut SSO is made by someone with authority, informed by a list of dependent applications. Break-glass access has been tested and works. Token and OAuth grant revocation is treated as a separate workstream from password and session resets.
Common pitfalls.
- The help desk verification relies on facts an attacker can find on professional networking sites.
- Nobody receives alerts for identity configuration changes, or they go to a mailbox nobody reads at night.
- The incident team tries to coordinate in chat, which runs on the compromised SSO.
- Break-glass accounts exist on paper only.
- Recovery focuses on the identity provider and forgets tokens and app registrations in downstream SaaS platforms.
On the SSO shutdown decision. There is no universally correct answer. The value of the inject is that the team discovers whether anyone knows the business consequences and holds the authority. Record who decided, when and why, and use it in the after-action report.
Adapting the audience. For an executive session, run Module 1 as a briefing and spend the time on injects 6 and 9. For a technical session, expand injects 3 to 5 into the exact console actions, roles and log sources in your identity platform, and add the curveball on customer-facing SSO. The cloud access key leak scenario is a useful follow-up for cloud teams.
Evaluating the exercise
| Capability | What good looks like | Red flags |
|---|---|---|
| Help-desk verification | Privileged MFA resets need strong verification and a second check | Reset granted on employee number and manager's name |
| Identity change detection | Federation and admin changes alert a named on-call person within minutes | Changes found by chance; alert disabled without anyone noticing |
| Containment of the tenant | Rogue trust and admins removed in a planned sequence | Piecemeal removal while the attacker recreates access |
| SSO shutdown authority | Named decision-maker with dependency list; decision and rationale recorded | Decision deferred; nobody knows which apps depend on SSO |
| Break-glass access | Tested accounts work without SSO; holders and vault known | Stale credentials; accounts deleted; vendor queue as the only route |
| Recovery and communication | Tokens and grants revoked; staff informed out of band; restoration order agreed | Staff learn from a login error; OAuth apps left in place |
Related
Frequently asked questions
What is an identity provider compromise tabletop exercise?
It is a facilitated discussion in which security, identity, cloud and executive staff rehearse their response to an attacker gaining administrative control of the organisation's single sign-on platform. Because every connected application trusts the identity provider, the exercise tests hard decisions such as disabling SSO, using break-glass accounts and rebuilding trust, in a setting where mistakes cost nothing.
What is an MFA fatigue attack?
An MFA fatigue attack, also called push bombing, is when an attacker who already has a user's password triggers repeated MFA push notifications until the user approves one out of confusion or frustration. It is often combined with a call or message pretending to be IT support. Number matching, phishing-resistant MFA and user reporting reduce the risk.
What are break-glass accounts?
Break-glass accounts are emergency administrator accounts kept outside normal sign-on flows, such as local cloud accounts that do not depend on the identity provider. They let you regain control when SSO is unavailable or compromised. They must be tightly protected, monitored for any use and tested regularly, which is exactly what this tabletop exercise checks.
Should we disable SSO during an identity provider compromise?
Sometimes. Disabling SSO or cutting federation stops the attacker using it, but it also locks out every employee and may break customer-facing services. The decision depends on how widely the attacker has spread, whether break-glass access works, and how quickly trust can be rebuilt. The exercise should make sure someone has the authority and the facts to decide.