Active Directory Sıkılaştırma Serisi Bölüm 4: Kerberos için AES Zorlaması

Merhaba

Active Directory Sıkılaştırma serisinin dördüncü bölümünde, kimlik doğrulamanın temel taşı olan Kerberos’un kriptografisine odaklanıyoruz. Konu: Kerberos’ta RC4 şifrelemesini bırakıp AES’i zorunlu kılmak.

Önceki bölümlerde NTLMv1, SMBv1 ve LDAP signing’i ele almıştık. Bu bölümde de benzer bir eski teknoloji borcunu kapatıyoruz: Kerberos biletlerinin hala zayıf RC4 ile şifrelenmesine izin veren yapılandırmayı sıkılaştırıp modern AES’e geçiyoruz. Bu, özellikle Kerberoasting adı verilen ve saldırganların çok sevdiği bir saldırı tekniğinin etkisini büyük ölçüde azaltır.

RC4 Neden Tehlikeli

Kerberos, kimlik doğrulama biletlerini (ticket) şifrelemek için farklı algoritmalar destekler. Bunların en eskisi ve en zayıfı RC4 (RC4-HMAC). AES ise bugünün standardı ve çok daha güçlü.

AES ile şifrelenmiş biletlerde bu tür çevrimdışı kırma pratikte çok daha zordur. Dolayısıyla RC4’ü devre dışı bırakıp AES’i zorunlu kılmak, Kerberoasting saldırısının en etkili panzehirlerinden biridir. RC4’ün yanı sıra çok daha eski olan DES algoritması da tamamen kırılmış durumdadır ve modern ortamlarda hiçbir şekilde kullanılmamalıdır.

Windows Server 2025 ve Güncel Durum

Modern Windows sürümleri AES’i uzun süredir destekliyor ve varsayılan olarak tercih ediyor. Ancak geriye dönük uyumluluk adına RC4 pek çok ortamda hala kabul edilmeye devam ediyor. Bu, eski uygulamalar veya yanlış yapılandırılmış hesaplar nedeniyle sessizce açık kalmış bir risktir.

Windows Server 2025 bu konuda AES’e güçlü şekilde yaslanır, ancak AES destekleniyor ifadesi RC4 artık hiç kullanılmıyor anlamına gelmez. Doğru hedef, ortamı RC4’e artık ihtiyaç duymayacak hale getirip Kerberos’u AES-only olarak yapılandırmak. Ancak bunu körlemesine zorlamak, hala RC4’e bağımlı hesapların veya uygulamaların kimlik doğrulamasını kırabilir. Bu yüzden yaklaşım, önceki bölümlerdeki mantığın aynısı: önce görmek, sonra zorlamak.

Kerberos Şifreleme Türleri ve Bit Değerleri

Bir hesabın hangi şifreleme türlerini desteklediği, Active Directory’de msDS-SupportedEncryptionTypes özniteliğinde bit maskesi olarak tutulur. Aynı değer, makine tarafında registry’de SupportedEncryptionTypes olarak da yapılandırılır.

Bu değerler toplanarak bir maske oluşturur. En sık kullanılan hedef değer:

• AES-only (önerilen): 8 + 16 = 24 (0x18). Yalnızca AES128 ve AES256’ya izin verir; DES ve RC4’ü devre dışı bırakır.

Yani hedefiniz, ilgili hesapların ve GPO (Group Policy Object)’nun SupportedEncryptionTypes değerini 24 (0x18) yapmak.

Aşama 1: RC4 Kullanımını Tespit Etmek

Zorlamaya geçmeden önce ortamda hangi hesapların ve isteklerin hala RC4 kullandığını görmelisiniz. Bunu iki açıdan yaparsınız: Kerberos olay kayıtlarından ve hesap özniteliklerinden.

Kerberos Olaylarından Tespit

Domain Controller’larda Kerberos bilet istekleri şu olaylara kaydedilir:

• Event 4768: Kerberos kimlik doğrulama bileti (TGT) isteği
• Event 4769: Kerberos servis bileti isteği (Kerberoasting açısından en kritik olan budur)

Bu olaylardaki Ticket Encryption Type alanı, isteğin hangi algoritmayla şifrelendiğini gösterir.

Önemli değerler:

0x17 değeri gördüğünüz her kayıt, hala RC4 kullanan bir istektir.

Bu kayıtları toplamak için:

Get-WinEvent -FilterHashtable @{ LogName = "Security"; Id = 4769 } -MaxEvents 5000 |
    Where-Object { $_.Message -match "0x17" } |
    Select-Object TimeCreated, Message -First 50

