Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/BaddKharma/redStack/llms.txt

Use this file to discover all available pages before exploring further.

Reference this section if any component is not behaving as expected after deployment. Start with the connectivity checks to confirm the network is intact, then move to component-specific health checks if a particular service is the problem.

​
Connectivity checks

​
Guacamole portal

Verify Guacamole is reachable from your local machine: 
curl -k https://<GUAC_PUBLIC_IP>/guacamole
Expected: HTTP 200 with the Guacamole login page HTML.

​
Internal hostname resolution (from Windows workstation)

Pre-configured /etc/hosts and C:\Windows\System32\drivers\etc\hosts entries are written on all machines at deploy time. Hostname resolution failures from WIN-OPERATOR mean the hosts file was not written during cloud-init. 
ping mythic
ping sliver
ping havoc
ping redirector
All four should respond with replies from internal IPs.

​
Redirector decoy and header validation

These two tests verify the core redirector security model from your local machine. Use a browser User-Agent — curl’s default is blocked by redirect.rules. 
UA="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"

# Test decoy page — no header present. Should return HTTP 200 with the CloudEdge CDN maintenance page.
curl -s -A "$UA" http://<REDIR_PUBLIC_IP>/

# Test C2 routing — valid header present. Should proxy to the Mythic backend.
# (Returns 404 if no listener is running, which is expected before Part 4 is complete.)
curl -s -A "$UA" -H "X-Request-ID: <token>" http://<REDIR_PUBLIC_IP>/cdn/media/stream/test
Retrieve the correct <token> value: 
terraform output deployment_info
# Look for: C2 Header: X-Request-ID: <token>

​
VPC peering

Verify VPC peering routes are present in both VPCs. From the redirector, the team server VPC CIDR (10.50.0.0/16 by default, or your custom vpc_cidr) should be reachable: 
ping -c 3 mythic
ping -c 3 sliver
ping -c 3 havoc
If these fail from the redirector, check the AWS VPC console under Route Tables and confirm that both the redirector VPC route table and the team server VPC route table have entries for each other’s CIDR via the VPC peering connection.

​
Component health checks

SSH to Mythic via the Mythic Team Server (SSH) Guacamole connection, then check container status:
cd /opt/Mythic
sudo ./mythic-cli status
Expected: 8 core containers plus apollo and http all showing running. Warnings about localhost binding are expected and harmless.Check Docker directly:
sudo docker ps
Retrieve the Mythic admin password:
sudo cat /opt/Mythic/.env | grep MYTHIC_ADMIN_PASSWORD
Access the web UI from the Windows workstation browser:
https://mythic:7443
Login: mythic_admin / password from above.If containers are not running, stop and restart Mythic:
sudo ./mythic-cli stop
sleep 10
sudo ./mythic-cli start
Check container logs directly with Docker:
sudo docker logs mythic_server
sudo docker logs mythic_nginx
If the mythic_nginx container keeps restarting with a missing certificate error, see the Mythic nginx SSL certificate missing section below.
SSH to Sliver via the Sliver C2 Server (SSH) Guacamole connection:
sudo systemctl status sliver
Connect the Sliver client to verify the daemon is accepting connections:
sliver-client
The client should connect without error and display the Sliver banner. If the sliver-server binary is missing, see the Sliver not installed section below.
SSH to Havoc via the Havoc C2 Server (SSH) Guacamole connection:
sudo systemctl status havoc
If not running:
sudo systemctl start havoc
If the binary is missing, the build step (Part 6) has not been completed. Run ~/build_havoc.sh on the Havoc server.
SSH to Guacamole and check that all three Docker containers are running:
sudo docker ps
Expected: guacamole/guacamole, postgres:15, and guacamole/guacd — all up.Check Nginx (the reverse proxy in front of Guacamole):
sudo systemctl status nginx
If connections are missing from the Guacamole UI, verify they exist in the database:
docker exec -it postgres_guacamole psql -U guacamole_user -d guacamole_db \
  -c "SELECT connection_id, connection_name, protocol FROM guacamole_connection;"
Expected: 7 connections (1 RDP, 5 SSH, 1 VNC). If missing, connections can be recreated manually through the Guacamole UI under Settings → Connections → New Connection.
SSH to the redirector and run the pre-installed test script:
sudo /home/admin/test_redirector.sh
This single command checks Apache status, all VirtualHost configurations, connectivity to all three C2 backends, and header/decoy page behavior.Check VirtualHost configuration directly:
sudo apache2ctl -S
Verify redirect.rules loaded correctly (should return a count of rules, not zero or an error):
grep -c 'RewriteCond' /etc/apache2/redirect.rules
Check Apache service status:
sudo systemctl status apache2
Review access and error logs:
sudo tail -50 /var/log/apache2/redirector-ssl-access.log
sudo tail -50 /var/log/apache2/redirector-ssl-error.log
sudo tail -50 /var/log/apache2/redirector-access.log
sudo tail -50 /var/log/apache2/redirector-error.log
URI prefixes in the logs identify which C2 backend received each request:
URI prefixBackend
/cdn/media/stream/Mythic
/cloud/storage/objects/Sliver
/edge/cache/assets/Havoc
If RDP through Guacamole is failing or slow:
  • Desktop takes a long time to load: Normal. Wait 10-15 minutes after initial deployment. Windows is the slowest component to initialize.
  • Check RDP is enabled: On the Guacamole server, confirm RDP connectivity: nc -zv win-operator 3389
  • Check Defender is disabled: After connecting, open PowerShell and run Get-MpComputerStatus | Select RealTimeProtectionEnabled. Expected: False.
  • Check hosts file: Open C:\Windows\System32\drivers\etc\hosts and confirm entries exist for mythic, sliver, havoc, guac, and redirector.

