Guide How do you secure PowerShell?

Guides - Privacy & Security Tips
97 Replies 46,853 Views
This guide may include member-written or external content. Check the steps before applying them.
shmu26 said:
What might get borked if I apply this "no language" tweak, besides powershell becoming useless?
Click to expand...

Everything that uses PowerShell. :)
It is like running applications in Comodo Sandbox with Untrusted setting (most restrictive).

Edit.
NoLanguage also uses System.Management.Automation;)
 
Last edited:
I found out that information included in 'Group Policy Settings Reference for Windows and Windows Server'
Download Group Policy Settings Reference for Windows and Windows Server from Official Microsoft Download Center
is not quite correct for the 'disabling script execution' reg tweak:

[HKEY_LOCAL_MACHINE \Software\Policies\Microsoft\Windows\PowerShell]
"EnableScripts"=dword:00000000

From the above reference, the reg tweak should work for Windows 7+, but it works for Windows XP(SP3)+ with PowerShell 2.0+. Of course, that is also true for Windows 7+ because starting from Windows 7 all Windows versions have built-in PowerShell 2.0 or higher.

Post edited.
 
Last edited:
I discovered another way to block powershell scripts.
In Creators Update, there is a bug with the rendering of non-Unicode scripts.
So if you change your system locale to a non-Roman character set, such as Hebrew, then powershell can't even get a path. It becomes pitifully useless.
 
shmu26 said:
I discovered another way to block powershell scripts.
In Creators Update, there is a bug with the rendering of non-Unicode scripts.
So if you change your system locale to a non-Roman character set, such as Hebrew, then powershell can't even get a path. It becomes pitifully useless.
Click to expand...
That is how smart people exploit the problem to solve another one.:)

Edit.
Maybe it is not a bug, but the new Microsoft mitigation?:)
 
Last edited:
Andy Ful said:
I think so. It is a long shot, but maybe the problem with your fonts is related to blocking untrusted fonts mitigation? It should not, but who knows?
Click to expand...
Not a long shot, in fact, I also thought like that, at first.
But after a lot of complaining on the microsoft forum, a company rep finally came on the forum and wrote like this:

The issue is a regression in GDI that affects legacy, non-Unicode apps. The bug is understood, and the owning team is working on a fix.
 
I did some tests with fake PowerShell executable known as 'p0wnedShell'. I compiled it including original System.Management.Automation.dll .
Tests were done with active default deny SRP to force ConstrainedLanguage mode. So, I copied original powershel.exe and custom made p0wnedShell.exe into whitelisted folder and run as standard user.
  1. The executable p0wnedShell.exe worked in FullLanguage mode, while powershell.exe worked in ConstrainedLanguage mode.
  2. Both executables respected Registry settings: ExecutionPolicy and EnableScripts.
So, the custom made executable, can bypass Language mode, but probably cannot bypass so easy, EnableScripts registry tweak.
The Language mode solutions require original powershell.exe to work properly.
 
Last edited:
It seems that NoLanguage mode trick with the profile.ps1, works for p0wnedShell too. So, my final conclusion must be corrected:
  1. ConstrainedLanguage mode related to active Default Deny SRP, can be forced only by original PowerShell executables.
  2. PowerShell Language mode is built into the System.Management.Automation.
  3. System.Management.Automation seems to be aware of the Registry settings (ExecutionPolicy, EnableScripts) and the commands included in profile.ps1 .
I checked my p0wnedShell64.exe (64-bit version) on Virustotal (3/61)

Antivirus scan for 7692e08b48d4d58d3160f4f87fec2bd60ee91ff36b8c8b0fd98c1414ab4cff79 at 2017-05-06 07:52:04 UTC - VirusTotal

AhnLab-V3..........................Malware/MSIl.MS16-032.C1616313....20170505
Kaspersky...........................HEUR:Exploit.MSIL.MS16-032.gen.....20170506
ZoneAlarm by Check Point.......HEUR:Exploit.MSIL.MS16-032.gen.....20170506
 
