Kurumsal Ağların Sessiz Katili (Kerberoasting)

Fatih Yüksektepe

24 Haz

6 dakikada okunur

Yıllardır kurumsal ağlarla uğraşan biri olarak şunu rahatça söyleyebilirim: En tehlikeli saldırılar, ekranınızda alarm çalanlar değil, sistemin içinde haftalar boyunca sessizce dolaşanlardır. Kerberoasting tam da bu kategoriye giriyor.

Bir saldırganın, ağınıza sızdıktan sonra tek bir standart kullanıcı hesabıyla, herhangi bir zararlı yazılım çalıştırmadan, tamamen meşru protokolleri kullanarak en yetkili servis hesaplarınızın parolalarını çalmaya çalıştığını düşünün. Üstelik bunu yaparken ağ trafiğinizde neredeyse hiç iz bırakmadan. İşte Kerberoasting budur ve kurumların büyük çoğunluğu bu saldırı vektörüne hâlâ yeteri kadar hazır değil.

Kerberos ve Servis Biletleri

Kerberoasting'i anlatmadan önce, bu saldırının üzerinde yürüdüğü zemini, yani Kerberos protokolünü kısaca ele almak gerekiyor. Windows 2000'den bu yana Active Directory'nin varsayılan kimlik doğrulama mekanizması olan Kerberos, adını Yunan mitolojisindeki üç başlı köpek Kerberos'tan alır. İsimlendirme rastlantısal değil; protokol gerçekten de üç temel aktör üzerine kurulu: Kimlik doğrulaması isteyen istemci, erişilmek istenen hizmet ve her ikisine de güvenen aracı olan Anahtar Dağıtım Merkezi (KDC).

Sistem şöyle çalışır: Ağa giriş yapan bir kullanıcı, KDC'den önce bir Bilet Verme Bileti (TGT) alır. Bu bilet, etki alanındaki krbtgt hesabının özeti ile şifrelenmiş bir pasaport gibidir. Ardından kullanıcı bir SQL sunucusuna, bir dosya paylaşımına ya da başka bir hizmete erişmek istediğinde, bu TGT pasaportunu KDC'ye göstererek söz konusu hizmet için özel bir servis bileti (TGS) talep eder. KDC, bu bileti hedef hizmetin hesabının parola özetiyle şifreler ve istemciye gönderir.

Ve işte kritik nokta tam burada: KDC, bu bilet talebini yaparken istemcinin gerçekten o hizmete erişim yetkisi olup olmadığını kontrol etmez. Sadece etki alanında geçerli bir hesap olup olmadığına bakar. Yetkilendirme kontrolü, bilet sunulduğunda servise bırakılmıştır. Bu tasarım kararı, Kerberoasting saldırısının doğmasına zemin hazırlamıştır.

Haritanızı Saldırgana Veren Kayıt Sistemi

Active Directory'de Servis Asıl Adları (SPN), hangi hizmetin hangi hesap altında çalıştığını tanımlayan kayıtlardır. Örneğin MSSQLSvc/sqlserver.sirket.local:1433 şeklinde bir SPN, SQL Server'ın sql_servis_hesabi adlı bir AD kullanıcısıyla çalıştığını ilan eder.

Saldırgan gözüyle bakıldığında SPN'ler, ağdaki kritik sistemlerin ve bu sistemleri çalıştıran hesapların tam bir haritasıdır. Ama daha da önemlisi, bu harita herkese açıktır. Etki alanına dahil herhangi bir standart kullanıcı, LDAP sorgusuyla tüm SPN kayıtlarını listeleyebilir.

Saldırganların hedef aldığı hesaplar bilgisayar hesapları değildir; Windows, bilgisayar hesaplarının parolalarını her 30 günde bir, 120 karakterlik rastgele dizilerle otomatik günceller. Bu parolaları kırmak pratikte imkânsızdır. Asıl hedef, bir sistem yöneticisinin yıllar önce bir dosyanın üzerine yazarak belirlediği ve bir daha hiç dokunmadığı insan yapımı servis hesaplarıdır.

Beş Adımda Etki Alanını Ele Geçirmek

Kerberoasting saldırısı beş aşamada gerçekleşir ve her aşama bir öncekinden daha sinsi bir hal alır.

İlk Erişim: Saldırganın kurumsal ağda geçerli, doğrulanmış bir hesaba ihtiyacı var. Bu; bir phishing maili, ele geçirilmiş bir VPN hesabı ya da satın alınmış kimlik bilgileri olabilir. Dikkat edin: Bu hesabın hiçbir özel yetkiye sahip olması gerekmiyor. Şirketin yeni stajyerinin hesabı bile bu işi görür.

Keşif: Saldırgan LDAP sorguları çalıştırarak Active Directory içindeki tüm SPN kayıtlarını tarar, bilgisayar hesaplarını filtreler ve insan tabanlı servis hesaplarını listeye alır. Bu aşamada BloodHound veya Impacket'in GetUserSPNs.py betiği sıklıkla kullanılır.

