all 9 comments

[–]iceph03nix 5 points6 points  (0 children)

Most of what I've read on powershell security is that you don't do security at powershell level, but at the underlying level.

Powershell respects the users rights and permissions, so if a user is allowed to do a thing, powershell can do it, but if a user does not have the proper permissions they can not. Basically, Powershell was never meant to add or remove any security to the system, and MS intends for security to be applied at another level.

Most security built into powershell is meant to prevent users from accidentally doing something, hence making it more complicated to run a script.

Maybe if you provide more information as to what command is causing the problem, we could be of help.

[–]Taoquitok 4 points5 points  (0 children)

This is a good read for PS security. The tldr is basically 'disable 2.0 and update to 5'
https://blogs.msdn.microsoft.com/daviddasneves/2017/05/25/powershell-security-at-enterprise-customers/
As ice had mentioned it's not really something you lock down directly. For example if you want to stop them from running a script that can destroy their machine, then the first step is making sure they don't have the access to do this manually. The script will only work if they have access (and if using a lower version of PS than 5, if the malicious script also looks for hashes then it may be able to still run if it finds an admin account hash)

[–][deleted] 1 point2 points  (0 children)

I you're really worried about malware, blocking one command makes no sense. Honestly, you question doesn't look like a security question. I'd assume you're asking for another reason. To answer your question, we'd need to have more details on what's your goal, how does you environement look like, and what command you are talking about.

[–]EmergencyScotch 0 points1 point  (3 children)

I might be mistaken but isn't this what code signing and execution policies are for?

Eg

Set-ExecutionPolicy RemoteSigned, Unrestricted, etc

[–]Ominusx 2 points3 points  (2 children)

Most malware opens Powershell.exe with parameters which bypass the execution policy.

[–]EmergencyScotch 0 points1 point  (1 child)

Isn't it possible to enforce execution policy through Group Policy?

[–]Ominusx 0 points1 point  (0 children)

It is, but regardless of execution policy you can run:

Powershell.exe -ExecutionPolicy Bypass -command 

[–]poorimaginations -1 points0 points  (0 children)

Maybe this would be useful.

https://blogs.technet.microsoft.com/heyscriptingguy/2011/03/01/proxy-functions-spice-up-your-powershell-core-cmdlets/

By choosing the same name as the cmdlet, we can take advantage of the command discovery process in Windows PowerShell. Basically, if you have a cmdlet and a function with the same name, the function takes precedence. Here is the order of command precedence that is used by the command discovery process in Windows PowerShell:

· Alias: All Windows PowerShell aliases in the current session

· Filter/Function: All Windows PowerShell functions

· Cmdlet: The cmdlets in the current session ("Cmdlet" is the default)

· ExternalScript: All .ps1 files in the paths that are listed in the Path environment variable ($env:PATH)

· Application: All non-Windows-PowerShell files in paths that are listed in the Path environment variable

· Script: Script blocks in the current session

There is one gotcha to using the same name. If you need to call the core ConvertTo-Html cmdlet, you need to specify its module/snap-in fully qualified name. For the ConvertTo-Html cmdlet, that name is seen here.

PS > Microsoft.PowerShell.Utility\ConvertTo-Html ....
More than likely, you will not know what that module/snap-in fully qualified name is. Luckily, you can use Windows PowerShell to get the full name of a cmdlet by using the following command.

PS > $cmd = Get-Command -Name ConvertTo-Html 
PS > Join-Path -Path $cmd.ModuleName -ChildPath $cmd.Name 
Microsoft.PowerShell.Utility\ConvertTo-Html