GOAD Lab Kurulumu: Bir Dizüstünde İki Ormanlı Active Directory

Neden bir lab, neden bu lab

Dört bölümlük “Assessing Active Directory” serisi bir Kali host ve sıfır kimlik bilgisiyle başlar. Bu yazı ise ondan önce geleni anlatır: hedefin en başta nasıl kurulduğunu. Tek bir Domain Controller, bir günden sonra sana yeni bir şey öğretmeyi bırakır; çünkü gerçek Active Directory güvenler, delegasyon, sertifika hizmetleri ve ACL zincirleri üzerinden kırılır ve bu ilişkiler ancak birden fazla domain söz konusu olduğunda ortaya çıkar. Bu yüzden laboratuvar, Orange Cyberdefense’in GOAD (Game of Active Directory) projesidir: iki ormanı, üç domain’i ve beş Windows sunucusunu tek bir ağa, kırktan fazla kasıtlı yanlış yapılandırmayla birlikte sığdırır.

Aşağıdaki her şey gerçek: gücü tam da yeterli olan bir dizüstü, yamalanması gereken bir hypervisor ve neredeyse beş saat süren bir kurulum. Bunları olduğu gibi yazıyorum, çünkü “lab kurulumu” rehberlerinin çoğu pürüzsüz görünen ama gerçekte saatler alan adımları atlıyor. Oysa kurulumun nerede tıkandığını bilmek, laboratuvarı bir kez daha kurmak zorunda kaldığında saatler kazandırır.

Mimari

İki orman ve bir alt domain. sevenkingdoms.local orman köküdür; north.sevenkingdoms.local onun alt domain’idir; essos.local ise ormanlar arası güvenle bağlanmış ayrı bir ormandır. Üç Domain Controller bu yapıyı taşır, iki üye sunucu servisleri barındırır ve bir Linux makinesi de kurulum işini yapar.

Windows 11 host (VMnet4 · 192.168.56.1)
└── VMware Workstation 26H1
    ├── DC01   kingslanding  192.168.56.10  (WS2019 · sevenkingdoms.local · ADCS)
    ├── DC02   winterfell    192.168.56.11  (WS2019 · north.sevenkingdoms.local)
    ├── DC03   meereen       192.168.56.12  (WS2016 · essos.local)
    ├── SRV02  castelblack   192.168.56.22  (WS2019 · IIS + MSSQL)
    ├── SRV03  braavos       192.168.56.23  (WS2016 · MSSQL · LAPS)
    └── PROVISIONING         192.168.56.3   (Ubuntu 22.04 · Ansible jumpbox)

SRV02 bir north üyesi, SRV03 bir essos üyesidir ve sertifika otoritesi (CertSvc) DC01 üzerinde çalışır. Bu yapıyı iki güven bir arada tutar: sevenkingdoms ile north arasındaki örtük parent/child güveni ve essos’a uzanan ormanlar arası güven. Bu iki güven türü, serinin ilerleyen bölümlerinde saldırı yolunun omurgasını oluşturacak. Parent/child güveni tek bir orman içinde yatay hareketi, ormanlar arası güven ise bir ormandan diğerine geçişi mümkün kılar; bu yüzden laboratuvarın ölçeği, tek domainli bir kurulumdan çok daha gerçekçi bir saldırı grafiği üretir.

Host: kıl payı yeterli

Dürüst özet yeterli, ama sınırda. Altı VM, 8 çekirdekli bir makinede 12 vCPU (1.5× aşırı yükleme) ve toplam 32 GB’a karşı yaklaşık 20 GB RAM alır. Gerçek bir pentest tek seferde tek hedefe saldırdığı için boştaki VM’ler neredeyse hiç maliyet çıkarmaz. Ancak paralel bir Ansible çalışmasında makine sürünür; bu yüzden kurulum sabır ister. Tam kurulum 4 saat 42 dakika sürdü ve en yavaş adım, 600 saniyelik Ansible timeout’unu aşan bir DC03 yeniden başlatması oldu. Bu süre, donanımın yetersizliğinden çok, altı makinenin aynı anda yapılandırılmasından kaynaklanıyor; tek tek ilerlemek toplam süreyi kısaltmaz, yalnızca daha öngörülebilir hale getirir.

Kurulum: Vagrant, Ansible ve jumpbox

