Posing as Microsoft Deliverables

Another Fakealert variant resorts to displaying a set of deceptive messages that can be found within the executable, while disguising the file as a Microsoft deliverable. These deceptions are best described as "cheap". Don't fall for it.

Here is a screenshot of the file properties from "uoyzsydz.exe", a file that attempts to open a browser on a victim's system to download more shocking fakealert ad content. Notice the use of the phony Microsoft trademark, the techie-sounding file description "Parsing software fo XML Media", and the official update-sounding version "2.34.0.1016":



At the time users were receiving and running the fresh new round of these released binaries, AV scanner detection was mostly non-existent, as it is missing for most of these new releases.

Unlike the xml parsers that Microsoft actually delivers, this module is packed simply with UPX and maintains fraudulent "shocker" strings to display to the user:
"Windows has detected spyware infection on your PC"
"Slow operation speed might have been caused by spyware."
"Internet attack detected."
"Somebody's trying to infect your PC with spyware or harmful viruses."
"Your computer is not protected against spyware."
"Spyware has been detected on your computer! Click here to run a FULL SYSTEM SCAN to protect your data"
"VERY HIGH RISK [ 5 / 5 ]".

It's not a surprise that no strings for "LOW RISK [ 1 / 5 ], DON'T BOTHER SHELLING OUT HARD EARNED MONEY BECAUSE OF OUR FRAUDLENT CLAIMS" appear anywhere in this file.

QQ Updates on Dns Port over Http?

Usually, port 53 is used for DNS queries and transactions over both tcp and udp, while http GET request traffic is handled over tcp 80 or 8080 (or ssl encrypted over 443).

Instead, currently we have an unusual set of files, often named "qq_updates.cab" that are being renamed and run on a fairly high number of user systems (they are not cab files. They are malicious executables) and querying http servers hosted in China over tcp port 53 for gif files (1.gif, 2.gif, 3.gif, B.gif, c.gif, etc). These queries are not standard dns lookup requests as a network admin might expect, or standard http requests for image files.

The responses for these gif file requests are either location information and directions to download more spyware executables or are additional spyware executables themselves, designed to steal a user names and passwords from multiple gaming applications. Some of the writers are becoming more clever and using encoded data over that port as well. Prevalence is high, and network admins may want to monitor dns ports for unusual http traffic for .gif files carrying nothing but executable content.

Return of Rustock?

Return is a powerful concept in many ways. In literature, return can touch on the limits of faith, love, loyalty, friendship, fidelity and mortality.

Homer's Ulysses wanders for years, returning to his home and his family in disarray. Initially, the only witness to recognize Ulysses in his home is his old dog Argus, faithfully waiting for his master's return over those 20 years: "As soon as he saw Odysseus standing there, he dropped his ears and wagged his tail, but he could not get close up to his master. When Odysseus saw the dog on the other side of the yard, dashed a tear from his eyes...But Argos passed into the darkness of death, now that he had seen his master once more."

Edward Fitzgerald's "The Rubaiyat of Omar Khayyam" speculates on the importance of understanding the inability to return:
"Then to the lip of this poor earthen Urn
I lean'd, the Secret of my Life to learn:
And Lip to Lip it mumur'd -- "While you live
Drink! -- for, once dead, you never shall return"

Unfortunately, in our last round of spambots, we find lots of return. However, these returns do not provide deep insight or wistful second comings. Instead, these returns serve to obfuscate the functionality of the rootkit driver component ("pgasghjd.sys") that appears to be the newest project of one of the rustock creators:
C:\progz\NewWork2\driver\objfre\i386\driver.pdb

Return is a powerful computing concept, and an important part of any CPU instruction set. The "RET" or "Return from procedure" instruction "transfers control to a return address located on the top of the stack".
These returns are used in an unusual way in the unpacking stub of the driver, avoiding making standard calls early in the routine. Here is the driver's entry point.



Notice the push of a hard-coded offset and the immediate return. This unusual sequence of assembly instructions simply pushes a return address to the stack, only to take control when the "ret" or "retn" is executed and control flows to this new offset. This sequence can be used as an effective emulator evasion trick.

