A. Power Response Features - Asymmetric-InfoSec/Power-Response GitHub Wiki

These are some of the core features built into the Power-Response framework. Each feature was implemented to improve ease of data collection, standardization, and accountability of actions during incident response.

Menu Style Navigation

Power-Response uses a menu-based selection system to reduce the amount of typing required to execute commands against a remote machine during the data collection phase of incident response. The drive for a menu based system came from two experiences, 1) manual typing in or copy and pasting commands into a console window during IR and 2) creating all encompassing scripts to collect data during incidents. Both methods work, but neither are ideal. Manual typing is manual typing and mistakes are made. Larger, all encompassing scripts are great, but are not very flexible.

The Power-Response menu system solves those problems by allowing incident responders to choose what data they collect and limiting the amount of typing required (outside of parameter setting). This provides a fast and efficient method of choosing what data to collect in a quick and easy way.

Persistent Parameters

As mentioned above, a lot of typing is kind of a drag. When you start a data collection effort, you will need to enter the relevant parameters, which in most cases means entering the machine or machines that you will be collecting data from. Once you parameters are set, the Power-Response framework will maintain those parameters and bring them from plugin to plugin.

Less typing for the win.

Fast and Scalable Data Collection

Power-Response is built on PowerShell remoting and the amazing capabilities that it offers. All plugins utilize PowerShell remoting to collect data from remote machines in a fast and secure way. There are two different plugin types that utilize PS Remoting in a slightly different way:

1. Collect Plugins

These are the plugins that start with Collect. These plugins use PS Remoting at the framework level and the framework is responsible for initiating and maintaining the PS Remoting sessions simultaneously. This provides very fast and efficient data collection. These plugins are used for collecting PowerShell native data only (no artifacts) from remote machines and are not used for retrieving files or deploying binaries to remote systems. These types of plugins are suitable for running against hundreds or thousands of hosts at once, however, make sure you test in your environment before doing this! See the section on Customizing Power-Response to see how you can use the config file to tune your PS Remoting capabilities.

2. Retrieve Plugins

These are the plugins that start with Retrieve. These plugins use PS Remoting as well, however, the framework is only responsible for initiating and terminating the PS Session. The plugin in responsible for using the session to accomplish the goals set in the plugin. This provides a slightly slower (we still perform parallel processing where possible), but still quick and efficient, data collection capability. This design choice was implemented to give plugin creators that capability to be flexible with how they deploy binaries and retrieve items from remote machines. These plugin types are suitable to run against a fairly high number of hosts in one execution, however, make sure you test in your environment before running against a very high volume of hosts. See the section on Customizing Power-Response to see how you can use the config file to tune your PS Remoting capabilities.

Note: by default, Power-Response will only run a Retrieve plugin once per day for a specific host. However, you can utilize the Forece parameter to force the collection of data, if desired.

3. Analyze Plugins

These are the plugins that start with Analyze. These plugins are meant to be paired with a Collect or Retrieve plugin to perform analysis on the data collected. By default, the Power-Response framework will run the corresponding Analysis plugin automatically and output the results for review.

4. Triage Plugins

Triage plugins give analysts the ability to run multiple plugins with the same execution. Triage plugins improve the efficiency of collecting data from machines.

5. Hunt Plugins

These plugins start with Hunt and are for threat hunting using Power-Response plugins. Data is collected from a high volume of machines (while letting PowerShell remoting broker all of the connections) and then the data is stacked and analyzed to discover anomalous indicators of compromise that can be used to initiate the response effort. These plugins can also help find evil when invoking these plugins against a high number of known infected machines.

These plugins are a lot like the Scope plugins below but are meant to find unknown threats and indicators in the environment.

6. Scope Plugins

These plugins start with Scope and allow analysts to take a set of known IOCs and perform a sweep to identify additional hosts that are impacted by the same indicators. These work very similar to hunt plugins, but are operating based on a known set of indicators and provide data on which hosts are impacted. If hunting with a known set of indicators, these plugins work best.

7. Eradicate Plugins

These plugins start with Eradicate and allow analysts to eradicate and remediate threats in an environment. ####WARNING####: Use with caution. Make sure you know exactly what you are going to be eradicating before you take any action. These plugins can help analysts get to remove a threat actor from an environment, and, in some cases, clean machines to an acceptable level to resume normal operations. Remember to consider your OPSEC and IR policies before using these plugins.

Consolidated and Standardized Output

Power-Response takes all output from plugins and stores it in a standardized and consistent manner. Analysts can specify a specific output path if desired (see the Customizing Power-Response section to determine how to do this). Where ever the output path is, Power-Response will place all of the data collected into the output directory and sort it based on host and plugin type. Each individual Power-Response output file includes a UTC timestamp and the name of the plugin that the data was collected for.

Power-Response also consolidates data into a single XLSX workbook with multiple sheets for a one stop review capability. All plugin data is captured here for ease of analysis and review while being able to highlight and manipulate as necessary. One note, XLSX spreadsheets are not protected with read-only attributes like CSVs, so if data integrity is important, make sure that at least one other output type is specified (CSV or XML).

Data is provided in CSV and consolidated XLSX format by default although this can be customized as well to include any combination of CSV, XLSX, and XML.

Data Integrity

Every piece of data that is collected from Power-Response is hashed with SHA-256 by default (this can be changed to MD5 if desired). Additionally, output files are converted to read-only so that cannot be easily, or mistakenly, edited. If your incident response turns into something that is more legal based, this will hopefully give you a starting point for showing the integrity of the data collected.

Logging and Accountability of Actions

Power-Response logs every plugin execution and includes information on user that executed the plugin, the parameters that were used, the time it was completed, and the hash of the data that was collected as well. This log also includes any errors that you may have received during the plugin execution as well, although we do try to make sure you get relevant errors at the console as well. This level of logging is helpful when you are piecing together the data collection timeline during lessons learned or while you are writing your after action report.