Unmanaged PowerShell Binaries and Endpoint Protection 

Optiv recently completed our 2017 endpoint security solution evaluation. The primary focus of the evaluation was to test the solutions’ efficacy across the cyber kill chain. Surprisingly, we discovered a high failure rate in detecting two custom binaries that were created for the evaluation as malicious and the commands executed through them. Both of these binaries incorporated the concept of unmanaged PowerShell. 

Unmanaged PowerShell is a way of executing PowerShell commands and scriptblocks without ever using PowerShell.exe or PowerShell_ISE.exe. The concept was introduced to me by Ben Ten at the Raleigh B-Sides Conference in 2015. Ben, an industry expert, explained that PowerShell is only the executable that allows you to interact with the .Net Framework and that any binary could be created to do the same thing. This concept is a few years old and there has been interesting research done by several people including Ben, Jared Haight and others on the topic. While unmanaged PowerShell isn’t the newest concept, it still proved to be an effective method of obtaining a shell and performing post execution actions on endpoints protected by enterprise-class security products. 

My goal was to create an unassuming binary that applied the unmanaged PowerShell concept and returned a reverse shell. I used Ben’s AwesomerShell project on GitHub as a reference. AwesomerShell’s proof of concept code creates an executable file that uses the System.Management.Automation dll. This program provides an interactive command window that accepts PowerShell commands without ever running powershell.exe. The code was modified in an attempt to make the binary look as benign as possible. The payload was a command to download Nikhil SamratAshok Mittal’s Invoke-PowerShellTcp in memory and pass the arguments to connect to our C2 server. 

Figure 1 – Creating the reverse shell connection 

Figure 2 – Final code 

OUTLOOK was used as the assembly name and default name space.  

Figure 3 – Changing the assembly name and default namespace  

The Outlook icon and Outlook 2013’s assembly information were also copied. Here, the intention was to fool or at least confuse a user if Task Manger was opened and the process details were viewed.  

Figure 4 – Changing the assembly information to match Microsoft Outlook  

The file was compiled and signed with a fake certificate. There are newer techniques that can be used to copy legitimate certificates. The real Outlook application would have a trusted sha1 and sha256 signature and would not be timestamped by Symantec. Some endpoint security products only look to see if a file contains a digital signature, instead of performing signature validation.  

Figure 5 – Details of the applied fake digital signature

During testing, the binary OUTLOOK.exe was delivered in an assumed phishing scenario and when executed on an endpoint it connects back to our C2 server. 

Figure 6 – Image of the malicious OUTLOOK file a user’s desktop

The attacker now has a reverse shell running under OUTLOOK.exe with the ability to download additional scripts into memory and run any commands that PowerShell.exe can execute. The lack of detection for the initial execution isn’t that impressive because the malware is only making a TCP connection. However, Optiv discovered that some endpoint security products only detect and log commands run from PowerShell.exe, not the malicious OUTLOOK executable. Unmanaged PowerShell sessions can be a way to execute PowerShell commands while bypassing these detections and preventions.

Figure 7 – Connection back from the victim with example PowerShell command

Figure 8 – Note, PowerShell.exe is not running on the victim

There are several ways to detect this activity in your environment. If possible, prevent unknown binaries from running. Organizations should also look at the logging options offered in PowerShell v5. PowerShell’s ScriptBlock logging is a way to capture cli commands that are used in some unmanaged PowerShell sessions.    

There are many different ways to execute this concept. If you are interested, I suggest you take a look at the research being done by Casey Smith @SubteE on Twitter. Stay tuned for Unmanaged PowerShell Binaries Part 2, which explains how to create a similar binary with an Empire launcher as the payload and Invoke-Obfuscation for detection bypass.