Looking back at an incident from spring 2024, while I was global sysadmin at Infoblox.

Lockouts are the most boring ticket there is

Every IT queue everywhere is full of them. Someone fat-fingered a password, someone’s phone died and they can’t do MFA, someone came back from PTO and forgot which password they’d rotated to. You unlock, you move on, you don’t think about it again.

That’s exactly what a credential-stuffing attack looks like from the service desk. It doesn’t announce itself. It arrives one ticket at a time, in the most ignorable format your queue has.

What actually caught my attention

It wasn’t the volume. It wasn’t a spike big enough to be obviously wrong.

It was who was getting locked out.

Normal lockouts are random. They scatter across the org — someone in finance, someone in sales, someone in engineering, no relationship between them. That’s what unrelated user error looks like.

These weren’t scattered. They clustered, and they clustered around people who worked together. When the victim list starts looking like a slice of the org chart instead of a random sample, something is selecting for those accounts. Randomness doesn’t produce org structure.

So I escalated to the security lead and the SOC while it was still building, rather than working the tickets individually.

The reason it looked like that

Root cause turned out to be exposure rather than any infrastructure weakness.

A chunk of the marketing organization had recently come back from a large industry event. Their corporate email addresses had been harvested — trade shows are enormously effective at concentrating real, current, verified corporate addresses in one place — and those specific addresses were then run against the VPN with credential stuffing.

That’s why the victim list looked like a department. It was a department. The attacker didn’t pick them because of who they were internally; they picked them because those were the addresses they had.

Over 15 users locked out before it was mitigated. It got a formal incident number and a post-mortem.

The thing I actually think about

Nothing detected this before I did, and I want to be careful about how I say that, because it isn’t a brag — it’s the point.

There was tooling. There was a SOC. But the lockouts arrived through the support queue, and the support queue is not a security tool. It’s a workflow system that happens to be where the earliest, most direct evidence of an identity attack shows up: real users, in real time, telling you they can’t get in.

The gap wasn’t a missing product. It was that “account lockout” is filed as a support event, and support events get resolved rather than analyzed. Every one of those tickets was individually closeable. The signal only existed in aggregate, and nothing in the workflow encourages you to look at the aggregate.

What I’d tell someone on a service desk

Look at who, not just how many. Volume thresholds catch loud attacks. Shape catches quiet ones. A modest number of lockouts concentrated in one team is more interesting than a larger number spread evenly.

Correlate against the outside world. The unlock in this case was remembering there’d been a conference. Recent public events involving your people — trade shows, a funding announcement, a press cycle, layoffs — change your exposure, and they explain victim lists that otherwise look arbitrary.

Escalate on pattern, not on certainty. I didn’t know it was an attack. I knew the distribution was wrong. Waiting until I could prove it would have cost the SOC time they used. The cost of being wrong was a slightly embarrassing message; the cost of being late was every additional account they got through.

Your queue is a sensor. It’s staffed by people who talk to users all day and develop a real feel for what normal looks like. That intuition is worth something, and it’s usually the first thing to notice when normal changes.

The most useful security instinct I picked up wasn’t a tool. It was the habit of asking why these people instead of just clearing the ticket.