These returns do not provide anything all that valuable, instead, these returns help to produce the unwanted spam, clogging global network pipes and peddling "male enhancement" drugs. These are the messages that are crass and vain, including with them a link to a couple of these "drug" peddling web sites. Obscene messages are not reproduced here, but here are a few examples:
"Give your chick a night to remember"
"Make sure you don't get left out of the action at parties"
"Fantastic results guaranteed"

Some returns come with really bad literature.

Vundo Variant Appropriates Microsoft Research Source Code

For the past several years, the Vundo family (also known as Virtumonde) of malware appeared high on AV vendors' prevalence lists -- this stuff is everywhere. To get there, the malware employs an aggressive set of tactics over the course of its distribution to evade AV and anti-spyware solutions. A close examination exposes an interesting observation that some of its user-mode rootkit tactics use the Microsoft Research Detours library in order to hide its presence from security solutions. Below is a somewhat technical description.

First off, the Detours project out of Microsoft Research focuses on "Binary Interception of Win32 Functions". In other words, when a developer or malware writer wants to hook a function inline and insert their own code, they can intercept a win32 function with code from the Detours library.
To use this code commercially, "Detours Professional 2.1 includes a license for use in production environments and the right to distribute detour functions in products...For information on licensing Detours Professional 2.1 contact Microsoft's IP Licensing Group at iplg@microsoft.com". Let's assume either that Microsoft never provided the vundo developers with a license or that the vundo developers never attempted to obtain a license for their "commercial" use.

One of Vundo's library components currently in the wild is injected into processes as a part of its attack. This component may in turn be detected by anti-spyware scanners using the EnumProcessModules api call, which would provide an anti-malware scanner using that call with a handle to the injected module. And this is where the abuse begins.
You can see the malicious Vundo hook in this screenshot, implementing the hook functionality from the Detours library. Basically, if a process calls EnumProcessModules, the vundo appropriated code will intercept the win32 function and report that the module enumeration procedure failed. When the EnumProcessModules call fails, certain security scanners are unable to detect the vundo component's presence:



How can Detours code be identified in this dll? Well, the source of the detours library can be placed side-by-side with the unpacked and disassembled vundo component. In many places, the same sequence and order of instructions and data is unmistakably identical. For the sake of brevity, we'll focus on just a couple that briefly illustrates our point in this post.

Here, the deadlisting for the vundo function is on the left, and the matching Detours source code on the right. This chunk of Detours code is at the core of the hooking functionality within disasm.cpp of detours.lib. The source from the Detours library here is determining the length of the currently evaluated instruction and then copying the instruction to the trampoline buffer (this location is the place where the inlined vundo rootkit function can call back into the original function without interception). The appropiated code on the left is compiler optimized, and it is a mirror image of the Detours logic on the right:



Here, in a similar fashion, we see vundo functionality that was stolen from the Detours library calling the DetourCopyInstructionEx() function and an inlined detour_does_code_end_function() function. In this reversing illustration, the vundo function is performing checks to ensure the target function's eligibility for interception. In other words, vundo's appropriated Detours code is checking to see if the target function contains a select set of instructions that would prevent hooking:

Ongoing targeted attacks during Tibet, Burma controversy and Olympic torch protests

Unfortunately, targeted computer attacks commonly occur. This morning's NPR show exposed such problems in regards to activists and journalists in China. Sadly, not much data is public about these sorts of attacks and it would be easy to speculate that such types of attacks are on the rise. Sometimes, the groups being attacked do not want members to be exposed or further put into public light and sometimes they do not fully understand they are being attacked. The NPR audio mentioned groups like the Falun Gong, Students for a Free Tibet, Human Rights in China and some China-based foreign journalists. Often, the attackers' identities are more difficult to uncover than more entertaining examples we've given in the past. While spoofed sources may seem to be from friends or friendly members of organizations, the true source remains in the shadows, hiding university or seemingly public ip addresses.

