Why PowerShell

While there are some great tools out there for cyber threat hunting, most require some type of agent installed on the hosts or a centralized server to function effectively.  Unfortunately, host and sever configuration for many networks, especially those on DoD or other government systems is very controlled and the agents required for those tools simply can't be installed.  In those instances, cyber threat hunters must "live off the land" when collecting host data across networks.  This means we must use tools already present on hosts/servers to hunt for indicators of compromise.

Fortunately, most of the networks I deal with and many other networks are already administered using PowerShell.  This means that not only is PowerShell installed on most of the host machines, but the network is already configured to allow PowerShell commands to be remotely executed.  Since PowerShell rides on the .NET framework, there are many providers available to expose data critical to cyber threat hunting.  Additionally, PowerShell has the ability to leverage WMI so even if standard .NET classes or PowerShell's thousands of built-in cmdlets/functions don't expose the data you need, WMI probably does.

PowerShell was built to help administrators get back on the command line and automate tasks for management of network systems.  It is very well documented and supported.  Unfortunately, much of what I find online in the way of PowerShell support/examples revolve around system administration tasks and not threat hunting.  There are some unique challenges a threat hunter might have when leveraging PowerShell that a system administrator may not have.  For example, since a threat hunter is likely to be limited to whatever is installed on host systems, he or she may have to use older cmdlets or WMI if an older version of PowerShell is installed.  I have seen many cases where someone creates an amazing PowerShell script for threat hunting data collection but it doesn't function on all or some of the hosts in a network because it relies on functionality not available in older versions.  Threat hunters have to be flexible and not just rely on scripts that can't be customized for specific situations.  Additionally, threat hunters may have to work around network limitations.  Recently, I was on a network where the WinRM service was disabled on several machines.  While WinRM is necessary for standard PowerShell remoting, there is more than one way to skin a cat.  In this case we leveraged RPC using specific PowerShell cmdlets in Windows PowerShell v5.1.

This post was intended to just give you a taste of why PowerShell is an important tool for cyber threat hunting.  In future posts, I will show real-world examples and hypotheticals to illustrate how PowerShell can be leveraged for threat hunting.