In early October, 2009, my system became infected with Trojan.Vundo.H.
I successfully removed the thing after 4 days of work. It was not an
easy task, except in the end, once I began to understood how it worked.
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.
I hope people find this useful. If so, you can
throw me a bone. Every little bit helps.
The original symptoms of infection were pop-up ads when I used my
browser (Firefox 3.5.x). I don't know what they were for, as I close
all pop-ups instantly. I knew they were different than normal, however,
as they occurred when visiting known pop-up free web sites, and were
occurring at random, unrelated web sites.
My first response was to try Webroot Antispyware with Antivirus, or
whatever its called. I have a subscription with a modern version and
updated definitions. I did a full sweep of my system, and it claimed
I was infected with Troj.Vertum.Gen, which it claimed
to have removed. Ok fine, I went on with my life.
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
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.
Next up was Malwarebytes' Anti-Malware. I downloaded this package,
and updated the definitions, from here --
The 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
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.
What I Knew to This Point About Trojan.Vundo.H
So, I thought everything was fine, but next morning, Trojan.Vundo.H
was back. The evidence was that the registry entries and directory
referred to above were back. Another scan with Malwarebytes verified
that it was back.
I now realised that I was in serious trouble. I didn't know what I
was dealing with, or enough about Windows to know how I was ever going
to figure it out.
I now had two questions --
Why did things seem fine for a while after Malwarebytes claimed to have
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 --
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.
A google and more research indicated that this pest was extremely
difficult to remove, and that many had had to resort to a reformat and
clean install. That was the last thing I wanted to do, especially since
I wasn't really sure how to do it.
During this research, however, I discovered a tool that claimed
to specifically remove Trojan.Vundo.H. It even has a
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 --
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.
Even tho the trigger was not a reboot, I needed to find out what was
going on at reboot, because it at least it did run at that time
occasionally. I found a tool called Process Monitor
(procmon) that claimed it do this, as well as monitor what was going on on the
system in general. Seemed useful to me. I downloaded procmon from
this site --
This 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
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
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
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.
I googled it, and it now seemed obvious that this was the heart of the
malware. The question is, how to get rid of it? Everything I read
came up with horror stories about how impossible it was to remove.
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
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
But it was not to be. The malware was back 12 hours later. Why?
Turns out because of what I think is a minor bug in FileAssassin,
and my major stupidity, I thought it was gone when it reality it
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
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
So the problem came down to figuring out how to delete tubakile.dll,
which was in-use by the winlogin process, which, if you deleted, would
crash the system, leaving no system in which to delete the dll. A
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 --
There is also a website that describes how to do this (a reply
in this forum) --
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 --
Just 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 --
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.
Another approach people had reported success with is Recovery
Console. Recovery Console is a tool that comes on some
Windows XP install disks. It basically boots into a primitive shell
that allows you do file commands (such as delete dlls) in the Windows
directory, presumably without any Windows processes running.
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 --
because there is a utility that will convert this floppy bootset
and burn a bootable CD, which I downloaded from here --
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
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.
Well, I suppose I could have just written the last section. But it
was important to me to document everything I tried. I hope someone
else finds it valuable. I know I will if I ever encounter another
malware. Besides, it is easier to believe the recommendation of
'jump right to Recovery Console' after seeing everything else that was
tried and failed. I do think my observations and notes explain some things
about Trojan.Vundo.H that will help clarify some things for people.
Disclaimer: The software and methods referenced in this article
worked as described on my system, as far as I know. There is no
assurance, however, that they will on your system, will be safe,
etc. You assume the risk of of using any software, methods,
recommendations, etc., referred to in this article. Trademarks
referenced are the property of their owners.
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?
Well, if you found this useful in removing Trojan.Vundo.H, please
consider a tip.