Steps to be taken during an outbreak

Viewing 11 reply threads
  • Author
    • #5156

      Hello  Members!!

      I would like to know what steps to be taken during virus attack or security breach more like defined steps to be taken internally during an outbreak.

      And How do you go about remediating ( steps ) them..

      Please Share your Experiences.

    • #32623

      Hello Crossover,

      That’s a bit of a generic question to answer fully, do you have a specific incident in mind?

      A great overview of the steps I’ve used to deal with a number of issues is from SANS
      This covers dealing with incidents from start to finish.

      They’ve also go some excellent examples of IR in their reading room too.

    • #32624

      I remember when the ILOVEYOU virus hit us.  The admin *RAN* into the server room and pulled the plug on the exchange server.

    • #32625

      This is a very broad question, but for responses to these situations, any good security professional would have an incident response plan.

      In addition to What90‘s reply, check NIST Special Publication 800-61, Computer Security Incident Handling Guide.

    • #32626

      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.

    • #32627

      Thank you for responses. I have to check 800-61 publications yet  and i liked What90’s link ( and that is what i was looking for). I found article so i thought sharing as well.

      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 )

    • #32628

      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—Identification
      You (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—Containment
      You 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—Eradication
      Clean 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—Recovery
      Check everything is okay and staff can work normally again.

      Step Six—Lessons Learned
      Write 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.

    • #32629

      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:

      * Immediate action
      * Investigation
      * Restoration of resources
      * Reporting the incident to proper channels

      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.

    • #32630

      I have to echo the previous comments and say that an incident response plan is crucial.  It is worth noting that in some organisations this may be incorporated into a broader Business Continuity Plan.

    • #32631

      @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.

    • #32632

      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.

    • #32633

      Whatever you do, don’t act too quickly. There may be an APT in your organization.  A blog post on Mandiant’s website explains it better:

Viewing 11 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?