Win2K Security Log Roundup

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.

   Previous  [1]  2  3  4  Next