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.

This is an interesting question that I would love to hear a proper answer to. I have come across some information that Doug might find helpful, however, I feel it might be slightly inadequate. Someone else can probably provide an expanded answer:

Login to the server you would like to have audit information stored on, Run -> RSOP.MSC -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy -> "Audit account logon events" & "Audit Logon events"

The explination for "account logon events" reads:

Audit account logon events

This security setting determines whether the OS audits each time this computer validates an account’s credentials.

Account logon events are generated whenever a computer validates the credentials of an account for which it is authoritative. Domain members and non-domain-joined machines are authoritative for their local accounts; domain controllers are all authoritative for accounts in the domain. Credential validation may be in support of a local logon, or, in the case of an Active Directory domain account on a domain controller, may be in support of a logon to another computer. Credential validation is stateless so there is no corresponding logoff event for account logon events.

If this policy setting is defined, the administrator can specify whether to audit only successes, only failures, both successes and failures, or to not audit these events at all (i.e. neither successes nor failures).

The explination for "logon events" reads:

Audit logon events

This security setting determines whether the OS audits each instance of a user attempting to log on to or to log off to this computer.

Log off events are generated whenever a logged on user account's logon session is terminated. If this policy setting is defined, the administrator can specify whether to audit only successes, only failures, both successes and failures, or to not audit these events at all (i.e. neither successes nor failures).

You would essentially need to enable those policies, define the policy settings and choose "failure" if you just want to monitor failed attempts. If you want, you could monitor successes as well, but it might make it a bit harder to parse through if you are only worried about looking for this sort of attack.

If you are concerned about similar configurations that your systems may be vulnerable to, I would recommend looking into STIG settings (link), when used in conjunction with a SCAP Scanner, it can really assist in highlighting some of the risks that your organization might be facing. STIG viewer tends to raise a few false positives, but if you read into the specifics of what each issue has, you might find it a non-starter.