Memory Forging Attempt by a Rootkit

Some time ago a new rootkit appeared that at first glance seemed more similar to initial variants of TDL3 than to the updated TDL4 variants we have seen this year. Like TDL3, it also parasitically infected a driver by inserting code in the resource directory of the PE file. In this case the name of Read more…

Some time ago a new rootkit appeared that at first glance seemed more similar to initial variants of TDL3 than to the updated TDL4 variants we have seen this year. Like TDL3, it also parasitically infected a driver by inserting code in the resource directory of the PE file. In this case the name of the file it infected was hard-coded to volsnap.sys. Also similar to the early variants of TDL3, this rootkit also hooked some pointers in the dispatch table (IRP hook) of the driver below disk on the device stack of the hard disk.

But it was very interesting to see some of the anti-rootkit tools not showing the dispatch table hooks that are usually pretty straightforward to identify. Also this malware would not allow an external debugger (WinDbg) to break, which was annoying.

The reason for hooks not being reported was that the memory being read by the tools was not the actual memory! The dispatch table as “seen” by the tools appeared not to be hooked–whereas in reality it was hooked. The part that made it interesting was that the memory was being read at the correct address with a mov instruction and not using some system API that could be hooked. We know of some proof-of-concept ways to achieve this, but I had not seen this behavior before from a threat in the wild.

Obviously the motivation for malware authors to use such techniques is to prevent tools from showing their hooks so that administrators are not alarmed of suspicious activity.

So how does it fake memory on read access? This rootkit is using hardware breakpoints (DRX register setting) to monitor access to memory areas of the kernel that it patches. In addition to modifying the DR0 register, it hooks the KiDebugRoutine pointer so that it gets notification when the hardware breakpoint is encountered due to memory access. This rootkit installs IRP hooks and sets the DR0 register to the memory address where the IRP hook is installed. So when the memory of the dispatch table is read, a “fake” image with no hook in it is presented by the malware’s KiDebugRoutine hook. Here is a brief overview of the KiDebugRoutine hook code.

This is the beginning of the malware’s KiDebugRoutine handler code. If it encounters a breakpoint, then the malware simply increments the instruction pointer for the thread where the exception occurred and returns it as handled. Otherwise we take the jump.

Image here

KiDebugRoutine Handler: Snippet 1

Next comes the target from the above jump (loc_403BCC). If the exception occurred at a kernel mode address, then we jump to loc_404026.

image here

KiDebugRoutine Handler: Snippet 2

At the target of the above jump, first the exception is processed normally by checking access flags, clearing the DR6 register, etc. Then the following code is used to identify if this is a read access to the protected memory and if the malware wants to block this particular access. If both of these conditions are true, then the read location is altered to point to a memory area with contents the malware wants to forge. Thus anyone who the malware does not like ends up reading the wrong memory. The comments in the code below explain the details. The assumption about ESI in the code below is interesting.

image here

KiDebugRoutine Handler: Snippet 3

This technique has been discussed before, and this example shows again just how modern rootkits are adopting techniques and evolving rapidly. In fact, after this malware we have seen yet another update in the master boot record infecting the TDL4 strain that is still using DKOM to put a  fake device object on the device stack of the hard disk. At McAfee Labs we will continue to investigate and provide protection against such threats.

SQL Slammer Worm Regains Momentum

At McAfee Labs every day we monitor millions of intrusion prevention systems (IPS) alerts from our sensors around the world. From these alerts, we often see interesting global data and trends. Recently, ISC noticed a sudden decline of Slammer traffic in the wild, which we also noticed on our sensors. The infamous Slammer was a Read more…

At McAfee Labs every day we monitor millions of intrusion prevention systems (IPS) alerts from our sensors around the world. From these alerts, we often see interesting global data and trends. Recently, ISC noticed a sudden decline of Slammer traffic in the wild, which we also noticed on our sensors.

The infamous Slammer was a rapid-spreading worm that started on January 25, 2003. It targeted Microsoft SQL Server, and the worm traveled over UDP on port 1434, which contributes to its rapid spread. It is incredibly noisy, and it really never went away, even though the worm is eight years old!

To our surprise, the amount of traffic that we detect dropped significantly in early March, and we do not yet know the reason for the decline. What we have noticed, however, was that alerts for Slammer started to reappear early this month.

I guess we will be seeing more Slammer alerts for a while.

LizaMoon the Latest SQL-Injection Attack

Working in the security industry brings about a myriad of challenges. This is especially true for vendors. We must do our best to educate and inform. At the same time, we want to avoid laying on the FUD–or scaring customers into making poorly educated security decisions. Which brings us to the recent LizaMoon attacks. There Read more…

Working in the security industry brings about a myriad of challenges. This is especially true for vendors. We must do our best to educate and inform. At the same time, we want to avoid laying on the FUD–or scaring customers into making poorly educated security decisions.

Which brings us to the recent LizaMoon attacks. There is an incredible amount of highly generic and vague information floating around. The fact of the matter is on-going SQL-injection attacks are a fact of life. They are not the only ones, either; every day there are mass spammings of new pieces of malware. Every week we see thousands of new “fake-alert” Trojans (a.k.a. rogue or bogus AV/security products and scams). And fake-alert is just one of the millions of static malware examples that we deal with on a constant basis.

So how should we respond? Do we toot our own horn and blast everyone with a gargantuan list of countermeasures for any and all threats? Do we wait and see how the industry reacts and then do what everyone else does?

Without getting too philosophical, I’ll cut to the chase.

What’s In a Name?

The LizaMoon attack is named after one of the domains referenced in the script code that gets injected into compromised pages.

Example: <script src=http://lizamoon[dot] com /ur[dot] php >

Lizamoon.com is not the only domain associated in this way. In the days since we started tracking this event, we have added many others. As of this writing we know of around 40 (give or take a few). If you are looking to block traffic to the malicious domains, this is where you want to focus your efforts. We have seen some recommendations to block all associated domains–even those that have been compromised (the valid sites that were victimized by the attack). This step may be overly paranoid. We do not necessarily need to block traffic to all these legitimate and well-meaning sites (by some estimates the count is up to 1.5 million) to protect against this and similar threats.

Make Me Feel Secure !

The injected scripts redirect clients to sites that are known to host fake/rogue/bogus security software. There are tens of thousands of write-ups on this fake-alert family on our Threat Intelligence site, and it’s one of the most prevalent families of static malware that we deal with.

The particular package associated with this attack is detected as follows:

Name: FakeAlert-PJ.gen.c
DAT: 6304
Release Date: April 2, 2011
Info: http://vil.nai.com/vil/content/v_348729.htm

Malicious hosts associated with this attack (for example, lizamoon.com) are categorized as malicious by our Web Reputation Service (http://mcaf.ee/92e06). Multiple McAfee products, at various layers of defense, use this intelligence to block traffic or filter out the bad stuff. McAfee Firewall Enterprise and McAfee Host Intrusion Prevention are just a few examples. More details on McAfee GTI Reputation and Categorization Services can be found here: http://mcaf.ee/92e06

The network side of the SQL-injection attack is detected through the McAfee Network Security Platform. The signatures that pick up this particular attack are approaching one year old (sig: HTTP: SQL Injection – evasion III in Releases 4.1.74, 5.1.44, and 6.1.11).

Where’s the Beef?

This is a SQL-injection attack. Before any of us blow our IT budgets on database security goodies, we must all take the basic first steps. Simple and core techniques, such as constraining user input, validating user input, limiting types of input, encrypting sensitive data, and designing accounts with the principle of least privilege will go a long, long way.