VPN Brute-Force Incident: Early Detection and Response
CompleteOverview
A brute-force credential attack hit the corporate VPN and started locking users out of their accounts. I was one of the first on the global service desk to read the pattern as an attack and not a run of unrelated lockouts, and I escalated it to the security lead and the SOC. The incident was formally tracked and reviewed in a post-mortem.
Problem
Account lockouts are the most common ticket in any IT queue. That is what makes a credential-stuffing attack hard to spot from the service desk: it presents as the most boring possible symptom, one user at a time, through the normal support channel.
What made this one different was shape, not volume. The lockouts clustered, and they clustered around users who had a reason to be targeted together.
Approach
Instead of working the lockouts as individual tickets, I treated the clustering itself as the signal and escalated to the security lead and SOC early, while the pattern was still forming. That escalation came from the service desk tier, not from a monitoring alert.
Root cause was exposure, not infrastructure. Part of the marketing organization had recently returned from a large industry event, and their corporate addresses had been harvested there. Those specific addresses were then used for credential stuffing against the VPN, which is why the victim set looked like a slice of the org chart instead of a random sample.
From there I supported mitigation alongside the security team and took part in the formal post-mortem.
Outcome
The attack was identified and escalated early enough for the security team to act while it was still in progress. 15+ users were locked out before mitigation. The incident was documented and reviewed as a formal post-mortem, and the exposure pathway (conference-harvested corporate addresses) was understood instead of left as an unexplained spike.
Lessons Learned
The service desk sees the attack before the dashboard does. A lockout queue is a security signal that happens to arrive in a support tool, and the only thing separating “unlucky Tuesday” from “active attack” is whether someone looks at who is being locked out instead of how many. Correlating victims against a recent external event is what turned a ticket pattern into an explanation.