The Case of the Sysinternals-Blocking Malware
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.
Comments
Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Wow, who would have thought desktops would do this. Great thought process here !Anonymous
January 01, 2003
Very interesting. It has been a while since I read such an interesting case in your blog, Mark. Thank you. Although, I'd probably have tried using Sysinternals tools offline, where malware are unarmed, unaware and sleep. Ironically, movies try to convince us that killing a person while asleep is an atrocity. But again, malware aren't people.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
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:windowsdaemon.dll.Anonymous
January 01, 2003
@Todd Thanks for sharing your case and I hope you like Zero Day!Anonymous
January 01, 2003
Who would have ever though to use Desktops in their troubleshooting. That was just brilliant. I agree with Nick, just the insight to use Desktop was key. I'll keep this tool handy as well. Mark have you ever guess Desktops would be used in a troubleshooting scenario? . Who knows, in the future, Zoomit might even be used to as a troubleshooting tool ;) Thanks again for awsome case and demonstration of tools!Anonymous
January 01, 2003
Interesting. Mark, a while ago, some malware infected my pc,it used to disable task manager and regedit.exe, I tried to follow it using Process monitor, process explorer and autoruns but nothing was clear, and what I found out is that it used to inject processes, so how to figure out such a case, since I looked into Appinit_dll using autoruns and nothing appeared there. thanks MarkAnonymous
January 01, 2003
@santosh, 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. @Thomas: 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?Anonymous
March 08, 2011
The insight to use Desktops is the key to this episode, and really is a great idea. Adding that to my toolbelt alone made this worth the read. Thanks!Anonymous
March 08, 2011
I believe if desperate you can boot from another drive, and run autoruns on the infected drive. I would in the end just reimage the drive if I could, never being 100% sure if all the malware was gone. Not tweeting the blog posts anymore?Anonymous
March 08, 2011
I agree with tam. Sysinternals tools are excellent and really helpful for tracking down and eliminating malware, but many times the damage to windows is far and spread. Some malware tweaks a lot of registry entries, sets numerous annoying group policy settings and even changes NTFS and registry permissions. Undoing that damage is time-consuming and what's worse is that you can never be totally sure you've repaired everything. Nowadays is just simpler and eaiser to re-image the drive with Microsoft's IMAGEX and be done with it.Anonymous
March 08, 2011
tam: agreed, once I have confirmed malware is on the system I NEVER assume it can be removed, especially from within the systemAnonymous
March 08, 2011
I thought malware was more advanced these days. Why does it not just install a rootkit to completely hide itself from Process Manager and all other equivalent tools at the same time? Surely the source code for such is out there?Anonymous
March 09, 2011
The comment has been removedAnonymous
March 09, 2011
@sci3ntist The malware would have disabled task manager and regedit through group policy. To enable task manager please see - support.microsoft.com/.../555480Anonymous
March 09, 2011
The comment has been removedAnonymous
March 09, 2011
@tam It seems Autoruns cannot be used offline, (that is, without running it under the target system) unless using runscanner (never got it to work perfectly though) or the version on the MSDART. I wish Autoruns could support that natively. :) Great article as always. Best of luck with the book launch! a small fanAnonymous
March 09, 2011
Nice! I normally download sys internal tools and rename then to get a *.bat extension then go to smwn then run autoruns and bam! bye bye malware :) of course I finish up with a nice full scan :)Anonymous
March 09, 2011
@Thomas: copy/rename regedit.exe, use reg.exe, etc. @wanderSick: check what version of Autoruns you use - it's supported offline scanning (specify System Root folder, User Profile folder) for a while.Anonymous
March 09, 2011
The comment has been removedAnonymous
March 10, 2011
@Todd So you've read Digital Fortress too, eh?Anonymous
March 10, 2011
The comment has been removedAnonymous
March 10, 2011
The comment has been removedAnonymous
March 10, 2011
@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, :(Anonymous
March 22, 2011
The comment has been removedAnonymous
March 26, 2011
The comment has been removed