The various code used in targeted attacks that we have evaluated to date are not terribly impressive pieces of malware. The trojans and spyware often are delivered over email as embedded data within files of all formats with enticing names that the recipient would most likely be interested in. For example, the NPR interview mentioned a "resume.doc" file that was delivered to current board members and staff of the targeted Students for a Free Tibet from the spoofed email address of an ex-board member. These Microsoft Word docs, Excel spreadsheets, malicious .chm help files, and Powerpoint slideshows usually are malformed in one way or another to attack vulnerabilities in flawed software on the receiver's side. When opened by outdated software, these maliciously crafted files and the included code drop and run trojans and spyware embedded in the files on the victim's system.
Most can be prevented by keeping software updated and patched, running security solutions, and as always, security in layers is recommended.

The audio mentions that most AV scanners are often evaded by the software components of these targeted attacks (an unusual admission from a member of the AV industry!). And that trojan builders create nastier rodents in response to the AV companies' better mousetraps.
ThreatFire is different -- our behavioral-based cat is bigger and faster than that little piece of cheese sitting on the wire and wood thing in the attic. Purrs like a kitten too.

Really not all that funny (cont. ii)

We researched some of the early stage activity of this new round of Storm. It's an unusual release for the group -- they are being chided on forums and blog comments for repetition of the one liner emails that are recognizable and identified by spam filters. We mentioned that the components used (no kernel mode drivers) and the user mode binaries' characteristics and behavior are unusual for the group as well. It seems that they lost a graphic designer and their driver developers left the scene (at least for this release).

So, let's elaborate a bit on what seemed like a total lack of sophistication in this release's code base, keeping in mind that the group's efforts have included implementation of the most effective techniques to target and successfully evade security products on users' desktops. They were good at this work, after all, they had built the allegedly largest botnet ever. To that end, the malware writers are not disappointing with this release.
While the changes in the relentless holiday releases of late have typically had to do with their social engineering themes, we find that now the evasion techniques have moved out of the kernel and into user-mode.

In the "kickme.exe" samples that load "testdll_f.dll", we find several interesting pieces of code. A loop implements an ntdll function overwrite routine just prior to loading the mysterious test dll that is unpacked in memory and never touches disk, and kickme hooks several api's -- NtOpenFile, NtQueryAttributesFile, NtClose, NtCreateSection, NtMapViewOfSection, and NtProtectVirtualMemory. Here is an example of one of the hooks:









The hook function blocks within the code are some of the first chunks of code to be unencrypted at startup. A jump table is built on the stack to redirect control back to the hook function from the jmp instruction in ntdll. When LoadLibraryW is called on the in-memory unpacked testdll_f.dll library, these hooks replace the standard Windows loader functionality and any security products' functionality that hooks these functions common to dll loading themselves. Up until this point in the binaries' execution, the thread has been busily unpacking code at the assembly level without making calls to api's other than a handful buried away in ntdll, like memcpy.
So far as we know, this user-level evasive behavior is new to Storm. These changes may be underestimated by some, but they help the group to meet their own goals in new ways.

On to the next malware family, we'll probably see you next holiday or major news event (possibly the NCAA championship) with more Storm details.

Common Hijack Habits Are Hard to Break

You just need to find the right point. Breakpoint, that is.

We've had a couple of recent posts that record the use of an injection technique quite commonly used by ITW malware. It has been used for years to evade personal firewalls. New code utilizing the same technique for a variety of solutions (grey, black, or white hat) continues to be posted. Proper prevention for this injection technique has a heightened longevity because of its popularity, and it underscores the usefulness of behavioral based security products. Let's take a look at some of the low level activity of the subject of yesterday's post.

Using a variety of monitoring tools, we can see that the software creates an Internet Explorer process in a suspended state. Eventually, that process is started and sends yahoo messenger spam off of the system and performs a variety of tasks. Let's use one of our favorite debuggers, Ollydbg, to identify the hijacking activity.

The dropper overwrites the entire code section of iexplore.exe process after it starts the browser in a suspended state. We'll throw the first executable, up.exe, into one of our favorite debuggers, Ollydgb. We search its list of imports, set a breakpoint on CreateProcessA and run the executable. These listings show the unusual command-line parameter and provided to CreateProcess:






