Attackers Are Quietly Testing Stolen Passwords Against Your Microsoft Tenant
If your organization runs on Microsoft 365, here's an uncomfortable thought: attackers may be checking stolen passwords against your tenant right now, at scale, without a single successful login showing up in your logs.
That's the takeaway from new research by Proofpoint, reported this week by The Hacker News. Researchers documented a technique they call OAuth client ID spoofing, and two large campaigns that have been using it since late 2025. It's worth understanding even if you never touch an authentication log yourself, because it changes what "we'd see it in the logs" actually means.
What the attackers are doing
Every application that signs in to Microsoft Entra ID (formerly Azure AD) identifies itself with a client ID — a long string that tells Microsoft which app is asking. Normally, that ID corresponds to a real, registered application.
In this technique, attackers send login requests to Microsoft's OAuth 2.0 token endpoint using the Resource Owner Password Credentials (ROPC) flow — an older, legacy way of authenticating that takes a username and password directly. But instead of a real application's client ID, they supply one that is syntactically valid yet doesn't correspond to any actual app.
Entra ID still processes the request, and the error message it returns differs depending on whether the username exists and whether the password is correct. That difference is the whole game. By reading the errors, attackers can confirm which stolen credentials are valid — effectively laundering a breached password list into a verified one — without ever completing a login.
Why your logs may not help
Here's the part that should get a security leader's attention. According to Proofpoint's research, when a spoofed client ID is used, no corresponding application name is recorded in the Entra sign-in log. The application ID field is filled with a meaningless string, and the friendly name that analysts actually scan for is blank.
Many detection rules and conditional access policies are scoped to known applications. A request from an application that doesn't exist can slip between those rules. And because the attacker never completes a successful sign-in, there's no "successful login from unusual location" alert to trip. The activity looks like noise — failed logins with odd, unnamed apps.
This is not a niche problem
The scale reported is striking. One campaign Proofpoint tracked, dubbed UNK_pyreq2323, ran from January to March 2026 and used more than 700,000 spoofed client IDs to target more than 1 million accounts across nearly 4,000 tenants — locking out roughly 28% of targeted users through failed attempts along the way. A second campaign, UNK_OutFlareAZ, has been running since December 2025 and targeted over 2 million users with 3.7 million randomized spoofed application IDs.
Four thousand tenants is not "a few big enterprises got hit." That's a spray across organizations of every size, and small and mid-sized tenants are squarely in the blast radius. If your users have ever reused a password that later showed up in a breach — and statistically, some have — your tenant is exactly the kind of place these campaigns go to find out whether that password still works.
What to do about it
The good news is that the practical defenses are things most organizations should be doing anyway. This research just raises the cost of putting them off.
Hunt for the telltale sign. Review your Entra sign-in logs for failed authentication events where the application name is blank or the application ID doesn't match anything you've registered. A burst of these is a strong signal someone is validating credentials against your tenant.
Don't scope your controls only to known apps. Proofpoint notes that conditional access policies scoped solely to commonly targeted applications can miss this activity entirely, because the "application" in the request doesn't exist. Broader policies — ones that apply to all cloud apps — close that gap.
Shut the door on legacy authentication. The ROPC flow is a legacy mechanism that passes usernames and passwords directly and can't satisfy multi-factor authentication. Microsoft has discouraged its use for years. If nothing in your environment legitimately needs it, block legacy authentication flows and this entire technique loses its target.
Assume some passwords are already known. Credential validation attacks only pay off when the underlying passwords are weak or reused. MFA everywhere, a password policy checked against known-breached passwords, and monitoring for unusual lockout spikes (remember that 28% lockout rate — your help desk may notice this attack before your SIEM does) all blunt the impact.
The bigger lesson: verify what your logs actually show you
The deeper issue this research exposes isn't a Microsoft quirk. It's the gap between what we assume our monitoring covers and what it actually covers. Plenty of organizations would have said, with confidence, "if someone was testing thousands of passwords against our tenant, we'd know." For months, across thousands of tenants, that assumption was wrong.
That's why we're firm believers that security controls need to be tested by people, not just configured and trusted. An experienced tester who attempts credential attacks against your environment — and then sits down with you to look at what your logs did and didn't capture — will find these blind spots before an attacker does. A scanner won't tell you your conditional access policy has a scoping gap. A human trying to sneak past it will.
If it's been a while since anyone tried to break into your Microsoft tenant on purpose, with your permission, that's worth fixing. Contact us today to discuss a penetration test that includes your cloud tenant.
Terry Bradley, CISSP, is the President and Founder of Mile High Cyber, with over 30 years of experience in cybersecurity. A CISSP since 2008, he specializes in penetration testing, vulnerability management, and virtual CISO services, helping small and mid-sized organizations identify, remediate, and verify their most critical security risks.