Mark Russinovich’s technical blog covering topics such as Windows troubleshooting, technologies and security.
Continuing the theme of focusing on malware-related cases (last week I posted The Case of the Malicious Autostart) as a lead up to the publication on March 15 of my novel Zero Day, this post describes one submitted to me by a user that took a unique approach to cleaning an infection when faced with the apparent inability to run Sysinternals utilities.
More and more often, malware authors target antivirus products and Sysinternals utilities in an effort to maintain their grip on a conquered system. This case began when the user’s friend asked if he’d take a look at his computer, which had begun taking an unusually long times to boot and logon. The friend, already suspecting that malware might be the cause, had tried to run a Microsoft Security Essentials (MSE) scan, but the scan would never complete. They also hadn’t spotted anything in Task Manager.
The user, familiar with Sysinternals, tried following the malware cleaning recipe I presented in my Advanced Malware Cleaning presentation. Double-clicking on Process Explorer resulted in a brief flash of the Process Explorer UI followed by the termination of the Process Explorer process, however. He turned to Autoruns next, but the result was the same. Process Monitor had the same behavior and at this point he became convinced the malware was responsible.
Malware can use numerous techniques to identify software that it wants to disable. For example, it can use the hash of the software’s executables, look for specific text in the executable images, or scan process memory for keywords. The fact that any small unique attribute is all that’s needed is the reason I haven’t bothered implementing mechanisms aimed at preventing identification. It’s a game I can’t win so I leave it to the ingenuity of the user to figure out a workaround. If the malware is simply keying off the names of executables, for instance, the user could simply rename the tools.
What makes this case somewhat ironic is that malware authors have long used various Sysinternals tools themselves. For example, the Clampi trojan, which spread in early 2009, used the Sysinternals PsExec utility to automatically spread. Coreflood, a virus that stole passwords in mid-2008, also used PsExec. More recently, Chinese hackers used Sysinternals tools to attack oil refineries. Malware authors even hijacked the Sysinternals brand by releasing a “scareware” product – malware that presents fake security dialogs to lure you into buying fake antimalware – named Sysinternals Antivirus:
Back to the case, the user, wondering if the malware was looking for particular processes or simply scanning for windows with certain keywords in their title bars, opened notepad, typed some text, and saved it to a file named “process explorer.txt”. Sure enough, when he double-clicked on the new text file, Notepad made a brief appearance before exiting.
Locked out of his usual troubleshooting tools, he wondered if there might be some other Sysinternals utility that he could leverage, browsed to the Sysinternals utilities index and scanned the list. Just a few tools down, the Desktops utility caught his attention. Desktops lets you create up to three additional virtual desktops for running your applications and use hotkeys or the Desktops taskbar dialog to quickly switch between them. Maybe the malware would ignore windows on alternate desktops? He launched Desktops using its Sysinternals Live link (which lets you execute the utilities off the Web without even having to download them) and created a second desktop. Holding his breath, he double-clicked on the Process Explorer icon – and it launched!
This particular malware presumably has a timer-based routine that queries window title text and terminates processes that have titles with blocked keywords like “process explorer”, “autoruns”, “process monitor” and likely the names of other advanced malware-hunting tools and common antivirus products. Because a window enumeration only returns the windows on a process’s current desktop, the malware was not able to see the Sysinternals tools running on the second desktop.
He didn’t spot anything unusual in the Process Explorer process list, so he launched Process Monitor (I would have tried Autoruns next). He let Process Monitor capture a couple of minutes of activity and then began examining the trace. His eye was immediately drawn to thousands of Winlogon registry operations, something he normally didn’t observe when he ran Process Monitor. Guessing that it was related to the malware, he set a filter to just include Winlogon and took a closer look:
Most of the operations were registry queries of values under a key with a bizarre name, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Notify\acdcacaeaacbafbeaa. In order to start every time Windows boots, the malware appeared to have registered itself as a Winlogon notification DLL. Winlogon notification DLLs are commonly used by software that monitors logon, logoff and password change events, but are also often hijacked by malware. To confirm his suspicion and find the name of the DLL, he right-clicked on one of the entries and selected “Jump To” from the Process Monitor context menu. In response, Process Monitor executed Regedit and navigated to the referenced key:
The DLLName value pointed at the malicious DLL, which had the same name - probably randomly generated – as the registry key. He knew at this point that the malware was probably interfering with the MSE scan, but armed with the name of the DLL, he wondered if MSE might be able to clean that specific file. Before he tried that he tried a full scan, weakly hoping that the malware wouldn’t detect the execution on the second desktop, but was unsuccessful. He launched MSE again and navigated the file-scan dialog to the DLL. A couple of seconds later MSE completed the analysis and reported that it both knew the malware and was able to automatically clean it:
He pressed the recommended action button and MSE quickly dispatched the malware. As a final check, he rebooted the system. Sure enough, the system booted quickly and the logon was fast. He was able to run the Sysinternals tools on the main desktop and Process Monitor’s trace was devoid of the malicious activity. With the help of a Sysinternals tools, he had vanquished the Sysinternals-blocking malware and successfully closed the case.
I am the guy who provided this case so it's fun to see it's on Mark's Blog getting wider circulation. I am under the same mentality that computers should be wiped after they are infected, tracking down all the changes the virus makes is a pain. In this case the person didn't have the CDs that usually come with the computer and at some point they had screwed up the recovery partition. It was a home users computer.
I even game the disclaimer they should pay to get the CDs and they said eh. They didn't pay me anything so I was not going to pay for the CDs.
Looking forward to your book Mark. Love a Thriller and at least this time I won't be critiquing the tech aspect.
@Todd Thanks for sharing your case and I hope you like Zero Day!
The maleware checks the registry every couple of seconds and redisables the registry and task manager.
I had to write some vbscript to enable registry keys, First I wasn't aware completely of what registry keys the malware used to modify, so I used process monitor to guess that and everytime I found out that a different process did this.
No, it doesn't register itself as a debugger, since I have windbg configured as a postmortem debugger, can you register two debuggers at the same time?
@Todd So you've read Digital Fortress too, eh?
I've fought with malware that kills off processes when you launch them. One workaround I've found is to rename the executable. 99% of the time they won't figure that out.
Our support service uses LogMeIn for accessing PCs and servers from remote. One of the very handy features of it is the ability to pull up a process list and kill applications there as well as directly editing the registry without ever having to spawn a separate process. Very handy for stubborn malware that won't die quietly.
@Todd, No computer I've purchased in the last six years came with an OS disk. These aren't high end machines, and something that OEM's do to be a few dollars cheaper than the other guy is to not provide an OS disk.
I don't mean to diminish the value of these posts. There are situations where imaging can't be done immediately, and this info can be butt saving.
@SQB - Not that one, no but many other books, as well as movies I have watched.
@jader3rd - Sorry Usually wasn't the right term. I actually run a large network and but occasionally help some friends so my language doesn't always match. :) This computer was over 6 years old, and they had CDs when they got it but couldn't find the, :(
Years ago malware just checked process names and not window titles - all you had to do was rename your executable. I remember one time where we were able to get regedit to run in a similar situation by renaming and replacing the default screen saver before booting into windows. After 2-3 minutes of idle the "screensaver" regedit.scr pops up - still an awesome hack.
It's only a matter of time before the Malware also blacklists "Desktops.exe"
I have just used comboFix to get rid of a rootkit. The attack was noticed when mse failed. When I tried sysinternal tools, process explorer and autoruns were blocked. I downloaded MS Malware tool and tool was kicked out after running 10 seconds. Desktop could not fool the rootkit. I followed steps from Mandatory Steps Before Requesting Assistance at dslreports. Every tool was tried in the order they appeared in the article until ComboFix was used. ComboFix took care the rootkit and returned me a clean XP. BitDefender bootup disc also failed to detect the rootkit. The rootkit planted c:\windows\daemon.dll.
Wow, who would have thought desktops would do this. Great thought process here !