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 17-2 shows the most significant events in this category.

Table 17-2: Account Management Events

Event ID	When It’s Recorded
624	A new user account was created.
626	A user account was enabled.
627	Someone tried to change the password on an account.
628	The account password was changed.
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.

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.

• 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, MOM (Microsoft Operations Manager), or another tool that can integrate logs from multiple machines. The most significant events in this category are shown in Table 17-3.

Table 17-3: Events in the Account Logon Category

Event ID	When It’s Recorded
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 17-4 shows the pertinent events in this category.

Table 17-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.

As you can see from Table 17-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 529. 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 does the following:

• Attempts to escalate privileges The SeTcbPrivilege privilege indicates that the user account named attempted to (and might have succeeded in) gaining the “act as part of the operating system” right—once a user does so, he or she can run code that has complete system access. The only entries for this event should be for the LocalSystem account and any accounts to which you have explicitly granted it—usually service accounts of some type.

• Modifies the auditing and security log When you see event IDs 577 or 578 with the SeSecurityPrivilege privilege, the user is using the privilege to clear or modify the log.

• 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.