How-to: Removal of Conficker in your FCS environment

Another Conficker post :) however this one is aimed at our FCS customers.  It semi-applies to other customers however other AV vendors operated differently with regards to updates etc so this won’t necessarily be applicable to all.

So today is Patch Tuesday … Yeah!!!

With today’s releases we are finally getting some relief out for Conficker.  The main piece of relief is through the MSRT or Malicious Software Removal Tool which contains an updated set of definitions and engine to handle the Conficker family of malware.  There are both x86 and x64 versions of the MSRT that are released.  I’ve never been a huge fan of this tool before as realistically this is a post-infection tool and it has a very limited definition set see KB890830 for the list.  But when you are hurting with one of those on the list its a great thing to have around.

So you might say great my WSUS auto-approves that etc my clients are going to be all happy by tomorrow… WRONG.  Part of the Conficker Modus Operandi is to disable both the Automatic Updates and BITS services.  Automatic Updates (Windows Update in Vista) is your WSUS client so no joy for you.

So here’s what you should do to get things fixed in your environment.  First off you need a logon script assigned to your computer accounts (user accounts would work if you knew they had admin access on the systems).  The scripts need to basically call out to run the MSRT manually on the system. You will also need to get the AU/BITS services back up and functioning, you could either do this via the script and the SC command line tool (i.e. sc config wuauserv start=auto) or you could do this via GPO directly and set the startup state of AU to Automatic and BITS to Manual (default states).  I’m posting in here some example code that one of our engineers put together (thanks Shain Wray I believe)

REM Running MSRT locally

REM Checking for x86 or x64
REM To use this as part of a GPO Startup Script, change <> to your
REM domain.
REM Notice the copy of the MRT.log up to a central location has
REM <servername>\<share with write perms>. This is on purpose.
REM In most cases, opening a share with everyone write permissions on a DC
REM is not recommended, it is suggested to use a
REM member server or workstation.

if /i %PROCESSOR_ARCHITECTURE% == x86 goto x86
if /i %PROCESSOR_ARCHITECTURE% == AMD64 goto x64

call \\<>\netlogon\Sleep.exe 10
Start /wait \\<>\netlogon\Windows-KB890830-V2.6.exe /q

copy %windir%\debug\mrt.log \\<servername>\<share with write

goto End

call \\<\netlogon\Sleep.exe 10
Start /wait \\<>\netlogon\windows-kb890830-x64-v2.6.exe /q

copy %windir%\debug\mrt.log \\<servername>\<share with write



The sleep.exe can be found from the 2003 Resource Kit Tools.  So this script should be self-explanatory for MSRT. 

Once you have copied all the .exe’s to a share and assigned the script via GPO to your computers OU’s then you need to get your users to reboot their systems which will cause them to run/clean and should hopefully fix your environment.  If you need help with this try posting a question here first and I’ll try to respond however if you need immediate assistance call us. As always we are here and available to help!! Malware cases are FREE as in no $250 for a ticket no hours decremented from your Premier contract etc.  So get on the phone call the CSS # (800) 936-5800 I believe and let them know you have a malware issue and need a case to work with CSS Security.

So while typing this I just checked the MMPC’s blog and they have a good post and a beautiful picture that explains how the malware works as well

Comments (3)

  1. Anonymous says:

    Hi! Hopefully you have not been hit by this malware. But if you have (before you updated the FCS def

  2. Derek says:

    When I try to run the above script I am recieving a windows script host error, live 16 char 4 syntax error code 800a03ea.  Any thoughts??

  3. Karsten says:

    Derek, save it with a .cmd extension, not a .vbs one.