Even though Empire is no longer being actively developed, it's still well worth having in your development/research environment. There are a few parts to setting it up and getting it working but once that is done its simple to try out a huge range of attack techniques such as persistence, recon & exploitation.
For this tutorial we'll be using Kali Linux 2019.3. If you don't have Kali setup head over to https://www.kali.org/downloads/ and grab your favourite flavour. Kali is relatively simple to get up and running. Once you're logged into Kali we can get Empire up and running.
Start by cloning the Empire repository and running the install script;
git clone https://github.com/EmpireProject/Empire.git cd Empire/setup/ ./install.sh
During the install you'll be asked about restarting services automatically, I'm never really relying on Kali so I let it restart all the services automatically. Next up it will ask you for a "Server Negotiation Password", I allow the system to generate a random string by pressing enter.
Once some certificates are created Empire is installed and ready for you to fire up.
Initial Empire Setup
Now that Empire is installed we can start it up using the following commands. These will change you out of the setup directory into Empire's root directory and kick it off.
cd .. ./empire
Once loaded you can see a number of modules loaded as well as listeners and agents.
- Modules - These do things, there are modules for all types of activities from maintaining persistence, exploiting known vulnerabilities all the way through to credential access via Kerberoasting.
- Listeners - Listeners listen for things. We setup listeners to receive communications from our agents and to relay commands back to our agents for them to run modules.
- Agents - Each agent would likely be a compromised machine that we can interact with and send commands to execute modules
- Stagers - We use stagers to establish that initial communication between an agent and our listener. Stagers can be created in many ways including PowerShell, VBS scripts and XML. All the stagers can be seen below.
Next we'll get our listener setup. This will listen for any communication from our targets and will relay commands back to them when required. Listeners are simple to setup and we will use the stock standard http listener. The name for this listener is also http & we will need this name later, probably best to use something more descriptive.
uselistener http execute
After executing you should see a [+] Listener successfully started! notification. Now we are ready to generate our stager code to run on our target server.
For our example we are going to use the multi/launcher stager, this will be PowerShell based due to using a Server 2019 target.
usestager multi/launcher info
There is only one required value that is not set by default and this is the listener you'd like the stager to connect to. This will be a reverse connection from the target to your Kali machine. If you have firewalls in the way you'll need to ensure there are rules to allow the traffic from and to the Kali machine. We can also see the default value for the Language is PowerShell so we don't need to change that for our testing.
Set the Listener to the one created earlier with;
set Listener http
Now we can generate the stager with the execute command which will output the PowerShell code to the terminal in this case.
Execute the Stager
For this testing we'll just copy across the Powershell code for the stager and paste into an elevated Powershell prompt on our Server 2019 target machine. This will run the stager code and close the PowerShell window, after that we can now send commands to our target for all sorts of goodness.
Hopefully that's helpful in getting the initial communications between your Kali machine and the target server. Firewalls, IPS and AV can all get in the way, so make sure you check logs for those security controls if anything doesn't work. In the next blog we'll go through detecting this intial payload and communications and then we'll get stuck into the recon and persistence commands and what that can tell you. Throughout all the parts we will go through how to detect this using built in Windows logs (As well as Sysmon, which should be built in)
If you have any feedback or questions on how to get Empire up and running please reach out to us at firstname.lastname@example.org or message any of us via LinkedIn/Twitter - @mike_nolan__ or @seamlessintel