This post is inspired by a twitter debate I observed between a pentester and a defender. It’s characteristic of several such debates I’ve seen on this topic.
The debate goes something like this:
- Defender: “Blocking powershell.exe is good”
- Pentester: “Nah. I can get around a PS block. Plus my attacks evade AV, so…”.
- Defender: “So? Just because *you* can get around it, doesn’t mean it’s not still a good idea.”
- Pentester: “But it’s not a good idea if I can just work around it…”
- Defender: “But even if it blocks one attack, it’s still good”
- Pentester: “<analogy>”
- Defender: “<wittyresponse>”
- Pentester: “You need to read more”
And on and on. Here’s my take on it. I’m a pentester, but was also a defender for many years at a F500. This response will not please everyone. That’s fine, it’s just an opinion. =)
They are both right.
Lemme splain….
Defender’s Perspective
Defenders do not view the world of infosec through the eyes of a determined, skilled attacker. They view the world through the quantity and quality of tickets generated by their SIEM (if they have one). It is true that a determined, skilled attacker (read and understand that) can work around a correctly implemented PowerShell block. One such method is to drop an exe to disk call a dlls. While there are tools to aid an attacker, this process is substantially harder to pull off. As a result, this extra effort is more likely to raise more alarms. Is it possible? Yes. Is it just as easy as landing with a call to powershell.exe? No. This has the effect of forcing the attacker to work harder and be yet more determined to compromise the org.
However, the benefit is still fully realizeable simply by taking a look at PowerShell based malware samples from say John Lambert or Security Doggo. If they use PowerShell, they are generally making a call to powershell.exe. If that is blocked, payload doesn’t fire, the day is saved. There is merit to this argument because the environment is inherently more protected via by the inability to execute code via powershell.exe. Additionally, the vast majority of users have no use for it, with obvious exceptions for orgs that use it in their loginscript, which you can simply whitelist with applocker.
Bottom line: The environment is more secure without powershell.exe than with it. It is not perfect security, but that’s why we have defense in depth. To suggest that it doesn’t work in a pentester’s edge use case is simply throwing the baby out with the bathwater and is not a good excuse for not considering the blocking of powershell.exe as a defensive control.
Pentester’s Perspective
I can work around a block of powershell.exe, therefore there’s no reason to block it. This is blunt way to put it, but generally the crux of the argument. It’s absolutely true that PowerShell code can be run without powershell.exe and this attack is able to be pulled off in most environments (albeit with more work and plumbing in your attack). Additionally, it is well known that Microsoft is basically pushing all apps to use and/or support PowerShell. Server 2016, Nano, etc. are all heavily managed via PowerShell. That’s a great convenience for defenders as well as attackers. Additionally, Microsoft is effectively ditching cmd.exe in favor of powershell.exe in future releases of Windows 10 (yes, I know, cmd.exe will still be available, but the point is undeniable: PowerShell is the future of Windows administration).
Finally, PowerShell v5 (with Windows 10) security enhancements are substantial. From advanced event logging to controls like Device Guard and JEA, along with ConstrainedLanguageMode (available since PSv3), the use of powershell.exe can be configured to make it difficult for attackers to execute their payload, while still allowing use for end users if necessary, plus like I said, we can just work around your block anyways…
Bottom Line: Don’t block powershell.exe. It’s a waste of time because my attacks are so 1337 that I can run PS without PS. Plus, even if you did block it, you’ll have to remove the block eventually for new versions of Windows cuz you’ll cripple yourself.
So What Should I Do?
While both arguments have merit, here is what I tell my clients: If you are running a Win7 shop with PSv2 as your default with little to no hope for upgrading in the future, then configure Applocker or SRP to block powershell.exe for non-administrators (Good instructional article on Applocker). I agree with pentesters that this control can be worked around and is not perfect, but you will block attacks, dangerous attacks, by blocking powershell.exe. Generally these attacks will be executed by Bob the sales bro who ‘Enables all the Content’ in every spreadsheet he opens. Hopefully, Bob is not a system administrator (RIGHT???). If powershell.exe is blocked, you may just save the day.
However, do so with the understanding that this will not work forever and you will have to change tactics before long, especially after you upgrade to a current OS. Also, do so with the understanding that you should still layer this with other controls (e.g. blocking macro-enabled docs from the internet) and not rely on it completely to keep you out of the news.
This is, and always will be, a cat and mouse game. The minute we become stuck in a way of thinking, we are simply fast-tracking our own irrelevance. Shift and move your environment as necessary, not letting the drive for tomorrow’s perfect security get in the way of today’s good security.
@curi0usJack
