--- title: "GOAD Lab Kurulumu: Bir Dizüstünde İki Ormanlı Active Directory" description: "Tüm serinin temel yazısı: iki ormanlı, üç domain'li bir Active Directory laboratuvarının bir ThinkPad üzerinde çıplak donanımdan nasıl kurulduğu, Vagrant ve Ansible'ın gerçekte ne yaptığı, yamalanması gereken VMware pürüzleri ve laboratuvarın nasıl başlatılıp snapshot alındığı ve Kali'den nasıl erişildiği." date: 2026-11-02 author: Sevban Dönmez (@jankesec) canonical: https://jankesec.com/tr/yazilar/goad-lab-setup/ --- ## 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)](https://orange-cyberdefense.github.io/GOAD/) 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) ```

Kurulduğu haliyle laboratuvar sınırı: makineleri Vagrant oluşturur, jumpbox yapılandırır ve tüm hedefler izole host-only ağda kalır.

| Domain | NetBIOS | DC | Tür | | --- | --- | --- | --- | | `sevenkingdoms.local` | SEVENKINGDOMS | DC01 (.10) | orman kökü | | `north.sevenkingdoms.local` | NORTH | DC02 (.11) | alt domain | | `essos.local` | ESSOS | DC03 (.12) | ayrı orman | `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 | Bileşen | Değer | | --- | --- | | Makine | ThinkPad X1 Carbon | | CPU | Intel Core Ultra 7 268V — 8 çekirdek / 8 thread | | RAM | 32 GB | | OS | Windows 11 | 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. | VM | vCPU | RAM | | --- | --- | --- | | DC01 / DC02 / DC03 | 2 | 2048 MB | | SRV02 | 2 | 4096 MB | | SRV03 | 2 | 3584 MB | | PROVISIONING | 2 | 2000 MB | ## 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. ```bash 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. | Ayar | Değer | | --- | --- | | Ağ | VMware `VMnet4`, host-only | | Subnet | `192.168.56.0/24` | | Host IP | `192.168.56.1` | | Gateway | yok | | DNS (lab içi) | `192.168.56.10` | 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 ```powershell 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: | Kapsam | Hesap | Şifre | | --- | --- | --- | | sevenkingdoms DA | `robert.baratheon` | `iamthekingoftheworld` | | sevenkingdoms DA | `cersei.lannister` | `il0vejaime` | | north DA | `eddard.stark` | `FightP3aceAndHonor!` | | essos DA | `daenerys.targaryen` | `BurnThemAll!` | | MSSQL SA (SRV02) | `sa` | `Sup1_sa_P@ssw0rd!` | | MSSQL SA (SRV03) | `sa` | `sa_P@ssw0rd!Ess0s` | ## 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](/tr/yazilar/opening-an-active-directory-assessment/) 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](https://orange-cyberdefense.github.io/GOAD/) - **Vagrant:** [vagrantup.com](https://www.vagrantup.com/) - **Ansible:** [docs.ansible.com](https://docs.ansible.com/) - **VMware Workstation Pro:** [techdocs.broadcom.com](https://techdocs.broadcom.com/us/en/vmware-cis/desktop-hypervisors/workstation-pro/26H1.html)