Best Way to Track Brute-Force Username Enumeration / Failed Username Attempts AD
Great question.
First things first - I consider most "penetration testers" to be script kiddies. My bias may not be fair or accurate but I'm putting in this disclaimer so that if you detect any cynicism in my tone, you know where it's coming from. I'm not saying there are no skilled pentesters, but this is my sweeping generality.
(Blue team for life!)
My question: 1) Is there a way to get Active Directory to log these failed username requests in a central location so we can notice a spike in them?
You did not supply enough information for anyone to be able to answer this question thoroughly and with confidence. You said your application was found to contain a flaw that allowed the attackers to enumerate user accounts. I'm trying to understand in what way you feel that AD needs to perform logging for your application.
Apparently the failures only ever showed up in the local event log of the server where the application was installed.
Apparently the failures showed up in the event log on the server? Or the failures did show up in the event log on the server? If so, what exactly did the events say? Who logged them? Your application? Or Windows? Go find out and I may be able to add additional clarification to my answer.
I'm going to go out on a limb here based on your presumption that these events should have been logged by Active Directory somehow... what if your pentesters weren't actually exploiting a flaw in your application at all, but were instead using a very well-known flaw in Kerberos itself to enumerate usernames? Kerberos itself contains what I would consider a design flaw in which an attacker can attempt thousands and thousands of "pre-authentication" attempts (i.e. a brute force attack) and the KDC will respond differently depending on whether the user account exists or not. This is not Active Directory-specific behavior, but applies just as well to MIT Kerberos, Heimdal, etc. The KDC will respond with KDC_ERR_PREAUTH_REQUIRED if a valid username was presented with no pre-auth data, even without attempting an actual authentication. In this way you can enumerate usernames from a KDC. But because the attacker (or the tool that the attacker is using such as KrbGuess - because pentesters are at their best when they're using other people's tools,) does not have to continue on to a full authentication attempt, nothing is logged because no actual authentication was attempted!
Now, on to your next question:
2) If not, what is the best way to monitor and actively detect this type of attack in the future (Hopefully without having to buy too much new equipment).
A couple of things.
First, there are paid, enterprise-grade products that are designed to detect these sorts of attacks (among much else.) Many vendors offer such products, and product recommendations are off-topic for Serverfault, but suffice it to say that they are out there. Many of these products work by requiring you to configure port mirroring between your domain controllers and these "data collectors" so that they see and analyze literally each and every packet that enters or exits your domain controllers.
(Sorry, that kinda' falls in to your "without buying too much new stuff" clause.)
Another thing that might help you is the registry entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
LogLevel = 1
Documented here.
If you enable this registry entry, you should get flooded with events in your Security event log about Kerberos errors that mention that Kerberos pre-authentication is required. An example of such an event:
A Kerberos Error Message was received:
on logon session DOMAIN\serviceaccount
Client Time:
Server Time: 12:44:21.0000 10/9/2012 Z
Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
Extended Error:
Client Realm:
Client Name:
Server Realm: DOMAIN
Server Name: krbtgt/DOMAIN
Target Name: krbtgt/DOMAIN@DOMAIN
Error Text:
File: e
Line: 9fe
Error Data is in record data.
But this may or may not help you if it doesn't specify where exactly the tsunami of Kerberos requests are coming from. This leads us back to those enterprise intrusion detection products that I mentioned earlier.
And dont't forget Windows Event Forwarding that can have your servers forwarding events to a centralized location to be analyzed by whatever tool you may have at your disposal.
This entire answer has so far been predicated on the Kerberos protocol, which I can't even really take for granted because you gave so little detail in your post. Nevertheless, I hope this helps at least a little.