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 { $retlist = @() foreach ($proc in Get-Process) { Stop-Process -InputObject $proc $TargetHash = "<our target hash goes here>" foreach ($targethost in $targets) {
|
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
Comments
Anonymous
Jul 3rd 2019
5 years ago
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
Jul 4th 2019
5 years ago
Anonymous
Jul 9th 2019
5 years ago
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 :-)
Anonymous
Jul 9th 2019
5 years ago
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!
Anonymous
Jul 9th 2019
5 years ago