Hackers Use 3.7 Million Fake OAuth Client IDs to Target 2 Million Entra ID Users

Hackers are using fake OAuth client IDs to enumerate Microsoft Entra ID accounts and test stolen passwords without generating successful sign-in events. The technique can also weaken security detections that group suspicious activity by application name.

The largest campaign identified by Proofpoint targeted more than two million users and submitted 3.7 million spoofed application IDs. A separate campaign targeted over one million accounts across nearly 4,000 Entra ID tenants.

According to Proofpoint’s OAuth client ID spoofing research, differences in infrastructure, user agents, and ID-generation methods suggest that separate threat actors have adopted the technique.

How OAuth client ID spoofing works

An OAuth client ID is a globally unique identifier assigned to an application. The application includes this value in the client_id field when it sends an authentication request to Microsoft Entra ID.

Attackers do not need to compromise or register an OAuth application for this technique. They can insert fabricated identifiers into authentication requests and study the responses returned by Entra ID.

Proofpoint reproduced the technique through Microsoft’s OAuth token endpoint using the Resource Owner Password Credentials flow. This flow lets an application submit a username and password directly. Microsoft’s ROPC documentation warns that the flow does not support multifactor authentication and recommends more secure authentication methods where possible.

Error codes can reveal account and password status

Entra ID returns different AADSTS error codes depending on the submitted username, password, and application identifier. Attackers can compare these responses to determine whether an account exists and whether a password works.

Authentication input	Entra ID response	What attackers may learn
Nonexistent username	AADSTS50034	The account does not exist
Valid username with an incorrect password	AADSTS50126	The username exists, but the password is wrong
Valid username and password with an unregistered client ID	AADSTS700016	The credentials may be valid, but the application identifier is not recognized

The AADSTS700016 response normally means that Entra ID could not find the supplied application identifier in the directory. Microsoft lists this response in its authentication error code reference.

In this attack scenario, however, the error may appear only after Entra ID has accepted the username and password. The request still fails because the fake application does not exist, but the attacker has already learned that the credentials may work.

Successful credential checks can look like failed logins

The use of an unregistered client ID prevents the authentication process from producing a successful sign-in. Security teams may therefore see only a failed request associated with an unknown application.

A syntactically valid but unregistered client ID appears in the application ID field of Entra ID sign-in logs. However, the related application name remains blank because no registered application matches the identifier.

If the attacker supplies a malformed client ID, both the application ID and application name fields may remain empty. Detections that depend on a known application name or count requests against individual applications may overlook this activity.

Attackers can spread requests across fictional applications

Traditional account-enumeration tools often use a small number of legitimate Microsoft application IDs. A large rise in authentication attempts associated with one application can trigger security alerts or rate limits.

OAuth client ID spoofing lets attackers divide requests across hundreds of thousands or millions of fictional applications. Each fake ID may appear only once or a few times, making the broader campaign harder to connect.

Conditional Access policies scoped only to specific applications may also fail to cover a fake identifier because it does not match the application included in the policy. This does not mean OAuth client ID spoofing bypasses every Conditional Access policy, but application-specific controls may not apply as defenders expect.

UNK_pyreq2323 targeted more than one million users

Proofpoint first observed the campaign tracked as UNK_pyreq2323 on January 14, 2026. Activity peaked in late January and early February before declining in early March.

The campaign targeted more than one million unique accounts across nearly 4,000 Entra ID tenants. It used over 700,000 spoofed client IDs and generated enough failed requests to lock approximately 28% of the targeted accounts.

Requests originated from Amazon Web Services infrastructure and used the python-requests/2.32.3 user agent. The attacker created fake identifiers by retaining the prefix of the Exchange Online application ID while changing its final six digits.

UNK_OutFlareAZ used 3.7 million fake client IDs

The larger campaign, tracked as UNK_OutFlareAZ, began in December 2025. It targeted more than two million users and used 3.7 million spoofed application IDs, according to the Proofpoint campaign analysis.

Most of the traffic came through Cloudflare infrastructure, although that does not indicate that Cloudflare participated in the campaign. The attackers also used a Microsoft Outlook user agent previously seen in other enumeration activity.

The campaign operated in two main waves. The first began on December 10, 2025, and peaked later that month at approximately 242,000 targeted users. A larger wave started in February 2026 and peaked on March 15 at around 720,000 users.

Detail	UNK_pyreq2323	UNK_OutFlareAZ
Users targeted	More than 1 million	More than 2 million
Spoofed client IDs	More than 700,000	3.7 million
Primary infrastructure	Amazon Web Services	Cloudflare and other providers
Client ID method	Changed the final digits of an Exchange Online ID	Generated a random UUIDv4 for each request
ID reuse	Up to 12 users per ID	One user per ID
Enumeration pattern	Non-alphabetical	Alphabetical

Random identifiers made correlation harder

UNK_OutFlareAZ generated a new UUIDv4 client ID for every authentication request. This prevented defenders from grouping large volumes of activity around a reused identifier.

The attackers tested common usernames such as dsmith, msmith, and jbrown across multiple tenants. Proofpoint believes the pattern indicates the use of a prepared username list against numerous organizations.

Proofpoint found clear differences between the two campaigns. These included their infrastructure, user agents, enumeration order, and methods for generating client IDs. The differences suggest that separate operators or tools independently adopted the same technique.

How organizations can detect OAuth client ID spoofing

Security teams should not treat every AADSTS700016 event as an attack. Legitimate configuration mistakes, missing application registrations, incorrect tenants, and application-consent problems can also produce this error.

However, a large number of these errors across different users, source addresses, or apparently random application IDs deserves investigation. Defenders should correlate the error with password failures, account lockouts, user agents, source infrastructure, and other authentication activity.

Organizations should review the following indicators:

• Sign-in events that contain an application ID but no application name.
• Events where both the application ID and application name are blank.
• Large numbers of AADSTS700016 responses affecting different users.
• Random UUIDv4 application IDs that appear only once.
• Authentication attempts spread across many unknown applications.
• Unusual account lockouts or repeated testing of common usernames.
• Outlook, Python, or other user agents appearing across unexpected infrastructure.

Defenders can use Microsoft’s AADSTS error descriptions during investigations, but the surrounding context matters. An application-not-found error may indicate that an attacker supplied working credentials with a fictional client ID.

Organizations should reduce reliance on passwords

Microsoft recommends avoiding the Resource Owner Password Credentials flow because it requires applications to handle passwords directly and does not work with MFA. Organizations should identify and replace legacy applications that still depend on it where possible.

Phishing-resistant authentication, including passkeys and hardware-backed security keys, can reduce the value of stolen passwords. Organizations should also apply Conditional Access broadly instead of relying only on policies tied to a few commonly targeted applications.

The campaigns show why successful sign-ins should not serve as the only evidence of compromised credentials. A failed request involving an unknown application can still tell an attacker that a username and password combination works.

FAQ