Phishing-proof MFA stops M365 spray and push fatigue

CISA’s AA24-290A campaign paired Microsoft 365 password spraying with MFA push bombing, then attacker device registration for persistence. Phishing-proof MFA 2.0 closes those login and enrollment surfaces. Ticket abuse after a foothold is a different problem.

According to the joint CISA advisory AA24-290A published 16 October 2024, Iranian cyber actors have since October 2023 used password spraying and MFA push bombing against Microsoft 365, Azure, and Citrix workforce accounts, then frequently registered their own MFA devices. Phishing-proof device-bound MFA 2.0 removes the password-only spray path and the approve/deny push path at interactive sign-in, and locked-down enrollment blocks silent attacker factor adds. Kerberos tickets and directory dumps after a foothold are residual post-auth work no login MFA undoes.

For the full attack-chain narrative, read the companion on legacymfa.sucks.

FAQ

Would phishing-proof MFA stop AA24-290A password spraying on Microsoft 365?

Yes. Password spraying in AA24-290A succeeded when workforce Microsoft 365, Azure, or Citrix logins still accepted a guessed or reused password without a device-bound gate. Phishing-proof MFA 2.0 replaces that password surface with origin-bound signatures held on enrolled hardware. There is nothing useful to spray for interactive sign-in once only those keys complete authentication. Closing that phishable login stops this path.

Can MFA 2.0 stop MFA push bombing and fatigue?

Yes. According to CISA, MFA fatigue or push bombing is bombarding users with mobile push notifications until someone approves by accident or to stop the noise. That works because approve/deny push is a transferable factor. MFA 2.0 has no prompt to spam. Authentication demands a fresh signature from an already-enrolled device, not a rubber-stamp notification. That is prevention, not detection.

How does phishing-proof enrollment stop attacker MFA device registration after foothold?

In AA24-290A, actors frequently modified MFA registrations so later access used attacker-controlled factors. CISA confirmed open MFA registration windows in two cases, and in another SSPR via public-facing ADFS plus Okta MFA registration for accounts that lacked MFA. Passkeys harden login only. If enrollment or recovery still accepts a phishable path, a temporary foothold can still bind a new factor. Phishing-proof enrolment requires an already-enrolled device or admin-governed binding at every lifecycle stage, which removes that factor-add surface.

What does MFA 2.0 not stop once AA24-290A actors already have a session?

MFA 2.0 does not undo Kerberos SPN enumeration and tickets, Microsoft Graph or PowerShell directory dumps, or Cmdkey credential listing after authentication has already succeeded. Those steps sit past login. Public reporting does not establish device-code phishing or AiTM cookie capture as the initial path here. Closing spray, push fatigue, and weak enrollment shrinks how often attackers reach post-auth discovery. Revoke, short-lived sessions, and endpoint controls remain hygiene for access already minted.

Are passkeys alone enough against this campaign class?

Passkeys are phishing-resistant at the login ceremony. AA24-290A also abused open MFA registration and SSPR recovery after foothold. If your deployment still uses phishable enrollment, an attacker who wins one password-plus-push window can still register their own device. MFA 2.0 is phishing-proof across registration, device onboarding, authentication, and decommissioning. That full-lifecycle coverage is what removes both the fatigue login and the post-foothold factor-add path in this advisory class.