The past year has been quite eventful for the Empire team. We have all gone in different directions in terms of employment, but we are still working together to bring more awesomeness to one of the premiere post-exploitation agents. If you haven’t had the chance to become familiar with the 2.0_beta branch, take a look at @harmj0y’s excellent post covering all of the new changes with that release. Also, we would like to thank everyone involved in the Empire community for your numerous contributions in terms of bug fixes, new modules, and oh yes, the countless git issues/feature requests (we can’t fix what we don’t know about right?). So without further adieu, here is a short list of what core changes were made for the 2.0 Final release. We’ll cover some of the additions in detail, including any modules/listeners of special interest.
- Added custom HTTP headers for HTTP and HTTP_Foreign listeners for use with Domain Fronting.
- Finalized REST API and fixed outstanding issues.
- Fixed cookie parsing bug.
- Added additional aliases for python agent.
- Removed legacy code in modules, listeners, and agents from the Empire/EmPyre merge.
- Added ability to import python packages from memory.
- Added Dropbox listener.
- Added the ability to use IPV6 with the HTTP and HTTP_Foreign listeners.
- Several module additions and updates.
Overall, the 2.0 release involved quite a few bug fixes. There were several areas where legacy code was left behind and caused issues because class definitions, and the back-end database structure changed. This has all been fixed now (hopefully) but, as you can imagine, going through 260+ module updates is a daunting task.
The REST API has been out of commission for quite some time. Major kudos to @harmj0y for getting this started. The underlying changes to the data structure and class definitions didn’t quite work well with the REST API. This is expected in a beta release, so please be patient as we continually fix issues with it. After revamping some of the code, everything seems to be in working order. Please take the time to familiarize yourself with the wiki. It now reflects any changes and new REST endpoints that were added. In regards to listeners, you can now view the listener options for a specified listener type.
The endpoint for this specific call has not changed. In addition, you may now use the REST API to upload a file to your agent. Please note that the data argument of the POST request should be a base64 encoded string.
Please keep in mind that when executing shell commands or modules through the REST API, results will not be returned immediately. Results are obtained through a separate API call. Overall, all of the REST API calls should be in working order but there will always be issues.
Modules and Updates
Now it’s time to highlight some of the new modules, module updates, and listeners. All thanks to contributions from the community. So we’ve been working to support more methods of communication channels within Empire and hope this release brings some much needed support for evading common detection methods for HTTP/HTTPS command and control (C2) traffic.
We started by adding support for IPv6 traffic. While this C2 channel may not be supported in every environment, the ability to operate from IPV6 adds another layer of offense-in-depth. Many defensive products and categorization sites do not support or scan IPv6 in default configurations.
Thanks to some awesome work we’ve finally decided to implement Third-Party C2 channels. BE SURE TO READ Terms of Service for any Third-Party service you use on an engagement. Dropbox is the first release we have provided with this update and more to follow. All you need is a Dropbox account, create an “APP”, and generate an API token. More info here https://www.dropbox.com/dvelopers/apps/create.
Here we see an Empire Dropbox listener and options.
Next, the folder structure that the listener creates using the API token access.
Lastly, a Wireshark capture of the dropbox staging process.
Community member klustic added a module to launch a SOCKS5 proxy for *NIX environments via this pull request https://github.com/EmpireProject/Empire/pull/478. While this method doesn’t use SOCKS through the beaconing Empire agent, it finally gives us a way to pivot over SOCKS into an environment.
The SessionGopher module was added to Empire by @arvanaghi. This can be used to remotely retrieve saved sessions for WinSCP, Putty, SuperPutty, and FileZilla. Awesome work! Also, thanks to Kevin Robertson and the NetSPI team for the updates to Inveigh and adding PowerUpSql to Empire respectively. To read up on all of the capabilities provided by PowerUpSql, look here
For macOS, @killswitch_GUI added a packet sniffing module that utilizes the libpcap native library to capture packets, all in Python, with ctypes. In addition, the ability to load Python packages entirely from memory is now possible. The zip files must contain all dependencies and match a specific format. You can find more details on that here. This is really great work and we will continue to bring more capabilities to macOS in the future.
Recently, the ability to add custom headers in the default profile for listeners was added. Since then, it has come to our attention that modifying the host header is a problem. When using the System.Net.WebClient class, there are a set of “system” headers that may not be modified, including the host header. If any of these headers are changed, the web request will fail with an exception. This is really only an issues on systems with .Net 3.5 or below. Newer versions of dot net will allow you to modify the host header. So, use your discretion whether you want to utilize custom headers for domain fronting.
We’ve ported over @enigma0x3 DCOM research from this blog post Using Distributed COM communications over port 135, we can execute commands on the remote host. This includes executing a new payload as seen in the following GIF.
If you would like to play with more DCOM fun, check out my script at https://github.com/rvrsh3ll/Misc-Powershell-Scripts/blob/master/Invoke-DCOM.ps1
Casey Smith @subtee has continually put out awesome techniques that utilize Microsoft signed binaries to execute untrusted code. One of my favorites, MSBuild, allows an attacker to use a Visual Studio project file or xml, to compile and execute CSharp code. In honor of his great work, I decided to automate this technique in PowerShell, and subsequently add a module to empire. You can check it out here
Well we’re not finished yet; however, as @sixdub and @harmj0y originally intended Empire to be a proof-of-concept RAT using only PowerShell, this project certainly has come a long way. Empire 2.0 extends the framework to other systems such as *nix and MacOS. With such a great community of users and developers we hope to continue to push the boundaries of what’s capable using the power of the Empire!
For more details on what has changed, check out the changelog