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
Anonymous
January 01, 2003
@Gabriel Thanks!Anonymous
January 01, 2003
@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.Anonymous
January 01, 2003
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.Anonymous
January 01, 2003
@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.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
@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.Anonymous
January 01, 2003
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.Anonymous
January 01, 2003
The comment has been removedAnonymous
March 14, 2011
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.Anonymous
March 14, 2011
The comment has been removedAnonymous
March 14, 2011
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.Anonymous
March 14, 2011
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?Anonymous
March 14, 2011
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.Anonymous
March 14, 2011
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? Thanks!Anonymous
March 14, 2011
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).Anonymous
March 14, 2011
@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.Anonymous
March 14, 2011
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.Anonymous
March 14, 2011
The comment has been removedAnonymous
March 14, 2011
"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)Anonymous
March 14, 2011
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.Anonymous
March 14, 2011
Keep the blog posts coming! I love reading your "Case of the Unexplained" blog posts!Anonymous
March 14, 2011
"(which is also arguably more humane)" - That gave me a laugh ;) Great post as always, thanks Mark!Anonymous
March 14, 2011
"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!Anonymous
March 15, 2011
The comment has been removedAnonymous
March 15, 2011
The comment has been removedAnonymous
March 15, 2011
The comment has been removedAnonymous
March 15, 2011
The comment has been removedAnonymous
March 15, 2011
UAC is not a security feature (Mark has said this). To be more secure, take yourself out of the Administrators group.Anonymous
March 15, 2011
The comment has been removedAnonymous
March 15, 2011
The comment has been removedAnonymous
March 15, 2011
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 youAnonymous
March 18, 2011
@zack - Unfortunately the Microsoft Diagnostic and Recovery Toolset (aka DaRT) is only available to those who pay for it...Anonymous
March 20, 2011
@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-)Anonymous
March 25, 2011
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.Anonymous
March 28, 2011
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?Anonymous
April 02, 2011
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.Anonymous
April 04, 2011
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.Anonymous
April 18, 2011
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.