Active Directory Güvenlik Sıkılaştırması

Bir sızma testi ya da güvenlik değerlendirmesi yaptığımda, ilk baktığım yerlerden biri neredeyse hep aynı: Active Directory. Yıllardır bu işin içindeyim ve şunu rahatlıkla söyleyebilirim, bir kurumun güvenlik olgunluğunu anlamak istiyorsanız önce onun Active Directory'sine bakın; geri kalan her şey büyük ölçüde oradan şekilleniyor. Çünkü Active Directory, kimlik doğrulamadan yetkilendirmeye, hangi kullanıcının hangi sunucuya erişebileceğinden hangi bilgisayarın domaine dahil olduğuna kadar neredeyse her şeyin merkezinde duruyor. Bir saldırgan için de durum aynı: domain controller'ı ele geçirebilirseniz, artık şirketin anahtarları elinizde demektir.

Buna rağmen sahada gördüğüm tablo hâlâ can sıkıcı. Birçok kurum Active Directory'yi on, on beş yıl önce kurmuş, o günden beri üstüne katman katman grup, politika, hesap eklemiş ama temel güvenlik mimarisini bir kere bile gözden geçirmemiş. "Çalışıyor, dokunmayalım" mantığı burada tam bir kâbusa dönüşüyor, çünkü çalışıyor olması güvenli olduğu anlamına gelmiyor. Bu yazıda Active Directory'nin neden bu kadar çekici bir hedef olduğunu, saldırganların en sık kullandığı yöntemleri ve bir ortamı gerçek anlamda sıkılaştırmak için nereden başlamak gerektiğini anlatacağım.

Neden Active Directory Bu Kadar Hedefte?

Bunun basit bir nedeni var: Active Directory tek bir noktada muazzam bir yetki yoğunluğu barındırıyor. Bir saldırgan bir kullanıcı bilgisayarına sızdığında elde ettiği şey sınırlı; o makinedeki dosyalara, belki o kullanıcının yetkilerine erişir. Ama aynı saldırgan domain controller'ı ya da bir Domain Admin hesabını ele geçirdiğinde, artık şirketteki her sunucuya, her dosya paylaşımına, her kullanıcı hesabına dilediği gibi erişebilir. Fidye yazılımı grupları bu yüzden saldırı zincirlerinin neredeyse tamamında aynı hedefe kilitleniyor: önce bir uç nokta, sonra yatay hareket, en sonunda da Active Directory üzerinde tam kontrol. Bir domain controller'ı ele geçiren saldırgan için şifreleme ya da veri sızdırma artık bir formalite; asıl iş çoktan bitmiştir.

İkinci neden, Active Directory'nin varsayılan yapılandırmasının çoğu zaman güvenlikten çok uyumluluğu önceliklendirmesi. Yirmi yıl önce tasarlanan bazı protokoller ve mekanizmalar, bugünün saldırı araçlarıyla karşılaştığında son derece kırılgan kalıyor. Kerberos'un servis biletlerini offline çatlatmaya açık bırakan yapısı, NTLM'in hâlâ birçok ortamda etkin olması, eski Group Policy Preferences özelliğinin parolaları şifrelenmiş de olsa herkese açık bir şekilde saklaması, bunların hepsi yıllar içinde birikmiş, hâlâ pek çok kurumda kapatılmamış zayıflıklar. Bir de buna insan faktörünü ekleyin: yıllar içinde biriken, kimsenin hatırlamadığı hizmet hesapları, hiç değişmeyen parolalar, "geçici" diye açılıp kalıcı hale gelen yetkiler. Active Directory'nin saldırganlar için bu kadar verimli bir alan olmasının sırrı, çoğu zaman kötü niyetli bir kod parçası değil, yıllar içinde birikmiş bu türden küçük ihmaller.

Saldırganların En Çok Kullandığı Yollar

Active Directory'ye yönelik saldırıları anlatırken genelde karmaşık, sinematik bir hikâye bekleniyor ama gerçek çoğunlukla oldukça sıradan. Saldırganların büyük kısmı sıfırdan açık bulmuyor; ortamın kendi yapılandırmasını kendine karşı kullanıyor.

