Interpreting the NT Security Log

Use the Security Log to track users' actions

In "Introducing the NT Security Log," March 2000, I explained the Security Log in general terms and gave you some tips about how to configure the log to preserve valuable audit trails. You also need to understand the three most important security events auditing categories: logon and logoff, object access, and process tracking. These three categories provide crucial information that you can use to track users' actions. Each system has an audit policy that you access from the Start Menu's Programs, Administrative Tools, User Manager, Policies, Audit, Audit Policy dialog box, which Screen 1, page 86, shows. The Audit Policy dialog box dictates which of seven categories of audit events the local Security Log will record.

Logon and Logoff
Logon and logoff are key events that many administrators consult the Security Log to view, but interpreting this seemingly simple category of audit events can be difficult. First, let's look at the various characteristics of logon events. Successful logons have event ID 528, which Figure 1 shows. No failed logons have event ID 528; rather, failed logons have event IDs that identify the reason for the failure. (For a complete list of security event descriptions, see the Microsoft article "Security Event Descriptions" at http://support.microsoft.com/support/ kb/articles/q174/0/74.asp.) Event ID 538 denotes event ID 528's corresponding logoff event. Event ID 528 provides several important pieces of information in the description field of the event record. User Name and Domain specify which user logged on or the account that the user employed. Logon ID is an ID code that is unique to the system and identifies the logon session. You can use the Logon ID to find the corresponding logoff events. You can use a logon event, event ID 528, and its corresponding logoff event, event ID 538, to determine the duration of a user session.

The logon event description also shows the Logon Type, which identifies how the user logged on. When a user logs on at the local console (i.e., keyboard and monitor), the Logon Type is type 2, which is an interactive logon. When a user on a workstation maps a drive or otherwise connects to another network computer, the user performs a type 3 logon, which is a network logon. Therefore, when you see event ID 528, type 2, you know someone logged on at the local console of that computer, and when you see type 3, you know someone connected to that system from the network. When a service starts under its specified user account, Windows NT records a type 5 logon, which is a service logon. If you use a third-party batch queue facility, such as Argent Software's Argent Queue Manager, the batch scheduler runs your batch jobs under the specified account and NT records event ID 528 with a type 4 logon, which is a batch job logon. You'll also see event ID 528 and event ID 538 with a type 7 logon when someone unlocks a workstation.

Logons can fail for several reasons. What happens when logons fail? Most frequently, you see the Logon Failure explanation Unknown user name or bad password, which is event ID 529. If a user has a disabled account or an account lockout, the user's logon fails and the system logs event ID 531 and event ID 539, respectively. Event ID 530 shows that a user tried to log on outside the allowed time of day or day of week periods specified for that user account. If an account has reached its account expiration date or if a user's password expired, the system logs event ID 532 or event ID 535, respectively. If you select the User May Log On To These Workstations option in the Logon Workstations dialog box, which Screen 2 shows, to restrict a user to certain workstations and the user tries to violate this restriction, NT records event ID 533. You can use rights to restrict users to certain types of logons for certain systems. If a user doesn't have rights to access a certain computer from the network and the user tries to map a drive to that system or view the Registry, the logon will fail and the system will log event ID 534. Event ID 534 also occurs when a user tries to log on at the console and doesn't have rights to log on locally. Services that attempt to start by using an account without the Logon as a service advanced rights trigger event ID 534. Processes that use an account without Logon as a batch job advanced rights to try to log on as a batch job also trigger event ID 534. If a logon fails for some other reason, you'll see event ID 537 with the Logon Failure explanation An unexpected error occurred during logon. These failed logon events also provide Logon Type information. For more information about performing audits of logons, see the Microsoft article "Auditing User Authentication" at http://support.microsoft.com/support/ kb/articles/q174/0/73.asp.

