Security

Forged memory fools antimalware: A new development in rootkits

Malware developers are deploying a new stealth technology. Michael Kassner interviews an expert who explains how some rootkits forge memory to outwit antimalware programs.

Rachit Mathur, Senior Antivirus Researcher for McAfee, was investigating what he assumed to be a variant of the TDL3 rootkit, known for hiding the infamous Google Redirect Virus. But, it was acting weird. Mr. Mathur explains:

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.

Mr. Mathur adds:

The reason for hooks not being reported was that the memory being read by the tools was not the actual memory!

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.

How is that possible?

I immediately wondered, "How in the world did he figure that out?"

His background offers a clue. Mr. Mathur has a M.S. in computer science specializing in reverse engineering, program transformation, and metamorphic malware. And, he has published in numerous venues: Journal in Computer Virology, Virus Bulletin, International Conference on Information Warfare, and IEEE International Workshop on Source Code Analysis and Manipulation.

That also explains the detail presented in his McAfee Labs blog post: Memory Forging Attempt by a Rookit. I tried to understand. But, pointers, register settings, and debug routines got the best of me. Knowing this is too important to screw up, I enlisted the help of Mr. Joris Evers of McAfee Corporate PR and Mr. Ian Bain of H3O Communications to connect with Mr. Mathur.

Kassner: I confess. I do not grasp how memory forging works. In lay terms, could you please describe what's going on? Mathur: Let me provide some background. Rootkits typically modify certain areas in the memory of the running operating system (OS) to hijack execution control from the OS. Doing so forces the OS to present inaccurate results to detection software (anti-virus, anti-rootkit).

For example rootkits may hide files, registries, processes, etc., from detection software. So rootkits typically modify memory. And anti-rootkit tools inspect memory areas to identify such suspicious modifications and alarm users.

This particular rootkit also modifies a memory location (installs a hook) to prevent proper disk access by detection software. Let us say that location is X. It is noteworthy that this location X is well known for being modified by other rootkit families, and is not unique to this particular rootkit.

Now since the content at location X is known to be altered by rootkits in general, most anti-rootkit tools will inspect the content at memory location X to see if it has been modified.

