Blog | PowerShell Security Best Practices

September 27, 2017

Threat actors have long since used legitimate tools to infiltrate and laterally move across defender’s networks. The reasons for this are clear; the likelihood of being detected is much lower when authorized tools are leveraged instead of malicious tools that might trigger prevention or detection controls. PowerShell attributes have also made it attractive to adversaries, having been used most recently in the Petya/NotPetya campaign. In this blog, we will cover some PowerShell best practices that will prepare you for adversaries who will use your own PowerShell implementation against you.


PowerShell is an automation platform and scripting language for Microsoft Windows and Windows Server, which allows you to simplify your system management. Unlike other text-based shells, PowerShell harnesses the power of Microsoft’s .NET Framework, providing rich objects and a massive set of built-in functions to take control of your Windows environments.

Windows PowerShell


PowerShell has been used heavily for cyber attacks, especially recently during the Petya/NotPetya campaigns. The most important aspect for attackers is its native integration with the .NET Framework, which offers multiple options for infecting or manipulating the target.

PowerShell’s most attractive attributes to adversaries are:

  • Simple access to network sockets
  • Ability to assemble malicious binaries dynamically in memory
  • Direct access to the Win32 Application Programming Interface (API)
  • Simple interface with Windows Management Instrumentation (WMI)
  • Powerful scripting environment
  • Dynamic, runtime method calls
  • Easy access to crypto libraries, e.g. IPSec, hashing algorithms
  • Ability to hook managed code
  • Simple bindings to Component Object Model (COM) (

All the above render PowerShell an extremely effective attack vector.

PowerShell was initially mentioned as an attack platform in 2010 (, when it was presented at Def Con 18 as proof of concept. Both a bind and reverse shell programmed purely in PowerShell were demonstrated in the same context.

There are numerous attack tools – like Nishang, PowerSploit, and PowerShell Empire platform (www.PowerShellempire[.]com)  –  that offer a post-exploitation agent built on cryptological communications. These tools can be used for reconnaissance, persistence, and lateral movement, as well as other offensive techniques. Of course, given its native capabilities, PowerShell can be programmed in multiple ways, providing custom tools and techniques to remain stealthy and undetected by common security controls and countermeasures.

Adversarial Tactics, Techniques & Common Knowledge, or ATT&CK by Mitre, which provides an extensive list of attack vectors, tactics, and techniques, describes PowerShell as a powerful interface that adversaries can use to perform a variety of actions, and provides real-world examples.


Given that PowerShell cannot be disabled or removed from organizations that require it, the following actions are the recommended best practices to use PowerShell efficiently while preventing its use as an attack vector.

1. PSLockDownPolicy And PowerShell Constrained Language Mode

Constrained language mode limits the capability of PowerShell to base functionality, removing advanced feature support, such as .NET and Windows API calls and COM access. This lack of advanced functionality stops most PowerShell attack tools, because they rely on these methods. However, in enterprise environments it can negatively affect legitimate scripts; thus it is highly recommended to schedule a testing period before activating this option, to filter out the legitimately used code.

Enable Constrained Language Mode:
[Environment]::SetEnvironmentVariable(‘__PSLockdownPolicy‘, ‘4’, ‘Machine‘)

Enable via Group Policy:
Computer Configuration\Preferences\Windows Settings\Environment (

2. PowerShell V.5 With Applocker And Device Guard

PowerShell v.5 comes with significant embedded security features that make its use more secure for enterprise environments. These security features include:

  • Script block logging. Script block logging provides the ability to log de-obfuscated PowerShell code to the event log.
  • System-wide transcripts. System-wide transcription can be enabled via Group Policy and provides an “over the shoulder” transcript file of every PowerShell command and code block executed on a system by every user on that system.
  • Constrained PowerShell. Constrained Language mode (as described above in best practice 1).
  • Antimalware integration (Windows 10). The new Windows 10 Antimalware Scan Interface (AMSI) enables all the scripting engines (PowerShell, VBScript, and JScript) to request analysis of dynamic content: from a script file, typed commands at the command line, and even code downloaded and executed in memory. This enables scanning of PowerShell code before it is executed on the computer.

In addition, using Applocker to block executables from unwanted user locations will provide better control.

Device Guard which is also applicable on Windows 10 and Windows Server 2016 can be used to enforce constrained language mode and application whitelisting by leveraging advanced hardware features where supported. (

3. Logging PowerShell Activity

PowerShell logging can be enabled via Group Policy for PowerShell modules:

  • Microsoft.PowerShell.* (i.e., Microsoft.PowerShell.Management module) – Logs most of PowerShell’s core capability.
  • ActiveDirectory – Logs Active Directory cmdlet use. A lightweight Windows PowerShell script that performs a single function.
  • BITS Transfer – Logs use of Background Intelligent Transfer Service (BITS) cmdlets.
  • CimCmdlets (2012R2/8.1) – Logs cmdlets that interface with Common Information Model (CIM).
  • GroupPolicy – Logs Group Policy cmdlet use.
  • Microsoft.WSMan.Management – Logs cmdlets that manage Web Services for Management (WS-Management) and Windows Remote Management (WinRM).
  • NetAdapter/NetConnection – Logs Network-related cdmdlets.
  • PSScheduledJob/ScheduledTasks (PSv5) – Logs cmdlets to manage scheduled jobs.
  • ServerManager – Logs Server Manager cmdlet use.
  • SmbShare – Logs Server Message Block (SMB) sharing activity.

For these logs to be useful, they need to be fed into a central logging system with alerts configured for known attack methods.

Relevant activity:

  • Downloads via .Net (New-Object Net.WebClient).DownloadString)
  • Invoke-Expression (and derivatives: “iex”)
  • BITS activity 
  • Scheduled Task creation/deletion
  • PowerShell Remoting

The best method to detect PowerShell attack code is to look for key indicators – code snippets required for the code to run correctly.

Example: Detecting Mimikatz (a widely-used tool for logged user credential capture)
Invoke-Mimikatz Event Log Keywords:


“System.Reflection.Emit.AssemblyBuilderAccess “




For obfuscated PowerShell, custom rules should be developed. For example:

  • Look for lots of brackets { }
  • Look for lots of quote marks ‘ ”

Both of these are heavily used in obfuscation techniques and usually are not used by legitimate software or normal administrators.

4. Remove PowerShell V.2

It is obvious that the security features integrated in the latest versions of PowerShell do not apply to v.2, which makes its use very attractive to adversaries; PowerShell v.2 can be used for lateral movement and persistence techniques with the same functionality. PowerShell v.2’s extra value is that because it does not have native logging capabilities, it remains undetected and offers stealth in attacker operations.

For that and other reasons Microsoft has recently announced that PowerShell v.2 will be deprecated from the next Windows 10 Update which is scheduled for this September (, so either way it is highly recommend to check and remove PowerShell v.2 from your environment.

You can check whether Windows PowerShell 2.0 is installed by running the following (as an administrator).

  • On Windows 7/8.1/10, the following will return a State as either Enabled or Disabled:
    • Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2
  •  On Windows Server, the following will return an InstallState of either Installed or Removed:
    • Get-WindowsFeature PowerShell-V2

5. Just Enough Administration – JEA

This is included with the latest update of Windows Management Framework 5.0 and 5.1, and is a security technology that helps organizations enforce information security by restricting IT administrative rights. JEA provides a practical, role-based approach to set up and automate restrictions for IT personnel, and reduces the risks associated with providing users with full administrative rights following the principle of least privilege.

JEA is implemented as a Windows PowerShell session endpoint (it requires PS remoting to be enabled), which includes a PowerShell Session Configuration file and one or more Role Capability files.

  • PowerShell Session Configuration file. This file is used to specify who can connect to an endpoint. Users and security groups can be mapped to specific management roles. Those files are specific to each machine, so an access control per machine is available. They contain information of what will be the name of the JEA endpoint, which roles will be assigned and of course who will have access to this endpoint. These files are PowerShell data files ending in a .pssc extension (
  • Role Capability files. These files are used to specify what actions users in a particular role can perform. For example it can be restricted to use certain pre-selected cmdlets, functions and external programs making the use of custom potentially malicious cdmlets practically impossible. Examples of potentially dangerous commands that should be constrained, are ‘Start-Process’, ‘New-Service’, ‘Invokde-Item’ etc. Detailed information on how to create such files can be found here
  • JEA configuration samples. Examples and templates can be found in Microsoft’s JEA Github repository (

Finally, another significant benefit of JEA is the actionable logging and reporting which is available in the Windows event log format, since all operations performed through the JEA endpoint can be recorded (with transcripts and logs) and show who accessed the environment and when, and what changes were made.

6. Scripts Code Signing

If PowerShell scripts are used in an enterprise environment, code signing is another control that improves security posture, by ensuring authenticity and integrity. This feature, along with a defined Execution Policy or Group Policy as “AllSigned” or “RemoteSigned”, will permit only digitally signed scripts to run. However we have to consider that several attacks in the past used malicious files digitally signed so this control just adds another security layer since it can be bypassed.


Because PowerShell is being monitored more and more by the day, adversaries have come up with techniques that evade detection, including:

  • Version downgrade to PowerShell v.2
  • Custom use of .NET Framework without PowerShell.exe execution
  • PowerShell obfuscation (invoke-obfuscation)

These are just indicative techniques; further analysis is not within the scope of this document, however “Logging PowerShell Activity” best practices will detect most of them.


The most significant recommendation, after reviewing most of the known attack techniques used recently, is upgrading to Windows 10 and PowerShell v.5 with all security features enabled and removing PowerShell v.2 as well. However, this is not easily feasible for most enterprise environments; of equal priority are activating embedded security features and extensive logging focused on specific indicators commonly used for attacking techniques.

Previous Post
BlueKeep: Cutting through the hype to prepare your organization
BlueKeep: Cutting through the hype to prepare your organization

Over the last week we have all been tuning into our news feeds and listening to the security folks chatting...

Next Report
Weekly Intelligence Summary 10 Jan 2020
Weekly Intelligence Summary 10 Jan 2020

In the spotlight this week: Iranian cyber response neither impossible nor guaranteed