​
Common issues and fixes

This is expected before listeners are started. The redirector test script (test_redirector.sh) attempts to connect to each C2 backend’s HTTP port. Sliver and Havoc only expose that port after a listener is configured.
  • Sliver: FAILED until an HTTP listener is started with http --lhost 0.0.0.0 --lport 80 in the Sliver console
  • Havoc: FAILED until the teamserver is running and an HTTP listener is created through the Havoc client
Re-run sudo /home/admin/test_redirector.sh after completing Parts 5 and 6 to confirm all three backends show OK.
The X-Request-ID header value is wrong or missing. The decoy page is always returned when the header check fails, regardless of URI prefix.
  1. Retrieve the correct token: terraform output deployment_info → look for C2 Header: X-Request-ID: <token>
  2. Confirm the token matches what is configured in your agent or test command
  3. Test manually with the correct token: 
    curl -s -H "X-Request-ID: <token>" http://<REDIR_PUBLIC_IP>/cdn/media/stream/test
    Expected: connection refused or 404 (proxied to Mythic), not the CloudEdge page.
Normal behavior. Windows cloud-init runs Defender disablement, RDP enablement, and tool installation (Chromium, VS Code, MobaXterm, 7-Zip) on first boot. This takes 10-15 minutes. Wait and retry the Guacamole RDP connection.
The SSH key pair (rs-rsa-key) must be created in AWS before running terraform apply. Terraform does not create it.Verify the key pair exists:
aws ec2 describe-key-pairs --key-names rs-rsa-key
If it does not exist, create it (run from inside the redStack/ directory):
aws ec2 create-key-pair --key-name rs-rsa-key --query 'KeyMaterial' --output text > ./rs-rsa-key.pem
chmod 400 ./rs-rsa-key.pem
Then re-run terraform apply.
The Guacamole Docker containers take several minutes to start after the instance boots. If you see a blank page, wait 3-5 more minutes and refresh. Check container status over SSH if the issue persists:
sudo docker ps
All three containers (guacamole/guacamole, postgres:15, guacamole/guacd) must be Up before the UI is available.
Symptom: Apache fails to start; sudo apache2ctl -S shows:
Invalid command '404:', perhaps misspelled or defined by a module not included
The redirector downloads redirect.rules from the redRules GitHub repo at boot. A network issue or timeout during cloud-init can leave the file empty or containing an error page.Verify the file contents:
head -3 /etc/apache2/redirect.rules
Re-download manually on the redirector:
curl -sL "https://raw.githubusercontent.com/BaddKharma/redRules/main/redirect.rules" \
  -o /etc/apache2/redirect.rules
sudo apache2ctl configtest && sudo systemctl reload apache2
Symptom: The mythic_nginx container keeps restarting. Logs show:
[emerg] cannot load certificate "/etc/ssl/private/mythic-cert.crt": No such file or directory
Generate the certificate manually:
sudo openssl req -x509 -newkey rsa:4096 \
  -keyout /etc/ssl/private/mythic-cert.key \
  -out /etc/ssl/private/mythic-cert.crt \
  -days 365 -nodes -subj "/CN=mythic"

cd /opt/Mythic
sudo ./mythic-cli restart
Verify:
sudo ./mythic-cli status
# mythic_nginx should now show "running (healthy)"
Symptom: mythic-cli status shows containers not running.
cd /opt/Mythic
sudo ./mythic-cli logs     # check for errors
sudo ./mythic-cli restart
Common causes:
  • Docker is still pulling images — wait 5 minutes after initial deploy
  • Port conflict — check with sudo netstat -tlnp
  • Insufficient memory — consider upgrading to t3.large in terraform.tfvars
  • Missing SSL certificate — see Mythic nginx SSL certificate missing above
Symptom: sliver-server command not found.Check the cloud-init log for installation errors:
sudo cat /var/log/user-data.log
Re-run the installation:
curl https://sliver.sh/install | sudo bash
Symptom: Havoc teamserver binary not found or service fails to start.Check the cloud-init log:
sudo cat /var/log/user-data.log
Verify Go is installed:
/usr/local/go/bin/go version
Rebuild manually:
cd /opt/Havoc/teamserver
sudo -E /usr/local/go/bin/go build -o teamserver .

# Start manually to see errors in real time
./teamserver server --profile /opt/Havoc/profiles/default.yaotl
Work through this checklist before digging into logs:
  • Listener is running on the correct C2 server
  • callback_host / Hosts field points to the redirector’s domain or public IP
  • Agent includes the correct X-Request-ID header with the auto-generated token
  • Agent URI uses the correct prefix (/cdn/media/stream/, /cloud/storage/objects/, or /edge/cache/assets/)
  • Redirector Apache is running with all VirtualHosts enabled (sudo apache2ctl -S)
  • Redirector can reach the C2 server’s private IP (ping mythic from the redirector)
  • Agent user-agent string is not blocked by redirect.rules (check for known scanner or AV strings)
Debug on the redirector:
sudo apache2ctl -S
sudo systemctl status apache2
sudo tail -100 /var/log/apache2/redirector-ssl-access.log
sudo tail -100 /var/log/apache2/redirector-ssl-error.log
sudo /home/admin/test_redirector.sh
Error: InvalidKeyPair.NotFoundThe key pair name in terraform.tfvars does not match an existing key pair in AWS.
aws ec2 describe-key-pairs --query 'KeyPairs[].KeyName'
Update ssh_key_name in terraform.tfvars to match the actual key pair name.Error: VPC limit exceededAWS accounts have a default limit of 5 VPCs per region. redStack creates 2 (team server + redirector), so you need at least 2 free VPC slots. Either delete unused VPCs in the AWS console or switch to the default VPC:
# In terraform.tfvars
use_default_vpc = true