In "Introducing the NT Security Log," I explained the distributed nature of NT logging. Nowhere does this distribution affect you more than with logon and logoff. People often refer to the act of logging on to a workstation with a domain account as "logging on to the domain," but at no time do you log on to the domain, nor do you log on to the domain controller when you use a domain account. Your workstation logon means that you're logging on to the workstation. Because you're using a domain account, the workstation can't authenticate you. Therefore, the workstation uses the NT LAN Manager (NTLM) network authentication protocol to forward your credentials to the domain controller. (For more information about the NTLM protocol, see "Inside SP4 NTLMv2 Security Enhancements," September 1999.) After verifying that your password is correct, the domain controller forgets about you. The workstation maintains your logon session until you log off. Consequently, the workstation's Security Log records interactive logons.

How do you get a picture of your domain's overall logon activity without looking at the Security Log of every workstation? Usually, a user's logon script performs standard drive mappings to file servers immediately upon logon, so many administrators examine their file-server Security Logs for events with a type 3 logon. Because no central record of logon activity for the domain exists, monitoring intrusion attempts is difficult. However, some help is available. Although domain controllers don't record all failed logons, they record all account lockouts, event ID 644, that are the result of several failed logons in close proximity. For more information about account lockout events, see the Microsoft article "Account Lockout Event also Stored in Security Event Log on Domain Controller" at http://support.microsoft.com/support/kb/articles/q182/9/18.asp.

Local accounts also create the need for you to monitor logon activity on individual systems. Although each workstation and server belongs to a domain and primarily relies on the domain controllers for authentication, each workstation and member server also maintains a local SAM. Users and intruders can use local accounts to try to log on locally or connect over the network. The built-in Administrator account is always present and available for logon. For tips about protecting this account, see "Protect Administrator Privileges," February 2000.

You can effectively monitor logons and logoffs if you know what to look for and where to look. To track logon activity, look (primarily on servers and workstations rather than domain controllers) for logons with event ID 528 and the corresponding logoffs with event ID 538. To watch for possible intrusion attempts, look for events that range from event ID 529 to 537 and event ID 539 on each vulnerable system.

Object Access
The object access category has only three events but is very powerful because it lets you monitor access to any object in your system, including directories, files, printers, and Registry keys. In User Manager, you must enable object access auditing for the system and each object you want to monitor. You specify an object's audit control list similarly to the way you specify an object's ACL. The object's audit control list specifies the users and the types of access that you want to track.

Object access auditing uses an event log instead of a transaction log. Therefore, NT doesn't tell you what the user did to the object but rather the type of access the user employed to open the object. For example, you can see an event that shows John opened salary.xls for Read, Write, Execute, and Delete access, but the event doesn't tell you whether John changed the file and what changes he made. Another caveat when auditing object access is that one user action can result in many events in the Security Log. For example, selecting a text file with Windows Explorer and double-clicking the file to view it in WordPad produces more than 20 events when you audit all access for that file and its parent directory.

Object auditing is most useful with conventional applications that directly use individual files, such as Microsoft Office applications. Other client/server applications, such as SAP, store all their data tables in a few large Microsoft SQL Server database files. If you enable auditing for these files, you ordinarily see objects open and close when the database server starts and stops. You can't determine which user is executing transactions or making modifications or which tables he or she is modifying. You have to rely on the application to provide that information. However, one reason to audit those monolithic database server files is to catch someone modifying them outside of the application. With most database servers, including SQL Server, you can shut down the service, replace the database files with a different version, and start the service again without the database server detecting the action. You might catch tampering of this nature with object access auditing.

The two main events of object access are object opened, event ID 560, and handle closed, event ID 562. These two events are complementary, similarly to the logon and logoff events. Successful event ID 560 events, which Figure 2, page 90, shows, display the opened object, the user who opened the object, the program the user employed, and the user's level of access. Before a program can access an object, the program must open the object, specify the type of access, and obtain a Handle ID. A Handle ID is a number that the OS uses to track open objects. The Handle ID is similar to the Logon ID. You can use the Handle ID to link an opened object event (event ID 560) to its corresponding handle closed event (event ID 562) to determine the length of time the user had the object open. The Handle ID also shows up in the event description, which Figure 2 shows, so you can identify the logon session the user accessed the object in.

