Avoiding WinZapper's Sting

In my article "Protecting the NT Security Log," Windows 2000 Magazine, July 2000, I discussed ways an attacker or a malicious administrator can tamper with or erase evidence from the Windows NT Security log. In the article, I stated, "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)." Well, a shrinkwrapped tool called WinZapper uses just such a sophisticated technique, and it's now available.

WinZapper, which Arne Vidstrom wrote, is available at NTSecurty.nu. The tool lets any member of the Administrators group highlight one or more events in the NT Security log and delete them. WinZapper works on both Win2K and NT systems. Although the program currently works only on the local system and doesn’t let you edit or forge new events, Vidstrom has stated that you can add these capabilities. As I noted in the first article above, this kind of attack has always been possible and isn’t a vulnerability in NT. If you gain administrator access or if you are a malicious employee with administrator access, just about anything is possible. However, theoretical attacks are quite different from attacks you can pull off with a shrinkwrapped hacker tool. Tampering with the Security log just went from being a theoretical attack requiring rare skill to a simple procedure that any disgruntled administrator with mediocre talents or a script kiddie can use.

So how do you protect yourself against WinZapper? First, protect administrative authority. Strictly limit membership to the Administrators and Domain Admins groups on both member server and domain SAMs. Limiting the number of users who have administrative authority in NT can be difficult because you need this authority to delegate many tasks. However, I have good news for those of you migrating to Win2K. Because authority is much more granular in Win2K, very few users need full Administrator privileges. You can protect yourself by requiring those who are administrators to follow best practice procedures to prevent attackers from stealing administrative authority. These best practice procedures include using strong passwords and not running untrusted software while logged on as an administrator. For additional suggestions on how to protect yourself, see my article, "Protect Administrator Privileges," Windows 2000 Magazine, February 2000.

Second, for high security systems such as e-commerce, consider implementing a Security log monitoring tool such as Axent Technology's Intruder Alert or Internet Security Systems' RealSecure OS Sensor. These types of tools constantly send new security events to a central log server before WinZapper has a chance to delete these events.

Because WinZapper leaves several pieces of residual evidence, the third line of defense is detection rather than prevention. On a test system, open User Manager and activate both the Process Tracking and Restart, Shutdown and System audit categories. Next, run WinZapper. Try using the Event Viewer to view the Security log. What happened? The action fails with an invalid handle message. From the time WinZapper runs until you reboot, NT won’t log any more security events and you won’t be able to view the Security log—just one indication that WinZapper has run on this system.

If you look in %systemroot%system32config, you will find dummy.dat, which is another indication that WinZapper has executed. Unfortunately, if you look at the owner of dummy.dat, you won’t know which user account executed WinZapper because WinZapper doesn’t work unless you are a member of the Administrators group. When an administrator creates a file, NT doesn’t make the individual user the owner; instead, the OS uses the Administrators group. Now, reboot the system and view the Security log. Scroll down to the most recent event ID 512, "System restarted." As Figure 1 shows, the last event the OS recorded before event ID 512 is event ID 592. When you open event ID 592, as Figure 2 shows, you see that the OS records the fact that WinZapper executed on this system. The event also indicates which user ran the program—Administrator in this case.

Of course, a crafty attacker might rename the WinZapper executable to something less obvious. However, in "Protecting the NT Security Log," I recommended that you use the Restart, Shutdown and System audit category to look for unauthorized restarts. You should also look for event ID 592 immediately preceeding event ID 512 in the Security log, which is a suspicious pattern of events. Typically, you will see several events related to event ID 593 for all of the processes that must stop prior to restarting a system.

It was only a matter of time before someone wrote a program like WinZapper. Keep in mind that this vulnerability isn’t a bug in NT. If an attacker gains administrative access or an administrator goes bad, you're already in trouble. Deleting events from the Security log is just one of many steps the intruder can take. Therefore, be sure to protect your administrative authority and strictly limit the users in the Administrators group.