Personally, I don’t think it is very wise to rely entirely on online malware elimination (ie. deleting them while running on the infected OS): you can not be entirely sure the system is clean afterwards, especially since rootkits have become so popular since the last years. The best ways is to boot from a clean media and remove the infections both with virus scanners and manual inspection, most importantly in all the entries in the system a program can insert itself into to ensure it gets run without user intervention sooner or later.

Autoruns, a tool from Mark Russinovich (Technical Fellow at Microsoft), is the tool of the trade for this task. Think of it as a MSConfig on steroids. If you are a regular follower of this blog, then you’ll know that I have the utmost respect for Mark… and this time, I must admit it might have blinded my judgement a bit as I probably trusted the tool’s output more than I should have…

So, Regedit didn’t want to run anymore and that was unacceptable to me: for some reasons, the machine couldn’t be rebuilt immediately (the best choice to recover from infections), which meant that I had to fix the issue. I do not mind this at all actually: restoring a system image is the easy way to fix problems: there is a problem, it gets fixed by restoring the clean image, but you never get to understand the “Why”… Understanding the reason why things happen is sometimes as important as fixing the issue itself: some day, this knowledge would be really useful and it is what raises your experience: overusing an imaging software isn’t going to make you a better professional, no matter how many times you use it.

Debugging and troubleshooting always seems to me to be a process very similar to medicine diagnostics: a patient (in our case, a computer) shows some symptoms of a disease and you must figure out what he has. Just like in any typical House MD episode, a patient with a strange pathology arrives and we need to hypothesize from the symptoms to establish probable causes, which ultimately leads to the main issue. One of my first hypothesis was that the virus disabled these tools through the “Image File Execution Option” registry entry (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options). One of this entry’s legitimate purpose is to automatically attach a debugger to a process as soon as it starts running, which is very helpful in some debugging scenarios. The problem is, that the way it is implemented, it also creates a rather big security issue as it allows to have an executable running instead of another one…

Under the hood, what happens is that the OS checks this registry key before actually launching any executable: if it finds an entry for the executable being started, it looks at the “Debugger” entry. This entry contains the executable that will be used to spawn this process as a child, most of the time, when used legitimately, a debugger, in particular ntsd, which is the debugger coming with the WinDBG debugging suite from Microsoft. For example, if there is an entry for Regedit.exe under this registry key and that the corresponding “Debugger” entry is “ntsd –d”, what is going to be executed is actually “ntsd –d regedit.exe”, which ultimately attaches regedit.exe to the debugger automatically without any kind of user interaction. On a normal system, ntsd never actually appears on screen as it only works if a kernel debugger is attached to the machine, which makes it an interesting way to completely prevent the execution of any chosen executable.

This technique is an old trick used by the more clever viruses in an attempt for them to prevent their removal and disable some anti-virus processes, so they can live their lives without being bothered: it has become to be known as the “Image Hijack” technique, as like with a plane hijacking, the originally planned destination is changed to a different one and controlled by a third process. Autoruns has a tab specifically designed to detect these entries, so I ran it directly from the web-site (http://live.sysinternals.com/autoruns.exe). I have taken the habit to immediately tick the menu options “Hide Microsoft Entries” and “Verify Code Signature”. Autoruns is comprehensive, which is a good thing, but also means the output can be very verbose and contain a lot of entries, the vast majority of them coming from the OS and being signed by Microsoft itself. As AuthentiCode is quite reliable, it is unlikely (unless it patched the AuthentiCode DLLs, of course) that some malware could fake the digital AuthentiCode signature used by Microsoft (which is most likely one of the most access-restricted resource in the company… imagine the consequences if this ever got leaked…). This has the benefit of hiding the entries to a lot of legitimate and trustable files, that we know for sure have not been modified, thanks to Autoruns checking the AuthentiCode signature of the files corresponding to each of the entries, so we can focus on the third-party processes, and look for the suspicious ones much easier and faster. I checked on the main tabs to ensure that I didn’t miss any rogue process and then went to the “Image Hijacks” tabs, which was empty! My first assumption was proven wrong and I had to switch to the next one.

Autoruns: no Image Hijacks detected
Autoruns: no Image Hijacks detected

I was aware of some Group Policy entries whose purpose is to disable several system administration tools to prevent users (or software) from messing with them, but these were not enabled either. I then checked the signature of the regedit files and everything was fine. I scratched my head, and noticed that everytime I tried to run regedit, the cursor changed to the hour-glass, which was implying the system was doing something, presumably launching a process… Was this process regedit.exe, which didn’t manage to run completely for some reason? I decided to find out by running another tool from Mark Russinovich, Process Explorer. Process Explorer is like the big brother of the classic Task Manager and is very powerful (can do awesome things like easily showing the call stacks of any threads in a process etc) and one of its useful features in our case is that when a process starts and exists immediately, it will still remain on the Process Explorer’s processes list for some seconds. I left Process Explorer open and tried to run Regedit from the Run box. I immediately noticed the following command “ntsd –d regedit.exe” appearing in the list. It was clearly an image hijack!

How come that such a reliable and well written tool from one of the biggest Windows experts on the planet failed to report these entries? It could have been a rootkit but a rootkit can easily prevent executable launching without having to rely on the image hijack technique. But… coming to think of it, isn’t ntsd.exe a Microsoft tool, and isn’t it Authenticode-Signed? I restarted Autoruns, went back to the Image Hijacks tab, which was as empty as before. However, this time decided to untick the “Hide Microsoft Entries” and “Verify Code Signature” and a bunch of entries suddenly appeared in front of my eyes… All these entries were actually hidden by Autoruns itself! The reason for this is that the “Debugger” registry entries contained the “ntsd.exe –d”, which allow the debugger to automatically attach to these processes as soon as they are executed. Autoruns scanned the process in that entry, ntsd.exe, which was a legitimate and untampered and signed Microsoft executable.

Autoruns with Hide Microsoft Entries disabled: it sure is crowded in there…
Autoruns with Hide Microsoft Entries disabled: it sure is crowded in there…

This option, used on this tab, is rather misleading and I’ll post a recommendation for the behavior to be changed. While admittedly, the tool behaved as it was supposed to technically, these entries still were created by illegitimate software and disabled important security tools, such as the most common antivirus services, regedit. The fact that the tool used by the hijack was from Microsoft and dutifully signed is to me irrelevant, as these entries were created by a malware who used a legitimate tool as a stub to its advantage to prevent other process from launching. Legitimate entries in the Image Hijacks are rare, rare enough, from my point of view, to consider showing entries even if they are Microsoft-signed as it isn’t going to pollute the view and can likely avoid other people falling in this trap…

In the end, the morale of this story is that we shouldn’t rely on our tools too much as they can sometimes act in a surprising manner or at least not as we though they would, no matter how many times you have used them before and no matter how highly you regard its authors…