The event description specifies two users: primary and client. If you use a conventional application (e.g., Microsoft Word) to open a file on your local system, the primary user information is the only relevant item. However, if you access an object through a client/server application that uses OS-level impersonation, the primary user information identifies the user account of the server application, and the client user information reflects the user on whose behalf the server is acting. A common example of this scenario is NT's handling of file sharing. When you access a file on a computer across the network through a shared directory, your local Workstation service connects to the Server service on the other system and initiates a type 3 logon. Before processing any request, the server impersonates the remote user and causes object access events to record both primary and client user information. In this case, the Primary User Name is SYSTEM, which is the account the Server service runs under. The Client User Name matches whomever the client connected to the file server as and is ordinarily that user's domain account.

The Accesses field in event ID 560's description tells you which type or types of access the user employed to open the object. The values for the access types correspond to low-level permissions in ACLs. For example, when I change a text file with WordPad, NT logs event ID 560 with accesses such as ReadData, WriteData, and AppendData.

A final piece of important information in event ID 560's description is the Process ID. You can use the Process ID to determine the program that the user accessed the file with. You can link the Process ID to other events, which I discuss later, to determine whether a user used Word, WordPad, or Notepad to change a file. However, the Process ID is useful only when the accessed object is on the same system as the user accessing the object. Otherwise, such as in the case of a file-server scenario, the Process ID will correspond to the server application and doesn't reveal much information.

The other important event in the object access category is object deleted, event ID 564. Event ID 564 specifies only the Handle ID and Process ID. To determine the user and the object the user deleted, you must use the Handle ID to link the object deletion event (event ID 564) to the corresponding object opened event (event ID 560). The object opened event tells you which user opened the object with delete access, and the corresponding object deleted event confirms that the user deleted the object.

Object access auditing is powerful but can be laborious and has the potential to slow down your system performance depending on how many objects you audit and how heavy activity is on those objects. I recommend that you use object access auditing sparingly. Aside from protecting highly important resources, security personnel often use object access auditing to build evidence when they suspect a user is tampering with data. I've also seen administrators enable object auditing on decoy files, such as a dummy salary.xls file, to catch would-be perpetrators. However, you need to consider proprietary concerns before you use this approach. Don't forget that you need to enable object auditing in User Manager on the system in which the objects in question reside to log access events—not necessarily on the user's local workstation.

Process Tracking
User Manager uses the term process tracking, but NT Event Viewer and NT documentation commonly refer to this category as detailed tracking. This category lets you track which programs a user is running on a workstation and which programs the server is using. Like the other categories, this category specifies two main events: creating a new process, event ID 592, and exiting a process, event ID 593. You can use the Process ID field common to both events to link the process creation (event ID 592) to its corresponding exit (event ID 593) and determine how long the program ran. The Image File Name field tells you which executable file the user opened. For example, if you run WordPad, you'll see WORDPAD.EXE in the Image File Name field, as Figure 3 shows. Unfortunately, you don't know which program ran because the field doesn't include the directory path. The User Name field specifies who ran the program, and you can link the Logon ID in event ID 592's description to the corresponding logon (event ID 528) to determine in which logon session the program ran. In unusual situations in which you want to discover which program is running another program, you can link the Creator Process ID to its corresponding process start (event ID 592).

Process tracking can be very useful on workstations, especially when you're investigating a user's activity. Process tracking combined with object access auditing on servers will give you a clear picture of a user's actions.

Logon and logoff, object access, and process tracking are three important categories of the Security Log. You can link logon sessions, processes, and object accesses to closely track a user's activity, as Figure 4 shows. Unfortunately, Event Viewer can't filter based on values in the description field; consequently, using the Logon ID, Process ID, or Handle ID to link events is laborious. However, the Event Viewer's Find dialog box lets you search the description field, which can help you link events in a pinch. You can also use event-log utilities to help you with problems such as filtering the Security Log.

When choosing your audit policy for these categories of the Security Log, keep in mind how computer roles (e.g., workstation, server, domain controller) determine which log the system records the events in. Be careful with object access and process tracking because these two security categories are the most likely to cause performance problems. In my next article in this series, I'll discuss more categories, such as account management, policy change, privilege use, and system events.

[Editor's Note: Email the author information about your favorite event-log tools (preferably shareware), and he'll put together a tour of the best tools that administrators are using. Also, send him your tips about how to get the most out of your NT Security Log.]