Guide | How To How do you secure PowerShell?

[Andy Ful]

I noticed that many users are interested in securing Windows Home from PowerShell attacks. There are a few ways to do it, using GPO, reg tweaks or SRP.

A. Disabling PowerShell script execution by reg tweak (Windows 7+):
[HKEY_LOCAL_MACHINE \Software\Policies\Microsoft\Windows\PowerShell]
"EnableScripts"=dword:00000000
The above reg tweak can stop known PowerShell bypass (paths omitted for simplicity):
powershell.exe "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & 'malware.ps1'"
etc.
The user can still run scripts from PowerShell console, for example (paths omitted for simplicity):
Get-Content helloworld.ps1 | PowerShell.exe -noprofile -

B. Restricting PowerShell by reg tweak to Constrained Language mode (PowerShell v.3.0 or later).
Constrained language mode locks down PowerShell to the core elements (no access to: direct .NET scripting, invocation of Win32 APIs via the Add-Type cmdlet, and interaction with COM objects).
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
"__PSLockDownPolicy"="4"

C. Using Default Deny Software Restriction Policies with Enforcement setting 'All software files' or 'All software files except libraries (such as Dlls)'. Scripts can be run with Administrative Rights when SRP are applied to 'All users except local administrators'.

1. Adding PowerShell extensions to 'Designated File Types' list.
   This can disable script execution when using Windows Explorer or Internet Explorer, by clicking PowerShell script or choosing 'Run with PowerShell' from the right click context menu.
   The script can still be executed when using commands with sponsors (PowerShell.exe, PowerShell_ise.exe):
   powershell.exe "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & 'malware.ps1'"
   etc.
2. Adding Disallowed rule '*.PS1' (or similar rules for other extensions). This can stop all examples of script execution from C.1. - PowerShell console is accessible as standard user. PowerShell still exists in the System.Management.Automation.dll (System.Management.Automation.ni.dll) and can be executed through a memory exploit to run scripts with nonstandard extensions.
3. Applying Disallowed rules to powershell.exe and powershell_ise.exe . This can stop all examples of script execution from C.1. - PowerShell console is not accessible as standard user. PowerShell still exists in the System.Management.Automation.dll (System.Management.Automation.ni.dll) and can be executed through a memory exploit.
4. When SRP Default Security Level: 'Disallowed' or 'Basic User' is applied and the enforcement is set to apply to ‘All users except local administrators’, then PowerShell (as standard user) is set to Constrained Language Mode (in Windows 7+ with installed PowerShell 5+). This can stop many malware scripts and exploit tools. In Windows 7, one should have .NET Framework 4.5.2 installed, and then install WMF 5.1: Install and configure WMF 5.1 . Whitelisted locations in SRP, do not change Constrained Language Mode setting. When PowerShell is run as administrator the Language mode is set to FullLanguage.

.
Post edited to add System.Management.Automation.ni.dll .
There is a way to bypass __PSLockDownPolicy, but this can be prevented when using it with Disabling PowerShell script execution reg tweak.

 

[brod56]

Thanks for the guide.
Voodoshield auto blocks Powershell activity (even from the user!) so no need to tweak the registry for me

 

[Andy Ful]

In Windows XP and Vista, only PowerShell 1 and 2 can be installed.
In Windows 7+, PowerShell 2.0 is the built-in system component, and can be updated to version 5.1.
In Windows 8, PowerShell 3.0 is the built-in system component, and cannot be updated to version 5.0.
In Windows 8.1, PowerShell 4.0 is the built-in system component.
In Windows 10, PowerShell 5.0+ is the built-in system component.
.
Post edited.

 

[Winter Soldier]

Just testing SecureAPlus command-line settings about PowerShell to mitigate fileless malware attacks.

Thanks a lot @Andy Ful for this great informative thread!

 

[askmark]

Thanks for the guide.
Voodoshield auto blocks Powershell activity (even from the user!) so no need to tweak the registry for me

Voodooshield protects all of Windows' vulnerable processes, even those that have yet to be exploited

@Andy Ful
Thanks for the guide. Always handy to know how to do these tweaks manually when you don't have third party software to back you up

 

[Andy Ful]

Thanks for the guide.
Voodoshield auto blocks Powershell activity (even from the user!) so no need to tweak the registry for me

Yes, Voodooshield works quite well with vulnerable powershell.
It blocked even the bypass trick:
powershell.exe "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & 'C:\z\Helloworld.ps1'"

But, it is not ideal - it did not block:
powersh.exe "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & 'C:\z\Helloworld.ps1'"

where 'powersh.exe' is 'powershell.exe' with changed name. I also noticed serious loopholes in Windows Script Host security in Autopilot mode (but this is not the right place to discuss it, and they are not present in other modes).

I can say that VoodooShield script blocking is still better, than in many antivirus programs.
The mentioned loopholes are not common in malware attacks. The Autopilot mode is OK for home users.

 

