The Case of the Sysinternals-Blocking Malware

  • Comments 27
  • Likes

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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Interesting,  I had a similar issue last night with a customer.  I my case I rad in safemode with command prompt[virus would run no matter what otherwise].  In Hkey_Current_user\software\microsoft\windowsNY\CurrentVerson\WinLogon there was a string called shell, with the virus path.   The virus program name was the same as the one above

  • 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.


  • 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!

  • 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?

  • 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 Mark

  • 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.

  • tam: agreed, once I have confirmed malware is on the system I _NEVER_ assume it can be removed, especially from within the system

  • 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?

  • 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.

  • I have a -probably naive- question: how did the malware manage to infect the system since its signature is known of MSE? I understand how the malware could prevent MSE to work once installed, but the anti-virus should have prevented it from installing in first place?

  • @sci3ntist

    The malware would have disabled task manager and regedit through group policy. To enable task manager please see -

  • @Sci3ntist:

    Maybe the malware registers itself as debugger for task manager and regedit just like Process Explorer does. That's interesting for regedit, because you would use regedit to remove the debugger registration under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. Maybe you can use a 3rd party registry editor such as RegAlyzer to check and remove the debugger entries.

  • @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 fan

  • 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 :)

  • @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.