In this day and age, any organization with security on the forefront of their list of operational concerns needs to have an audit policy. Generally, this policy defines the types of log entries that will be monitored, the frequency with which those events will be monitored, and the action plan that will be undertaken in case any abnormal activity is detected after a thorough analysis of that audit trail. Luckily, the most recent versions of Windows give us a highly transparent view of the activity within a system; they indicate who is doing what and when all of these actions happened.
In this piece, I’ll brief you on the four key areas to watch out for in your event logs across your workstations and your overall domain as well as the rationale behind all of them.
1. Audit success and failure events in the system log
The idea here is to identify patterns of use over a normal period of time so that when a nefarious actor attempts to gain access to your system, you can detect his or her actions using a spreadsheet or other analysis software to identify patterns that are out of the norm. According to Microsoft, system success and failure events are generally low volume but tend to offer a high value in terms of the information they present, so these should be the cornerstone of any auditing and profiling scheme you may deploy.
2. Look for policy change success events on the domain controllers
These types of events indicate that someone on the system is attempting to alter the Local Security Authority (LSA) policy configuration. This is one way intruders could attempt to download a copy of the Active Directory database or plant malware in sensitive domain controllers. The frequency of these policy change success events should be rare enough to be indicative of nefarious activity. Unfortunately, it is typical to have many failure events on normal, completely unbreached systems, so the signal-to-noise ratio on monitoring failure events is usually too low to be worth the bother.
3. Look for success events in account management
These events are written when users are created, modified, or deleted and when groups are created, deleted, or have their memberships changed. A combination of success events is a good forensic to trace potential breaches of your directory back to where nefarious actors were able to create accounts or elevate existing accounts to a highly privileged state—for example, to a domain administrator.
4. Examine success events in the logon categories
Do it both on individual computers and on domain controllers. For individual workstations, this will give you a record of when users sign on and off their computers. (For member servers on a domain, there is no need to monitor success events, since those events will be covered by monitoring for success events on a domain controller.) You can easily trace a stolen password or other breach by examining the dates and times of successful logon events of the account in question.
Monitoring logon success events for domain controllers shows you when accounts sign on and off the domain. This information can be used in a similar fashion if you are working with the Active Directory. Of course, the larger the domain or number of users, the more legitimate success events will be written, so you will need to come up with a retention policy that defines when you can purge successful event data from your audit system so that it does not become overburdened with data.