[codswollip]

VoodooShield !

 

[509322]

But, it is not ideal - it did not block:
powersh.exe "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & 'C:\z\Helloworld.ps1'"

To rename powershell.exe to powersh.exe, did you have to take ownership from Trusted Installer on the version of Windows that used to test ?

 

[HarborFront]

Sorry, found the answer

 

[509322]

1. Block *.ps1 and other script types by default in User Space
2. Run powershell.exe with restricted privileges
3. Scripts will inherit restricted privileges from restricted interpreters - even in System Space
4. Block the loading of *.dlls from User Space
5. Block the launch of *.exe from User Space
6. Disable macros
7. Whitelist only scripts that have been audited
8. If you want to get crazy you can audit scripts, sign them, and play with powershell language modes, and set restrictive policies

PowerShell can be run from a *.dll or *.exe, even if powershell.exe and powershell_ise.exe are disabled.

PowerShell can be launched via macros\scripts.

PowerShell should not be shipped with\enabled by default on Home versions of Windows - that's just my personal opinion.

 

[_CyberGhosT_]

Thanks for the guide.
Voodoshield auto blocks Powershell activity (even from the user!) so no need to tweak the registry for me

Very good, and I take that one step further, just to be sure, here take a peek

That's from my "Disallowed list" from Lasso.
It's blocked from internet access as well, just in case it does start
No registery tweaks here either

 

[Andy Ful]

To rename powershell.exe to powersh.exe, did you have to take ownership from Trusted Installer on the version of Windows that used to test ?

I simply copied the original file to another location and renamed it. The PowerShell sits in the System.Management.Automation.dll , so custom made executable can run PowerShell . Default Deny SRP can stop such custom made executables, but only 'Constrained Language' or 'No Language' mode can stop memory exploits from using System.Management.Automation.dll to run advanced PowerShell scripts.

 

[509322]

I simply copied the original file to another location and renamed it. The PowerShell sits in the System.Management.Automation.dll , so custom made executable can run PowerShell . Default Deny SRP can stop such custom made executables, but only 'Constrained Language' or 'No Language' mode can stop memory exploits from using System.Management.Automation.dll to run advanced PowerShell scripts.

I don't think Constrained language mode is all that restrictive. I wouldn't rely upon it - at least not all by itself.

A lot of people don't understand that a lot of PowerShell shenanigans are post-exploit = no exploit = no worries.

 

[Andy Ful]

Very good, and I take that one step further, just to be sure, here take a peek
View attachment 148148
That's from my "Disallowed list" from Lasso.
It's blocked from internet access as well, just in case it does start
No registery tweaks here either

I am afraid that, this cannot stop the trick:
powersh.exe "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & 'C:\z\Helloworld.ps1'"

Process Lasso, Sandboxie, NVT ExeRadar Pro, etc. can monitor executables: powershell.exe and powershell_ise.exe. NVT ExeRadar Pro can also monitor executable by hash, so it can stop the above trick if powersh.exe has the same hash as powershell.exe. But mostly, they cannot stop custom made executable with an unknown name.

 

[509322]

But mostly, they cannot stop custom made executable with an unknown name.

Malware can copy-paste legitimate files from System to User Space. Plus, malc0der can simply provide a copy of legitimate Windows process with their malware.

That is why it is best to just block everything from User Space that is not explicitly allowed.

 

[Andy Ful]

I don't think Constrained language mode is all that restrictive. I wouldn't rely upon it - at least not all by itself.

A lot of people don't understand that a lot of PowerShell shenanigans are post-exploit = no exploit = no worries.

Constrained language mode locks down PowerShell to the core elements (no access to: direct .NET scripting, invocation of Win32 APIs via the Add-Type cmdlet, and interaction with COM objects). This stops most exploits and exploit kits.
PowerShell Security: PowerShell Attack Tools, Mitigation, & Detection » Active Directory Security

The 'No Language' is the most restrictive, but I do not know how to implement it without WinRM service.

 

[Andy Ful]

Malware can copy-paste legitimate files from System to User Space. Plus, malc0der can simply provide a copy of legitimate Windows process with their malware.

That is why it is best to just block everything from User Space that is not explicitly allowed.

Yes, that is why we both like SRP.

 

[509322]

Constrained language mode locks down PowerShell to the core elements (no access to: direct .NET scripting, invocation of Win32 APIs via the Add-Type cmdlet, and interaction with COM objects). This stops most exploits and exploit kits.
The 'No Language' is the most restrictive, but I do not know how to implement it without WinRM service.

Yes, but *.ps1 files can still execute that can do malicious things.

Yes, PowerShell documentation suxx !

 

[Andy Ful]

The 'Constrained Language' mode is quite effective now, but who knows what will be tomorrow?

 

[tonibalas]

When i open my PowerShell with my standard account ( SUA ) i get this

When i try to open PowerShell modules with my admin password i get this

Can you tell if my PowerShell is secured?