The Case of the Mysterious Reboots

This case opens when a Sysinternals power user, who also works as a system administrator at a large corporation, had a friend report that their laptop had become unusable. Whenever the friend connected it to a network, their laptop would reboot. The power user, upon getting hold of the laptop, first verified the behavior by connecting it to a wireless network. The system instantly rebooted, first into safe mode, then again back into a normal Windows startup. He tried booting the laptop into safe mode directly, hoping that whatever was causing the problem would be inactive in that mode, but logging on only resulted in an automatic logoff. Returning to a normal boot, he noticed that Microsoft Security Essentials (MSE) was installed and tried to launch it. Double-clicking the icon had no effect, however, and double-clicking its entry in the Programs and Features section of the Control Panel resulted in an error message:


Hovering his mouse over the MSE icon in the start menu gave the explanation: the link was pointing at a bogus location likely created by malware:


Because he couldn’t get to the network, he couldn’t easily repair the corrupted MSE installation. Wondering if the Sysinsternals tools might help, he copied Process Explorer and Autoruns to a USB key, and then copied them from the key to the laptop, which he was now convinced was infected. Launching Process Explorer, he was greeted with the following process tree:


In my Blackhat presentation, Zero Day Malware Cleaning with the Sysinternals Tools, I present a list of characteristics commonly exhibited by malicious processes. They include having no icon, company name, or description, residing in the %Systemroot% or %Userprofile% directories, and being “packed” (encrypted or compressed). While there’s a class of sophisticated malware that doesn’t have any of these attributes, most malware still does. This case is a great example. Process Explorer looks for the signatures of common executable compression tools like UPX, as well as heuristics that include Portable Executable image layouts used by compression engines, and highlights matches in a “packed” highlight color. The default color, fuchsia, is visible on about a dozen processes in the process view. Further, every single one of the highlighted processes lacks a description and company name (though a few have icons).

Many of them also have names that are the same, or similar to, legitimate Windows system executables. The one highlighted below has a name that matches the Windows Svchost.exe executable, but has an icon (borrowed from Adobe Flash) and resides in a nonstandard directory, C:\Windows\Update.1:


Another process with a name not matching that of any Windows executable, but whose name, Svchostdriver.exe, is similar enough to confuse someone not intimately familiar with Windows internals, actually has TCP/IP sockets listening for connections, presumably from a botmaster:


There was no question that the computer was severely infected. Autoruns revealed malware using several different activation points, and explained that the reason even Safe Mode with Command Prompt didn’t work properly was because a bogus executable called Services32.exe (another legitimate-looking name) had registered as the Safe Mode AlternateShell, which is by default Cmd.exe (command prompt):


My recommendation for cleaning malware is to first leverage antimalware utilities if possible. Antimalware might address some or all of an infection, so why do work if you don’t have to? But this system couldn’t connect to the Internet, preventing easily repairing the MSE installation or downloading other antimalware like the Microsoft Malicious Software Removal Tool (MSRT). The power user had seen me use the Process Explorer suspend functionality at a conference to suspend malware processes in order to prevent them from restarting each other when someone trying to clean the system terminates one. Maybe if he suspended all the processes that looked malicious he’d be able to connect to the network without having the system reboot? It was worth a shot.

Right-clicking on each malicious process in turn, he selected Suspend from the context menu to put the process into a state of limbo:


When he was done, the process tree looked like this, with suspended processes colored grey:


Now to see if the trick worked: he connected to the wireless network. Bingo, no reboot. Now connected to the Internet, he proceeded to download MSE, install it, and perform a thorough scan of the system. The engine cranked along, reporting discovered infections as it went. When it finished, it had found four separate malware strains, Trojan:Win32/Teniel, Backdoor:Win32/Bafruz.C, Trojan:Win32/Malex.gen!E, and Trojan:Win32/Sisron:


After rebooting, which was noticeably faster than before, he connected to the network without trouble. As a final check, he launched Process Explorer to see if any suspicious processes remained. To his relief, the process tree looked clean:


Another case solved with the help of the Sysinternals tools! The new Windows Sysinternals Administrator’s Reference, authored by Aaron Margosis and me, covers all the tools and their features in detail, giving you the tools and techniques required to solve problems related to sluggish performance, misleading error messages, and application crashes. And if you’re interested in cyber-security, be sure to get a copy of my technothriller Zero Day.

Comments (6)
  1. Oh, good. That's what I do everyday. I use Sysinternals tools in this fashion. Actually, I have been doing this for years now. But I also use additional more sophisticated tools. Malware are nasty things.

  2. CaptainMVP says:

    Nice article ..

  3. Anonymous says:

    When you have multiple instances of malware interacting, you often get side effects like non-functional networking. Each malware is designed to be a solo affair and take over the machine (often as invisibly as possible) so each new link outside the norm in the chain for networking can create additional issues.

  4. Anonymous says:

    I really wouldn't trust that laptop after such a successful infection. I would grab/rescue data files but re-image the computer as you do not know if a stealthy rootkit is installed.

    Also I wonder why Microsoft does not provide authoritative list of authentic files (along with descriptions/function, hash and file sizes) that come with Windows and its various products.

    Sometimes even Microsoft authored files don't come with a digital signature and proper version header information or the digital signature fails validation when using Sysinternal tools (I'm thinking of a version of a.NET frameworks here)

    One feature I would like to see in Windows to help defeat a lot of malware is functionality that allows the user or administrator to "seal" a windows installation. That means that Windows and/or security essentials records the file hashes/signatures of all executables on the system at a given point in time and will not allow any new executables/software that show up on the computer (except those updated via Windows update or other secure update methods) to be executed.

  5. jader3rd says:

    I wonder what the purpose was of preventing the laptop to connect to a network? The malware won't be able to receive commands if not connected to a network, and it won't be able to spread itself.

  6. Anonymous says:

    @jader3rd: Bugs, bugs, and more bugs. Malware writers are known for creating crap that rivals expensive consultant teams for code quality, and two of them probably clashed in a way that caused a blue screen automatic reboot.

    @Mark: Could you look at Process Monitor and consider flagging it as high-DPI-aware? I have to manually add the compatibility flag every time I update it on a machine or it looks like a blurry mess. (I don't use XP style DPI, too many problems.)

Comments are closed.

Skip to main content