Unmanaged PowerShell Binaries and Endpoint Protection – Part 2

In my last blog post, I discussed the process of creating a binary that contained a reverse PowerShell payload, only it did not leverage PowerShell.exe or PowerShell_ISE.exe. The binary talked directly to the .NET Framework. This binary proved very successful in bypassing endpoint vendors in Optiv’s 2017 endpoint research. In this blog I will build on the previous post by introducing obfuscation to the code, which will make detection more difficult. The new binary will contain a PowerShell Empire stager, it will be “signed,” and it will be placed on the OS where an attacker can achieve userland persistence. 

In order to get started, an Empire listener needs to be active, and a stager must be created for that listener. Using the multi/launcher stager and turning the BASE64 option to False, we receive the output below.

Figure 1 – PowerShell Empire stager output

The stager code is copied over to Visual Studio. Note, I removed a few of the ScriptBlock logging commands because the commands triggered detections during testing. The stager script is broken up into smaller, more manageable segments.

Figure 2 – PowerShell Empire stager in Visual Studio

If the stager code above was used in the binary, there is a high chance that endpoint vendors would detect the file as malicious. The endpoint industry is slowly starting to tackle the PowerShell problem, which is very difficult to solve because of PowerShell’s flexibility. The stager code needs to be changed to avoid detection but still needs to be readable by the .NET Framework. 

Daniel Bohannon, a senior applied security researcher at Mandiant, released an incredibly useful tool to obfuscate PowerShell commands and scripts called Invoke-Obfuscation. Written in PowerShell, Invoke-Obfuscation allows us to change the syntax of a PowerShell command through concatenating, whitespaces, reverse ordering, encoding and a few other methods.

Figure 3 – Invoke-Obfuscation

Invoke-Obfuscation is used to obfuscate each of the smaller stager commands. Line by line the commands were copied into Invoke-Obfuscation and encoded in either ASCII, Hex, Octal, Binary, AES or BXOR.

Figure 4 - Example of stager command encoded with Invoke-Obfuscation

Obfuscating a stager within Empire is now built in but must be set to “True” in the settings menu prior to creating the stager code. Similarly, commands can be obfuscated within Empire and also must be set to “True” in the stager settings. The Optiv research team discovered that the output of some obfuscated commands contained double quotes and needed to be replaced with single quotes in order for C# to interpret the command properly.

Figure 5 - PowerShell Empire multi/launcher stager settings

After each of the smaller segments from Figure 2 are obfuscated, the segments are inserted in the corresponding section in the Program.cs file.

Figure 6 – Program.cs file with the original commands in green and obfuscated ones in orange.

In this example, the custom application is named OneDrive. The file is signed with a fake signature designed to look like it is from Microsoft and the binary is compiled. The end result is a file that looks similar to the real Microsoft OneDrive executable.

Figure 7 – Compiled malicious OneDrive executable

Figure 8 – “Signed” file with sigtheif

But, why OneDrive? As it turns out, Microsoft OneDrive launches automatically each time a user logs in to their computer. Assuming an adversary has access to a machine, they can locate the OneDrive process, kill it and replace the binary with the malicious OneDrive file. On the next reboot, the attacker will have a persistent session under that particular user. 

Figure 9 – Locating and killing the OneDrive process on the victim host

Figure 10 – Uploading the malicious OneDrive executable to the users’ AppData\Local\Microsoft\OneDrive folder

Figure 11 – Client view of AppData\Local\Microsoft\OneDrive\OneDrive.exe

Once the machine is rebooted and the user logs back in, the attacker has a reverse shell that provides all the tools that PowerShell Empire offers. Not to mention it runs under an unmanaged PowerShell binary that looks a lot like OneDrive on the surface. 

Figure 12 - PowerShell session under our malicious OneDrive executable

There are several ways to detect this activity in your environment. If possible, prevent unknown binaries from running or perform hash verification. Organizations also should look at the logging options offered in PowerShell v5 and v6. PowerShell’s ScriptBlock logging is a way to capture CLI commands that are used in some unmanaged PowerShell sessions. If ScriptBlock logging is enabled, policies should be set to alert when it is turned off.  Monitoring network connections from OneDrive to IPs other than those used by Microsoft would be an additional way to detect malicious activity.