Bilet Talebi: Hedeflenen SPN'ler için Etki Alanı Denetleyicisi'nden TGS bileti talep edilir. KDC hiçbir yetki kontrolü yapmadan bu biletleri üretir ve gönderir. Ağ trafiğinde görünen şey, tamamen meşru bir kimlik doğrulama talebidir.

Biletlerin Çıkarılması: Elde edilen biletler bellekten veya doğrudan ağ trafiğinden alınır. Impacket kullanıldığında biletler hedef makinenin belleğine hiç düşmeden saldırganın sistemine ulaşır. Mimikatz veya Rubeus kullanıldığında ise LSASS belleğinden çekilir.

Çevrimdışı Kırma: Saldırının en sinsi anı burasıdır. Biletler kurumun ağı dışına taşınır ve artık sizin güvenlik duvarlarınız, IDS'leriniz, EDR çözümleriniz bu süreci göremez. Hashcat ile saniyede milyarlarca tahmin yapılarak zayıf bir parola saatler, hatta dakikalar içinde kırılır. Parola ele geçirildiğinde, o yetkili servis hesabı artık saldırganın elindedir.

Teknik Borç ile Güvenlik Açığının Kesişimi

Bu saldırının neden bu kadar yaygın ve başarılı olduğunu anlamak için protokol mimarisinden çok kurumların insan alışkanlıklarına bakmak gerekiyor.

Sistem yöneticilerinin büyük çoğunluğu servis hesabı oluşturduğunda şunu düşünür: "Bu hesabın parolasını değiştirirsem, tüm bağlı servisleri tek tek güncellemem gerekir. Bir tanesini atlasam faturalama sistemi çöker. Daha iyi o hesabı olduğu gibi bırakayım." Ve Active Directory'deki "Parola hiçbir zaman süreyi doldurmaz" kutucuğunu işaretleyerek hesabı kendi haline bırakır.

Bu, yanlış bir tercih değil; operasyonel bir zorunluluğun getirdiği doğal bir reflekstir. Ama sonuç olarak ortaya 2010 yılında "Sirket2010!" parolasıyla oluşturulmuş, Domain Admins grubuna eklenmiş, üretim sistemlerini çalıştıran ve bir daha hiç dokunulmamış bir hesap çıkar. Bu hesap bugün hâlâ üretimde çalışıyor ve Kerberoasting için mükemmel bir hedef oluşturuyor.

Gartner'ın verilerine göre IT yardım masası çağrılarının yüzde 20 ila 50'si yalnızca parola sıfırlama taleplerinden oluşuyor. İnsan kullanıcılar için bile bu kadar yorucu olan süreç, onlarca farklı sunucuya bağlı servis hesapları için yöneticilerin gözünde gerçek bir kabusa dönüşüyor. Dolayısıyla parolalar değiştirilmiyor ve teknik borç her geçen yıl büyüyor.

RC4

Servis biletlerinin şifreleme yöntemi de bu tabloya ayrı bir boyut katıyor. RC4-HMAC algoritması, parolanın NTLM özetini doğrudan şifreleme anahtarı olarak kullandığı için herhangi bir salting işlemi yapmaz. Bu, aynı parolanın her zaman aynı şifreleme anahtarını üretmesi anlamına gelir. Saldırganlar önceden hesaplanmış tablolar ve devasa parola sözlükleri kullanarak bileti çok hızlı kırabilir.

AES-256 ile şifrelenmiş biletler çok farklı bir tablo sunar. Hesap adı ve etki alanı adı, parolanın özetine karıştırılarak güçlü bir salting oluşturur. Kırma süresi katlanarak artar. Microsoft bu gerçeği kabul ederek Windows Server 2025 ve Windows 11 24H2 sürümleriyle birlikte RC4'ü Kerberos kimlik doğrulamasında varsayılan olarak devre dışı bırakmayı planlamıştır. DES ise bu sürümde tamamen kaldırılmıştır.

Nasıl Tespit Edersiniz?

Kerberoasting'i tespit etmenin zorluğu, saldırının tamamen meşru Kerberos trafiği üzerinden gerçekleşmesidir. Ancak bu, tespiti imkânsız kılmıyor; sadece daha zekice bir bakış açısı gerektiriyor.

Windows Güvenlik Günlüklerindeki Event ID 4769 buradaki temel kaynağınızdır. Bu olay, her TGS bileti talebinde oluşur. Ama günde on binlerce meşru 4769 logu arasında asıl aradığınız şey belirli anormalliklerdir:

Birincisi, bilet şifreleme türü. Modern ortamlarda AES standart olmasına rağmen RC4 (0x17 hex değeri) ile şifrelenmiş bilet talepleri yüksek öncelikli alarm üretmelidir. Saldırganlar, kırmayı kolaylaştırmak için kasıtlı olarak RC4 talep eder.

İkincisi, kısa sürede çok sayıda farklı servis hesabı için bilet talebi. Meşru bir ortamda tek bir kullanıcı birkaç dakika içinde onlarca farklı servis hesabı için bilet talep etmez. Bunu gördüğünüzde Rubeus veya Impacket'in ağınızı taradığını düşünmeye başlayın.

SIEM çözümlerinizi veya XDR'ınızı bu korelasyonlar için yapılandırmanız, saldırıyı erken aşamada yakalamanın en pratik yoludur.

