The Case of the Unusable System

This post continues in the malware hunting theme of the last couple of posts as Zero Day availability draws near (it’s available tomorrow!). It began when a friend of mine at Microsoft told me that a neighbor of hers had a laptop that malware had rendered unusable and asked if as a favor I’d be willing to take a look. Her friend was desperate because she had important files, including documents and pictures, on the laptop and had no backup.

Unlike most people in the computer industry that view the requests of friends and family for troubleshooting help as a burden to be avoided, I embrace the challenge. When fixing a system or application problem, it’s me against the computer and success is satisfying and always a learning experience. But that success also has an academic feel. With malware, it becomes personal, pitting me against the minds of criminal hackers. Defeating malware is a victory of good over evil. I should print a t-shirt that says “Yes, I will fix your computer!”. I immediately agreed and we made arrangements to get the laptop dropped off at my office.

When I had a few free minutes the next day I powered on the laptop, logged in, and within seconds was greeted with a torrent of warning dialogs announcing that the computer was infested with malware and that it was under attack from the Internet:


I also saw a barrage of warnings that various applications had been stopped from launching because they were infected:


I hadn’t seen scareware this aggressive. After a minute the appearance of new warnings ceased and I began my investigation. Starting with the insertion of a USB key containing the Sysinternals tools, I tried launching Process Explorer. However, I found that trying to run anything – whether part of Windows or third-party – resulted not in the execution of the application, but in the display of the same “Security Warning” dialog reporting that the application was infected. This system was truly unusable.

The infected account was the only one configured, so that ruled out trying to clean from a different account in the hope that it might not be infected. I was afraid that cleaning the malware might require off-line access to the system via a boot CD installed with the Microsoft Diagnostic and Repair Toolset (the Microsoft product that’s the descendent of ERD Commander, the product I created at Winternals Software). My MSDaRT CD was at home and I’d have to burn a new one. But I had noticed when I logged on that it was 5-10 seconds before the first popups started appearing. If the malware didn’t block running applications during that time window, either because it was initializing or just letting the first few logon applications run so that the Explorer could fully start, I might be able to sneak Process Explorer and Autoruns in before the lock down. That would save me the time and trouble of burning a CD. It was worth a try.

Before logging off, I copied Process Explorer and Autoruns to the desktop for easy access. I logged on and double-clicked the icons in quick succession. There was a short pause and then both applications appeared. It had worked! I had to wait for the avalanche of warning dialogs to stop and then turned my attention to Process Explorer. Sure enough, one process stood out, hgobsysguard.exe:


I explain the common characteristics of malware in my Advanced Malware Cleaning presentation and this sample had all the telltale signs:

  • Random or unusual name: hgobsysguard.exe seems like it might be legitimate, but I had never seen or heard of it and the name revealed nothing of its purpose or origin
  • No company name or description: legitimate software almost always includes a company name and description in the version resource of their executables. Malware often omits this since most users never run tools that show this information.
  • Installed somewhere other than the \Program Files directory: you should add software not installed in the \Program Files directory to the list of suspects for closer inspection. In this case the executable was installed in the user’s profile, another sign of malware.
  • Encrypted or compressed: In order to avoid detection by antivirus and make analysis more difficult, malware authors often encrypt their executables. Process Explorer uses heuristics to try to identity encrypted executables, which it refers to as “packed”, and it highlights them in purple like it did for this one.

I carefully studied the other running executables, including the services running within the various Svchost.exe hosting processes, but I didn’t see anything else that looked suspicious. Sometimes malware employs the “buddy system”, where it uses two processes, each watching the other so that if either terminates, the other restarts it, making it virtually impossible to terminate them. When I see that I use Process Explorer’s suspend feature to put both to sleep and then kill them (which is also arguably more humane). Here all I had was one malicious process, so I just terminated it. It didn’t reappear, which was a good sign that there wasn’t a buddy lurking within another process as a DLL. I then navigated to the malware’s install directory and deleted its files.

With the process and executables out of the way, the next step was to determine how the malware activated and delete its autostart entries. I switched to Autoruns, which had finished its scan in the meantime, and spotted two entries pointing at the malware’s executable. Both entries had names that appeared to have been randomly generated, consistent with typical malware:


I deleted the entries, studied the rest in case there was some other component that wasn’t so obvious, and did some standard crapware cleanup while I was there. I rebooted the system and logged back on to confirm it was clean. This time there were no popups, I was able to run software as normal, and neither Process Explorer nor Autoruns showed any sign of more infection. I had spent a total of five minutes and had some fun outwitting the malware to avoid offline cleaning. Case closed.