The stack shows the CREATE_SUSPENDED state of the new process:







The ProcessInfo structure that is passed back out of this call provides handles to both the process ID (PID) and the main thread ID (TID) of the newly created Internet Explorer process. These handles will be re-used later in the routine. For now, the hijacker will call GetThreadContext to copy out all of the values held in the registers of the currently suspended iexplore main thread. They will be used when the thread's execution is resumed:







We see the entire .text section of iexplore mercilessly overwritten and extended with a loop that calls WriteProcessMemory and VirtualProtect on ten separate occasions. It's a lot of work to hijack IE successfully!
In effect, this work completely overwrites Microsoft's code, making Internet Explorer just a shell for the injection code to work within:








Now that the executable code has been tediously copied into IE, the context of the suspended thread is set back to its original environment (actually, a small trick is used and just the context defaults are used) and the newly overwritten thread's execution is resumed:








What looks like a familiar browser process is not a browser at all.

If your security solution doesn't already stop an old habit like this one, you might want to find out why not.

What's in a picture?

Sometimes, nothing that you can look at.
We are analyzing what appears to be a spike in PornClicker activity. The keenly named updater, up.exe, for this software downloads a jpg from smart-browser.com, a "sex browser" software distributor.
Jpeg files normally are a special format of image files commonly used for displaying pictures on the web. But this updater renames the downloaded jpegs to .dll and .exe extensions. They most likely are using the jpg extension on its downloaded executables to evade the simplest firewall and Url filtering schemes.

The delphi-written executable surprises us with a few camouflaging techniques. We are seeing it use multiple plays on Adobe's trademarked name. For example, when up.exe is run and deletes itself, it uses the unusual suspended process/setthreadcontext technique mentioned in a previous post to start and inject Internet Explorer with its own code. Then, the code running within the IE process creates an "Adobe" directory within the user's %Application Data% directory. This zombie Internet Explorer process downloads the udpi2.jpg file served from hxxp://smart- browser.com/ updatex/ udpi2.jpg, and renames the phony image file to rundtl.exe. Their code then creates a run registry key so that the app starts every time the machine is booted:
"HKCU\Software
\Microsoft\Windows\CurrentVersion\Run\AdobeManager"
"C:\Documents and Settings\p\Application Data\Adobe\rundtl.exe" -sys
Hmm. Is it a pdf reader or Adobe's download manager? No.

Instead, once running alongside another downloaded .jpg file renamed to an executable component (mdb.dll), the PornClicker connects to Yahoo!Messenger over http and starts spamming out messages like
"I know it's been a while but check out my webpage and let me know if you wanna talk more"
hxxp://sexmecrazyy .com
It also begins to click on and pull down garbled urls.

Nothing to look at here:






















ThreatFire's name for it is "PuA.SmartBrowser.PornClicker".
Note- It has been updated to Trojan.Injector.

Chartreuse pill

Ok, we're running out of little pill colors to match up with Matrix analogies. But simply put, the red pill and the subsequent blue pill work attempted to achieve the goal of detecting and abusing virtual machines.

Maybe chartreuse isn't what we're looking for, maybe it is, but worms we are currently monitoring in the wild are mixing up their own colorful pill recipes. The authors' intent is to detect and evade research environments. These virtual or sandboxed environments are frequently the sort of environments that security researchers have been using to automate malware analysis. We are seeing prevalent worms target VirtualPC, VMWare, and now Anubis for detection and evasion (Anubis is connected with an Austrian security group, somewhat similar in purpose to the very effective ThreatExpert).

Here is an assembly code chunk we extracted from an ITW worm. This code is an attempt to detect Anubis:
sub esp, 104h
lea eax, [esp+0]
push ebx
push offset aCInsidetm ; "C:\\InsideTm\\"
push eax ; str1
xor bl, bl ; status (bl) = 0
call ds:strstr

The disassembly matches up somewhat with some proposed Anubis-detecting c code fairly recently posted to an underground forum:
char ModulePath[MAX_PATH];
GetModuleFileName(NULL, ModulePath, MAX_PATH);
p = strstr(ModulePath, "InsideTm");
if(p != NULL) return true;

