Background
PowerShell had its beginnings as a way to enable administrators to perform their tasks both locally and remotely with unprecedented access to underlying Windows components, such as COM objects and WMI. Since being included in every major Windows Operating System since Windows 7, PowerShell based tooling is well proliferated for both legitimate and malicious use and includes common tooling such as SharpSploit, PowerSploit, PowerShell Empire, Nishang and Invoke-Obfuscation.
Sumo Logic Cloud SIEM Enterprise Special Ops (SpecOps) has observed a significant uptick in PowerShell utilization by malicious actors in recent years that directly relates to the industry’s growing recognition of the “Fileless malware” threat. These attacks have grown in popularity with the advancement of malicious actors’ tactics, allowing them to leverage attacks that avoid malware being placed onto a targeted system (i.e., “fileless”). Attackers can now harness PowerShell to execute commands within memory, rendering traditional malware hash analysis and detection methods obsolete. With this approach, malicious actors increase their chances of operating undetected and likely succeeding in their objective(s).
This growing prevalence of “fileless” tactics and techniques, also known as “Living off the Land,” can essentially be boiled down into the adversary relying on resources already within the victim’s operating system and environment instead of having to pull down custom tooling. With this tactic, adversaries can focus on utilizing local applications, processes and scripting such as PowerShell and Windows Management Instrumentation (WMI).
While this may seem like a daunting task for defenders to differentiate between legitimate activity and malicious, a number of techniques exist. The first in a series on Windows-based Threat Detection, this post will focus on techniques around Windows logging that can help pick out the malicious PowerShell activity.
Essential Logging
Thankfully Microsoft has granted the blue team a way to capture some additional logging that will provide more insight into the PowerShell activity within the environment. While there are certainly a number of PowerShell logs that can be enabled, this is our base recommendation.
- Event ID 4103 – PowerShell Module Logging
- Event ID 4104 – PowerShell Script Block Logging
- Event ID 4688 – Audit Process Creation w/ Command Line Process Auditing
Note: PowerShell version 5.0 or newer required
Configuring all of this logging is covered step-by-step with screenshots in the Appendix.
Threat Hunting for PowerShell in Cloud SIEM Enterprise
With PowerShell Operational logging configured and enabled, let’s take a look at how these appear in CSE and a few examples of some initial threat hunting that can be performed.
Mimikatz
Event ID 4104 provides tremendous visibility for the entire script block, which in this case we use to identify password stealer activity. Mimikatz is routinely observed by SpecOps, and it never ceases to amaze us how lazy attackers can be. By performing a simple search within CSE for “Mimikatz,” we find that it was attempting to be downloaded by a .Net WebClient.
Malicious PowerShell via CLI
To effectively determine what is being run within the environment given the increase in fileless attacks and living off the land it is necessary to enable Audit Process Creation w/ Command Line Process Auditing. With Event ID 4688 Audit Process Creation and Command Line Process Auditing now enabled, let’s take a look at what can be accomplished within CSE.
When performing any type of threat hunting on Windows-based logs, it can be useful to start with looking at basic statistical anomalies. By analyzing the rare events (above), a suspicious PowerShell command immediately sticks out.
- powershell.exe -WinDOwStyLE HiDdEn -exe bypass -file C:UsersSpecOpsAppDataRoamingbwfbkilpdgauiu62nbcu.ps1
SpecOps, when performing a threat hunting operation, will often start with basic statistical techniques and then pivot to more common TTPs that have been previously observed. When analyzing malicious PowerShell, it becomes evident that most commands will incorporate some form of bypass to circumvent the PowerShell Execution Policy.
By looking for a command line with bypass, we are able to find the same result from above without having to look through every command line. While there are numerous ways to utilize obfuscation with PowerShell, it can still be extremely effective to start hunting with just the basic syntax and progressing to more complex statements.
PowerShell Lateral Movement via WinRM
PowerShell Module Logging (Event ID 4103) may not have the robust content that Script Block Logging (Event ID 4104) contains, but it can still be useful to identify areas that will require further analysis. In the case of lateral movement, SpecOps routinely identifies the use of Windows Remote Management(WinRM) through the use of the PowerShell command Enter-PSSession. By structuring a search for Enter-PSSession within CSE, it makes it possible to identify connections that may be malicious. While Enter-PSSession and the use of WinRM are not the only way to identify PowerShell based lateral movement, it is a good starting point and can help in the task of breaking down malicious vs legitimate usage.
Conclusion
In recent years, “fileless” attacks and “living off the land” have been gaining popularity and more importantly functionality. Without adequate logging in place, there is no way to achieve visibility and differentiate between legitimate and malicious activity with regard to these activities. To effectively determine what is being run within the environment, it is necessary to enable Audit Process Creation w/ Command Line Process Auditing. By enabling these three Event IDs (4104, 4103, and 4688), blue teamers can effectively increase visibility and context necessary to understanding “fileless” threats.
Appendix
Configuring PowerShell Event ID 4103/4104
The combination of PowerShell Module and Script Block logging provide the ability to view the entire script block that is processed, and in many cases script obfuscation is removed revealing the deobfuscated code. The full script contents will appear in Event ID 4104, while Event ID 4103 will contain pipeline execution details as PowerShell executes, including variable initialization and command invocations.
Logging will be configured via Group Policy:
- Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell.
- Select: Turn on Module Logging, and Select: Enabled, Select: OK
- Select: Turn on PowerShell Script Block Logging, and Select: Enabled, Select: Log script block invocation start /stop events:
Configuring Event ID 4688
Enabling Audit Process Creation w/ Command Line Process Auditing allows for logging command line arguments that are commonly leveraged in fileless based attacks and is an invaluable resource for the blue team.
Logging will be configured via Group Policy:
- Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration > Detailed Tracking
- Select: Audit Process Creation, Select: Success + Failure, Select: OK
- Computer Configuration > Policies > Administrative Templates > System > Audit Process Creation
- Select: Include command line in process creation events, Select: Enabled, Select: OK
