When MFA Works Perfectly and You Still Lose
In April 2026, one phishing platform was linked to hundreds of Microsoft 365 compromises a day, according to Microsoft's Vice President of Security Research, speaking to The Register. The pattern in these cases was consistent: an employee received a request that looked routine, followed the prompts on a genuine Microsoft page, and never typed a password anywhere an attacker could see it. Multi-factor authentication functioned exactly as designed. The attacker got in anyway.
That is the uncomfortable core of this story. Two separate threat operations, a phishing-as-a-service platform called Kali365 and a group Microsoft tracks as Storm-2949, both reached Microsoft 365 environments last spring without defeating MFA. They walked around it, using the same thing every security control ultimately depends on: a person willing to help.
The Valet Ticket Scam: How Kali365 Operates
The FBI's IC3 advisory, published in May 2026, describes Kali365 as a Telegram-based phishing kit first observed in April. Its method centers on the OAuth device authorization grant, a legitimate sign-in flow originally built for devices without a full keyboard or browser, like a smart TV.
Here is the human mechanism underneath the technical one. Device-code phishing works like a valet stand scam. The attacker hands you what looks like your own claim ticket and asks you to drop it at the front desk on their behalf. The front desk is real. The ticket is real. But the moment you hand it over, you have authorized someone else to walk off with the car, and your own keys never leave your pocket.
In practice, the attacker starts a login on their own device, which generates a short code. Kali365 then sends a branded email impersonating a trusted service like Adobe, DocuSign, or SharePoint, carrying that code and a link to Microsoft's genuine verification page. The victim, doing exactly what a security-aware employee is trained to do, visits the real page and enters the code, unknowingly authorizing the attacker's device instead of their own.
Microsoft then issues OAuth access and refresh tokens, in effect a valet ticket for the account, with the refresh token quietly reprinting a fresh pass every hour until someone cancels it at the source. Arctic Wolf's incident responders found attackers using that access to plant malicious inbox rules, suppressing security alerts so the intrusion could continue undetected.
Nothing about this required guessing a password or cracking encryption. It required one person, in a moment of routine helpfulness, entering a code on a page they had every reason to trust.
The Kiosk Anyone Can Talk Their Way Into: Storm-2949
Storm-2949 took a different door into the same building. Microsoft's Defender Security Research Team documented, in a May 2026 case study, how this actor turned a single compromised identity into a cloud-wide breach by abusing Self-Service Password Reset, the feature designed to let locked-out employees recover their own accounts without waiting on IT.
Picture a key-card reset kiosk in an office lobby. The attacker calls ahead posing as facilities staff, tells the employee their access needs urgent verification, and asks them to approve a prompt. The kiosk does precisely what it was built to do. It issues a new card, no questions asked, because the request looked legitimate.
Microsoft assessed that Storm-2949 impersonated internal IT support, telling targets their accounts required urgent verification and walking them through approving MFA prompts as part of what seemed like a routine reset. Once a user approved, the attacker reset the password, stripped the existing authentication methods, and enrolled Microsoft Authenticator on their own device, locking the real employee out completely.
The group repeated this social engineering script across three more accounts, then used a custom script against the Graph API to enumerate the organization's directory, and reached the company's Key Vault, the digital cabinet holding the credentials to everything else. They opened it in four minutes.
What Both Cases Have in Common
Strip away the branding and the tooling, and Kali365 and Storm-2949 are running the same play from opposite ends. One impersonates a document notification. The other impersonates the help desk. Both rely on a legitimate Microsoft process functioning correctly, a login page, a password reset flow, an MFA prompt, and both rely on an employee treating an unusual request as a normal one.
This is the part a purely technical view of security tends to miss. MFA was designed to stop credential theft. It was never designed to detect a human being talked into authorizing someone else's device, or into approving a reset they did not initiate. The control worked. The decision around it did not.
The Takeaway
MFA remains a meaningful defense against basic credential stuffing and reused passwords, and organizations should keep it in place. But these two cases from spring 2026 show that MFA is a control on a moment, not a guarantee about the person triggering that moment. Kali365 succeeds by getting someone to authorize a device that isn't theirs. Storm-2949 succeeds by getting someone to approve a reset they didn't ask for. Neither required breaking anything. Both required a plausible story and a willing employee.
The practical defense is the same in both cases: treat any unsolicited code, link, or "urgent verification" request as suspicious by default, verify IT support requests through a separate known channel, and understand that a genuine-looking Microsoft page proves the page is real, not that the request behind it is.
If this kind of breakdown, where the technology holds and the human layer doesn't, is useful to you, subscribe free at threatlevelhuman.substack.com. Subscribers also get the free Social Engineering Red Flags field guide, a quick-reference resource for spotting exactly these kinds of manipulation attempts before you click, approve, or confirm.
<- back to the blog