Threat Level: green Handler on Duty: Russ McRee

SANS ISC: Using Powershell in Basic Incident Response - A Domain Wide "Kill-Switch" - Internet Security | DShield SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Using Powershell in Basic Incident Response - A Domain Wide "Kill-Switch"

Now that we have the hashes for all the running processes in the AD Domain, and also have the VT Score for each hash in the system, how can we use this information?  Incident Response comes immediately to mind for me.  If you've ever been in a medium-to-large-scale "incident", the situation that you often find is 'we know everything seems to be infected, but out of thousands of machines, which ones are actually infected right now?  Not only that, but "our AV doesn't detect this exact malware yet, or if it does, it detects it but doesn't kill it or delete it".  The methods we've looked at these last few days allow us to enumerate an up to the minute list of infected stations, outputting a "punch list" for the responders fixing those stations.  Not only that, but we can tack on a "kill switch" command that will terminate (and even delete) the running malware if the AV product isn't doing that.

What we don't want to do is to automate this too much or too soon - don't take the VirusTotal listing and do any global kill process code based on just that!  You might for instancesee a hash collision, and kill a good process.  Or, much more likely, we could have one AV vendor in the VT pool (which as of today is 66 vendors) return a false positive for our hash.  And if one vendor returns a false positive, you'll likely find 5 or 6 more vendors who as a first step in their automation process is "copy that other vendor's result".   So one false positive almost always ramps up to 4-5-6-7 in short order, ramping back to zero will often take longer than the ramp-up.

What we want to do is take all of our inputs to ensure that the file hash is a true IoC for the current infection.  At this point, should we use the output of our first script?  The short answer there is "NO"!  The Windows process numbers may have changed, and we likely don't want to go killing processes by name (unless we are very sure that we don't have a name collision in our infection).

What we'll do is take our known malware hash, and sweep the domain looking for a match at this instant.  If we find one on a machine, we'll kill that process and return the machine name and the various file names affected.  If you deep in IR mode, you might also want to delete those affected files (or at least try to).

Our code should look something like the sample below.  Again, BE CAREFUL - targeting the wrong process can easily bluescreen an entire domain in minutes.  If you add the "delete" line, if you accidentally target something that Windows needs those bluescreened devices won't be coming back without help (every AV vendor has learned this the hard way):

function EnumAndKill {
    $targethash = @()

    $retlist = @()

    foreach ($proc in Get-Process) {
    try
        {
        # hash the executable file on disk
        $hash = Get-FileHash $proc.path -Algorithm SHA1 -ErrorAction stop
        if($hash -eq $targethash) {
            $retval = @()
            $retval | add-member -membertype noteproperty -name HostName -value $env.ComputerName
            $retval | add-member -membertype noteproperty -name TargetHash -value $hash
            $retval | add-member -membertype noteproperty -name ProcessName -value $proc.name
            $retval | add-member -membertype noteproperty -name FilePath -value $proc.path
            $retval | add-member -membertype noteproperty -name Result -value ""

            Stop-Process -InputObject $proc
            $killconfirmed = Get-Process | Where-Object {$_.HasExited}
            if ($p.processname -match $killconfirmed.processname)

               {
               $retval.Result = "SUCCESS"
               # possibly add a delete of $proc.path here (depending on your situation)
               }
            else { $retval.Result = "ERROR"}
            $retlist += $retval
            }
        }       
     catch {
        # error handling.  If the file can't be hashed - either it's not there or we don't have rights to it
        # note that you will need to edit the host and share for your environment
        # no catch statements in this function
        }
    }
    $retlist
}

$TargetHash = "<our target hash goes here>"
$targets =get-adcomputer -filter * -Property DNSHostName
$count = $targets.count
$i = 1
$DomainKillResult = @()

foreach ($targethost in $targets) {
   write-host $i of $count -  $targethost.DNSHostName
   if (Test-Connection -ComputerName $targethost.DNSHostName -count 2 -Quiet) {
       $DomainKillResult += = invoke-command -ComputerName $targethost.DNSHostName ${function:EnumandKill($TargetHash)}
       ++$i
       }
   }

 

 

We *really* could have used something like this in an incident that I worked about a year ago.  Multiple timezones, limited IT resources, and a variant of trickbot that (at first) no AV  product would detect, and later even when the products would detect the malware, they stubbornly refused to stop or delete the executables involved.

Got any IR war stories to tell?  Please, use our comment form, let's talk!

===============
Rob VandenBrink
Coherent Security

Rob VandenBrink

515 Posts
ISC Handler
Saw an awesome talk at ShmooCon Epilogue a few years back about target using saltstack for IR on client systems. A few months after saltstack was all setup trickbot showed me how vulnerable these systems were. Used a GPO to disable SMB client to client communications, which stopped the spread within a couple hours. Then saltstack to tag and quarantine systems with IoC. It was rad.
Anonymous
I can't share war stories but I have questions instead. The idea of using powershell on windows clients for IR is quite interesting, because it would not require any 3rd party software to install.

Short description of the environment I work in:
- Healthcare industry
- about 15.000 - 20.000 applicable clients
- 27 Domains (single forest)

That being said I would like to profit from your experience with powershell based IR tools and ask the following questions:
- How big (number of applicable clients) are those domains of yours?
- Why do you use PS-Session over PSExec?
- What do you think about deploying those scripts via GPO on the clients and let them report back the results?

I ask these question, because I have about 20.000 applicable clients in 27 different Domains (same forest). I can imagine, that it would take a while to runs such scripts.
Currently we use PSExec for deploying a collection tool, which supports us on on-demand investigations.
Anonymous
How did you do the GPO disable of SMB client to client communications?
Rod

6 Posts
I used PS-Session because some of the commands that I'm building on don't have an option to run remotely (the UDP enum stuff in particular).
You could certainly use other methods to gather this info - "pushing" scripts to the remote endpoint is one such method. However, I tend to approach these things like I'm in a consulting situation - in this case, the client is "on fire" with malware, possibly the DC's are infected, and you need to gather results ASAP to take action on.
In a "steady state, all is well" situation there are tons of options - but when everything is broken, the first thing that works is usually what you go with :-)
Rob VandenBrink

515 Posts
ISC Handler
I usually try to limit lateral movement by using LAPS isc.sans.edu/forums/diary/Microsoft+LAPS+Blue+Team+Red+Team/24528/
Limiting it via SMB is an interesting idea - pushing firewall rules out would be my first approach, restricting the 3 "culprit" ports between known workstation subnets. Or better yet, only permitting inbound SMB to workstations from known and trusted admin stations. Anyway, neat idea, look for a story on this soon!
Rob VandenBrink

515 Posts
ISC Handler

Sign Up for Free or Log In to start participating in the conversation!