From some of the code posted recently on the same underground forums, Sandboxie's turn is coming up next.

The older VMWare detection used in the worm is a bit off color from the red pill itself. But it looks like a duplicate copy of what is showing up in the current valentine's day Storm worm variants we are seeing. The code is being used and reused in current malware:
mov eax, 'VMXh' ; VMWare magic number
mov ebx, 0 ; default
mov ecx, 0Ah ; get vmware version command
mov edx, 'VX' ; port #
in eax, dx ; read port
cmp ebx, 'VMXh' ; check vmware reply
setz [ebp+bool_VMWare] ; set vmware status accordingly
pop ebx
pop ecx
pop edx
jmp short @@check_vmware


Anyways, the good folks developing Anubis, and any researchers running automated sandbox technology on top of VirtualPC or VMWare should be aware that these functions are showing up today in prevalent password stealer dropping worms that we've seen rereleased multiple times each day for a couple weeks now.

If you attended VB2007 and checked out Sergei's talk, you'd have seen that ThreatExpert already solves this sort of little pill problem with a goat on a leash.

Help.exe still not much of a helper

One of the highest hitting worms that ThreatFire encountered over the past week is a worm designed to target online game player logins by dropping a password stealer and rootkit components on infected systems. We previously blogged about the help.exe component that drops rkd.dll, amvo0.dll and amvo.exe, and now we observe many more variants that are repacked with some fairly sophisticated packer and code perversion technology.

The password stealers themselves are updated on various websites that we have observed moving locations throughout China, repacked for AV and emulation evasion purposes. We also see ongoing server side polymorphism with the dropper.

The executables all display very unusual static PE characteristics. First, the import directory contains the name of one dll (kernel32) and imports only three of its functions (LoadLibraryA, GetProcAddress, ExitProcess), the bare bones minimum that you need for a PE packer:


























All of the section names are mangled, to further raise our suspicion:


























And finally, the resource section is huge and unrecognizable to a simple resource section parser (hint -- it contains more executable code):



























Unfortunately, effectively this incessant rate of change results in a low rate of AV scanner detection:


























If you are seeing a popup like this one, go ahead and quarantine the thing:

Dave's inflight thoughts

Dave Aitel, founder of ImmunitySec, sometimes comments on Halvar Flake's and Sabre security (oops, I mean zynamics) projects. They speak at a lot of the same conferences.

He just happened to be flying back from jfk when a few deep thoughts came to mind about evading the holy grail of automatic malware classification that he posted on DailyDave:
"Given that avoiding "behavioral signatures" is a matter of calling random NOP-like API calls (i.e. CreateFile + CloseHandle == 1 NOP), Halvar's program classification techniques involve a structural differencing engine. This has advantages (see his talk for details) in that program structure closely reflects the semantic meaning of a program, as interpreted by a compiler.
So the obvious way, from what I can tell, to defeat a structural differencing algorithm would be to do a static or dynamic analysis of your target program, and for each CALL opcode, change the destination to a dispatcher function. This dispatcher function can then be built to do a O(1) table lookup to find the true destination of the call."

I like the way Dave thinks. Unfortunately, other folks do too, and all sorts of evasive techniques are commercially available. That means the techniques are available to the bot herders, and it appears in our labs that the herders are distributing most of their bots packed with this stuff now.

Undetected bot activity

We're seeing a pretty dramatic uptick in bot activity today. With all the attention that botnet activity has been getting lately, I thought that this stuff was going the way of Ruben Studdard. Anyways, unfortunately, we are also seeing a very low detection rate for the major AV players, with most of the detections in the scanners supported by Virustotal coming from somewhat unreliable heuristic based detections:

