Monitoring Important Security Events

You can find a wealth of information in your Windows 2000 computers' Security logs. The Security logs can provide vital information about logon activity, important system-level events, account management, and file-access events—information that, if you know how to find it, can help you detect suspicious activity and audit crucial administrative tasks. Effective event-log sleuthing includes looking not only for particular event IDs but also for workstation or server types so that you can correctly interpret certain event IDs and codes within the event details. Codes within events can imply different situations depending on whether the event occurred on a workstation, server, or domain controller (DC). In addition, Microsoft changed some event IDs between the releases of Windows Server 2003 and Windows XP and the release of Win2K.

Logon Activity
Monitoring logon attempts is a good way to detect attacks and suspicious activity. Win2K provides two audit-policy categories: Audit logon events and Audit account logon events. These categories can be confusing. Audit logon events generates logon events on the local system on which the logon occurs, whereas Audit account logon events generates events when someone tries to authenticate with an account that's stored on the computer on which the logon event is recorded. Win2K tracks both domain account logons and local SAM account logons. When someone logs on to your workstation with a domain account, that person is not only logging on to your workstation but is also authenticating using an account that's stored on the DC. Therefore, Audit logon events will generate events in your workstation's Security log, and Audit account logon events will generate events on the DC's Security log. Within seconds of someone logging on to your workstation, Audit logon events will generate events on the DC because your workstation will log on as you to the DC to apply user-level Group Policy. Audit logon events will also generate events on member servers because your workstation, as it processes your logon script and persistent drive mappings, will log on as you to various member servers so that it can map drives to shared folders. Similarly, Audit logon events will generate events on a server when someone logs on to the server console or accesses the server over the network by using either a domain account or a local account in the server's SAM. But you'll see Audit account logon events activity only when someone logs on to the server (interactively or over the network) by using a local account in the server's SAM, rather than using a domain account.

When you examine events that Audit logon events generates on DCs, remember that the events reflect interactive logons to the DC as well as logons that occur over the network. Member computers in the domain regularly access DCs to refresh Group Policy, both as the computer account and as the user currently logged on. Examining events that Audit account logon events generates on your DCs will reveal every attempt to log on with a domain account from any computer on the network, including workstation logons, connections to member servers, and logons and connections to the DC itself.

Monitoring Logon Failures
Because logon failures that are due to invalid passwords can signify that an imposter is trying to guess a user's password, tracking those failures is extremely important. To track invalid password logon failures for domain accounts, monitor all your Win2K DC Security logs for event ID 675 (Pre-authentication failed) with failure code 0x18 and for event ID 681 (The logon to account: %2 by: %1 from workstation: %3 failed. The error code was: %4) with error code 3221225578. On Windows 2003 DCs, don't look for event ID 681. In XP and later, Microsoft replaced event ID 681 with event ID 680. Win2K used event ID 680 only to report successful authentications. With XP and later OSs, event ID 680 can mean successful or failed authentication as indicated by event types Failure Audit or Success Audit.

You'll find the failure or error code in the event's description. The DC logs event ID 675 when Kerberos authentication fails and a failed event ID 680 or event ID 681 when Windows NT LAN Manager (NTLM) authentication fails. A failed event ID 680 or event ID 681 signifies that at least one of the computers involved in the logon is a pre-Win2K computer or a computer from an untrusted domain. The pre-Win2K computer can be a workstation or a member server (e.g., a user at a Win2K workstation connecting to a pre-Win2K member server with a domain account). You can identify the workstation by looking for the client IP address in event ID 675 or the workstation name in event ID 680 or event ID 681.

