Contained lab network
GOAD systems were planned around a dedicated Proxmox bridge and distinct addressing space so vulnerable domain assets remained separated from normal lab services.
SECURITY RANGE CASE STUDY
GOAD Security Range
A segmented Active Directory attack-and-defense lab built to support hands-on security testing, Windows domain practice, adversary emulation, and defensive validation inside an isolated Proxmox network. The project focused on deploying intentionally vulnerable infrastructure safely by preparing clean VM baselines, using Terraform-driven provisioning, and keeping the range separated from normal home lab and management systems.
PROBLEM
Vulnerable Active Directory labs need containment before exploitation.
Hands-on Active Directory security practice requires realistic Windows domain infrastructure, but intentionally vulnerable environments cannot be treated like normal lab workloads. A GOAD-style lab introduces domain controllers, Windows servers, Linux support systems, insecure configurations, and attacker-accessible paths by design.
The challenge was not just deploying GOAD. The environment needed proper baselines before deployment, clean VM images that Terraform could use consistently, and a segmented Proxmox network that kept vulnerable systems boxed off from the rest of the lab.
This project became a practical introduction to infrastructure-as-code state management. Terraform was used to define and create lab resources, which meant the deployment process depended on clean configuration, predictable VM templates, and an understanding of how Terraform tracks resource state over time.
ARCHITECTURE
Terraform defines the range, Proxmox hosts it, and an isolated bridge contains it.
flowchart TD
OP[Operator] --> TF[Terraform Configuration]
TF --> API[Proxmox Provider / API]
API --> IMG[Clean VM Baseline Images]
IMG --> BRIDGE[Isolated Proxmox Bridge]
BRIDGE --> RANGE[GOAD Lab Network]
RANGE --> DC[Domain Controllers]
RANGE --> WIN[Windows Servers]
RANGE --> LNX[Linux Support Systems]
DC --> TEST[Attack, Validate, Revert, Rebuild]
WIN --> TEST
LNX --> TEST
Controlled deployment path
Terraform and a deployment host became the controlled path for creating, adjusting, and rebuilding the lab instead of relying on unmanaged manual VM creation.
INFRASTRUCTURE AS CODE MODEL
Terraform introduced a state-driven operating model.
Terraform was used as the deployment layer for the lab environment. This introduced a different operating model than manually creating each VM in the Proxmox interface. Instead of treating VM creation as a one-off click path, the lab required declarative configuration files, known baseline images, consistent VMIDs, network mappings, and Terraform state tracking.
flowchart LR
CFG[Desired Configuration] --> PLAN[Terraform Plan]
STATE[Terraform State] --> PLAN
REAL[Existing Proxmox Resources] --> PLAN
PLAN --> APPLY[Terraform Apply]
APPLY --> PVE[Proxmox VM Resources]
APPLY --> STATE2[Updated Terraform State]
Desired configuration
Terraform files described what the lab should look like, including VM definitions, identifiers, network placement, image sources, and deployment parameters.
Terraform state
Terraform state tracked what had already been created. Understanding state was necessary to know when a change would update, recreate, or fail against real Proxmox resources.
Baseline dependency
The deployment depended on clean VM baselines. If the source image was not prepared correctly, Terraform could create broken or inconsistent systems at scale.
Repeatable deployment
The long-term goal was a rebuildable range: define the lab, deploy the lab, test inside the lab, and tear down or rebuild with less manual drift.
BASELINE PREPARATION
Clean images had to exist before automated deployment could be trusted.
Before deploying the lab, the environment needed proper baseline images. This became a required step rather than an optional cleanup task. A clean image gives Terraform something predictable to clone or build from. Without that baseline, every downstream system can inherit problems from the template: wrong drivers, bad networking, leftover configuration, missing guest tools, or inconsistent authentication settings.
Clean image requirements
Baseline images needed validated operating system installs, virtual hardware behavior, network readiness, and settings required for Proxmox-based management.
Deployment consistency
Once a clean image existed, Terraform could use it as a repeatable starting point and reduce one-off manual differences between GOAD systems.
Failure reduction
A bad baseline creates repeated failures. Fixing the baseline first helped prevent the same issue from being copied into every deployed system.
Recovery support
Clean baselines also supported the recovery model. If the range was broken during testing, systems could be reverted or rebuilt from a known-good starting point.
SECURITY CONTROLS
The range was treated as unsafe infrastructure by design.
Isolated bridge
The GOAD network was built around a dedicated Proxmox bridge instead of sharing the normal management network. This created a clear boundary between intentionally vulnerable systems and the rest of the lab.
Separate addressing
The environment used a distinct address space for the security range, making it easier to identify GOAD assets, document the environment, and avoid accidental overlap with existing systems.
Controlled management path
Administration and deployment were performed through a management or deployment VM rather than giving every vulnerable workload direct access to the broader lab.
Terraform-controlled deployment
Terraform was used to reduce manual drift and make the lab more repeatable. Configuration files became the deployment source of truth instead of relying only on manual Proxmox changes.
Baseline image control
Clean VM images were treated as a prerequisite. The security range needed known-good deployment sources before vulnerable workloads were created.
Snapshot and rebuild readiness
Because GOAD is designed for testing, the environment needed a recovery model that supported breaking, reverting, and rebuilding systems without affecting unrelated lab services.
ENGINEERING WORK
The build required networking, baselines, Terraform configuration, and state awareness.
Proxmox network preparation
Created a dedicated virtual bridge for the GOAD security range and planned the lab around a separate network boundary to keep vulnerable domain infrastructure off the main lab network.
VMID planning
Reserved a separate VMID range for GOAD systems so the environment could stay organized and easy to distinguish from other lab workloads.
Clean baseline image creation
Prepared clean images for deployment so Terraform could create systems from a predictable starting point and reduce repeated configuration errors.
Terraform configuration
Reviewed and adjusted Terraform configuration files for Linux and Windows systems, including VM identifiers, network settings, template references, and environment-specific values.
Terraform state learning
Worked through the relationship between Terraform configuration, Terraform state, and the real Proxmox environment. State became a key learning point because it controls how Terraform understands what already exists and what needs to change.
Deployment host setup
Prepared a Linux-based management or deployment VM to support GOAD automation, configuration editing, Terraform execution, and build operations.
VALIDATION
Validation focused on containment, consistency, and rebuildability.
Network validation
Confirmed that GOAD systems landed on the intended isolated bridge and addressing space, preventing a vulnerable AD lab from appearing on the normal lab network.
Baseline validation
Validated clean images before deployment so downstream systems would inherit a known-good starting point rather than repeated template problems.
Terraform validation
Reviewed Terraform configuration before deployment to confirm VMIDs, network mappings, template references, and environment values were correct.
State validation
Treated Terraform state as part of the deployment workflow and learned how state drift or incorrect assumptions about existing resources can cause confusion during rebuilds or changes.
Isolation validation
Treated the range as separate from the rest of the lab. GOAD assets could communicate inside the range while access into and out of the range remained controlled.
Recovery validation
Designed for breakability. The workflow emphasized the ability to revert, rebuild, or redeploy rather than preserve every system as a permanent production workload.
OUTCOME
The project created the foundation for a safer, repeatable AD security range.
The GOAD project established the foundation for an isolated, Terraform-driven Active Directory security range inside Proxmox. Instead of placing vulnerable domain systems directly into the normal lab, the environment was designed around segmentation, clean baselines, declarative deployment, VM organization, and recovery planning.
The project also created a practical learning path for Terraform in a real infrastructure context. Terraform configuration and state became part of the deployment process, while clean images and network baselines became prerequisites for reliable automation.
The result is a safer and more repeatable path for hands-on security testing, AD exploitation practice, defensive validation, and student-style lab demonstrations without mixing intentionally vulnerable systems with core infrastructure.
LESSONS LEARNED
A security range is still infrastructure.
Baselines come before automation
Terraform can automate deployment, but it cannot fix a bad source image. Clean baselines are a prerequisite for reliable infrastructure automation.
Terraform state matters
Terraform state is how Terraform understands what exists, what changed, and what it should do next. Learning that relationship was a major part of this project.
Segmentation comes before exploitation
The first priority was not launching attacks or testing tools. The first priority was making sure the lab was placed in the right network boundary.
Rebuildability matters
Security ranges should be easy to reset. If a lab cannot be safely broken and rebuilt, it becomes harder to use for real testing.
NEXT PHASE
Complete deployment, validate the domain, and document controlled attack paths.
Planned improvements
- Domain controller validation.
- Windows host validation.
- Terraform cleanup and repeatable deployment testing.
- Snapshot and revert workflow.
- Attack path documentation.
- Detection and logging notes.
- Student and demo-safe walkthroughs.
Project Summary
Designed and deployed the foundation for a segmented GOAD Active Directory security range inside Proxmox using Terraform, clean VM baselines, an isolated virtual bridge, dedicated addressing, controlled management access, and recovery-focused workflows to support safe adversary emulation, Windows domain testing, and defensive validation without exposing core lab infrastructure.