Lab 2 - Empire Setup and Initial Agent

In this lab we will:

• spin up Empire

• connect to the Starkiller graphical user interface

• create a listener

• create a stagers

• RDP into our entrypoint system

• execute a variety of stagers

• interact with an agent and perform some situational awareness

1. Make sure that you are connected to the openvpn file that was created when you deployed the lab environment. sudo openvpn student.ovpn Your VPN connection should say something along the lines of Initialization sequence completed. It is of crucial importance to NOT terminate this terminal session.

1. Now that you are connected to the VPN take note of your tun0 adapter IP address. (this should be in the 10.8.0.0/24 region, typically 10.8.0.2). You can find the IP by opening up a new terminal tab or window and typing ip addr show dev tun0

   

2. In this terminal window (or a seperate one, if you are forgetful about your IP), you can start your Empire server. Much like the VPN connection, this terminal session needs to remain active and should NOT be closed. You can start your Empire server by typing (you might need to change directories using the"cd" command to your empire location, such as /opt/Empire/ ./ps-empire server Eventually you should see something along the lines of

   
3. Open a web browser and browse to the following URL: http://localhost:1337/index.html#/, you will be greeted by the starkiller interface 😄

   
4. You can login to starkiller using the following credentials: Username: empireadmin Password: password123

5. Once logged on, you are conveniently dropped on the listener page. Please create a new listener by clicking on the orange create button on the top right.

   

1. Although you could create an HTTPS listener in Empire, for this workshop, we will be going with plain HTTP instead to reduce overhead. We cover HTTPS listeners in SEC565 🥁. When you clicked the create button, a new window will appear selecting the type of listener that you want, go ahead and select "http" from the dropdown list.

2. A new window appears allowing you to specify all kinds of details for your listener. Give your listener an appropriate name such as workshop-http-listener

3. In the Host field, replace the IP address with the IP address of your tun0 interface

4. Although port 80 is appropriate, you might already have something running on that port, so we will be picking port 8888 for this workshop.

1. Click on the little box icon on the left hand side to open up a stager generation window.

2. Fill out the type of listener, in this case multi_launcher, give the listener an appropriate name, in our example we picked workshop-launcher, and finally, most importantly, tie the listener to your listener. then click on the orange "Submit" button.

   

In a real engagement you obviously need to get initial access through social engineering or exploitation.

Some green buttons will be added to your top navigation after you click submit. We will be needing those in a moment 👍. First, open a new terminal tab or window and RDP into our entry point of our environment using xfreerdp, if xfreerdp is not installed on your system yet you can install it by opening a terminal window and typing sudo apt install freerdp2-x11 -y xfreerdp /v:10.0.10.20 /u:Administrator /p:'AnsibleAutomation123!' +clipboard /dynamic-resolution

1. Now that we are logged in as a local administrator we can immediately launch an Empire C2 agent with high integrity (administrative privileges). Open up a new PowerShell terminal on the workstation.

1. copy paste your stager in there by clicking on the icon.

   
2. Press enter to get an implant up and running, you will see your implant appear by clicking on the chain icon on the left.

3. So, let's think about this from a purple team perspective for a second and think about the opsec implications. One of the primary detection engineering log source is the process create eventlog. In our lab, we have installed sysmon, making it easy for us to query Kibana looking for Powershell execution. Base64 encoded powershell commands don't happen often, especially not with a hidden window switch. This is however quite typical initial access behavior for a lot of C2 frameworks, not just Empire. Let's hunt for the stager in our Kibana. In the Blue team realm, we have a bit of a complex issue, which is that organizations use different SIEMS. To solve that problem we typically write detection rules platform agnostic using a technology which is called "sigma". We then conver the sigma rule into a queryable rule in our SIEM using a converter. We cover this in SEC699. An example of a basic sigma rule is below:

title: Base64 Encoded PowerShell Command Line
id: 52f76348-95de-4b52-9289-4676142a2c1a
status: stable
description: Detects the execution of PowerShell with Base64 encoded commands. This is a very common technique used by adversaries to obfuscate their commands and payloads.
references:
    - https://attack.mitre.org/techniques/T1059/001/
author: Jean-François Maes
date: 2025/09/09
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        # The process executable must be powershell.exe
        Image|endswith: '\powershell.exe'
        # The command line must contain one of the flags for encoded commands.
        # PowerShell allows abbreviated parameters, so we check for common short forms.
        CommandLine|contains:
            - ' -e '
            - ' -en '
            - ' -enc '
            - ' -encode '
            - ' -encodedc '
            - ' -encodedcommand '
    condition: selection
falsepositives:
    - Some legitimate software installers or administration scripts may use this technique, but it is rare. All occurrences should be investigated.
level: high
tags:
    - attack.execution
    - attack.t1059.001

If we convert this to a KQL syntax (which is what we use for Kibana) this would be the rule

winlog.event_data.Image : "*\\powershell.exe" and winlog.event_data.CommandLine : ("* -e *" or "* -en *" or "* -enc *" or "* -enco*" or "* -encoded*" or "* -encodedcommand *")

1. Open up your webbrowser in your Ubuntu VM whilst connected to the VPN and browse to https://10.0.10.50:5601/ You will be greeted to an elastic stack. The credentials to log in are: elastic ElkSecur3!

   
2. Once logged in, click the hamburger icon then click on Discover

   

1. From there, you will be able to play around with the event logs and be a cool blue teamer! Let's paste our KQL query that we extrapolated from our Sigma rule and set the date to 1 day ago. If you are overwhelmed with logs you can fine tune your date to a few minutes or hours making it easier to navigate.

   

19. We get results! There it is, our stager, free for the blue team to look into!

1. If we take a look at the scriptblock logging for the agent, we would see something highly interesting and alarming for blue teams...

   

Indeed, if we trace this back to our launcher we see that by default, 2 bypasses are selected. an AMSI bypass and an ETW bypass. Since sysmon primarily lives from ETW events, we will have to create a new launcher that does not have these bypasses enabled so we can see what happens under the hood.

1. Create a new agent and stager following the steps mentioned above, but this time make sure to remove the bypasses.

   

1. In your agents tab, enabled Process ID, we will need this later.

   

Bonus Challenge 1. You might find more base64 encoded commands... can you figure out where they come from? Can you figure out what they do? If you are stuck, chatgpt can provide a clue...

Bonus Challenge 2.

Find a way to deliver the stager without triggering base64 encoded detections... This shouldn't be too hard :)