Rome Didn’t Fall in a Day: Building A Resilient Empire C2, Part One

empire_logo_black4[Originally posted at ImplicitDeny]

In this two-part series, we will walk through building an infrastructure to host your
command and control (C2). At the end of this series, you should have at least two servers ready for your engagement. One server will be a simple web server to host your stagers, and the other will be an Empire C2. Note, this can be expanded to have multiple C2 servers as may be necessary for long-term persistence.

From a tradecraft and evasion perspective, it makes sense to configure some agents (compromised machines) to call back to different C2 servers. Rapheal Mudge has an excellent post on this tradecraft perspective.

Here in Part One, we will install and configure our servers. In Part Two, we will publish our stagers, setup Empire listeners, and use an Empire agent to give ourselves a Metasploit shell.


Lets quickly talk about tradecraft, and why we want more than one server for our C2 infrastructure, especially if we are going against an active incident response (IR). Ideally, we would have three or more servers:

  1. Stager host for our one-liners which download the payload/agent
  2. Payload/agent host
  3. C2 host(s), or proxy-redirectors to a single C2 host
    • Some agents call back infrequently, and are long-haul hosts. Something like 24 hours might be appropriate. If these are calling back to an entirely separate domain and Empire listener, it can be incredibly difficult for IR to discover these as they only check in once every 24 hours. Further, should your other C2 domains get burned, you’ll likely have these to re-inject back into the network.
    • Other agents call back frequently and can be used for more real-time discovery and attack. Twice as bright, half as long. These may have a higher risk of discovery, but with a resilient infrastructure, there are backup plans for the backup plans.

Why this setup? If you’re going against IR, there is a possibility of any one or more of these elements getting blocked. For instance, a clever user may recognize your phishing attempt and alert IT. IT will then likely block your mail server and stager host after some investigation. Or, IR may notice your C2 traffic and block the domains associated with it. For these reasons and more we want to separate out as many elements of our infrastructure as possible so that the exposure of one element does not expose the entire operation.


  • You know how to purchase and configure a domain
  • You have basic knowledge of Linux
  • You have purchased at least one or more domains
  • You can publish a simple web site

For the server infrastructure, you can use a VPS like DigitalOceanAWS or any others, or even on-premises hardware. I’d recommend reading the terms of service before deciding on your host of choice.

Web Server

The web server is where we will store our stagers. Stagers, in this case, are short PowerShell scripts that download the full remote access agent. They’re designed to be small, universal, and readily bypass content filters. I like to have my web site look even moderately legitimate for incident responders who may see the URL in their web filter. Some web filters don’t always show the full URL, and only show the domain and sometimes subdomains in the logs. Regardless, communication with a resolvable domain is always less suspicious than an IP address.

Domain1, setup a basic web server. The basic steps I follow are these captured from the many tutorials on the internet on web server first-steps:

  • Install and configure the UFW firewall on Ubuntu (Allow 22, 80, 443)
  • Configure SSH to disable password logins (pubkey only)
  • Install fail2ban
  • Install and configure Apache web server
  • Get an SSL cert from LetsEncrypt for our domain and server
  • Build a simple web site, HTML only using a free template from one of the million resources out there
  • Create a folder for your stagers in the web root
  • At the DNS, point domain1 to your new web server

Command & Control

I’ve used a fairly minimal server image for my C2. Either the $5/mo or $10/mo image on DigitalOcean should fit your needs depending on how many agents you expect to be running and how busy you expect them to be. In an ideal world, you will have 2+ C2 servers each with their own domain name. One for your long-haul agents, and the other for your rapid-callback agents. This can also be accomplished with a redirector or proxy, and using a single C2 server.

Once your server or droplet is up and running, perform the same basic server install steps as you did above. This generally includes installing your SSH key, install and configure UFW (allow 22, 80, 443), install fail2ban, and install Git:

$ sudo apt-get install git

Get a copy of Empire and run the install script:

$ cd
$ git clone
$ cd Empire/setup
$ sudo ./

Finally, configure domain2 to point at the IP of your C2 server.

We will configure Empire to listen on port 443 with its own SSL certificate in Part Two of this article, available soon.

One thought on “Rome Didn’t Fall in a Day: Building A Resilient Empire C2, Part One

  1. Pingback: Rome Didn’t Fall in a Day: Building A Resilient Empire C2, Part Two – bneg

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s