Bu sorgu Security günlüğündeki Event 4769 kayıtları arasından 0x17 (RC4) içerenleri süzer. Çıktı boş dönerse, taranan pencerede RC4 ile şifrelenmiş servis bileti isteği yakalanmamış demektir; bu iyi bir işarettir, ancak periyodik işleri kaçırmamak için taramayı bir süre sürdürmek gerekir.

Hesap Özniteliklerinden Tespit

Hangi hesapların açıkça RC4’e ayarlı olduğunu ya da hiç şifreleme türü tanımlanmadığını görmek için msDS-SupportedEncryptionTypes özniteliğini sorgulayın. Özellikle SPN’e sahip servis hesapları Kerberoasting’in birincil hedefidir:

SPN’e Sahip (Servis) Hesapların Şifreleme Türü Ayarlarını listele:

Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties msDS-SupportedEncryptionTypes, ServicePrincipalName |
    Select-Object Name, msDS-SupportedEncryptionTypes, ServicePrincipalName

Çıktıda SPN’e sahip hesaplar ve şifreleme türü ayarları listelenir. Bu örnekte krbtgt hesabının msDS-SupportedEncryptionTypes değeri 0 görünüyor; bu, öznitelik açıkça ayarlanmadığı için varsayılan davranışın geçerli olduğu anlamına gelir ve pratikte RC4’e de izin verilebilir. Değeri 4 olan hesaplar ise açıkça RC4’e ayarlıdır.

Özniteliğin boş (null) olması, hesap için varsayılan davranışın geçerli olduğu anlamına gelir ki bu genellikle RC4’e de izin verir. Değeri 4 olan hesaplar açıkça RC4’e ayarlıdır.

Aşama 2: AES’i Zorunlu Kılmak

RC4 kullanan hesapları ve uygulamaları tespit edip AES’e uygun hale getirdikten sonra zorlamaya geçebilirsiniz. Bunu iki katmanda yaparsınız: makine düzeyinde GPO (Group Policy Object) ile ve hesap düzeyinde öznitelik ile.

Group Policy ile Makine Düzeyi

Ortam genelinde izin verilen şifreleme türlerini AES ile sınırlamak için:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network Security: Configure encryption types allowed for Kerberos

Bu politikada yalnızca AES128_HMAC_SHA1 ve AES256_HMAC_SHA1 kutularını işaretleyin; RC4 ve DES seçeneklerini işaretlemeyin. Bu, SupportedEncryptionTypes değerini 24 (0x18) yapar.

Adımlar sırasıyla şöyle:

Security Options altında Network security: Configure encryption types allowed for Kerberos politikasını bulun. Başlangıçta durumu genellikle Not Defined olur.

Politikayı çift tıklayın, Define these policy settings kutusunu işaretleyin ve yalnızca AES128_HMAC_SHA1 ile AES256_HMAC_SHA1 kutularını seçin. DES_CBC_MD5 ve RC4_HMAC_MD5 işaretsiz kalmalı. Ardından Apply‘a tıklayın.

Ayarın doğru olduğunu (Yalnızca AES128_HMAC_SHA1 ve AES256_HMAC_SHA1 seçili) teyit edip OK ile pencereyi kapatın.

Politika listesinde değerin artık AES128_HMAC_SHA1,AES256_HMAC_SHA1 olduğunu görürsünüz. Değişikliğin makinelere ulaşması için gpupdate /force çalıştırabilirsiniz.

Registry ile Uygulama (Tek Makine / Test)

İzole bir test veya tek makine senaryosu için registry doğrudan yazılabilir:

$krb = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters"
# 0x18 = 24 = AES128 + AES256 (RC4 ve DES devre disi)
Set-ItemProperty -Path $krb -Name SupportedEncryptionTypes -Value 0x18 -Type DWord

SupportedEncryptionTypes değeri 0x18 (24) olarak yazılıyor; yani yalnızca AES128 ve AES256, RC4 ve DES ise devre dışı. Bu, GPO ile aynı sonucu üreten registry karşılığıdır ve tek makine ya da test senaryoları için uygundur.

Hesap Düzeyinde AES Ayarı

Özellikle servis hesaplarında msDS-SupportedEncryptionTypes özniteliğini açıkça AES’e ayarlamak, o hesabın biletlerinin AES ile şifrelenmesini sağlar:

İlgili Servis Hesabını Yalnızca AES’e Ayarla (24 = AES128 + AES256)

Set-ADUser -Identity "svc-uygulama" -Replace @{ "msDS-SupportedEncryptionTypes" = 24 }

