The Repeat · New episode every Monday
Last week's attacks. This week's protection.
Every Monday, The Repeat breaks down what attackers actually did last week to Microsoft environments and the services you rely on: what happened, why the usual defenses stayed quiet, and the exact steps to take before the same attack repeats on you. A few focused minutes, no jargon.
Latest episode
AADSTS700016: the Entra log that means you're breached
Episode 14 min
Two campaigns tested stolen credentials against roughly three million Microsoft accounts using OAuth client ID spoofing: ROPC login requests sent with fake application IDs, reading Microsoft's own error responses to confirm which passwords still work. No sign-in ever succeeds, so most SOC detections never fire. In your Entra ID sign-in logs the attack looks like a failed login, but error AADSTS700016 with a blank application name means the attacker's password was correct.
What to do about it today
- Run the sign-in log query below against your Entra ID SigninLogs before anything else today.
- Treat AADSTS700016 with an empty application name as a validated password, not a failed login. Reset those credentials first.
- Check your Conditional Access scoping: policies scoped per application never trigger on these requests. Apply baseline policies that cover all apps.
- Don't read silence as safety. AADSTS50034 never reaches SigninLogs, because Entra only logs attempts against usernames that exist.
SigninLogs
| where ResultType in ("700016", "50126")
| where isempty(AppDisplayName)
| summarize attempts=count(), users=dcount(UserPrincipalName)
by IPAddress, ResultType
| order by attempts descAADSTS50034 will not appear in SigninLogs: Entra only logs sign-in attempts against usernames that exist, so the invalid-username case never reaches the table.
The format
What happened. Why it worked. What to do.
Most people hear about an attack weeks after it mattered, when it's a headline instead of a warning. The Repeat closes that gap: one short episode, every Monday, built from what actually hit the week before.
What happened
Last week's campaign in plain language: who was targeted, how it got in, and the real numbers behind it.
Why defenses missed it
The specific reason alerts stayed quiet, so you can check whether yours would have too.
What to do now
Concrete steps and, when it helps, the exact query to run. Usable in minutes, without buying anything.
Beyond awareness
Watching is how you find out. Members are already protected.
The Repeat exists because most organizations learn about an attack after it lands, when the cleanup starts. Awareness closes part of that gap. It cannot close all of it, because attackers move faster than headlines.
That is the problem UnifiedONE was built for. When one member of the community validates a threat, protection applies to everyone connected, at the front gate, before impact. The attack you hear about on Monday is often one the community stopped the week before.
About the series
When do new episodes come out?
Every Monday. Each episode analyzes attacks from the previous week, so the steps are current when you watch.
What does The Repeat cover?
Real campaigns from the previous week that affect Microsoft environments and the everyday services organizations rely on. Each episode explains what happened, why defenses missed it, and what to do about it.
Is it only about Microsoft?
Microsoft environments come up often because that's where most organizations live, but the series covers whatever mattered last week, whichever service it hit.
Do I need UnifiedONE to use the advice?
No. Every step works on its own, with the tools you already have. UnifiedONE automates the same protection across a community, so members are covered before an episode even airs.
Never learn about an attack too late again.
Subscribe for Monday's episode, or connect your environment and let validated protection apply automatically.