File V received on 11.16.2007 21:22:05 (CET)
Antivirus Version Last Update Result
AhnLab-V3 2007.11.17.0 2007.11.16 -
AntiVir 7.6.0.34 2007.11.16 HEUR/Crypted
Authentium 4.93.8 2007.11.16 -
Avast 4.7.1074.0 2007.11.15 Win32:IRCBot-CFX
AVG 7.5.0.503 2007.11.16 Obfustat.VTU
BitDefender 7.2 2007.11.16 Packer.Krunchy.B
CAT-QuickHeal 9.00 2007.11.16 (Suspicious) -
DNAScanClamAV 0.91.2 2007.11.16 -DrWeb 4.44.0.09170 2007.11.16 BackDoor.IRC.Sdbot.2056
eSafe 7.0.15.0 2007.11.14 -
eTrust-Vet 31.2.5300 2007.11.16 -
Ewido 4.0 2007.11.16 -
FileAdvisor 1 2007.11.16 -
Fortinet 3.11.0.0 2007.10.19 -
F-Prot 4.4.2.54 2007.11.16 -
F-Secure 6.70.13030.0 2007.11.16 -
Ikarus T3.1.1.12 2007.11.16 Virus.Win32.IRCBot.CFX
Kaspersky 7.0.0.125 2007.11.16 -
McAfee 5165 2007.11.16 -
Microsoft 1.3007 2007.11.16 Backdoor:Win32/Poebot.V
NOD32v2 2664 2007.11.16 -
Norman 5.80.02 2007.11.16 -
Panda 9.0.0.4 2007.11.16 Suspicious file
Prevx1 V2 2007.11.16 -
Rising 20.18.40.00 2007.11.16 Trojan.Win32.Agent.vyl
Sophos 4.23.0 2007.11.16 Mal/EncPk-BP
Sunbelt 2.2.907.0 2007.11.16 -
Symantec 10 2007.11.16 -
TheHacker 6.2.9.132 2007.11.16 -
VBA32 3.12.2.5 2007.11.16 -
VirusBuster 4.3.26:9 2007.11.16 Packed/FRBR
Webwasher-Gateway 6.0.1 2007.11.16 Heuristic.Crypted

This low detection antivirus scanner rate may be due to the use of the kkrunch packer.
Threatfire has been identifying it as "Trojan.CnomBot".
The bots are all reporting back to a server in China. We'll keep you updated.

AVKiller making the rounds again

We're hearing more reports of AV killing bots being spammed in Europe again. Back in September, we posted an analysis of a driver that modifies the file system stack. In human terms, that means the driver disables most real-time anti-virus scanner functionality (it's the anti-virus software magic that can scan a file when you copy it to your drive, and immediately identify the file as malicious). Luckily, this time around, eighteen of the thirty-two scanners maintained on Virustotal detect the portion of this critter. It is the downloader that is emailed to users (when we first saw the file, detection rates were almost non-existent):


























The email message containing the AVKill/rootkit attachment is getting through spam filters this time around. The best advice, if you receive an email with an enticing subject line like "Free Hot Game" or "Free Sports Tracker" and the text of the message is nonsense, is to delete it immediately.

Are we ready for some football?

We've been receiving all sorts of new mail from the Storm threat's authors. The latest to arrive at our office accounts is a message appealing to football fans. With college and pro football underway in the states, this social engineering is sure to attract some individuals. Here is the text of the email message:

"Life as we know it is back, NFL season is open.
Know all the games, what time, what channel and the stats.
Never be in the dark again with this online game tracker:
http://ip.address.he.re"

Here is a snapshot of the site offering the "tracker.exe" file that potential victims will reach by clicking on the email message's link. DO NOT visit the site if you receive the email, and DO NOT download and run this "tracker.exe" file:






















Every link on the page, including the "Peyton Manning" link, will fail to download a couple of times, frustrating and confusing the user. Three's a charm, and the tracker.exe file will download to your machine. Again, do not download and run the file. It installs all sorts of rootkit components and executables that you do not want on your system.

The authors have been somewhat inconsistent with this version of the multi-layered threat. They haven't incorporated the commoditized exploits that attack Internet Explorer, Firefox and third party components like the Yahoo! Messenger into this web page, like they have on all of their other recent attack sites. The tracker.exe executable doesn't change with every download, either. Maybe we are very early on in this stage of the spam/website setup, or a different part of the group set this server up.
The location of this server, most likely another Mac OSX server, is somewhat unusual for this group as well. Geobytes tells us that it is located in Tujunga, CA:























