Dissecting powershell attacks

There is an app commandlet for that

Allegedly dubbed as Microsoft’s post-exploitation language powershell is Microsoft attempt to provide good command-line interface for administrators, developers and power users. Despite being 8 years old it only recently started getting widespread adoption with enterprises moving on to Windows 7 and 2008 environments.

There is also increased use of powershell from APT actors, malware writers and red teamers alike.

Why is that?

Well, powershell is incredibly powerful, installed by default and trusted application. It can do almost anything in Windows environment. What’s not to like?

It is increasingly abused for payload delivery, lateral movement, persistence by attackers.

Here is some facts:

  • Installed by default as part of OS
  • Provide remote shell capability like SSH called Powershell Remoting
  • Remoting capability enabled by default in Server 2012
  • Powershell v5 will have built in ssh client and server
  • Full .NET Framework access
  • Win32 API and native code access
  • Can access registry, files, WMI, change settings etc.
  • Can access and manage most OS components like services and tasks
  • AVs suck at detecting powershell scripts
  • Can reflectively inject code
  • Don’t touch disk most of the time
  • Leave barely any forensics evidence
  • Encrypted network traffic

Sounds good, huh?

Getting offensive

Recently there is also was a surge in various offensive frameworks that use powershell, the most notable one is an Empire – http://www.powershellempire.com/

It is essentially attempt to create metasploit like environment with powershell based agent instead of classic meterpreter.

I won’t go into details about this, you can play with it yourself, but i will be using it as an example. Needless to say it is very promising and powerful and we as defenders need to be prepared for that.

Since then most other common red team frameworks include powershell based payloads including metasploit, SET, Cobalt Strike among others.

Ask a blue team

So what can we do as defenders to counter that?

In terms of security powershell is not offering much – there is a concept of ExecutionPolicy which restrict what kind of scripts can be run. It won’t allow user to run a script by double clicking it, but as often with Microsoft powershell have a built-in bypass of this by invoking powershell.exe with -ExecutionPolicy Bypass command-line option, so it’s effectively cancel itself out. You can also sign scripts just like executables, but it also depends on ExecutionPolicy and most people probably won’t bother with it for custom scripts.

For more information about ExecutionPolicy read excellent Carlos Perez post here – http://www.darkoperator.com/blog/2013/3/5/powershell-basics-execution-policy-part-1.html#

Also check this for multiple ways to bypass it – https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/

More interesting approach would be to leverage AppLocker Script blocking feature to whitelist only certain scripts.

Moving on to detection, the most important step is to enable extended powershell logging.

Unfortunately it will require some patch wrangling since by default powershell 2.0 which is installed in windows 7 and 2008 R2 server is not allowing this. So you need to upgrade to at least powershell 3.0 or later to have an ability to enable extended logging. Look for Windows Management Framework package(KB2819745), you need to install this package manually.

What this means however is that most environments you will encounter will not have an extended logging ability configured and you will have very few forensics artifacs to go around.

So, getting back to business, what we specifically looking for is a Module Logging option located in group policy settings under

Computer Configuration → Policy → Administrative Templates → Windows Components → Windows Powershell


This logging option allows you to get a detailed information about what commadlets was run as well as output of commandlets, which is absolutely great. Plus you will have full source code for scripts, so even if attacker will delete them later you will always have a sample in logs. Unfortunately logging is really extensive and will generate a lot of events, so you will need to ship this log off the machines somewhere else or they will be quickly overwritten. Due to the sheer amount of events it is also hard to sift through them.

Here is snippet from log with simple Get-Service command generate 4 events



Here is after playing for a few minutes with Empire:


As you can see there is 2406 events generated. This is after few minutes running various modules.

There is also alternative ways to get information about what was run as mentioned in Mandiant whitepaper, for example via modified global profile. But it is trivial to bypass by invoking powershell with -NoProfile option, so I won’t cover it as it is not a reliable way.

Detecting bad stuff.

So, how do we detect bad stuff?

If powershell is not used in your environment – look for any signs of powershell usage, such as Prefetch files, powershell processes, shim cache entries of powershell etc. Also look for wsmprovhost process in addition to powershell.

Another option would be monitoring for a new processes that run powershell with -enc option, since there is not much legitimate usage of encoded scripts that I know of, this will be highly suspicious. On the other hand every malicious payload I saw was in form of base64 encoded script.


Powershell Empire payload

You can also use other indicators for this like -NoP or -NoProfile option, -ExecutionPolicy Bypass and -W Hidden. But looking for -enc option will be the most consistent indicator. This obviously require CommandLine option logging.

Yet another option will be looking for downloading functionality.

In terms of logged payload – there will be all kinds of stuff, but what I find the most common is downloading functionality as most powershell payloads is staging. This really depends on your environment, but looking for .NET WebClient API is a good start.


Powershell Empire Stage downloading

Next I would look for any calls to .NET API for native code such as Add-Type commandlet and calls to System.Reflection and System.Runspace.InteropServices namespaces as well as any calls to external DLLs(look for common system DLLs names like kernel32.dll, common functions like LoadLibraryA as well as DLLImport keyword). Again this would depend on your environment but looking for native code calls is an easy way to spot various malware and hacking tools like Invoke-mimikatz that rely on reflective injection for stealth.


Empire PowerDump module

Yet another one will be looking for common strings associated with tools such as Mimkatz or Empire. You can simply search for mimikatz and empire strings to check for this, but I am not a big fan of this since you can fairly easy change this. You can catch some lazy pentesters though.


Invoke-Mimikatz output

Yet another signs of malicious powershell would be usage of FromBase64String function as attackers often store encoded code in base64 form or pass data in encoded form. Of course use of base64 is not necessary malicious but a lot of offensive powershell tools use base64 making it easy to spot looking for this function. Just try searching github for this string and you will find a lot of offensive powershell tools.


Github search results for Base64 function


Powershell provides versatile and powerful trusted environment that attackers increasingly abuse to stay undetected. Unfortunately Microsoft wasn’t making it easy to audit powershell execution until much later and Windows 7 and 2008 Server being the most widely deployed in enterprise we will be stuck only to couple of artifacts for a while.

I would like to thank guys from Mandiant for sharing their great research on powershell attacks. Check out their paper linked in reference section for more information.

But it is not all gloom here – blue team can leverage the all powerful powershell for incident response!

Check out this great project – https://github.com/davehull/Kansa












  1. Jeffrey Snover · · Reply

    This is a great write up!

    Many of the issues you addressed here are dealt with in PowerShell V5. I would love to hear your opinion about how we did on that and whether there are additional things we should be doing to better protect our customers and their environments. We are passionate about getting this right. Lee Holmes has written a blog detailing the V5 Security improvements here http://blogs.msdn.com/b/powershell/archive/2015/06/09/powershell-the-blue-team.aspx


    Jeffrey Snover
    MSFT Technical Fellow


    1. Hey Jeffrey!

      I am definitely like changes in v5, especially the Constrained mode!
      However it is not clear how granular it is, can you allow some .net apis while restricting others?
      Gotta play with it myself.
      In terms of improving, nothing immediately jumps to mind considering v5 changes, but i will keep you in mind when i think of something.
      The only problem right now is that most environments stuck with v2 and you can’t even log with that leaving powershell completely undetectable.
      I would really appreciate if Microsoft raise awareness and promote upgrading powershell to it’s customers.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: