November 1, 2022
Custom PowerShell rules can provide unique insight into the goals and methods attackers use in their attempts.
We already know that custom rules are essential for improving SIEM and operational security performance. In the previous parts of this series, we covered the risks of improper log collection and emphasized the importance of writing custom rules to catch suspicious PowerShell behavior that machine learning models aren’t likely to detect.
Part four of this series will focus on some of the information that custom rules can provide to analysts conducting incident investigations.
Custom rules can do more than enable Exabeam or USM Anywhere to block attacks that would otherwise go unnoticed. The logs that these rules rely on can tell us a lot about what attackers are doing, what their goals are, and how they intend to pursue them.
This is important for sensitive industries where advanced persistent threats are becoming increasingly common. Blocking one attack doesn’t always mean threat actors will move on and look for another target. They can afford to wait, regroup, and try a different approach.
That’s why security professionals must commit to continuously improving their custom rulesets. Fortunately, the data those rules provide can be an invaluable source of information about how the organization’s risk profile is changing over time.
Interpreting PowerShell Event IDs to Assess Threats
In Part Two of this series, we listed over twenty PowerShell log event IDs that SIEM users need to collect to optimize their custom rule capabilities. Each one of them tells a small part of an attack’s story, allowing security professionals to build accurate narratives around suspicious activities.
Let’s focus on two of those event IDs in particular:
- 4103 – PowerShell Module Logging
- 4104 – PowerShell Script Block Logging
These two events can store valuable data for attack forensics and threat-hunting tasks. Reviewing the data can tell investigators what attackers were actually doing with PowerShell, potentially showing lateral movement attempts and other activities that should inform future custom rules.
Let’s look at both of those in greater detail:
PowerShell Module Logging - 4103
This event records the pipeline execution details associated with PowerShell commands. It includes commands executed and some of the corresponding script data. It might not contain all of the details about the execution or its output results but will generally trigger more often than script block logging does.
This is particularly useful for detecting lateral movement and privilege escalations that may not otherwise trigger high-severity alerts. These events may be the first indication that something worth investigating is happening.
PowerShell Script Block Logging - 4104
This event records entire blocks of code as they are executed. This can give SIEM users a complete record of suspicious activity and the full content of the script involved. Since it maintains a complete audit trail of each activity, it’s a comprehensive resource for attack forensics.
Script block logging creates fewer events than module logging, but they tend to be more detailed. These events can be useful for organizations that need to minimize the volume of log data generated while still gaining visibility into attacker commands and code execution.
In both events, most will have a severity level of informational, but don’t let this distract you. While higher-level events warrant review and investigation, the informational events let us know if a service or elevated permissions account has been executing commands on platforms where they may not be permitted. This is why enhancing SIEM performance with UEBA technology is so important.
Note that 4014 events can be very short as well.
And of course, the transcription log will show both events together.
Improve Custom Rules Using Real-World Threat Activity
Every organization has a unique IT architecture guided by its business logic, history, and strategic goals. While there is a great deal of valuable threat intelligence data available from security vendors and institutional authorities, there is no replacement for visibility into how these threats interact with your systems and solutions.
When it comes to optimizing the security posture of a specific organization, enabling transcription, collecting logs, and building custom rules is just the beginning. As threat actors confront those rules, their activities will provide valuable information about how to improve rule performance. Pay close attention to your PowerShell event log data, and you’ll find clear opportunities to reinforce your organization’s security posture moving forward.
Improve your custom rulesets with proper interpretation of PowerShell Event IDs. Get in touch with Castra for assistance today.