That's a bit of a generic question to answer fully, do you have a specific incident in mind? well let's say conflicker virus ( I basically want to understand the procedures and the remediation steps it may or may be not conflicker )

Read the SANS link and break up your response in to steps in order to deal with the problem in a calm and rational way.

One possible way of dealing with a Conficker outbreak in a Windows active directory (AD) domain follow the SANS steps.

Step Two—IdentificationYou (as the security person) have been alerted of that there's a problem.In Conficker's case, AD user accounts have started locking out large numbers.

First thing to do is find a machine causing the problem and examine it.Looking in Domain Controllers event logs will show which machine(s) is causing the accounts to be locked out.

Once you've examined the machine and determined the problem, Conficker in this case, you need to work out what Conficker does and how it works in order to stop it. Then the why, who and how the machine got infected. For example: Was it patched? Did it have a working AV did the attack come from USB or another machine.

Step Three—ContainmentYou need to make the call on how to deal with the problem and get management involved. Do you go in hard and locking down the network and blocking internet access or do you quietly clean up the mess in the background? Conficker is well written, so infected machines aren't crashing and the AD locks can be scripted to be unlocked to minimise the down time effects on the staff.

Lets say you got a number of machines without out patches and no antivirus across the network and Conficker infected one of those machine from a USB drive. Scanning for infected or machines open to infection would give you a list of machines to fix and let you know how many machines are possible problems.

Quick fixes could be using group policy to turn on Xp's firewall and block port TCP 445, or force out the patches, AV and reboot machines. Searching for machines with AT1.job file and deleting that file will also slow up Conficker. If you have a network with modern switches, drop all the infected machines on to a special VLAN that has no access to the rest of the network and fix them as and when you have time.

Someone needs to talk to the staff and tell them in non-geek terms what the problem is and how not to make it worst (e.g. ban use of USB sticks while clean up the network)

Step Four—EradicationClean up all the infected systems and ensure all the other computers in the network are protected from possible infection. Find any infected USB drives and clean/remove them.

Step Five—RecoveryCheck everything is okay and staff can work normally again.

Step Six—Lessons LearnedWrite up what happened and put it in to a time line of events and actions. Work out what you could have done better and how this could have been avoided. You may suggest regular patching is a good idea, as is restricting the use of USB drives by certain staff.

what90 posted some excellent comments so I will chime in here. Your first goal above all (before an incident) is to have an incident response plan in place. This keeps you from running around like a chicken with its head cut off.

Borrowing from Redhat so I don't have to reinvent wheels I will chime in afterward:

The incident response plan itself can be separated into four sections:

An incident response must be decisive and executed quickly. There is little room for error in most cases. By staging practice emergencies and measuring response times, it is possible to develop a methodology that fosters speed and accuracy. Reacting quickly may minimize the impact of resource unavailability and the potential damage caused by system compromise.

In a business - any business - the order of the day is to make money. In a mission critical environment, you can't just "yank the machine offline" as others have suggested. If you plan ahead, you can remediate the situation. For example, because VMWare is cheap, you could have an exact image on standby to throw in place while you sanitize an infected machine.

There are plenty of things to do prior to an incident so I suggest you focus on pre-emptive tasks because after all - if an incident has struck you - no matter what plans are in place, you are dealing with it no? Setting up a checklist keeps a focus and a plan which in the long run save you time and your business money.

impelse wrote:First: olways disconnect the machine from internet and begin to work with that and if the whole companyI would protect the servers first and later the users.

This response could be jumping the gun a bit. Certain types of malware will go inactive or even delete itself if the network connection is pulled. A better step is to move the system to an isolated VLAN where further analysis can be performed. Part of properly responding to an incident is understanding what you have been attacked with.

I agree with what has been said. Have an IR plan written up before hand so that when something happens you aren't running around screaming yanking out cables. Containment is important, have a way set up to where if something happens, you can contain it to one machine. If the machine is not mission critical, you can disconnect it from the network. Have regular backups made, and validate them. Check them periodically to make sure they work correctly. I've heard of too many companies that go to back up their systems, only to find that all the backups they have are corrupted because they weren't created properly and checked.