Identifying Empire HTTP Listeners

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.

Perhaps that response doesn’t look interesting, but it’s enough to fingerprint an Empire HTTP listener.

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.

Punching the query title:”404 Not Found” +”Server:Wekzeug” into Shodan shows that Werkzeug very reliably serves a 404 page that is 233 bytes. This gives us a great starting point for finding Empire listeners on Shodan: title:"404 Not Found" +"Content-Length: 233" yields ~24,000 entries. We can’t use the Server field in the HTTP response because Empire allows the user to modify it.

Another important detail about Flask and Werkzeug is that they don’t support HTTP 1.1. You can actually see in the server’s response that it starts by declaring “HTTP/1.0”. However, Empire’s HTTP response contains a feature introduced in HTTP 1.1. The Cache-Control field, originally included in RFC 2068, “Hypertext Transfer Protocol -- HTTP/1.1”, was introduced into Empire in a commit to avoid caching. Empire isn’t the first or last HTTP server to backport Cache-Control, but it does help us narrow the field a bit. The Shodan filter title:"404 Not Found" +"Content-Length: 233" +"Cache-Control: no-cache, no-store, must-revalidate" -"post-check=" -"pre-check=" -"private" has 406 results.

While we’re talking about RFC violations, it should be noted that use of the Pragma field, also introduced in the caching commit, is not correct. According to RFC 1945, “Hypertext Transfer Protocol -- HTTP/1.0”, use of no-cache with Pragma is intended for HTTP requests only. Again, Empire is not the first to ignore the RFC. In fact, Pragma: no-cache is widely used in HTTP server responses. RFC be damned. However, Werkzeug doesn’t use it by default so Empire’s usage helps narrow the field even further: title:"404 Not Found" +"Content-Length: 233" +"Cache-Control: no-cache, no-store, must-revalidate" -"post-check=" -"pre-check=" -"private" +"Pragma: no-cache" has 306 results.

There is one more RFC violation I want to point out, again from the caching commit, and that is the use of the Expires field. Both HTTP 1.0 and 1.1 specify that this field should contain a date. For example: Expires: Thu, 01 Dec 1994 16:00:00 GMT. Empire uses Expires: 0 which both RFCs specifically call out as incorrect (although 1.0 says 0 should be accepted and 1.1 says it must be accepted). The Shodan filter title:"404 Not Found" +"Content-Length: 233" +"Cache-Control: no-cache, no-store, must-revalidate" -"post-check=" -"pre-check=" -"private" +"Pragma: no-cache" +"Expires: 0" has 301 results. It should also be noted that Microsoft IIS servers generally don’t use Expires: 0. Which means Empire’s default value of Server: Microsoft-IIS/7.5 isn’t a good fit.

There is one more field that we know an Empire HTTP listener must have and that’s the Server field. As previously mentioned, this field is user configurable so you shouldn’t try to key off of the contents. But simply requiring the field to be present narrows the results down to 298: title:"404 Not Found" +"Content-Length: 233" +"Cache-Control: no-cache, no-store, must-revalidate" -"post-check=" -"pre-check=" -"private" +"Pragma: no-cache" +"Expires: 0" +"Server:".

We have more or less exhausted what we know an Empire HTTP listener response should contain. Now we need to add to the filter what we know it should not contain. For example, Empire doesn’t serve up any fields with “X-” or “Set-Cookie”. My final Shodan filter has 282 results: title:"404 Not Found" +"Content-Length: 233" +"Cache-Control: no-cache, no-store, must-revalidate" -"post-check=" -"pre-check=" -"private" +"Pragma: no-cache" +"Expires: 0" +"Server:" -"X-" -"Set-Cookie:" -"Connection:" -"Etag" -"Last-Modified" -"Accept-Ranges:" -"Access-Control".

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.

At the beginning of this write up, I made an HTTP request to “/” which resulted in a 404 error response. This is because Empire hasn’t implemented a route for “/”. However, Empire has implemented a route for literally everything else. For example, the following request yields a 200 OK:

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.

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.

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.