MFA Push Bombing Leads to a Successful Lagos Sign-In
At 03:12, the SOC receives 47 Microsoft Entra ID MFA push notifications for 12 users in four minutes. Eleven users deny; one user in Chicago approves a push and then calls the helpdesk saying they did not initiate it. At 03:20, SIEM shows a successful sign-in for that user from Lagos, Nigeria, with a new user agent; EDR shows no malware on the user's laptop. The account has access to finance SharePoint and a payment approval app. The SOC's SLA is 15 minutes for high-severity identity alerts. The helpdesk has a script that resets passwords but does not revoke sessions. The user is on PTO and unreachable. The attacker has not yet triggered a payment alert.
1. How should the SOC triage this alert, and what evidence determines whether it is a true compromise?
Read the worked answer
Treat it as a likely true compromise, not a false positive. The combination of 47 pushes in four minutes, one approval by a user who denies initiating it, and a successful sign-in from Lagos within eight minutes is a classic MFA fatigue pattern. The Chicago user's approval may have been accidental or social-engineered; the Lagos sign-in indicates the attacker obtained a session.
Prioritize within the 15-minute SLA because the account can reach finance SharePoint and a payment approval app. Check Entra sign-in logs for authentication method, device ID, conditional access result, IP reputation, and whether the Lagos session used a token or a fresh MFA challenge. Review audit logs for new MFA methods, password changes, mailbox rules, OAuth consent grants, and SharePoint sharing changes. Check the payment app's audit trail for approval-rule changes or new payees.
EDR showing no malware on the laptop does not clear the account; token theft and push bombing are identity attacks. The absence of a payment alert means the attacker has not acted yet, not that the account is safe.
2. What containment actions are required, and why is a password reset from the helpdesk script insufficient?
Read the worked answer
A password reset alone is insufficient because it does not invalidate existing refresh tokens or active sessions. The attacker may continue using a stolen token after the reset. Required actions: revoke all sessions and refresh tokens, reset the password, and re-register MFA after removing any attacker-added methods. If the account is high-risk, disable it until the user is reachable and identity proofing is complete. Block the Lagos IP and user agent at conditional access or the identity provider, but do not rely on IP blocking alone.
Review and remove suspicious mailbox forwarding rules, OAuth application consents, and SharePoint external sharing. Check the payment approval app for delegated approvers, changed bank details, or pending fraudulent payments, and notify finance to apply dual approval. Preserve sign-in and audit logs before making changes.
Because eleven other users received pushes, check their sign-in logs too. The attacker may have tested many accounts and succeeded on one. Contain the confirmed account first, then hunt for the same source infrastructure across the tenant.
3. What communication and follow-up steps should the SOC take given the user is on PTO and finance is at risk?
Read the worked answer
Escalate to the incident commander and finance leadership immediately, because the account can approve payments. Ask finance to freeze any payment approvals from that user and to verify recent changes by phone. Notify the user through a second channel, not the compromised account, and ask for identity verification before restoring access. Do not send detailed incident information to the user's email if the mailbox may be compromised.
Engage HR or legal if the mailbox contains sensitive data, and preserve evidence for any potential fraud investigation. Document the timeline: push notifications, approval, helpdesk call, Lagos sign-in, and containment actions. Record which sessions were revoked and which MFA methods were removed.
After containment, review why conditional access allowed a Lagos sign-in and why the helpdesk script lacked session revocation. Add push-number matching or phishing-resistant authentication for finance roles, tune impossible-travel and MFA-fatigue detections, and test the revised helpdesk runbook. Follow up with the other eleven users to confirm none approved a push.