Four Million Fake App IDs, One Blind Spot: How Hackers Are Slipping Past Microsoft Login Defences
Two criminal campaigns sent over four million spoofed application identities at Microsoft's sign-in system and barely triggered an alert. Here is what happened, who is at risk, and what security teams can do.
Key points
- Two hacking campaigns, tracked as UNK_pyreq2323 and UNK_OutFlareAZ, used more than four million fake application identifiers to attack Microsoft Entra ID (Microsoft's cloud login system) between December 2025 and March 2026.
- UNK_pyreq2323 targeted over one million user accounts across roughly 4,000 organisations; about 28 percent of those accounts hit lockout.
- UNK_OutFlareAZ generated 3.7 million spoofed identifiers against more than two million accounts, peaking at around 720,000 targeted users on 15 March 2026.
- Both campaigns exploited a legitimate but outdated login method called ROPC, hiding inside error-log noise that most security teams were not watching.
- A specific error code, AADSTS700016, is the clearest early warning sign that an attacker has already confirmed a valid username and password.
What actually happened here?
Two separate groups of hackers found a way to test stolen passwords against Microsoft's sign-in system while making the activity look like ordinary technical clutter.
Every large organisation running cloud-connected Microsoft services generates a constant stream of failed login attempts. Expired scripts, old app connections, developers using the wrong settings: all of it produces a background hum of errors that security teams learn to ignore. These two campaigns were engineered to sound exactly like that hum.
The attackers used an older login method called ROPC, which stands for Resource Owner Password Credentials. Think of it as a way to check a username and password in a single automated message, without opening a browser. Developers leaned on it heavily before Microsoft recommended moving away from it, and it still runs quietly inside countless business systems today. We first reported on ROPC being abused in a story filed 3 July 2026.
Inside each ROPC request sits a field called a client ID, which is supposed to identify which approved application is asking to log in. The hackers simply made that field up. UNK_pyreq2323 mutated the last digits of a real Exchange Online application ID across more than 700,000 variations. UNK_OutFlareAZ went further, generating a completely fresh random identifier for every single request and producing 3.7 million unique fake IDs in total.
Because no single fake ID appeared more than a handful of times, the volume-based alerts that most security tools rely on never triggered.
Why does one specific error code matter so much?
Microsoft's login system returns different error codes depending on exactly what went wrong, and one of them is a near-certain sign of danger.
AADSTS50034 signals that the username doesn't exist. AADSTS50126 fires when the username exists but the password was wrong. AADSTS700016 appears when the username and password were both correct, but the application ID wasn't recognised. That last one is the warning: on its own it looks like an admin forgot to clean up an old app registration, but when it appears alongside a rapidly rotating list of fake IDs, it means an attacker has just confirmed a working credential pair.
| Error code | What it signals | Risk level |
|---|---|---|
| AADSTS50034 | Username does not exist | Low |
| AADSTS50126 | Username exists, wrong password | Medium |
| AADSTS700016 | Valid credentials, fake app ID | High |
| AADSTS700016 + many rotating IDs | Active credential-validation attack | Critical |
Security researchers at Proofpoint, who published the original findings (also covered by CSO Online), note they can't yet confirm whether the two campaigns are run by the same people or two independent groups who arrived at the same trick separately. For defenders, that distinction changes nothing.
Should ordinary employees be worried?
Yes, and the action items are straightforward. A 28 percent account-lockout rate across more than a million targeted users is a real helpdesk and productivity problem, not a theoretical one.
Every account that returned AADSTS700016 before it locked out is an account whose password the attackers have already confirmed. That password can be tried against personal email or banking apps, and confirmed credentials also open paths to email inboxes and connected cloud services. As we reported on 28 July 2026, a password reset alone won't eject an attacker who has moved on to stealing session tokens rather than reusing the password directly.
If you work at an organisation using cloud-connected Microsoft services, watch for unexpected lockout notifications or login alerts from a service you didn't just use. Report those immediately rather than assuming they're a system glitch.
For security teams, the detection logic involves watching sign-in logs for a single source IP cycling through many unregistered application IDs within a short window, combined with AADSTS700016 in that same window. A workable query in Microsoft's log-analysis language looks at distinct client ID counts per source address per 15-minute period, flagging anything above five with a 700016 code present.
When that pattern fires, force a password reset on the affected account, revoke all active sessions and authentication tokens, then review sign-in and mailbox activity for the days that follow. That review window matters: a confirmed credential often gets used quietly for days before it surfaces as a forwarding rule or a fraudulent payment request.
Common questions
Could this happen to someone who does not use Microsoft products?
This specific technique targets Microsoft Entra ID, but the underlying approach of using a disposable application identifier to slip past volume-based detection could be adapted for any login system that supports similar automated flows. The broader lesson about watching for rotating identifiers rather than counting per-application failures applies widely.
What can organisations do right now without a full detection overhaul?
The fastest step is disabling ROPC authentication for any application that doesn't genuinely need it, cutting off the method the attackers depend on. Pair that with alerting on any AADSTS700016 event that arrives with an unrecognised client ID, even a single instance, so analysts can triage it rather than let it vanish into the noise.