GOAD’ın desteklenen yolu, VM’leri oluşturmak için Vagrant ve içlerinde domain’leri kurmak için Ansible kullanmaktır. VMware üzerinde GOAD bir jumpbox modeli izler: Vagrant önce bir Ubuntu makinesi açar (.3 adresindeki PROVISIONING), GOAD kaynağını ona kopyalar, ardından Ansible jumpbox üzerinden WinRM ile her Windows VM’ine ulaşarak onu bir domain’e dönüştürür. Bu modelin avantajı, kurulum mantığının tek bir yerden yönetilmesi ve tekrarlanabilir olmasıdır. Vagrant makinelerin yaşam döngüsünü, Ansible ise içlerindeki yapılandırmayı üstlenir; iki araç birbirinden bağımsız çalıştığı için bir sorun çıktığında hangi katmanın bozulduğunu ayırt etmek de kolaylaşır.

Vagrant ──► 6 VMs (boxes: windows_2019 ×3, windows_2016 ×2, ubuntu ×1)
   │
   └─► scp GOAD source ──► jumpbox (.3)
                              │
                              └─► ansible-playbook build.yml
                                    ├── dc01 → AD + ADCS + trust
                                    ├── dc02 → child domain
                                    ├── dc03 → second forest
                                    ├── srv02 → IIS + MSSQL
                                    └── srv03 → MSSQL + LAPS

Sonuç, deterministik olarak kurulan ve tek komutla sökülüp yeniden kurulabilen bir laboratuvardır. Bu determinizm, deneyleri tekrarlanabilir kıldığı için en az teknik içerik kadar değerlidir.

Yamalanması gereken kısımlar

Temiz açıklama sürtünmeyi gizler. VMware Workstation 26H1 64-bit’e geçti ve bu geçiş, Vagrant’ın VMware utility’sini her biri ayrı bir yama gerektiren biçimlerde bozdu:

• WOW6432Node registry düzeltmesi — utility, VMware’ı 32-bit görünümde aradı ve bulamadı; bu yüzden HKLM\SOFTWARE\WOW6432Node\VMware, Inc.\VMware Workstation altında InstallPath ve ProductVersion değerlerinin oluşturulması gerekti.
• VMnet4 elle oluşturuldu — Vagrant ağı kendisi oluşturamadı (vmrest API’si 400 döndü), bu yüzden host-only ağ Virtual Network Editor içinde elle oluşturuldu.
• scp yol bozulması — GOAD’ın kopyalama adımı Windows ters bölü yollarını scp’ye geçirdi ve scp bunları uzak host sandı; çözüm olarak forward slash’e ve rsync yerine tar + scp yedeğine geçildi.
• fix_ip.ps1 scheduled-task — statik IP uygulamak, açılış sırasında WinRM TCP oturumunu öldürüp Vagrant’ı kilitliyordu; bu yüzden IP değişimi, oturum kapandıktan sonra çalışan bir scheduled task’a ertelendi.
• Python 3.14 configparser — set() ile yazılan yorum satırları config parser’ı bozdu; yazar da Python yorumlarına çevrildi.

Bunlar “lab kurulumu”nun gerçek içeriğidir. Araçlar olgundur, ama 64-bit bir hypervisor geçişi ve yeni bir Python sürümü tüm boru hattını kırmaya yeter; her başarısızlık, gerçekte olduğu şeyden çok bir provisioning hatası gibi göründü. Yamalar local-patches.diff olarak tutulur, böylece upstream bir git pull sonrasında da çalışmaya devam ederler. Buradaki genel ders şu: altyapı araçları yükseltildiğinde, kırılan şey genellikle araç değil, araçların birbirine varsaydığı arayüzlerdir.

Ağ: bilerek host-only

Laboratuvar ağı, VMnet4 üzerinde host-only bir 192.168.56.0/24 ağıdır: gateway yok, internet yok, DHCP yalnızca Vagrant’ın ilk WinRM teması için açık. VM’ler statik adres kullanır ve dışarı çıkış yolu yoktur; bir saldırı laboratuvarı için tam istediğin budur: internete ulaşamaz ve internet de ona ulaşamaz.

Saldırı makinesi (Kali) laboratuvara LAN üzerinden ulaşır: Windows host, fiziksel ağ ile VMnet4 arasında yönlendirme yapar (IPEnableRouter=1, iki arayüzde forwarding açık) ve istemcinin yalnızca 192.168.56.0/24 için bir route’a ihtiyacı vardır. Bütün bunlardan yazılmaya değer kural şudur: host-only tut ve içeri yönlendir — VMnet4’ü kurumsal bir ağa bridge’leme. Bu kural, laboratuvarın yanlışlıkla dış dünyaya açılmasını engeller. Gateway’in bilinçli olarak yokluğu, VM’lerin dışarı sızmasını da, dışarıdan birinin içeri sızmasını da engeller; yalnızca senin yönlendirdiğin trafik geçer.