Peyton Manning? They probably could have pwned my system with a Brett Favre link.

How do Storm and other current threats attack security solutions and silently maintain their presence on systems?

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:

How do Storm, NotFound and other threats infiltrate so many PC's?

As the trend continues to move away from exploiting system services and more commonly toward exploiting client applications like web browsers and third party plugins, our research has turned towards these threats and overturned some fairly new stones for the commoditized exploit packages currently in the wild. The Storm threat, and numerous others have been using these packages to deliver driveby browser and, in this case, third party plugin exploits. These sorts of threats have been very effective recently at compromising users' systems in order to build botnets and send spam, and steal passwords and other sensitive information.

Now, not only are these packages delivering repacked and crypted binaries via harmless looking but malicious web pages, but they are re-obfuscating the malicious content hidden on the web pages at very small intervals. The threats, at every level, are constantly changing.

We collected up these changing pages from multiple malicious web sites, de-obfuscated their code, and isolated each exploit with its shellcode to analyze them, and to identify any problems they might cause for security products. Here are some notes from our research on in-the-wild web exploits:

The code across malicious groups is becoming more and more similar. There most definitely is code sharing between the groups writing the exploits. Some of them are the exact same techniques for identical exploits.

One recent addition to the commoditized exploit packages that are bought and sold online that has not been much discussed is exploitation of a recently disclosed Yahoo Messenger vulnerability, with shellcode that evades some of the major av vendors’ security software.

The vulnerability effects a version of a component called the "Webcam Viewer Networking and Imaging" ActiveX component (ywcvwr.dll v2.0.1.4). Basically, an old-fashioned stack-based buffer overflow occurs because a 1023 byte buffer is set aside to store input for webcam functionality, but the input is not properly checked, allowing for maliciously crafted webcam objects to run arbitrary code of the attacker's choosing.

We examined the attacker's approach. They use a reliable method of delivering control to their shellcode on XP Sp2 and Vista systems over IE6 and IE7 with default settings: they spray the heap with shellcode of their choosing simply by creating a dozen or so variables in their javascript, and stuffing them with lots of NOP followed by shellcode. They then deliver a large amount of data (5000 bytes) to this unchecked 1023 byte buffer and overrun values on the stack, including the exception handler. An exception occurs, and because the exception handler is overwritten with an address on the heap, control is passed to their download and execute shellcode.

By default, this exploit works on Vista systems when IE6 and IE7 do not have the "Data Execution Prevention" feature enabled. But techniques to disable the DEP check even when it is enabled have been published as well.

This image shows the thread stack as it is overflowed. An exception has been caused at this point, and we break on it to notice that the stack is covered with “\x0a\x0a\x0a\x0a”.

When this exception occurs, we can take a peek at the exception handler, which also is stored on the stack. It has been overwritten with “\x0a\x0a\x0a\x0a” as well. Because the exception has been thrown, our goat system tries to provide control to the first handler in the list, which happens to be at the craftily overwritten “0a0a0a0a”.

Interestingly, the heap has been sprayed with shellcode because the javascript sets up multiple variables full of shellcode. Due to this spray, the location “0a0a0a0a” now points to “0c0c0c0c”, which also is located on the heap. This heap contains two things – a nop sled of "0c0c0c0c" and “download and execute” shellcode.

Control will slide down the sled to our shellcode, and the attackers will effectively download and execute a set of binaries stored on another web server. These binaries download and execute even more malware, including bots, rootkits, password stealers, adware and other problematic software.

They keep coming! Another Yahoo webcam viewer vulnerability has been discovered and its exploit posted by a Chinese security group without having notified Yahoo, so we’ll keep an eye on this 0day as well and probably post on it. We’ve looked through the code, and it attacks a heap overflow instead of a stack overflow like this one, but methods to effectively defend against it remain the same.

Beware web sites and links that you have not visited before, especially if they are sent to you via email, and update your security software. Buffer overflow exploits like this one can turn an unwitting user into a victim.