Kerberoasting bunun en tipik örneği. Active Directory'de bir hizmet hesabına Service Principal Name (SPN) tanımlandığında, herhangi bir yetkili kullanıcı bu hesap adına bir servis bileti talep edebiliyor. Bu bilet, hizmet hesabının parolasından türetilen bir anahtarla şifreleniyor. Saldırgan bu bileti aldıktan sonra domain controller'a hiç dokunmadan, kendi ortamında offline olarak parolayı kırmaya çalışabiliyor. Hizmet hesaplarının parolaları genelde yıllarca değişmediği, çoğu zaman da basit ya da tahmin edilebilir olduğu için bu saldırı can sıkıcı derecede etkili. Bir saldırganın tek bir düşük yetkili kullanıcı hesabıyla ağa girip birkaç saat içinde bir hizmet hesabının parolasını kırarak Domain Admin yetkisine ulaştığı senaryolara defalarca şahit oldum.

Golden Ticket ve Silver Ticket saldırıları bir adım daha ileri gidiyor. Saldırgan bir şekilde krbtgt hesabının parola özetini ele geçirdiğinde, artık domain içinde istediği herhangi bir kullanıcı adına, istediği yetkilerle, geçerli görünen bir Kerberos bileti üretebiliyor; buna Golden Ticket deniyor. Bu bilet o kadar meşru görünüyor ki, domain controller onu sorgulamadan kabul ediyor. Silver Ticket ise benzer bir mantıkla, tek bir servis hesabının ya da bilgisayar hesabının parola özetini kullanarak sadece o servise özel sahte biletler üretiyor. İkisinin de ortak noktası şu: saldırgan bir kere bu özetleri ele geçirdiğinde, günler hatta aylar sonra bile ortama geri dönüp kimse fark etmeden yeniden yetki kazanabiliyor.

DCSync saldırısı ise doğrudan domain controller'ların birbiriyle konuşma şeklini istismar ediyor. Normalde domain controller'lar birbirleriyle replikasyon yaparak parola özetlerini senkronize eder. Belirli replikasyon yetkilerine sahip bir hesap ele geçirildiğinde, saldırgan kendini sanki bir domain controllermış gibi tanıtıp gerçek bir domain controller'dan doğrudan parola özetlerini isteyebiliyor; buna da DCSync deniyor. İşin kötü tarafı, bu saldırı için saldırganın domain controller'a fiziksel ya da network düzeyinde erişmesine bile gerek yok; sadece doğru yetkilere sahip bir hesabın kimlik bilgilerini ele geçirmesi yetiyor.

Bunlara bir de kısıtlanmamış delegasyon (unconstrained delegation) ve aşırı geniş tanımlanmış yetkilendirme yapılarını ekleyebilirim. Bir sunucuya unconstrained delegation tanımlandığında, o sunucuya bağlanan herhangi bir kullanıcının kimlik bilgisi önbelleğe alınıyor ve sunucu bu kimlikle domain içinde başka yerlere erişebiliyor. Bir saldırgan böyle bir sunucuyu ele geçirdiğinde, o sunucuya bağlanan yüksek yetkili bir yöneticinin kimliğini de ele geçirmiş oluyor; genelde bunun farkına bile varmadan. Son olarak ntds.dit dosyasının doğrudan çalınması var; bu dosya domain controller üzerinde tüm kullanıcı hesaplarının parola özetlerini barındırıyor. Bir yedekleme sunucusuna ya da domain controller'ın disk imajına erişebilen bir saldırgan, tek bir dosyayı kopyalayarak aslında tüm şirketin kimlik bilgilerini cebine atmış oluyor.

Gerçek Hayattan Bir Senaryo

Bunun pratikte nasıl işlediğini göstermek için, sık karşılaşılan, kurgusal ama fazlasıyla tanıdık bir örnek anlatayım. Orta ölçekli bir üretim şirketinde IT ekibi, muhasebe yazılımının çalışması için yıllar önce bir hizmet hesabı oluşturmuş: "svc_muhasebe". Bu hesaba SPN tanımlanmış, parolası ilk kurulumdan bu yana bir kez bile değiştirilmemiş ve hesap, geçmişte bir migrasyon sırasında yanlışlıkla Domain Admins grubuna eklenip sonradan çıkarılmayı unutulmuş.

