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 returnKassner: 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.
The cat and mouse game continues. Thanks to people like Mr. Mathur, we have a fighting chance.
Michael Kassner is currently a systems manager for an international company. Together with his son, he runs MKassner Net, a small IT publication consultancy.