Is Securing PowerShell a Lost Cause?
Part 2 of a 3 Part Series
Check out Part 1 of this series here.
Before I begin, I have to thank Helen for the cool new email banner. Ransomware is such a serious topic that it is nice to be able to inject some fun into it when we can.
Speaking of serious topics: PowerShell and Ransomware. We know that initial access brokers and ransomware operators love to use PowerShell during their attacks, so how can organizations better secure it?
Alternatively, should organizations try to secure it or just remove it all together? In their guidance on securing PowerShell both Microsoft and the NSA/CISA/GCSB/GCHQ [PDF] all suggest that removing PowerShell is the wrong answer. It is better to secure it than to remove entirely, especially because so many security and incident response tools rely on PowerShell.
I don’t disagree with this guidance, but I do think it is a bit out of date. For example, in the Microsoft recommendation for client systems they state:
Client systems. After initial infection (by a macro-enabled document or user double-clicking a malicious executable), malware sometimes uses PowerShell as one component of its attack chain. Microsoft’s recommendation is not to block PowerShell completely, as PowerShell is required for many operating system and system management tasks. Microsoft’s recommendation is to limit PowerShell to authorized users and administrators to mitigate the use by commodity malware, as described by point #4 above (“Deploy Device Guard / Application Control Policies”). If Windows Defender Application Control is not an option, security products that block PowerShell from unknown parent processes (such as Word, Excel) are a reasonable middle ground.
Here is my problem with this advice, “…limit PowerShell to authorized users and administrators…” In theory, this works, but we know that in every ransomware attack the attack attempts to gain administrative access, which means that they will easily be able to bypass whatever restrictions are in place. You could make the argument that it is harder to gain administrative access if PowerShell is restricted, but tools like Mimikatz don’t require PowerShell to run.
This also means that organizations have to do a better job of managing least privilege across their Active Directory installation, including not giving everyone in the organization local Admin access (PLEASE, PLEASE, PLEASE DO THIS).
I understand the complications involved in removing PowerShell from client systems. But for organizations that can, it might be the easiest solution. I am going to turn on comments for this post, I would love to hear what you think.
Assuming you can’t remove PowerShell from client workstations, then the advice to restrict who can use PowerShell is good advice but, again, it also means you have to have strong identity and access management policies, which too many organizations do not.
Microsoft also recommends enabling Windows Defender Application Control (or its equivalent in other EDRs) and using that to restrict which programs can execute PowerShell. They recommend that only signed applications should be able to execute PowerShell and also to block commonly used phishing vectors, such as Microsoft Word, from executing PowerShell as well. Again, this feels like outdated advice, we’ve seen a number of attacks where cybercriminals used stolen keys to sign their malware, so it looked like a valid application.
The alternative, of course, is to create an “allow list.” Only applications on that list would be able to execute PowerShell scripts, everything else would be blocked by default.
So, now an organization has to not only have excellent IAM policies, but also application management policies as well. Which, honestly, most organizations, especially larges ones, should have in place — but too many do not.
Finally, both Microsoft and the Government(s) Bulletin above recommend enabling PowerShell Logging. I think this is a critical component to good PowerShell security and it is what I am going to focus on for Part 3 of this series. In short, good log analysis can help overcome a lot of the weaknesses associated with the other suggestions for securing PowerShell.
But, effective PowerShell logging requires good asset management. You have to ensure that you know that you are collecting logs from every systems that is running PowerShell. You also have to know what/where that system is when an alert is generated and be able to respond to the alert quickly.
In short, effective PowerShell security requires good:
Identity and Access Management
Application Control
Asset Management
Vulnerability Management (you have to keep PowerShell itself patched.
So, essentially, good PowerShell security requires all of the usual good security practice recommendations — go figure.