Avenging PowerShell to Stop Ransomware
Part 3 of a 3 Part Series
You can check out Part 1 and Part 2 of the series here.
Because if we can't protect the Earth, you can be damned well sure we'll avenge it.
— Tony Stark, Avengers
In an ideal world all cyberattacks would be stopped at the point of attempted intrusion and all the safeguards discussed in Part 2 of this series (and other places) would prevent ransomware groups from ever using PowerShell in the network. Unfortunately, in security none of us get to live in an ideal world.
This means we are often chasing alerts after IABs or ransomware groups have managed to gain access. In this case, the goal is to limit the damage they can cause, find them in the network and stop them before they can steal data, encrypt files, jump to other networks and more.
Given the pervasiveness of PowerShell in ransomware attacks, hunting for signs of PowerShell can provide those breadcrumbs to root out malicious actors and stop them before they cause damage to your organization. But, how do you do that?
As with most things in security, it starts with building a baseline. If you understand what PowerShel traffic within your organization is supposed to look like, then it is easier to spot the anomalies and stop them (unless, as has happened more than a few times, there are already threat actors in your network while you are building the baseline).
Most organizations build their baseline by collecting and analyzing PowerShell logs, but it also helps to talk to the teams that are using PowerShell to find out why and how they use it. I’ve been in many networks where building the baseline uncovers PowerShell scripts that were running for years that no one knows who initiated them or why. These discussions can also lead to more efficient and secure uses of PowerShell internally and they absolutely improve communication so teams know to inform the security team when they run a new script or change existing scripts.
Once you have built your baseline, you want to find a way to understand how adversaries are using PowerShell. Understanding their behavior helps build detections.
So, for example this excellent report from Unit 42 shows Vice Society using ExecutionPolicy Bypass command:
powershell.exe -ExecutionPolicy Bypass -file \\[redacted_ip]\s$\w1.ps1
It turns out that the ExecutionPolicy Bypass command is commonly used by a number of ransomware groups.
Another great example of how IABs and ransomware groups use PowerShell is to disable your security tools is in this report from Kroll:
C:\Windows\system32\windowspowershell\v1.0\powershell.exe -Command Set-MpPreference -DisableRealtimeMonitoring $true
Your organization is most likely not using either of these commands (at least I hope not) so hunting for examples of them in PowerShell logs can find malicious ransomware activity early.
Some ransomware groups try to mask their activity by encoding their PowerShell commands by encoding the commands, as pointed out by RedCanary:
powershell.exe -encod VwByAGkAdABlAC0ASABvAHMAdAAgACIAdAB3AGUAZQB0ACwAIAB0AHcAZQBlAHQAIQAiAA==
Their linked report includes methods for detecting the use of encoding in scripts.
These are three quick and relatively easy things you can look for in PowerShell logs that are usually signs of malicious activity. But, because you have built a baseline of PowerShell activity in your network, you can also start looking for anomalous traffic.
For example:
Scripts running at odd times
Scripts executed by a new network admin (side note: ANY time a new admin account is created should automatically draw an alert).
Scripts running on or from machines that don’t normally run PowerShell scripts
Scripts engaging in unusual (or possibly any) network probing.
Each organization is different and differs in how they use PowerShell. But if you have that baseline, and continuously update the baseline it is easier (not easy, easier) to find the oddities, flag them and stop a ransomware attack before it can do damage.