InTrust 11.6 - Preparing for Auditing and Monitoring PowerShell Activity

PowerShell Auditing and Real-Time Monitoring Overview

InTrust provides a number of disparate features that help you track and regulate the use of PowerShell in your environment. This document summarizes how InTrust covers these needs and what workflows you can configure to meet them.

To get ready for working with PowerShell logs, make sure the events you are interested in are audited. For details, see Making PowerShell Events Available.

After you have set up PowerShell logging, proceed to configure your InTrust workflows. See the following topics:

• Setting Up Monitoring for Suspicious PowerShell Activity
• Monitoring for PowerShell Downgrades
• Real-Time Collection and Forwarding of PowerShell Activity Data
• Task-Based Gathering of PowerShell Activity Data
• Analyzing PowerShell Events in Repository Viewer

Making PowerShell Events Available

It is recommended that the computers you want to watch should have PowerShell 5.1 or later installed, because its logging facilities are far superior to earlier versions of PowerShell.

Configuration Through Group Policy

PowerShell activity must be logged on the computers you are interested in monitoring and gathering from. In the Group Policy Management console, configure the Computer Configuration | Policies | Administrative Templates | Windows Components | Windows PowerShell policy for these computers, as follows:

1. Set the Turn on Module Logging item to Enabled and specify * as the module name.
2. Set the Turn on PowerShell Script Block Logging item to Enabled and select the Log script block invocation start / stop events option for it.

Configuration Through the Registry

An alternative way to turn on the necessary logging options is to modify the registry. You can use the snippet below for this purpose.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\PowerShell]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging]
"EnableModuleLogging"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging\ModuleNames]
"*"="*"

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging]
"EnableScriptBlockLogging"=dword:00000001
"EnableScriptBlockInvocationLogging"=dword:00000001

Save it as a text file with the reg extension. Once you have the file, use the Merge command on it to enable logging by modifying the registry.

Monitoring for PowerShell Downgrades

PowerShell logging capabilities have improved significantly from version to version. Early PowerShell versions audit much fewer kinds of events that more recent ones. However, PowerShell provides a way to run cmdlets in modes that are compatible with previous versions. Therefore, a common attack strategy is to use the compatibility mode in order to prevent logging of malicious activity. The "PowerShell downgrade attack detected" rule informs you about such threats.

You need the following:

• The real-time monitoring rule
  To monitor computers running PowerShell, use the Advanced Threat Protection | Windows/AD Suspicious Activity | PowerShell | PowerShell downgrade attack detected rule as the starting point.
• The site that contains the computers you want to watch
  The predefined "All Workstations" site may suit your needs. If you want to be more specific than that, create your own site and include the computers you need that run PowerShell or PowerShell Core.
• The real-time monitoring policy that applies the rule to the computers you want to protect
  Use the "Windows/AD Security: Detecting Common Attacks" real-time monitoring policy as your template and associate your policy with the correct site. If you have made separate sites for computers running PowerShell and PowerShell Core, include both sites in the policy.

How It Works

The "PowerShell downgrade attack detected" rule works by capturing PowerShell startup events. If PowerShell 2.0 or earlier is invoked, the alert is triggered.

Configuration Details

All of the required elements (the rule, policy and site listed above) are predefined in InTrust and associated with one another. If the existing configuration suits you, you can use the predefined objects directly. However, if you want to make adjustments, consider making copies of the objects, re-associating the copies and proceeding to work with them instead of the originals. InTrust treats all sites, rules and policies the same whether they are predefined or user-defined.

The following procedure assumes that you are working with your personalized copies of the objects listed above and doesn't mention the default predefined objects.

1. In InTrust Manager, under Configuration | Sites | Microsoft Windows Network, make sure your site is populated with the computers you want to monitor for PowerShell downgrades.

2. Open the properties of the rule. Click the Notifications tab and check that an email message is listed. Edit the message if necessary, as described in the Message Templates section of the Notification topic.
3. Click the General tab and select the Enabled option to activate the rule. After you close rule properties, commit the changes.
4. Open the properties of the real-time monitoring policy. On the Rules tab, make sure the necessary rule is specified.
5. On the Sites tab, specify the correct site or sites.
6. Select the E-mail tab, and click Add to specify who will receive the messages. For detailed instructions, see the Notification Groups section of the Real-Time Monitoring Overview topic.
7. Select the General tab and select the Activate option. After you close the properties dialog box, commit the changes. The configuration is now finished; InTrust agents will be installed automatically to the site computers to perform the monitoring.

