Empire is a popular open source post-exploitation framework. The framework can very roughly be broken down into two parts: agents and listeners. An agent is an implant that lives on the victim’s computer. A listener resides on the attacker’s command and control server and handles communication with the agent. A lot of work has gone into making agents difficult to find. Less has been done to hide listeners. In this write up, I point out mistakes that have been made in Empire’s HTTP listeners and then look at some listeners found in the wild.

Empire has five different HTTP-based listeners. From a network point of view, they’re similar in that a request to “/” results in a 404 Not Found error.

Creating the Shodan Filter

One of the important things to know about Empire is that it’s built on top of Flask. Flask uses Werkzeug for some of its HTTP functionality. Empire’s dependency on Werkzeug is immediately evident in the HTTP response because the error message, “The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again” is hardcoded in Werkzeug.

Are Those Really Empire Listeners?

The logic behind the Shodan filter is fairly sound, but cautious readers should be asking themselves, “How can you be sure all of the results are Empire listeners?” You can’t be sure. Obviously, non-Empire servers could have the exact same HTTP banner. However, there is one more mistake in Empire that will allow us to confirm if a server is an Empire listener or not.

On a normal server, “/” often maps to index.html, index.php, index.asp, etc. So it’s pretty odd if you request “/” and get a 404 but request “/index.html” and get a 200. Not only that, but the HTTP content for most 200 OKs is hardcoded in Empire. Using this knowledge we can verify, with very little doubt, that a server is an Empire listener.

<html><body><h1>It works!</h1><p>This is the default web page for this server.</p><p>The web server software is running but no content has been added, yet.</p></body></html>

Empire In the Wild

The Shodan filter seems to be quite accurate. Of the 282 servers listed on Shodan, I only counted one false positive and one I wasn’t sure about among the servers that are still reachable. I did find that some servers don’t serve up the default page for index.html. For example, the following is part of the Empire powershell stager implementation.

I also found it interesting that few listeners changed the default Server field from Microsoft-IIS/7.5. The following table lists the non-default Server values that I observed.

Server Value

Count

Microsoft-IIS/8.5

7

Microsoft-IIS/9.0

1

Microsoft-IIS/10.0

1

BigIP

1

Apache

1

Apache/2.4.6

1

web012

1

nginx/1.8.0

1

To my knowledge, there is no such thing as IIS 9.0. I’m pretty sure the versioning jumped from 8.5 to 10.0.

Finally, I found SSL usage in conjunction with Empire to be fairly interesting. I counted 47 self-signed certificates among the discovered servers. More intriguing to me is the amount of certificates issued by Let’s Encrypt. It’s been Let’s Encrypt’s long-standing policy to not police content and I’m certainly not going to argue against them. Especially since I don’t have sufficient information to determine if any of the servers are actually malicious. As such, I’m just going to present the data without further comment. I’ve broken the domains up into two groups: domains verified to have Empire HTTP listeners and unreachable servers.

Conclusion

Little mistakes add up. Not just for the blue team but for the red team, too. Take advantage of your adversaries’ mistakes when you can. In this case, you can use plugin 99592 to help find any Empire HTTP listeners in your environment.

Our website uses cookies. By continuing to browse the website you are agreeing to our use of cookies. For more information on how we use cookies and how you can disable them, please read our Privacy Policy.