Re: Incident Response

[Josh Little <josh () zombietango com>]

 On 6/30/2010 12:05 PM, Craig Freyman wrote:
> I have a rookie question about incident response. 
>
> When the AV flags a virus, what steps should you take to handle the
> situation?
>
> I would assume the following would be important to figure out:
>
>     * What the bug is and how it works
>     * If any other malware has been planted
>     * What the bug actually did to the system, did it steal anything
>       or log anything?
>     * ??
>
> Looking forward to your responses......
>
> -Craig
Well, in the scenario you are positing here - IR in response to a
flagged event by AV - you need to first determine what did the AV
product flag on and what action was taken. Most enterprise consoles will
tell you this in one level of readability or another. Was the
site/file/execution blocked by the auto-protect feature? Was it a hit
against an existing running process that just now became a known piece
of malware due to a definition or engine update? So to begin with, I
would look to see whether we are looking at a flag against code that
tried to run on the machine and was prevented by the AV product or
whether it was a hit against an active process. Unfortunately, you can't
just assume that all is well for some alerts in regards to the first
case, AV blocking code execution. You will still need to do some level
of investigation against the machine to insure that the AV product
didn't miss something - i.e. it blocked only one of the three pieces of
malware that were put on by a dropper. This would be your fairly
standard event analysis stuff - looking for processes that differ from
your normalized process list, memory analysis to find injected
processes, etc.

As for determining what actually occurred on the system, there are
several things that can be done, depending on the risk level involved,
budget, time, and skill of the responder:
    - Reverse engineering the sample to determine function
    - Network forensics: what has the infected host been talking to that
is atypical
    - Basic research against already known samples of the same or
similar executables
    - For high risk systems that have been infected (a commerce server
for example), bringing in a outside IR specialist may be in order
    - Run the sample in a tightly controlled lab and monitor the sample
to see what changes are made to the system and what network calls are
made. Also, try submitting the sample to a sandbox service like Anubis
or Sunbelt's CWSandbox.

A lot of this revolves around really knowing your environment. That
means knowing what are the typical processes that run on each class of
systems (servers, desktops, etc), the user that each process should be
running under, versions, and in very high risk/value cases the hash
value of each process. What is the typical network traffic footprint of
each class of systems - i.e. is it normal for a DMZ server to initiate
an outbound SSH connection? Tracking something like Netflow records
helps immensely with this. In other words, the amount of work you put in
knowing and normalizing your network will payoff big time when it comes
to responding to incidents.

Josh Little

_______________________________________________
Pauldotcom mailing list
Pauldotcom () mail pauldotcom com
http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom
Main Web Site: http://pauldotcom.com