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?
Fri, September 25, 2009
Network World — 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?
Conficker Hype a 'problem,' Says FBI Cyber-Chief
Kaspersky: 6 Million Users Infected By Conficker
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 younotice 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.
