A Blocked Sign-In Is Still A Breached Password

Here is a sign-in that most SOCs close without a second look: result Failure, error code AADSTS53003, "Access has been blocked by Conditional Access policies." The policy worked and nobody got in, so the ticket gets closed.

Look at what has to be true for that error to appear. Entra ID evaluates Conditional Access after it has checked the password. A wrong password fails earlier, with a different code. So every AADSTS53003 tells you something the person signing in now knows as well: that username and password are correct.

In its 22 October write-up of a Microsoft 365 token spray-and-replay campaign, Huntress said it plainly: AADSTS53003 means the credential was valid, not that the attack was stopped. Their advice was to prioritise response by credential validity, not by the volume of the spray. We agree, and we think it should change how blocked sign-ins are triaged.

Why "blocked" feels like a win

Conditional Access is doing its job when it blocks a sign-in from an unmanaged device, a disallowed country or a legacy client. Dashboards count those blocks as prevented attacks, and most of the time the count is high because password spraying is constant background noise.

The trouble is that the noise and the signal arrive in the same log table. A thousand failed sign-ins with error 50126 (wrong password) are the spray. One sign-in with error 53003 in the middle of them is the spray's success. If triage is driven by volume, the one that matters is buried under the thousand that do not.

What a valid-credential block actually means

Plenty of 53003 events are your own users on a personal laptop or travelling. But when you see AADSTS53003 for a user who did not make the attempt, four things follow:

1. The password is compromised. It came from a breach, a phishing page, an infostealer or a lucky guess, and it now sits in someone's list of working credentials.
2. The policy that stopped it is the only control left. Change that policy, add an exclusion for a project, or find a client type it does not cover, and the next attempt succeeds.
3. The attacker will try other routes. The same credential may work on a VPN, a third-party SaaS app with its own login, or a personal account where the user reused it.
4. Other users are probably in the same position. Credentials tend to arrive in batches.

None of those are closed by the block. All of them are closed by a password reset, a check for other activity and a look at whether the same source succeeded anywhere else.

What the Huntress campaign showed

In the campaign Huntress tracked, the attacker made more than 200,000 sign-in attempts and got at least 497 successful sign-ins across 79 organisations. In one four-day burst in September there were 303 successful sign-ins across 29 organisations, and 1,052 blocked sign-ins at four organisations. Read with Huntress's own guidance on AADSTS53003, those blocks were not failures. They were working credentials that met a policy, held by an attacker who already had a way past MFA elsewhere.

The organisations where the policy held were lucky that it held. They were still exposed in the sense that matters: someone outside had a working password for their users.

How we think triage should work

The fix is not a new tool. It is a different question at the top of the triage process. Ask "was the credential valid?" before "how big was the spray?"

• Separate the error codes. Wrong-password failures (50126) are a volume metric. Valid-credential blocks (53003, and MFA-stage failures where the password step passed) are individual incidents.
• Raise the severity of valid-credential blocks from unfamiliar sources, and raise it further if the same source IP succeeded anywhere else in the tenant.
• Act on the credential, not the event. If the user didn't make the attempt, reset the password, review their recent sign-ins, registered devices and authentication methods, and tell them why.
• Look sideways. Check whether the same source tried other users, and whether those attempts ended in 53003 too.
• Close the gap the attacker is looking for. Make sure Conditional Access covers all users, all cloud apps and all client app types, and move high-value users to phishing-resistant MFA.

A starting point for Microsoft Sentinel, to tune for your tenant:

// Valid credentials stopped only by Conditional Access
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "53003"
| summarize Attempts = count(), IPs = make_set(IPAddress, 10),
            Locations = make_set(Location, 10), Apps = make_set(AppDisplayName, 10)
    by UserPrincipalName
| order by Attempts desc

Run it once against your own tenant. Every name on the list is worth a question: if that user didn't make the attempt, someone else knows their password.

The wider point

Preventive controls fail quietly. A blocked sign-in feels like the end of the story because nothing visible happened. Usually it is the middle: the attacker found the door locked and went looking for another one. Detection and response exist for that middle. The useful question about any block is what the attacker learned from it.

This is how our SOC treats identity alerts. Our 24/7 SOC works them to a conclusion, and CYBERSHIELD AI investigates every incident, reaching a verdict in an average of 3 minutes 30 seconds. Whether an incident is closed or escalated is decided by policy and your own decision templates, not by the model. We have written before about how identity attacks hide in plain sight in Entra ID logs. Valid-credential blocks are one of the plainest examples. For a worked example of the campaign behind this post, see our threat research on the token spray-and-replay campaign.

If you want to know how many valid-credential blocks your tenant logged this month, and what happened next, talk to us or book a demo.