What to Audit and Why

Auditing is important because it allows you to correlate actions with specific times. A complete discussion of the specifics of auditing is beyond the scope of this book (the Security Operations Guide for Windows 2000 Server is a good place to get that level of detail, though). In this section, I discuss which events are interesting in each event category so that you can get a feel for what they ll tell you if you see them.

Account Management Events

Account management events happen when users or groups are created, deleted, or changed. Table 18-2 shows the most significant events in this category.

Table 18-2: Account Management Events

Event ID	When It s Recorded
624	A new user account was created.
626	A user account was enabled.
629	The specified account was disabled.
630	The specified account was deleted.
644	The specified account was locked out.
632	An account was added to a global security group .
633	An account was removed from a global security group.
636	An account was added to a domain local security group.
637	An account was removed from a domain local security group.
642	Properties of an account were changed. Enabling or disabling the account triggers this event, as does changing other account properties.

You can use these events to identify a variety of things, including these:

• Account creation attempts When a new account is created, you ll see event IDs 624 and 626.

• Password change attempts Event ID 627 is recorded before the password change is attempted, and event ID 628 is logged if the change was successful. Watch these events to ensure that every instance reflects a legitimate password change.

• Account status changes Event IDs 629 and 630 are logged when an account is disabled or deleted. It s particularly useful to look for event ID 626 followed by event ID 629, indicating that an account was enabled, used, and then disabled.

  Event ID 642 indicates that the account s properties (including its name, display name , or enabled/disabled status) were changed. This is usually valid, but not always.

• Group membership changes If you see event IDs indicating that accounts have been added to any of the administrative groups (Domain Admins, Enterprise Admins, local administrators, or custom groups to which you ve delegated permissions), that should be a warning flag.

Event ID 644 is logged only on the primary domain controller emulator for the domain; it indicates that the specified account was locked out. Any time you see this event, verify that the user in question knows that his or her account got locked out ”if the user didn t cause the lockout, you ve probably found an attack in progress.

Account Logon Events

These events are generated on domain controllers when an account is validated by the domain controller. Accordingly, watching these events tells you when someone has tried to log on with a particular account. However, because any domain controller in the domain can accept requests for that domain, tracking these events requires you to use EventCombMT, Microsoft Operations Manager, or another tool that can integrate logs from multiple machines. The most significant events in this category are shown in Table 18-3.

Table 18-3: Events in the Account Logon Category

Event ID	When It s Recorded
672	A Kerberos authentication ticket (TGT) was issued.
673	A Kerberos service ticket was issued.
674	A Kerberos ticket was renewed.
678	An account was mapped to a domain account.
680	The specified account logged on.
681	A domain logon was attempted.
682	A user reconnected to a disconnected Terminal Services session.
683	A user disconnected from a Terminal Services session without logging out.
677	A ticket-granting service ticket was not issued ”this indicates a logon failure.

You can use these events to diagnose logon failures, because each domain logon failure generates an event ID 677. (If logon failed because of time differences between the domain controller and workstation, you ll also see event ID 675.)

Logon Events

Logon events are generated when users log on or off a computer. If Alice logs on to a workstation using a local account, the event log shows only a logon event. If she logs on using domain credentials, the domain controller shows event ID 678, then the local machine shows a logon event. Table 18-4 shows the pertinent events in this category.

Table 18-4: Events in the Logon Category

Event ID	When It s Recorded
528	A user successfully logged on.
529	A logon attempt failed because of an unknown user name or a known user name with a bad password.
531	A logon attempt failed because the account was disabled.
532	The logon attempt failed because the account has expired .
533	The logon attempt failed because the user doesn t have permission to log on to this computer.
534	The user tried to log on with a logon type that s not allowed for the account.
535	The logon attempt failed because the password has expired.
538	The user logged off.
536	Logon failed because the NetLogon service isn t available.
537	An unexpected failure occurred during the logon process.
539	Logon failed because the account is locked out.
540	Logon succeeded.

As you can see from Table 18-4, each of the failure types is pretty easy to understand. However, the key to identifying attacks using these events is to look for patterns. A single user might generate a few 529 errors in a row if he or she has forgotten a password, but a sequence of these errors at a time when the user wouldn t normally be logging on (say, 3 A.M.) might indicate that someone is up to no good.

Tip  

If you see event ID 539 for an account, check back and you ll find a skein of 529s. That should give an indication of when the account lockout occurred.

Privilege Use

The privilege use events indicate that the set of privileges associated with the user has changed. Event ID 576 indicates that privileges were added (you ll see this at logon time); event ID 577 indicates that the user tried to use a privilege, and event ID 578 indicates that the privileges were used to do something. The privileges that can be granted span a wide range of capabilities; the most interesting ones indicate when a user takes ownership of an object. In this case, look for event IDs 577 and 578 with the SeTakeOwnershipPrivilege privilege listed. This generally indicates that an attacker is trying to cover up his or her tracks, but it also occurs when a legitimate administrator takes ownership of files or folders.