Minimize your digital risk by detecting data loss, securing your online brand, and reducing your attack surface.
A powerful, easy-to-use search engine that combines structured technical data with content from the open, deep, and dark web.
Digital Risk Protection
Research Team Finds 50% Increase in Exposed Data in One Year
New report recognizes Digital Shadows for strongest current offering, strategy, and market presence of 14 vendors profiled
Read Full Report
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.
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:
All the above render PowerShell an extremely effective attack vector.
PowerShell was initially mentioned as an attack platform in 2010 (https://www.youtube.com/watch?v=JKlVONfD53w), 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 (https://adsecurity.org/?p=2604)
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:
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. (https://docs.microsoft.com/en-us/windows/device-security/device-guard/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies)
3. Logging PowerShell Activity
PowerShell logging can be enabled via Group Policy for PowerShell modules:
For these logs to be useful, they need to be fed into a central logging system with alerts configured for known attack methods.
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:
For obfuscated PowerShell, custom rules should be developed. For example:
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 (https://support.microsoft.com/en-us/help/4034825/features-that-are-removed-or-deprecated-in-windows-10-fall-creators-up), 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).
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.
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:
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.