Win2K Security Log Roundup

Audit process tracking and several other audit categories complete your arsenal

When you're tracking an attacker's movements through your network, information about which programs the intruder has run can be a valuable clue to his or her activity. Other leads might include changes to rights and policies. Unauthorized system reboots might also be a sign of trouble.

You can use Windows 2000's simple Audit process tracking category to monitor program execution. The OS's Audit privilege use, Audit policy change, and Audit system events categories can also prove useful. Alongside the other auditing categories that I present in this series of articles about the Win2K Security log, these events can help you piece together the details of an attacker's attempts to violate your network's integrity. (For a list of the previous articles in this series as well as related articles about the Windows NT Security log, see "Related Articles in Previous Issues," page 68.)

Audit Process Tracking
Audit process tracking doesn't track failed events, but when you enable the category to audit for success, it supplies two events: event ID 592 (a new process has been created) and event ID 593 (a process has exited). The Microsoft Management Console (MMC) Event Viewer snap-in's Category column lists the Audit process tracking category as Detailed Tracking. (For information about how to enable auditing categories, how to configure a system's Security log, and how to use the Event Viewer snap-in to review the Security log, see "Tracking Logon and Logoff Activity in Win2K," February 2001.)

When a user starts an executable such as Microsoft Excel, Win2K logs event ID 592. This event tells you which program the user started and when. Figure 1 shows a sample event; the Time, User, and Image File Name fields indicate that Billy started Excel at 5:51 p.m. Notice that Win2K logs the full path of the executable—a nice enhancement over NT, which logs only the base filename.

The Logon ID field corresponds to the logon ID that Win2K assigned Billy when he logged on to the system. This ID lets you connect the process-creation event with the original successful logon event ID 528. (For a quick reference of the Security log events that I discuss in this series, see Table 1. For a detailed explanation of logon events, see "Tracking Logon and Logoff Activity in Win2K.")

When Win2K starts a new process, the OS assigns the process a number, called a Process ID, that is unique for the lifetime of the process. Event ID 592 displays this number in the New Process ID field. After a user starts an application, the user's next step is usually to open a file in that application. In "Keeping Tabs on Object Access," June 2001, I explain that event ID 560's description also includes the Process ID field and that you should be able to use this ID to identify related event ID 560 and event ID 592 occurrences. However, Win2K doesn't log the same process ID in event ID 592 that it logs in event ID 560 or in any other event. Event ID 592 displays the process ID as a 10-digit number, whereas the other events (and Task Manager's Processes tab) display the process ID as a 3- or 4-digit number. (I've heard that Microsoft has fixed this discrepancy in Windows 2002 and Windows XP—formerly code-named Whistler.)

You can use event ID 592's Creator Process ID field to identify the process (if any) that started the new process. Simply look for a previous event ID 592 with a Process ID that matches the selected occurrence's Creator Process ID. (Event ID 592 uses the 10-digit format for both fields.)

Event Viewer doesn't provide a filter to sort Security log events by logon ID or process ID, but you can search events for a particular ID. To find event occurrences that include a specific ID, open the Event Viewer snap-in, right-click the Security log, and select View, Find. Type the ID in the Description field, and click Find Next.

When a user closes an application, Win2K logs event ID 593. Event ID 593 includes a Process ID field, but as I explained earlier, this ID doesn't match the process ID in the corresponding event ID 592 occurrence that Win2K logged when the user opened the application.

Process ID­matching problems aside, linking process-tracking, object-access, and logon events—to document when a user logged on, what applications the user opened, and which files and other objects the user accessed with each application—can be a complicated process. Linking these events is easy when you're in a standalone workstation environment in which the user logs on, runs applications, and accesses files on only one system. In the real world of networks and file servers, though, the situation isn't quite so simple. Win2K logs process-tracking events on the computer on which the application executed (i.e., the user's local workstation) but logs object-access events on the computer on which the object resides. (For example, when a user opens a file across the network on a file server called FS1, the Server service on FS1 opens the file on the user's behalf.) Therefore, you can't directly identify which applications a user employed to open files that reside on a remote file server.

For example, suppose a user logs on to a workstation, opens Excel, and edits a spreadsheet that resides on a file server. Win2K logs event ID 592 in the workstation's Security log and logs event ID 560 in the server's Security log. The process IDs in these two event occurrences won't correspond (and wouldn't even if Win2K used the same process ID for both events). Instead, you must look for an event ID 592 occurrence in the workstation's Security log that overlaps with an event ID 560 occurrence in the server's Security log.

