Active Directory’yi Ele Gecirme Teknikleri Serisi – Bolum 1: Giris ve Kerberoasting

Merhaba

Eylül 2026’da Avustralya Signals Directorate (ASD), ABD Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Kanada Canadian Centre for Cyber Security (CCCS), Birleşik Krallık National Cyber Security Centre (NCSC-UK) ve Yeni Zelanda National Cyber Security Centre (NCSC-NZ) ortaklaşa “Detecting and Mitigating Active Directory Compromises” başlığıyla güncellenmiş bir rehber yayımladı. Bu rehber, Active Directory Domain Services (AD DS), Active Directory Certificate Services (AD CS) ve Active Directory Federation Services (AD FS) ortamlarına yönelik 17 yaygın tekniği ele alıyor ve her biri için tespit ve mitigasyon önerileri sunuyor. Bu yazı dizisinde, rapordaki her tekniği sırasıyla Türkçe’ye uyarlayarak işleyeceğim: tekniğin nasıl çalıştığı, nasıl mitigasyon uygulanacağı, nasıl tespit edileceği ve ilgili Event ID’ler. Rapor teknikleri, saldırganların genellikle izlediği mantık zinciriyle sıralı şekilde ele alıyor: önce yetki yükseltme ve yanal hareket için kullanılan teknikler, ardından kalıcılık (persistence) sağlamak için kullanılan teknikler. Ben de aynı sırayı takip edeceğim. Mümkün olduğunda, kendi Windows Server 2025 lab ortamımda tekniği çalıştırıp Event Viewer çıktılarını ve ilgili ayar ekranlarını da paylaşacağım.

Ayrıcalıklı Erişimi Güvenceye Almak: Serinin Çerçevesi

Rapor boyunca tekrarlanan en temel öneri, ayrıcalıklı erişimin (privileged access) güvenceye alınmasıdır. Active Directory’ye yönelik kötü niyetli faaliyetin acil hedefi, Domain Admins ve Enterprise Admins gibi en yüksek yetkili güvenlik gruplarındaki kullanıcı objelerini hedef alarak domain’in kontrolünü ele geçirmektir. Bunu önlemek için Microsoft’un Enterprise Access Model‘i gibi katmanlı (tiered) bir model kullanılması öneriliyor. Bu model, önceki Active Directory Administrative Tier Model’in yerini alan ve Active Directory’nin Microsoft Entra ID gibi bulut servisleriyle Entra Connect veya AD FS üzerinden bağlandığı hibrit ortamlar için tasarlanmış bir yaklaşımdır. Temel ilkeleri şunlardır:

  • Tier 0 kullanıcı objeleri kimlik bilgilerini daha alt katmandaki sistemlere maruz bırakmaz. Tier 0 kullanıcı objeleri; Domain Admins ve Enterprise Admins güvenlik gruplarındaki kullanıcılar, KRBTGT kullanıcı objesi, AD FS servis hesabı, yedekleme yöneticileri ve Microsoft Entra Connect kullanıcı objeleri gibi domain’de önemli erişime sahip her türlü kullanıcı objesidir.
  • Tier 0 bilgisayar objeleri yalnızca Tier 0 kullanıcı objeleri tarafından yönetilir. Tier 0 bilgisayar objeleri arasında Domain Controller’lar, AD FS sunucusu, AD CS kök sertifika otoritesi, yedekleme sunucuları ve Microsoft Entra Connect sunucusu bulunur.
  • Alt katmanlardaki (Tier 1 veya Tier 2) kullanıcı ve bilgisayar objeleri üst katmanların sağladığı servisleri kullanabilir, ancak tersi mümkün değildir.
  • Hiyerarşi, alt katmanların üst katmanları kontrol etmesini engelleyecek şekilde uygulanır.
  • Ayrıcalıklı erişim yolları (pathways); bu yolların sayısı minimize edilerek, korumalar uygulanarak ve yakından izlenerek güvenceye alınır.

Tier 0 kullanıcı ve bilgisayar objeleri, en azından phishing-resistant MFA, privileged access workstation kullanımı, Kerberos armoring ve zero trust politika uygulaması gibi ek güvenlik korumalarına sahip olmalıdır. Microsoft’un Enterprise Access Model’ini uygulamak, Active Directory’ye karşı kullanılan birçok tekniği belirgin şekilde zorlaştırır ve bazılarını imkansız hale getirir. Saldırganlar bu durumda daha karmaşık ve riskli tekniklere başvurmak zorunda kalır, bu da tespit edilme olasılıklarını artırır.

