This week, let’s discuss a detection idea that seems great when you’re building a detection system: alerting when a user account experiences many failed logins.

Or, in other words: alerting when an attacker is banging on the door.

First, it’s worth asking: why would someone want to alert on “many failed logins”?

Usually, a high volume of failed logins from suspicious IPs/locations indicate that the user is actively being targeted by an attacker.

Because that user is being targeted, they’re at a higher risk of being successfully hacked. So, it makes sense to want to monitor that account extra closely.

However––in practice, in the age of automation––there are failed attacks happening all the time.

This barrage of failed logins is one of the ways that attackers wear down defenders. If a defender alerts on failed attacks, they’re much more likely to experience alert fatigue themselves, and miss the real attack when it comes in.

Let’s dive into a real attack we stopped recently to see why this approach doesn’t work.

‍

A Loud and Persistent Brute Force Campaign

In a previous post, we dove into a campaign where many users were probed from the same IP infrastructure—a slow and quiet spray.

This case is exactly the opposite––it was loud and bombastic. Logins from all over the world, all kinds of highly suspicious IPs, most of them so suspicious that they were outright blocked by Microsoft.

Here’s a snapshot of the logs:

Over two weeks, the attacker cycled through nearly 50 different IPs —a mix of proxies and data centers from all over the world—trying to brute-force a single account without MFA.

Most of those logins were blocked by Microsoft. But, eventually, one got through.

‍

What If You Alerted on “Too Many Failed Logins”?

Let’s paint the picture:

Day 1: You get a handful of alerts.

Day 2: More alerts. Same user. Still blocked.

By Day 4 or 5, the alert volume is high—and still nothing’s actionable. The attacker hasn’t gotten in.

Then it happens: one login succeeds.

But by then, you’re desensitized. The alert looks just like the last 20. It blends in.

‍

The Noise is a Feature, Not a Bug (For the Attacker)

Attackers know how alert logic works. They know noisy login failures create fatigue.

Sometimes, the noise is the tactic—designed to make the real signal easy to miss.

‍

Takeaway: Failed Logins Should Be a Signal, Not a Trigger

Repeated failed logins matter. They tell you who’s being targeted.

But alerting on them directly just floods your team with unactionable noise.

Use them as context. And when a login finally lands, you’ll know it’s real—and you’ll kick the attacker out fast.

Bonus points if you can build that awareness of failed attacks into your detection system. It’s what we’ve done at Petra.

—

We’re partnering with more and more folks who handle BEC Incident Response engagements. If that’s you,  schedule a demo today.