The nasty is known variously as Navipromo, msclock32l, msplock32, wymigqzhr, and other aliases. It's been around for a while, but few anti-malware apps can detect it, and fewer still can remove it. It reports on URLs visited and displays pop-ups.
The source of the infection is unknown to me, but the very first thing I did on the system was remove Limewire. Draw your own conclusion.
With the system running normally, there is no sign of any problem, except that the start-up times are terribly slow and there is masses of disc activity (but it was a Celeron 2600 with 256MB - a sluggish machine at the best of times). Ad-Aware, and Hijackthis could see a fair collection of other scumware in normal mode, Spybot was disabled - this is common: some app switches off the Spybot scan so that you get a "no problem found" message very quickly. But normal mode scans are never a great deal of use, so I just mention that for information.
In safe mode, the usual combination of Ad-Aware, Spybot, Hijackthis and Ewido cleaned the other infections off with no real trouble. The slow booting still troubled me, however, so I ran Spybot and Ewido again. Spybot scanned normally, finding nothing. Ewido, however, reported about 20 rouge processes and a single rouge file: c:\windows\system32\msclock32.dll. Ewido was unable to delete the processes or the file, however.
Sounds simple enough, yes? Why not boot in safe mode and delete msclock32.dll? Because, so far as Windows is concerned, the file doesn't exist. It is not visible to any normal Windows action (explorer, dir on the command line, etc.). In safe mode or normal mode, it is invisible, and no operation can be performed on it.
The next step, then, was obviously to remove the hard drive and slave it to a spare machine. (Or boot off floppy, which would achieve much the same thing.) Renamed the file OK, then scanned twice with Spybot and Housecall. Both report clean. Reinstalled the drive in the victim system .... and the problem was unchanged.
At this point I spent quite a while reading up on rootkits and rootkit scanners, downloading two. Sysinternals' RootkitRevealer could detect several instances of it but has no removal abilities - it's a detection-only program. F-secure's Blacklight Rootkit Eliminator, like Ewido, can detect it and attempt to remove it, but fails for some reason unknown to me.
Note that with a rootkit detector, you can't sensibly run it in safe mode: the basic idea is that the rootkit scanner does brute-force accesses to the system and compares the responses to those same accesses but made by orthodox Windows system calls. Where the brute-force access gives a different result to the orthodox call, we have a potential rootkit. (Or possibly a legitimately hidden item - Windows itself creates several such for (among other things) network shares, and other apps, notably anti-virus ones, may do the same. The long and the short of this is that the rootkit detector can only function while the rootkit is active. If you boot in safe mode, and this deactivated the rootkit, then it is invisible.
At this point, I get a little unclear. I buggerised about with a whole lot of different attempts to clean the system, including more sessions with the drive plugged into a spare system. I didn't make notes - which is just as well, as I'd still be writing!
In the end, I achieved success by discovering the source files from which, apparently, msclock32.dll was being recopied even after I deleted or renamed it. There were three of them, all with similar random-letters names, all in one of the system folders (c:\windows? can't remember). Naturally, these also were protected by the rootkit techniqie - i.e., not visible to any Windows function.
But to do this, you have to get smart. You can only see system32/msclock32.dll when you boot normally (and then only by using Ewido, RootkitRevealler or F-Secure Blacklight - Spybot, Trend Micro Anti-virus, Ad-Aware and Housecall are all blind to it), and even when you use a brute-force method to delete it, it is recreated on reboot. It "doesn't exist" in safe mode either, whether logged in as the user or on the administrator account.
In the end I nailed it by booting into the administrator account, using that to create a new user account, and then booting into that new user account and using the very latest Ewido update (which arrived two-thirds of the way through this epic), plus plugging the drive back into a spare system and manually deleting the random-letter files together with msclock32.dll from two different locations - having previously located the random-letter files using Rootkit Revealler from the new user account.
If that last para isn't very clear, well, it was my 7th or 8th hour with this system and I wasn't very clear myself by this time. (Now did I fire 5 shots? Or did I fire 6?)
Despite not taking detailed notes, I have learned quite a bit about the general class of problem, and will be much better prepared to deal with the next one - and there will be a next one, have no doubt about that.
