How attackers are validating stolen Entra credentials without ever appearing in your sign-in logs
Proofpoint published primary research on July 13 documenting a credential validation technique that produces no successful sign-in log entry in Microsoft Entra ID, regardless of whether the tested credentials are valid. Two active campaigns have been running this technique since at least December 2025. One of them has already tested over one million accounts across nearly 4,000 tenants.
This is not a vulnerability in the traditional sense. It is a consequence of how Microsoft's OAuth2 token endpoint handles authentication requests under the Resource Owner Password Credentials (ROPC) flow, combined with how Entra ID logs events. The result is a detection gap that existing SIEM rules largely cannot close.
How it works
ROPC is a legacy authentication flow that allows direct submission of a username and password to Microsoft's token endpoint, bypassing the browser-based redirect flow that modern auth uses. Microsoft deprecated ROPC and recommends disabling it, but it remains enabled by default in most tenants.
When an attacker sends a POST request to the ROPC token endpoint with a spoofed (nonexistent) OAuth client ID, Microsoft Entra returns one of several error codes depending on what it knows about the submitted credentials. A nonexistent username returns a specific error before any logging occurs. A valid username with a wrong password returns a different error. A valid username with the correct password returns error AADSTS700016 (application identifier not recognized), because the client ID is fake.
That last response confirms a working credential pair. It generates no successful sign-in log entry because no sign-in succeeded. The client ID field in the log shows blank, since the attacker used a nonexistent application. Detection logic tuned to watch named applications, or to alert on successful sign-ins, sees nothing.
The two active campaigns
Proofpoint documented two distinct campaigns using this technique. UNK_pyreq2323 has been active since January 14, 2026. It systematically constructed spoofed client IDs by taking the Exchange Online application prefix and randomizing the final six digits, generating over 700,000 distinct fake identifiers. The campaign reached more than one million user accounts across nearly 4,000 tenant organizations and locked out approximately 28% of the accounts it touched. The lockouts are a side effect of the enumeration: too many wrong-password attempts triggering account lockout policies.
UNK_OutFlareAZ has been active since December 2025 and uses Cloudflare infrastructure to distribute its requests. It reached over 2 million users with 3.7 million randomized spoofed application IDs. Both campaigns appear to be systematically building validated credential inventories, likely for use in targeted intrusion operations or credential resale.
What defenders can do
The detection surface is narrow but not zero. The key signal is high volume of AADSTS700016 errors in Azure AD sign-in logs, specifically where the application name field is blank or missing. This pattern does not appear in normal authentication traffic; standard ROPC authentication from legitimate apps uses real registered client IDs.
The more direct mitigation is to disable ROPC flows in Conditional Access for all tenants where it is not specifically required by a legacy workload. Microsoft's guidance has been pointing in this direction for years; the Proofpoint research makes the cost of not acting concrete. If you have already disabled ROPC, you are protected from this specific technique.
For tenants that must keep ROPC enabled, add alert logic for blank-application-name authentication attempts with high AADSTS700016 rates. Standard sign-in failure monitoring will not catch this; the specific error code and blank application name combination is what to hunt.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if your team is dealing with Microsoft 365 credential hygiene or Entra ID detection engineering.