Edit: I should have anticipated this!
Of course, after writing instructions on how to remove a common virus, I should have realized my content-sensitive Google ads on the left side of the page would all instantly turn into scam anti-virus tools.
Please, please don’t attempt to use any of those advertisers’ products to fix your computer if that’s what you came here to do. In fact, don’t click them at all. They won’t work, and you’ll just have more crap on your computer. Remember, despite anything Google might tell you, they don’t personally vet ads before letting them loose on their network and they don’t bother removing bad ads until somebody complains.
Sorry.
I managed to infect my work machine with this little bastard, and it took me several hours but I finally figured out how to get rid of it. Despite the name on the Wikipedia page, Vundo isn’t a trojan, it’s a plain ol’ virus, which managed to gain a foothold on my computer through Sun’s Java plug-in.
Lesson 1: Java is by far more trouble than it’s worth; uninstall it.
Anyway, I seem to have gotten a brand new variant of Vundo that slipped under Symantec’s radar, and the existing removal instructions and tools simply didn’t work for me at all. The most useful existing tutorial is on this seemingly nameless page, and the instructions on McAfee’s guide, which got me 75% of the way to the solution, and from there I found my own way to finishing the job.
To remove Vundo:
- These instructions assume you are running Windows XP and have Administrator privileges. This shouldn’t be an issue, as if you didn’t run as Administrator, or were using Vista, you probably wouldn’t have been infected in the first place.
- Follow the instructions on the seemingly nameless page linked above for identifying the DLL files used by the virus, up to the “Remove the Infection” header. (These instructions outline using ListDLLs.exe to get a list of all DLLs currently running on your computer. Vundo DLLs have a blank Version column, “C:\Windows\System32″ in the Path column, and have a string of 8 random characters as the filename.) Save the list somewhere handy, or print it out.
- Locate the first DLL file on the list in your “C:\Windows\System32″ folder. Right-Click the icon and select Properties. Click to the Security tab. Make sure the “Everybody” group is selected, then click the Deny checkbox next to Full Control. This should automatically check all other permissions in the Deny column. (Note: you won’t be able to uncheck the “Allow” column, but the fix will work anyway.)
- Repeat the last step for the other Vundo files identified using ListDLLs.exe. (In my case, there were 3 DLL files used by the virus.)
- (This is the kind of nasty part.) Perform a hard reboot by holding the power button of your computer in for 15 seconds, or until it turns itself off. You cannot allow your computer to shut down normally, or Vundo will rename and reproduce itself during the shut down process.
- After your computer finishes restarting, you can now delete the DLL files you changed permissions on. You should also empty the recycling bin, to ensure they are fully deleted.
- Run a virus scanning program that’s normally capable of getting rid of Vundo to ensure nothing else remains. Spybot Search and Destroy seemed to do a good job of identifying it, or you could download and use Symantec’s removal tool.
How does this work? The variant I have keeps its DLL files constantly open and locked using both WinLogon.exe and Explorer.exe, so they are impossible to rename or remove.
The seemingly nameless page recommends queuing the files to be deleted on the next boot, but that didn’t work at all on my system. (Once WinLogon.exe is running, the DLL files are impossible to delete. I think the “delete on next boot” utility doesn’t run until WinLogon is already running.)
McAffe recommends using Process Explorer to Suspend Explorer.exe, WinLogon.exe and RunDLL32.exe as you do the removal, and then do a hard reboot. This in theory would prevent Vundo from re-establishing itself during the shut down process, but it didn’t work for me because the DLL files were impossible to rename or remove while Explorer.exe and WinLogon.exe were running, even when they were suspended. (Which makes sense– suspend is like pausing a program. If the program has locked files, why would you expect them to become unlocked while it was paused? I can only assume McAffe’s directions work on a different variant of Vundo, although I can’t see how.)
My solution relies on three handy bits of trivia I’ve learned:
- Windows XP boots using Administrator group permissions.
- Deny permissions always over-ride Allow permissions.
- The NTFS driver starts enforcing file permissions really, really early in the boot process
Basically, by setting Deny permissions for the Administrator group on the DLL files, we made it impossible for any program on the computer to run them, even programs that start before the user is logged in (like WinLogon.exe.) Once WinLogon.exe and Explorer.exe both fail to open the Vundo DLLs, they can simply be deleted from the system because they are no longer locked.
I hope this is helpful to somebody down the line.