Enabling the Audit process tracking category on a server won't shed much light on the applications that execute at users' workstations. However, the category's events can help you track the use of server-side programs, such as Microsoft SQL Server or Microsoft Exchange Server, and any programs that administrators and operators execute while logged on interactively. Be aware that enabling this category on a server can place a load on the server's resources, so carefully monitor effects on performance.

Tracking logons and the utilization of processes and objects can help you monitor a suspected attacker's actions. You should also monitor the attempted use of user rights, which can alert you to suspicious behavior before an attacker can do damage. Win2K's Audit privilege use category keeps tabs on this type of action.

Audit Privilege Use
The Audit privilege use category tracks successful and failed attempts to exercise user rights. (Microsoft articles and Win2K documentation are inconsistent and use the terms privileges and rights interchangeably.) More than 34 rights exist, ranging from powerful rights such as Act as part of the operating system to rather innocuous rights such as Bypass traverse checking. When you enable Audit privilege use, the Security log begins to register three events: event ID 577 (privileged service called), event ID 578 (privileged object operation), and event ID 576 (special privileges assigned to new logon).

When a user attempts to invoke a right, Win2K logs either event ID 577 or event ID 578, depending on the right. (Win2K monitors some internal rights on a service basis and others on an object basis.) In both events, the Privileges field specifies which right the user invoked. Win2K logs the right's short name, which always begins with Se and ends with Privilege. However, Win2K doesn't display these short names when you edit rights assignments in the MMC Group Policy Editor (GPE) snap-in. Instead, the snap-in displays rights' full descriptions. (For example, Figure 2 shows an event ID 577 occurrence that Win2K logged when I changed the time on my computer. The event's SeSystemtimePrivilege right corresponds to the Change the system time right in GPE.)

When Win2K permits a user to invoke a right, the OS logs event ID 577 or event ID 578 as a success. If a user tries to exercise a right that hasn't been assigned to him or her, Win2K logs the event as failed. For some rights, the Primary User Name and Primary Domain fields identify the user who invoked the event. For rights that a server process invokes, however, these fields correspond to the local system's computer account. You can recognize such rights because the Primary User Name field is the same as the Computer field, followed by a dollar sign ($).

In such cases, you must look at the Client User Name and Client Domain fields to determine which user invoked the right. The Primary Logon ID and Client Logon ID fields correspond to the Logon ID field in the event ID 528 or event ID 540 occurrence that Win2K recorded when the user logged on.

Event ID 578's Process ID field identifies the process that directly invoked the event. For example, when you view the Security log, the Services process invokes the SeSecurityPrivilege (i.e., Manage auditing and security log) right on your behalf. The corresponding event ID 578's process ID belongs to the Services process.

Because the Audit logon events category contains specific event IDs for tracking logon activity, Win2K doesn't record successful or failed logon rights by default. (These rights—with the exception of Access this computer from the network and Deny access to this computer from the network—begin with the words Logon as or Deny logon.) Neither does Win2K log a few other rights—such as SeBackupPrivilege (i.e., Backup files and directories) or SeRestorePrivilege (i.e., Restore files and directories)—that are invoked so frequently that they would quickly fill up the Security log. To enable auditing for these rights, you can make a registry change in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa: Set the FullPrivilegeAuditing subkey, which is a REG_DWORD value, by setting the value to 1.

