Guide | How To How do you secure PowerShell?

[shmu26]

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 Windows XP + 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.

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.

 

[Andy Ful]

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.

Do not forget about System.Management.Automation.dll . I do not know anyone trying to delete or rename this DLL, so I cannot recommend it.
.
Edit.
Both System.Management.Automation.dll and its native image System.Management.Automation.ni.dll should be taken into consideration.

 

[shmu26]

Do not forget about System.Management.Automation.dll . I do not know anyone trying to delete or rename this DLL, so I cannot recommend it.

Let's say someone deletes powershell.exe, but he doesn't delete this dll that you mentioned. Can powershell still run??

 

[Andy Ful]

Let's say someone deletes powershell.exe, but he doesn't delete this dll that you mentioned. Can powershell still run??

Yes. From memory using that DLL or via dropped powershell.exe, or via custom made fake powershell.exe .

 

[ParaXY]

I use an AppLocker exception Publisher rule to stop Powershell from running. I also block things like cscript.exe and wscript.exe from running.

 

[_CyberGhosT_]

I use an AppLocker exception Publisher rule to stop Powershell from running. I also block things like cscript.exe and wscript.exe from running.

Very good

 

[ParaXY]

Very good

I have almost 70 Microsoft executables that I don't allow to run under an SUA account

 

[509322]

Do not forget about System.Management.Automation.dll . I do not know anyone trying to delete or rename this DLL, so I cannot recommend it.

Do it as an experiment in VM.

Let's say someone deletes powershell.exe, but he doesn't delete this dll that you mentioned. Can powershell still run??

PowerShell can be run by using a custom *.dll or executable = even if you disable PowerShell in the Windows Shell and, I believe, disable System.Management.Automation.dll (not 100 % sure on this), then PowerShell can still run on the system. For example, as a post-exploit.

That is why you want to run commonly exploited programs - like Office and browsers - with robust restricted privileges. You might end up with a User Session infection that can still cause problems, but once you reboot the system it should not persist if the restrictions are robust with inheritance.

Restricted Privileges does not prevent encryption, key-logging, data theft, network connects, etc; it blocks persistence. Encryption does not need persistence. That is why additional User Space policies are needed to bolster Restricted Privileges.

 

[Andy Ful]

Do it as an experiment in VM.



PowerShell can be run by using a custom *.dll or executable = even if you disable PowerShell in the Windows Shell and, I believe, disable System.Management.Automation.dll (not 100 % sure on this), then PowerShell can still run on the system. For example, as a post-exploit.

That is why you want to run commonly exploited programs - like Office and browsers - with robust restricted privileges. You might end up with a User Session infection that can still cause problems, but once you reboot the system it should not persist if the restrictions are robust with inheritance.

Restricted Privileges does not prevent encryption, key-logging, data theft, network connects, etc; it blocks persistence. Encryption does not need persistence. That is why additional User Space policies are needed to bolster Restricted Privileges.

Powershell APIs sit in the System.Management.Automation.dll, so any PowerShell hosting executable has to use it. It is possible to make a custom executable wrapped with its own System.Management.Automation.dll. In this case, it can run PowerShell scripts without PowerShell installed in the system. But, such scenario is more complicated than using malware executable without powershell. Attackers focus on using PowerShell components already present in the system, especially when PowerShell malware script is going to be run from memory.

Edit.
From msdn.microsoft.com :

System.Management.Automation
This namespace is the root namespace for Windows PowerShell. It contains the classes, enumerations, and interfaces required to implement custom cmdlets. In particular, the Cmdlet class is the base class from which all cmdlet classes must be derived.

Windows PowerShell Reference

 

[509322]

Powershell APIs sit in the System.Management.Automation.dll, so any PowerShell hosting executable has to use it. It is possible to make a custom executable wrapped with its own System.Management.Automation.dll. In this case, it can run PowerShell scripts without PowerShell installed in the system. But, such scenario is more complicated than using malware executable without powershell. Attackers focus on using PowerShell components already present in the system, especially when PowerShell malware script is going to be run from memory.

Edit.
From msdn.microsoft.com :

System.Management.Automation
This namespace is the root namespace for Windows PowerShell. It contains the classes, enumerations, and interfaces required to implement custom cmdlets. In particular, the Cmdlet class is the base class from which all cmdlet classes must be derived.

Windows PowerShell Reference

It's fun searching for the PowerShell infos - innit ?

It is so much fun that I would rather set "No Language" mode and risk borking the system. Clean installing the OS is a whole lot faster than finding PowerShell infos that make sense.

 

[shmu26]

Do it as an experiment in VM.



PowerShell can be run by using a custom *.dll or executable = even if you disable PowerShell in the Windows Shell and, I believe, disable System.Management.Automation.dll (not 100 % sure on this), then PowerShell can still run on the system. For example, as a post-exploit.

That is why you want to run commonly exploited programs - like Office and browsers - with robust restricted privileges. You might end up with a User Session infection that can still cause problems, but once you reboot the system it should not persist if the restrictions are robust with inheritance.

Restricted Privileges does not prevent encryption, key-logging, data theft, network connects, etc; it blocks persistence. Encryption does not need persistence. That is why additional User Space policies are needed to bolster Restricted Privileges.

What do you say about the Comodo 10 approach to catching powershell scripts? Will that cover all the scenarios?

 

[Sunshine-boy]

What do you say about the Comodo 10 approach to catching powershell scripts? Will that cover all the scenarios?

Comodo Internet Security Setup/configuration thread (Setting Only)
I think yes cuz umbra said:
File List
set some vulnerable processes as unrecognized (regedit.exe, cmd.exe, etc...)

 

[Sunshine-boy]

everyone need to config comodo like umbra settings: Or u are infected

 

[shmu26]

Comodo Internet Security Setup/configuration thread (Setting Only)
I think yes cuz umbra said:
File List
set some vulnerable processes as unrecognized (regedit.exe, cmd.exe, etc...)

That may be a very good idea, but it really has nothing to do with the Comodo 10 mechanism for catching scripts, which is supposed to eliminate the need for that tweak.

 

[darko999]

without and with admin rights same outcome

 

[WinXPert]

everyone need to config comodo like umbra settings: Or u are infected

Don't have Comodo, so I'm chopped liver?

 

[shmu26]

Don't have Comodo, so I'm chopped liver?

Pass the mustard, please.

 

[Sunshine-boy]

Don't have Comodo, so I'm chopped liver?

idk

 

[Deleted member 178]

That may be a very good idea, but it really has nothing to do with the Comodo 10 mechanism for catching scripts, which is supposed to eliminate the need for that tweak.

My setting was for v8 , then Comodo finally understood with v10 that some legit processes have to be closely monitored/protected.

 

[Andy Ful]

It's fun searching for the PowerShell infos - innit ?

It is so much fun that I would rather set "No Language" mode and risk borking the system. Clean installing the OS is a whole lot faster than finding PowerShell infos that make sense.

Yes, it is true. NoLanguage mode can be applied on computers with PowerShell 2.0 (even with Windows XP and Vista). Anyone can apply it by creating the file 'C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1' with the command: $ExecutionContext.SessionState.LanguageMode='NoLanguage'
.
Edit.
I edited this post to underline that the above can be bypassed by using '-noprofile' command in PowerShell, so it is not recommended.