# GOAD

This is my internal notes for getting GOAD - Game of Active Directory up and running on Proxmox.

# Install the essentials

apt update && apt install curl sudo tmux -y
curl -s https://ludus.cloud/install | bash

Server may reboot a few times and you'll lose SSH connectivity temporarily.

# Check install status

ludus-install-status

At the end of the install you'll get an API key. Write it down! You'll need it for the next step.

# Make an admin user

export LUDUS_API_KEY='ROOT.xxx'
ludus user add --name "Brian Johnson" --userid brian --admin --url https://127.0.0.1:8081

# Get that user's Proxmox creds

export LUDUS_API_KEY='brian.xxx'
ludus user creds get

# Download GOAD

sudo apt install python3.11-venv  
export LUDUS_API_KEY='brian.123@xxxx'
git clone https://github.com/Orange-Cyberdefense/GOAD.git ~/GOAD

# Install Ludus

git clone https://gitlab.com/badsectorlabs/ludus ~/ludus
cd ~/ludus/templates

# Build VM templates - 4 at a time

Note: before you do, edit ~/GOAD/extensions/ws01/providers/ludus/config.yml and put win10-22h2-x64-enterprise-template as the extension instead of the Win10 template name that comes by default. Here's what the file will then look like:

- vm_name: "-GOAD-WS01"
    hostname: "-WS01"
    template: win10-22h2-x64-enterprise-template
    vlan: 10
    ip_last_octet: 31
    ram_gb: 4
    cpus: 2
    windows:
      sysprep: true

Now you can build the templates:

# Add the templates you need for a full GOAD load:
cd ~/ludus/templates
ludus templates add -d ubuntu-22.04-x64-server
ludus templates add -d win10-22h2-x64-enterprise
ludus templates add -d win2016-server-x64
ludus templates add -d win2019-server-x64
ludus templates build -p 4

# Check the template list
ludus templates list

# Example output of templates list
+------------------------------------+-------+
|              TEMPLATE              | BUILT |
+------------------------------------+-------+
| debian-11-x64-server-template      | TRUE  |
| debian-12-x64-server-template      | TRUE  |
| kali-x64-desktop-template          | TRUE  |
| win11-22h2-x64-enterprise-template | TRUE  |
| win2022-server-x64-template        | TRUE  |
| ubuntu-22.04-x64-server-template   | TRUE  |
| win10-22h2-x64-enterprise-template | TRUE  |
| win2016-server-x64-template        | TRUE  |
| win2019-server-x64-template        | TRUE  |
+------------------------------------+-------+

Note: normally you can run ludus templates status to check status of the template install, but this will fail if you're building multiple templates at once with the -p flag.

# Install GOAD

cd ~/GOAD
./goad.sh -p ludus 

# Check the install
check

# Set lab to GOAD/GOAD-Light/NHA/SCCM/etc  
set_lab GOAD

# Set the first three octets of the range (optional)
set_ip_range 10.3.10

# Install
install

# Install the GOAD extensions (optional)

install_extension elk
install_extension exchange
install_extension ws01
install_extension wazuh

# Check range status

ludus range config get

