Anthony Rose | Jacob Krasnov

It’s been a while since we made a blog post, and it’s because we have been busy updating Empire for the official release of Empire 3.0 ! There are a lot of significant changes, so we thought it would be a good idea to walk through them in a little more detail instead of just listing them in the changelog . Many of these have lingered on various branches of the Empire project and have finally been consolidated, as well as several additions of our own. Also, we want to share our future plans for the Empire framework.

Python 2/3 Compatible

The most significant update is that the Empire codebase has been ported from pure Python 2.7 to Python 2.7/3.x. With the End of Life coming for Python 2.7 at the end of the year, Debian has already started dropping support for all Python 2.7 packages. Debian dropping support upstream has begun causing issues for Kali to maintain support for several tools, and Empire was one of the last frameworks that Kali is supporting that needs to make the conversion to Python 3. This port ensures that Kali will be able to continue supporting Empire into the future and the BC Security Empire fork has been incorporated into the Kali Experimental build and will most likely be the supported Empire version going forward.

New Powershell Modules

While the port to Python 3 was vital for the continued life of the project, it didn’t do anything to update its functionality or effectiveness. There are, however, plenty of those types of upgrades in the new release as well. We have included many brand-new and “old” additions as part of the release. Some of them are considered “old” in the sense that they have been in the Dev branch of the original Empire repository, or they hadn’t been pulled into a release. We wanted to ensure that the authors of those modules/fixes got proper credit, so we have included them as part of the release. Those modules are:

We gave the users associated with the original pull request credit as authors for those modules/fixes, if there is some work that has been incorrectly attributed, please let us know at [email protected] and we will correct it ASAP.

Enhanced Windows Evasion

Now let’s talk about some of the new updates. One of the biggest capability upgrades to Empire itself is the updated evasion capability. This has been achieved by updating the base launchers to remove some of the distinctive signatures that existed. For example, the HTTP launcher had a bug that caused an add header command to be repeated twice and was particularly hard to obfuscate away even when using Invoke-Obfuscation.

This bug was also the primary reason that Windows Defender instantaneously caught many of the process migration modules. Due to limitations in the length of the string that can be used with modules such as Invoke-PSInject, it was impossible to obfuscate away that distinctive signature. Even though the initial payload went undetected, as soon as another module attempted to launch, it would be caught. Removal of that bug alone greatly restored the effectiveness of Empire.

We have also updated the AMSI bypasses to reduce their size and change their signature. The Matt Graeber bypass is well known at this point and will cause Defender to flag on it without any obfuscation. Specifically, the words amsiintifailed and system.management.automation.amsiutils cause a trigger, while Invoke-Obfuscation does not add concatenation to these fields as this could cause the function to fail. In this case, concatenation does not affect the function and adding it to those fields causes it to no longer be flagged.

Mimikatz 2.2.0

Mimikatz is one of the most popular post-exploitation tools that can dump hashes, passwords, and tickets from memory. In Empire 3.0, Mimikatz was updated to version 2.2.0, which allowed attacks against Windows 10 (specifically 1903) to be possible once again. Another new feature is the addition of Data Protection API (DPAPI) support for Powershell PSCredential and SecureString. You can find the latest version of Mimikatz in our most recent build or on their Github .

JA3/S Signature Randomization

JA3 is a method of fingerprinting the TLS handshake that was first published by John Althouse, Jeff Atkinson, and Josh Atkins from Salesforce back in 2017. It came about as a proposed solution to identifying malicious encrypted traffic. Research published by the Akamai Threat Research group has found that more than 80% of malicious traffic is now conducted over encrypted channels. As a result, many defenders have adopted this technique. For further discussion on it, see our blog post here .

We have implemented JA3/S randomization, but not JA3 randomization. The JA3 signature varies based on the listener used already, and unfortunately, to modify the signature

typically requires Administrative privileges on the victim computer. The purpose of the randomization is to break the known pairing that signals Empire C2. The JA3 randomization already achieves this without first needing Administrative privileges

Way-Forward

Moving forward, we plan to make regular updates as new research is published. We believe that Powershell and Empire framework will remain a major threat vector employed by APTs, malware authors, and Red Teams. When we conduct an assessment, we think that companies are best served when we emulate the primary attacks that they face rather than employing the latest and greatest offensive evasion tactics. That being said, we recognize that Powershell may no longer be the most effective attack vector in terms of evasion, but represents a credible and realistic threat.

We plan to continue to update and upgrade the usability of the Empire framework. Some future upgrades that we have planned are incorporating more C# modules into the framework, as well as other attack vectors, implementing function name aliasing and randomization, and adding a multi-user GUI.