PuzzleMaze - Trojan.Vundo.H
The purpose of this article is to detail my experience, what I did, what I learned about the pest, etc., so that removing the next virus is easier, and so that another virus newbie confronting this for the first time will not feel hopeless. This article is not How to Remove Trojan.Vundo.H from Your System, but How I Removed Trojan.Vundo.H from My System. (one thing that frustrated me during this process was websites along the lines of 'how to remove X from your system', which included nothing but lame, general platitudes such as 'remove infected services from task manager", and 'remove infected dlls from \windows\system32', followed by ads for spyware removal software. Gee thanks).
I am not affiliated with any of the software mentioned in this article. I am a free lancer who likes to write about stuff. I have a background in computer security, but NOT on Windows systems. I don't know all that much about Windows systems at all, as will probably come out in the article (and after learning the tiny bit about Microsoft security that I did during this experience, I will never buy another Microsoft product again, if I can help it). I had never been infected with malware in 25 years of using a PC. So I was a green newbie at this. I do not know what the attack vector was. The infected system was Windows XP, SP2.
Unfortunately, I continued to get the pop-ups. I again did a full sweep with Webroot, this time it claimed I was infected with Mal.Fake.Adav, or words to that effect, claimed it was removed, and I continued with my life.
As did the pop-ups, at some point later. I was not keeping detailed notes at this point, so I do not know how long it took them to regenerate, but with the benefit of hindsight, I think it was a while. I was still trusting Webroot. I ran Webroot for a third time, and this time it said my system was clean, despite the fact that I was still receiving the pop-ups. The only thing it did was to suggest that a suspicious entry called levojidon was being added to the Windows registry to run at startup. A google search did not reveal a single hit on "levojidon".
I am disappointed with Webroot, both the product and its support. It did everything wrong -- it said it removed the infection when it did not, it failed to detect the infection when the evidence was overwhelming that it remained, and their support was lame.
I made a support call to Webroot, detailing the issue to date, and was asked to do some things to generate logs, and send them in. I was told I would receive a response "within 24-72 hours", or I could pay to get faster service. At the time of writing, it has been over 120 hours, without even the courtesy of a response. Again, with the benefit of hindsight, I am certain that if I had opened my wallet on the pay-to-play service, that it would have been a waste of money. And that boiled my blood -- I am paying for the software to detect and remove malware; when it fails at that task, why should I be expected to pay more?
I will not be renewing my Webroot subscription. The proper response of the Webroot software should have been: 'we have detected Trojan.Vundo.H, and it cannot be removed by this software. Here are some recommendations'. Instead, its failure appeared as an upsell for paid removal services. Very disappointing, for what I felt (and still do, actually), was a reputable package.
http://www.malwarebytes.org/mbam.phpThe first problem was that the software refused to run at all. Clicking on the desktop icon generated an error claiming to not be able to find mbam.exe. I reinstalled it, same problem.
One of the principles of security is, that on a compromised system, you can't assume normal causes, or that any of your usual premises are in place. I figured there was a chance that the malware itself was causing this failure. I was right. I opened a command prompt in the Malwarebytes install directory, and continuously did a 'dir' while it was installing, and noticed mbam.exe was indeed being installed, then being deleted. Geez.
I did another install, and quickly copied mbam.exe to another name before it was deleted. I think you have about 2-3 seconds to do this. I was able to successfully run Malwarebytes under the new name. A google search later confirmed that one of the symptoms of Trojan.Vundo.H (et. al.) was to delete mbam.exe when it was installed.
Gee, it seemed afraid of this thing. I felt optimistic. It certainly didn't seem afraid of Webroot; in fact, as I was later to learn, there is evidence that it actually uses Webroot as part of its process! (of course, it also remains possible that the malware simply was able to disable Webroot''s reporting of its existence. Again, all premises are off on a compromised system).
I did a full scan with Malewarebytes, and it detected Trojan.Vundo.H, and said it would remove it on a reboot. (The issue, I later learned, was that part of the malware is dlls that are in use by running processes, and that they could not be deleted now, but had to be marked for deletion on reboot. This became a crucial point that I did not understand at the time).
Malewarebytes also detected the 'levojidon' entry in the registry that Webroot reported, and reported an additional registry entry to run at startup -- a seemingly random NNNNNNNN.exe, where NNNNNNNN is an eight digit number. Malewarebytes associated these entries with Trojan.Vundo.H. This NNNNNNNN executable was created in a directory of the same name under
c:\Documents and Settings\All Users\Application Data
Before removal, I ran Webroot again, to see if it could see the malware now (perhaps it cleaned it, and I was reinfected), but it did not, although it picked up the 8 digit random number exe in the registry this time.
So, I asked Malewarebytes to remove the malware, rebooted, scanned again, and everything seemed fine. I went on with my life, and everything was fine.
I was more impressed with Malwarebytes than Webroot, and will consider a paid license when my Webroot one expires.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
called 'levojidon' and 'NNNNNNNN.exe', where NNNNNNNN is a seemingly random 8 digit number.
c:\Documents and Settings\All Users\Application Data\NNNNNNNNWhere NNNNNNNN is the same as above, which contained the .exe and a .bat file with the following contents:
(I did not have taskkill on my system, so, as I was to later find out, once this thing started, it churned forever. The randomly named .exe (muwesoli.exe in this example) was something I could not find on my system, and, at this point, I was unaware of its relevance.:try taskkill /im muwesoli.exe /f del "C:\WINDOWS\system32\muwesoli.exe" if exist "C:\WINDOWS\system32\muwesoli.exe" goto try cmd.exe /c start C:\DOCUME~1\ALLUSE~1\APPLIC~1\46054019\46054019.exe /install del "C:\DOCUME~1\ALLUSE~1\APPLIC~1\46054019\46054019.bat"
Why did things seem fine for a while after Malwarebytes claimed to have removed it?
What triggered it to regenerate?
The obvious answer to the second question was a reboot, but several reboots during the day did not cause it to regenerate (I was using the registry entries as evidence of regeneration).
One thing I did discover, I believe from the Malwarebytes log, was that when Windows boots, it lists everything that it runs (well, this isn't exactly true, but true enough for this purpose) in a the following directory --
c:\windows\prefetch
This seemed like a major discovery on my part, but I suppose that if I were a Windows guy, I would have already known this. Anyway, I noticed that the NNNNNNNN.exe referenced above was running at this time. But Malwarebytes had removed it from the Run key in the registry. So, what was causing it to run? If I could figure this out, I'd be onto something.
The only other things running at the time (I looked that the timestamp of the NNNNNNNN.pf file in that directory) were system executables. I did a checksum of those executables against known good copies, and they were fine. I didn't understand what was going on.
During this research, however, I discovered a tool that claimed to specifically remove Trojan.Vundo.H. It even has a Wikipedia entry. Cool, this must be the answer. At least it seemed legit, in contrast to all the bullshit web sites that claimed to tell you how to remove it, but were simply too vague to be useful, and nothing more than pitches for some product.
I downloaded VundoFix from this web site --
http://vundofix.atribune.org/
With evidence of the malware in the registry, and Malwarebytes reporting it there, but not removing it, I ran VundoFix to see if I would have better luck. Unfortunately, it didn't even detect the malware, much less remove it. It claimed my system was clean. I don't know how this thing is supposed to work, but you would think that something that claims to be designed for this specific purpose would at least detect it. Again, it is possible that the malware itself is disabling VundoFix from working properly, I suppose.
In any case, it was a dead end, so I asked Malwarebytes to remove the thing again, and pressed on with my life. One thing that seemed clear was that at least at this point in my understanding, I had reached a steady state, where I would simply monitor the registry, and when the thing came back, I would ask Malwarebytes to remove it. But this was a wholly unsatisfactory existence.
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspxThis tool is hot, and seems a must have in general. It allowed me to monitor changes to the registry, files, directories, all of it.
It seemed all I had to do was filter on changes to the 'Run' registry key above, and to the 'c:\windows\system32' directory looking for the creation of rogue dlls, and the 'c:\documents and settings\all users\application data' directory to see which process was creating these things. When the system rebooted with symptoms, I would know. I set up these filters, let it run, and went on my merry way.
One thing I noticed when this thing was running was that every process on the system periodically wrote to a hidden file called 'kopayowu' in the 'c:\windows\system32' directory. Astonishingly, I thought nothing of it, as perhaps this was some sort of normal Windows logging, and Malwarebytes didn't report or remove this file as part of its process. In hindsight, this turned out to be a clue I overlooked. Other than this, procmon wasn't showing all that much activity on this filter.
Then, as I was doing other stuff, at some seemingly random point, procmon lit up like a Christmas tree. All sorts of activity in the three places in my filter. I had caught the thing doing a regeneration.
Procmon is a difficult tool to use, and the log files are huge, but working thru them, I discovered that winlogin.exe was the process responsible for the regeneration. I also noticed that it occurred at 6:51 PM. What was special about that time? What event had triggered it? I remembered that that was the timestamp on the c:\windows\prefetch files from the morning.
I now had my two answers. The trigger for the regeneration appeared to be 12 hours after the last regeneration, and the process responsible appeared to be winlogin.exe. However, I had done a checksum check on winlogin.exe earlier, and it appeared fine. This was something I didn't understand.
I followed thru the procmon log to see what was going on. It appeared that winlogin woke up, enemerated all the registry entries under the 'Run' key, then looked for an entry called 'livojidon' and 'MS Juan' (the latter apparently an alias for this malware). It, or another component of the malware, in various order, created the NNNNNNNN directory referenced above, ran that .bat file, created some dlls and an exe in the C\windows\system32 directory, and ran that exe as well. I didn't keep detailed notes on the order of operation, or which process called which, as I saved the log file in case I ever need this info.
It ended up opening alot of system processes, it appeared to run Webroot, for what purpose I don't know. Anyway, the regeneration was now complete, and while I knew when and which process was responsible, what was I going to do about it?
One thing I did notice when reading thru the log was prevalent references to a dll called tubakile.dll. This had shown up in \windows\system32, but Malwarebytes did not identify it as a component of the malware. I also noticed it had an old date.
However, I also noticed in the procmon logs that one of the things the malware did was change the dates on the components it created (procmon is really a beautiful tool, to show all this detail). I surmised that tubakile.dll was a piece of the malware that merited further investigation.
One thing I didn't understand, tho, was that if tubakile.dll was the heart of the malware, why was winlogin the process that initiated its regeneration? I have no clue, but apparently rogue dlls can attach to system processes and modify their behaviour? Who knows? This was my working model, in any case.
You can't just delete tubakile.dll. You get a message that says it is in use by another process. This fit with my working model as above.
Fine, I had the perfect tool. Malwarebytes has a component called 'FileAssassin' that will delete in-use dlls. It had successfully deleted the others as part of this process. All I had to do was run that; the only reason it didn't work before was because Malwarebytes didn't identify tubakile as part of the malware.
So, I went to c:\windows\system32, did 'dir /ah' to verify that it was there, and asked Malwarebytes to delete it. It correctly said I would need a reboot, which I did. Back to c:\windows\system32, did 'dir /ah' again, and tubakile.dll was gone. Woohoo!, and I went on with my life.
In playing with FileAssassin, I noticed that when you delete a file, it changes it from hidden to not hidden. I was doing my test above with 'dir /ah', which means (I think, anyway), show hidden files only. After I ran FileAssassin, tubakile.dll was plainly visible, but not with 'dir /ah'. Malwarebytes FileAssassin failed to delete tubakile.dll on reboot; I simply thought it had because it did not show up the way I was running 'dir' and the attribute change. I tried again with FileAssassin a few times after I realised this, but no dice.
Just a note about what I think is going on here. When a dll is attached to a process, either legitimately, or as malware, you cannot delete the dll unless you stop the process it is attached to. Tools like FileAssassin appear to get around this by marking the dll for deletion at boot, but if the dll is attached to a process that boots before Malwarebytes (such as winlogin.exe in this case), it is in-use even at this early state, so no dice. I don't know the order that processes run at boot, and in theory, if this is more or less random, you could keep trying and hope Malwarebytes runs first and deletes it before winlogin.exe runs, but it seems even more likely that it is not random, and important processes such as winlogin.exe run first. Thus, if it is attached to winlogin.exe, as the evidence indicates, you may be screwed using this method.
Microsoft does offer a utility that can be possibly leveraged to get around this problem, called inuse, available here --
http://www.microsoft.com/downloads/details.aspx?FamilyID=3a9927b6-0b0a-4261-b29b-3e78aa7618ac&displaylang=en
According to the documentation, you can only replace dlls, not remove them with this tool. However, it seems possible, in theory, to replace tubakile.dll with just a random non-Malware dll. Then, with the malware inactive, remove the new tubakile.dll using other methods that were impossible with the malware active (more on that later). Based on what I know about this thing, and the tools available, there is reason to believe that this approach could work, assuming both the replacement using inuse worked in the first place, and attaching a random dll to winlogin.exe would not destroy the system. It certainly would seem more likely to work if the replacement dll were coded with the proper entry names, if you could figure them out. I never tried this, and certainly don't recommend it, unless you know more about what is going on here than I do, but it was to be my last defense.
Just an editorial about how stupid Microsoft is. (I could write many based on the stupid security model that lets application level processes affect system level processes (at all, much less without local operator consent), but that is for a different day).
Microsoft has a utility called taskkill that will let you kill any system process, and thus crash your system, but doesn't give you a utility to kill a dll, presumably because they are afraid the operator will use it to crash their system! Rogue dlls are allowed to attach to system processes without owner consent, but the owner is not allowed to initiate a deletion of said dlls by their own will! How stupid and illogical is that? I've never had all that much respect for Microsoft technology, but after this experience, I have absolutely none.
There was actually evidence that this could be done, if done quickly. There is a utility called unlocker that can apparently break the in-use association, available here --
http://download.cnet.com/Unlocker/3000-2248_4-10493998.html?tag=lst-1&cdlPid=10838644There is also a website that describes how to do this (a reply in this forum) --
http://www.softwaretipsandtricks.com/forum/windows-xp/16022-cannot-delete-dll-files.html
And I quote from the above --
Use the "Unlocker" software with the infected file and unlock all the files linked to the virus or spyware. In this moment you have to be very fast and throw the file into the trash basket, if you don't make it fast, the computer is going to restart (in my case, because I was killing to important processes: winlogin.exe and explorer.exe) and you'll miss the chance to make it in one simple try, I think that you have 2 or 3 seconds to do this action.
So, I was still missing a step. I needed to know which processes tubakile.dll was attached to, in order to follow the recommendation of using unlocker. This is where other websites fall short, they don't tell you how to do this.
Here's how. There is a utility called Process Explorer (procexp) that does this, available here --
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspxJust click Find->Find DLL or Handle. All the process that that DLL is attached to are listed.
Then I needed something to kill them with. There is a utility called taskkill, mentioned above, that will kill anything; unfortunately, it doesn't come will all versions of XP, including mine. Why does Microsoft do this? This is an essential utility for any operator of an operating system. So I had the added hassle of finding and downloading taskkill, which I did from here --
http://members.ziggo.nl/gigajosh/2005/05/taskkillexe.html
I noticed a ton of processes had tubakile.dll attached to them, according to procexp, including procexp and a program I wrote myself. I didn't understand how this was possible, but didn't care, it was time to bring out the chainsaw. I booted into 'Safe Mode' to minimize the number of processes I had to look at.
Which is when the sinister nature of this beast finally hit home. I realised why it was attached to procexp, et. al. It appeared that when any process was started on the system, tubakile.dll would immediately attach to it. At least this is what procexp was reporting. How is this even possible? This presented a paradox; how could the above recommendation work?
Once I killed the system processes, even if I got the order right (and I believe you can buy more time by killing smss.exe first), you still need a shell to do the deletion. On XP, this is usually explorer.exe, which was also infected, and thus must also be killed. It would seem possible to have an alternate shell, such as FreeComander, but how could you start it? I set up an icon to delete tubakile.dll, but that of course died when explorer.exe was killed.
As tubakile.dll was attached to every process running on the system, and would attach itself to every new process, including shells, I saw no way to do this. If I knew a bit more about Window's internals, I might have been able to write a small shell to do this (like a lightweight .com file from the old days which perhaps dlls didn't attach to), but I didn't know how to this or if it was possible. I'm a Unix guy, after all.
Despite a promising start, this, too, was a dead end.
This sounded like a good idea, problem is that my PC vendor didn't bother to include an XP installation disk with my PC (the install set is on the hard disk; how stupid is that?), so I didn't have it. Another seemingly dead end.
Turns out you can download the Recovery Console boot system from Microsoft if you don't have it, but only for floppies! How stupid is that? If they can give you one for floppies, why can't they give you you one for CD/DVD. Where was I going to find a USB floppy drive, and blank floppy disks, and 11 in the evening?
Anyway, I downloaded this package from here --
http://www.microsoft.com/downloads/details.aspx?familyid=15491F07-99F7-4A2D-983D-81C2137FF464&displaylang=enbecause there is a utility that will convert this floppy bootset and burn a bootable CD, which I downloaded from here --
http://tips.vlaurie.com/2006/05/recovery-console-for-those-without-an-xp-disk/
This was the first download I had made during this process which I could not verify its safety to my satisfaction via third party web sites. I read thru the package, looked at the programs as best I could, and let if fly. I was desperate after 4 long days of fighting this thing.
The package worked without a hitch. I couldn't believe it. In a matter of minutes, I now had a bootable XP Recovery Console. I don't know if the package was safe, but I didn't notice anything bad happening.
I booted the Recovery Console off the CD, deleted tubakile.dll, and that was the end of it. Woohoo. No ill effects, and no evidence of infection since. I now press on with my life.
A couple of notes about Recovery Console. When it boots, it can appear that it is about to do a full install. This made me real nervous, but eventually it gave me the chance to go into Recovery Console. You also must know the Administrator password on the system being booted. For many people, this is blank. If you don't know what yours is, you should not be doing any of the things in this article :) Also, you will need to know how to tell your machine how to boot off of a CD.
One conclusion that I think can be made with a relative degree of certainly is that I believe that it is impossible for any legitimate malware removal product to remove Trojan.Vundo.H. That is the conclusion from my research on this. (The one big caveat is that I knew nothing about Windows before this experience).
You need an "out of band" mechanism, such as Recovery Console, making the affected disk a slave, etc.
This is a sad statement about Microsoft engineering and security, and I will be buying a Mac next time around the block, if I am able to. Its not that I'm affected by malware all that often, it is the principle of buying a product that is a demonstrated piece of junk. What rational individual would set foot on an aircraft with such demonstrated core engineering flaws? Why do consumers tolerate it from their computers?
