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 about it.
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 login system while making the activity look like ordinary technical clutter.
Every large organisation that uses Microsoft 365 or Azure 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 ever opening a browser window. Developers used it heavily before Microsoft recommended moving away from it, and it still runs quietly inside countless business systems today.
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 Microsoft Exchange application ID across more than 700,000 variations. UNK_OutFlareAZ went further and generated a completely fresh random identifier for every single request, 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 means the username does not exist. AADSTS50126 means the username exists but the password was wrong. AADSTS700016 means the username and password were both correct, but the application ID was not recognised. That last one is the warning sign: 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 set of credentials.
| 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 cannot 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, but the action items are simple. A 28 percent account-lockout rate across more than a million targeted users is a real helpdesk and productivity problem, not a theoretical one.
More importantly, every account that returned AADSTS700016 before it locked out is an account whose password the attackers have already confirmed. That password can be tried on personal email, banking apps, or anywhere else the person reuses it. Confirmed credentials can also give attackers access to email inboxes, connected software-as-a-service tools, and internal systems.
If you work at an organisation using Microsoft 365, watch for unexpected lockout notifications, unfamiliar password-reset emails you did not request, or any login alert from a service you did not just use. Report those immediately rather than assuming they are a system glitch.
For security teams, the detection logic involves watching sign-in logs for a single source IP cycling through many different unregistered application IDs within a short window, combined with the presence of 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, the response is straightforward: 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 following the AADSTS700016 hit. That review window matters because a confirmed credential often gets used quietly for days before it shows up in an obvious way like 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 idea, using a disposable or fake application identifier to slip past volume-based detection, could be adapted for any login system that supports similar automated flows. The ROPC method is a Microsoft-specific implementation, but 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 practical step is to disable ROPC authentication for any application that does not genuinely need it, cutting off the method the attackers depend on. Pair that with alerting on any AADSTS700016 event that comes with an unrecognised client ID, even a single instance, so analysts can triage it rather than let it disappear into the noise.
