Home Operating Systems Windows General A Real World Encounter with Conficker
A Real World Encounter with Conficker PDF Print E-mail
Written by Tim Wray   
Wednesday, 23 November 2011 13:47

I recently had a massive war with one of the most notorious viruses of the last 3 years, and this is how we handled it. Hopefully it will be of some help to others.


How it began

At one of the facilities I work at, we have somewhere around 30 computers, as well as 20 or more machine controls that are Windows XP Embedded-based. One of the production cells was unresponsive, and the entire automation setup was pausing, staying delayed for long periods of time, and such things.


In the end, I discovered that the data collection software on the automated system was not running and that the automation expected it to return that it had received data. This problem, though, alerted me to the fact that many other PCs on site were giving virus warnings from our Symantec installs on older computers, as well as Microsoft Security Essentials on some of the newer computers. They were all finding signatures of the Conficker virus, variant B. Many of the computers would not run auto updating and could not contact Windows Update, particularly on Windows XP machines.


It didn't take me long to put two and two together in determining the attack vector inside the facility. Just a few hours before I had left earlier in the evening, it was requested of me to put a PC on the network so that it could be accessed via a VNC client in a conference room while a couple of employees trained on specialized software that was installed on it. The computer was used and had come from an external network. It was also severely unpatched, unprotected, and was infected from the time it was brought in. The first reports of trouble and network unavailability were very close in time proximity (10 minutes) to when the computer was first introduced into the facility's main subnet. Naturally, I was kicking myself for not having vetted the machine thoroughly before I hooked it up, but I was in a hurry and wanted to get home on time that evening, for reasons I cannot recall now, as well as the employees needing to train on the computer's software and having limited time with an instructor who was present to train them.


Being in a hurry was a MAJOR mistake this time.


Cleanup Process

After scanning several computers and cleaning them by installing and running Windows Security Essentials (which took about the first two hours), I realized that there was a possibility that the virus had infected some of our machining systems' controls. Due to the way one brand's controls were interfaced, they were infected. At this time, I called in the rest of my IT staff and we got to work.


As I realized how the systems were being infected via network broadcast, I took all ethernet switches offline. I also downloaded the latest version of the Microsoft Malicious Software Removal Tool, which was able to remove the virus quickly and without a need for the PC to be connected to the internet. I would scan the thumb drive I was using with the tool between visits to computers, as Conficker would usually attempt to replicate via the thumb drive if it had been inserted into a computer that was infected.


Naturally, as I began trying to find ways to clean the entire network, I started looking for a way to detect infection via network. This was a two part process that involved stopping the virus from being able to replicate via group policy on our domain-connected machines, and then running Zenmap (a frontend for the popular nmap tool) with a specialized command that returns whether or not a computer is likely infected with conficker.


First, you need to follow the "Stop Win32/Conficker from spreading by using Group Policy Settings" instructions in Microsoft article KB962007. There is a MAJOR PITFALL to this process, which you will read about shortly, and I will tell you how to fix it shortly. You need to run this step.


Next, Install Zenmap on a computer that is unaffected, and run it with this command:

nmap -p 139,445 -T4 -v -n -Pn --script smb-check-vulns --script-args safe=1

For deeper results, set "--script-args" to safe=0 and provide domain-wide login credentials to the script as follows (I highly recommend this, as I found three more with this method):

nmap -p 139,445 -T4 -v -n -Pn --script smb-check-vulns --script-args safe=0,smbuser=user@domain,smbpass=YourPasswordHere

Then, go clean each computer one by one with MSRT. Then, make sure Microsoft Patch KB958644 is installed. It can be downloaded for manual install from here, for all affected versions of Windows: http://technet.microsoft.com/en-us/security/bulletin/ms08-067. This patch is for the Server service in Windows, which the virus exploits to spread itself to other computers in the network.


If you can, install Windows Security Essentials on every single computer you can. Unfortunately, you cannot install it on XP Embedded, but you can use the server service patch and the MSRT, which should be good enough as long as you have the rest of the network cleaned up.



Aftermath and that MAJOR PITFALL!

When we had finished cleaning up all our systems, we started restarting servers and services, and we immediately ran into a problem with one of our production data collection servers. We could ping systems from the console, but the server could not be contacted elsewhere on the network. You could not even ping it.


Naturally, we assumed that Conficker had terribly molested the whole Windows install beyond usability. We discovered our Microsoft Sharepoint server, an AD Domain Controller, and one other production data collection server were all in the same condition, essentially unusable.


At this point it is 1AM, Saturday. The whole event started going down Friday night, 6pm. We spent the entire day Saturday, until late in the evening, trying to redo all systems, staring with Sharepoint. After we had gotten everything setup, it started exhibiting the same symptoms AGAIN. Services failed on start with various errors, no network services, etc.


So, we essentially spun our wheels in the mud for almost three whole days before we discovered, once I had read through the KB962007 article from Microsoft again, that though I had removed this special policy from being enforced on our domain, that DOES NOT give the required permissions to the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost key that are needed for Windows to function even close to correctly. To rectify this, go to the Svchost key in the registry editor (regedit), right click it, select "Permissions", and give full control to "Administrators" and "SYSTEM", then reboot the system, and all will be back to normal.


You could setup a policy that changes this permission back, essentially the opposite of the process done in KB962007.


I had actually formatted and restarted installation of two servers that had complex software tie-ins with PLCs and other automation components, and would have been stuck in the boat of trying to reconfigure them (many more days of work) if I had not made Symantec Ghost images of both servers before I had began. I was able to ghost them back to the way they were and fix that registry Svchost permission, and put them right back in service. So, ALWAYS GHOST so you have a snapshot of how things "were". That, though, is a subject for another article altogether.


Good luck in the trenches my brothers and sisters in IT. Blast that conficker!!!