Hackers Are Faking OAuth App IDs to Quietly Test Stolen Microsoft Logins

A new trick lets attackers check stolen Microsoft Entra ID passwords without triggering a single sign-in alert.

ThreatVectr Newsdesk· 4 min read
Full frame photoreal editorial shot of a dimly lit corporate server room with soft blue rack lights, a single glowing cloud-shaped indicator on a monitoring scr
Share

Key points

  • At least two separate hacking groups are using a new trick called OAuth client ID spoofing to test stolen Microsoft cloud logins without setting off alarms.
  • The technique targets Microsoft Entra ID, the login system that millions of companies use to control who gets into their email, files and apps.
  • The attackers can confirm whether a username and password work, and even list valid accounts, without ever producing a successful sign-in record for defenders to see.
  • Standard security dashboards do not flag the activity because no login actually completes.
  • Turning on multi-factor authentication would blunt most of the damage, since a working password alone is not enough to get in.

A quiet new attack is making life harder for the people who guard corporate cloud accounts.

At least two separate groups of criminals are using a technique researchers are calling OAuth client ID spoofing. In plain English, they are lying about which app is asking Microsoft to check a password, and Microsoft's login system answers the question anyway.

That answer is enough to tell an attacker whether a stolen username and password combination is real. It also lets them run down long lists of email addresses to see which ones actually exist inside a company. And none of it shows up as a successful login.

What is actually happening here?

The target is Microsoft Entra ID, the cloud service (formerly known as Azure Active Directory) that most large organisations use to manage staff logins to Microsoft 365, Teams, SharePoint and thousands of connected apps.

When you sign into one of those apps, your browser hands Microsoft two pieces of information: your credentials, and an ID for the app you are trying to reach. That app ID is part of OAuth, the industry standard (RFC 6749) that lets one service log you into another.

The catch: the app ID is not verified in the way a defender might assume. An attacker can pretend to be a well known, trusted Microsoft app when submitting a password check. Entra ID processes the request, tells the attacker whether the password worked, and, crucially, does not write a normal sign-in event to the logs that security teams watch.

So the attacker gets the answer they wanted. The company sees nothing.

Why is this a big deal?

Most companies rely on failed and successful sign-in logs to spot password-spraying attacks, where criminals try common passwords against many accounts. Take away that signal and the usual detection playbook stops working.

As first reported by The Hacker News, the technique is already being used in live campaigns, not just proof-of-concept demos. Two distinct groups are running it, which suggests the method is spreading through the criminal ecosystem.

Stolen passwords are cheap and plentiful, mostly harvested through phishing, where criminals send fake emails to trick staff into typing their password into a lookalike site, and through infostealer malware that scrapes saved passwords off infected laptops. Being able to silently sort the working passwords from the dead ones is genuinely useful to an attacker planning a follow-up intrusion.

Would MFA have helped?

Honestly, yes, mostly. Multi-factor authentication, where a login also needs a code from a phone or a hardware key, means a correct password on its own does not open the door. The spoofing trick can still confirm the password is valid, which is bad, but the attacker cannot walk in with it.

Phishing-resistant MFA, such as passkeys or FIDO2 security keys, is stronger still because it also refuses to hand credentials to fake sites.

What should ordinary people do?

If you use a work Microsoft 365 account, turn on MFA if your employer has not already forced it. Use a password manager so every site gets a unique password, which limits the blast radius if one leaks. And treat any email asking you to "reconfirm your Microsoft login" as suspicious until proven otherwise.

Microsoft has not yet published a formal advisory naming this specific abuse pattern. Defenders will want to widen their monitoring beyond the standard sign-in logs, and to review which OAuth application IDs are legitimately used inside their tenant.

© 2026 Threat Vectr