Being able to respond and detect malicious events effectively is critical when operating SIEM solutions. There is a fine line between seeing too much and not seeing enough. This article will focus on how to identify and detect PowerShell ShellCode with a Splunk search query. That search can be made into a dashboard or even developed into an alert whenever that activity occurs. Powershell is one of the most effective scripting languages and one of the most abused, so it is essential to have the means of detecting when its shellcode is in use.
Known Malicious Use Cases for Powershell
Powershell has many ways it can be utilized legitimately. Unfortunately, it can be abused as well just as quickly. The following are some ways that Powershell can be used to harm a system or network.
- Stopping privilege escalation is a great way to hinder any further activity; if an attacker cannot escalate, they are essentially stuck.
- Having a solid familiarity with your business is crucial in understanding what “normal” files look like. Hackers enjoy hiding their scripts as common file names or intuitive “clickbait” files like “AmazonGiftCard.ps1”.
Executing compiled scripts
- The ability to run scripts should be restricted by a role, if possible, to ensure that malicious PowerShell compiled scripts cannot be executed from every machine if not necessary.
Remote execution of exploits
- Being able to run commands on a network remotely is as dangerous as it gets. Hackers can run their malicious payloads from an outside location without detection by not having proper access controls to restrict it and appropriate network blocks in the area.
Propagation (using Microsoft office macros)
- Nested PowerShell scripts that are passed around from person to person within an email or embedded link can wreak havoc if not quickly detected and rectified.
Why is PowerShell so effective?
Outside of PowerShell is a powerful tool, some other reasons why it is used by hackers religiously are as follows:
- Most internal operations teams trust PowerShell by default or at first glance, as it is seen more like a “professional” tool than a hacker tool. Also, system administrators use it regularly, so the security team may get alert fatigue if they are not actively tuning out allowed activity, thus missing an actual attack.
- It’s not as noisy as you may think. Currently, there are only two or three different event codes dedicated specifically to detecting Powershell activity. Which, by default, could create fewer leads for analysts to dig into.
- It, by default, can incorporate remote access executions.
How to detect PowerShell within a Splunk Search
We all have been waiting for this moment; now that we know how Powershell can be abused within a corporate environment, how exactly do we detect it? The following search query will enable Security teams to pick up on traces where it is being used within your Splunk subscription.
This base search will detect whenever a PowerShell instance attempts to execute a remote command. Ideally, you will want to tune this rule to exclude known administrators allowed to run PowerShell possibly. Still, as a starting point, you shouldn’t have anyone (not logged into your VPN) running remote scripts from outside your network. Additionally, if you want to take an even more proactive approach and detect ALL instances where PowerShell has been executed in general, swap out event code 4104 with 4103.
(source="WinEventLog:Microsoft-Windows-PowerShell/Operational" (EventCode="4104" "AAAAYInlM") ("OiCAAAAYInlM" OR "OiJAAAAYInlM"))
By implementing the above Splunk search query, you are proactively taking the necessary steps to improve overall security visibility. There hardly is ever a “one size fits all approach” when it pertains to Security controls; you must do what is feasible for your enterprise. To understand more about how Powershell works or how you can best learn the Splunk search language, head over to Cybrary to check out the available fantastic content.