Joff Thyer //  

It is no secret that PowerShell is increasingly being used as an offensive tool for attack purposes by both Red Teamers and Criminals alike. Thanks to the efforts of a number of people in the industry, we have tools like PowerSploit, PowerShell Empire, MailSniper, and Bloodhound just to name a few of the top contenders. While most of these tools are definitely post-exploitation in nature, the ability of Red Teamers, and attackers to trivially social engineer end users provides an easy path to extensive PowerShell usage.

Windows 7 is still prevalent in enterprise environments with the default installation version of PowerShell at 2.0. Unfortunately, this version of PowerShell provides no real event logging ability, thus leaving defenders largely blind with the exception of one PowerShell script signing policy.

Fortunately for defenders, Microsoft has responded with significant PowerShell logging enhancements in the Windows Management Framework (WMF) starting with version 4.0, and version 5.0. If an organization is using Windows 10, then the Windows Management Framework is already installed at version 5.0. For those organizations still at Windows 7, it is advisable to upgrade all workstations to WMF version 5.0 bring PowerShell also up to version 5. In addition, Windows 7 has a dependency on dot NET version 4.5 in order to install WMF 5.0. Once this is completed, there are some additional event logging features enabled which include the following:

1. Module Logging: logs PowerShell pipeline execution details during execution including variable initialization, and command invocation. Module logging is able to record some de-obfuscated scripts, and also some output data. This form of logging has actually been available since PowerShell 3.0 and will log all events to Event ID 4103.
2. Script Block Logging: logs and records all blocks of PowerShell code as they are executing. The full contents of the code, including the entire script, and all commands are captured. Script block logging also captures all de-obfuscated code due to the object-oriented nature of its implemented. For example, if a script is base64 encoded using the “-Encoded” command argument, script block logging will log the actual decoded script block during execution. Unlike module logging, script block logging does not log the output from executed scripts. If an event exceeds the maximum event log message size, script block logging will split the logged events into multiple events. Additionally, in PowerShell 5.0, script block logging will log events that match a list of suspicious commands at a logging level of “warning”. The normal logging level will be “verbose” or “informational” when enabled. The “suspicious” events will be logged regardless unless script block logging is explicitly disabled. All script block logging events are logged as event ID 4104. In addition to this event, there is an option to log script block execution start and stop events as event ID 4105, and 4106. In my experimentation, enabling this option also provides little additional benefit at the cost of many more events being logged, thus I chose to leave this option disabled.
3. Full Transcription Logging: logs a full transcript of every single PowerShell session with input and output data. The transcripts are written to individual files with a naming convention that prevents name collisions. It is important to note that transcription only records what appears in the PowerShell terminal windows which does include the contents of scripts or output written directly to the file system. While the transcripts are written by default to the documents folder, this is configurable. It would be advisable to write the transcripts to something like a network share to avoid being deleted and/or modified by an attacker.

After performing the required upgrade to WMF 5, and PowerShell 5 (if using Windows 7), the next step is to enable the logging options. All of these options can be enabled through group policy, however, be aware that the appropriate Windows 10 administrative template files need to be installed before the group policy options will be visible. Not being a former Windows system administrator, I struggled through this for a while before I found the administrative template download located at this Microsoft web page.

https://www.microsoft.com/en-us/download/details.aspx?id=48257

Note that after installation of the administrative templates, your task is not over. All that the installation actually does is copy the files into the “\Program Files (x86)\Microsoft Group Policy” directory. It is up to you to move the appropriate “PowerShellExecutionPolicy.admx”, and the “PowerShellExecutionPolicy.adml” into the correct locations on your system. In a domain environment, the SYSVOL can also be used to deploy administrative templates by using the “\\SYSVOL\Policies\Policy Definitions” directory.

After doing this, your local or domain group policy should contain the additional logging options both in the computer, and user configuration areas. The path to the configuration under each area is:

Policies -> Administrative Templates -> Windows PowerShell

Once you have defined these group policy options, the actual events will be logged on the local system in the Applications and Services Logs, as follows:

Applications and Services ->

                Microsoft ->

                        Windows ->

                                PowerShell ->

                                        Operational

The following screenshot was taken after establishing a PowerShell empire session on a remote system. In the process, many different script block log entries were created showing important detailed information on all of the different script blocks being executed. You can also see in this event log that a couple of entries are logged at a “Warning” level indicating potentially suspicious code being executed.

Having said all this, do yourselves a favor, and get WMF 5.0 installed in your environment followed by enabling script block logging at minimum. Friends don’t let friends run PowerShell without logging! Of course, I am assuming that you are all happily planning on collecting these event logs centrally right!?

Happy hunting!