Win2K never logs the use of the SeAuditPrivilege (i.e., Generate security audits), SeCreateTokenPrivilege (i.e., Create a token object), SeDebugPrivilege (i.e., Debug programs), SeChangeNotifyPrivilege (i.e., Bypass traverse checking), or SeAssignPrimaryTokenPrivilege (i.e., Replace a process level token) rights. However, when a user with one or more of these rights logs on, Win2K records event ID 576 (special privileges assigned to new logon—this event usually closely follows a successful logon event ID 528 or event ID 540). To determine which rights a user had at the time the user logged on, look at event ID 576's Logon ID field, which identifies the user, and the Assigned field, which lists the rights' short names.

Audit Policy Change
Whereas the Audit privilege use category lets you audit who is using which rights and when, the Audit policy change category lets you track administrators' changes to rights assignments. The category lets you monitor several types of policy changes.

First, Audit policy change lets you know when rights assignments change. When an administrator grants someone a right, Win2K logs event ID 608 (user right assigned). The event's User Right field lists the short names of the assigned right or rights. The Assigned To field identifies the user or group to which the administrator assigned the right or rights. Figure 3 shows the event ID 608 occurrence that Win2K logged when I assigned the SeCreateTokenPrivilege (i.e., Create a token object) and SeCreatePermanentPrivilege (i.e., Create permanent shared objects) rights to the Administrators group.

The User Name, Domain, and Logon ID fields under Assigned By ostensibly identify who changed the rights assignment. But whereas NT administrators assign rights directly through User Manager, Win2K administrators grant or revoke rights indirectly through Group Policy Objects (GPOs). Because of this difference and because a user's local system reads Group Policy and makes the associated rights assignment changes, event ID 608 lists the user's local computer account as the Assigned By user. To get a clue to which administrator changed the rights assignments, you must enable the Audit directory service access category to audit changes to GPOs in Active Directory (AD—for information about how to audit such changes, see "Mining the Win2K Security Log," April 2001).

When you revoke a user right, Win2K logs event ID 609 (user right removed) the next time Win2K applies Group Policy. This event's User Right field is similar to the User Right field in event ID 608. The Removed From field specifies the users or groups who lost the right or rights. The User Name, Domain, and Logon ID fields under Removed By specify the local computer account, just as event ID 608's Assigned By fields do. Win2K logs both events on the computers on which Win2K applies the GPO that contains the rights assignments, but the OS logs changes to GPOs on the domain controller (DC) to which an administrator connected when he or she edited the GPO.

Audit policy change also lets you track changes to trusted relationships with other domains. When an administrator uses the MMC Active Directory Domains and Trusts snap-in to add a new trusted domain, Win2K logs two identical occurrences of event ID 610 (new trusted domain) on the DC to which the administrator connected. Event ID 610's Domain Name field identifies the newly trusted domain. To find out who added the trust relationship, look at the User Name, Domain, and Logon ID fields under Established By.

Win2K also logs one occurrence of event ID 620 (trusted domain information modified) on the DC. However, this event doesn't supply any additional information. When you remove a trusted domain, Win2K logs two occurrences of event ID 611 (removing trusted domain). This event includes the same fields as event ID 610, except that the User Name, Domain, and Logon ID fields fall under the heading Removed By rather than Established By.

Event ID 610, event ID 611, and event ID 620 expose another bug in Win2K auditing: Win2K logs these events when you add or remove a trusting relationship as well as when you add or remove a trusted relationship. The events tell you only that a trust relationship was added or removed—not whether the specified domain is trusted or trusting.

Win2K logs event ID 612 (audit policy change) whenever Group Policy application results in a change to a computer's audit policy. The event's New Policy field specifies which audit categories were enabled for success or failure. (For example, Figure 4 shows that I enabled auditing for successful and failed policy changes.) As in event ID 608, event ID 612's User Name, Domain Name, and Logon ID fields under Changed By don't specify which administrator changed the audit policy because Win2K doesn't detect changes until Group Policy is actually applied. Still, event ID 612 is useful for catching changes to audit policy.