Bir saldırgan, kimlik avı e-postasıyla sıradan bir çalışanın bilgisayarına erişim sağlıyor. Bu çalışanın domain üzerinde neredeyse hiçbir özel yetkisi yok ama az yetkili bir hesap bile Kerberoasting yapmak için yeterli. Saldırgan birkaç dakika içinde tüm SPN'li hesapların servis biletlerini topluyor, "svc_muhasebe" hesabının biletini fark ediyor, kendi bilgisayarında offline olarak parolayı kırmaya başlıyor. Parola karmaşık görünse de yıllar önce belirlenmiş, sözlük tabanlı bir saldırıyla birkaç saat içinde çözülüyor.

Saldırgan artık "svc_muhasebe" hesabının kimlik bilgileriyle domaine giriş yapabiliyor ve bu hesabın hâlâ Domain Admins grubunda kalan gizli yetkisini keşfediyor. Buradan sonrası hızlı ilerliyor: domain controller'a erişim, krbtgt hesabının parola özetinin çalınması, bir Golden Ticket üretilmesi ve şirketin tüm dosya sunucularına, e-posta sistemine, yedekleme altyapısına sessizce yayılan bir fidye yazılımı. IT ekibi olayın farkına vardığında, saldırgan çoktan haftalardır ortamda geziniyor; çünkü hiçbir kural hizmet hesaplarının anormal bir şekilde giriş yapmasını ya da krbtgt hesabına yönelik replikasyon isteklerini izlemiyordu. Bu senaryoda hiçbir "sıfırıncı gün" açığı yok; sadece birikmiş, kimsenin fark etmediği yapılandırma hataları var. Ve bu, çoğu gerçek vakanın da özeti.

Active Directory Nasıl Sıkılaştırılır?

Active Directory'yi tek seferlik bir proje gibi "sıkılaştırıp bitirmek" mümkün değil; bu sürekli bakım isteyen, canlı bir disiplin. Ama yıllardır bu tür ortamlarla uğraşan biri olarak, en çok fark yaratan adımları aşağıdaki gibi sıralayabilirim.

İlk ve en temel adım, katmanlı yönetim modelini (tiered administration / Enterprise Access Model) hayata geçirmek. Buradaki fikir basit ama uygulaması disiplin istiyor: domain controller'lar ve sertifika otoriteleri gibi en kritik varlıkları Tier 0 olarak ayırıp, bu katmandaki hesapların kimlik bilgilerinin asla daha alt seviyedeki, daha az güvenli sistemlerde kullanılmamasını sağlamak gerekiyor. Bir Domain Admin hesabıyla günlük bir iş istasyonuna giriş yapmak, tam da bu modelin engellemeye çalıştığı şey; çünkü o iş istasyonu ele geçirildiği an, o hesabın kimlik bilgileri de saldırganın eline geçiyor. Bunu desteklemek için ayrıca yönetici hesaplarının sadece özel olarak sıkılaştırılmış, internete çıkışı kısıtlanmış Privileged Access Workstation (PAW) adı verilen cihazlardan kullanılmasını sağlamak gerekiyor.

İkinci adım, hizmet hesaplarını ve makine parolalarını modernize etmek. Mümkün olan her yerde klasik hizmet hesaplarını group Managed Service Account (gMSA) yapısına taşımak gerekiyor; bu yapı parolaları otomatik olarak, çok uzun ve karmaşık şekilde düzenli aralıklarla değiştiriyor ve bu parolaları hiçbir insanın bilmesine gerek kalmıyor. gMSA'ya taşınamayan eski hesaplar için de en az otuz karakterlik, rastgele üretilmiş parolalar kullanmak, bu hesapları düzenli olarak gözden geçirmek ve hiçbirinin gereksiz yere yüksek yetkili gruplarda kalmadığından emin olmak şart. Yukarıdaki senaryodaki "svc_muhasebe" hesabının hem parolası hem de grup üyeliği düzenli denetlenseydi, o saldırı zinciri muhtemelen ilk adımda kesilirdi.

