Targeting ZeroAccess Rootkit’s Achilles’ Heel

[Nytro]

[h=1]Targeting ZeroAccess Rootkit’s Achilles’ Heel[/h]Monday, April 30, 2012 at 4:17pm by Aditya Kapoor

[h=2]Proliferation[/h] 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 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 [3] 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.

[h=2]

Installation[/h] 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 [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 – Step 8. In Step 5, ZeroAccess intercepts disk i/o by hooking DeviceExtension->LowerDeviceObject field in the \driver\disk 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.

[h=2]Impact of real time kernel monitoring[/h] 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.

[h=2]Is that it? How did Deep Defender clean the machine?[/h] 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.

Sursa: Targeting ZeroAccess Rootkit’s Achilles’ Heel | Blog Central

[ionut97]

Si inca un articol despre acest rootkit puteti gasi aici:

Analysis of ZeroAccess Rootkit / Malware / Security Analysis / Downloads - Tuts 4 You

Author Marco Giuliani

Description When we write about ZeroAccess rootkit, it is essential to go back in 2009 and to remind when this rootkit had been discovered in the wild. It was the time of MBR rootkit and TDL2 rootkit – the second major release of the most advanced kernel mode rootkit currently in the wild – when security researchers came across a new, previously unknown, rootkit able to kill most of security software as soon as they tried to scan specified folders in the system. ZeroAccess was creating a new kernel device object called __max++> , this is the reason why the rootkit has quickly become known in the security field as the max++ rootkit, also known as ZeroAccess due to a string found in the kernel driver code, presumably pointing to the original project folder called ZeroAccess (f: \VC5\release\ZeroAccess.pdb).

This rootkit was storing its code in two alternate data streams, win32k.sys:1 and win32k.sys:2. To avoid being detected, it was killing every security software that attempted to scan for alternate data streams. It created in the system folder a number of fake junctions (note: an NTFS junction point is a feature of the NTFS file system that allows a folder to be linked to another local folder, becoming an alias for such target folder) pointing to the fake rootkit device written above. When security software tried to scan such specified folders for Alternate Data Streams presence (FileStreamInformation class), the rootkit’s selfdefense queued a work item in the security process able to immediately kill it. It became a non-trivial job scanning the system without being killed.

Since then, ZeroAccess rootkit evolved, changing the way it infects the system, becoming yet more advanced and dangerous. In this paper we are going to analyse this threat and how it evolved to its current release.

E o completare,scuze daca am postat gresit.