It all started on Valentine’s day. I don’t know which virus we got, but that’s when the wicked pop-up windows started happening. Before it was all done, we came within a hair’s breadth of reformatting the hard drive on the computer. In a last-gasp effort, we emerged victorious over the Trojan.Vundo, Downloader, AntiVirus2009, and Trojan.Metajuan viruses. There may have been something else, but that was all that Symantec End-Point Projection could find. It took surgical warfare in the trenches of c:\windows\system32 before we were able to dispatch the enemy once and for all.
Initially we suspected that Google Toolbar had been infected. So we uninstalled the Firefox web browser. When, thereafter, the pop-ups continued, we suspected that Internet Explorer was the culprit. This seemed to be confirmed when WeatherBug, which uses the IE Engine, was accompanied by the vile pop-ups. I uninstalled Weatherbug, because it’s a virus of sorts itself (I hate how it tells itself to load on startup if you EVER start the program manually.)
We began to get a better understanding of the real culprit when we attempted to uninstall Internet Explorer. An attempt to delete the entire Internet Explorer directory was fruitless, as Windows reported that it was in use. We were able to delete iexplore.exe, however—except that five seconds later it was back.
At that point, my son and I put on our deep-sea SCUBA gear and plunged to the supposedly safe depths of Windows Safe mode. It wasn’t entirely safe. We were able to delete Internet Explorer . For good measure we deleted the entire directory. We’re using Firefox and Opera now, thank you. ;-) We found every other instance of iexplore.exe on the hard drive and deleted it as well. Then we emptied the recycle bin.
It helps when you’ve been attacked by Vundo-Downloader-AV09-Metajuan to have another computer to compare to. A very helpful clue was that we noticed that rundll32.exe showed up in the process list of the infected computer, but not in the list of the non-infected computer. Whenever we would end the rundll32.exe process, it would pop right back in the process list. With some help of notes from the Symantec web site, we ran msconfig.exe and found a strange looking process that was in the list. It used rundll32.exe to invoke (in our case) a DLL called tehutaah. We disabled that line in the startup, but when we would restart the computer it would come right back. This was one of the issues that was (sort of) fixed in safe mode (but not completely—read on).
It occurred to me after we encountered tehutaah to look in c:/windows/system32 for further activity. This is where we hit paydirt, except it still took about 2 hours to clean everything up. We sorted all files in c:\windows\system32 by descending date, using file explorer. Several DLL and INI files had been recently created. The other advantage is that, because a spawner dll program was creating new ones of these almost as fast as Symantec got rid of them, the filenames were easily noticeable, because they were random jumbles of upper- and lower-case letters (and occasionally numbers, I think, but I don’t remember for sure). One by one, I determined whether any of those files existed on the non-infected computer (hardly any of them did). If they didn’t exist on the non-infected computer, my son deleted them on the infected computer. It came down to 2 DLLs and 2 INI files that could not be deleted—even in safe mode—because somehow the DLLs were in use by windows. (I think my next computer will be a Macintosh.) The culprit files, in our case, were called:
· EfcYOHXn.dll
· nxHOYCFe.ini
· nxHOYCFe.ini2
· ddvngs.dll
We first did a search in the registry for ddvngs.dll. While we found the following on the non-infected computer (AppInit_DLLs value is blank):
we discovered that on the infected computer, the AppInit_DLLs value was set to ddvngs.dll , which was one of the files that we couldn’t delete from c:\windows\system32. We changed the value of AppInit_DLLs on the infected computer to blank (as illustrated above) and restarted the computer in safe mode, at which time we were able to get rid of ddvngs.dll.
But we still had EfcYOHXn.dll and nxHOYCFe.ini & .ini2 to deal with. (Notice that the base name of the ini and ini2 files is the base name of the dll file spelled backwards).
I right clicked on the DLL file and performed a Virus scan, and it came up clean. I right clicked on the DLL file and performed an Ad Aware Scan, and it came up clean again.
We couldn’t delete EfcYOHXn.dll, even in safe mode. But I could delete the ini and ini2 files. Just like the iexplore.exe file discussed earlier, however, both files were regenerated within a few seconds.
Not being able to delete the EfcYOHXn.dll I was able to rename it somehow. Before restarting the computer again in safe mode, we did a search in th registry for EfcYOHXn and found that instead of how it looked on the non-infected computer (Application Packages value is “mxv1_0”):
the value of the “Authentication Packages” token had two values—not just “msv1_0”, but also “c:\windows\system32\efcYOHXn”. We found and cleared this extra Authentication Packages value out of several ControlSet registry entries.
Then we restarted in safe mode. Then we were able to delete the dll file. Then we were able to delete the ini files, and they never came back.
