Guide | How To How do you secure PowerShell?

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

shmu26

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

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

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.
 
Last edited by a moderator:

Andy Ful

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

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 ? :confused:

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

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,150
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?
 
  • Like
Reactions: AtlBo and Andy Ful

shmu26

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,150

darko999

Level 17
Verified
Well-known
Oct 2, 2014
805
without and with admin rights same outcome

FEbh2UG.png
 

Andy Ful

From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
7,900
It's fun searching for the PowerShell infos - innit ? :confused:

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.
 
Last edited:

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