Malware v2.0 writers continue to develop new techniques and write sophisticated code to evade security solutions. We’ve seen a surge in the volume of changing and newly distributed malware that “go Ring0”, or install kernel level drivers. Often, and in the case presented here, the driver is installed in order to silently render AV solutions useless. The widespread Storm threat includes kernel level functionality to perform some of its malicious work, but so do a number of other web-based threats that include components not yet detected by all of the AV community.

In our previous post, we examined a commoditized third party plugin exploit being used in the wild now and its “proactive-solution” evading shellcode. This post will take a look at another effective attack method being used right now, often as another layer in a web based attack, with the end result of rendering a majority of real time av scanners ineffective on the system. Why do malware writers go to these lengths? Usually, in order to obtain and maintain presence on the system.

This added technique relies on a driver installer (often downloaded and executed by an attacker’s shellcode), and a driver component to perform the malicious activity. The samples that we have analyzed also will download a spambot and proxies following the driver component’s successful modification/destruction of the av solution’s real-time scanning capabilities.

I’ll try to describe the activity and environment in fairly plain terms, so readers don’t have to be a device driver writer to understand what is going on.

The driver somehow has to be copied to the system and its service installed. This action can be done in a number of ways. The executable component that creates the driver file and installs the service can be launched on a victim’s system by attacking a web browser plugin as detailed in the last post, binding it to another exe and spamming it out to harvested email accounts, or any number of other well known methods already effectively used in the wild.

This downloaded executable copies out the .sys file to c:\windows\system32\drivers and makes a common win32 api call to install this driver as a file system object. Here’s a quick snapshot of the thread stack when the call is made:

The dropper’s work is almost done. Next, it starts the service and exits.

Once the driver is started by its installer, it maliciously modifies the file system stack. “Real-time” file scan functionality is then disabled, even for major av products.

Here are a couple of screenshots of the system’s device tree prior to the attack – 1. a device tree representation of the Ntfs and raw filesystem drivers following a default install, and 2. a device tree representation of the Ntfs and raw filesystem drivers following the installation of a major anti-virus product. Keep in mind this kernel layout is what the malware writers are looking at when choosing their targets. The visualization is meant to help understand what is being attacked…

This screenshot presents the filesystem stack prior to the installation of the AV product. Notice that the ntfs driver (labelled DRV  \FileSystem\Ntfs) has a named device (labelled DEV \Ntfs), and also in its stack is the system volume (labeled MED \Device\HarddiskVolume1), which represents the underlying disk volume/partition. The XP SP2 operating system device tree normally looks like this following a default install:

This screenshot presents the device tree representation of the file system stack after the installation of a major vendor’s anti-virus product. The Ntfs driver stack has been changed altogether. These changes are indicate that the anti-virus scanner has installed a set of mini-filter drivers, shown by the additions of multiple new attachments labeled “ATT Attached: (Unnamed) – \Filesystem\FltMgr”:

After observing and recording the state of the filesystem stack in a normal state and in a av solution modified state, we run the malware on this goat system in our lab, and it runs unhindered by the antivirus product — signatures for the binary have not been added yet by this av vendor, even though the malware has been circulating in the wild for over a couple of weeks now. At least a couple other vendors are detecting the dropper and its driver.

Here is a screenshot of the filesystem stack after the malware has been run. Notice that all of the mini-filter attachments that were attached by the AV solution to the Ntfs device object have now been detached from the stack:

This modification effectively chokes off any real-time functionality of the AV solution’s filesystem scanner. We expected the system to crash and throw off a BSOD, but it kept running in this state in our labs for hours without any blue screen.

The AV security application continues to run, without presenting any warning to the user that it has been hacked, so the user thinks everything is ok. But their system is left unprotected at this level.

At last we confirm the inability of the real-time AV filesystem scanner to detect malware copied to disk in real-time. We copy three year old malware binaries (variants of the bagle Trojan) from a server we maintain in the labs to this attacked system. Normally they are caught by this AV scanner’s real-time protection: 

The files are copied to the system’s hard drive without any detection, while the Auto-protect feature of the scanner quietly reports its “On” status. The AV solution clearly has been rendered useless and misleads the user into thinking that their drive is protected. This last confirmation in the AV gui’s status page reinforces that this host compromise is unexpected, effective and stealthy: