Normally I don’t hit by viruses. I’m very good with Windows Update and keeping the anti-virus signatures up to date on my machine. Thus, I was very surprised yesterday afternoon when I saw a blinking tray icon and a badly worded balloon message indicating that I had an “infection”.

 

A quick check showed that a program called “SpyAxe” had shown up installed on my system. What’s worse, I found two suspicious processes named MSSEARCHNET.EXE and NVCTRL.EXE running. Attempts to kill them using TaskMgr and Process Explorer (ProcExp) weren’t successful, as they kept re-spawning. Definitely virus behavior.

 

With this info in hand, I hit MSN Search and found that there was a recent upswing in activity related to SpyAxe “tool” (As well as the similar SpySherriff), staring around 12/28/05. Warning, I don’t claim to be a virus expert, nor claim to offer useful advice on helping others who get hit by this. What follows is just some of my observations. Your mileage may vary.

 

My first attempt to rid my system of this was to download the latest AV signatures from the corporate network. A full scan of my system later, no viruses detected, but I still definitely had badness on my system.

 

At this point I was starting to take off the gloves. Long time readers of my MSDN column know that I know a think or two about mucking around with processes. J

 

Early on I had noticed several files with current creation times in my \windows\system32 directory, including MSSEARCHNET.EXE and NVCTRL.EXE. I couldn’t delete any of them, as they were all “locked” by another process. Using one of my favorite tricks, Image File Execution Options, I was able to stop them from continuously re-spawning. After deleting the files, I thought I was done. A second check of \windows\system32 showed there was still a file: LDxxxx.TMP that was locked. (Where xxxx is four random numbers.)

 

Using ProcExp, I determined that this file was loaded by WinLogon.exe. A quick check of my wife’s machine showed that her WinLogon.exe had nothing similar going on. Hmm… badness. What’s worse, I ran my PEDUMP utility on the LDxxxx.TMP file, and found it calling functions like Process32First/Next, RegSetValue, and WININET.DLL functions. They were exactly the combination of functions you’d use to download files and inject bad code into unsuspecting processes.

 

Entering the phrase “WinLogon .TMP DLL” into MSN Search, I found that this is a well known exploit, and that the .TMP DLL actually adds registry values to this key:

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer

 

The added registry values redirect various DLLs loaded by Internet Explorer. Even worse, when I deleted those registry entries, at least one of them reappeared. Definitely evil behavior.

 

At this point I cranked up RegMon, deleted the offending registry values, then checked to see who was re-writing them. Turns out it was WinLogon.exe. Whoever’s responsible for this isn’t your garden variety kiddie hacker.

 

Question of the day: How would you stop this evil DLL from continuously resetting the key value back? Being brave (or foolhardy) I attached a debugger to WinLogon.exe. For the debugger, I chose PEBrowseInteractive because of its great breakpoint setting abilities.) My intent was to trap when the DLL called RegSetValue, and NOP out the code.

 

However, the breakpoint never appeared to get hit. At the same time, Explorer started acting very sick. I reset the machine to try the trick again, but when I rebooted, I saw no trace of the WinLogon LDxxxx.TMP DLL anymore. Not completely sure that I’d eliminated the malware, I dig a bunch more searching, verified a ton of registry keys, carefully examined each process, and at the moment it appears like I’m clean.

 

Just to be safe, I ran RootkitRevealer, and it came up clean as well.

 

Since then, I’ve been running IE at the “High” security level, and only adding well known sites to the trusted sites list.

 

Sorry if this post sounds like an ad for SysInternals and SmidgeonSoft, but there stuff is just good. Incidentally, be sure to read Mark R’s post on this same topic.