A Snort Alert Was the Red Herring. Underneath, It Was an Active Password Spray.

This one didn’t come from my home lab. This was a real ticket, on a real client environment, and I worked it in real time. No controlled test, no Atomic Red Team, no safety net. Just a vague complaint about user lockouts and a Meraki firewall log pointing at a Snort rule I had never seen before.

Here’s what I found.

The Alert That Started It

Multiple users were being locked out, and the Meraki firewall had flagged Snort rule 3:41548, described as an F5 BIG-IP TLS session ticket uninitialized memory disclosure attempt. If you don’t know what F5 BIG-IP is, you’re not alone, I didn’t either. It’s an enterprise-grade application delivery controller used for load balancing, SSL termination, and remote access. The rule exists because a specific vulnerability in BIG-IP’s SSL profile can leak uninitialized memory to a remote attacker.

The problem? This client wasn’t running BIG-IP. After confirming the gateway server was a plain Windows Server with no F5 software present, the Snort rule became a false positive. Windows RD Gateway handles TLS session tickets natively, and the way Windows constructs that session ticket data is close enough to the malformed F5 pattern that Snort matched on it. The firewall was blocking legitimate traffic, not an attack.

Case closed, right? Not even close.

Here’s Where It Gets Interesting

When I pulled the Meraki event log expecting to see a flood of 3:41548 events, I only found a handful. But there were hundreds of failed logon events sitting right next to them.

That’s the moment I asked the right question: are these two things even related?

A few IPS false positives don’t cause widespread lockouts across multiple user accounts. The volume didn’t add up. So instead of whitelisting the Snort rule and calling it done, I went to the domain controller.

What the DC Logs Actually Showed

Filtered for authentication failures and found 806 Event ID 4776 entries within 30 minutes, all across different accounts. Event ID 4776 is the domain controller logging NTLM credential validation failures, meaning something was hammering authentication requests directly against the DC at scale.

Now for the fun part. Each event has an error code buried in it. Here’s what the codes mean:

• 0xC000006A: Valid username, wrong password
• 0xC0000064: Username doesn’t exist in the environment

Every event I checked came back 0xC0000064. The accounts being targeted didn’t exist. The attacker wasn’t working from any knowledge of this environment; they were cycling through a generic username wordlist: jsmith, admin, john.doe, administrator, the usual suspects.

The Source Workstation field on every single event pointed back to the RD Gateway server, confirming the attack was entering through the publicly exposed gateway and passing authentication requests straight through to the DC.

This is a password spray, not a brute force. Brute force hammers one account with many passwords. Spraying tries common passwords across many accounts, specifically to stay under lockout thresholds. The lockouts on real accounts were collateral damage from the spray incidentally hitting valid usernames.

Key Takeaways

Don’t stop at the first alert. The Snort rule was a real finding, but it was not the incident. Closing the ticket there would have left an active attack undetected.

IPS false positives can mask what’s underneath. When a Snort rule fires on legitimate traffic and blocks it, the downstream effects can look exactly like an attack. Validate the rule before you act on it.

Volume and pattern matter. A handful of IPS events next to hundreds of authentication failures tells a story. Learn to read the ratio, not just the individual alerts.

Event ID 4776 with 0xC0000064 at scale is a spray signature. If you’re seeing it across many different non-existent accounts in a short window, something is working through a wordlist against your environment.

The Snort alert wasn’t the threat. It was the thing that made me look close enough to find the real one.

Not every finding comes from a lab. Follow along as I document both the controlled testing and the real-world work.