Customizing Powershell Empire to Avoid Detection

June 17, 2017 admin Research

Powershell Empire is a very powerful post-exploitation framework for Windows environments. The tool has been gaining
popularity since its release in 2015. As more red teams and malicious threat actors utilize the tool, more detection is being
developed to identify the use of Empire on the network. This post will show some customizations that change the network traffic
of Empire in order to avoid detection.
Before we get into what changes can be made to alter Empire traffic, it is important to understand the Empire staging process
and what data is in the network traffic at each stage.
For this example, we will be using the Launcher stager which is a Powershell one-liner that will perform an IEX on a file hosted
on Empire’s web server in order to pull down the stage 2 payload. More detailed information about the staging process can be
found on the Empire website at: https://www.powershellempire.com/
Most common network intrusion devices will look to identify common components in the staging process. Those items can
include the user agent string, the name of the files being accessed, the protocol and the port number. There will be different
artifacts at different stages of the staging process that should be changed. We will first take a look at custom profiles and how to
use them while creating a listener.
There are several demo profiles included in the data/profiles directory. The format of an Empire profile is much simpler than a
profile for Cobalt Strike. The profiles for Empire allow you to change the payload file name, the user agent string as well as
headers in the communication. Creating a custom profile can be used to emulate a particular threat actor to test your defenses or
customize the tool to avoid detection. Our goal is the latter so we will be creating a profile that will attempt to look like normal
user activity. Depending on the attack infrastructure you have setup and the domain name that you are using, you could
potentially make your traffic look like traffic analytics, browsing activity or connectivity to a streaming service.
By showing information while setting up a listener, you can see the default profile that is used by Empire.

The default profile has a set of default file names which include:
/admin/get.php
/news.asp
/login/process.jsp
There are the file names that the Empire agent will communicate with via GET and POST requests to check for tasks and upload
data.
We will simply replace these files with new file names in our custom profile.
We will also change the UAS in our custom profile. If you have already performed your recon, you may have a better idea of
what browsers are deployed in the target environment. The goal here is to avoid detection so setting our C2 to use the same UAS
as most traffic in the environment is another way to blend in to the thousands of requests going across the wire.
For this example we are going to set the UAS as “Mozilla/5.0 (profileUAS)”. This is so when we look at the traffic we will be
able to see where our custom UAS is being utilized.
This is the custom profile we have so far:
“/wp_includes/test1.php|Mozilla/5.0 (profileUAS)|Accept:*/*”
This will use the file /wp_includes/test1.php and a UAS of Mozilla/5.0 (profileUAS)
When creating our Empire listener, we will set that in the DefaultProfile option. Rather than changing the values of the default
profile while creating the listener, you can make the changes in setup_database.py before creating the empire database. This will
replace the default value so all listeners you create will have your custom profile by default.
Lets fire off our payload and get a shell to take a look at the traffic.
We execute our payload on the victim machine and the first request back to our attacking box is the following:

As you can see, this does not have our custom file name or our custom UAS.
The second request is the following POST request:

Again, we are seeing default values for the file names and UAS rather than our custom data.
The next request is the stage 2 request which again uses default data.
Finally once the actual C2 traffic starts, we see our custom data in the network traffic: