LSASS Sıkılaştırması ile Kimlik Bilgisi Hırsızlığını Engellemek

Active Directory ortamlarında saldırılar nadiren tek bir makineyle sınırlı kalır. Saldırgan genellikle zayıf bir noktadan içeri sızar o makinede yönetici hakkı elde eder ve oradan ağ içinde adım adım ilerler. Bu ilerlemeyi mümkün kılan şey neredeyse her zaman aynıdır bir sistemden çalınan kimlik bilgileriyle bir sonraki sisteme atlamak.

İşin ilginç tarafı bu zincirin en kritik halkasını kıran savunmanın yıllardır Windows’un içinde hazır beklemesi ama yöneticilerin büyük çoğunluğunun bunu hiç etkinleştirmemiş olmasıdır. Üstelik bu savunma için ek bir lisansa, üçüncü taraf bir ürüne ya da ayrı bir yazılıma da gerek yok doğru bir Grup İlkesi (GPO) yapılandırması yeterli.

Bu makalemde tam olarak bu boşluğu nasıl kapatacağımızı baştan sona ele alacağız.

Saldırının hedefindeki süreç: lsass.exe

Windows’ta oturum açan kullanıcıların kimlik bilgilerini bellekte tutan süreç lsass.exe‘dir. Parola özetleri ve Kerberos biletleri bu sürecin belleğinde durur.

Mimikatz, ProcDump gibi araçların yaptığı iş de tam olarak buraya tutunup o bellek içeriğini dışarı boşaltmaktır.

Gerçek bir ihlalin senaryosu çoğu zaman şöyle işler saldırgan bir makinede yönetici hakkı kazanır LSASS belleğini boşaltır ve oradan elde ettiği kimlik bilgileriyle ağdaki diğer sunuculara yönelir. Yani LSASS belleğine erişimi kapattığınızda, aslında yatay hareketin (lateral movement) başladığı noktayı ortadan kaldırmış olursunuz. Savunmayı buraya kurmak, saldırıyı en başından kesmek demektir.

Birinci katman: LSASS’ı korumalı süreç olarak çalıştırmak (PPL)

İlk ve en temel adım LSASS’ı korumalı bir süreç (Protected Process Light – PPL) olarak çalıştırmaktır. Bu özellik açıldığında işletim sistemi LSASS’ı ayrı ve korumalı bir alana taşır. Sonuç şu: yönetici hakkına sahip bir saldırgan bile artık standart yöntemlerle bu belleğe ulaşamaz.

Bunu GPO ile bir kayıt defteri tercihi olarak dağıtabilirsiniz. Computer Configuration → Preferences → Windows Settings → Registry yolunu izleyip HKLM\SYSTEM\CurrentControlSet\Control\Lsa anahtarının altına RunAsPPL adında bir DWORD değeri oluşturmanız ve değerini 1 yapmanız yeterli.

Burada akılda tutulması gereken tek kritik nokta var: PPL’in devreye girmesi için makinenin yeniden başlatılması şarttır. Yalnızca gpupdate çalıştırmak yetmez; ayar ancak yeniden başlatmanın ardından gerçekten aktif hale gelir.

İkinci katman: Defender’ın ASR kuralını devreye almak

İkinci katmanı Microsoft Defender’ın Saldırı Yüzeyi Azaltma (Attack Surface Reduction — ASR) kuralları oluşturur. Bu kümeden bizi ilgilendiren kural, doğrudan LSASS belleğinden kimlik bilgisi çalınmasını engellemeye yöneliktir ve 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b0 GUID’iyle tanımlanır.

Bu kuralı Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Microsoft Defender Exploit Guard → Attack Surface Reduction → Attack Surface Reduction Rules yolundan etkinleştirir, ilgili GUID’i ekleyip değerini 1 (Block) yaparsınız. Böylece Defender, LSASS sürecine yönelik bellek okuma girişimlerini engellemeye başlar.

PPL’den önemli bir farkı var: bu kural çalışabilmek için Defender’ın etkin olmasına bağlıdır. Ortamda Defender’ı pasif moda alan üçüncü taraf bir antivirüs varsa, bu kural devreye girmez.

Adım adım uygulama

İki katmanı da bir araya getiren süreç oldukça düz ilerler. Önce gpmc.msc konsolunu açıp hedef bilgisayarların bulunduğu OU üzerinde yeni bir GPO oluşturursunuz. Ardından sırasıyla PPL ayarını ve ASR kuralını bu GPO içinde yapılandırırsınız; ilki LSASS’ı korumalı sürece hazırlar, ikincisi Defender’ı bellek okumalarını engelleyecek şekilde ayarlar.

Yapılandırma bittikten sonra hedef makinelerde gpupdate /force komutunu çalıştırın ve makineleri yeniden başlatın — PPL’in etkinleşmesi için bu şart. Son olarak işin gerçekten çalışıp çalışmadığını test etmek için Mimikatz gibi bir araçla LSASS belleğine erişmeyi deneyebilirsiniz. Yapılandırma doğruysa karşınıza Access Denied çıkmalı.

PPL’in aktif olduğunu doğrulamak

Korumanın gerçekten devrede olduğunu PowerShell ile birkaç saniyede teyit edebilirsiniz:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name RunAsPPL

Komutun çıktısında RunAsPPL : 1 görüyorsanız, LSASS korumalı süreç olarak çalışıyor demektir. Bu satır, yapılandırmanın başarıyla oturduğunun en hızlı göstergesidir.

Sınav ipucu: tek bir katmana güvenmeyin

Burada önemli bir uyarı var. PPL tek başına kimlik bilgisi hırsızlığını tamamen önleyemez; yetenekli bir saldırgan belirli sürücü tabanlı tekniklerle bu korumayı aşmaya çalışabilir. Bu yüzden en sağlam yaklaşım her zaman katmanlı savunmadır.

En güçlü kombinasyon şu üç bileşenin bir aradadır: PPL, LSASS’ı korumalı süreç olarak çalıştırır; ASR kuralları, Defender üzerinden bellek okumalarını engeller; Credential Guard (VBS) ise sanallaştırma tabanlı güvenlikle kimlik bilgilerini donanım destekli, izole bir alanda saklar. Sınavlarda da en güçlü savunma olarak gösterilen seçenek neredeyse her zaman bu üçünün birlikte uygulandığı yapılandırmadır. Yani tek bir mekanizmayı işaretleyen şıkları değil “hepsini birden” diyen bütünleşik seçeneği aramak doğru olur.

Hangi sürümlerde çalışır?

PPL, sunucu tarafında Windows Server 2008 R2 ve sonrasında, istemci tarafında ise Windows 7 ve sonrasında desteklenir. ASR kuralı ise biraz daha yeni bir altyapı ister: Windows 10 sürüm 1709 ya da Server 2019 ve üzeri gerekir, ayrıca Microsoft Defender’ın etkin birincil antivirüs olması şarttır. Defender’ı pasif moda alan bir çözüm devredeyse kuralın beklendiği gibi çalışmayacağını unutmayın.