Top Categories

Spotlight

todayApril 10, 2024

Cyber Security + Offensive Security Tools Hubbl3

Ransomware during a Pentest, Yes or No?

NOTE: Some of the topics in this article are probably going to be a bit contentious, but part of the hope in publishing this article is to drive some additional discussion within the offensive security community Ransomware has become one of the most prevalent threats that companies face today. It [...]


Overview of Empire 4.0 and C#

Cyber Security + Offensive Security Tools Cx01N todayMay 17, 2021 7889 13 5

Background
share close

The release of Empire 4.0 is just around the corner and we wanted to take some time to walkthrough some of its new features. So what is Empire 4.0? It is a refactor of the internal structure of Empire, the addition of C# capabilities, and a revamped user interface. This has been a massive rework of the project to allow for easier development in the future, as well as the addition of more modern capabilities found in C2s.

A good tool for getting an idea of the direction modern C2s are going is C2 Matrix. This website allows users to search for specific implant types (C, C#, PowerShell, Python, etc.) and compare those against a variety of different parameters, such as C2 Channel, User Interface, and Capabilities. You can see below that adding additional implants will move Empire from supporting just PowerShell and Python to being a more versatile tool. The codebase refactor will allow for better support of multi-user interfaces, further bringing Empire into alignment with modern C2s.

List of C2s and Capabilities from TheC2Matrix.com

So Why Refactor The Code?

Because Vinnybod is a masochistic overlord who was rejecting all our poorly written pull requests. All joking aside, the Empire codebase is over 5 years old and will now use the REST API to power the CLI. Refactoring is a part of ensuring the longevity of the Empire project. It has gone through many updates from many individuals and was converted from Python 2 to Python 3. Most of that time was focused on bringing new functionality and not so much on how that functionality was implemented. By doing some more “boring” work upfront to refactor and clean up the existing code, future features can be implemented much faster. Martin Fowler explains why spending time upfront is better for the long-term sustainment of a project in his post, Is High Quality Software Worth the Cost?

Cumulative functionality of software versus the time (and thus cost) – Martin Fowler

For example, we noticed a lot of divergent functionality between the CLI and API when building Starkiller, which interacts exclusively with Empire through the REST API, even though they should have been doing the same exact thing. Extracting the client to use the REST API removes those duplicate, diverging code paths. It also forces us to write a better functioning API, which in turn brings better feature parity between the client and GUI and makes it easier for others to extend Empire’s functionality with new tools like Deathstar. This is just a start to that work, as we have plans to implement a more consistent and functional API in a future major release.

Install Instructions

You can access the alpha release of Empire 4.0 through our sponsor repo or through Kali. The following commands will install the most recent alpha release on Kali:

echo "deb http://http.kali.org/kali kali-experimental main non-free contrib" | sudo tee -a /etc/apt/sources.list 
sudo apt update
sudo apt install -t kali-experimental powershell-empire

Empire Startup

The startup process for Empire has significantly changed since it now uses a Server/Client Architecture. You’ll be running a terminal for the server similar to the teamservers for Cobalt Strike, PoshC2, and Silenty Trinity. To launch the empire server, run ./ps-empire server. The new server interface can be setup either locally or on a remote host and is self-contained.

New interface of the Empire server

The client is the revamped CLI for Empire. The new interface keeps many aspects of the original interface but has been updated for better scalability and usability. The client can be launched by running ./ps-empire client.

Empire client’s new interface

Now before we go over the new C# functionality, here are a few other features that can be found in Empire 4.0.

  • Added Offensive DLR Modules: IronPython, ClearScript, & Boolang
  • Added NTLM-Extract, Invoke-SharpSecDump, MS16-051 stager
  • Added customizable bypass option to stagers
  • Added suggested values for stagers, listeners, modules, and plugins

CSharp Plugin Startup

We found that not every engagement requires the use of installing dotnet. Since it takes up a non-trivial amount of space, we decided that we would make installing dotnet and using the C# functionality in Empire optional, at least for the moment. At some point, we may integrate the C# server directly into the Empire codebase, but for now, it is contained in a plugin. When you first boot up the C# server, it will generate the backend compiler.

useplugin csharpserver
execute
CSharp Server for running the modified Covenant Rosyln Compiler

Shared Code Components (Covenant Roslyn Compiler)

When deciding to add in C# capability, we wanted to support in-place compilation instead of requiring a user to launch a secondary program and open an outputted project file to be able to use the resources. This process is tedious and not really workable for an engagement. Instead, we wanted to implement something like Covenant. After some work, we realized that instead of having something LIKE the Covenant Roslyn Compiler, we could just use the Covenant compiler.

This saved us a lot of work but, more importantly, enabled us to further our goal of making Empire interoperable with as many open source projects as possible. We think that making projects interoperable encourages more community contributions, makes upgrades easier and provides more flexibility for operators to move between projects as engagements require without having to relearn entire new codebases and project nuances. So with the integration of the Covenant Roslyn Compiler, Empire now supports the use of Covenant Task files. These tasks can be used with BOTH the C# agent and PowerShell agents. Now we will explore all the features currently available for the C# agent.

Setting up a Launcher

You will need to start a listener for the agent to communicate with. You’ll notice that the “set” command now offers a dropdown list of suggested options and values. You can type uselistener to get a list of available listener options, but we will be using the http listener for this example.

Dropdown menu for setting listener options

Once the listener is started, you will need to generate a launcher to deploy the agent. The command usestager will display all the available stager options. At the moment, C# agents will only work with the csharp_exe stager.

Dropdown menu for available stagers

The csharp_exe stager was originally created by Elitest as a C# stage 0 that launched a PowerShell agent. Hubbl3 created a purely C# stager that leverages the Sharpire Project, which was an implementation of the Empire Agent in C#. The C# launcher, known as Sharpire, is packaged within this stager and can be changed based on setting the stager language to PowerShell or CSharp.

Information page for the C# stager
All options available for both PowerShell and C# launchers

Many of the options traditionally used by PowerShell launchers are not currently available when creating a C# payload. For example, setting the Obfuscation and Bypasses will not affect the launchers generation and will be ignored.

Message returned to Empire client when generating C# launcher

New in Empire 4.0, files that are generated within Empire will be loaded into a client folder called “generated-stagers” which is located in the client directory.

Generated stager directory for the Empire client

Using the CSharp Agent

Launching the C# launcher is relatively simple. All that is needed is loading the file to the target machine and executing the .EXE. This will trigger the agent to execute and will initialize the staging in memory. The client will get a notification when the agent checks back in and will be displayed on the agents page.

Table of active/inactive agents

Typing interact <agent_name> will allow users to interact with the agent and send commands to it. A dropdown list of active agents will be displayed, so going to the agents page will not be necessary and so agent interaction can happen from any menu.

Dropdown menu of Empire modules

The command usemodule <module_name> is how users will select modules to execute on the agent. Usemodule uses a keyword search to assist in selecting the correct module. Previously, a user had to type out the entire path to the module. The C# modules are compiled on the fly and sent across the C2 channel to the agent on the other side. A huge advantage of the way the C# modules were implemented is that it will allow C# agents to run either PowerShell or C# modules and vise versa.

AMSI Bypass module from SharpSploit
Rubeus being compiled through the compiler and executed
PowerShell module being executed through a C# agent

The interactive shell menu is a new feature that creates a session for a user to send PowerShell commands within. The interactive shell parses its current working directory and allows the user to get a similar feel to a PowerShell window.

Interactive shell within an Empire agent

Wrap Up

The upcoming Empire 4.0 release is a massive rework of the project and is opening the door for some exciting new features in the future. Anyone can check out the project through the Kali experimental repo and submit feedback through the Empire GitHub or our Discord.

Written by: Cx01N

Rate it

Previous post

Similar posts