ludus range status --user GOAD[plus numbers/digits that appear after the VMs in your lab

# Snapshot VMs (optional)

See this guide, but in general you could snapshot the whole range with:

ludus snapshots create <snapshot-name>

# Redeploy a range

You can follow these steps to redeploy a range:

# Redeploy just a specific VM

...one that might be having license issues (where 180 count is not resetting, for example):

ludus range deploy --limit GOAD0ffddd-GOAD-SRV01 --user GOAD0ffddd-GOAD-SRV01

Watch logs:

ludus range logs -f --user GOAD0ffddd

More information about adding a single VM to a range here

# Redeploy the WHOLE range

# Run GOAD shell and specify Ludus as provider
cd ~/GOAD
./goad.sh -p ludus

# List instances
list

# "Use" the one that needs redeployment
load xxx-goad-ludus (whatever the range name is)

# Kill it with fire (you'll be asked to confirm the destruction)!
destroy

# Keep tabs on its death
status

After "death" I found a problem (discussed here where even after rebuilding the range, the Windows VMs thought they only had a few days left of licensing (despite doing slmgr /rearm and rebooting).

So I trashed all the templates with:

ludus templates rm -n debian-11-x64-server-template
ludus templates rm -n debian-12-x64-server-template
ludus templates rm -n kali-x64-desktop-template
ludus templates rm -n win11-22h2-x64-enterprise-template
ludus templates rm -n win2022-server-x64-template
ludus templates rm -n ubuntu-22.04-x64-server-template
ludus templates rm -n win10-22h2-x64-enterprise-template
ludus templates rm -n win2016-server-x64-template
ludus templates rm -n win2019-server-x64-template

Then rebuild the templates:

# Readd the templates (sanity check)
cd ~/ludus/templates
ludus templates add -d ubuntu-22.04-x64-server
ludus templates add -d win10-22h2-x64-enterprise
ludus templates add -d win2016-server-x64
ludus templates add -d win2019-server-x64

# Build the templates
ludus templates build -p 4

# Check status on builds
ludus templates list

Before redeploying, I've found that the /root/.ssh/known_hosts file needs to have its previous GOAD hosts cleared out so that you don't get SSH key/security issues on next deployment. In those cases, I do this (assuming 10.3.10.x is my old subnet):

# Backup first just in case
cp /root/.ssh/known_hosts /root/.ssh/known_hosts.bak

# Remove all offending entries
for ip in $(seq 1 254); do
  ssh-keygen -f "/root/.ssh/known_hosts" -R "10.3.10.$ip"
done

# Troubleshooting

# Elasticsearch reset

I had an issue where Elasticsearch dashboard was all jacked up with messages like:

“Failed to retrieve privileges”
“License is not available”
“Kibana server is not ready yet”

# Reset Elasticsearch passwords

/usr/share/elasticsearch/bin/elasticsearch-setup-passwords interactive

# Test the new password

curl -u elastic:NewPass2026!!! http://10.3.10.50:9200

# Update Kibana config

In /etc/kibana/kibana.yml add:

elasticsearch.hosts: ["http://10.3.10.50:9200"]
elasticsearch.username: "elastic"
elasticsearch.password: "NewPass2026!!!"

# Restart services

sudo systemctl restart elasticsearch
sudo systemctl restart kibana

# Monitor logs

sudo journalctl -u kibana -f

# Check that dashboard are actually working

Elasticsearch accessible at http://10.3.10.50:9200
Kibana working at http://10.3.10.50:5601

# Installing/reinstalling just certain parts of a GOAD install

From the author:

Yes you can retry certain parts. Use `>provision_extension wazuh` to relaunch only wazuh provision once instance is selected.

# Wazuh manual agent install

Sometimes when installing/reinstalling goad, one or more servers complain that the Wazuh installation fails (typically SRV01). So I'll jump into that machine's VNC console in Proxmox and do this:

invoke-webrequest https://packages.wazuh.com/4.x/windows/wazuh-agent-4.8.2-1.msi -outfile c:\tmp\wazuh-agent

Then I just run the GOAD install command again:

install

There was also one time I had to do the next step, which is complete the manual install:

msiexec.exe /i c:\tmp\wazuh-agent /q WAZUH_MANAGER=ip.of.wazuh.box WAZUH_REGISTRATION_SERVER=ip.of.wazuh.box

# Wazuh server default password

Per this issue, if you need to get the various Wazuh passwords, login at the console (username: localuser, password: password) and then check the end of this file for the default Wazuh install password:

/opt/wazuh/wazuh-install-output.txt

# Winlogbeat install

Sometimes Windows systems don't get the winlogbeat.zip properly so I manually visit them from VNC console and install via PowerShell:

invoke-webrequest https://artifacts.elastic.co/downloads/beats/winlogbeat/winlogbeat-7.17.6-windows-x86_64.zip -outfile "c:\program files\elastic\winlogbeat\winlogbeat.zip"

# Debian router config

# iptables rules

I use a Hetzner server to setup two networks in my GOAD environment. One is configured with an extra external IP where the firewall terminates, and that LAN is 192.168.1.x. So in order to then have an Apache Guacamole server traverse from 192.168.1.x I like to back up the current iptables config and then modify a rule to allow traffic:

# Update and install iptables-persistent module
sudo apt update
sudo apt install iptables-persistent

# Backup current config
sudo iptables-save > 2025-xx-xx-iptables.original

# Punch in rules to allow 192.168.1.x to talk to the GOAD network of 10.3.10.x
sudo iptables -I LUDUS_DEFAULTS 2 -s 192.168.1.111/32 -d 10.3.0.0/16 -m comment --comment "192.168.1.111/32 IP to range forward rule" -j ACCEPT
sudo iptables -I LUDUS_DEFAULTS 3 -s 192.0.2.49/32 -d 10.3.0.0/16 -m comment --comment "opnsense to range forward rule" -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 10.3.10.0/24 ! -d 198.51.100.0/24 -o ens18 -j MASQUERADE

# Make rules persistent
sudo netfilter-persistent save

# Save the rules one more time
sudo iptables-save > 2025-xx-xx-iptables.golden

# Block LAN to WAN traffic

I had a few instances where Hetzner was complaining about scanning activity from inside my GOAD network. I could never figure out if it was indeed coming from students, but had this rule ready to block all GOAD-to-Internet traffic with this iptables rule if necessary:

# Block 10.3.10.x from hitting the Internet
sudo iptables -I LUDUS_USER_RULES 1 -s 10.3.10.0/24 -j DROP

# Remove rule when the coast is clear
sudo iptables -D LUDUS_USER_RULES -s 10.3.10.0/24 -j DROP

# Extend Windows licenses

You can extend them (I think) up to 3 times for a total of 540 days. When the countdown is running low on a Windows system, do this from cmd prompt:

slmgr /rearm

Check license expiration:

slmgr /xpr

More information about the technical bits behind license re-arm procedures, read this.