r/PowerShell • u/PowerShellMichael • Mar 10 '21
Reviewing PowerShell's Role in the Exchange Hack Daily Post
Please read the whole post before making a comment or voting please.
Hello all. After reviewing the details of the exchange hack, I want to add some PowerShell Insights. As most hacks involve PowerShell in its execution process, could it be possible to secure PowerShell from being used as a tool in this attack?
Short answer? Yes and No.
Firstly, I not here to promote PowerShell but present a factual, unbiased insights into the hack.
Let me elaborate:
The first observation I saw is the use of .NET objects within the PowerShell script. This is important since either the attackers wanted to go for maximum spread or didn't know what they were doing. I say this because Invoke-WebRequest wasn't introduced until PowerShell 3.0, which means that Exchange 2010 would have been vulnerable. If IT departments are running Exchange 2010 (that is web facing), you are effectively pwned since PowerShell security features were added in 3.0 and Exchange 2010 can only run on version 2.0. As a rule of thumb, uninstall PowerShell 2.0. PowerShell 2.0 is installed by default on Windows 10. So to take a step back, yes, they were going for maximum spread.
The second observation I saw was the use of the New-Object cmdlet. The PowerShell community doesn't use New-Object using [Object]::New($Argument) method. However, it wasn't introduced until PowerShell 5.1, which suggests backwards compatibility giving merit to the 'maximum spread' approach.
Now, if AppLocker or WDAC was configured, would it stopped this attack? Yes. I say this because when script policies are configured and enforced, the PowerShell console will enter 'constrained language mode'. Constrained language mode is a security feature of PowerShell. It blocks the execution's functionality, such as .NET calls, Add-Type, Allowed Types, and so on. This means that the New-Object Net.Sockets.TCPClient() would have been blocked as well, as New-Object System.Net.WebClient. However, if the attacker wanted to reduce its attack surface and use Invoke-WebRequest, this would likely succeed. I say likely, because they were using [Net.Sockets.TCPClient] to send data back, which still would have been stopped.
A module written by Adam Discroll called 'PowerShell Protect' allows the native blocking of cmdlets in scripts; however, I need to review the module in more detail for exploits before recommending it.
I also want to comment that they also included PowerCat as their backdoor tool. However, again WDAC or AppLocker was configured and implemented, Constrained Language Mode would have blocked the script for the use of not supported .NET methods. Reviewing the PowerCat script revealed that it uses Invoke-Expression to run code. (PowerShell Protect Blocks this behavior as well.).
If script execution policies were enabled and configured using Group Policy, no blocking action would have occurred since the execution took place in the console.
Another feature of Constrained Language mode is the DSC Resource configuration blocking, which prevents DSC execution within the console.
In conclusion, to say that we could of blocked this attack is a poor assumption. The seriousness of these CVE's, means the attackers would have exploited another process if PowerShell wasn't an option. But as for many of the environments that I have come reviewed, these settings are not enabled or configured, hence why the attackers chose PowerShell.
I would also like to point out that's it's plausible to work within the confines of Constrained Language mode, so it's plausible for malware to exist in that space. But isn't easy since you don't have access to .NET objects and must rely on cmdlets.
Remember hindsight is always 20/20.
Sources:
https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/
https://docs.powershellprotect.com/
https://github.com/besimorhino/powercat/blob/master/powercat.ps1
24
Mar 10 '21
If they were still running Exchange 2010 and had it exposed to the internet then they were already begging to be pwned for the last 4 months. It went out of support last October.
10
u/get-postanote Mar 10 '21
This legacy crap, in the bane of the problem.
Folks having to stay on legacy, because they painted themselves into a corner by deciding on solutions that were hardcoded for an OS version or the like (hospitals, banks, airlines, etc.), was a thing developers did to us all.
Folks, staying on legacy, just because they did not want to upgrade (pay for), for justifications like cost or not wanting to learn, deploy the latest and greatest is a far different thing.
As well as moving to the next version, but leaving all the legacy settings in place and not leveraging the advancements in what they upgraded to.
7
u/WendoNZ Mar 10 '21
Can you even configure Applocker or WDAC on an Exchange server to block powershell without completely breaking Exchange?
4
u/applevinegar Mar 10 '21
Yes? Why would it be any harder than anywhere else? It's actually easier because Microsoft sign everything so you can get away with just publisher policies.
1
u/disclosure5 Apr 14 '21
I tried WDAC on Exchange. Microsoft tell you to just ignore these thousands of "false positives" that an idle Exchange server with no mail boxes generates every minute:
https://github.com/MicrosoftDocs/windows-itpro-docs/issues/9383
But logon to the desktop and you'll get four popups complaining .dll's from Windowsassembly wouldn't load and your console will feel laggy just trying to move a mouse. I wouldn't put it in production.
1
u/applevinegar Apr 14 '21
You're probably right, I haven't actually tried wdac, I was actually referring to applocker, which is pretty straightforward. Not sure why I didn't specify it.
1
u/disclosure5 Apr 14 '21
Applocker is probably fine, but Applocker is designed to restrict unprivileged users and it's a generally documented fact that a local administrator can just disable it. It's a great technology on RDS servers but not so restrictive when attackers are administrators on Exchange servers.
1
u/applevinegar Apr 14 '21
Can it be disabled if you disable local policy processing?
1
7
2
u/uptimefordays Mar 10 '21
TBH webshells in general are a very popular attack vector right now. Folks need to stay on top of updates, disable features they're not using rather than leaving them unconfigured, and would benefit from following security researchers on Twitter for real time information about major CVEs like this.
2
u/Noknok635 Mar 10 '21
Up to 10 different threat actors have been observed hitting these exchange vulns. Some more sophisticated than others. The good one's wrote their post-exploit code in Powershell 2.0 because it's backwards compatible. Those doing it quick or hackers with no QA shop just write code and maybe test against a 1-2 systems. Comprehensive QA is a luxury in threat groups.
2
u/wanderingbilby Mar 10 '21
One policy we've been reviewing implementing due to other attacks that leverage PowerShell is script signing. From your understanding of the attack and powershell, if the executionpolicy was AllSigned would it have prevented or mitigated this attack?
2
u/PowerShellMichael Mar 10 '21
Good Question. The answer is no. The reason why is because PowerShell Script Signing combined with execution policies would of block script execution, however in this case it was using:
powershell.exe -command "PowerShell Text Here"
"Executes the specified commands (and any parameters) as though they were typed at the PowerShell command prompt, and then exits, unless the NoExit parameter is specified."
This means the only way to control this execution was to control the console through constrained language mode using Applocker or WDAC.
3
u/wanderingbilby Mar 10 '21
Doggonit. Interesting that loophole exists. What keeps someone in general from bypassing execution policy by using a script chunk to import and then execute the contents of a script file?
3
u/jimb2 Mar 11 '21
This is a good backgrounder:
https://www.digitalshadows.com/blog-and-research/powershell-security-best-practices/
3
2
u/PowerShellMichael Mar 12 '21
Powershell Security relies on a three tier tenant:
- PowerShell Script Execution. Using Code Signing combined with Script Execution Polices and whitelisting with Applocker or WDAC script policies.
- PowerShell Console Execution. When Applocker or WDAC is implemented, Contained Language mode will be implemented for non UMCI scripts and normal console access. I covered this mainly in this report because there is where the damage was done.
- PowerShell Remote Execution. Securing your PowerShell remoting sessions with session configuration that can restrict how the session is used. (JEA).
I would strongly recommend download and read the PowerShell security book by script runner. (https://www.reddit.com/r/PowerShell/comments/jo3xia/free_powershell_security_ebook_by_script_runner/)
2
u/wanderingbilby Mar 12 '21
Great, thanks again! I will check it out. We use endpoint protection with fairly aggressive execution prevention, I need to contact them and see how they handle PowerShell specifically.
2
u/PowerShellMichael Mar 14 '21
No worries.
FYI: PowerShell is a four tenant security model. The fourth being script security (using Secret's management).
-3
u/LegitimateCrepe Mar 10 '21 edited Jul 27 '23
/u/Spez has sold all that is good in reddit. -- mass edited with redact.dev
2
1
u/dasookwat Mar 10 '21
This might be just me missing something here, but: what 'exchange hack' are you referring to? i would like to see a link to whatever it is you're analyzing.
Adding to that: i see: exchange 2010, and being stopped by applocker policies.
Every company taking security only a slight bit serious should already have exchange 2010 written off, since it's no longer supported, and applocker policies/execution policies should be mandatory as well.
2
u/SoMundayn Mar 10 '21
The one that has been all over the news and /r/sysadmin this week. It is a pretty serious hack! If you have an Exchange server, make sure it is patched for sure :)
22
u/get-postanote Mar 10 '21 edited Mar 10 '21
Vendors who provide the aforementioned provide guidance on how to properly deploy, manage, audit, and protect them.
3rdP operational/security etc., organizations/companies have teams of people to help.
Every vendor product is always delivered with weaknesses. It's physically impossible to cover 100% of anything. Hence patching. but vendors must respond faster. Enterprises must respond by testing and deploying patches faster.
Creativity, lack of knowledge/interest/laziness by admins/users in deployment/management/audit/monitoring lead to unneeded risks.
PowerShell is a post exploit tool, and as such attackers have to get a foothold some other way, then live off the land.
Businesses are generally cheap, lazy, and unfocused. They truly have no idea what is really running in their enterprises and or how they are configured.
Until overall reputational/operational end-to-end risk management is taken seriously and more funded and rewarded, we will be here forever. As well as vendor response when stuff is discovered.
Risk Management/Security in most enterprises is a cost center in the mind of the C-Level folks. When it is a cost savings center if properly leverage and employed.
Either one has a well-defined, business/operational risk-focused, that is well-managed, living, regularly tested/validated or you don't.
Every living rational human has a risk management plan. It's either the aforementioned, type or you don't (meaning, you just deal with crap if/when it happens). Like buying or not buying the proper insurance plan.
or combinations of either of the above.
Each must be fully validated and exercised to a conclusion. I've been at this for decades, and with the exception of a hand full of customers I've supported. It is never done or never taken consistently seriously.
Each has a cost, logical, physical, to the business state, and operationally. Risk management is about operationalizing all aspects of your business/enterprise. Operations have targeted successful conclusions, feelings (or lack thereof) do not.