Other types of logon failures generate event ID 676 (Authentication Ticket Request Failed) for Kerberos authentication, but for NTLM authentication, Windows 2003 and XP continue to use event ID 680 with the Failure Audit event type and Win2K continues to use event ID 681. These logon failures include invalid usernames, account or password expiration, and prohibited times of the day (i.e., someone tries to log on when he or she isn't allowed to log on). To identify the reason for the authentication failure, look at the failure code for event ID 676, which Figure 1 shows, and at the error code for event ID 681, which Figure 2 shows. Notice that event ID 676's failure code isn't as specific as event ID 681's error code. Event ID 676's failure code corresponds to the failure code that the Kerberos protocol specifies.

If you're in the habit of renaming the Administrator group to obscure it from attackers, look for event ID 680 with error code 3221225572 and event ID 676 with failure code 6 and Administrator as the username. On Win2K, look for event ID 681. On Windows 2003 and XP, however, look for event ID 680 with event type Failure Audit. Microsoft replaced event ID 681 with event ID 680 flagged as failure. These events specify logon failure as a result of a invalid username for NTLM and Kerberos, respectively. Table 1 lists authentication failure and error codes.

Monitoring event ID 675 and event ID 676 as well as failed event ID 680 or failed event ID 681 on your DCs will give you a complete picture of all domain-account logon failures but won't detect logon attempts to member servers using local SAM accounts. Attackers often use local accounts to try to gain access to computers because local accounts are more difficult to monitor and control and often have weak passwords. To monitor such activity, enable Audit account logon events on your member servers and watch for event ID 681, which signifies that someone tried to log on to the server by using the specified local account. Member servers never log Kerberos events because local SAM accounts always use NTLM authentication. Make sure your administrators follow best practices and avoid using local accounts in lieu of domain accounts. Then, monitor successful local SAM-account logons to your servers (event ID 681). If your administrators avoid using local SAM accounts in lieu of domain accounts, you should regard any Audit account logon events activity on member servers as suspicious.

You might consider disabling the Audit logon events category on member servers because it generates events both for local SAM and domain-account logons without distinguishing between them and is largely redundant to Audit account logon events. The only value of enabling Audit logon events on member servers is that it lets you distinguish between interactive logons and connections from users elsewhere on the network.

If you want to track all logons from the server console, check for event ID 528 (Successful Logon) with logon type 2 and failed Audit logon events attempts with logon type 2. To track connections to a computer by a user elsewhere on the network, look for event ID 540 (Successful Network Logon), which signifies a network logon. Audit logon events also lets you determine how long the user was logged on. Note the logon ID, which you can find in the description of event ID 540 or event ID 528. Then look for event ID 538 (User Logoff) with the same logon ID. By using the same logon ID to tie the logon event (event ID 540 or event ID 528) to the logoff event (event ID 538), you can determine how long the session lasted.

If your account-lockout policy is set to automatically unlock accounts after a specified time period, you won't be able to detect lockouts as a result of users calling in to reset their passwords unless you check your logs for event ID 644 (User Account Locked Out). On DCs, event ID 644 signifies that a domain account was locked out; on member servers, it signifies that a local SAM account was locked out. This event is part of the Audit account management category, not the logon categories. You might want to monitor logons to servers and domains during unusual hours, which might identify suspicious activity (or just that someone is working long hours).

Important System Events
The Win2K Security log identifies several major system events that help you identify physical-access attacks and recognize abuse of administrator authority (for a list of important security events, see Table 2). Whenever someone clears the Security log, Win2K logs event ID 517 (The audit log was cleared) regardless of how the computer's audit policy is configured. This process can help you identify the person who cleared the Security log. If Audit system events is enabled, Win2K logs event ID 512 (Windows NT is starting up) when the system reboots. Reboots are important to security because Win2K systems are highly vulnerable to physical-access attacks while the OS is down. You might be able to compare event ID 512 with other information you might have, such as server-room entry and exit logs, to determine who was present when the server rebooted. If you enable Audit policy changes, Win2K will log event ID 612 (Audit Policy Change) when the computer's audit policy is changed. Event ID 612 records exactly which categories were enabled and disabled.

Incorrect changes to a system's time can wreak havoc on applications. To change the system's time, users must have the Change system time user right, which you can track by enabling Audit privilege use. Then, monitor for any occurrence of event ID 577 (Privileged Service Called) that specifies SeSystemTimePrivilege in its description.

Account Management
The Audit account management category lets you audit how administrators use their authority and monitor when they grant new access. On DCs, watch for event ID 642 (User Account Changed), which lets you monitor user-account-status changes or password changes. Because this event ID covers almost all types of user account changes, read the description to determine which changes were made on the user account. As Figure 3 shows, event ID 642's description clearly states the type of change, such as password reset or account enabled.

Event ID 624 (User Account Created) lets you keep track of new domain user accounts on DCs, but I recommend that you also monitor member servers for this event. Local SAM accounts are usually undesirable for security reasons because local SAM accounts aren't subject to the centralized controls and monitoring of domain accounts, and event ID 624 will help you keep a handle on local SAM accounts as well as detect intruder-created backdoor accounts.

Monitoring for new-member additions to a group is also important. On DCs, watch for event ID 632 (Security Enabled Global Group Member Added), event ID 636 (Security Enabled Local Group Member Added), and event ID 660 (Security Enabled Universal Group Member Added) to identify when new members are added to groups. Because SAMs allow only local groups, you can monitor just for event ID 636 on member servers. All three event IDs specify the group, new member, and user who made the change. As Figure 4 shows, event ID 632 reveals that user rsmith added Guest to the global group Domain Admins. If you want to detect unauthorized computers, use event ID 645 (Computer Account Created) to monitor when new computers are added to the domain.

File Access
The Audit object access category lets you track all types of access to files, folders, and other objects, such as printers and registry subkeys. Enabling this category will initially generate limited security events that are related to SAM maintenance. As soon as you enable this audit category, you'll see some object-access events in the Security log, even though you haven't specifically enabled auditing on any objects. To audit a file or folder, locate the file or folder in Windows Explorer and open its Properties page. Select the Security tab and click Advanced. In the Access Control Settings window, select the Auditing tab, as Figure 5 shows. Initially, the auditing entries list will be empty. Click Add, select a user or group whose access you want to audit, then click OK to open the Auditing Entry window. You can add any combination of users or groups, but I recommend simply using Everyone. Select the types of access you want to audit, then click OK.

Be careful not to turn on auditing for all types of access, especially successful read access. Too wide an audit policy can generate a crippling number of security events that will slow your system to a crawl and fill your log with useless noise. For the same reason, limit the number of folders for which you enable auditing. For example, enabling auditing on the system drive root for all types of access is a recipe for disaster.

Depending on the type of information you're trying to protect, you might want to detect unauthorized attempts to read a file or track anyone who might have changed a file. To detect unauthorized read attempts, enable auditing for failed Read data attempts. To detect file changes, enable auditing for successful Write data and Append data attempts. Be aware, however, that Win2K audits only potential changes. For example, if Bob opens a Microsoft Word document for write access but immediately closes the file without making any changes, Win2K will log only the fact that Bob successfully opened the file for write access. Windows 2003 solves this problem by recording a specific event the first time a user actually writes to an open file. You can also detect when an administrator changes file permissions by monitoring successful Change permission attempts. When a user accesses a file by using a type of access that you've enabled for auditing, Win2K generates event ID 560 (Object Open), which identifies the user, file, and type of access granted or denied. For example, the error code that Figure 6 shows signifies that Bob tried to open a file for read access when he didn't have access to that file. You can deduce that he didn't have access because the event is a failed object-access event. You know he tried to open the file for read access because ReadData is listed under Accesses.

Scanning Logs
The events described in this article constitute the most important and easily recognized security events in Win2K security logs. Win2K uses the Microsoft Management Console (MMC) Event Viewer snap-in to provide minimal functionality for scanning logs for the specific events you enter. You can use the Event Viewer snap-in to filter by event ID and other types of information. Select the Security log in Event Viewer, right-click, and select View, Filter.

Event Viewer doesn't let you filter events based on values in the event descriptions (e.g., logon ID or other codes), which is unfortunate because the description contains much of the information that you need to identify important events. However, Event Viewer does provide a way to scan filtered events for values in the description. After you set up the filter, right-click the Security log again and select View, Find. You can find events based on several fields, including the description. The Find Next button lets you find one event at a time. Another quick and dirty way to scan a log is to save it to a tab-delimited text file, then open the file with Microsoft Excel. However, both these methods let you scan only one log at a time, which isn't helpful if you have to monitor multiple systems.

Third-Party Tools
Some third-party tools, such as GFI LANguard Security Event Log Monitor, Symantec Intruder Alert, and Adiscon's EventReporter, can merge logs from multiple computers into one database and provide aggregated reports and alerts. Alternatively, you might try using SystemTools.com's free DumpEvt utility to build your own solution. DumpEvt comes with a Microsoft Access database template that can import events from many different computers. You can then use the database to design your own reports to monitor your network.