According to Barracuda on 15 October 2025, Whisper2FA is a phishing-as-a-service kit that live-relays Microsoft 365 passwords plus MFA OTP, SMS, voice, or push responses until the attacker’s real login succeeds. Phishing-proof device-bound MFA stops that credential-phase path: there is no code to type and no prompt to approve on a spoofed origin, so the AJAX relay cannot finish authentication or mint a usable session. Session cookies after a completed login are residual; closing the phishable login stops this path, and malware after a legitimate login is a harder, separate problem. The full attack-chain write-up is on legacymfa.sucks. The same prevention logic applied to the UK industrial AiTM campaign.
FAQ
Would phishing-proof MFA stop Whisper2FA on Microsoft 365?
Yes. Phishing-proof MFA 2.0 would stop Whisper2FA from completing Microsoft 365 workforce login via live OTP or push relay. Barracuda describes Whisper2FA as a live relay that keeps validating MFA responses against the real sign-in until the attacker’s login succeeds. Device-bound, origin-bound signatures never leave the enrolled hardware and never bind to the attacker’s page, so the kit has nothing transferable to exfiltrate or replay. That is prevention, not detection: the ceremony fails before a session exists.
Are passkeys enough against Whisper2FA, or do you need MFA 2.0?
Passkeys (phishing-resistant FIDO2/WebAuthn) harden the Whisper2FA login act when the user already holds an enrolled authenticator, because the kit cannot harvest an origin-bound assertion the way it harvests OTP or push. MFA 2.0 is phishing-proof across the identity lifecycle, with no phishable factor at registration, device onboarding, authentication, or decommissioning. For this Barracuda-documented kit the decisive failure was phishable MFA at authentication. Public reporting does not show an enrollment-stage compromise in the Whisper2FA chain, so clean passkey login already breaks the relay; full-lifecycle phishing-proof coverage closes the weaker onboarding paths other kits still abuse.
Do session cookies after Whisper2FA mean login MFA failed later?
No. Session cookies after Whisper2FA do not mean login MFA failed in a second phase. Barracuda’s chain places cookie and post-auth session material only after the live MFA relay successfully completes Microsoft 365 authentication. No login MFA undoes a token already issued. Defenders still revoke access and refresh tokens after a bad session. Lifetime tweaks are not a substitute for prevention. Fooling a user into a proxied login is easy. Planting malware on an already-logged-in PC is not.
Does classic SSO make residual Whisper2FA impact worse?
Yes. Classic SSO makes residual Whisper2FA impact worse because one stolen Microsoft 365 cloud session becomes a skeleton key across mail, files, chat, and other federated apps without a fresh proof at each boundary. That design conflicts with zero-trust’s never-trust, always-verify rule. Secure Explicit Sign-On keeps one-tap UX while each app gets its own fresh device-bound signature, so there is no single replayable federation cookie to fan out after a bad login. Harden the login first with the device-bound architecture; shrink blast radius second.
Would shorter Microsoft 365 token lifetimes stop Whisper2FA?
No. Shorter Microsoft 365 token lifetimes would not stop Whisper2FA. Lifetime limits only force the attacker to re-use or re-steal sooner after a session already exists. Whisper2FA’s win is finishing the phishable login and receiving a legitimate session. If the attacker also registers their own authenticator during that window, lifetime caps stop mattering. Closing transferable OTP, SMS, voice, and push at every login is the prevention path; revoke and Conditional Access remain hygiene around residual sessions.
