MFA Fatigue Followed by a Helpdesk Reset

Order matters because some steps are ineffective until others are done, and some destroy evidence.

1. Capture first: the forwarding rule, any OAuth consent grants, the registered MFA methods and their timestamps, sign-in logs, and the helpdesk ticket and call recording. Screenshot or export before changing anything.
2. Revoke refresh tokens and sessions for the account. A password reset alone leaves the attacker's existing tokens valid, which is the single most common containment failure in this scenario.
3. Remove the attacker-registered authenticator, reset the password, then force re-registration through an in-person or verified-video identity check - not a phone call using the same attributes that were just abused.
4. Delete the forwarding rule and any inbox rules, and check for delegate access, mailbox permissions, and mailbox search or export activity.
5. Review and revoke OAuth application consents granted in the window; consent grants survive password resets.
6. Hunt the pattern: helpdesk-initiated resets in the last 90 days correlated with new MFA registrations and external forwarding.

Disabling the account is acceptable if containment confidence is low, but reset plus revoke plus method removal is usually sufficient and avoids taking a clinician offline.

The root cause is identity proofing at the helpdesk; MFA worked exactly as designed once the attacker had a method enrolled. Fix in this order:

1. Reset procedure. Require callback to the number on file or manager confirmation for clinical and privileged accounts, and explicitly ban breach-exposed attributes (date of birth, employee ID, partial account numbers) as sole proof. Add approval and audit on every MFA reset.
2. Number matching with additional context in Authenticator. This defeats push fatigue at effectively zero cost and should be enabled tenant-wide before anything else in the MFA layer.
3. Conditional Access for all users requiring a compliant or hybrid-joined device for mailbox access - extending the existing finance-only policy - and block legacy authentication tenant-wide.
4. Token protection and session controls for high-risk roles.
5. Alerting on MFA method registration and on helpdesk-initiated resets.

The sequencing trap is item 3: the two legacy applications will resist, and teams often leave basic auth open tenant-wide to accommodate them. Scope the CA policy and allowlist those apps by name with a dated migration, rather than letting two applications hold 4,000 accounts open to MFA bypass.

Hunt over 90 days on correlation, not single events. Query for MFA method registrations that occur within two hours of a password reset performed by a helpdesk operator; that pairing is the attacker's fingerprint and is rare in normal operations. Layer in: new inbox rules with external forwarding, sign-ins from an unfamiliar ASN or country immediately after a reset, mailbox audit events for delegate additions, and OAuth consents granted by users shortly after a reset.

Also baseline push volume per user per hour. Sixty-three pushes in nineteen minutes should have paged someone at push ten; that is a straightforward threshold detection and it was absent.

For durable detection, alert on 'MFA method added within 60 minutes of a helpdesk reset' at high severity, and route it to the identity team rather than the general queue. Review helpdesk reset volume per operator per week - an outlier on that metric is often the first sign of social engineering, and it catches the next attempt before it succeeds.