Guide | How To How do you secure PowerShell?

[Andy Ful]

@Andy Ful
Check this post by Voodooshield developer:

VoodooShield ?

Thanks. I would like to contact with VoodooShield developer, but I am not Wilderssecurity member.
But, everyone can contact with me by mail:
Hard_Configurator@o2.pl

As @VoodooShield mentioned (VoodooShield ?), the powershell bypass can be serious, when software/system is exploited, and powershell.exe can be copied/renamed. Another problem can arise when powersh.exe is used in the phishing attack with dropped script and shortcut containing the command. I think, that it is not a serious problem (for home users) when VoodooShield is active.
Yet, the Windows Script Host vulnerability is serious, and should be corrected.

 

[Andy Ful]

I was invited by @VoodooShield to contact with him by his Web Page, so I did.

 

[509322]

Looking at the poll results, I am a little surprised, that simple and effective '__PSLockDownPolicy', is so uncommon in users' setups. It is a good security supplement to the popular blocking of powershell.exe and powershell_ise.exe . It can be easily adopted in Windows 7 : Install and configure WMF 5.1 , and it is trivial, when using Windows 8+ (Reg-tweak, PowerShell 3.0+ built-in the system).

Home users don't know about it because it is documented (and very poorly documented at that) in places on the web that even security paranoid types do not visit.

Besides, articles have been linked here and it seems no one bothers to read them.

Another thing is that even a lot of security paranoid users do not fully comprehend that default PowerShell is a needless security risk. Personally, I consider it a menace for typical home users.

 

[shmu26]

Powershell is not a signed process. So if you change the name of the file, it will be blocked by NVT ERP, because it will be seen as an unknown file, assuming the hash is different. If the hash is the same, it will produce a vulnerable process prompt, as mentioned earlier in this thread.

Comodo will see it as an unknown file, if either the name or path is changed.

 

[_CyberGhosT_]

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.

We weren't discussing vunerable variants, we were discussing "Powershell".
I have contingencies for variants, but I chose to stay on topic

 

[WinXPert]

My settings are to block powershell using Protection | Application Rules in EAM. Clicking .PS1 file opens it it notepad. But I have no protection when powershell is renamed.

Thanks for the info, learned something new here again.

 

[Andy Ful]

Powershell is not a signed process. So if you change the name of the file, it will be blocked by NVT ERP, because it will be seen as an unknown file, assuming the hash is different. If the hash is the same, it will produce a vulnerable process prompt, as mentioned earlier in this thread.

Comodo will see it as an unknown file, if either the name or path is changed.

Thanks @shmu26. I wrote :
Process Lasso, Sandboxie, NVT ExeRadar Pro, etc. can monitor executables: powershell.exe and powershell_ise.exe. (...) But mostly, they cannot stop custom made executable with an unknown name.

That was unfair to NVT ERP (that I like very much). In fact, any anti-exe can stop custom made executable with an unknown name (if not whitelisted), but NVT ERP additionally can stop vulnerable system executables.
Sandboxie can force powershell.exe and powershell_ise.exe to run sandboxed (paid version). Generally, it cannot stop custom made powershell host, but if the parent process is sandboxed, then the child fake powershell executable is also sandboxed. So, the strength of Sandboxie protection depends, if one runs potentially vulnerable applications in the sandbox or not.

Edited!
The real problem for anti-exe solutions, arise with memory exploits, when they can run PowerShell from System.Management.Automation.dll (System.Management.Automation.ni.dll) .

 

[shmu26]

Thanks @shmu26. I wrote :
Process Lasso, Sandboxie, NVT ExeRadar Pro, etc. can monitor executables: powershell.exe and powershell_ise.exe. (...) But mostly, they cannot stop custom made executable with an unknown name.

That was unfair to NVT ERP (that I like very much). In fact, any anti-exe can stop custom made executable with an unknown name (if not whitelisted), but NVT ERP additionally can stop vulnerable system executables.
Sandboxie can force powershell.exe and powershell_ise.exe to run sandboxed (paid version). Generally, it cannot stop custom made powershell host, but if the parent process is sandboxed, then the child fake powershell executable is also sandboxed. So, the strength of Sandboxie protection depends, if one runs potentially vulnerable applications in the sandbox or not.

The problems arise with memory exploits, when they that can run PowerShell from System.Management.Automation.dll .

Thanks.

