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 (27)
  1. jader3rd says:

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

  2. says:

    Wow, who would have thought desktops would do this. Great thought process here !

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

  4. Anonymous says:

    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_usersoftwaremicrosoftwindowsNYCurrentVersonWinLogon there was a string called shell, with the virus path.   The virus program name was the same as the one above

  5. Anonymous says:

    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.

  6. @Todd Thanks for sharing your case and I hope you like Zero Day!

  7. Anonymous says:

    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!

  8. Anonymous says:


    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

  9. Anonymous says:


    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?

  10. nick says:

    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.


  11. tam says:

    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?

  12. Daniel says:

    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.

  13. frymaster says:

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

  14. niklas says:

    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?

  15. KooKiz says:

    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?

  16. santosh says:


    The malware would have disabled task manager and regedit through group policy. To enable task manager please see –…/555480

  17. thomas says:


    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_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options. Maybe you can use a 3rd party registry editor such as RegAlyzer to check and remove the debugger entries.

  18. wanderSick says:

    @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

  19. J says:

    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 🙂

  20. nc/m says:

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

  21. Todd Mortensen II says:

    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.

  22. SQB says:

    @Todd So you've read Digital Fortress too, eh?

  23. Keith Dickinson says:

    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.


  24. tam says:

    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.

  25. Todd Mortensen II says:

    @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, 🙁

  26. pewpewlazerz says:

    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.

  27. Trevor says:

    It's only a matter of time before the Malware also blacklists "Desktops.exe"

Comments are closed.

Skip to main content