Proliferation
ZeroAccess is one of the most talked and blogged,[1][2] about rootkits in recent times. It is also one of the most complex and highly prevalent rootkits we have encountered, and it is continuing to evolve. The ZeroAccess rootkit is distributed via both social engineering as well as by exploitation. A recent blog post by our colleagues at McAfee describes some of the odd methods this rootkit adopts to get installed on machines without getting noticed.
One of the goals of this rootkit is to create a powerful peer-to-peer botnet, which is capable of downloading additional malware on the infected system. This botnet is reportedly [3] involved in click fraud, downloading rogue antivirus applications, and generating spam.
This Google map of the United States shows McAfee VirusScan consumer nodes reporting unique ZeroAccess detections during the past week.
Our consumer data for the past month shows close to 4,000 unique systems detecting ZeroAccess daily. And the trend is continuing upward.
Installation
In my recent analysis of this rootkit, I wanted to understand its initial installation mechanism. The installation of ZeroAccess involves overwriting a legitimate driver on disk with the malicious rootkit driver. Usually Step 1 varies in different variants. Some variants directly overwrite a legitimate driver and others first inject the malicious code in trusted processes like explorer.exe and then, from the injected code, overwrite the driver (this is done to bypass various security products and to make analysis more challenging). During Step 1, the original driver code is kept in memory. The driver that is overwritten in Step 2 is randomly selected (details here[1]). In our discussion below we assume CDROM.sys is being overwritten. Step 2 to Step 8 are fairly static in variants of ZeroAccess. Once the driver is overwritten by malicious code, it is loaded in kernel space. The first task of the kernel mode code is to ensure that it sets up the malware to survive reboots and to forge the view of overwritten driver (CDROM.sys).
Lets move on to see how this scheme works in Step 5 through Step 8. In Step 5, ZeroAccess intercepts disk i/o by hooking the DeviceExtension->LowerDeviceObject field in the \driver\disk DEVICE_OBJECT. So now any disk i/o would go through the rootkit’s malicious routine. In Step 6, the kernel mode code has access to a clean image of the CDROM.sys driver stored in memory. To survive reboots it flushes the file to disk using the ZwFlushVirtualMemory API. The request to flush the clean image is, interestingly, sent to the file CDROM.sys, which at first glance looks counterintuitive. Why would the rootkit want to write the clean image to the file it just infected in Step 2? Looking more closely, the rootkit actually uses its disk i/o redirection framework. So, when this request to store the clean image of the file on disk travels through the virtual driver stack shown in Step 7, it is encrypted and redirected (Step 
to the rootkits “protected” folder that it created in Step 3, instead of going to the actual CDROM.sys.
Once the original encrypted image of CDROM.sys is stored in the protected folder, the infection becomes persistent and can easily survive reboots. Any attempt to read the infected CDROM.sys would have to traverse the hijacked i/o path, in which the rootkit on the fly decrypts the original file from its protected storage and presents the clean image, thus forging the view of the file to security tools. Also, during a reboot the infected file would first load the malicious code in kernel, which can refer to its “protected” folder, and load the original file in kernel, thus ensuring the uninterrupted functionality of the original device.
To clean this threat, security tools have to take several steps in repairing either memory or decrypting the file in its protected folder so that they can restore the original file. Also once the rootkit is active in kernel mode, it takes lot of evasive steps to kill or circumvent the security tools as described by our colleagues in this Virus Bulletin article. So repair becomes even more challenging and research more costly.
Impact of real-time kernel monitoring
I tested for more than a year many variants of this rootkit family against McAfee’s Deep Defender technology, which provides real-time protection against unauthorized kernel-memory modifications. The following screenshot shows Deep Defender blocking the DeviceExtension hijack attempt in Step 5, which was critical to the rootkit’s survival. Once this hook was blocked, the machine was cleaned after a reboot, without any fancy repairs. This move shaved off days of reverse engineering and writing custom repairs against this rootkit and its multiple variants. It seems Deep Defender has found the Achilles heel of this rootkit.
How did Deep Defender clean the machine?
You did not miss part of this article. The interesting point is that Deep Defender did not have to do any custom repairs to clean this threat. It just blocked in real time the core functionality of the rootkit. Let’s revisit the attack strategy to understand what happened.
When the rootkit attempted to hijack the DeviceExtension pointer in Step 5, Deep Defender’s real-time kernel-memory protection saw the attempted change and recognized it as a malicious attempt to modify a critical structure and blocked the hijack attempt. With the hook gone, the rootkit could not hijack the disk i/o path, which means it could not store any files in its “protected” folder and could not survive any reboots without getting noticed. It certainly cannot forge the view of the file anymore. But the most interesting part is that the attempted hijack block by Deep Defender actually redirected the rootkit’s write attempt in Step 7 to its original location. So Step 8 would actually overwrite the original file that it just infected from user mode, thus forcing the rootkit to clean up for us. After a reboot, the system will be back in the clean state.
This strategy from Deep Defender works against all the current ZeroAccess variants. It would be challenging for the rootkit authors to fully bypass this defense without either leaving the system in a corrupted state or being noticed by security tools, which would catch them red handed if they could no longer forge the view of the file.