By Marco Giuliani

The latest generation of a rapidly evolving family of kernel-mode rootkits called, variously, ZeroAccess or Max++, seems to get more powerful and effective with each new variant. The rootkit infects a random system driver, overwriting its code with its own, infected driver, and hijacks the storage driver chain in order to hide its presence on the disk. But its own self-protection mechanism is its most interesting characteristic: It lays a virtual tripwire.

I’ve written about this rootkit in a few recent blog posts and in a white paper. On an infected computer, this new driver sets up a device called Devicesvchost.exe, and stores a fake PE file called svchost.exe – get it? The path is Devicesvchost.exesvchost.exe. The driver then attaches itself to the disk device stack. The driver creates a new system process, called svchost.exe, pointing to the path: \GlobalrootDevicesvchost.exesvchost.exe. This fake process serves as a kind of trap, specifically looking for the types of file operations performed by security software.

When a typical security scanner tries to analyze the rootkit-created svchost.exe file, the rootkit queues an initialized APC into the scanner’s own process, then calls the ExitProcess() function — essentially forcing the scanner to kill itself. The rootkit’s effectiveness, however, is hindered by a weakness in the way the rootkit filtered disk I/O. As it turned out, we can easily bypass the filtering technique and get to the masked data. We’ve also reversed the code the rootkit uses to generate domain names it will contact for command-and-control, and have provided a list of the domains it will use in the months of July, 2011 and August, 2011 so network managers can protect themselves proactively.

Until May 2011, the rootkit was hitting only 32-bit versions of Windows. Normally, it’s much more difficult to infect 64-bit Windows in kernel mode, due to two technologies: the driver’s digital signature verification check, and PatchGuard, the built-in Kernel Patch Protection technology. But recent changes to the rootkit’s architecture extended its spread into 64-bit world, though it doesn’t infect 64-bit systems using a kernel mode driver. Instead, it uses a more compatible user mode rootkit technique.

And then in June, the team behind ZeroAccess mixed up its infection techniques yet again. The way most people become infected with this rootkit today is through exploit kits hosted on drive-by download Web sites. The exploit kits push a dropper to the victim PC and executes it. The dropper attempts to evade UAC by executing a new, code-injected instance of explorer.exe.

Windows 7’s UAC implementation contains a white list of system processes which can elevate their own privileges without user interaction in some specific situations, depending on how the UAC feature is configured. Explorer.exe is present in this white list so that, if the UAC feature is configured to not notify the user on every action requiring user’s interaction (configuration used by Microsoft as a factory setting), the process can automatically elevate itself and get administrator privileges. The rootkit module injected in explorer.exe shows the internal development project string (“p:vc5release_uac.pdb“) because the module itself has no name; it’s just a bunch of code injected inside the explorer.exe.

In order to contact its CnC server, the rootkit uses something called a domain generation algorithm. This code, first widely seen during the Conficker outbreak, creates random domain names based on the system date.

The malware creator can then generate a list of domain names that will match those in the rootkit for any time in the future, and register some, or all, of the domain names in advance of the rootkit’s attempted check-in times. These list generators can make it much more difficult to maintain a blacklist of dangerous Web sites. The rootkit only uses the data representing the year, month, and date from a call to GetSystemTimeAsFileTime as a variable, which means it can only generate one domain per day.

If the victim’s operating system is x64, the rootkit splits off and uses a different technique to infect the system. In order to do this, ZeroAccess needs an additional module, which it will download. Its x86 infection technique remains unchanged from those documented in the white paper; the only notable difference being the way of the rootkit generates the payload’s filename.

The rootkit stores the additional modules in a hidden RC4 encrypted volume inside %windir%system32config, just as it did in previous iterations. ZeroAccess can store and launch additional payloads or plugins from this hidden volume, which will remain hidden from the operating system and security software. In the current generation, the rootkit is installing ad-clicker Trojans in this hidden area, which causes a lot of network usage on infected systems.

The most interesting development is ZeroAccess’ use of another, second rootkit driver (as described above) as a weapon to kill, without mercy, every kind of security software. Not only does the security scanner call its own ExitProcess(), but after the software has been killed, the rootkit ratchets up the nuisance level to 11: It resets the ACL setting of the process’s file, rendering the file unusable unless the user manually sets back the correct ACL.

Why this fake process is able to terminate most security software? Because every security software runs a process scan as part of a full system scan. By scanning the process list, the security software trips over the fake process and it gets killed – both the process and the file’s ACL settings. The security software is effectively gone.

Interestingly enough, it also looks like the rootkit has a backdoor: If you run a file with a specific timestamp, PE checksum, and MajorOperatingSystemVersion and MinorOperatingSystemVersion properties, the rootkit will ignore the file. Such functionality could allow the rootkit’s creator to, for instance, run a custom tool that removes all trace of the rootkit code, which the rootkit itself will ignore.

This self-defense update to ZeroAccess seems like it could make things difficult for people and businesses to protect their computers. A ZeroAccess-infected computer, with its security software disabled, remains unprotected and ripe for any other kind of infection. But it’s also a technique that could result in a backlash. After all, it’s not as if disabling an antivirus scanner will pass unnoticed. If anything, it will force the creators to work harder, because the rest of the security industry will refocus its efforts to squash the most annoying gnat buzzing around the yard.

About the Author

Blog Staff

The Webroot blog offers expert insights and analysis into the latest cybersecurity trends. Whether you’re a home or business user, we’re dedicated to giving you the awareness and knowledge needed to stay ahead of today’s cyber threats.