Hunting for Malicious PowerShell using Script Block Logging

The Splunk Threat Research Team recently evaluated ways to generate security content using native Windows event logging regarding PowerShell Script Block Logging to assist enterprise defenders in finding malicious PowerShell scripts. This method provides greater depth of visibility as it provides the raw (entire) PowerShell script output. There are three sources that may enhance any defender's perspective: module, script block and transcript logging. We focused our security content on script block logging (4104) as it provides the most granular visibility of PowerShell scripts that execute on an endpoint. However, we also provided a way to gather all three for testing validation, production or curiosity.

Summary of Logging Types

  • Transcript Logging: As described by Microsoft, Transcript Logging provides a summary of what’s happening in a PowerShell session as if you were looking over the shoulder of the person typing. It will provide the commands and the output of those commands. This is fairly verbose in most organizations and would require filtering (via the Splunk UF, in Splunk) or logging only on critical assets. What does it look like?

  • Module Logging: module logging is a bit different in that it includes the command invocations and portions of the script. It’s possible it will not have the entire details of the execution and the results. EventCode = 4103. What does it look like?

  • Script Block Logging: This is the raw, deobfuscated script supplied through the command line or wrapped in a function, script, workflow or similar. Think of everytime an adversary executes an encoded PowerShell script or command, script block logging provides that data in its raw form. EventCode = 4104. What does it look like?

Hunting Analytic

As we began generating content, we wanted a way to evaluate the dataset created to identify keywords that would ultimately convert to new analytics. We utilized all the standard frameworks in use; Empire, Cobalt Strike, Metasploit, Atomic Red Team and AtomicTestHarnesses. Script block provides a voluminous amount of data and we didn’t want to be too selective on our keywords for the analytics we wanted to produce. With this release, we’re publishing a hunting analytic that will assist with combing through 4104 event data. This detection is powered by the merging of two queries (Thank you Alex Teixeira) to assist with maximizing the identification of suspicious PowerShell usage. The detection may be found on our Security Content repository here.

As we played with the data more and more, we have found that it’s even more useful by adding scores to each keyword. Keywords in this case are each `eval`. In this instance, the scoring is based on fidelity. $DoIt is a function that Cobalt Strike uses, therefore the score is set to 4. Keywords like IEX are more commonly used and I’ve set the score to 2. An example of the scoring used in the following capture showcases how the scores can help bring up interesting PowerShell scripts. It is also easy enough to copy and paste an eval statement and add new keywords. Our example is not exhaustive, but a starting point for defenders to begin digging deeper. 


Following our research effort, we were able to compile a good amount of new analytics. We hope this inspires others to contribute (via GitHub Issues or PR) to continue to enhance coverage for the community. 





Detect Empire with PowerShell Script Block Logging



Identifies two values that are always found in the default PowerShell-Empire payloads.

Detect Mimikatz With PowerShell Script Block Logging



Identifies strings typically found in PowerShell script block code related to mimikatz.

Powershell Fileless Process Injection via GetProcAddress

T1059.001, T1055

Execution, Defense Evasion, Privilege Escalation

Identifies the use of GetProcAddress within the script block.

Powershell Fileless Script Contains Base64 Encoded Content

T1059.001, T1027


Identifies the use of Base64 within the script block.

Unloading AMSI via Reflection


Defense Evasion

Identifies within the script block, typically found in encoded commands disabling AMSI.

PowerShell Domain Enumeration



Identifies commands typically found with domain and trust enumeration.

PowerShell Loading .NET into Memory via System.Reflection.Assembly



Identifies system.reflection.assembly within the script block being used, typically found in malicious PowerShell script execution.

Powershell Creating Thread Mutex


Defense Evasion

Identifies the `mutex` function typically found and used in malicious PowerShell script execution.

Powershell Processing Stream Of Data



Identifies suspicious PowerShell script execution via EventCode 4104 that is processing compressed stream data.

Powershell Using memory As Backing Store


Defense Evasion

Identifies within the script block the use of memory stream as new object backstore.

Recon AVProduct Through Pwh or WMI



Identifies suspicious PowerShell script execution performing checks to identify anti-virus products installed on the endpoint.

Recon Using WMI Class



Identifies suspicious PowerShell where WMI is performing an event query looking for running processes or running services.

WMI Recon Running Process or Services



