Analyzing Event Logs
Now that you know how to collect and merge many event logs into one file, how do you efficiently analyze this file to find suspicious activity patterns? Several available reporting utilities can analyze output files for specific types of activity.
R528. R528 helps you monitor users' logon sessions to determine who accessed a system during an incident, determine normal usage trends, and recognize anomalous logons that might indicate a security breach or unauthorized account use. The utility searches for occurrences of event ID 528 (successful logon) and corresponding event ID 538 (user logoff) in one or more .evt files. (For more information about logon events, see "Monitoring Privileges and Administrators in the NT Security Log," June 2000.) R528 lets you choose from several report sections, which Figure 2 shows.
The first section details each logon session, showing the user who logged on, which computer the user logged on to, the logon type, the logon date and time, and the logoff date and time. One problem with NT's auditing is that NT doesn't always record event ID 538; consequently, R528 will probably find more records with event ID 528 than event ID 538.
The utility's second report section lists the unmatched logon events. Note that R528 reports show the system that a user logged on to, not the system the user logged on from. (For example, when a user logs on to a local workstation with a domain account, NT records the logon in the local workstation's log. When the same user accesses a shared directory on another server, NT records that logon in the other server's log.)
You can use R528 to search multiple .evt files simultaneously and produce one comma-, tab-, or semicolon-delimited report. R528 has a host of options to control the reported information and level of detail, so you might need to experiment to find the right reporting combination for your needs.
R529. R529 helps you monitor event ID 529 (failed logon). The utility's report (which Figure 3, page 85, shows) lists failed logon attempts, detailing the user account, the system the user attempted to log on to, and whether the logon originated locally or over the network. R529 also tries to distinguish between innocent mistakes and attacks by looking for two or more failed logons that involve the same account and computer and that occur within 5 minutes of one another. When R529 finds a successful logon that immediately follows a failed logon, the utility reports the pattern as a mistake. When a successful logon follows a string of failed logons, R529 reports a successful attack. For all other situations, the utility reports a failed attack. The utility's simplistic pattern recognition can't dependably recognize all attacks, but the tool's mistake recognition helps you weed out failed logons that were likely the result of user error. Two optional summary sections help you identify the computers and user accounts that intruders attack most frequently.
NTLast 1.6. NT OBJECTives' NTLast 1.6 is another free tool that you can use to analyze logon activity. (The company also offers NTLast 2.85 for purchase; for a review of NTLast, see Mark Joseph Edwards, "NTLast v2.6," September 1999.) Similar to the UNIX last command, NTLast offers several reporting options to help you analyze logon and logoff events. You can use the /n switch to specify the number of logon and logoff events that you want NTLast to report. You can use the /s and /f switches to report successful or failed logons, respectively; you can use the /r and /I switches to specify remote network or interactive (i.e., local) logons, respectively. When you select successful logons (i.e., when you use the /s switch), NTLast tries to find the corresponding logoff event for each logon, as Figure 4 shows. In this capacity, NTLast functions similarly to R528.
NTLast doesn't read archived .evt files, so you must use the tool's /m switch to run the utility against each remote system that you're monitoring. For example, to report the past 20 failed remote logons, type
ntlast /m oraclesvr /f /r /n 20
R592. In "Interpreting the NT Security Log," April 2000, I explain how to use the process tracking audit event category to audit programs that run on your workstations and servers. Security event ID 592 identifies a started process, as well as the process name, the user who started the process, and the date and time that the process started. Event ID 593 identifies an ended process. Event ID 592 and event ID 593 correspond in a manner similar to the complementary logon and logoff security event IDs 528 and 538. R592, another tool for purchase from Frank Heyne Software, searches one or more event logs for each event ID 592 and corresponding event ID 593 and produces a useful report showing who ran each process and how long the process ran. The source file and output file options are similar to R528's options. Although process tracking is valuable (especially on workstations), it has limits: Users can copy and change program names, and NT reports only the executable name rather than the full pathname.
System-log tools. When you use a RAS server, attackers can easily target this important entry to your network. Frank Heyne Software's R20050 provides RAS connection reports (RAS connections trigger System event ID 20048 and System event ID 20050). Cut from the same mold as R528 and R592, this utility offers the same options for source and output formatting.
Creating Custom Reports
Although the tools I've described can help you analyze the event logs and generate specialized reports, these tools deal with only certain activities. When you want to monitor other activities (e.g., file and object access, use of user rights, account management), you can use ELDump and Access to import the necessary event logs from all your systems into one Access database, then create custom reports that draw information from all the event logs. By using ELDump in combination with Access, you can overcome the inherent problems that arise from the different number of strings in each event ID's free-form description.
First, create an Access table that has columns for all the standard description data (e.g., date, time, event ID, username, source, type, category, computer name). Then, add 20 more text columns and label them with generic names (e.g., string1, string2) for the message strings. These extra columns will provide room for events with large descriptions. Create a batch file that uses ELDump to dump the Security logs for all your relevant systems into one text file. Use ELDump's -A parameter to specify output for only the past 24 hours of activity (i.e., -A 24). Use the -s parameter to specify each computer from which you want to dump the logs. For example,
eldump -s oraclesvr -s docsvr1 -s docsvr2 -A 24 -t -l sec > events.txt
will dump the past 24 hours of activity from the Security logs for the servers OracleSvr, DocSvr1, and DocSvr2 into a tab-delimited file called events.txt.
Next, create a macro that automatically imports the text file into your Access table. Add a command to the batch file to execute the macro after ELDump runs. Configure the batch file to delete the text file after importing it into the Access table. Finally, schedule the batch file to run each day at the same time. Now you have a master database of all security events for your network, and you can write custom reports from this database. For example, you can write a Daily High Risk Events report that lists all the highly suspicious events that I described in "Protecting the NT Security Log," July 2000. You can sort the events by event ID, then by computer. You can also use this database for ad hoc queries when you need to research trends or investigate other situations. With this method, you might miss or duplicate some events depending on how exact your job scheduler is and how quickly the dump executes. If this possibility concerns you, you can insert a step in the batch file to first use EventSave to dump the logs, then use ELDump to read the archived .evt files rather than pull the events directly from your systems' logs.
In the Know
You'll need to dedicate time to set up regular automated archiving and reporting processes, but you'll save time in the long run by eliminating the need to manually peruse each event log. And after you've initiated these processes, the sky is the limit for your archiving and analyzing options. Take the time now to implement automated processes, and you can sleep easier knowing what is happening on your network.
)
Register
Rob Williams August 04, 2000