The Challenge
Microsoft Security Research has tracked a campaign since May where attackers compromised Microsoft 365 accounts by posing as IT helpdesk staff. These attacks succeeded because organizations used phishable MFA methods, authenticator apps, SMS codes, and software-based One-Time Password tokens, that could be intercepted or manipulated through social engineering.
The attackers didn't use a zero-day vulnerability. Instead, they called employees on their personal phones, claiming an urgent passkey or MFA update was needed, and guided them through authentication flows that handed over session tokens or authorized attacker-controlled clients. Once inside, attackers registered their own authentication methods, phone numbers, authenticator apps, OTP tokens, allowing persistent access even after password resets.
The method was simple: social engineering to capture credentials, adversary-in-the-middle (AiTM) phishing pages or Microsoft device-code authentication flows to bypass MFA, and Microsoft Graph enumeration to map the tenant. Attackers accessed SharePoint, OneDrive, and Exchange Online at a controlled pace, fewer than 1,000 files or emails per hour, to avoid triggering alerts.
The Environment and Constraints
The affected organizations had:
- Enforced MFA, but with phishable methods (authenticator apps, SMS, software OTP)
- Enabled device-code and authentication-transfer flows without clear business needs
- Conditional Access policies that didn't require phishing-resistant authentication
- Allowed personal devices to access corporate resources without Microsoft Defender for Endpoint coverage
- No alerts for authentication method registration tied to sign-in anomalies
This setup is common. Many organizations implemented MFA years ago and haven't updated their authentication methods. While any MFA is better than none against automated attacks, it doesn't protect against targeted social engineering.
The attackers exploited a gap between policy intent and technical enforcement. Teams believed they had MFA protection, but the implementation allowed an attacker with a phone number and a convincing script to register their own authentication method quickly.
The Approach Taken
Microsoft's guidance focuses on two technical controls and one detection pattern.
Enforce phishing-resistant MFA via Conditional Access. Require FIDO2 security keys or certificate-based authentication for sensitive applications and privileged accounts. Phishing-resistant authentication ties the cryptographic challenge to the origin domain, preventing an attacker on a lookalike domain from completing the handshake.
Target high-value resources first: Exchange Online, SharePoint sites with regulated data, and any application with customer information. Roll out by user group, starting with administrators and finance teams.
Block device-code and authentication-transfer flows where unnecessary. Device-code authentication is legitimate for scenarios like smart TVs or embedded devices. If your organization doesn't use these, disable the flow. Attackers used it because it's a legitimate Microsoft feature that bypasses some phishing detection.
Correlate new authentication method registrations with unusual sign-in patterns. Look for sequences where a user signs in from an unexpected location or device, registers a new authentication method, then makes Microsoft Graph API calls to enumerate users, groups, and roles. Each event is normal alone; the sequence indicates compromise.
This requires SIEM integration with Azure Active Directory sign-in logs and audit logs. Look for temporal proximity: registration within 15 minutes of a suspicious sign-in, followed by Graph activity within the next hour.
Results and Metrics
Microsoft didn't publish remediation timelines or account recovery metrics, but the detection guidance implies the attacks succeeded due to a lack of visibility into the authentication method registration sequence. Attackers maintained access by registering their own methods, meaning password resets alone didn't revoke access.
The campaign showed that phishable MFA gives a false sense of security against social engineering. Jon Baker, VP of Threat-Informed Defense at AttackIQ, noted, "The passkey in this campaign is the lure, not the weakness. The MFA that got bypassed was phishable. Real passkeys would have stopped it."
The attackers' use of the "python-httpx" user agent in SharePoint and OneDrive activity suggests automation, but the controlled pace, staying under 1,000 files per hour, shows they understood enterprise baselines. Volume-based anomaly detection wouldn't flag this activity without additional context.
What They Would Do Differently
Organizations that experienced these intrusions would likely prioritize three changes:
Require phishing-resistant MFA for all privileged accounts immediately. Don't wait for a full rollout. Administrators, finance, HR, and anyone with access to customer data should use FIDO2 security keys starting today. The cost of a security key is $20-50; the cost of a compromised admin account is much higher.
Disable authentication flows you don't use. If you're not supporting embedded devices or legacy applications that require device-code authentication, turn it off. The principle is reducing attack surface, every enabled flow is a potential social engineering vector.
Build detection rules that correlate identity events. A new authentication method registration isn't suspicious. A sign-in from a new country isn't suspicious. Graph enumeration isn't suspicious. But all three within 30 minutes should trigger an alert and a temporary account freeze pending verification.
Takeaways for Your Team
Phishable MFA is not sufficient against targeted social engineering. If your MFA implementation relies on authenticator apps, SMS codes, or software OTP tokens, an attacker with a phone and a script can bypass it. FIDO2 security keys prevent this because the cryptographic challenge is bound to the domain, there's no way for a user to "help" an attacker on a phishing page.
Authentication method registration is a privileged operation. Treat it like a password reset: it should require strong verification, trigger alerts, and be logged for correlation. If a user registers a new method, your SIEM should check whether the preceding sign-in came from an expected location and device.
Social engineering scales when it mimics legitimate IT processes. The attackers in this campaign impersonated helpdesk staff and used passkey enrollment as the lure because it sounds like a plausible IT request. User education helps, but technical controls are more reliable. If your Conditional Access policies require phishing-resistant authentication, the phishing page can't complete the flow even if the user is fooled.
Detection requires sequence analysis, not threshold analysis. The attackers stayed under volume thresholds intentionally. What gave them away was the sequence: suspicious sign-in → new authentication method → Graph enumeration → file access. Build detection rules that look for temporal patterns, not just individual anomalies.
If you're running phishable MFA today, you're one convincing phone call away from a compromised tenant. The fix is technical, Conditional Access policies enforcing FIDO2, and the timeline is now.
