Attackers spoofing OAuth client IDs to cloak Entra compromise attempts: Proofpoint

Proofpoint has identified multiple cloud campaigns in which attackers used forged OAuth client IDs to reveal Microsoft Entra ID accounts. The attackers can then test credentials like passwords without triggering compromised-credential alerts. The technique allows threat actors to test large numbers of usernames and passwords without creating or registering an OAuth application. An OAuth client ID is a public identifier used to identify the application making an authentication request. The cyberattack technique relies on differences in the types of authentication errors generated. Entra ID returns different AADSTS error codes depending on whether the username exists, whether the password is correct, and whether the supplied client ID corresponds to a registered application. Threat actors can interpret these error codes to differentiate nonexistent accounts from valid users and identify valid username-password combinations. This works even if the authentication request fails because the application identifier is not recognized. For example, a fabricated client ID can reveal that a username and password were accepted before Entra ID rejected the request because the supposed application does not exist. The company says this allows valid credentials to be identified without generating a successful sign-in record. Users must implement effective monitoring Proofpoint says users should not treat an “application-not-found” error as a configuration problem. The error can occur after Entra ID has accepted a valid username and password but rejected the request because the supplied client ID does not correspond to a registered application. The event may indicate that an attacker has identified working credentials, even though no access token was issued and no successful sign-in was recorded. The application metadata in the sign-in record can provide an initial indicator. Proofpoint recommends treating these patterns as potential signs of client ID spoofing. Those credentials could then be tested through a real application or used in phishing, MFA-targeting or other account-compromise attempts. This OAuth client ID spoofing exposes a digital identity security problem in which an authentication system can deny access while still revealing useful information about the accounts and credentials being tested. Users must analyze error code patterns, incomplete application metadata, large numbers of client IDs, and requests targeting many accounts from related infrastructure.

Proofpoint has identified multiple cloud campaigns in which attackers used forged OAuth client IDs to reveal Microsoft Entra ID accounts. The attackers can then test credentials like passwords without triggering compromised-credential alerts. The technique allows threat actors to test large numbers of usernames and passwords without creating or registering an OAuth application.

An OAuth client ID is a public identifier used to identify the application making an authentication request. The cyberattack technique relies on differences in the types of authentication errors generated. Entra ID returns different AADSTS error codes depending on whether the username exists, whether the password is correct, and whether the supplied client ID corresponds to a registered application.

Threat actors can interpret these error codes to differentiate nonexistent accounts from valid users and identify valid username-password combinations. This works even if the authentication request fails because the application identifier is not recognized. For example, a fabricated client ID can reveal that a username and password were accepted before Entra ID rejected the request because the supposed application does not exist.

The company says this allows valid credentials to be identified without generating a successful sign-in record. Users must implement effective monitoringProofpoint says users should not treat an “application-not-found” error as a configuration problem. The error can occur after Entra ID has accepted a valid username and password but rejected the request because the supplied client ID does not correspond to a registered application.

The event may indicate that an attacker has identified working credentials, even though no access token was issued and no successful sign-in was recorded. The application metadata in the sign-in record can provide an initial indicator. Proofpoint recommends treating these patterns as potential signs of client ID spoofing.

Those credentials could then be tested through a real application or used in phishing, MFA-targeting or other account-compromise attempts. This OAuth client ID spoofing exposes a digital identity security problem in which an authentication system can deny access while still revealing useful information about the accounts and credentials being tested. Users must analyze error code patterns, incomplete application metadata, large numbers of client IDs, and requests targeting many accounts from related infrastructure.