You can also use the Audit policy change category to monitor several other policy changes. Event ID 617 signals a change to the Kerberos policy, which controls ticket lifetimes and renewal. (Win2K doesn't limit event ID 617 to explicit administrator changes to the Kerberos policy but logs the event each time a DC applies Group Policy.) When you change Group Policy's Encrypted Data Recovery Agents section, which controls who can decrypt files that are encrypted with the Encrypting File System (EFS), Win2K logs event ID 618 (encrypted data recovery policy changed). Again, the event's User Name, Domain Name, and Logon ID fields under Changed By don't truly tell you which administrator changed the policy; these fields simply specify the local computer account.

You can also monitor changes to a computer's IP Security (IPSec) policy, although some confusion exists about the events that give you this ability. Win2K documentation (at http://www.microsoft.com/technet/security/monito.asp) lists the IPSec audit events—event ID 615 and event ID 616—as part of the Audit policy change category, but Event Viewer categorizes these events under Detail Tracking (i.e., the Audit process tracking category). Moreover, Win2K logs these events even when you don't enable the Audit policy change or Audit process tracking category. At any rate, when you assign an IPSec policy through a GPO in AD or through a computer's local GPO, Win2K logs event ID 615. If you use a GPO in AD, event ID 615's description specifies IPSEC PolicyAgent Service: Using the Active Directory Storage policy. If you assign the IPSec policy through the local GPO, event ID 615's description specifies IPSEC Policy-Agent Service: Using the Active Local Registry policy, as (i) there's no Active Directory Storage policy or (ii) the Active Directory Storage policy couldn't be applied successfully and there's no Cached policy. If Win2K encounters a problem applying the policy, the OS logs event ID 616 (IPSec policy agent encountered a potentially serious failure).

Watching for changes to Group Policy is an important step in ensuring your network's integrity. But you also need to remain vigilant about monitoring physical access to network systems. Win2K can help you accomplish this goal as well.

Audit System Events
The Audit system events category provides several useful security events. Whenever a Win2K system boots, Win2K logs event ID 512 (Windows NT is starting up). You can use this event to catch unauthorized system reboots—a potentially significant situation because Win2K is vulnerable whenever someone who has physical access to the system shuts it down. (For details about avoiding this vulnerability and other potential security breaches, see "Protect Administrator Privileges," February 2000.)

Although Win2K documentation claims that Win2K logs event ID 513 (Windows NT is shutting down) whenever a system shuts down, the claim is inaccurate. To determine how long a system was down, compare the date and time of an event ID 512 occurrence with the last event that Win2K recorded before the occurrence.

Win2K logs event ID 517 (audit log was cleared) whenever someone clears the Security log. (Win2K records this event in the new log.) Event ID 517 might reveal intruders who tried to cover their tracks.

Win2K logs several other events at system startup. The OS logs an occurrence of event ID 515 (trusted logon process has registered with the LSA) for each logon process that starts. (Logon processes, a component of the Win2K security subsystem, handle logons.) Win2K also logs an occurrence of event ID 514 (authentication package has been loaded by the LSA) for each authentication package that the OS loads. (Authentication packages support various authentication protocols such as Kerberos, NT LAN Manager—NTLM—and Secure Sockets Layer—SSL.) The OS logs an occurrence of event ID 518 (the SAM has loaded a notification package) for each notification package that Win2K loads; the standard notification packages are scecli, kdcsvc, and rassfm. (Notification packages are special DLLs that you can develop and install to synchronize passwords with other systems or to implement special password rules. However, attackers can use notification packages to steal passwords. Question any nonstandard notification packages, which could be Trojan horses.)

A Well-Rounded Arsenal
Win2K provides an impressive array of auditing facilities, including several enhancements over NT auditing. However, Win2K auditing also includes some significant bugs, and Win2K's Group Policy application process means that you can't always identify who changed a policy because administrators no longer make policy changes directly. If complete and accurate auditing is important to you, let Microsoft know that it needs to fix these bugs and that Win2K needs more granular auditing of policy changes that occur through GPOs.