I recently received an email from a co-worker that said Malwarebytes was the source of a particularly vexing problem that’s been encountered recently. The problem is that once someone has been infected with one of those fake Security Centre viruses, and subsequently cleaned and rebooted, no programs will launch. This didn’t sit right with me, so I decided to investigate a bit. I’ve confirmed that Malwarebytes is not the cause of this issue. Well, at least not directly.  

By confirmed I mean that the root cause of the issue is present before any anti-malware work is done on a computer that will eventually exhibit this issue. I’ve tested this on three machines that were infected, one accidentally infected physical machine and on two purposefully infected VM’s (XP and 7) I have.  

Unless you actually care how the Windows registry works and are interested in some registry information this is for sure tl;dr.

The problem  

The latest batch of what I’ll call Security Centre viruses, the ones that act like an antivirus program and trick users into installing the virus, sets file associations in the registry so that users cannot access programs that can be used to interfere with the virus. These programs typically include things like taskmgr.exe, regedit.exe, msconfig.exe, and mmc.exe along with any management consoles that run through an MMC, such as services.msc.    

The problem I’m referring to is that once you’ve rid a computer of viruses and rebooted the machine, when you try to open any .exe file, you receive a message along the lines of “The system cannot find the specified path” or “Windows cannot find ‘C:WindowsSystem32Winterpret32.exe’ please check the path and try again.” Or some such popup. This is caused by the virus rerouting system paths.  

The .exe extension is rerouted via a registry change to one of, or all possibly, the following registry keys:  

HKCR\.exe  
HKCR\exefile\shell\open\command  
HKCR\exefile\shell\runas\command 

The key is changed to force files with the .exe extension to run through an application that the virus runs in order to intercept and block those programs from running. If the .exe file that is called is not on the program’s list of applications to block, it is passed off to Windows, which runs the program normally. If the program is on the list, the virus will pop up something like “This application is infected, do not run it!” Since as far as Windows can tell, the system call you’ve made has been processed, no errors are generated, nothing happens, everything is as it should be.  

When an anti-virus program does a full scan of the computer, and sometimes on a quick scan depending on the program, it searches the hard drive of the computer, finds malicious executables, and removes them. It also goes through portions of the registry and finds references to those programs and removes them. Normally, this is good because it prevents things like autorun at startup, or the remapping of things like Windows Security Centre to the virus’ own mockup. However, in some cases, such as this, this is a bad thing.  

Because .exe files have been rerouted to run through the virus, when the virus has been removed, Windows now cannot run anything through this and so returns the invalid path error above.  

The fix:

This fix is similar to the fix for the sircam worm that spread around a few years ago, but the path pointed to seems to be randomly generated, within %systemroot%\system32. The path has been 8 characters long, with 32 at the end of it. The 32 at the end could be coincidence, so don’t assume it’s always going to end with 32. In my tests the paths have been the following:  

C:\Windows\System32\jsuvhi32.com  
C:\Windows\System32\Nvuwvq32.com 
C:\Windows\System32\vvUPOc32.com

That path is inserted into one of the registry keys above as:  

<path> “%1” %*

ie:  

C:\Windows\System32\jsuvhi32.com “%1” %*

Ideally, the antivirus program would be smart enough to know that it should only remove the &lt;path&gt; portion, but not the “%1” %* part. But no AV program is that smart, so they just blank the key. Since the registry is not read dynamically, meaning that at boot almost the entire thing is read as is into RAM, everything that is written to it requires a reboot to become effective. This is why it’s important to scan the entire registry when a computer has become infected, and why many viruses return after a reboot.  

So what you need to do is change the default values of the following registry keys:  

HK_CLASSES_ROOT\exefile\shell\open\command
HK_CLASSES_ROOT\exefile\shell\runas\command

“But, Robbie” I hear you say, “How can I edit the registry when I can’t launch regedit.exe?!?” And to you, I answer thusly: “By going old school.”  

NOTE, this will not work on an x64 based system. As far as I know there is no equivalent.

Go to the start menu, and launch command; NOT cmd.  

Cmd is the built in 32bit Command prompt that has been in Windows since the NT kernel became the base of Windows instead of the 16bit Windows 9x kernel. CMD is a shortcut to C:\Windows\System32\cmd.exe, and .exe files won’t run. You need to launch C:\Windows\Systm32\command.com  

So go to Start>Run, and type: command  

You’ll be greeted with a Command Prompt window that says Microsoft ® Windows DOS as the top, rather than a version specific banner for that version of Windows. This is a 16bit application which is does not recognize your path, additionally NONE of the normal shortcuts in a command prompt work. No tab to complete, or sensible directory switching. From here, you will need to CD to \Windows\System32. Then do:    

copy regedit.exe regedit.com

Then launch regedit.com from this command window. Regedit.com is the exact same program as regedit, so using it is the same as normal regedit.  

Once you’ve got regedit open, navigate to the following keys:

HK_CLASSES_ROOT\exefile\shell\open\command
HK_CLASSES_ROOT\exefile\shell\runas\command

and change their values to:    

“%1” %*  

NOTE: Unlike normal documentation that specifies to NOT use the quotation marks, you MUST use them here.

If for some reason the command key does not exist under one, or both, of the registry entries, create it. Do this by right clicking on either open or runas, then select New&gt;Key. Then name the key command. Once you have created the key, you will need to select the key, and then create a new String Value. Once you’ve created the new String Value, double click it, and set the value as above.  

Then reboot, and you should be able to launch .exe’s without a problem.  

Now, while I have not witnessed this particular batch of viruses doing the following, it is possible that they could.  

Windows doesn’t run executable files by checking the above registry key. It runs them by querying the registry about what it is supposed to do with a .exe file, and then does that. The registry points .exe files to exefile, which translates to “HK_CLASSES_ROOT\exefile” as above. It’s possible to change what is done to a .exe file on open by setting the default value of .exe in the registry to something else. This something else could be a duplicated, but altered version of the exefile class, which runs the file through a similar interceptor program in the same manner that this virus did, so you need to make sure that the default key of HK_CLASSES_ROOT.exe is set to exefile  

Congrats to you for reading all of that.