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.
Prev. page
[1]
2
next page 
