OAuth Client ID Spoofing, the New Cloud Threat Discovered by Proofpoint

Authentication errors can reveal whether an account exists and if the entered password is correct. This principle is exploited by a technique observed by Proofpoint in various campaigns against Microsoft 365 environments.

The technique, referred to as OAuth client ID spoofing, involves inserting fake application identifiers in the requests sent to Microsoft Entra ID. The goal is not to impersonate a specific application or directly obtain an OAuth token, but to analyze the service's responses to verify accounts and credentials.

How client ID spoofing works

Every application registered in Microsoft Entra ID is associated with a client ID, a unique identifier in GUID format. This value is included in OAuth requests and recorded in access logs along with the application's name.

In the campaigns analyzed by Proofpoint, attackers sent requests to Microsoft’s OAuth 2.0 endpoint through the Resource Owner Password Credentials flow, which allows direct transmission of username and password. Instead of using a real application identifier, however, a fabricated or modified client ID is used.

Entra ID continues to process the request and returns different error codes based on the entered data. The error AADSTS50034 indicates that the username does not exist, while AADSTS50126 is returned when the account is valid but the password is incorrect.

The code AADSTS50034, typically associated with an unrecognized application, can instead indicate that the username and password are correct, but the client ID does not match a registered application. Thus, the attacker may discover that they have found valid credentials, even though authentication is not completed.

Why it is hard to detect

Traditional password spraying and account enumeration attacks often target well-known and widespread Microsoft applications. A high number of requests against the same application can be identified through rules based on the volume of attempts or the service name.

With client ID spoofing, however, requests are distributed among hundreds of thousands or millions of nonexistent applications. In the logs, only the application ID may appear, without the corresponding name. When the identifier used is not even a valid GUID, both fields may be empty.

Even attempts against nonexistent usernames can remain outside access logs, as Entra ID only logs events associated with valid accounts. The activity thus appears fragmented across numerous identifiers, without successful accesses and with few easily correlatable elements.

The technique can also reduce the effectiveness of Conditional Access policies applied only to specific applications. A fabricated client ID does not correspond to the protected service and may not trigger the checks intended for that particular application.

Millions of fake OAuth identifiers

Proofpoint analyzed two large-scale campaigns, seemingly conducted by different actors or tools. The first, named UNK_pyreq2323, was observed between January and March 2026 and used over 700,000 fake client IDs. The campaign affected more than a million accounts spread across nearly 4,000 tenants, using AWS infrastructure and the client python-requests/2.32.3.

In this case, attackers started from the identifier of Exchange Online and modified the last digits. Each client ID was used against a limited number of users, reducing the likelihood of detecting an abnormal volume associated with a single application. According to Proofpoint, about 28% of targeted accounts were blocked due to numerous attempts.

The second campaign, monitored as UNK_OutFlareAZ, was observed starting in December 2025 and reached an even greater scale: over two million users and 3.7 million fake client IDs. Each attempt used a completely random and different UUID. Much of the traffic came from Cloudflare's infrastructure, while the user agent simulated a version of Microsoft Outlook. Differences in the generation of identifiers and the infrastructure used indicate that the technique may have been independently adopted by multiple groups.

What to look for in Microsoft Entra ID logs

To detect these activities, it is not enough to check the number of failed authentications associated with the most commonly used applications. SOCs should analyze events where the application name is absent, client IDs that do not correspond to registered applications, and requests where both the application ID and application name are empty.

Particular attention should be paid to the error AADSTS700016. It does not necessarily indicate a simple configuration issue: in the presence of a forged client ID, it can signal that the attacker has already verified the correctness of the username and password.

Client ID spoofing alone does not allow bypassing multi-factor authentication or accessing the tenant. However, it can be used to identify existing accounts, verify already compromised credentials, and prepare subsequent attacks with fewer attempts and higher chances of success.