You can modify such settings as alerting, response actions, rule activity time, or others at any time as necessary.

Setting Up Monitoring for Suspicious PowerShell Activity

This topic helps you minimize the impact of attacks based on PowerShell scripts. InTrust lets you thwart PowerShell-wielding attackers by setting up alerts and emergency response actions for whenever someone uses suspicious PowerShell commands.

You need the following:

• The real-time monitoring rule
  To monitor computers running PowerShell Core 6.0 and later, use the Advanced Threat Protection | Windows/AD Suspicious Activity | PowerShell | Suspicious PowerShell Core activity rule as the starting point. For computers running PowerShell 5.1 and earlier, use the Advanced Threat Protection | Windows/AD Suspicious Activity | PowerShell | Suspicious PowerShell activity rule.
• The site that contains the computers you want to watch
  The predefined "All Workstations" site may suit your needs. If you want to be more specific than that, create your own site and include the computers you need that run PowerShell or PowerShell Core. If some of these computers run PowerShell and the others PowerShell Core, create two sites for each set.
• The real-time monitoring policy that applies the rule to the computers you want to protect
  Use the "Windows/AD Security: Detecting Common Attacks" real-time monitoring policy as your template and associate your policy with the correct site. If you have made separate sites for computers running PowerShell and PowerShell Core, create a separate real-time monitoring policy for each site.
• Make sure PowerShell logging is enabled through group policy on the computers you want to monitor
  See Making PowerShell Events Available for details.

How It Works

The "Suspicious PowerShell activity" and "Suspicious PowerShell Core activity" rules work by capturing the use of PowerShell keywords from a specific set. These keywords are traces of PowerShell activity that might mean trouble if the activity is done by the wrong people. Keywords like this are typically found in modules that uncover system vulnerabilities, such as PowerSploit. These modules are often designed for testing purposes, but they are just as effective if the intent is malicious. If any of the keywords is detected in the PowerShell command prompt input or implicitly at any level during PowerShell operation, the rule is matched.

The rule has two parameters that control its operation:

• Keywords
  This is the list of keywords that the rule watches for, as described above. The default list is designed to cover a wide range of suspicious situations and minimize false positives. You can extend this list to anticipate other threats that you are aware of.
• User Whitelist
  These are the users who you trust with PowerShell. The rule will ignore whatever these users do with PowerShell. Use this parameter to specify accounts that have to perform administrative tasks on the monitored computers. Today, a lot of such tasks are performed through PowerShell by Windows without the user having to work with PowerShell directly. Take this into account when whitelisting users; this will help avoid false positives.

The rule can trigger the following response actions to stop an attacker in their tracks and help investigate the situation:

• Log off the offending user, provided that they are logged on interactively
• Disable the user account
• Stop and disable the Windows Remote Management service; if the user is logged on remotely, this will cut off their PowerShell session
• Enable auditing of a variety of events for analysis of that user's subsequent activity

By default, all of these response actions are disabled. You can enable any combination of them as necessary.

Configuration Details

All of the required elements (the rules, policy and site listed above) are predefined in InTrust and associated with one another. If the existing configuration suits you, you can use the predefined objects directly. However, if you want to make adjustments, consider making copies of the objects, re-associating the copies and proceeding to work with them instead of the originals. InTrust treats all sites, rules and policies the same whether they are predefined or user-defined.

The following procedure assumes that you are working with your personalized copies of the objects listed above and doesn't mention the default predefined objects.

1. In InTrust Manager, under Configuration | Sites | Microsoft Windows Network, make sure your site is populated with the computers you want to monitor for suspicious PowerShell activity.

2. Open the properties of the rule. Click the Notifications tab and check that an email message is listed. Edit the message if necessary, as described in the Message Templates section of the Notification topic.
3. Select the Response Actions tab, and select the check boxes next to any of the response actions you need.
4. Click the General tab and select the Enabled option to activate the rule. After you close rule properties, commit the changes.
5. Open the properties of the real-time monitoring policy. On the Rules tab, make sure the necessary rule is specified.
6. On the Sites tab, make sure the correct site is specified.
7. Select the E-mail tab, and click Add to specify who will receive the messages. For detailed instructions, the Notification Groups section of the Real-Time Monitoring Overview topic.
8. Select the General tab and select the Activate option. After you close the properties dialog box, commit the changes. The configuration is now finished; InTrust agents will be installed automatically to the site computers to perform the monitoring.

You can modify such settings as alerting, response actions, rule activity time, or others at any time as necessary.