Skip to main content
Before moving on to redirector configuration and C2 setup, confirm that every lab machine is reachable. This catches initialization failures, user data timing issues, and network misconfiguration early — before they surface as confusing errors during C2 payload testing. All IPs and credentials come from: 
terraform output deployment_info
Wait at least 5–10 minutes after terraform apply completes before running these checks. User data scripts are still running on all instances during this window. The Windows workstation is the slowest — allow up to 15 minutes in total.

​
Access methods

The lab supports three ways to reach internal machines. Use whichever fits your workflow. All three should work after a clean deployment.

Windows workstation

Ping and test hostnames from inside the lab network via the Guacamole RDP session.

Guacamole SSH connections

Click any SSH connection in the Guacamole portal to open a terminal directly in your browser.

SSH jumpbox from your host

Use Guacamole as an SSH jumpbox to reach internal machines from your local terminal.

​
Verify from the Windows workstation

This is the primary connectivity check. All C2 callbacks originate from victim machines inside the lab network, so the Windows workstation’s view of the network is the one that matters most.
1

Open the Windows workstation

In the Guacamole portal, click Windows Operator Workstation. Wait for the desktop to load (10–30 seconds).
2

Open PowerShell

Right-click the desktop and select Open PowerShell here, or press Win + R, type powershell, and press Enter.
3

Ping all lab machines by hostname

Run each ping in sequence. All hostnames are pre-configured in C:\Windows\System32\drivers\etc\hosts — no DNS required.
ping mythic
ping sliver
ping havoc
ping redirector
ping guac
Expected result: Each hostname resolves to a private IP and returns four replies with no packet loss.
The redirector hostname resolves to its private IP in the redirector VPC, reachable via VPC peering. All other hostnames resolve to private IPs in the team server VPC.

​
Verify via Guacamole SSH connections

For each SSH connection in the Guacamole portal, click the tile and confirm a shell prompt appears. This verifies that guacd can reach the target host and that SSH is accepting connections. 
# Once connected to any lab machine, confirm hostname resolution works from Linux as well
ping -c 4 mythic
ping -c 4 sliver
ping -c 4 havoc
ping -c 4 redirector
ping -c 4 guac
Expected result: All pings resolve and respond from any Linux machine in the lab.

​
Verify via SSH jumpbox from your host

Guacamole has a public Elastic IP and accepts inbound SSH. Use it as a jumpbox (-J) to reach internal machines directly from your local terminal without opening any additional firewall rules. Get the Guacamole public IP from terraform output deployment_info → GUACAMOLE ACCESS PORTAL → Public IP. 
ssh -i rs-rsa-key.pem -J admin@<GUAC_PUBLIC_IP> admin@mythic
ssh -i rs-rsa-key.pem -J admin@<GUAC_PUBLIC_IP> admin@sliver
ssh -i rs-rsa-key.pem -J admin@<GUAC_PUBLIC_IP> admin@havoc
Replace <GUAC_PUBLIC_IP> with the value from terraform output deployment_info. The rs-rsa-key.pem file must be in your current directory, or provide the full path.
The jumpbox method uses your AWS SSH key (.pem) for authentication, not the lab password. This is the only access method that requires the key file — all Guacamole connections use password auth.

​
Success criteria

Your deployment is ready for C2 configuration when all of the following are true:
CheckExpected result
Guacamole portal accessiblehttps://<GUAC_PUBLIC_IP>/guacamole loads and accepts login
All 7 connections visibleHome screen shows all 7 pre-configured connection tiles
Windows desktop loadsRDP session connects and desktop appears within 30 seconds
All hostnames ping from Windowsping mythic, sliver, havoc, redirector, guac all reply
All Guacamole SSH connections openEach SSH tile opens a shell without errors
Jumpbox SSH works from hostssh -J reaches internal machines using .pem key

​
Troubleshooting connectivity failures

  • Confirm the URL uses https:// — HTTP redirects to HTTPS but the redirect may fail if Nginx is still starting.
  • Check that the Guacamole instance is in a running state in the AWS EC2 console.
  • Check your security group rules. Port 443 must be open to your IP. Your localPub_ip in terraform.tfvars controls this — verify it is set correctly and includes the /32 suffix.
  • If the instance just started, wait 3–5 minutes for Docker and Nginx to finish initializing.
The connections are created by the Guacamole setup script during user data execution. If fewer than 7 appear, the script may still be running or may have failed partway through.SSH into the Guacamole server (using the external IP and your .pem key) and check the log:
ssh -i rs-rsa-key.pem admin@<GUAC_PUBLIC_IP>
sudo tail -100 /var/log/user-data.log
Look for errors near the connection creation steps. If the API was not ready in time, you can re-run the Guacamole setup manually or create the missing connections through the Guacamole admin UI.
The Windows instance takes longer to initialize than any other component. User data scripts disable Defender, enable RDP, and install tools — this can take up to 15 minutes on first boot.
  • Wait 5 more minutes and try clicking the tile again.
  • In the AWS EC2 console, check that the Windows instance shows running status and that the Status checks column shows 2/2 checks passed.
  • If RDP fails after 15 minutes, check the Windows instance’s user data log via the EC2 console: Actions → Monitor and troubleshoot → Get system log.
Hostname resolution relies on C:\Windows\System32\drivers\etc\hosts. If a hostname does not resolve:
  1. Open PowerShell as Administrator on the Windows workstation.
  2. Inspect the hosts file:
Get-Content C:\Windows\System32\drivers\etc\hosts
  1. Confirm the expected entries are present. If missing, the Windows user data script may not have completed. Check the EC2 system log for errors.
If the entry is present but ping fails, the target instance may not be running. Verify all instances show running in the EC2 console.
  • Confirm port 22 is open on Guacamole’s security group for your IP (localPub_ip in terraform.tfvars).
  • Verify the .pem file permissions. On Linux/macOS, the file must not be group or world readable:
chmod 400 rs-rsa-key.pem
  • Confirm you are using the correct key name. The key must match ssh_key_name in terraform.tfvars (default: rs-rsa-key).
  • Internal machines (mythic, sliver, havoc) are reachable via the jumpbox only because Guacamole shares a VPC with them. The redirector is in a separate VPC — it is not reachable via internal hostname through this jumpbox.
All instances run user data scripts on first boot. The timeline from terraform apply completing to all services being ready:
InstanceEstimated initialization time
Guacamole3–5 minutes
Redirector3–5 minutes
Mythic5–10 minutes (installs ~10 Docker containers)
Sliver3–5 minutes
Havoc5–10 minutes (builds from source)
Windows10–15 minutes
If you are within this window, wait and retry. Do not assume a failure until the full initialization time has elapsed.

Build docs developers (and LLMs) love

Get started for freeTalk to us