Kerberoasting

Serinin ilk tekniği olan Kerberoasting, service principal name (SPN) ile yapılandırılmış kullanıcı objelerini istismar eder. Bir kullanıcı objesi SPN ile yapılandırılmışsa, domain’deki başka herhangi bir kullanıcı objesi (yetkisiz kullanıcılar dahil) bu obje için bir ticket granting service (TGS) ticket’i talep edebilir (bu, kullanıcı objelerinin servislerle etkileşime girmesine izin veren, tasarım gereği var olan bir işlevdir). TGS ticket’i, kullanıcı objesinin parola hash’i ile şifrelenir; bu hash çevrimdışı kırılarak düz metin parola ortaya çıkarılabilir. Saldırganlar TGS ticket’ini kırıp düz metin parolayı elde ederse, o kullanıcı objesi olarak kimlik doğrulaması yapabilir. Saldırganlar genellikle Active Directory domain’ine ilk erişimi elde ettikten kısa süre sonra yetki yükseltmek ve yanal hareket etmek için Kerberoasting uygular. SPN ile yapılandırılan kullanıcı obje türleri genellikle servis hesabı (service account) olarak adlandırılır; bunlar bilgisayar objelerinde çalışan servisleri işleten kullanıcı objeleridir ve yönetimsel yetkilere sahip olabilirler. Bu servis hesaplarından biri Kerberoasting yoluyla ele geçirilirse, genellikle Active Directory ortamını daha ileri seviyede ele geçirmek için kullanılabilecek ek yetki ve erişim sağlar. Bazı durumlarda servis hesapları, Domain Admins gibi yüksek yetkili güvenlik gruplarının üyesi olabilir; bu durumda Kerberoasting, domain’in tam olarak ele geçirilmesiyle sonuçlanabilir. Kerberoasting’i gerçekleştirebilen birden fazla offensive security aracı vardır (örneğin Mimikatz, Rubeus ve Impacket). Native PowerShell komutlarıyla da Kerberoasting gerçekleştirilebilir.

Kerberoasting Nasıl İşler

  1. Saldırgan, SPN ile yapılandırılmış bir kullanıcı objesi için Domain Controller’dan TGS ticket’i talep eder.
  2. Domain Controller, TGS ticket’iyle yanıt verir.
  3. Saldırgan, TGS ticket’ini kırarak düz metin parolayı ortaya çıkarır ve kullanıcı objesi olarak kimlik doğrulaması yapar.

Kerberoasting’i Mitigasyon Etmek

Kerberoasting, normal Active Directory işlevselliğini taklit eder ve SPN ile yapılandırılmış kullanıcı objeleri bulunan her Active Directory ortamında uygulanabilir bir tekniktir. Aşağıdaki güvenlik kontrolleri Kerberoasting’i mitigasyon etmek için uygulanmalıdır:

  • SPN ile yapılandırılmış kullanıcı objesi sayısını minimize edin. Bu, saldırganların Kerberoasting uygulaması için saldırı yüzeyini azaltır.
  • SPN’li kullanıcı objelerini group Managed Service Account (gMSA) olarak oluşturun. gMSA’lar otomatik parola rotasyonuna ve 120 karakterlik bir parolaya sahiptir, SPN yönetimini basitleştirir. Bu güvenlik özellikleri parolanın kırılmasını zorlaştırarak Kerberoasting’in başarılı olma olasılığını düşürür. Ancak SPN’li kullanıcı objelerini gMSA olarak oluşturmak uygun değilse (örneğin sistem Windows tabanlı değilse veya uygulama gMSA’yı tam olarak desteklemiyorsa, System Center Configuration Manager gibi), benzersiz, tahmin edilemez ve yönetilen minimum 30 karakterlik bir parola belirlenmelidir.
  • SPN’li kullanıcı objelerine, işlevlerini yerine getirmek için gereken minimum yetkileri atayın ve bunların Domain Admins gibi yüksek yetkili güvenlik gruplarının üyesi olmadığından emin olun. Saldırganlar Kerberoasting’i başarıyla uygulayıp TGS ticket’ini kırarsa, kullanıcı objesine atanan yetkilerin minimize edilmesi etkiyi azaltır ve saldırganın elde ettiği erişimi sınırlar.
  • SPN ile yapılandırılmış kullanıcı objeleri için Advanced Encryption Standard (AES) şifrelemesini etkinleştirin. Active Directory varsayılan olarak TGS ticket’ları için RC4 şifrelemesi kullanır, bu da parola kırmaya karşı savunmasızdır. AES şifrelemesinin zorunlu kılınması, TGS ticket’larını kırmak için gereken süreyi ve hesaplama efor’unu belirgin şekilde artırır, böylece Kerberoasting’in başarılı olma olasılığını azaltır. Ayrıca saldırganlar Kerberoasting sırasında şifreleme türünü genellikle RC4’e düşürmeye çalışır; kimlik doğrulama loglarında bu şifreleme türünün varlığı Kerberoasting’in gerçekleştiğine dair bir gösterge olabilir.

