Protecting the NT Security Log

Use the system events and policy change categories to track down intruders

In "Monitoring Privileges and Administrators in the NT Security Log," June 2000, I showed you how to use the privilege use and account management audit categories to monitor the activity of users who have administrative privileges. But what if intruders try to cover their tracks by tampering with the Windows NT Security log? You can use the system events and policy change categories to detect such attempts. (User Manager calls these two categories restart, shutdown, and system and security policy changes, respectively. As I mentioned earlier in this series, the NT Event Viewer and User Manager use different names for the auditing categories. For a table that compares the Event Viewer and User Manager category names, see "Monitoring Privileges and Administrators in the NT Security Log." For a list of other articles in this series about the NT Security log, see "Other Articles in This Series," page 104.)

Tracking Shutdowns, Restarts, and Policy Changes
The system events and policy change categories can help you identify signs of physical-access attacks and log tampering. The system events category includes event ID 512 (system restart) and event ID 517 (security log cleared). NT logs event ID 512 at every startup and event ID 517 whenever an administrator, or anyone with the Manage Auditing and Security Log right, clears the Security log. The policy change category includes event ID 612 (audit policy change), which notifies you that someone with administrative privileges changed the system audit policy from the Start menu's Programs, Administrative Tools, User Manager, Policies, Audit, Audit Policy dialog box.

Intruders have limited methods (aside from the log-filling tactics that I described in "Introducing the NT Security Log," March 2000) for covering their tracks in the Security log. The log file (i.e.,%systemroot%system32configsecevent.evt) is secure while NT is up because you can open the file only from the Event Viewer. This restriction prevents intruders from modifying or erasing the log while the OS is up unless they use very sophisticated techniques (e.g., injecting malicious code into the event-logging process). However, the log file is vulnerable while NT is down if an intruder has physical access to the system. Even when the boot drive is NTFS, an intruder can boot DOS from a 3.5" disk and use Winternals Software's NTFSDOS to delete or replace the log file. (NTFSDOS gives you read and write access to NTFS partitions from DOS, regardless of file and directory permissions.) Intruders in UNIX systems commonly modify the System log to disguise their activities. Although theoretically intruders can modify the NT Security log file while NT is down, NT's log-file format is more complicated than UNIX's log-file format, and I'm unfamiliar with tools that can fabricate records or delete specific portions of the log. Consequently, intruders are likely to delete the Security log file—or replace it with a copy that they made before the intrusion—and manipulate the auditing policy to disguise their actions. Fortunately, you can use the system events and policy change categories to detect such activity.

Log Tampering During NT Downtime
Because NT is so vulnerable during a shutdown, my policy in extremely high-security settings is never to shut down a system without at least two administrators present and always to record in a written operations log the shutdown and the reason for it. With this policy in place, you can scan the event log for system restarts (i.e., event ID 512), each of which should correspond to a record in the written log. Unexplained restarts might signal that someone tampered with the log or other files while NT was down (you might want to use a monitoring tool to alert you when the system restarts). You can compare these restarts to your computer room's electronic entry and exit records or security-camera video records (if you maintain such records) to determine who was present when the restart occurred.

In addition to event ID 512, four NT System log events can help you track shutdowns and restarts. These events, which are available only on systems running Service Pack 4 (SP4) or later, can even help you recognize when someone reboots the system without a complete shutdown. System event ID 6005 signifies that NT restarted; this event is synonymous with security event ID 512. Event ID 6006 signifies a clean shutdown, meaning NT didn't restart until after the It is now safe to turn off your computer message displayed. Event ID 6008 signifies a dirty shutdown, meaning the system unceremoniously rebooted without first initiating a proper shutdown. Event ID 6009, which resembles event ID 512, lists the OS version, build number, service-pack level, and other pertinent system information; NT logs this event during each boot. You can calculate the amount of time between shutdown and restart to determine how long the system was vulnerable. However, savvy intruders can change the system clock before restarting NT to give the illusion that little or no time elapsed. Intruders can also set the clock back before shutting down the system, thus giving themselves enough time to complete an attack without leaving a telltale empty period in the log. Look for event ID 577, which reflects the time change, in combination with event ID 512.

Intruders with administrator access might also try to clear the event log to cover their tracks. This action will stick out like a sore thumb if you've taken steps to make manual event-log clearing unnecessary. (For suggestions about how to set up a configuration that automatically maintains and archives the Security log, see "Introducing the NT Security Log.") Also, NT immediately logs event ID 517 in the empty log, notifying you that The audit log was cleared. NT logs this event even when auditing is off.

Deactivating Audit Policy
Before taking down the system and subsequently deleting or replacing the log file, an intruder with administrator access can turn off auditing to prevent NT from logging event ID 512. But auditing will remain off when the system comes back up, and an absence of event records will quickly alert you that auditing is off—and that you need to launch an investigation. Consequently, the intruder might be tempted to reenable the official audit policy after tampering with the log. If you've activated the policy change category in your official audit policy, the intruder's actions will generate event ID 612, which specifies the categories that the intruder turned on or off for both success and failure instances. In the event description, which Figure 1 shows, minus signs (-) show that someone disabled a category and plus signs (+) show that someone enabled a category.

Taking Precautions
If you're willing to make regular checks and implement the necessary audit policy, you can detect Security-log tampering. First, require two operators to be present whenever someone reboots the system, and maintain a signed record and explanation of each reboot. Second, implement a combination of maximum log size, event-log wrapping, and archival options to make manual clearing of the event log unnecessary. Third, activate the policy change category in your official audit policy configuration. And fourth, routinely check the Security log for event IDs 512, 517, and 612. Watch for event ID 512 occurrences that have no corresponding entry in the written operations log, and investigate these unauthorized reboots. Search the event log for gaps of time with no events, and compare those gaps to the computer room entry and exit records, if possible. Consider event IDs 517 and 612 suspicious because clearing the log or changing your audit policy is seldom—if ever—necessary. Regularly verify that the current system audit policy matches your official configuration. Be suspicious of any inconsistencies, and investigate immediately.

NT's security events auditing categories let you track every aspect of activity on your NT systems. You can tie together different events from separate categories to create a detailed audit trail. You can even identify when someone tries to tamper with your event log. The final article in this series will detail tools that help you automate Security log monitoring and management.