Üçüncü adım, artık büyük ölçüde gereksiz kalmış eski protokolleri kapatmak. NTLM'i, özellikle NTLMv1'i, mümkün olduğunca devre dışı bırakmak; LDAP imzalamayı ve SMB imzalamayı zorunlu hale getirmek; domain controller'larda Print Spooler servisini kapatmak (bu servis, PrintNightmare gibi coercion saldırılarının klasik giriş noktalarından biri); ve SMBv1'i tamamen ortamdan kaldırmak gerekiyor. Bunların hiçbiri yeni ya da gizli bir tavsiye değil ama sahada hâlâ şaşırtıcı sayıda ortamda bu ayarların varsayılan, yani güvensiz haliyle durduğunu görüyorum.

Dördüncü adım, Kerberos'un can damarı olan krbtgt hesabını ve yüksek yetkili hesapları özel olarak korumak. krbtgt parolasının yılda en az bir kez, ideal olarak daha sık, art arda iki kez değiştirilmesi gerekiyor; çünkü bu hesabın özeti Golden Ticket saldırılarının temelini oluşturuyor. Yüksek yetkili kullanıcıları Protected Users güvenlik grubuna eklemek de bir diğer güçlü önlem; bu grup, hesapların NTLM ile kimlik doğrulamasını, önbelleğe alınmış kimlik bilgilerini ve delegasyona açık olmasını otomatik olarak engelliyor. Yerleşik Administrator hesabının günlük kullanımdan tamamen çıkarılıp sadece acil durum ("break-glass") senaryosu için saklanması da aynı mantığın bir parçası.

Beşinci adım, görünürlük ve izleme. Buraya kadar sayılan önlemlerin hepsi önemli ama hiçbiri, bir saldırının gerçekleştiğini anlayamıyorsanız yeterli değil. Kimlik doğrulama olaylarının (4768, 4769), hesap değişikliklerinin (4738, 5136), başarısız girişlerin (4625) ve PowerShell çalıştırmalarının (4103, 4104) merkezi olarak toplanması ve bir SIEM üzerinden korelasyona sokulması gerekiyor. Aynı kullanıcı için kısa sürede çok sayıda servis bileti talebi geldiğinde bu bir Kerberoasting girişimine işaret edebiliyor; bir 4769 olayının karşılığında beklenen bir 4768 olayı yoksa bu bir Golden Ticket kullanımının belirtisi olabiliyor. Ben ayrıca "canary" hesaplar oluşturulmasını da öneriyorum: hiçbir zaman gerçekten kullanılmayan ama SPN'i olan ya da eski Group Policy Preferences'ta parolası duran sahte hesaplar. Bu hesaplara herhangi bir erişim denemesi olduğunda, bu neredeyse kesin bir keşif ya da saldırı sinyali oluyor.