Comodo 10 has an interesting new way of handling powershell (and many other script interpreters), they call it "embedded code detection" .
I like the idea, but I don't know if its effectiveness has actually been tested. If anyone has anything to say about it, I would like to hear.

 

[Andy Ful]

Thanks.

Comodo 10 has an interesting new way of handling powershell (and many other script interpreters), they call it "embedded code detection" .
I like the idea, but I don't know if its effectiveness has actually been tested. If anyone has anything to say about it, I would like to hear.

Maybe I'm doing something wrong, but it seems that :

powershell.exe "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & 'C:\z\Helloworld.ps1'"

run sandboxed in CF, but not the command with fake executable:

C:\z\powershe.exe "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & 'C:\z\Helloworld.ps1'"

Both executables are marked by CF as Unrecognized. I uploaded 'Helloworld.ps1' (see below, the TXT extension must be changed to ps1), maybe someone can test it.
The file 'powershe.exe' is from Windows 10 Anniversary edition, and 'powershell.exe' is from Creators Update edition. If I copy 'powershell.exe' and rename it, CF runs it in the sandbox.
So, the problem is with the old version of powershell host (powershe.exe).

 

[shmu26]

Let me make sure I understood your results correctly.
when you ran powershell.exe, the command line was sandboxed.
when you ran powershe.exe, it was sandboxed, but the command line was not sandboxed.

 

[Andy Ful]

Let me make sure I understood your results correctly.
when you ran powershell.exe, the command line was sandboxed.
when you ran powershe.exe, it was sandboxed, but the command line was not sandboxed.

I can put it even more simple (the command line is not needed, paths do not matter).
When I ran from Explorer powershell.exe it is sandboxed (Creators Update).
When I ran from Explorer powershe.exe it is not sandboxed (Anniversary Update).
Both executables are marked as Unrecognized. It make no sense for me, so maybe I am doing something wrong.

 

[shmu26]

Sorry I am so thickheaded, but which one of these did you do?

1 click on powershe.exe, and it was not sandboxed, even though it is on the unknown file list.

2 set the ps1 file type to open with powershe.exe, and then click on Helloworld.ps1, and powershe.exe was not sandboxed, even though it is on the unknown file list.

3 none of the above

Another question: do you have CFW in proactive mode, or did you leave it at default settings, which is Firewall mode?

 

[Andy Ful]

Forget about scripts. Just run two executables. Both are marked as Unrecognized. One is sandboxed (powershell.exe from Creators Update), but the other not (powershe.exe = powershell.exe from Anniversary Update with changed name).

Edit.
I set CF to Firewall Security (default).

Edit2
I removed both files from CF File list. Renamed both files to a.exe and b.exe, and run them.
The same result.

 

[shmu26]

Forget about scripts. Just run two executables. Both are marked as Unrecognized. One is sandboxed (powershell.exe from Creators Update), but the other not (powershe.exe = powershell.exe from Anniversary Update with changed name).

Edit.
I set CF to Firewall Security (default).

Okay, after reading your edit, I think I know the answer. Firewall Security mode has autosandbox (now called "containment") disabled by default. It only uses HIPS.

So if you enable "containment", or if you switch to Proactive mode, you should see different results.

EDIT: If you remain in firewall mode, and you enable containment, by default it will not sandbox the files that are more than three days old. It only sandboxes new files.

 

[Andy Ful]

Okay, after reading your edit, I think I know the answer. Firewall Security mode has autosandbox (now called "containment") disabled by default. It only uses HIPS.

So if you enable "containment", or if you switch to Proactive mode, you should see different results.

EDIT: If you remain in firewall mode, and you enable containment, by default it will not sandbox the files that are more than three days old. It only sandboxes new files.

Thanks, I will test it, later. (dinner time).

 

[Andy Ful]

Thanks. Problem solved. As you found out, the strange behavior had its source in CF Sandbox, file time settings.
In my case it was 60 days, and both files had file dates (visible in Explorer) less than 60 days old. But, CF takes into consideration file creation date, that in my case was different from the file date visible in Windows Explorer (modification date).

So, I could finally test my PowerShell scripts/commands. All sandboxed.
But, one thing should be checked - memory exploit, that can use directly System.Management.Automation.dll to run PowerShell.

 

[shmu26]

Thanks. Problem solved. As you found out, the strange behavior had its source in CF Sandbox, file time settings.
In my case it was 60 days, and both files had file dates (visible in Explorer) less than 60 days old. But, CF takes into consideration file creation date, that in my case was different from the file date visible in Windows Explorer (modification date).

