Fighting Conficker

A lot of really good research has been published about the Conficker worm, its many forms, infection vectors and speculation as to what it’s going to do next. But what seems to be missing is the operational side of fighting Conficker. What signs would you expect to see, how do you really fight it and what can you possibly do to prevent it?

Here’s a fictional case study that may be of help.

Day one: Why is my account getting locked out?

You come in to the office thinking it's just another day in the security trenches, but when you try to log on to the network you
notice your account is locked out. OK, no big deal, although a little odd. You could call the help desk but you reset it yourself and then head for a cup of coffee when you realize a number of employees are wondering around mumbling about being locked out and complaining about a huge help desk queue.

OK, now something is smelling fishy. You start to check around and realize that accounts are being locked out all over the network. Time for your operational team to start doing some homework.

But where do you start? What if you don’t have central log monitoring or your intrusion detection system doesn’t see anything? One place to start: go to your directory service server logs and see which computer the source of the account lockouts is coming from. In Active Directory, you can use a free Microsoft tool called ‘Log Parser’ to search multiple logs at once.

Chances are that the logs will be overwhelmingly huge because of all the lockouts, but if you determine the main log entry in the Security log that is related to this issue (like event id 644, User Account Locked Out), use Log Parser to pull out all the relevant events and look at how many the source computers are generating. If there are 3 instances, this most likely is normal activity. If there are thousands, then this might be your culprit.

Maybe not though! Some computers may have an errant process running that generates that type of activity. The lesson here: make sure you use gentle language when describing the issue because accusing people of having infected computers without gathering facts can cause trust issues amongst staff.

If you can identify a starting point for the virus, make sure you grab log files and put them somewhere safe (application, security and system - not only for the infected computers, but for the directory service servers as well). At some point when things calm down, you’ll want these for forensic analysis.

Day 2 was spent dealing with more of the same. You’ve combed log files. You have identified that systems were in fact infected by the Conficker virus. And you have been cleaning and chasing it all over your network, even on systems that were patched and had up to date anti-virus software. You are frustrated and exhausted as are the rest of the staff that are trying to clean this stuff up!

Day three: OK, now we have a process to clean it

Before you tear all of your hair out, you do some more research and realize that running your anti-virus software alone may not clean the virus. Conficker has five known variants and can utilize the various versions to help itself spread fast and via different vectors. Looking at the research done by the Conficker Work Group, you find that the major anti-virus vendors have published a variety of repair tools that may clean the virus better than anti-virus alone. Furthermore, you start reading the fine print in the Microsoft Knowledge Base article on Conficker and you see that there is a Group Policy Object (GPO) that can be used to help stop the propagation of the worm.