Rules
Rules for PowerShell Protect.
You can configure rules to determine which script executions to audit and\or block. This document outlines how to configure rules. You can generate rules with the configuration cmdlets.
Conditions
Rules are evaluated based on conditions. Conditions look at various properties of a PowerShell script and execution environment to determine whether the script can run or if it should be audited.
Multiple Conditions
Rules can contain multiple conditions. If all of the conditions are met, the rule will execute the actions defined by the action references.
Match One or More Conditions
When specifying multiple conditions, by default all conditions must be met before the rule is triggered. If you specify the -AnyCondition
parameter of New-PSPRule
, any condition will trigger the rule.
Properties
Conditions check specific properties to ensure that they meet the given criteria. Below is a list of the available properties. PowerShell Protect takes advantage of the PowerShell Abstract Syntax Tree (AST) to analyzer scripts.
Operators
Operators are used for matching properties to values. Below is a list of available operators. None of the operators are case sensitive.
Value
The value is a string to match with the property value during execution. This is a string, boolean or a RegEx.
Default Rules
The default rules are built-in to PowerShell Protect and do not require configuration.
AMSI Bypass Protection
The AMSI bypass protection will be enabled by default. An AMSI bypass prevents AMSI from loading and thus prevents Windows Defender from scanning scripts as well as PowerShell Protect.
You can learn more about AMSI bypass by reading our previous post.
Log4J CVE-2021-44228 (Log4Shell)
Requires PowerShell Protect 2021.12.0 or later.
Blocks attempts to use the Log4j jndi
string used to exploit CVE-2021-44228
Module and Script Block Logging Bypass Protection
Module and script block logging provide insight into the scripts that are running on a system. There are techniques to bypass this logging and Protect will block those by default.
Assembly Load from Memory
One common technique for loading malicious assemblies in a fileless attack is to store the assembly as a base64 encoded string within the script. The System.Reflection.Assembly.Load
method will be used to load the byte array directly in memory without accessing the file system. PowerShell Protect will now detect the use of this method and block the script.
Here is a blog post about an AMSI bypass loaded with this method.
An example of this in action from the blog post is listed below.
Disabling Defender
Windows comes with cmdlets for managing the local Windows Defender instance. The Set-MpPreference
cmdlet can be used to disable Windows Defender by using the DisableRealtimeMonitoring
parameter. Although you will need administrative permissions to perform this action, you will be able to see if users are attempting to execute this command and further investigate the behavior.
An example of the command that is blocked is listed below.
Invoke-Expression
Invoke-Expression
is used to execute arbitrary strings as PowerShell script. While it can be used for legitimate purposes, it is often used to download and execute malicious payloads such as this recently discovered exploit.
Use of the System.Reflection.Emit Namespace
One common technique used by fileless attacks is the ability to define .NET assemblies and types in memory. This can be done with the System.Reflection.Emit
namespace. Rather than invoking the C# compiler, like with Add-Type
, you won’t see any file system activity when this type of attack is taking place. PowerShell Protect will now watch for these types of method calls, audit and block them.
You can see an example of this in PowerSploit’s Invoke-ReflectivePEInjection
command for loading binaries into memory without file system access.
This is one way of loading a binary, like Mimikatz, into memory from a script-based payload.
An example of the script that would be blocked.
PowerSploit
Windows Defender already blocks a bunch of the PowerSploit commands. You won’t be able to use Invoke-Mimikatz
or Invoke-ReflectivePEInjection
as-is on a default Windows environment because Defender is checking for these commands. PowerShell Protect now checks for all functions defined in PowerSploit to ensure that no one is poking around your environment with any of the tools.
Marshal Class
The use of the System.RuntimeServices.Interop.Marshal
class may be an indication that someone is attempting to manipulate memory within the PowerShell process. This class provides methods for allocating unmanaged memory segments, copying bytes around and determining memory sizes, among other things.
The use of the Marshal
class is rare in the C# and the .NET world and should be even more rare in the PowerShell world. Although it may not be an actual attack, it’s a strange thing to be doing for most sysadmins.
An example of the script that would be blocked.
Persistent WMI Event Subscription
Attackers may use WMI to create a persistent WMI event subscription to run a command during system start up or user logon. This is a difficult attack to detect. It’s also a less common use of PowerShell. We’ve decided to block it by default in PowerShell Protect.
An example of the script that would be blocked.
BloudHound Injestor Execution
BloudHound is an Active Directory tool for enumerating and visualizing relationships in a domain or forest. It uses an injestor, SharpHound, to execute the enumeration of objects and discover their relationships. There are some signs of SharpHound usage that we have identified and blocked to prevent people from executing SharpHound. Other rules, like Assembly Loading for Memory, will also prevent this type of script execution.
An example of the script that would be blocked.
Kerberoasting
Kerberoasting is a lateral movement technique that abuses the Kerberos Ticket Granting Service (TGS). Using tools like Mimikatz, tickets can be dumped from memory, brute forced offline and then used to exfiltrate passwords which can be used to move laterally across an environment.
PowerShell Protect looks for signs of this type of attack being performed based on signatures found in scripts like Invoke-Kerberoasting.ps1.
An example of the script that would be blocked.
Disabling Default Rules
You can disable default rules by using the -DisableBuiltinRules
.
You can disable default rules by using the -DisabledBuiltInConditions
parameter.
Last updated