MITRE’s data sources
- PowerShell logs
- Loaded DLLs
- DLL monitoring
- Windows Registry
- File monitoring
- Process monitoring
- Process command-line parameters
Beyond those referenced by ATT&CK, security teams should consider collecting information from Microsoft’s Antimalware Scan Interface (AMSI), Sysmon, and ScriptBlock logging.
Unfortunately, there is no single data source that provides a holistic way to reliably observe and detect PowerShell in all of its varied forms. AMSI is very effective at detecting malicious uses of PowerShell, but it can produce high volumes of data that lack context if you don’t have some type of event tracing enabled. ScriptBlock logging provides a tremendous level of visibility into the PowerShell activity it logs, but it is not able to record PowerShell that is injected directly into memory.
Once you’re collecting the logs necessary to observe malicious instances of PowerShell, you can begin looking for process interactions and other artifacts that will reliably alert your security team to anomalous and potentially malicious behaviors. As a caveat, many of these suggestions are environment-dependent and will vary in effectiveness from one organization to another.
A good place to start is a review of encoded commands. Not all encoded commands are malicious, but most malicious commands are encoded. Looking for encoded or obfuscated command lines will consistently provide value when searching for malicious activity. While this may be noisy in some environments, you’ll want to consider looking for:
- All variations of the -encodedcommand switch. (
- Strings such as Base64
- Use of obfuscation characters, such as
Weeding out false positives
To combat the noise, begin whitelisting common encoded commands observed in your environment related to known good applications and approved IT activity. Constant tuning of your detection criteria improves the fidelity of alerts, which saves analysis time and reduces alert fatigue in your SOC.
It may be helpful to monitor all scheduled tasks that were created using PowerShell across your environment. If you are able to filter certain command lines, then it’s worthwhile to look out for any containing URLs. The following alert ideas will reliably find malicious PowerShell, but they might also generate a lot of noise:
- Strings such as
http or parsing command lines for
wget, to name a handful of options
- Commands leveraging .NET for modules such as
From an EDR perspective, tracking process ancestry is another good PowerShell detection strategy. Malicious PowerShell often stems from an unusual parent process, such as Microsoft Office applications such as Word or Excel, as is common in macro-laden phishing attacks.