VPN Brute-Force Incident — Early Detection and Response
CompleteOverview
A brute-force credential attack hit the corporate VPN and began locking users out of their accounts. I was one of the first members of the global service desk to recognize the pattern as an attack rather than a run of unrelated lockouts, and escalated it to the security lead and the SOC. The incident was formally tracked and later reviewed in a post-mortem.
Problem
Account lockouts are the single most common ticket in any IT queue. That is exactly what makes a credential-stuffing attack hard to spot from the service desk: the attack presents as the most boring possible symptom, one user at a time, through the normal support channel.
What made this one different was shape rather than volume — the lockouts clustered, and they clustered around users who had a reason to be targeted together.
Approach
Rather than 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 happened from the service desk tier, not from a monitoring alert.
Root cause turned out to be exposure rather than infrastructure: a portion of the marketing organization had recently returned from a large industry event, and their corporate addresses had been harvested. Those specific addresses were then used for credential stuffing against the VPN, which is why the victim set looked like an org chart slice instead of a random sample.
From there I supported mitigation alongside the security team, and participated in the formal post-mortem reviewing the attack.
Outcome
The attack was identified and escalated early enough for the security team to act on it 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 rather than 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.