There will be a junction in the Windows directory where the main core of the virus is located. This can be found, neutralized, and removed by one of two methods:
A) (easy/recommended) Using junction.exe (http://technet.microsoft.com/en-us/sysinternals/bb896768) from a command line, type:
junction /accepteula -s c:\ > junctions.txt
Then press enter. This process should take a few minutes, so if it doesn’t finish right away, leave it alone. When it completes, open junctions.txt and look for a line that looks like this:
Failed to open \\?\c:\\WINDOWS\$NtUninstallKB46089$: Access is denied.
B) (more involved) Using Gmer again, if you can run it, go to the Files tab, then proceed to C:\WINDOWS making sure to click the Windows folder in the left pane, rather than on the right. Once it finishes loading the Windows directory on the right side, there will either be one, or upwards of 40, $NtUninstallKB directories. If there is only one, it’s more than likely the one you are looking for, which can be confirmed by entering the directory (inside Gmer) and seeing some numeric files that show red writing (Gmer flags malware files in red text). If there are a good amount of the $NtUninstall directories, you can find the malicious one by comparing the name lengths of these files. The malicious directory will Always have one less digit than the rest. This can be confirmed in the same manner as listed above.
Step 3
You have found the junction, now to neutralize and remove it by using the following [built-in] Windows commands:
- (XP) cacls c:\WINDOWS\$NtUninstallKB46089$ /p everyone:F
- (Vista/7) icacls c:\WINDOWS\$NtUninstallKB46089$ /grant everyone:F
- Afer performing either command, press Y for Yes

####################################
On some systems, mainly Vista/7 systems, the above will say it processed the directory, but the kernel-level monitoring for this rootkit will change the permissions directly back to what they were, so fsutil will say Access Denied. To get around this, you will need to use
Inherit.exe (sirefef.com/inherit.exe)
which will force inheriting permissions from the parent directory.
This can be done one of two ways:
- Drag the directory, or file, onto Inherit.exe, which will result in a prompt that says OK. Click OK.
- Use CLI and type: inherit.exe c:\path\to\directory\or\file – which will give you the same OK prompt
###################################
After changing the permissions on the windows junction, use the following combination of commands to neutralize it:
fsutil reparsepoint delete c:\WINDOWS\$NtUninstallKB46089$

rmdir /s c:\WINDOWS\$NtUninstallKB46089$ 
To remove the loader.tlb, a reboot is necessary, BUT DON’T REBOOT YET!!!!!!
Step 4
If junctions.txt lists
c:\\Windows\assembly\GAC_MSIL\Desktop.ini (there may be more than one)
this needs removed as well. To do so:
- cd C:\Windows\Assembly\GAC_MSIL
- cacls desktop.ini /p everyone:F
- attrib -s -h desktop.ini
- del /f desktop.ini
To make sure they are all gone out of this directory, type:
dir *.ini && dir /a:h *.ini
File not found is what we are looking for here. If you find any desktop(2).ini files or anything that looks like that, they can be deleted using the above method.
Step 5
There should still be a piece of the infection left in:
C:\Windows\system32\drivers which will cause everything to come back if not caught. It seems that this rootkit picks .sys files out of this directory at random, and I have seen up to 2 infected at the same time. To find this infection, we will want to use:
TDSSkiller (http://support.kaspersky.com/downloads/utils/tdsskiller.exe)
For this, you simply download the executable file, run it, then click Scan Now. After it finishes, it should present you with the results, and actions associated with those results. If any of these actions are set to Skip, then TDSSkiller is not able to remediate that file.
Common drive files sirefef infects are:
- netbt.sys
- mrxsmb.sys
- cdrom.sys
- afd.sys
- ipsec.sys
- beep.sys
- volsnap.sys
- rdpcdd.sys
- rasl2tp.sys
- redbook.sys
These files CANNOT be simply replaced, as the rootkit monitors the infected file(s) at the kernel level and will replace it the millisecond that it is modified
###############################
A word of caution:
TDSSkiller only catches the driver infection about 70% of the time.
With newer variants, even the newest version of this utility isn’t picking up the infection. I have provided the above list for you to do your own troubleshooting if TDSSKiller comes up clean. Do Not Trust It.
It’s a bit time-consuming, but you can upload these files, one at a time, to one of the following websites:
TAKE THIS EXTRA STEP. IT’S WORTH IT.
DO NOT TRUST A CLEAN TDSSKILLER RUN!###############################