Kassner: Sorry to interrupt, but I wanted to mention, this is where the rootkit gets sneaky. Mathur continues: In the case of this particular rootkit, the original (what's expected) content at location X is moved by the rootkit to a different location, Y. When an anti-rootkit tool tries to read the contents at location X, it is served contents from location Y. So, the anti-rootkit tool thinking everything is as it should be, does not warn the user of suspicious activity. Kassner: You mention locations X and Y. My immediate thought is: If antimalware checks location X, why place the malware information at that location? Mathur: Malware changes the content at location X because the operating system (OS) uses location X to call OS-specific code that handles access to disk. That way during disk access, the malware gets to decide if it wants to allow access to the files being requested by a program or the planted malcode. This is called a dispatch table hook or IRP hook. Kassner: Are you saying the malware is intelligent enough to know what program wants access to location X? Wow. I'm afraid to ask, but how does it do that? Mathur: The malware definitely needs to determine where the read query is coming from. Only then will it be able to make sure the OS reads the 'actual' contents at location X and ends up calling the malware code that inspects disk access. Whereas other programs (including anti-virus) read the 'fake' contents at location Y.

When a read access occurs at location X, due to the CPU hardware breakpoint being set, an exception is triggered. Since the malware also modifies an OS variable named KiDebugRoutine, the malware code gets control when such an exception is triggered.

Here the malware is able to ascertain the address of the instruction that is trying to read. The malware compares this address with a pre-defined list of addresses that the malware wants to allow access. These addresses either belong to the OS or to the malware itself.

If the address of the instruction performing the read matches one of the pre-defined ones then the malware does not forge memory. The code that does this can be seen on the blog in figure "KiDebugRoutine Handler: Snippet 3".

The following code compares against one such pre-defined address. If it matches then the exception is set as handled without forging the memory and the execution will resume to read the 'actual' contents:

cmp   eax, dword_41D810 ; compare EIP with pre-defined locations that are allowed to read correct memory

jz   loc_403BC5  ; set as handled and return

Kassner: Does this rootkit have a name? Mathur: McAfee detects it as TDSS.e!rootkit. Kassner: I'm really curious. How did you determine the rootkit was forging memory? Mathur: When analyzing this malware sample, some common tools did not report any suspicious rootkit-like activity. But, further analysis and debugging revealed there was indeed a hook. And, it was located at a memory location where those tools commonly inspect. Yet, they did not report finding a hook. This was bizarre and really caught my attention.

Fortunately, the malware's implementation is not perfect. That became apparent during my investigation. I observed that two different methods used to inspect the same memory area were returning different results. That was an unexpected clue.

Because we knew what we were looking for, it did not take long to realize that a hardware breakpoint (DR0 register) was set to location X and malware was trying to protect it. The rest was typical reverse engineering to figure out the details of its workings.

Kassner: Is this something we can expect more of? Or since you now know it is actively "in the wild", will malware developers move onto something different? Mathur: That's a good question. Now that the technique is known to be used out there, we will certainly see anti-rootkit tools adding features to cope with this, like watching for hardware breakpoints before accessing memory or looking for KiDebugRoutine hooks, etc.

One would not expect this technique to become popular across many different malware families due to the need for setting a hardware breakpoint. Because, it is easy to avoid falling into this trap once you know about it.

But, updating anti-rootkit features take time. So, we may see this being used by a few versions of malware. And, we expect to see variations in the implementation details.

It is interesting to note that sophisticated malware will likely adopt this first. While less-intricate malware incorporate it, more slowly, extending its use. What actually happens is anybody's guess, but these seem reasonable possibilities.

Kassner: As users, how do we avoid memory-forging malware? Mathur: From a user perspective, normal precautions like safe browsing and keeping software up to date will help. Also, detection software may need updating to cope with this. So users should get the latest version and always have current anti-virus definitions. Kassner: In the blog, you alluded to the fact that this was a known technique, but not actively used. Are any other new and sneaky techniques looming on the horizon? Mathur: This technique has been mentioned in the past, but there were no reports of it being used by malware, until now. Unfortunately, we have not seen the last of such techniques. We expect malware authors to continue adopting and innovating better ways to hide.

This is something we intend to discuss at this year's Virus Bulletin Conference, along with our predictions of what might be coming.

Final thoughts

The cat and mouse game continues. Thanks to people like Mr. Mathur, we have a fighting chance.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

92 comments
gibsonkapokosa
gibsonkapokosa

I find this article particulary useful in educating users on the danger and difficulties in detecting and removing malware. Some users I have encountered erroneously believe that as long as they have up to date anti-malware software they would stay free from malware. they also believe that detecting and removing malware is a straight forward job, which clearly isn't

SkyNET32
SkyNET32

One on my mac right? Or would there have to be some pop-up asking me for my password for something that I didn't install intentionally, right? ;) @jacqui, That rootkithunter isn't compatible with mac past 10.3.8. @michaelKassner, That was a great article/interview with Charlie Miller. I'm going to send it to a "mac fanboy" friend of mine and say "ah ha!" :D

SkyNET32
SkyNET32

@michael Kassner, thanks for the links on Mr. Miller. I will certainly read up on it. @Jacqui, thank you, I believe then, by your first sentence that that is no longer the case? Rootkits for Unix systems may no longer need your password? @JCitizen. HAHA! I have to agree also, but being a Librarian, I like to stay on top of these topics and see what everyone else is saying across the Internet, even if yes, sometimes they do make my gums ache. ;)

SkyNET32
SkyNET32

