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:

image

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

image

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:

image

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:

image

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.