Conficker has been doing the rounds for awhile, so it was only a matter of time before it found a way on to the network.

There are some fantastic write ups on how Conficker acts: Sneaky tricks, Autorun.inf , working groups , detection methods and resources.

Here’s how Forefront deals with it.

From a USB drive

When Conficker is on a USB drive, Forefront reports it as conficker.x!inf, x being the version, and happily wipes the autorun.inf file on the USB drive. It doesn’t remove the hidden file at detection; a scan has to be run on the USB drive to remove it. Nice and straightforward.

ON the network

When you get Forefront detected Conficker on a machine warning, this is the time you need to be worried. Why is it a worry?

Well gentle reader, this means Conficker was able to infect the machine and Forefront has stepped in to clean it after the fact.

By after the fact, I mean Conficker has attacked the system and dropped it’s dll and AT1.job in to a local folder on the attacked system.

Look in the attacked machine’s System event log, two Event ID 3004, Source FCSAM followed by a Event ID 3005, Source FCSAM have been generated.

Event ID 3004 is Forefront detecting and suspending the file, Event ID 3005 is Forefront removing the file.

IMPORTANT NOTE:

If someone is logged on to the machine Forefront is protecting and Conficker attacks it, the Forefront icon turns in to a red cross. If the user simply ignores this, that is doesn’t click the icon and press smart clean, after ten minutes Forefront removes or quarantines the file.

This means for those ten minutes the AT1.Job file and the .dll are on the attacked system, despite being in a suspended state. By suspended state, the files are still visible.

So how did Conficker get on the machine in the first place?

There are only three ways that can happen:

1)      Conficker was on the machine before you installed Forefront and Forefront detects it on first scan

2)      The patch to protect against Conficker, MS08-086 KB958644, is not installed and Conficker attacks the machine

3)      And the worst, by far, is an administrative account has been used to attempt to install Conficker on the machine

Ignoring the first way and using the deployment tool of your choice to patch your machines for the second way, let’s talk about big bad number three.

Here are some of the scenarios for way number three can occur first:

1)      You have a terrible password policy and the password of a local administrator account is in the guessing file of Conficker

2)      Conficker successfully attacks a machine left logged in as a local Admin with no AV

3)      Someone with administrator rights plugs in a infected USB in to the machine without antivirus (or the antivirus is horribly out of date)

So having Forefront installed on all machines and up to date is step one. Step two is user education on USB sticks. Step three is an awareness campaign to all of your IT admins. Since you’re using Forefront, Active Directory should be in use as well. If you don’t have money for smarter tools just use software deployment GPO’s to install Forefront and then use WSUS to push out the updates.

So now that I’ve taught you to suck eggs, here are some suggestions to actually help.

Group policy objects (GPO) can aid find Conficker infected machines First enable audit policies (Computer Configuration – Windows Settings – Security Settings – Local Policies – Audit Policies), with the most important being Audit account login events. Set this to success and failure.

With this GPO enabled and applied, when the next machine reports being attacked by Conficker connect to the machines Security event log and filter by Event ID 680. This ID deals with which account login in to the machine and from which machine.

What we want is the 680 successes as our number one priority, as this means Conficker has an account that can connect to the system. The 680 failures still tell which machines are attacking and can be add to the clean up task.

There a number of log parsing tools and scripts out there to automate finding the 680 event id on multiple systems, pick your favourite and use that.

The two pieces of information we are interested in are Logon Account and Source Workstation within the 680 event id. These two wonderful fields tell us which account and which computer successful attacked the machine.

Stating the obvious, run a cleaning tool Ms tool or any one of these or format and rebuild the computer only after taking a copy of the event logs. The more important part is the user account. In a number of companies, every machine has the same local administrator account. If this is a poor password, it is time to change it. Script out a password change for all machines, plenty of examples on how to do this are online.