Bal Küpü Hesabı

Tespit mekanizmaları arasında en güvenilir yöntemlerden biri, Honeypot (Bal Küpü) servis hesabı kurgulamaktır. Yöntem basit ama çok etkili.

Ağda hiçbir gerçek servisi çalıştırmayan sahte bir AD hesabı oluşturun. Bu hesaba finans departmanındaki kritik bir veritabanını ya da intranet yönetim portalını çağrıştıran, saldırganın gözüne cazip görünecek bir SPN atayın. Parolasını 100 karakteri aşan, rastgele ve kırılması fiilen imkânsız bir dize olarak belirleyin. Ardından bu hesap için bir TGS talebi oluştuğunda anında uyarı verecek bir alarm kurun.

Meşru hiçbir sistem bu sahte hesabı hiçbir zaman aramaz. Dolayısıyla bu hesap için bir bilet talebi oluştuğu anda, ağınızda keşif yapıldığını kesin olarak bilirsiniz. Yanlış alarm oranı sıfıra yakındır.

gMSA ve AES Zorunluluğu

Tespiti konuştuk, ama asıl mesele saldırı yüzeyini daraltmaktır. Bu konuda iki temel strateji öne çıkıyor.

Grup Yönetilen Hizmet Hesapları (gMSA), operasyonel kabusu tamamen ortadan kaldırıyor. gMSA hesaplarında parola yönetimini sistem yöneticisi değil, doğrudan Active Directory üstlenir. 120 karakterlik rastgele parola her 30 günde bir hiçbir hizmet kesintisi yaşanmadan otomatik olarak yenilenir. Mevcut teknoloji ile bu parolaların kırılması pratikte mümkün değildir.

Kurulumu PowerShell üzerinden birkaç komutla yapılabilir:

# KDS Kök Anahtarı yoksa oluşturun

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

# gMSA hesabını oluşturun

New-ADServiceAccount -Name "SQLService_gMSA" `

    -DNSHostName "sql.sirket.local" `

    -PrincipalsAllowedToRetrieveManagedPassword "SQL_Sunucular_Grubu"

# İlgili sunucuda etkinleştirin

Install-ADServiceAccount -Identity "SQLService_gMSA"

Eski uygulamalar gMSA'yı desteklemiyorsa en az 35 karakterlik karmaşık parolalar belirleyin ve bunları bir PAM çözümüyle yönetin. Parolaları en fazla 60 veya 90 günde bir rotasyona tabi tutun.

AES şifrelemesini zorunlu kılmak için AD nesnelerinin msDS-SupportedEncryptionTypes niteliğini güncellemeniz gerekir:

# Hesabı yalnızca AES-256 destekleyecek şekilde yapılandırın

Set-ADUser -Identity "sql_servis_hesabi" `

    -Replace @{'msDS-SupportedEncryptionTypes' = 16}

Kritik bir not: Bu değişikliği yaptıktan sonra hesabın parolasını mutlaka bir kez sıfırlayın. Aksi takdirde, AD nesne özellikleri AES desteklediğini gösterse de Etki Alanı Denetleyicisi arka planda eski NTLM özetini kullanmaya devam eder ve RC4 bilet dağıtmayı sürdürür. Bu adım atlanırsa bütün yapılandırma işi boşa gider.

Ağınızdaki RC4'e hâlâ açık hesapları tespit etmek için şu sorguyu kullanabilirsiniz:

Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x7 `

    -and -not msDS-supportedEncryptionTypes -bor 0x18"

Bu Bir Sıfırıncı Gün Değil, Birikmiş İhmalin Faturası

Kerberoasting hakkında konuştuğumuzda aslında Kerberos protokolündeki matematiksel bir zafiyetten değil, yıllar içinde biriken operasyonel alışkanlıklardan ve teknik borçtan söz ediyoruz. Bu saldırı için yama bekleyen bir sıfırıncı gün yok. Siber suçlular, sizin altyapınızda ne kadar güncel teknolojiye yatırım yaptığınıza değil, ne kadar teknik borç biriktirdiğinize bakıyor.

Ağınızda 2012 yılından kalma, parolası asla değişmemiş, Domain Admins grubuna eklenmiş bir servis hesabı varsa bu hesap, tüm güvenlik yatırımlarınızı bir anda anlamsız kılabilecek potansiyele sahip tek bir anahtar niteliğindedir.

Geleneksel "çevre güvenliği" anlayışı bu tür saldırılara karşı kör kalmaya devam edecek. Çünkü saldırgan zararlı bir yazılım çalıştırmıyor, imza tabanlı sistemlerin tanıyacağı bir payload kullanmıyor; ağınızın kendi protokollerini, kendi kullanıcı kimlik bilgilerini, kendi meşru araçlarını sizin aleyhinize çeviriyor.

Savunma paradigmasının da değişmesi şart: Kimliği doğrulanmış her eylem güvenlidir varsayımı çökmüştür. Artık ağ içindeki davranışları, Kerberos bilet taleplerini ve kullanıcı bazlı anormallikleri anlamak bir seçenek değil, zorunluluktur.