He had about a working exploit for the Mac. People bashed him in the comments section and the thread (as usual) turned into a Mac "fanboi" vs MS argument. I wanted to ask a question but figured I'd get drowned out by all the bickering; There is this notion of the 'privilege escalation' syndrome, where folks say, the only way (on a mac only?) malware would "burn you" is if the user allowed it to (you have to provide your password - is that correct?) So, my question is, isn't there malware (for the Mac and Windows for that matter) that can override the OS's built-in "please provide your password or I won't let you execute" security feature? Discussions about "the problem lies between the keyboard and your chair sir" aside, can malware in fact, be sneaky and smart enough to not need a user's password to infect a machine, Mac or otherwise? I thought I'd ask here to see if it is in fact true or not. It seems to be a mantra among Mac users that "there is no malware in the wild for the mac". I have a mac myself and I Bootcamp it with Windows 7 (I'm so proud of myself! :D) and I like them both so, I'm not partial to either one. Can anyone help with this question? Thanks, Philip P.S. Forgive me if I sound pretty dumb, its been a while since I've listened to a Steve Gibson podcast. XD P.P.S Oops, I forgot to supply the Bott article if anyone was wondering http://www.zdnet.com/blog/bott/coming-soon-to-a-mac-near-you-serious-malware/3212?tag=mantle_skin;content

pgit
pgit

I've always wondered why there can't be some form of randomization of memory locations that would thwart any attempt at an exploit because the malware writer would have no way of targeting a given function, seeing as it'll be a different address at every boot. Sort of like a benign root kit. I know windows does a modicum of randomization of memory allocation, but that's way up the food chain at the application level. Maybe there's just too much overhead for such a thing to work. But maybe a modular approach could work, have the three basic files that load the OS bump their base up or down a block or two and translate all calls, the math should be simple, but I bet the hardware simply won't allow enough randomization. I know nothing about low level coding, I suppose I shouldn't speculate about such things. I've also often wondered if there isn't a physical, non code-based way to detect a root kit, say an anomaly in the radiation field emitted by the processor. Have a micron sized starship Enterprise hovering over the CPU checking it's surface for anomalies with the sensors... :)

OldGuru
OldGuru

Pre-boot scans, provided the AV has the rootkit's signature, are not fooled by this exploit simply because scan is performed before operating system is loaded. I know Avast provides such scan. But there is another thought that's bugging me; even if AVs have the right signatures, still rootkits can get around pre-boot scans by encrypting themselves and storing the encrypted copy with the encryption key on the disk in a, say, jpg file. At boot time, instead of the rootkit, a simple "loader" can be loaded to load and decrypt the rootkit, re-encrypt it with another random key, and save it to the disk. Even a simple scrambling technique, such as XORing the code with a randomly generated pattern, can ensure the rootkit is not detected in a pre-boot scan. The loader itself is not detected because it is not a malware itself and AV's don't look for it. Even if they do, it's much easier to create different variants of a simple loader than the rootkit itself.

Rodneyfarr
Rodneyfarr

whats to keep this memory at restart...say place in memory at shut down write to hd then on restart write to memory and delete hd files

seanferd
seanferd

Thanks to Rachit Mathur, Joris Evers, Ian Bain, and Michael, et al. As users, how do we avoid memory-forging malware? Excellent question. Conficker, you know, still owns millions of computers.

AnsuGisalas
AnsuGisalas

I wonder how long it will take before we see malware inserting into the hypervisors. Let's just hope there are few vulnerabilities to allow it...

Spitfire_Sysop
Spitfire_Sysop

Can you let us know when there is a software that implements the new detection routine? The only blip about this is "updating anti-rootkit features take time" so I imagine that there is currently no automated detection available?

Slayer_
Slayer_

Or is this something that any OS could fall victim to?

Craig_B
Craig_B

It seems the rule is whatever gets in the lowest starting position wins. That is, if malware gets into a low level before the OS/App can get a hold it wins and if the OS/App gets there first it wins.

Editor's Picks