Comments (38)

  1. Anonymous says:

    I discovered that removal of "System Tool 2011" fake anitvirus, which was very similar in attack mode to the malware described in the post, an easy way to be able to run Autruns.exe and ProcExp.exe (or ProcExp64.exe, depending on the OS) is to rename them to either "iexplore.exe" or "explorer.exe".  It was installed in C:ProgramData on a Windows 7 machine.

  2. Anonymous says:

    @AC: Any process running at the same integrity level (and session) can do almost anything it wants to any other process at the same (or lesser) level.  To launch an application, you need an application (explorer being the most prevalent example).  If you modify explorer (via …), you can stop the launching of a process.

  3. Anonymous says:

    @WndSks – true, you'll find legitmate software in the windows and windowsystem32 directories as well. However, places other than Program Files are the exception for legitimate software, but the rule for malware.

  4. Anonymous says:

    @Jon True – this could have been defeated in safe mode as well. I've posted this before, but obviously best practice is to wipe and restart when you have an infection. But security is about risk analysis and management and wiping/reload has a high cost. Given the purpose and characteristics of this malware, and my previous experience, the likelihood that I had successfully cleaned it was very high.

  5. Anonymous says:

    @Mark: You said: "Unlike most people in the computer industry that view the requests of friends and family for troubleshooting help as a burden to be avoided, I embrace the challenge. When fixing a system or application problem, it’s me against the computer and success is satisfying and always a learning experience."

    Wow! Are we not a single soul in two different bodies? No, we aren't but we definitely have something in common.

  6. Anonymous says:

    @Gabriel Thanks!

  7. Anonymous says:

    @patokat tech:  Autoexec.bat (and for that matter, autoexec.nt) only run when a command prompt is created in NT; so it wouldn't have run at startup.  You could put the tools in the Startup folder, but the launching of these applications is serial and non-deterministic; the tools might have been loaded after the malware had started.  The way Mark did it was one of the fastest ways as it doesn't wait for WinInit to complete the login processing ('Run' registry key, 'Startup' folder, etc.) – it just waits for the shell (explorer.exe) to start; which is the first process to be created by WinInit.

    To guarantee success, Mark could have replaced Explorer with ProcExp as the shell (via HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionWinlogonShell) – this would have minimized the amount of malware loaded at login.

  8. Anonymous says:

    It's in situations like this that I wish Windows had a UAC like feature which would prevent executables from running if they weren't in admin configured directories. I'd always block any executables from running which lived in %userprofile% or %programdata%.

    Sadly, more and more legitimate programs are trying to install in those locations to make it easier on the user. But with easier, along comes insecure.

  9. Wilhelm Svenselius says:

    Cleaning malware is fine – but unless the user learns to exercise common sense and caution, and to run regular backups, the same issue will repeat itself and the next time it might not be a 5-minute job.

  10. Tom says:

    Friends?  No.

    Family?  Yes.  But then they get demoted to a limited user account, I reset the administrator password, and it goes on my Live Mesh so that I can login remotely and keep it updated from time to time.

    I'm also a "once it's infected, you can't trust it ever again" kind of guy.  I've seen more than one malware infection simultaneously.  Could be turtles on top of turtles — you just don't know for sure.  Once a system is compromised, safer just to blow everything away and start over.

  11. e. charles sterling says:

    Agreed, it can not only take more time but the cleaning process itself can uproot the degree of damage and eventually cause the system to crash.

    Imaging the typical user's machines is not practical and getting them to do backup is like pulling teeth w/o Novocaine.

    This is all dependent on what damage has occurred in the first place.

    Casually passing this cleaning process off is ill advise to a user.

    Unfortunately most users don't want to learn the basics of the issues around Malware and too openly accept the false view that a computer must be replaced every few years because it has gotten slow and is now old.

  12. Seth says:

    Sysinternals utilities have become more popular and drawn more attention from malware creators. There will be one day dangerous malware can successfully block all useful Sysinternals utilities (including Desktops which was mentioned in the previous post), how can we defeat malware then?

  13. tam says:

    Another method of protection would be something like Deepfreeze, which resets everything after a reboot.  But be sure to optimize Readyboot first.  i/o in win7 seems to be slowwww compared to xp.

  14. Nick says:

    Thanks for the writeup, Mark. Pretty interesting.

    The only question I have is:  Did you end the cleanup there, or did you look deeper before declaring the machine clean?  Anymore when I see an infected machine I can't help but wonder what else might be there, but unseen.  There's a pretty good argument for using a rootkit-based system where "obvious" malware is installed by the invisible rootkit every 10-20 days.  If somebody cleans it off things look okay for another couple weeks and then BAM, malware is back even though the user hasn't done anything.

    Do you personally suggest reinstallation of the operating system after a computer is compromised by malware like this?  When you help a family member clean their system, do you feel okay with them accessing their online banking from the "cleaned" system, or do you perform a more in-depth check for a rootkit?


  15. Jon P says:

    Nice work!  My preferred method for dealing with something like this is to boot to Safe Mode.  That blocks the malware from ever loading in the first place (almost no startup entries get processed in Safe Mode).

  16. Billy O'Neal says:

    @Seth: That day was a few years ago. Modern rootkits (for example) don't block the sysinternals tools — they just make themselves invisible inside said tools.

  17. engur says:

    an idea, you can implement a thin hypervisor and a infrastructure to use it with your sysinternals utilities like modern hvm rootkits. So, when somebody wants to analyze a normal user computer (whicih is modern but no use of any hypervisor thing) your utilities run and analyze safely while the OS switches VM mode and your hypervisor handles the rest.

  18. Kent says:

    What about the image hijack registry entries that allowed the malware to stop anything else from running? I had one system where I failed to remove these keys and applications still wouldn't run. If there aren't image hijacks, how did the malware stop other processes from starting? Just curious.

    Your process has really helped me streamline and improve my own scareware removal procedures.

  19. WndSks says:

    "Installed somewhere other than the Program Files directory" Don't forget that Win7 added the per user programs known folder. (And Chrome etc install in appdata)

  20. AC says:

    How is malware able to stop all applications from launching?  I support many computers (running as restricted user, Win 7, Vista and XP) that get malware like this.  It seems like a flaw in Windows to allow this behavior without admin privilege.  Please don’t give away any knowledge that will help malware, but I would like know your thoughts about why Windows would allow this.  It is very easy to clean from an Admin account, but it is very inconvenient for the users.  Symantec Endpoint doesn’t seem to help with the problem.

  21. Gabriel says:

    Keep the blog posts coming! I love reading your "Case of the Unexplained" blog posts!

  22. Chris Sanny says:

    "(which is also arguably more humane)" – That gave me a laugh ;)

    Great post as always, thanks Mark!

  23. wanderSick says:

    "Unlike most people in the computer industry that view the requests of friends and family for troubleshooting help as a burden to be avoided, I embrace the challenge."

    Having an attitude like that is key in successfully battling malware. This is the most important thing to learn from this post. Thanks!

  24. adamth0 says:

    @Seth – You can outwit many malware programs by renaming the executable you want to run.  For example – when I have to clean up some malware that’s not letting me open regedit (or is killing regedit as soon as I launch it), I rename it to hivemonster.exe
    or somesuch, and then launch it.  The same can be done for procexp.exe (but probably not the driver it relies on).  I’ve not yet encountered malware that prevents windbg.exe from launching (unless it’s one preventing all applications from launching).  If you
    have a 32-bit Windows installation to clean, you’ll notice that RootKitRevealer employs random filenames


    @AC – it doesn’t need to be a Windows vulnerability that lets this sort of thing get installed.  I’ve seen a few Vista/Win7 laptops get hosed thanks to a Sun Java vulnerability recently.  Too many people just click ‘OK’ on the UAC dialogs.

    On a final note- if anyone does clean up such an infection, please don’t forget to submit the sample to the Malware Protection Center:…/Submit.aspx

  25. Will Raresheid says:

    I cleaned almost the very same thing from a computer my wife was using (could have been the same, just different names). She claimed that she did not click on a message box or popup to enable the malware. She is a very smart user and I believe her. It appears that this one can infect with little or no user participation. All our data is backed up but reloading from scratch is such a pain and I saw it as Mark did, a challenge. Cleanup was successful and there has been no sign of the malware in the weeks afterward.

  26. Sam says:

    For those who think removing the virus is not enough:

    the virus might even have been dormant for some time, and (for those who have backup) might even be contained in the backup, too.

    So if you think removing the malware is not enough, you might want to consider purging the backups, too. And maybe burning the building down, tossing some salt on the ashes, just to be sure you really got the virus :)

  27. Sergey says:

    just  a similar story with manual  removal  of a virus.…/hunting-evil-trojan-bot-on-viruses-and.html

  28. tam says:

    UAC is not a security feature (Mark has said this).  To be more secure, take yourself out of the Administrators group.

  29. djdanlib says:

    Nice write-up, and some good thinking. It really pays to know how the system works internally, doesn't it? I've disinfected that one from people's computers before. I've seen it come from an ad banner on the Wall Street Journal, after making the user open the article again in disbelief… Java launched and delivered its payload. I only found one product that could clean it up (Webroot) but I wouldn't have needed that product if your article had existed a year ago! I had to turn on the PID column in Taskman so I could keep launching it (the malware kills it immediately, so seeing it flash onscreen is the only way to get PIDs) and start-run-killall the processes that were blocking all AV and anti-malware software… couldn't launch cmd, regedit, MBAM, Spybot, Ad-Aware or any of the AV software I had available, and most other EXEs were blocked. So: Again, good work!

    AC, I think malware is able to stop apps from launching via the same mechanism as AV software is able to scan apps before they launch and prevent known trojans from launching. You can hook just about any OS function and insert your own code before the OS's code.

  30. adamth0 says:

    Another point about UAC in this scenario.  Regardless of the attack vector used (eg Flash, Java or browser vulnerability) – the malware dropped itself on disk to %USERPROFILE%, and referenced itself (to run at each login) in the HKEY_CURRENT_USER hive.  Neither of these things requires administrator privileges.  These are things that standard user accounts can do – so no elevation would have been required at all.  From the limited range of malware that I've had the displeasure of cleaning up, it does seem that since the introduction of UAC, malware tends to use HKCUSoftwareMicrosoftWindowsCurrentVersionRun – even when it could just as easily have written to the HKLM equivalent (eg, an administrator account on Windows XP).

    In one recent cleanup I was doing, Security Essentials had correctly alerted to an exploitation of CVE-2010-0840, but had failed to stop it (and the Java version was sufficiently recent that this vulnerability should not have been an issue any longer).  It was another fake antivirus program.  Once cleaned up, I submitted the sample to MS, who added it to their definitions within 48 hours.  I also tracked down the specific website and ad network that displayed and hosted the malicious banner, and although it took much longer for their abuse departments to respond, eventually the banner was nerfed by the ad network.

  31. zack says:

    Hi Mark,

    I tried looking or easy download of the bootable Microsoft Diagnostics and Recovery Toolset with your tools in it… Can you help us put a link where we can download it with all the sysinternals tools or at least a basic instruction how to create it…

    Thank you

  32. Joe P says:

    @zack – Unfortunately the Microsoft Diagnostic and Recovery Toolset (aka DaRT) is only available to those who pay for it…

  33. Zack says:

    @Joe P..Hi, I saw that as well. but MS also has a beta version of it.. but not much documentation how to add tools and eventually use it..maybe for paying customers as well? 8-)

  34. Davdee says:

    Mark, many thanks for your blog. I admire your patience with a Windows that appears to be a zombie with malware. And while I used ProcExplorer some time back I must start using it again. Regrettably at our shop, the rule is: rebuild the Windows rather than spend time fixing it. I like to go down the latter path but time becomes short usually.

  35. patokat tech says:

    Could you have put process explorer and autoruns in the autoexec.bat to make sure you got them running, or would they have had too low a priority to run? What about putting them into the user's startup folder?

  36. bendodge says:

    This sort of scareware is very common at the repair shop where I work. Personally, I like to use rkill from Bleepingcomputer. It terminates malware in memory and presents a report, which is much more efficient than trying to sneak stuff in in the first few seconds, although I have had to do that a few times for particularly evil ones.

    It comes in several few flavors (exe, scr, com) to avoid getting snagged on launch. Another effective tactic is to rename whatever you want to run to eXplorer.exe or the name of another system process.

  37. Roland says:

    agree, good writeup, and its because I fix friends & family PCs I check here for new ideas.

    I keep a standard price for when asked, a bottle of cheap red wine. Otherwise you build up a moral imbalance, which kills friendships and stops repeat requests at the time they most need it.

  38. Intuit says:

    Some malware will modify HKCR.exe and HKCRexefile pointers, as well as a few others so that they host each new instance of any new process.  I've also had systems that become unbootable after disabling the malware.  (in such cases will have to modify the HKLMSYSTEMControlSet###ControlCriticalDeviceDatabase key)  Basically they trick the system into thinking their malware is a critical boot device.  There's also another dirty little trick they use to prevent certain software from executing (not mentioned under "The Case of the Sysinternals-Blocking Malware") but rather not mention it publicly until I see more instances of it.