Identifies suspicious PowerShell script execution where WMI is performing an event query looking for running processes or running services.

Allow Inbound Traffic In Firewall Rule


Lateral Movement

Identifies suspicious PowerShell commands to allow inbound traffic inbound to a specific local port within the public profile.

Mailsniper Invoke functions



Identifies known mailsniper.ps1 functions executed on an endpoint.

Delete ShadowCopy With PowerShell



Identifies PowerShell commands to delete shadow copy using the WMIC PowerShell module.

Powershell Enable SMB1Protocol Feature


Defense Evasion

Identifies enabling of smb1protocol through PowerShell Script Block logging.

Detect WMI Event Subscription Persistence


Privilege Escalation, Persistence

Identifies WMI Event Subscription to establish persistence or perform privilege escalation.





How to Enable It?

There are three effective ways to enable PowerShell Logging. Depending upon the deployment method or if needing to deploy across a large fleet, the registry or Group Policy will be the best bet. If testing in a lab setting, all three methods following will help.


This method may be useful if using a deployment or logon script. 

  • Enable ScriptBlock Logging
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging
      • EnableScriptBlockLogging = 1
  • Enable Module Logging
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging
  • EnableModuleLogging = 1
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging \ModuleNames
      • * = *
  • Transcription
    • HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription\
      • EnableInvocationHeader = 1
      • EnableTranscripting = 1
      • OutputDirectory = <path_to_directory>

The PowerShell Operational Log may be found here:



In any case, Hurricane Labs references a script written by Tim Ip that we have borrowed and expanded on. We enhanced it with the following abilities:

  • Enable one or all PowerShell logging methods
  • Create a new inputs.conf to capture transcript logs and PowerShell Operational logs
  • Disable all logging
  • Enables Process Creation with Command-Line (4688)

Get Invoke-SPLPowerShellAuditLogging here.

Update a currently used Windows inputs.conf on the Splunk Universal Forwarder or use Invoke-SPLPowerShellAuditLogging to create the inputs. 

source = XmlWinEventLog:Microsoft-Windows-PowerShell/Operational
renderXml = 0
disabled = false
index = win   
sourcetype = powershell:transcript
disabled = false
multiline_event_extra_waittime = true
time_before_close = 300
index = win
`Invoke-SPLPowerShellAuditLogging -method CreateInputs`

Enable Logging via Group Policy Objects

For a more enterprise and granular policy deployment approach, within the Group Policy Management Console, create a new or modify an existing object, browse to Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell

From here, enable the policies of interest and begin logging. Deploy to critical assets or all as needed.

This work was inspired by many others who have written about PowerShell Logging, but not limited to:

Test Yourself

Atomic Red Team: Using Atomic Red Team, we can simulate PowerShell commands simply using Invoke-AtomicRedTeam. To begin, check out the Wiki and follow along.

In a lab setting, or authorized device, run the following commands to get started:

IEX (IWR '' -UseBasicParsing);
    Install-AtomicRedTeam -getAtomics -force

This will install Invoke-AtomicRedTeam. From here, we may now run T1059.001 from Atomic Red Team.

invoke-AtomicTest T1059.001

Want some more data? Check out AtomicTestHarnesses.

Out-ATHPowerShellCommandLineParameter -GenerateAllParamVariations -UseEncodedCommandParam -Execute

Learn More

To learn more, watch the on-demand Splunk Tech Talk "Hunting for Malicious PowerShell using Script Block Logging" now.


The Splunk Threat Research Team is an active part of a customer’s overall defense strategy by enhancing Splunk security offerings with verified research and security content such as use cases, detection searches, and playbooks. We help security teams around the globe strengthen operations by providing tactical guidance and insights to detect, investigate and respond against the latest threats. The Splunk Threat Research Team focuses on understanding how threats, actors, and vulnerabilities work, and the team replicates attacks which are stored as datasets in the Attack Data repository

Our goal is to provide security teams with research they can leverage in their day to day operations and to become the industry standard for SIEM detections. We are a team of industry-recognized experts who are encouraged to improve the security industry by sharing our work with the community via conference talks, open-sourcing projects, and writing white papers or blogs. You will also find us presenting our research at conferences such as Defcon, Blackhat, RSA, and many more.

Read more Splunk Security Content

Join the Discussion