The Case of the Sysinternals-Blocking Malware
Published Jun 27 2019 12:11 AM 8,615 Views
First published on TechNet on Mar 06, 2011

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.

Version history
Last update:
‎Jun 27 2019 12:11 AM
Updated by: