Detecting and Defending against PowerShell Shells

So much of our industry focuses at Red Team P0wnage.  I read a retweet by my Con 'son' @Ben0xA last week on PowerShell Shells by 'Lab of a Penetration Tester' Blog Nikhil Mittal @Nikhil_Mitt.  Nikhil did a week of PowerShell Shells on his Blog found at:

• Labofapenetrationtester - Week of PowerShell Shells

Nikhil did a great five days of PowerShell Shell examples of different types. Here are the five PowerShell Shells Nikhil reported on:

• Day 1 - Interactive PowerShell shells over TCP
• Day 2 - Interactive PowerShell shells over UDP 
• Day 3 - Interactive PowerShell shells over HTTP/HTTPS
• Day 4 - Interactive PowerShell shells with WMI
• Day 5 - Interactive PowerShell shells over ICMP and DNS

This is a perfect exercise for Blue Teamer's as more and more malware is trying to use PowerShell and by default, Windows has terrible default logging to detect PowerShell use or misuse.  PowerShell provides malwarians a way to persist their backdoors without having to leave a malware payload behind on disk that us defenders may be able to find.  This method is also used by MetaSploit and the 'Social Engineering Toolkit' (SET) pen testing tools.

The post exploitation kit known as PowerShell is included in every newer version of Windows and being used more an more by administrators, InfoSec pros and yes, the malwarian Hackers since it is so powerful and already on the system reducing the need for malware files to remain behind and potentially get detected.

The week of PowerShell Shells is interesting in that you can try the Shells in the five posts Nikhil created as he provided great examples and sample code and scripts.  This is kewl in that you can try them and for those of us on the Blue Team side, figure out what we would do to detect this type of attack.  If you are like me, you use these types of Red Team Hackery posts to test, validate and improve your defenses.

So what can we do to defend against PowerShell P0wnage?  A lot actually, but you do have some configuration to do which I have already discussed in a previous post, but let's take a direct look at one of the the PowerShell Shells.

Here is a screen shot of the TCP PowerShell Shell I ran for the test.

As you can see the connection was successful.

So what can we detect for this type of attack ?

First off, we need to make sure your system is ready to capture the behavior so be sure you have the following items configured:

1. Advanced Auditing enabled (Win 7 and Win 2008 and later)
2. Command Line logging registry hack applied
3. Process Create - Success
4. PowerShell default profile enable enabling command line logging

You can see how to enable and configure your logs to detect these types of attacks with my info:

• PowerShell Logging - Post
• Command Line Logging - Ask a Malware Archaeologist - Presentation
• Enable and Configure your logs - The Windows Logging Cheat Sheet

Just an example, here is what a netcat shell listening looks like in the logs to get us started.  EventID 4688 picks this up easily with the command line logging tweak!

Now let's take a look at what you can detect when a PowerShell Shell is executed.  There are two ways to execute PowerShell scripts, inside a PowerShell Shell and via a Command Shell.  It was not clear how this was done in Nikhil's posts so let's take a look at launching both methods and how to detect this behavior.  Also, it was not clear what the PowerShell ExecutionPolicy was set to on the system, so lets assume it is set to restricted (default) and the hacker would have to bypass this restriction.  But here is what a failed execution looks like in the logs due to the ExecutionPolicy being set to 'Restricted'.

If a hacker wants to execute PowerShell scripts and bypass any restrictions, they will need to state a bypass on the command line when launching PowerShell.  The EventID 4688 will detect this behavior and if you have command line logging enabled, catch this condition every time.  This should be a key alert that you setup as this is a clear indication someone is trying to hack you!

If the entire command was executed at the command line it would look like this in the EventID 4688 log entry.  BAM!  Got you sucka!

Monitoring for an ExecutionPolicy bypass and/or NoProfile bypass would catch someone trying to p0wn you instantly.  I recommend you monitor and alert for this as a critical Top 10 that you monitor and alert on!

Let's assume we ignore any EventID 4688 events and want to detect this using PowerShell logging.  There are two ways to do this, the first being easier to integrate into a central Log Managment solution by properly configuring the PowerShell logs to capture command line activity.  The other is to use the PowerShell Transcript logs which can be configured to capture everything executed when a PowerShell Shell is invoked.  PowerShell Transcripts are a text file usually found under the users AppData directory structure.

Let's look at EventID 500 or 501 of the 'Windows PowerShell' Log to see what the PowerShell Shell execution looks like.

As you can see we are able to catch the hackery with either a Security Log EventID 4688 or with a Windows PowerShell Log EventID 500 or 501.

Here are the details executing in the PowerShell script Nikhil provides.

You can easily see the IP and Port used, streaming information, path, byte info and encoding.  Clearly communication is taking place that shows up in the Logs if properly configured.

The second method is the PowerShell Transcript log that you can invoke in the default profile so started each time PowerShell is invoke, to either overwrite or append.  This is what the PowerShell Shell execution looks like when I was testing.

As you can see as kewl as the file-less PowerShell Shell hacking may be, it is clearly detectable and you MUST look for this behavior in your logs as it is getting used much more in malware I am seeing today.  Within the last month I dissected a malware sample I received that was a Microsoft Word document that executed a VB script launching a command shell, calling CScript script which then launch a PowerShell Shell backdoor. Being a Blue Team Defender I REALLY wish the Red Team Breakers and Hackers would include the Blue Team 'How To Defend' against the breaking and hackery they discuss...  Instead, us Blue Teamers must digest these types of posts and create a counter-point post on how to defend against these attacks.  

Happy Hunting!

#InfoSec #PowerShell #Defend