Kerberoasting’i Tespit Etmek

Kerberoasting’i tespit etmek zor olabilir çünkü bu teknik meşru Active Directory aktivitesini yansıtır. Kullanıcı objeleri domain’deki servislere erişirken TGS ticket’i talep eder ve bu meşru aktivite için üretilen olaylar, Kerberoasting tarafından üretilenlerle aynıdır. Bu durum, Kerberoasting’in loglanan çok sayıda meşru olay arasında gözden kaçmasına neden olabilir. Kerberoasting’i tespit etmenin bir yöntemi, TGS talep olaylarını (event 4769) analiz etmek ve kısa bir zaman aralığında SPN ile yapılandırılmış birden fazla kullanıcı objesi için TGS taleplerinin yapıldığı durumları tespit etmektir. Kerberoasting tipik olarak SPN’li tüm kullanıcı objeleri için TGS ticket’larının eş zamanlı olarak alınmasını içerir. Kısa bir süre içinde SPN’li çok sayıda kullanıcı objesi için TGS ticket talep olaylarının (event 4769) varlığı, Kerberoasting’in gerçekleştiğine işaret edebilir. Bir diğer tespit yöntemi ise servislere yönelik olağandışı TGS taleplerini analiz etmektir; örneğin, normalde yalnızca diğer sunucular tarafından erişilen bir yedekleme sunucusu gibi, talep eden kullanıcı veya bilgisayar objesinin normalde erişmediği servislere yönelik TGS talepleri buna örnek olabilir. Aşağıdaki Event ID’ler merkezi olarak loglanmalı ve zamanında analiz edilmelidir

Tablo 1. Kerberoasting’i Tespit Eden Olaylar

Event ID Kaynak Açıklama
4738, 5136 Domain Controller’lar Bir kullanıcı hesabı değiştirildiğinde üretilir. Saldırganlar kullanıcı objelerini değiştirip Kerberos service ticket’i alabilmek için SPN ekleyebilir. TGS ticket alındıktan sonra kullanıcı objesi tekrar değiştirilir ve SPN kaldırılır.
4769 Domain Controller’lar Bir TGS ticket’i talep edildiğinde üretilir. Saldırganlar Kerberoasting uyguladığında, talep edilen her TGS ticket’i için bu olay üretilir. Saldırganlar genellikle Rivest Cipher 4 (RC4) şifrelemesiyle TGS talep eder, çünkü bu ticket’lar kırılarak düz metin parola elde etmek daha kolaydır. RC4 şifrelemesiyle TGS talep edilirse, event 4769 için Ticket Encryption type değeri ‘0x17’ olur. Bu şifreleme türü daha az kullanıldığından, bu türle üretilen 4769 olaylarının daha az olması beklenir, bu da potansiyel Kerberoasting aktivitesini tespit etmeyi kolaylaştırır. Ayrıca yaygın offensive security araçları Ticket Options değerini ‘0x40800000’ veya ‘0x40810000’ olarak ayarlar; bu değerler Kerberoasting’i tespit etmek için kullanılabilir.

Bu teknik, Active Directory canary’leri yardımıyla da tespit edilebilir; bu konuyu serinin son bölümünde ele alacağım.

Lab Uygulaması: Windows Server 2025 Üzerinde Kerberoasting

