I'm trying to figure out the best ways to harden PowerShell for heavy users like myself, especially for tasks involving PowerCLI or other vendor-specific modules. My department has constrained language mode enabled, but I've been running PowerShell inside WSL which is functional but has its downsides, such as some Windows-specific commands not working and issues with modern authentication. I've come across several potential solutions: 1) Setting up a Jump Host for our entire team with all necessary cmdlets installed, 2) Whitelisting with Windows Defender Application Control or AppLocker, 3) Establishing a private local Jump Host, or 4) Disabling constrained language mode entirely. But these are all just theories for now, and I'm really interested in hearing what approaches others have actually implemented that have proven effective.
7 Answers
Before diving into solutions, it’s important to clarify what you're trying to protect against. Hardening PowerShell can mean different things based on the threats you're addressing.
Don’t forget that PowerShell’s access level is based on what you can do interactively, so ensure you’re hardening the services it interacts with as well!
If you want serious hardening, consider using WDAC and signing your scripts, which allows only signed scripts to run. It’s more complex but can provide robust security. AppLocker is an alternative, but it's not as strict as WDAC.
I personally use Azure Automation with hybrid worker groups. It connects via GitHub for source control and helps manage tasks very effectively. In my setup, I use local PowerShell to connect accounts and run specific tasks.
As a pentester, I'd recommend restricting PowerShell as much as practical. Threat actors often exploit it, so limiting its use can reduce risks significantly.
Have you checked out PowerShell JEA (Just Enough Administration)? It's designed for situations like yours and can help manage interactions securely without giving too much access.
That sounds like a great fit! Have you implemented it yourself or just heard about it?
Keep in mind that signing your scripts usually allows them to run in full language mode. Not sure if that’s a solution for you considering issues like 'install-module' being unavailable.
Good point! It would be great to clarify how signing impacts that functionality.
Totally get that! Sometimes it feels like we're just looking for extra security without a clear target.