Empire & Tool Diversity: Integration is Key

Justin Warner
6 min readFeb 11, 2016

Since the release of PowerShell Empire at BSidesLV 2015 by Will Schroeder (@harmj0y) and myself, the project has taken off. I could not be more proud of the community of contributors and users that have rallied together to help us maintain and continue building Empire. Since the project’s release, Matt Nelson (@enigma0x3) has joined our team and has taken charge of handling the various issues that arise from time to time (many thanks to him for this uphill battle). Also, Matt Graeber (@mattifestation) is now working with us and will likely have a lot of backstage influence on the continued development AND detection/mitigation of Empire. To think of it, I have been mostly hands-off with Empire development recently… Will and Matt work at speeds that I can only envy and their vision for the tool is fantastic. This post is continuing an ongoing blog series that the Empire team is doing and will cover integration with existing toolsets, namely Metasploit and Cobalt Strike. The remainder of the series with some background and an ongoing list of series posts is kept here.

Early on we recognized that we didn’t want Empire to be an “all-purpose” agent, so we wanted to ensure that it integrated well with existing operational tools and platforms. We firmly believe that there is no single universally perfect tool- every situation demands a different perspective and each blue team likely has different training objectives (red teams take note, they are your “customer”). With unity in mind, we wanted to primarily focus our integration on easily passing sessions back and forth between Empire, Metasploit, and Cobalt Strike.

Launching Empire From Meterpreter/Beacon

The first situation we’ll dive into is the execution of an Empire agent from an existing access or during initial ‘exploitation’. We use a variety of tools during our engagements, so this is a use case we frequently run into. Tool diversity can be a major strength for any team.

ReflectiveDLL Method

My favorite method of passing access is the use of Empire’s reflective DLL. There will be an entire post on this aspect of the agent, so for the sake of this post, let’s just state that Empire has the ability to generate a Fewer-style reflective DLL launcher that does not require powershell.exe execution. It utilizes Lee Christensen’s (@tifkin_) project UnmangedPowerShell to accomplish this behavior. Sidenote: if you ever want to make your own reflective DLL, Raphael Mudge has a good post outlining the process.

I prefer the reflective method of launching Empire because it allows us to get agent execution in any process, which is beneficial for a number of reasons:

  • Less impact in process auditing scenarios
  • Use of existing user tokens and proxy settings (i.e. inject into Internet Explorer for cleaner egress)
  • Harder to recognize during initial detection methods when compared with “powershell -nop -enc” pattern

Let’s assume you have a listener configured for your standard Empire agent. First, you must generate your reflective DLL from within the Empire server. Note: you must choose the proper architecture here (Empire defaults to x64).

The “launcher.dll” file is now a reflective stager for Empire and can be used with any standard injection technique, including those built into Metasploit and Cobalt Strike.

1. Initial Exploitation

For the first case, let’s assume we want to stage Empire from a Metasploit exploit. With the DLL created, you simply specify a payload of windows/dllinject/reverse_http with any exploit module and point the DLL option for the listener to our newly created “launcher.dll”.

2. Meterpreter -> Empire

If we already have a Meterpreter agent inside the network, it would be silly to re-exploit a system/network to obtain a brand new session. In this case, you can utilize Metasploit’s post modules to obtain access via Empire. Simply load and use the windows/post/manage/reflective_dll_inject module with the PATH set to the launcher DLL.

3. Beacon -> Empire

If you are a Cobalt Strike user, the process is similar. Cobalt Strike is one of the main tools we use on engagements, and we have come to love the dllinject functionality. This operates in the same way as Metasploit’s post module. Remember to match up the architecture of the DLL you’re injecting with the architecture of the process you’re injecting into!

Launcher Method

If for some reason you are not able to perform a reflective DLL injection (AV, HIDS, exploit scenario, IR Team etc.) and you still desire Empire, there is a much easier solution. As you likely know, Empire’s stager is a very small stub of PowerShell code that is a souped-up version of the infamous “download cradle”. With this stub of code, we can create a powershell.exe one-liner to execute on any host.

For MSF, you can simply use the PowerShell encoded launcher to spawn a stager.

For Beacon, the shell command does not work as smoothly but due to the easy PowerShell integration, this is not a problem. You can generate a launcher with “Base64” set to false and wrap it inside of a function block in a file. Inside your Beacon agent, simply use powershell-import to load in your file and call the function name.

Passing to Metasploit/Cobalt Strike

The inverse of the situations above is also vital to consider. The movement from an existing Empire agent to Beacon or Meterpreter is a common workflow we use in post exploitation scenarios.

Since we built Empire’s listener architecture to be relatively flexible, we integrated a listener “type” to handle this situation for us that abstracts away some of the backend configuration. The “meter” listener exposes a set of parameters you can easily pass to the code_execution/shellcode_inject module. This works for both Meterpreter and Beacon due to the common staging protocol. Essentially, the listener is a shortcut that pre-populates the fields for certain modules. The shellcode_inject module exposes a slightly out-of-date version of PowerSploit’s Invoke-Shellcode.ps1, which allows you to execute a shellcode stager that is interoperable with both agents. Going forward, there might be some changes with this as we updatecode_execution/shellcode_inject with the new PowerSploit implementation, but we will continue to support this interoperability option for injection.

The first step in the chain is to open up a listener on Metasploit/Cobalt Strike that will handle the callback.

Next, define a new foreign listener in Empire with a “meter” type. Since the staging protocol between MSF and Beacon is identical, this foreign listener will work in both toolsets.

Once the listener is created, you can launch the shellcode_inject module and specify the created listener alias.

Conclusion

This is a small sample of the functionality built into Empire. If you are interested in using it or have questions, check out the documentation at http://www.PowerShellEmpire.com or hit us up in IRC in #psempire.

Happy Hacking!

Originally published at http://www.sixdub.net on February 11, 2016.

--

--