Guide | How To How do you secure PowerShell?

The associated guide may contain user-generated or external content.

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
@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.
 
Last edited:
5

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

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,153
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_

Level 53
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Aug 2, 2015
4,286
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

Level 25
Verified
Honorary Member
Top Poster
Malware Hunter
Well-known
Jan 9, 2013
1,457
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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
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) .
 
Last edited:

shmu26

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,153
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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
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).
 

Attachments

  • Helloworld.txt
    570 bytes · Views: 618
Last edited:

shmu26

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,153
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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
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

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,153
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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
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.
 
Last edited:

shmu26

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,153
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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
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.:D
But, one thing should be checked - memory exploit, that can use directly System.Management.Automation.dll to run PowerShell.
 
Last edited:

shmu26

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,153
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.:D
But, one thing should be checked - memory exploit, that can use directly System.Management.Automation.dll to run PowerShell.
Thanks!
 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
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.
 
Last edited:

shmu26

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,153
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

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,226
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.:)
 

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top