From JEA, CLM, and WinRM to AMSI integration and execution policies: We’ll explain how you can professionally “harden” PowerShell and make it more secure.
What is “PowerShell Hardening”?
There is no official, universally accepted definition of “PowerShell Hardening.” On the one hand, the term refers to the process of hardening IT systems using PowerShell – that is, subjecting them to System Hardening. This can be done using custom-developed PowerShell scripts or with hardening tools such as Enforce Administrator, which is based on PowerShell DSC.
On the other hand, PowerShell Hardening also refers to the hardening of PowerShell itself. In many publications, the term is used in this sense.
📅 Enforce Administrator: Book a live demo
How do you harden PowerShell?
Using the last definition, PowerShell Hardening refers to a measure that significantly reduces PowerShell’s attack surface. This is achieved through the secure configuration of the application.
Why is this important? PowerShell has been used by IT administrators for about 20 years. They use it, among other things, to configure the operating system and automate tasks. As a result, attackers frequently attempt to “hijack” PowerShell to take control of systems. PowerShell is often used as a post-exploitation tool to spread further within the corporate network.
However, PowerShell Hardening does not mean banning or disabling the framework! Rather, it is about making its use controllable, traceable, and secure.
PowerShell Hardening thus follows the classic principles of System Hardening:
✅ Reduce the attack surface
✅ Limit opportunities for abuse
✅ Create transparency through logging
✅ Enable legitimate administration
PowerShell Hardening: What should you NOT do?
Yes, PowerShell can be exploited as an attack vector. However, it doesn’t make sense to completely uninstall PowerShell. NSA and other security agencies even explicitly advise against disabling or removing this Windows tool. Without PowerShell, essential administrative tasks can no longer be performed.
Aggressive restrictions that severely impair productivity also make no sense. PowerShell Hardening must not result in important scripts or administrative tools becoming unusable!
So always keep in mind: 100% System Hardening can and must never be your goal. Otherwise, your systems will become unusable!
How do you implement PowerShell Hardening?
Would you like to know in detail how to implement effective and sustainable PowerShell Hardening? Then you should implement the following measures:
Advanced Logging
➡ PowerShell offers extensive logging features such as script block logging, module logging, and transcription to make executed commands traceable. This transparency is extremely valuable from a security and forensic perspective, as PowerShell is frequently used in “Living off the Land” attacks.
➡ Logging is not a trivial matter! Even established standards like the CIS Benchmarks do not provide a clear-cut assessment of individual logging options, particularly transcription. They do not explicitly set these to “enabled” or “disabled,” but rather vary depending on the security profile and deployment scenario.
➡ For example, if scripts contain plaintext passwords or tokens, these can be unintentionally logged when logging is active. PowerShell Hardening requires a deliberate logging design, secure scripting standards, and clear organizational guidelines. And not just the blanket activation of all logging options.
Disable Legacy Components
➡ A fundamental hardening step is to disable outdated versions of PowerShell, particularly PowerShell 2.0. Since the outdated version does not support modern security features such as AMSI or enhanced logging, attackers exploit it as a downgrade path.
➡ PowerShell v2 should therefore be consistently disabled or removed. This significantly reduces the attack surface without impacting regular administrative operations.
Application Control and Code Signing
➡ One of the most effective measures in PowerShell Hardening is controlling which code is allowed to run. Technologies such as AppLocker or Windows Defender Application Control (WDAC) make it possible to restrict the execution of scripts and binary files to trusted sources.
➡ While AppLocker relies on rule-based permissions (such as path, hash, or publisher), WDAC takes a significantly stricter, kernel-based approach. This means that only explicitly approved code is permitted!
➡ Code signing also plays a central role in this context. Cryptographic signing of scripts ensures that only verified and approved code is executed. This not only ensures integrity but also establishes clear chains of trust in the operating environment.
➡ A key advantage: Other security mechanisms only achieve their full effectiveness through the use of Application Control. For example, Constrained Language Mode can be reliably enforced for untrusted code in combination with WDAC, while signed and approved scripts continue to run in Full Language Mode.
AMSI: Anti-Malware Scan Interface
➡ The Anti-Malware Scan Interface (AMSI) enables security solutions to analyze PowerShell code at runtime, regardless of whether the code comes from a file, is entered interactively, or is generated dynamically.
➡ Good to know: AMSI is not a protection mechanism that secures PowerShell. Rather, it is an interface that provides transparency for endpoint security products. Its effectiveness therefore depends largely on the connected application and the configuration.
➡ In the context of System Hardening, AMSI is a key component for detecting PowerShell abuse early on. However, it does not replace proper configurations or restricted permissions. Why? AMSI can be bypassed under certain conditions.
JEA: Just Enough Administration
➡ JEA technology allows administrative tasks to be provisioned in such a way that users are only permitted to perform the exact actions they need. All of this is done without granting general admin access. This significantly reduces risks, even if login credentials are compromised. It thus consistently implements the principle of least privilege.
➡ JEA is based on specially defined session configurations and roles (role capabilities). These are used to precisely define which commands and actions may be executed.
CLM: Constrained Language Mode
➡ Constrained Language Mode (CLM) specifically restricts powerful PowerShell features that are frequently exploited. These include, for example, access to .NET types, COM objects, or the dynamic generation of code. PowerShell remains usable when CLM is enabled, but the attack surface is significantly reduced.
➡ This means: While CLM restricts the technical capabilities of PowerShell, JEA controls what a user is allowed to do. CLM thus primarily protects against dangerous code on hardened systems, while JEA protects against excessive privileges in administrative sessions. Both approaches complement each other but do not replace one another.
➡ Constrained Language Mode is not intended as a standalone security measure. Only when combined with system-wide application control mechanisms such as AppLocker or Windows Defender Application Control does the protection work reliably.
➡ In such scenarios – depending on the configured policy -Windows automatically enforces Constrained Language Mode for untrusted code, while approved or signed scripts are still allowed to run in Full Language Mode.
➡ The security benefit thus results from the interplay of restriction and targeted trust. However, this requires well-defined policies as well as controlled script approval.
WinRM: Secure Remote Management
➡ PowerShell is frequently used for remote administration. Accordingly, WinRM is also a key component of the hardening process. Security depends largely on the specific use case and the authentication mechanism used.
➡ As a general rule, WinRM always encrypts communication, regardless of whether HTTP or HTTPS is used. As Microsoft describes, after successful authentication, all PowerShell remoting traffic is transmitted in encrypted form.
______________
A key difference when assessing security lies in the operating model:
🔻 In AD-integrated environments, authentication is performed via Kerberos by default. This verifies the identity of both the user and the target system without transmitting reusable credentials. In these scenarios, there is generally no additional need to use certificates in the context of WinRM.
🔻 In so-called standalone environments – that is, outside a domain – NTLM is used instead. Here, certificates primarily serve to verify the identity of the client and server. However, they are not responsible for the actual encryption of the communication.
🔻 This distinction is important: While Kerberos already provides strong authentication and mutual identity verification in AD environments, standalone scenarios require a carefully planned configuration to achieve comparable security levels.
🔻 Regardless of the scenario, access control remains a key factor. Only authorized systems and users should be permitted to use WinRM, combined with network restrictions and a well-defined permission model.
🔻 Since WinRM is frequently used for lateral movement within a network, the principle of least privilege also plays a central role. Technologies such as JEA can help to specifically restrict administrative access and limit the impact of compromised credentials.
🔻 The goal of PowerShell Hardening is therefore to enable controlled, traceable, and secure remote administration -taking into account the respective deployment scenarios.
______________
Handling Credentials
➡ PowerShell Hardening also includes the secure handling of credentials. Why? Poorly designed scripts can result in passwords or tokens being passed in plain text or even logged. Especially when transcription logging is enabled.
➡ Conclusion: Secure credential mechanisms and carefully planned logging strategies should definitely be part of your PowerShell Hardening!
➡ Therefore, secure mechanisms for credential management should be used, such as secret management solutions or dedicated vault systems. At the same time, clear guidelines for script development and logging are essential.
Execution Policy as a protective mechanism
➡ The Execution Policy is not a security mechanism either, but rather a safeguard against unintended script execution. Such as from accidentally opened files or unsigned scripts in emails.
➡ An attacker with sufficient privileges can bypass or deliberately modify the Execution Policy. Therefore, when hardening the system, it should not be viewed as a protective barrier, but rather as a baseline security setting. One that raises users’ awareness of the need to handle scripts responsibly.
➡ PowerShell Hardening, in this context, means above all: Do not create a false sense of security, but rather classify the Execution Policy correctly and combine it with genuine security measures!
Conclusion
PowerShell Hardening is not a single measure, but a holistic approach to making PowerShell a less attractive potential attack vector – without restricting functionality for authorized users. Only the combination of various strategies and measures (such as controlling code execution and maintaining a clean operating model) creates a robust security strategy.
Do you have further questions on this topic? Or do you need assistance? Please feel free to contact us. The FB Pro System hardening team is happy to assist you.
Images: Freepik/Magnific AI