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

Key points

• At least two hacking groups are using OAuth client ID spoofing to test stolen Microsoft cloud logins without setting off alarms.
• The technique targets Microsoft Entra ID, the login system millions of companies use to control access to email and files.
• Attackers can confirm whether a username and password work, and list valid accounts, without producing a successful sign-in record.
• Standard security dashboards don't flag the activity because no login actually completes.
• Multi-factor authentication would blunt most of the damage, since a working password alone isn't enough to get in.

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

At least two distinct criminal groups are using a technique researchers call OAuth client ID spoofing. They're 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 confirm whether a stolen username and password combination is real. It also lets attackers work through long lists of email addresses to find which ones exist inside a company. None of it shows up as a successful login.

What is actually happening here?

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

When you sign into one of those apps, your browser hands Microsoft two things: your credentials, and an ID for the app you're trying to reach. That app ID is part of OAuth, the industry standard that lets one service log you into another.

The catch: the app ID isn't verified the way a defender might assume. An attacker can impersonate a trusted Microsoft app when submitting a password check. Entra ID processes the request, returns whether the password worked, and doesn't write a normal sign-in event to the logs security teams watch.

The attacker gets the answer. The company sees nothing.

Why is this a big deal?

Most companies rely on sign-in logs to spot password-spraying attacks, where criminals try common passwords against many accounts. Remove that signal and the standard detection playbook breaks.

As first reported by The Hacker News, the technique is already running in live campaigns, not just proof-of-concept demos. Two distinct groups are using it, which suggests it's spreading through the criminal ecosystem. That pattern looks familiar: we reported on 3 July that a single spray campaign threw 81 million login attempts at Microsoft 365 accounts over two weeks.

Stolen passwords are cheap, mostly harvested through phishing (fake emails that trick staff into typing credentials into lookalike sites) and infostealer malware that scrapes saved passwords off infected laptops. Silently sorting working passwords from dead ones is genuinely useful to an attacker planning a follow-up intrusion.

Would MFA have helped?

Honestly, yes, mostly. Multi-factor authentication (MFA) requires a login to also supply a code from a phone or hardware key, so a correct password alone doesn't open the door. The spoofing trick can still confirm the password is valid, which is bad, but the attacker can't walk in with it.

Phishing-resistant MFA using passkeys or FIDO2 hardware keys is stronger still, because it also refuses to hand credentials to fake sites. Microsoft is already moving in that direction: passkeys become the default for Entra ID business accounts in September 2026, with SMS codes cut off in February 2027.

What should ordinary people do?

If you use a work Microsoft 365 account, turn on MFA if your employer hasn't already forced it. Use a password manager so every site gets a unique password, which limits the damage if one leaks. Treat any email asking you to reconfirm your Microsoft login as suspicious until proven otherwise.

Microsoft hasn't published a formal advisory naming this specific abuse pattern. Defenders should widen monitoring beyond standard sign-in logs and review which OAuth application IDs are legitimately used inside their tenant. A working password that never produces a login event is still a working password.