Targeting ZeroAccess Rootkit’s Achilles’ Heel
ZeroAccess is one of the most talked and blogged ,  about rootkits in recent times. It is also one of the most complex and highly prevalent rootkits we have encountered and which is still continuing to evolve. The ZeroAccess rootkit is distributed via both social engineering as well as 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 reportedely  involved in clickfraud, downloading rogue antivirus applications, and generating spam.
This Google map of the United States shows McAfee VirusScan consumer nodes reporting unique ZeroAccess detection over 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.
In my recent analysis of this rootkit , I was looking to understand the 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 i.e. some variants would directly overwrite a legitimate driver and some others would 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, which is overwritten in Step 2, is randomly selected (details here ), 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 – Step 8. In Step 5, ZeroAccess intercepts disk i/o by hooking DeviceExtension->LowerDeviceObject field in the driverdisk DEVICE_OBJECT. So now any disk i/o would go through rootkit’s malicious routine. In Step 6, the kernel mode code has the access to clean image of CDROM.sys driver stored in memory and to survive reboots it flushes the file using ZwFlushVirtualMemory API to disk. The request to flush the clean image is interestingly sent to the file CDROM.sys, which at first glance looks counter intuitive. Why would the rootkit want to the write 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 file on disk traverses through the virtual driver stack shown in Step 7, it is encrypted and redirected ( Step 8 ) 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 , where, the rootkit decrypts the original file from its protected storage on the fly and presents the clean image, thus forging the view of the file to security tools. Also during 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 uninterrupted functionality of the original device.
In order to clean this threat, security tools have to take several steps in repairing either memory or decrypting the files 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 colleages in this Virus Bulletin article. So repair becomes even more challenging and research costly.
Impact of real time kernel monitoring
I tested many variants spanning over an year of this rootkit family against McAfee’s Deep Defender technology which provides real time protections against unauthorized kernel memory modifications. The following screenshot shows Deep Defender blocking the DeviceExtension hijack attempt in Step 5, which was critical to rootkits survival. Once this hook is blocked the machine was cleaned after a reboot, without any fancy repairs and it actually shaved off days of reverse engineering and writing custom repair against this rootkit and its multiple variants. It seemes as if Deep Defender hit right in the Achilles heel of the rootkit.
Is that it? How did Deep Defender clean the machine?
No you did not miss part of the article, the interesting part is that Deep Defender did not have to do any custom repairs to clean this threat. It just blocked realtime the core functionality of rootkit. Lets 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 is 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 cannot store any files in its “protected” folder anymore and could not survive any reboots without getting noticed. It certainly cannot forge the view of the file anymore as well. 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 go 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 cleanup 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 and without being noticed by the security tools which would catch them red handed if they cannot forge the view of the file anymore.
The original article/video can be found at Targeting ZeroAccess Rootkit’s Achilles’ Heel