Son olarak, bu işi tek başına elle takip etmenin insan hatasına çok açık olduğunu vurgulamak isterim. BloodHound gibi araçlarla ortamdaki gizli yetki zincirlerini (kimin, hangi izinle, dolaylı olarak Domain Admin'e ulaşabildiğini) haritalamak; PingCastle ya da Purple Knight gibi ücretsiz değerlendirme araçlarıyla düzenli olarak ortamın olgunluk skorunu ölçmek, sıkılaştırma çalışmasını tek seferlik bir kontrol listesinden, sürekli iyileşen bir sürece dönüştürüyor. Bunlara ek olarak domain controller yedeklerinin şifrelenmiş, erişimi sadece yetkili yedekleme yöneticileriyle sınırlı tutulması ve yama yönetiminin domain controller'lar için asla ihmal edilmemesi gerekiyor; çünkü ntds.dit dosyasına giden en kısa yol, çoğu zaman gözden kaçmış bir yedekleme paylaşımından ya da güncellenmemiş bir sunucudan geçiyor.

Hibrit Ortamların Getirdiği Ek Risk

Bugün artık saf, bulutla hiç bağlantısı olmayan bir Active Directory ortamıyla karşılaşmak neredeyse istisna haline geldi. Çoğu kurum Entra Connect (eski adıyla Azure AD Connect) ya da benzer bir senkronizasyon aracıyla şirket içi Active Directory'yi buluta bağlamış durumda. Bu köprü kullanışlı ama aynı zamanda yeni bir saldırı yüzeyi de açıyor. Entra Connect sunucusu üzerinde çalışan senkronizasyon hesabı, genelde şirket içi domainde çok geniş yetkilere sahip; bu sunucuyu ele geçiren bir saldırgan, bulut tarafındaki kimlikleri de manipüle edebiliyor, hatta bazı senaryolarda bulut yönetici hesaplarını ele geçirip şirket içi ortama geri dönebiliyor. Bu yüzden Entra Connect sunucusunu da tıpkı bir domain controller gibi Tier 0 varlığı olarak ele almak, erişimini son derece kısıtlamak ve üzerinde başka hiçbir servisin çalışmamasını sağlamak gerekiyor.

Aynı hibrit yapı içinde parola spreyleme (password spraying) saldırıları da hâlâ şaşırtıcı derecede etkili. Saldırganlar tek bir kullanıcı hesabına art arda çok sayıda parola denemek yerine, tüm kullanıcı listesine karşı birkaç yaygın parolayı deniyor; bu yöntem hesap kilitleme eşiklerinin çoğu zaman altında kalıyor ve fark edilmeden geçebiliyor. Özellikle bulut tarafındaki kimlik doğrulama uç noktaları, şirket içi ağın izleme kapsamının dışında kaldığı için bu tür saldırılar için elverişli bir zemin oluşturuyor. Burada da çözüm karmaşık değil: akıllı kilitleme eşikleri, phishing'e dayanıklı çok faktörlü kimlik doğrulama ve bulut tarafındaki oturum açma günlüklerinin şirket içi SIEM ile aynı görünürlük altında toplanması yeterli oluyor.

Yönetişim ve Düzenli Denetimin Rolü

Teknik önlemler ne kadar sağlam olursa olsun, arkasında bir yönetişim disiplini yoksa zamanla eriyorlar. Bir yıl önce doğru şekilde yapılandırılmış bir grup üyeliği, bir proje bitip unutulduğunda kolayca gereksiz bir yetkiye dönüşebiliyor. Bu yüzden düzenli, takvime bağlanmış bir erişim gözden geçirme sürecinin olması gerekiyor; üç ayda bir yüksek yetkili grupların üyeliğini, hizmet hesaplarının hâlâ kullanımda olup olmadığını, kimin hangi delege yetkiye sahip olduğunu tekrar tekrar sormak gerekiyor. Bu tür bir gözden geçirmeyi bir kereliğine yapıp "artık temiz" demek büyük bir yanılgı; çünkü Active Directory canlı bir organizma gibi, her yeni proje, her yeni personel, her yeni entegrasyonla birlikte yeniden kirleniyor. En sağlıklı kurumlarda gördüğüm ortak nokta, bu gözden geçirmenin sadece BT'nin değil, ilgili iş birimi yöneticilerinin de imzasını gerektiren bir süreç haline getirilmiş olması; çünkü bir yetkinin gerçekten gerekli olup olmadığını çoğu zaman en iyi o yetkiyi talep eden departman biliyor.

Bu yazıyı hazırlarken bir kez daha fark ettiğim şey şu: Active Directory'yi güvenli hale getirmek büyük bütçeli bir dönüşüm projesi gerektirmiyor çoğu zaman. Yukarıda saydığım adımların büyük kısmı ek bir lisans ya da yatırım gerektirmeden, mevcut Windows Server özellikleriyle uygulanabilir; asıl gereken şey disiplin, düzenli denetim ve "bu hesap neden hâlâ bu yetkiye sahip?" sorusunu sormaktan vazgeçmemek. Sonuç olarak Active Directory sıkılaştırması, bir kerelik proje değil, sürekli bakım isteyen bir alışkanlık; ve bu alışkanlığı kazanan kurumlar, bir saldırganın ortamda haftalarca fark edilmeden dolaşmasını değil, ilk adımda yakalanmasını sağlıyor.