Last edited:
shmu26 said:
If you take ownership of the powershell files, then you can simply delete them or rename them. This should work on any version of Windows. But they might come back after a Windows update.
Click to expand...
Yes, they do, so I run a removal script every day to make sure it stays that way. I use this:

Code: 
takeown /f "%ProgramFiles%\WindowsPowerShell" /a /r /d y
icacls "%ProgramFiles%\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%ProgramFiles%\WindowsPowerShell" /s /q
takeown /f "%ProgramFiles(x86)%\WindowsPowerShell" /a /r /d y
icacls "%ProgramFiles(x86)%\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%ProgramFiles(x86)%\WindowsPowerShell" /s /q
takeown /f "%WinDir%\System32\WindowsPowerShell" /a /r /d y
icacls "%WinDir%\System32\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%WinDir%\System32\WindowsPowerShell" /s /q
takeown /f "%WinDir%\SysWOW64\WindowsPowerShell" /a /r /d y
icacls "%WinDir%\SysWOW64\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%WinDir%\SysWOW64\WindowsPowerShell" /s /q
 
TairikuOkami said:
Yes, they do, so I run a removal script every day to make sure it stays that way. I use this:

Code: 
takeown /f "%ProgramFiles%\WindowsPowerShell" /a /r /d y
icacls "%ProgramFiles%\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%ProgramFiles%\WindowsPowerShell" /s /q
takeown /f "%ProgramFiles(x86)%\WindowsPowerShell" /a /r /d y
icacls "%ProgramFiles(x86)%\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%ProgramFiles(x86)%\WindowsPowerShell" /s /q
takeown /f "%WinDir%\System32\WindowsPowerShell" /a /r /d y
icacls "%WinDir%\System32\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%WinDir%\System32\WindowsPowerShell" /s /q
takeown /f "%WinDir%\SysWOW64\WindowsPowerShell" /a /r /d y
icacls "%WinDir%\SysWOW64\WindowsPowerShell" /inheritance:r /grant:r Administrators:(OI)(CI)F /t /c
rd "%WinDir%\SysWOW64\WindowsPowerShell" /s /q
Click to expand...

The above cure is similar to blocking powershell.exe and powershell_ise.exe .
I am afraid that this does not remove PowerShell from the system, because of several instances of System.Management.Automation.dll outside 'WindowsPowerShell' folders. The PowerShell can still be executed from the memory or by the custom made executable.
 
Lockdown said:
Yes, but *.ps1 files can still execute that can do malicious things.

Yes, PowerShell documentation suxx !
Click to expand...
PowerShell v6.1.0 preview 1 : PowerShell v6.1.0 preview 1 | Richard Siddaway's Blog

Published March 28, 2018
The first preview release of PowerShell v6.1 is available at PowerShell/PowerShell
There are a few breaking changes you should check out.
Most of the changes are minor engine updates and bug fixes.
There are no big new features in this preview release


Richard Siddaway blog: blogs.msmvps.com/RichardSiddaway/: Richard Siddaway's Blog
 
Prorootect said:
PowerShell v6.1.0 preview 1 : PowerShell v6.1.0 preview 1 | Richard Siddaway's Blog

Published March 28, 2018
The first preview release of PowerShell v6.1 is available at PowerShell/PowerShell
There are a few breaking changes you should check out.
Most of the changes are minor engine updates and bug fixes.
There are no big new features in this preview release


Richard Siddaway blog: blogs.msmvps.com/RichardSiddaway/: Richard Siddaway's Blog
Click to expand...

I know all about Richard Siddaway's site.

People should not have to go to Richard's or Don Jones' or Michael F Robbins' websites or anywhere other than Microsoft's official documentation. But anyone who has any experience knows Microsoft's documentation is atrocious.
 

Recently browsing

Members who viewed this thread in the last 5 minutes

You may also like...

Back
Top