Set-ADUser -Replace ile ilgili servis hesabının msDS-SupportedEncryptionTypes değeri 24 (AES128 + AES256) yapılıyor; böylece o hesabın biletleri yalnızca AES ile şifrelenir. Komuttaki hesap adını kendi ortamınızdaki servis hesabıyla değiştirin.

Kurumsal ortamda önerilen yöntem, makine düzeyi için GPO (Group Policy Object), servis hesapları için ise öznitelik ayarının birlikte kullanılmasıdır.

krbtgt Hesabına Dikkat

Kerberos altyapısının kalbindeki krbtgt hesabı, biletlerin imzalanmasında kullanılır. Ortamı tam olarak AES’e taşımak için krbtgt hesabının da AES destekli olması ve parolasının (uygun aralıklarla ve iki kez) sıfırlanması gerekebilir. Bu işlem hassastır ve replikasyonun tamamlanmasını beklemeden iki kez üst üste yapılırsa kesintiye yol açabilir. krbtgt parola sıfırlamasını yalnızca planlı bir bakım penceresinde ve Microsoft’un önerdiği adımlarla yapın.

Doğrulama

Zorlamadan sonra, Domain Controller’lardaki Event 4769 kayıtlarında Ticket Encryption Type değerinin artık ağırlıklı olarak 0x12 (AES256) veya 0x11 (AES128) olduğunu görmelisiniz. Hala 0x17 (RC4) görünen kayıtlar varsa, ilgili hesap veya uygulama henüz AES’e taşınmamış demektir.

Sağlıklı bir sonuçta RC4 kayıtları ya tamamen kaybolur ya da yalnızca gerçekten güncellenmesi gereken birkaç eski istisnayı işaret eder.

Geri Alma (Rollback) Planı

Zorlama sonrası kritik bir uygulamanın kimlik doğrulaması kırılırsa, GPO (Group Policy Object) ayarını geri alıp gpupdate /force ile hızlıca eski davranışa dönebilirsiniz. Hesap düzeyinde ayarladıysanız, ilgili msDS-SupportedEncryptionTypes değerini geçici olarak RC4’ü de kapsayacak şekilde geri alabilirsiniz.

Ancak bunu kalıcı bir çözüm değil, yalnızca sorunlu hesabı veya uygulamayı AES’e taşıyana kadar geçici bir köprü olarak kullanın. Pilot yaklaşım burada da geçerlidir: değişikliği önce sınırlı bir kapsamda uygulayın, izleyin, ardından dalgalar halinde tüm ortama yayın.

Genel Görünüm

Kerberos’ta AES zorlaması, Kerberoasting başta olmak üzere kimlik bilgisi hırsızlığına dayalı saldırıların en etkili kapatma yollarından biri. RC4 ve DES gibi zayıf algoritmaları devre dışı bırakmak, saldırganın çevrimdışı parola kırma imkanını büyük ölçüde ortadan kaldırır.

İzlenecek yol serinin genel mantığıyla aynı: önce görünürlük (Event 4769’da 0x17 takibi ve hesap özniteliklerinin denetimi), sonra RC4’e bağımlı hesapları AES’e taşıma, ardından GPO (Group Policy Object) ile AES-only (0x18) zorlaması ve gerektiğinde krbtgt bakımı, en son da doğrulama. Bu sırayı koruduğunuzda hem Kerberoasting riskini büyük ölçüde kapatır hem de üretim ortamını kesintiye uğratmadan sıkılaştırmayı tamamlarsınız.

Serinin bir sonraki bölümünde LDAP channel binding zorlamasını ele alacağız. Kimlik altyapısını katman katman güçlendirmeye devam edeceğiz.

Uyumluluk ve Çerçeve Eşlemesi

Aşağıdaki tablo, serideki her sıkılaştırmanın hangi uyumluluk çerçevesi kontrolünü karşıladığını ve hangi MITRE ATT&CK tekniğini engellediğini özetler. Hiçbir çerçeve bu ayarları isim isim zorunlu tutmaz; sıkılaştırmalar ilgili kontrolleri karşılar. Bağlayıcılık: Zorunlu = PCI DSS (kart verisi), KVKK (TR), TCMB (finansal), HIPAA (ABD sağlık); Taahhüde bağlı = ISO 27001; Gönüllü = NIST CSF, CIS Controls.

Engellenen başlıca MITRE ATT&CK teknikleri: T1557 Adversary-in-the-Middle (NTLM relay), T1550.002 Pass-the-Hash, T1187 Forced Authentication

Başka bir yazımızda görüşmek dileğiyle…