Users of Endpoint Detection Response (EDR) systems know they are powerful tools for detecting Threat Actors (TA)'s. But there is often be a lot of mystery about how they work and hence the badness of what they detect and/or block. This mystery makes can not only make it difficult to understand EDR coverage of attacks, but more critically understand an major EDR pain point which is they tend to have a lot of false positives. For understanding how EDRs work, I really like this EDR Telemetry project from Kostas https://github.com/tsale/EDR-Telemetry?tab=readme-ov-file
The project divides EDR telemetry into these categories:
Process Activity
File Manipulation
User Account Activity
Network Activity
Hash Algorithms
Registry Activity
Schedules Task Activity
Service Activity
Drive/Module Activity
Device Operations
Other Related Events
Named Pipe Activity
EDR Sysops
WMI Activity
BITS Jobs activities
Powershell Activity
Understanding Powershell Activity
Reviewing important aspects of monitoring PowerShell activity, it is crucial to focus on PowerShell script block logging. Below is a table detailing different types of PowerShell logs, their descriptions, and their log locations. Analyzing script block logs allows for strong detections of suspicious software and tools executed within PowerShell scripts. For example, the logged script block can be examined for strings like 'mimikatz' (a popular hacking tool) or 'sekurlsa' (a module within mimikatz). While this detection method is not foolproof, skilled threat actors may alter common names, it serves as an additional layer of detection that would not be possible without this type of logging.
This article discussed Script Block Logging within the context of a specific EDR detection function. However, it is important to note that even if your EDR does not support PowerShell Script Block Logging analysis, you can still analyze PowerShell script blocks for malicious activity using other mechanisms. This flexibility is not always available for other types of EDR telemetry.
To analyze PowerShell script blocks outside of EDR, you need to enable PowerShell Script Block Logging and export these logs (event ID 4104) to an external logging system like a SIEM. The external logging system can then run queries to examine the content of these PowerShell logs for suspicious strings that could indicate malicious activity.
An important aspect of PowerShell Script Block Logging analysis is that many EDRs include alerts for detecting Base64 encoding in scripts. While Base64 encoding is increasingly common in legitimate scripts, including those used by Windows Defender EDR (which can lead to it flagging its own scripts as suspicious), its presence alone does not indicate malicious activity. Understanding the context of Base64 encoding is crucial for effective analysis. It's not the encoding itself that is suspicious, but rather how it is used. Therefore, a foundational understanding of Base64 is essential for contextualizing its presence and decoding it when necessary.
kql encoded powershell
Powershell arms race
ith the added security features in PowerShell (ie. ScriptBlock Logging, AMSI, etc.), it makes sense that red teamers are investing in other options. And C# is the logical next step from PowerShell, seeing that they both are based on the .NET framework and porting toolsets from PowerShell to C# is fairly easy to do
AMSI bypass.
AMSI patching in particular, has started to be targeted by a lot of AV and EDR solutions so this is a major perk of the technique.
script block smuggling
References
Comentários