Powershell in Windows Explorer - Block

[petben]

Any ideas how to remove the Powershell shortcuts in Win 10 file Explorer.

 

- Open a folder

- Select any file

- File menu

- 'Open Windows Powershell'

- 'Open as administrator'....... if you like...

 

I already have SRP setup but we cant block powershell.exe due to login scripts being required..

[Oaktech]

Change file permissions to deny...

 

Create the 'do not run the following programs' and specify powershell.exe and powershell_ise.exe policy?

[3s-gtech]

These shortcuts seem to bypass that. I managed to do it by removing them from the menu:

Delete Hive  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.Powershell HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.location.Powershell HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.location.cmd HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.MultiVerb.Powershell

There are other features you can remove too.

Edited June 14, 2018 by 3s-gtech
Somehow all of my formatting is getting stripped out, GRRRRRRR

[Oaktech]

These shortcuts seem to bypass that. I managed to do it by removing them from the menu:

Delete Hive  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.Powershell HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.location.Powershell HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.location.cmd HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\Windows.MultiVerb.Powershell

There are other features you can remove too.

 

It doesn't bypass changing the file permissions unless you run as admin...

[3s-gtech]

No, you're right - if you change the actual permissions on the .exe files that should stop them from running. I was reluctant to do that in case it interfered with scripts on logon etc. These shortcuts do bypass many of the GPOs used to prevent Powershell and CMD from running, which is mighty helpful.

[petben]

Thanks, so what is the conclusion of this?

Deleting those HKLM reg keys seems like a good thing if it actually removes those shortcuts.

Changing permissions will affect logon scripts?

[3s-gtech]

Changing permissions may affect them, if those scripts run as that user. I have logon Powershell and batch logon scripts, so can't do it that way. I have to use a combination of GPOs, Applocker and these registry tweaks as a result. Windows 10 will still let you run Powershell via the Start Menu Search though!

[Oaktech]

Changing permissions may affect them, if those scripts run as that user. I have logon Powershell and batch logon scripts, so can't do it that way. I have to use a combination of GPOs, Applocker and these registry tweaks as a result. Windows 10 will still let you run Powershell via the Start Menu Search though!

 

 

It's not been my experience that changing those permissions affects the ability to run scripts, but I guess that's because all the scripts I have that apply run in an elevated context.

 

Adding the powershell exe to the do not run GPO stops it from running from the start menu search unless you elevate it.

[petben]

is the gpo:

dont run specified windows applications - powershell.exe

 

any different to:

software restriction policy - powershell.exe

 

 

 

 

Thanks

[DJ-1701]

is the gpo:

dont run specified windows applications - powershell.exe

 

any different to:

software restriction policy - powershell.exe

 

 

 

 

Thanks

 

Yes, the former doesn't allow you to run it from the Windows Explorer process.

The later won't let you run it from all other processes, for example cmd.

[Oaktech]

is the gpo:

dont run specified windows applications - powershell.exe

 

any different to:

software restriction policy - powershell.exe

 

 

 

 

Thanks

 

Yes - I find specifying it in the SRP breaks a whole bunch of stuff but specifying it in the 'do not run' section has no noticeable effect other than it can no longer be invoked manually by the user the GPO applies to.

[petben]

I have tested this and with the setting - don't run specified windows applications - powershell.exe

 

logon scripts specified in the user GPO do not run....

 

shame

[free780]

Anybody tried applocker? Probably the same result. I supposed you could not block powershell.exe and powershell_ise.exe but sign all your scripts and lock down the execution policy to signed scripts. Not ideal but better than the current situation.

[free780]

This is an interesting approach.

https://www.scip.ch/en/?labs.20150507

 

I guess the real question is not blocking powershell but if a user can do get-childitem HKLM: | out-file c:\users%username%\onedrive - %org%\regdump.txt then he same is possible in vbscript. The real question is locking down what the user can do not how they do it.

[HPlum78]

I don't know what OS you are talking about or indeed what version of PS either but instead of hobbling PowerShell in a manner that is unsupported you could try the New-PSRoleCapabilityFile:-

 

The New-PSRoleCapabilityFile cmdlet creates a file that defines a set of user capabilities that can be exposed through session configuration files. This includes determining which cmdlets, functions, and scripts will be available to users. The capability file is a human-readable text file that contains a hash table of session configuration properties and values. The file has a .psrc file name extension, and can be used by more than one session configuration.

 

The full details are here:- https://docs.microsoft.com/en-us/powershell/module/Microsoft.PowerShell.Core/New-PSRoleCapabilityFile?view=powershell-5.1

 

I will have to look into what MS has around best practice/ recommendations around this, I know it the later version of PS have more integration for JEA and app looker support has been added but needs more investigation before I can be sure of what is the best approach.

 

I have probably added these in the past on here a little old (also a little off topic) but worth a look:-

 

https://channel9.msdn.com/Events/Blue-Hat-Security-Briefings/BlueHat-Security-Briefings-Fall-2013-Sessions/PowerShell-Best-Practices

 

And this is a later view, and Lee covers the hobbling of PS and why its not good from a security/ admin perspective:-

 

https://blogs.msdn.microsoft.com/powershell/2017/10/23/defending-against-powershell-attacks/

Edited June 19, 2018 by HPlum78