January 1, 2012 at 12:00 am #5987
by MattG at 2012-12-23 08:11:36
While reverse engineering the Windows RT implementation of PowerShell on the Surface tablet, I discovered a handy environment variable setting that could make securing local PowerShell clients extremely simple.
If you create the environment variable "__PSLockdownPolicy" and set it to "4", you will force PowerShell to start it's default runspace in "Constrained" language mode. For those of you who have experience using PowerShell on the Surface tablet then you already know the limitations imposed on you by "Constrained" mode. In fact, so far, none of the malicious tools that I've contributed to the PowerSploit project work while PowerShell is running in "Constrained" language mode.
Pushing down this environment variable to all the workstations in a domain via GPO would be an easy win in the effort of preventing the execution of malicious PowerShell scripts.
Update: Oisin Grehan @oising was apparently the first to discover this. He tweeted about this on October 26. 😀
by MattG at 2012-12-23 09:24:26
It should go without saying though that this technique is rendered ineffective if the user is able to modify the environment variable upon launching PowerShell. That being said, you've already got issues on your workstations if users can modify system environment variables. 😀
As an example, if I were given permission to execute wbemtest, I could start PowerShell with environment variables that I control.
I digress. My point is, don't blindly trust this technique to protect users.
by cookie.monster at 2012-12-30 11:23:10
I have to ask – why are you attempting to prevent scripts from running? It would seem that if you get to a point where a malicious script is executing, you have already been compromised.
I suppose it might be a decent addition to a layered approach, but I'm not sure if it would be worth the effort of ensuring it is only applied to computers that should have no reason to execute PowerShell scripts...
by MattG at 2012-12-30 11:55:19
For clarification, this would not prevent scripts from running. Constrained language mode primarily restricts direct access to .NET types/objects/methods. The overwhelming majority of cmdlets still work in this mode.
I think the ideal use case for this would be to lock down PowerShell on the local machine so that users cannot run dangerous scripts. This setting would not prevent administrators from using PowerShell remoting, however. Their access would be defined by the PSSessionConfiguration used when connecting remotely, not by the "__PSLockdownPolicy" environment variable.
You're right though. This is clearly part of a layered defense. I think every organization needs to run their security under the assumption that they are already compromised because in most cases, they already are.
You must be logged in to reply to this topic.