Not Your Grandfather’s Empire I’ve wanted to put this blog together since returning home from DEFCON. Anytime we ran into someone who recognized our swag, they mentioned how much they loved Empire back in the day and didn’t realize it was being actively maintained. This made me reflect on all [...]
I’ve wanted to put this blog together since returning home from DEFCON. Anytime we ran into someone who recognized our swag, they mentioned how much they loved Empire back in the day and didn’t realize it was being actively maintained. This made me reflect on all the features we’ve added over the years and inspired me to write this blog.
Empire has come a long way from its humble beginnings. What started as a PowerShell-centric tool has now evolved into a multi-language, modular framework capable of much more. Let’s dive into some of the newest capabilities that make Empire a force to be reckoned with.
One of the biggest architectural changes we made in Empire was the introduction of the teamserver. In the past, Empire ran both the server and client from the same application, creating a cumbersome system to maintain.
Now, we’ve implemented a cleaner, more scalable solution. Empire uses a dedicated API to separate the server and client. This not only streamlines the overall architecture, but also allows Empire to be multiplayer.
We also switched to using MySQL as the database backend. This means you can now manage hundreds of agents simultaneously without sacrificing stability or speed (Yes, we really have seen 100s of agents run off a single instance).
We put together Starkiller a while back because Empire had a relatively unused API, and we wanted to play around with what a GUI might look like. Some tasks just lend themselves to a better experience in a GUI, and Starkiller delivers that.
We still have the command line client, but overall it’s been relatively unmaintained and will be deprecated in 6.0. Using Starkiller doesn’t mean you have to give up all the goodness the terminal provides. In fact, we reimplemented the terminal for agent interactions within Starkiller, giving you the best of both worlds. With Starkiller, you can still wield the power of Empire in a visually intuitive interface while retaining the raw terminal for seasoned (old and stubborn) users who prefer to type out commands.
One of the first areas we wanted to expand into was C#. We were already running PowerShell, so adding a task to process .NET assemblies wasn’t too much of a leap. Our vision was to have the ability to run both PowerShell and .NET assemblies all within a single framework.
At first, we explored a few options, including basing our model on Covenant. Our goal was to maintain compatibility so that any task we built for Empire could also be used in Covenant. However, as Covenant’s development stalled, we pivoted. We decided to pull out the Roslyn compiler that Covenant integrated and built our own system around it. This gave us the flexibility we needed to compile tasks in real-time against the target machine, while minimizing the need for precompiled binaries (because let’s be real, who trusts random EXEs from GitHub anyway?).
If you haven’t noticed, I haven’t been calling it “PowerShell Empire” anymore—that’s because it’s not just PowerShell. The framework has outgrown its original name.
Also known as Sharpire, the C# agent was the first modern implant added to the framework. Originally started by another developer and never integrated into the framework, we’ve been maintaining and enhancing it since then. This addition marked a significant expansion of Empire’s capabilities. With Sharpire, we can now run C# payloads seamlessly alongside PowerShell tasks. The introduction of the C# agent was a turning point in Empire’s history, pushing it away from its PowerShell roots.
At one point, I became frustrated with our Linux implant, which was essentially unused at the time. The existing codebase was based on Python 2, which was reaching end-of-life. I wanted to bring it up to Python 3, so I bit the bullet and started updating the agent code. Keeping Python 2 compatibility quickly became a nightmare. The differences in how strings and bytes are handled between Python 2 and 3 were causing too many issues, so we decided to go all-in on Python 3. Once the agent was updated, the modules came next. After all, the agent is pretty useless without the modules.
This is where we started to take Empire beyond basic TTPs (Tactics, Techniques, and Procedures). We’ve always wanted to pivot Empire into the threat emulation space since Hubble and my background is in cyber threat assessments and red teaming for the Air Force.
IronPython became a game-changer. You might have read our previous blog on IronNetInjector or our research paper, which goes into much more detail. TL;DR Turla, a nation-state actor, uses IronPython to defeat defenders by injecting .NET code in ways that defeat modern EDRs.
We built a prototype based on this technique and realized that it wasn’t far from being compatible with Empire. With a few changes to the Python 3 agent, we were able to support a Bring Your Own Interpreter (BYOI) agent à la byt3bl33d3r’s SilentTrinity. This is where things get weird—in the best possible way. You can now run PowerShell, C#, Python, and IronPython within a single framework.
Even better, this payload defeats nearly every major EDR on the market. This is partly because users haven’t fully explored and uploaded it to VirusTotal yet, but mostly because the loading process obscures detection. Everyone still defaults to the PowerShell agent, even though we’ve got so much more under the hood.
Another powerful feature we’ve added to Empire is support for Beacon Object Files (BOFs). BOFs are small, compiled programs written in C that execute directly in memory, offering a way to perform various post-exploitation tasks. In Empire, we’ve streamlined the process by allowing you to execute BOFs directly through the agent using RunOF.
Not only that, but Empire comes with a library of BOFs ready to go. For instance, we’ve included TrustedSec’s situational awareness library, nanodump, tgtdelegation, and so many more.
Plugins have been around since 2.5, but went mostly unused. Plugins allow you to scale the capability of your server without needing to understand or touch the core codebase. We have increased plugin capabilities over time, adding things like event hooks and tasks that can be written in the database.
For example, we created a plugin that could exploit EternalBlue (I know, it’s old, but reliable). Initially, we wrote the exploitation process in Python to get an Empire agent loaded remotely. Then, Metasploit released Bring Your Own Stager, making things much easier. Now, we can spin up a Metasploit instance, generate shellcode using Donut (also integrated directly into Empire), and let Metasploit handle the exploitation.
If you’ve been following our Twitter (and yes, I refuse to call it anything else), you’ll know we’ve been pushing regular updates to Empire with new abilities and fixes almost weekly. But we’re also working on something big.
Empire 6 is going to bring our first non-.NET-based agent to Windows. I decided to build it in Go for two main reasons: 1) it wasn’t too hard to learn, and 2) I liked the concept from Sliver. We always strive for community engagement with Empire and with the popularity of Sliver and Go we thought integration of Go would provide a larger opportunity for contribution and carry over of TTPs.
We’ve spent an enormous amount of time making sure our server and implants are rock-solid. We are talking stability that can run ops for weeks or even months. Stability is a huge pet peeve of ours when it comes to C2 frameworks, so we’ve made it a priority.
Empire has transformed from a simple post-exploitation framework into a cutting-edge, multi-language platform capable of handling advanced TTPs and bypassing the latest defenses. Whether it’s leveraging IronPython to emulate nation-state actors, using plugins to scale functionality, or building a Go-based agent to push boundaries, Empire continues to evolve.
Stay tuned as we continue to push the limits of post-exploitation frameworks and bring new and innovative features to Empire!
If you want to learn more about Empire, its capabilities and how to contribute continue over to the wiki. For in-depth training on how to leverage Empire in operations, check out our on-demand Empire Ops I course. It will take you on a deep dive into the upgrades we discussed here and more.
Note: All code samples shown in the post can be found in our repo here In recent years, PowerShell tradecraft has seen a drop in popularity among pentesters, red teams, ...
