Splunk is committed to using inclusive and unbiased language. This blog post might contain terminology that we no longer use. For more information on our updated terminology and our stance on biased language, please visit our blog post. We appreciate your understanding as we work towards making our community more inclusive for everyone.
The Splunk Threat Research Team (STRT) most recently began evaluating more ways to generate security content using native Windows event logging regarding PowerShell Script Block Logging. 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 (Event Code 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. Adversaries continue to use PowerShell and defenders are granted deeper visibility with Script Block Logging.
Watch the video to understand how STRT has developed PowerShell analytics for Splunk by using the Splunk Attack Range to collect the generated logs, and hunt for suspicious PowerShell.
PowerShell attacks have not surmised and Microsoft continues to expand on new features, plus it’s native integration in each operating system. Since version 5 of PowerShell, logging was expanded to include script block, module and transaction logging. What does this mean? Granular visibility into what is being run on our endpoints.
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.
Windows Event Code=4104
What does it look like?
The Splunk Threat Research Team has developed a set of detections to assist with getting started in detecting suspicious 4104 script block events.
Analytic |
Technique |
Tactic |
Notes |
T1059.001 |
Identifies two values that are always found in the default PowerShell-Empire payloads. |
||
T1059.001 |
Identifies strings typically found in PowerShell script block code related to mimikatz. |
||
T1059.001, T1055 |
Identifies the use of GetProcAddress within the script block. |
||
T1059.001, T1027 |
Identifies the use of Base64 within the script block. |
||
T1562 |
Identifies system.management.automation.amsi within the script block, typically found in encoded commands disabling AMSI. |
||
T1059.001 |
Identifies commands typically found with domain and trust enumeration. |
||
PowerShell Loading .NET into Memory via System.Reflection.Assembly |
T1059.001 |
Identifies system.reflection.assembly within the script block being used, typically found in malicious PowerShell script execution. |
|
T1027.005 |
Identifies the `mutex` function typically found and used in malicious PowerShell script execution. |
||
T1059.001 |
Identifies suspicious PowerShell script execution via EventCode 4104 that is processing compressed stream data. |
||
T1140 |
Identifies within the script block the use of memory stream as new object backstore. |
||
T1592 |
Identifies suspicious PowerShell script execution performing checks to identify anti-virus products installed on the endpoint. |
||
T1592 |
Identifies suspicious PowerShell where WMI is performing an event query looking for running processes or running services. |
||
T1592 |
Identifies suspicious PowerShell script execution where WMI is performing an event query looking for running processes or running services. |
||
T1021.001 |
Identifies suspicious PowerShell commands to allow inbound traffic inbound to a specific local port within the public profile. |
||
T1114.001 |
Identifies known mailsniper.ps1 functions executed on an endpoint. |
||
T1490 |
Identifies PowerShell commands to delete shadow copy using the WMIC PowerShell module. |
||
T1027.005 |
Identifies enabling of smb1protocol through PowerShell Script Block logging. |
||
T1546.003 |
Identifies WMI Event Subscription to establish persistence or perform privilege escalation. |
The following community Splunk SOAR playbooks mentioned below can be used in conjunction with some of the previously described Powershell analytics.
Name |
Technique ID |
Tactic |
Description |
Execution |
This playbook hunts for malware across managed endpoints, disables affected users, shuts down their devices, and blocks files by their hash from further execution via Carbon Black. |
||
Execution |
This playbook tries to determine if a file is malware and whether or not the file is present on any managed machines. VirusTotal "file reputation" and PANW WildFire "detonate file" are used to determine if a file is malware, and CarbonBlack Response "hunt file" is used to search managed machines for the file. The results of these investigations are summarized in an email to the incident response team. |
||
Execution |
This playbook retrieves IP addresses, domains, and file hashes, blocks them on various services, and adds them to specific blocklists as custom lists |
For more information about how Splunk SOAR can accelerate investigations and remediations for your SOC, check out the upcoming Splunk4Ninjas Splunk SOAR Hands On Workshop.
PowerShell is not leaving the Windows endpoint any time soon. As defenders, we need to expand beyond process and command-line analytics and begin diving deeper into our logs to identify more unique ways to capture malicious or suspicious activity. Script block logging, albeit not new, opens our horizons to see complete scripts being executed
For a full list of security content, check out the release notes on Splunk Docs:
You can find the latest content about security analytic stories on GitHub and in Splunkbase. Splunk Security Essentials also has all these detections now available via push update.
Any feedback or requests? Feel free to put in an issue on GitHub, and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions If you need an invitation to our Splunk user groups on Slack.
We would like to thank the whole threat research team Jose Hernandez, Rod Soto, Bhavin Patel, Mauricio Velazco, Michael Haag, Teoderick Contreras, Lou Stella and Patrick Bareiss for their contribution to this release.
The Splunk platform removes the barriers between data and action, empowering observability, IT and security teams to ensure their organizations are secure, resilient and innovative.
Founded in 2003, Splunk is a global company — with over 7,500 employees, Splunkers have received over 1,020 patents to date and availability in 21 regions around the world — and offers an open, extensible data platform that supports shared data across any environment so that all teams in an organization can get end-to-end visibility, with context, for every interaction and business process. Build a strong data foundation with Splunk.