I already did one post about using eventcomb/logparser to look for clients but found a better way to do it on a case last night which I wanted to share.  The first thing you need is to enable netlogon debug logging on all of your DC’s save the following as a .reg file and import it on all your DC’s that you want to monitor:

Windows Registry Editor Version 5.00


This will cause netlogon to start logging extended entries to %windir%\debug\netlogon.log.  You may take a slight perf hit on your DC’s for this just as an FYI.  You will not fill up your drives as it logs to 2 20Mb files.. netlogon.log and netlogon.bak and uses circular logging where it starts overwriting once it fills up.

What we are looking for is the value “0xC000006A” on any line which indicates “The value provided as the current password is not correct”.  So we already have articles on using NLParse to look for these as well as you could use logparser etc but these are all non-realtime right, you copy  all the files somewhere you parse them you look at the output etc.. wouldn’t it be nicer if you could just have a console where you just glance and see when you have a malware client acting up :)..  The key to this is using a TAIL utility.  In my case I used Tail for Win32 which you can find here http://tailforwin32.sourceforge.net/

On the system you plan on monitoring from install this piece of software. Strangely you have to open a log file before you can start modifying the settings for the client so open your first netlogon.log file.  The client supports network paths so you will be opening \\DCNAME\C$\Windows\Debug\Netlogon.log for each of your DC’s (yes this would stink for a large environment but hopefully if you’re that large you spent the money on a product to do this for you anyway… right??).

Once you have your netlogon files open go to Settings>Keywords and add 0xC000006A as a keyword.  Also you will want to set “Show only Hot Lines” to enabled (this drops all the other netlogon junk which we don’t want to see) and set “Wrap Lines” to enabled.  Basically what you end up with in the end is multiple windows open that are only looking for entries of bad password attempts and pulling those in close to real time from the netlogon logs.  This allows you to easily see when a client is hammering away on user accounts and allows you to go shutdown and clean that system.  Another tip is you can use the Window>Cascade or Tile option to automatically arrange the netlogon file windows to easily see when a DC is seeing a problem client.

Updated had the wrong value in the for the reg key :)

Update 2 3/11/09:  This has a slight catch here apparently in that this is only for NTLM bad password attempts and you still need to use eventcomb or something else to see Kerberos bad password tried :(  http://technet.microsoft.com/en-us/library/cc776964.aspx 

“If the Netlogon logs from all domain controllers from the time of lockout but do not display data that pertains to any of the locked-out user accounts that you are analyzing, then NTLM authentication is not involved in the lockouts. This normally indicates that the authentication issues are between computers running Windows 2000 or later, because earlier versions of Windows used NTLM authentication exclusively. You should focus on Kerberos authentication troubleshooting by using Kerberos logging and examining the Security event logs.”

Update 3 4/9/09  http://baremetalsoft.com/baretail/ is also good actually seems better then tailforwin32, free windows gui tail utility to use with this solution.