Laboratuvarı çalıştırmak

cd C:\Users\pwc-cyber\GOAD
$env:PATH = 'C:\Program Files\Vagrant\bin;' + $env:PATH
$I = '6c9cb8-goad-vmware'

.\.env\Scripts\python.exe goad.py -t status   -l GOAD -p vmware -i $I
.\.env\Scripts\python.exe goad.py -t start    -l GOAD -p vmware -i $I
.\.env\Scripts\python.exe goad.py -t stop     -l GOAD -p vmware -i $I
.\.env\Scripts\python.exe goad.py -t snapshot -l GOAD -p vmware -i $I
.\.env\Scripts\python.exe goad.py -t reset    -l GOAD -p vmware -i $I

VM’ler headless çalışır: vmrun list onları gösterir, ama Workstation arayüzünde asla görünmezler ve onları GUI’den kapatmamalısın (Vagrant’ın durum takibini bozar). Teste başlamadan önce bir snapshot alındı; böylece bozulan bir laboratuvar bir -t reset uzağında kalır. Bu alışkanlık, her deneyden önce temiz bir başlangıç noktası sağlar ve başarısız bir denemenin laboratuvarı kalıcı olarak bozmasını engeller.

Önceden bilmeye değer kimlik bilgileri

Laboratuvarın giriş noktaları şunlardır: her domain’in bilinen bir Domain Admin’i vardır ve kullanıcı/grup/ACL kataloğunun tamamı tek bir dosyada, ad/GOAD/data/config.json içinde yaşar; bu dosya tek doğru kaynaktır:

Bunun kazandırdığı şey

Laboratuvar ayakta olduğunda saldırı yüzeyi meselenin tamamıdır: Kerberoasting ve AS-REP roasting, constrained ve unconstrained delegation, sekiz adımlı ACL zincirleri, AD CS ESC1–ESC15, MSSQL linked server’lar, LAPS ve daha fazlası. Takip eden seri, bu tekniklerin her birini tek tek, yanında tespiti ve düzeltmesiyle birlikte yürür. Seri, GOAD Bölüm 1: Sıfır Kimlik Bilgisinden Saldırı Grafiğine ile başlar. Buradaki amaç, teknikleri ezberletmek değil; her birinin hangi yapılandırma hatasına dayandığını göstermektir. Laboratuvar bu yüzden yalnızca bir saldırı alanı değil, aynı zamanda savunma tarafının nerede neyi izlemesi gerektiğini gösteren bir haritadır.

Kanıt ve sınırlar

Bu yazı, ThinkPad X1 Carbon üzerinde tamamlanan tek bir GOAD kurulumunu kaydeder: altı makinenin envanteri, VMnet4 topolojisi, 4 saat 42 dakikalık provisioning çalışması, karşılaşılan kesin hata noktaları ve instance’ı başlatmak, durdurmak, snapshot almak ve sıfırlamak için kullanılan komutlar. Yukarıdaki hesap ve parolalar başka bir ortamdan değil, GOAD’ın kasıtlı olarak zayıf bırakılmış fixture’larından gelir.

Sonuç, her VMware veya GOAD sürümü için bir benchmark değildir. Registry, scp, statik IP ve Python yamaları bu Windows 11 / VMware Workstation 26H1 / Python 3.14 birleşimini anlatır. Farklı bir provider veya sürüm başka bir yerde kırılabilir. Laboratuvar gateway olmadan host-only kaldı; burada hiçbir şey üretim ya da üçüncü taraf bir ağa karşı çalıştırılmadı. Bu sınır, yazıdaki tüm sonuçların yalnızca bu izole laboratuvar ortamı için geçerli olduğunu da açıkça ortaya koyar ve okuyucunun aynı adımları kendi ortamında körü körüne tekrarlamaması gerektiğini hatırlatır.

Referanslar

• Orange Cyberdefense, GOAD: orange-cyberdefense.github.io/GOAD
• Vagrant: vagrantup.com
• Ansible: docs.ansible.com
• VMware Workstation Pro: techdocs.broadcom.com