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