Monday, December 19, 2011

Quick Tip UPDATED: The Care and Feeding of your Hacker Check

"Oh, No! The Hacker Check went off! We're under attack!"

Not necessarily.


Wednesday, November 30, 2011

The hacker check is not a proof of intrusion as much as it is a canary in the coal mine. By understanding exactly what the Hacker Check does, you can learn how best to make it work for you:

The Hacker Check looks for the following Event IDs in the Security Log over a 24 hour period, it then totals them up and if they exceed the specified threshold an Alert is generated:

529,  530, 531, 532, 533, 534, 535, 539, 548, 675, 676, 672, 644, 4625

(Please note that Event ID 672 is only included in this calculation when the Event Type is Failure Audit.)

This check is not intended to give you a forensic window into the cause of these alerts, but rather to inform you that the total count of these alerts exceed your specified threshold so you can take a closer look (However, you could use the Event Log and Critical Event checks to get a specific count of the above events for quick dashboard reference if you were so inclined). One of the common things to trigger a high number of events would be an application not having the correct security clearance to do a specified action, resulting in automated multiple failed attempts.

If you see your attempts averaging a certain number over the course of several days and can see the causes by tracing the event ID's listed above in your event log, you can probably increase your threshold in our dashboard so you are only alerted when the count exceeds this new average.

Want more information from the server agent about what's going on?  The IDs  in the Hacker Check are going to be critical errors in the Security Event Log.  Hmmm ... that sounds so familiar ... Oh, right!  There's a Daily Critical Events Check.

If you installed your agent recently by using the "Standard Checks" method, 3 of these were added to your monitoring set.  One each for the System Log, the Application Log, and the Security Log.  If you didn't add them this way, you can install as many of these checks as you have Event Logs (in the 'classic' sense, that is) on any given machine. 

By default these are placed in "Report Mode."  In this mode, you will receive no alerts or see red on the dashboard.  But, double-clicking the results of the check will tell you what Event ID's were discovered and how many times.   In the Security Log, the critical events will coincide with the instances of the Hacker check!  This will give you more insight into the issue on your machine at any given moment.  Then you can see what type of access is trying to be exploited:
  • "Fat-finger" logon error
  • ActiveSync device with a wrong password
  • Someone in the far reaches of the world using a port scanner and a brute-force dictionary attack at your FTP, HTTPS, or RDP port that's open on the firewall
  • Something else ...
From there the server logs themselves would have to be examined.