So, I could finally test my PowerShell scripts/commands. All blocked.
But, one thing should be checked - memory exploit, that can use directly System.Management.Automation.dll to run PowerShell.

Thanks!

 

[Andy Ful]

Summing up the PowerShell security in Comodo Firewall, we have:

1. Comodo Sandbox with @cruelsister settings, when keeping powershell.exe and powershell_ise.exe as Unrecognized.
2. "Heuristic Command Line Analysis" and "Embedded Code Detection", integrated under one interface as "Do Heurristic Command Line Analysis".

The 'Embeded Code Detection' catches fileless scripts, converts them into files in the: C:\ProgramData\Comodo\Cis\tempscrpt
folder, and finally throws into the sandbox. This fucntion + heuristics has to be quite efficient in script blocking. People on Comodo forum complain, that their scripts (Visual Studio project assemblies) are autosandboxed, when "Do Heurristic Command Line Analysis" is activated. If one wants to run embedded scripts, he can activate the HIPS, and give the script hosting executable, the Installer/Updater policy.

So, for home users, CF offers very good PowerShell security.

 

[shmu26]

Summing up the PowerShell security in Comodo Firewall, we have:

1. Comodo Sandbox with @cruelsister settings, when keeping powershell.exe and powershell_ise.exe as Unrecognized.
2. "Heuristic Command Line Analysis" and "Embedded Code Detection", integrated under one interface as "Do Heurristic Command Line Analysis".

The 'Embeded Code Detection' catches fileless scripts, converts them into files in the: C:\ProgramData\Comodo\Cis\tempscrpt
folder, and finally throws into the sandbox. This fucntion + heuristics has to be quite efficient in script blocking. People who use scripts, complain on Comodo forum, that their scripts (Visual Studio project assemblies) are autosandboxed, when "Do Heurristic Command Line Analysis" is activated. If one wants to run embedded scripts,
he can activate the HIPS and give the script hosting executable the Installer/Updater policy.

So, for home users, CF offers very good PowerShell security.

Thanks for report!

 

[Andy Ful]

what if you uninstall powershell?

In one of my previous posts, I wrote that one cannot uninstall PowerShell, and that in Windows XP and Vista, PoweShell is not built-in the system, so may be not installed (if not needed). I think, that this may be somewhat confusing, and not quite satisfactory answer.
PowerShell in Windows 7+ is built-in the system so cannot be uninstalled. Yet, in Windows XP + SP2 and Windows Vista it can be installed via updates.

I found some more detailed info about how to uninstall Windows PowerShell 1.0 in Windows XP + SP3 here:
https://support.microsoft.com/en-us...es-for-windows-server-2003-and-for-windows-xp

"Windows PowerShell 1.0 is packaged as a Windows update. If you install a Windows service pack as an upgrade after you install Windows PowerShell 1.0, you cannot uninstall Windows PowerShell 1.0. The service pack upgrade installer removes the uninstallation programs for all Windows updates. This includes the Windows update that installs Windows PowerShell 1.0.
If you install a service pack as an update from Microsoft Update or from Windows Update, the service pack update does not remove the Windows PowerShell 1.0 uninstaller. Only an upgrade removes the uninstaller.
If you have installed a service pack as an update, you can uninstall Windows PowerShell 1.0. However, you should uninstall the service pack update before you uninstall Windows PowerShell 1.0. Uninstalling the Windows PowerShell 1.0 update after you apply a service pack update is considered uninstalling in the wrong order. This might jeopardize the operating system. Updates should only be uninstalled in the reverse order in which they were installed."

So generally, there are problems with uninstalling PowerShell 1.0 on computers with XP and Service Pack 3.

To install Windows Powershell 2.0 on an XP machine, you must have also SP3. Powershell is included in the:
Windows Management Framework, which you can download at: support.microsoft.com/kb/968929
Windows Management Framework Core, which you can download at: support.microsoft.com/kb/968930
Those updates (and PowerShell 2.0) can be uninstalled via Control Panel > Programs and Features > Installed Updates

Deinstallation of PowerShell in Windows Vista:
PowerShell 1.0 --> uninstall KB928439
PowerShell 2.0 ---> uninstall Windows Management Framework Core (KB968930)
PowerShell 2.0 --> Windows Features > Windows PowerShell 2.0 (untick)

I hope this will help.