MFA Fatigue and the Token That Survived the Reset
Meridian Health Partners runs a hybrid identity estate: on-premises Active Directory synced to Entra ID, 2,400 staff, password-only VPN for contractors, and push-based MFA for everyone else. The service desk resets roughly 300 passwords a week and verifies callers by asking for their employee ID and manager name. On a Tuesday, a user approves an unexpected MFA push at 23:40 after receiving eleven in a row. By the time an analyst reviews the sign-in log nine days later, the attacker had registered a new Authenticator device, created an app password, added a hidden inbox rule forwarding finance mail to an external address, and granted consent to a third-party mail-reading application. Conditional Access is licensed but only one policy exists - a legacy 'block countries' rule left in report-only mode. Impossible-travel alerts fired 2,100 times last month and are auto-closed. The attacker still holds an active refresh token.
1. Set the containment order for the first two hours. Justify why each step precedes the next and say what you preserve before changing anything.
Read the worked answer
Order matters because the attacker's access does not live in the password.
- Preserve first, quickly: export Entra ID sign-in and audit logs, mailbox audit logs, and the Conditional Access report-only results to write-once storage before changing anything. Logs age out and the attacker can delete mailbox rules.
- Revoke refresh tokens and sessions for the account. Disabling the account alone leaves a live token that keeps minting access tokens, so revocation must precede the password reset.
- Remove the attacker-registered authentication method and delete the app password, then reset the password.
- Revoke the OAuth consent and the enterprise app grant, and delete the inbox rule - record its forwarding target first.
- Hunt: query the whole tenant for MFA method registrations, app password creation, consent grants, and inbox rules created in the last 30 days. This is how you find the other victims.
- Then notify: finance, the insurer, and legal for contractual or regulatory duties.
The trap is treating this as a compromised password. A reset that leaves the rogue authenticator, the app password, and the mail-reading consent in place gives the attacker a route back within minutes, which is exactly what happened here.
2. Rank four identity control changes by risk reduction per unit of user friction, and defend the ranking against the complaint that 'staff already have too many prompts'.
Read the worked answer
- Alerting on authentication-method registration and consent grants - zero user friction. It is the one control that would have caught this attack at step one, and it detects the technique instead of trying to prevent every possible initial access.
- Number matching, or better phishing-resistant FIDO2 for privileged and finance roles. Push fatigue dies against number matching, and enrolment is a one-time cost.
- Conditional Access enforcement: require a compliant or managed device, and block legacy authentication and app passwords. App passwords exist precisely because legacy protocols cannot do MFA - one of them survived the reset here.
- Risk-based step-up and impossible-travel tuning. Valuable in principle, but with 2,100 auto-closed alerts it is currently negative value until retuned and routed to a human.
The 'too many prompts' objection deserves a number, not an argument. Measure prompts per user per day, consolidate to one, and report approval rates and time-to-authenticate. Then contrast that with a nine-day dwell time and a live token in an attacker's hands. Start with admins and finance, where impact is highest and friction is felt least, and publish the enrolment timeline so the complaint has somewhere to land.
3. The app password and the OAuth consent both survived a password reset. What does that tell you about the incident assumptions, and what should the team check on every other account?
Read the worked answer
It tells me the mental model 'reset the password and you are clean' was wrong. Three separate persistence mechanisms outlived the credential change: a registered authentication method, a legacy-protocol credential, and a delegated OAuth grant whose access token is renewed by the application itself, independent of the user's password. Any one of them re-establishes access.
So scope checks must broaden for every account:
- Authentication methods registered in the last 30 to 90 days, especially from an unusual IP or ASN.
- App passwords and legacy-auth artifacts; the classic indicator is a successful IMAP, POP, or SMTP authentication against a mailbox.
- OAuth consent grants to unfamiliar or newly registered applications, and any app holding Mail.Read, Files.Read, or offline_access.
- Mailbox rules, forwarding addresses, and calendar delegation that hide or redirect mail.
- Sign-ins using the token itself: anomalous user agents and IPs after the reset.
- Whether the service desk verification weakness was used against other users; a spray pattern implies a target list.
It also changes severity. Nine days of mail forwarding is a data breach requiring notification analysis, not a contained account takeover, and the fix list now includes token protection and restricting user consent to applications.