Agent SmartResponse Host Checking

The Problem

How can you find out if a SmartResponse™ plug-in using PowerShell will run on a specific System Monitor Agent host? Also, with what user context will the SmartResponse plug-ins execute?

Windows PowerShell execution policies let you determine the conditions under which PowerShell loads configuration files and runs scripts. We would like to find out what that setting is on a specific host that has a System Monitor Agent installed. Read more about execution policies here:

SmartResponse plug-ins initiated on a System Monitor host will run in the User Context of the System Monitor Agent Service on that host. Knowing what that user context is will help us to configure our SmartResponse appropriately.

The Short Answer

We can find out both the execution policy and user context—a sample SmartResponse plug-in for doing this is attached.

The Solution

Because PowerShell implements a cmdlet which reports the execution policy, this should be pretty straightforward to create a SmartResponse. However, we need the PowerShell execution policy to be configured to allow our script to run…in order to find out if scripts can run or not. I have to say there’s a bit of an inter-dependency crisis there.

No problem. PowerShell allows you to specify a BASE64 encoded string at the PowerShell command line, and by design, it encoded commands are not controlled by the Execution Policy. Therefore, we can leverage a BASE64-encoded PowerShell command within SmartResponse to find out the current execution policy.

We initially create a PowerShell script that queries both the current user context and the execution policy. We then BASE64 encode the whole PowerShell script and insert the BASE64 encoding as a parameter in our SmartResponse actions.xml file.

Here’s a snippet of the file:

(Click on images to view larger)

Figure 1. Snippet of PowerShell Script

So, let’s import it into LogRhythm and go launch the SmartResponse manually against a specific Host:

Figure 2. Initiating SmartResponse

We see the service request being sent:

Figure 3. Sending Service Request

And the response:

Figure 4. Service Request Response

In this case, the SmartResponse was running with SYSTEM privileges (from which we know that the System Monitor Agent involved is running under the LocalSystem Account), and the MachinePolicy is set to “Restricted.” This means a Group Policy Object is in place controlling the PowerShell Execution Policy, and that no regular scripts can be launched.

Consequently, we can deduce that this host will not currently run PowerShell Scripts (and by extension not run PowerShell Script based SmartResponse plug-ins). However, it could run other SmartResponse plug-ins that were not using PowerShell and would run them under the LocalSystem account.

The logic within this script can be used in future SmartResponse plug-ins to validate that they will actually have appropriate rights to perform the actions they are supposed to take.

The Benefit

This is a quick and easy solution to how we find out whether standard PowerShell-based SmartResponse will execute on a specific target System Monitor Agent Host, and if so, what user context will be used. And we can do it all without leaving the LogRhythm console.

More From Andrew Hollister

Tracking Group Policy Changes: Part 3

Detecting Rogue Process in the Service Session

Unauthorized Use of Windows Administration Tools Use Case

SmartResponse Shell

Adding Items to a LogRhythm List vis SmartResponse Plug-ins