Empire

Empire Post-Exploitation Framework: A Practical Guide

Empire is a post-exploitation framework written in Python that allows red teams to run a command and control server, stage agents on target systems, and execute modules from there. It was originally built by Caleb Smith and has gone through a few major revisions. The modern iteration is still called Empire but it has shifted away from being exclusively PowerShell-dependent. You can grab the current source code from GitHub at https://github.com/BC-SECURITY/Empire. I cloned it a while back and started using it to understand how C2 infrastructure actually works on the ground. When you first boot Empire, you get a listener, a stager generator, and a module library. The workflow is straightforward in theory: spin up a listener, generate a stager that the listener knows how to accept, deploy that stager to a target, and once the agent checks back in, run modules against it. Most people stop at that level because the default help text and tutorials never push past it. The thing nobody tells you is that the listener and stager need to talk the same protocol version or the connection drops silently without any useful error message. I ran into this a couple of times during a test engagement. I had an HTTPS listener on port 443 generating fine, but every stager I sent back to it would fail at the initial handshake. Turns out my server was hitting an outdated certificate validation path. The workaround was simple enough after I found it: instead of letting Empire generate a self-signed cert automatically, I pulled in a real certificate from the company I was testing with and pointed the listener at it using the --cert-path option. That single change fixed the handshake failures across all agent versions.

Setting Up and Starting the Server

Clone the repo, run the setup script, and it will prompt you for basic configuration. You typically need Python 3.8 or newer, and the framework will install its own dependencies. Once setup finishes, launching the server is just a matter of running the empire binary. The console greets you with a empire> prompt. From there you configure listeners, generate stagings, and deploy modules. The list of listeners shows what transport options are available. HTTPS, HTTP, DNS, and SMB are the main ones you will encounter in the field. Each has tradeoffs. DNS listeners are slower and harder to debug. SMB is noisy on most networks and tends to flag SIEM alerts immediately. HTTPS remains the standard for a reason.

Generating and Deploying a Stager

After creating a listener, you generate a stager from it. Empire produces different stager types depending on the platform. On Windows the traditional approach has been PowerShell, though the newer Python-based stagers are gaining traction because they bypass a lot of the legacy AMSI blocks that catch older PowerShell payloads. I prefer using the Python stagers now because they tend to stay on disk shorter and leave less trace in event logs. Deployment varies wildly depending on your access to the target. If you have a shell, you can just drop the payload and run it. If you only have user-level access, you are working with whatever delivery mechanism your testing rules allow. Phishing templates, document macros, or USB-based staging are the common paths people use. The framework does not care how the stager gets onto the machine. It only cares that the stager eventually reaches out to your listener.

Empire Agent Management

Once an agent checks in, you can see it listed under the agents command. Each agent gets a unique name and a status field. You switch to an agent with the useagent command and start issuing tasks. The task list is where most of your time goes. You check permissions, enumerate the network, move laterally, harvest credentials, and so on. The module library covers a lot of ground but not everything you will need. One thing beginners miss is that stale agents do not automatically time out the way you might expect. An agent marked as offline may still be running in the background, and issuing tasks to it will just sit in a queue until the server's internal timeout fires. I spent maybe thirty minutes debugging why a task would not execute before I realized the agent was simply unreachable due to a VPN reconnection. Checking the lastseen timestamp and manually removing phantom agents keeps things clean.

Running Common Operations

Here are a few modules that come up repeatedly in practice. Network enumeration uses modules like enum/privilege_info and enum/local_admin_search to map what an agent can reach. You typically run these right after initial access to understand your foothold. Credential harvesting includes the well-known credentials/gpp and credentials/mimikatz modules. Mimikatz modules in Empire require a staged download if you do not already have them on the target. The download-and-execute pattern is built into the framework, so you do not need to craft manual downloaders.

Lateral movement relies on modules that can pass hashes or credentials to remote systems. Empire bundles several approaches but the most reliable is often launching a new agent on the pivoted host through WMI or PSExec rather than trying to reuse an existing token. The new agent gives you a clean session with fresh permissions.

Known Limitations and Where It Breaks

Empire is not a magic bullet. There are real constraints that show up quickly if you use it seriously. First, the framework is heavy. A full Empire deployment with multiple listeners and active agents can consume noticeable memory and CPU on the C2 server. If you are running it on a modest VPS, expect sluggish response times once you have more than a handful of concurrent agents. Second, detection is a persistent problem. Modern endpoint solutions flag Empire's default PowerShell stagers very reliably. Even the newer Python stagers get caught by behavioral detection if you run the same module set too many times. I had a customer who ran the standard credential modules across a test environment and every endpoint triggered an alert within minutes. The workaround was splitting tasks across multiple C2 servers with different listener configs and staggering the timing between module runs. It added work but it also exposed a gap in their monitoring that most quick tests would have missed.

Third, the module system assumes a certain level of target consistency. If your environment runs patched systems, custom security configurations, or nonstandard OS builds, a lot of built-in modules will return errors or do nothing. You end up falling back to manual commands rather than relying on the framework's abstraction layer.

When to Use Something Else

If your goal is purely offensive tooling inside a controlled lab, Empire is fine. If you need something lighter, more customizable, or easier to integrate into automated pipelines, frameworks like Sliver or Covenant exist and handle some of the same problems differently. Sliver in particular ships with better support for Go-based agents and has a cleaner API for scripting. I switched to Sliver for most of my routine engagements after about six months with Empire. Empire still has a place in my toolkit for specific module sets and for legacy engagements where the team already has familiarity with it. The core lesson from working with this framework is that the value is not in the download and install. It is in understanding how the C2 channel behaves under different network conditions, how your stager selection affects detection surface, and how to structure your task flow so that agent downtime does not cascade into a failed engagement. Everything else is just reading the documentation and running the commands.