Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: InfoSec Handlers Diary Blog - Using Powershell in Basic Incident Response - A Domain Wide "Kill-Switch" InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Using Powershell in Basic Incident Response - A Domain Wide "Kill-Switch"

Published: 2019-07-02
Last Updated: 2019-07-02 12:59:24 UTC
by Rob VandenBrink (Version: 1)
5 comment(s)

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

Keywords:
5 comment(s)
Diary Archives