Current reports on the use of Windows PowerShell as an attack platform bring up the increased need to detect and prevent the abuse of our system administration ecosystem. The recent release of Mandiant’s M-Trends 2017 annual report highlights the development of more sophisticated tactics, techniques, and procedures (TTP) by financial threat actors against banking targets in Asia and Europe. These attacks are employing internal system administration tools, specifically Windows PowerShell, to fly under the radar and maintain persistence.
“Windows PowerShell is a good example of a relatively new attack vector that many organizations are not monitoring and logging. Attackers are increasingly leveraging Windows PowerShell to conduct their operations when undertaking malicious activity within a victim’s environment. In many environments, PowerShell does not leave artifacts indicating its usage. This situation can be improved by upgrading older versions of PowerShell (such as 2.0) to later, more robust logging versions (5.0 offers a much broader range of security information) and by implementing additional logging features such as Sysmon. The bottom line from an incident response perspective is that while PowerShell logging was not a typically monitored event to maintain effective cyber threat visibility five years ago, it most definitely is now.”
Windows PowerShell was developed by Microsoft to provide a system administration infrastructure that provides more power and flexibility to perform automated routine tasks and configuration management across their entire domain. PowerShell is based on the .NET framework and provides a command-line shell as well as a powerful scripting language. The PowerShell Gallery gives system administrators a list of modules and scripts to deploy on their domain and the ability to contribute their own for the community.
However, many security researchers and penetration testers have developed a number of post-exploitation tools using PowerShell—PowerSploit, Empire, PoshSec, PowerUp and PowerView are just a few examples. Blue Teams need to actively search for the execution of these modules and react quickly when they appear in their log data.
PowerShell Version Updates
Thankfully, Microsoft added some instrumentation capabilities to PowerShell starting in version 3.0. Windows 7 and Server 2008 ship with PowerShell version 2.0, so system administrators need to upgrade the .NET framework and the Windows Management Framework to version 5.0.
Threat actors are aware that PowerShell version 2.0 does not log and are taking advantage of that by forcing the use of version 2.0; which is supported for backwards compatibility reasons. The command to do so is quite simple and may be run in a command shell or PowerShell:
PowerShell.exe -Version 2 “your command arguments here”
Incident responders need greater visibility to detect the use of PowerShell version 2 in addition to current versions. Instrumenting Windows Powershell is fairly straight forward because the tool leverages Microsoft’s existing event logging capabilities. We recommend that you enable PowerShell logging according to the procedures outlined by Matthew Dunwoody (Mandiant/FireEye).
To obtain the visibility necessary to audit PowerShell command line, module, and script execution, do the following:
- Upgrade to the current version
- Enable logging capabilities through group policy
- Increase windows instrumentation through Sysmon
External Procedure Links
Enable PowerShell logging
The following instructions assist you in enabling PowerShell Logging: https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html
To gain endpoint visibility and record critical events, we recommend installation and configuration of Sysmon, its free and easy to install. To install Sysmon, see the Collecting Windows Logs and Events from Windows Machine article, and select Sysmon from the table of contents.
Suspicious Cmd Line Arguments
Execution of PowerShell with command line arguments that include the following should be regarded as suspicious and prompt further investigation:
PowerShell.exe -Version 2 PowerShell.exe -EncodedCommand PowerShell.exe -ExecutionPolicy Bypass PowerShell.exe -NonInteractive PowerShell.exe -NoProfile PowerShell.exe -WindowStyle Hidden