Yukarıdaki teoriyi kendi Windows Server 2025 lab ortamımda pratikte gösterelim. Harici bir saldırı aracı (Rubeus, Impacket vb.) kullanmadan, yalnızca native PowerShell ile bir TGS ticket’i talep ederek Kerberoasting’in Domain Controller tarafında nasıl bir iz bıraktığını inceleyeceğiz. Test ortamında svc-sqltest adında, MSSQLSvc/sqltest.lab.local:1433 SPN’i ile yapılandırılmış bir servis hesabı var. Kerberoasting’in klasik senaryosunu göstermek için bu hesabın msDS-SupportedEncryptionTypes özniteliğini 4 (yalnızca RC4-HMAC) olarak ayarladım; böylece Domain Controller, AES yerine zayıf RC4 şifrelemesiyle ticket üretmek zorunda kalıyor. Gerçek ortamlarda bu zafiyet, hesap AES için doğru yapılandırılmadığında veya eski uygulama uyumluluğu gerekçesiyle RC4’ün açık bırakıldığı durumlarda kendiliğinden ortaya çıkar. Aşağıdaki komutla, herhangi bir kimlik doğrulanmış domain kullanıcısı olarak bu SPN için bir TGS ticket’i talep ediyorum:

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/sqltest.lab.local:1433"

PowerShell konsolunda komutun çalıştırılması ve dönen ticket bilgileri (Id, ValidFrom/ValidTo, ServicePrincipalName, SecurityKey): Komut çalıştığı anda Domain Controller üzerinde Event ID 4769 (A Kerberos service ticket was requested) kaydı oluşuyor. Event Viewer’da bu kaydın General sekmesinin üst kısmında talep eden hesap ([email protected]), hedef servis hesabı (svc-sqltest) ve servis hesabının MSDS-SupportedEncryptionTypes: 0x4 (RC4) olarak ayarlandığı görülüyor:

Event ID 4769 detayı – hesap ve servis bilgileri: Kaydın devamında, Additional Information bölümünde asıl aradığımız alanlar yer alıyor. Ticket Encryption Type: 0x17 ve Session Encryption Type: 0x17 değerleri, DC’nin bu TGS ticket’ini RC4-HMAC ile şifrelediğini doğruluyor; bu da tam olarak rapordaki tespit kriterine karşılık geliyor. Ticket Options: 0x40810000 değeri de yaygın offensive security araçlarının bıraktığı imzayla eşleşiyor:

Event ID 4769 detayı – RC4 şifreleme kanıtı: Bu üç ekran görüntüsü, Kerberoasting’in rapor da anlatıldığı gibi tamamen meşru bir Kerberos akışının içinde, hedef servisin gerçekten çalışıyor olmasına dahi gerek kalmadan nasıl gerçekleştirilebildiğini ve Event ID 4769 üzerinden nasıl tespit edilebileceğini somut biçimde gösteriyor. Servis hesabı AES’e zorlansaydı (msDS-SupportedEncryptionTypes değeri AES256’yı da kapsayacak şekilde ayarlansaydı), aynı komut Ticket Encryption Type alanında ‘0x12’ (AES256) döndürecek ve saldırganın çevrimdışı kırma girişimi çok daha maliyetli hale gelecekti.

 

Uyumluluk ve Çerçeve Eşlemesi

Çerçeve İlgili Kontrol/Madde
PCI DSS Gereksinim 8.2 (Güçlü kimlik doğrulama), Gereksinim 8.3 (MFA)
HIPAA 164.312(d) – Kişi veya Varlık Kimlik Doğrulaması
ISO 27001 A.9.2 (Kullanıcı Erişim Yönetimi), A.9.4 (Sistem ve Uygulama Erişim Kontrolü)
KVKK Madde 12 – Veri Güvenliğine İlişkin Yükümlülükler
TCMB Bilgi Sistemleri Yönetimi Tebliğ – Erişim ve Yetkilendirme Kontrolleri
NIST CSF PR.AC-1 (Kimlik ve kimlik bilgisi yönetimi), PR.AC-7 (Kimlik doğrulama)
CIS Controls CIS 5 (Hesap Yönetimi), CIS 6 (Erişim Kontrol Yönetimi)

MITRE ATT&CK: T1558.003 (Steal or Forge Kerberos Tickets: Kerberoasting)

 

Sonuç

Kerberoasting, Active Directory’ye ilk erişim sonrası en sık başvurulan yetki yükseltme tekniklerinden biri. SPN’li hesapların sayısını minimize etmek, gMSA kullanmak ve AES şifrelemesini zorunlu kılmak, bu tekniği büyük ölçüde etkisiz hale getiriyor. Serinin bir sonraki bölümünde, benzer bir mantıkla çalışan ancak Kerberos ön kimlik doğrulamasını (pre-authentication) hedef alan AS-REP Roasting tekniğini ele alacağız. Kaynak: Detecting and Mitigating Active Directory Compromises – ASD/CISA/NSA/CCCS/NCSC

Bir yanıt yazın

Başa Dön