Kalıcılık, erişimden farklı bir problemdir
Bu serinin ilk dört bölümü Domain Admin’e ulaşmakla ilgiliydi. Bu not ise Domain Controller üzerinde ayak bastıktan sonra ne yapacağınla ilgilidir — hedefin “domain’i ele geçir”ten “geri gelebilmeyi sürdür”e döndüğü aşama. İçeri girmek genellikle iz bırakır; içeride kalmak ise yeniden başlatmalardan, parola değişikliklerinden ve logları inceleyen bir savunmacıdan sağ çıkacak en küçük izi bırakmakla ilgilidir.
Bu aşamada üç numara öne çıkar ve hepsi aynı noktadan başlar: sevenkingdoms.local orman kökü DC’si KINGSLANDING (192.168.56.10) üzerinde zaten Administrator’ım. NT hash’i önceki DCSync’ten elimde ve bu hash SMB ile WinRM üzerinden çalışıyor. Yani artık kimlik doğrulama bir engel değil; asıl mesele, bu erişimi fark edilmeden ve mümkün olduğunca uzun süre koruyabilmek.
$ nxc winrm 192.168.56.10 -u Administrator -H c66d72021a2d4744409969a581a1705e
WINRM 192.168.56.10 5985 KINGSLANDING [+] sevenkingdoms.local\Administrator:... (Pwn3d!)DC’nin ilk karşı koyduğu şey kendi antivirüsüdür. Kutuya mimikatz taşımam gerekiyor ve Get-MpComputerStatus Defender’ın gerçek zamanlı korumasının açık olduğunu bildiriyor. Bu, kalıcılık aşamasının gerçek dünyadaki ilk dersidir: erişim ne kadar güçlü olursa olsun, savunma yazılımı aracın kutuya girmesini veya çalışmasını engelleyebilir.
$ nxc winrm 192.168.56.10 -u Administrator -H c66d72021a2d4744409969a581a1705e -x "powershell -c (Get-MpComputerStatus).RealTimeProtectionEnabled"
TrueTamper protection kapalı olduğu için, Domain Admin yetkimle tarama motorunu kapatıp aracı kutuya bırakabiliyorum. Bu adımı ayrıca yazmaya değer, çünkü tüm kalıcılık hikâyesindeki ilk gerçek engel budur: sıkılaştırılmış bir DC’de, bu üç numaranın hepsini yapan araç, çalıştığı anda silinecek kadar iyi imzalanmış durumdadır. Yani savunma tarafında doğru yapılandırılmış bir Defender, saldırganı daha ilk adımda yavaşlatır ve geride tespit edilebilir bir iz bırakmaya zorlar.
$ nxc winrm 192.168.56.10 -u Administrator -H ... -x "powershell -c Set-MpPreference -DisableRealtimeMonitoring 1"
$ nxc smb 192.168.56.10 -u Administrator -H ... --put-file /usr/share/windows-resources/mimikatz/x64/mimikatz.exe "\\Windows\\Temp\\mikatz.exe"
[+] Created file ... on \\C$\\Windows\Temp\mikatz.exeSkeleton Key: tek parola, her hesap
Skeleton Key kimlik bilgisi çalmaz ve bilet üretmez. Domain Controller’ın lsass.exe içindeki KDC’sini yamalar; böylece gerçek parolanın yanı sıra, birebir mimikatz parolası herhangi bir hesap için çalışır. Bu yaklaşımın zarafeti, mevcut hesaplara veya parolalara hiç dokunmamasıdır: gerçek kullanıcılar kendi parolalarıyla giriş yapmaya devam ederken saldırgan da her hesap için geçerli tek bir parola kazanır. Enjeksiyon, SYSTEM olarak çalıştırılan tek bir komuttur (psexec bana SYSTEM bağlamını verir):
$ impacket-psexec sevenkingdoms.local/[email protected] -hashes aad3b435b51404eeaad3b435b51404ee:c66d72021a2d4744409969a581a1705e \
"C:\Windows\Temp\mikatz.exe \"privilege::debug\" \"misc::skeleton\" exit"
mimikatz(commandline) # privilege::debug
Privilege '20' OK
mimikatz(commandline) # misc::skeleton
[KDC] data
[KDC] struct
[KDC] keys patch OK
[RC4] init patch OK
[RC4] decrypt patch OKÜç satır — [KDC] keys patch OK, [RC4] init patch OK, [RC4] decrypt patch OK — ve domain artık bir ana parolaya sahiptir. Bunu DC’nin kendisinin yapacağı şekilde doğruluyorum: sahte parolayla iki farklı hesap için Kerberos TGT’si istiyorum ve KDC ikisini de veriyor:
$ impacket-getTGT sevenkingdoms.local/Administrator:mimikatz -dc-ip 192.168.56.10
[*] Saving ticket in Administrator.ccache
$ impacket-getTGT sevenkingdoms.local/tywin.lannister:mimikatz -dc-ip 192.168.56.10
[*] Saving ticket in tywin.lannister.ccacheBirbirinden bağımsız iki hesap olan Administrator ve tywin.lannister, mimikatz ile açılıyor. Bütün mesele bu: KDC artık ana anahtarı gerçek anahtarın yanında kabul ediyor; bu yüzden kimsenin bir şey değiştirmesi gerekmiyor ve her kullanıcı normal şekilde giriş yapmaya devam ediyor. Yani savunmacı tarafında kullanıcıların davranışında görünür bir bozulma olmaz. Tehlikeli olan da tam olarak budur: saldırganın elinde artık her hesap için geçerli tek bir parola vardır, ama kullanıcı deneyimi ve parola politikaları hiç değişmemiş gibi görünür.
İşin ince kısmı, tekniğin yapmadığı şeydir. Aynı DC’ye NTLM girişleri hâlâ başarısız olur:
$ nxc smb 192.168.56.10 -u Administrator -p mimikatz
[-] sevenkingdoms.local\Administrator:mimikatz STATUS_LOGON_FAILURESkeleton Key yalnızca KDC’deki Kerberos kod yolunu yamalar (SamIRetrieveMultiplePrimaryCredentials ve RC4 çözme rutini). NTLM kimlik doğrulaması farklı bir yol olan Msv1_0.dll üzerinden gider, bu yüzden o yol hiç etkilenmez. Pratik sonuç şudur: anahtarı enjekte ettikten sonra Kerberos ile ilerle (getTGT, -k), NTLM ile değil. Bu ayrım, “teknik çalıştı” ile “SMB girişim neden reddediliyor diye bir saat harcadım” arasındaki farktır.
Ayrıca teknik yalnızca bellek içidir. Diske hiçbir şey yazılmaz ve yama, lsass.exe yeniden başladığında ya da DC yeniden başlatıldığında buharlaşır. Bu hem gücüdür (diskte iz kalmaz, dolayısıyla dosya tabanlı tespitten kaçınır) hem de zayıflığıdır (tek başına yeniden başlatma sonrası kalıcılık sağlamaz). Uzun vadeli bir dayanak noktası arıyorsan, bu tekniği tek başına değil, yeniden uygulanabilecek bir erişimle birlikte düşünmen gerekir.
Custom SSP: sıradaki düz metin parolayı loglamak
Skeleton Key senin için kapıyı açarken, custom bir Security Support Provider başkalarının kullandığı anahtarları yakalar. misc::memssp, düz metin kimlik bilgilerini C:\Windows\System32\mimilsa.log dosyasına kaydeden bellek içi bir SSP yükler:
mimikatz(commandline) # misc::memssp
Injected =)Buradaki bellek vurgusu önemlidir: SSP lsass.exe içine kaydedilir ve asla DLL olarak diske yazılmaz, bu yüzden geride dosya bırakmaz. Yalnızca sonraki parola tabanlı girişleri loglar — uzaktan gelen bir NTLM ya da Kerberos girişi düz metin değil hash taşır, bu yüzden biri etkileşimli bir oturumda parola yazana kadar (RDP, runas, saklanan kimlik bilgisiyle çalışan zamanlanmış görev) log boş kalır. Bu, tekniğin sabır gerektirdiği anlamına gelir: SSP hemen sonuç vermez, yalnızca kullanıcıların parolalarını elle girdiği anları bekler. Tespit hikâyesi de buna bağlı olarak dardır: yeni bir mimilsa.log dosyasını, arkasında diskte DLL olmadan kayıtlı bir SSP’yi veya lsass sürecine enjeksiyon yapan herhangi bir süreci izle.
DSRM: burada geçerli olmayan yol
Üçüncü klasik yöntem DSRM istismarıdır: Domain Controller’ın yerel Administrator hash’ini (Directory Services Restore Mode hesabı) dök ve DsrmAdminLogonBehavior değeri 2 olarak ayarlıysa hash ile DC’ye yerel olarak pass-the-hash yap. Bu laboratuvarda tüm yol kapalı:
$ reg query HKLM\System\CurrentControlSet\Control\Lsa /v DsrmAdminLogonBehavior
ERROR: The system was unable to find the specified registry key or value.Değer hiç ayarlanmamış — ki bu varsayılandır: DSRM hesabı yalnızca DC restore moduna önyüklendiğinde kullanılabilir, normal çalışma sırasında değil. Bir başka deyişle, hash’i döksen bile varsayılan yapılandırmada onu normal çalışan bir DC’ye karşı kullanamazsın; teknik ancak yönetici bu davranışı bilinçli olarak değiştirdiyse anlam kazanır. Bu dürüst sonuçtur ve bir not defterinde tutulması gereken doğru türden bir sonuçtur: bir tekniğin ne zaman geçerli olmadığını bilmek, onu zorlamaya çalışmaktan daha hızlıdır. Bu yolu kapatan kontrol de basittir: DsrmAdminLogonBehavior değerini 0’da bırak ve DSRM parolasını düzenli olarak döndür.
Tespit ve düzeltme
| Teknik | Dokunduğu yer | Tespit | Kontrol |
|---|---|---|---|
| Skeleton Key | lsass.exe KDC/RC4 yaması (bellek içi) | Birçok hesapta aynı anda mimikatz girişinin başarılı olması; anormal auth ile Event ID 4624 | LSA Protection; lsass yazmalarında EDR; reboot temizler |
Custom SSP (memssp) | lsass.exe SSP kaydı | yeni mimilsa.log; diskte DLL olmadan SSP | LSA Protection; imzasız SSP’leri engelle; lsass enjeksiyonuna alarm |
| DSRM | yerel Administrator hash | DsrmAdminLogonBehavior = 2 (registry) | değeri 0’da tut; DSRM parolasını döndür |
Üçünü de körelten tek kontrol, Domain Controller’larda LSA Protection kullanmaktır: bu, tam da söz konusu tekniklerin yamalamak ya da enjekte etmek zorunda olduğu lsass sürecini izole eder. İkinci kontrol ise daha sıkıcı olanıdır — Defender’ı ve tamper korumasını açık tutmak; bu walkthrough’un daha ilk adımını açıkça loglanan bir eylem haline getiren de buydu. Üçüncü ve en az teknik olan kontrol, lsass sürecine yapılan olağandışı erişimleri ve beklenmedik SSP kayıtlarını sürekli izlemektir; çünkü bu ailedeki tekniklerin çoğu, çalışabilmek için aynı sürece dokunmak zorundadır.
Özet
Skeleton Key üçünün en temizidir: tek bir bellek içi yama, KDC’yi mimikatz ana parolasıyla bir arka kapıya çevirir, Kerberos için çalışır (NTLM için değil) ve diskte dosya bırakmaz. Custom SSP bu kapı açma yeteneğini kimlik bilgisi yakalamayla takas eder; DSRM ise — herkesin sıradaki diye listelediği yöntem — DsrmAdminLogonBehavior değerini hiç açmamış bir laboratuvarda geçerli değildir. Bu üçünün karşılaştırılması, kalıcılık tekniklerini değerlendirirken kullanışlı bir ölçüt verir: hangi izi bıraktıkları, ne kadar sürdükleri ve hangi tek savunma kontrolüyle durduruldukları. Buradaki birleştirici ders şudur: bu tekniklerin hepsi lsass tabanlıdır, dolayısıyla tüm aile aynı kontrolde etkisiz hale gelir.
lsass.exe içinde bellek içi kalıcılık: yamalanan KDC, bir sonraki yeniden başlatmaya kadar Kerberos üzerinden her kullanıcının gerçek anahtarının yanında ana parolayı da kabul eder.Kanıt ve sınırlar
Tüm komutlar, izole host-only GOAD laboratuvarındaki KINGSLANDING (192.168.56.10) üzerinde çalıştırılmıştır. lsass.exe enjeksiyon aşamasına geçebilmek için Domain Admin yetkisiyle Windows Defender gerçek zamanlı izlemesinin açıkça kapatılması (Set-MpPreference -DisableRealtimeMonitoring 1) gerekmiştir; Tamper Protection ve LSA Protection’ın (RunAsPPL) açık olduğu sıkılaştırılmış bir üretim Domain Controller’ında hem misc::skeleton hem de misc::memssp lsass sürecine ulaşmadan engellenir. Testlerin ardından laboratuvar, temiz snapshot durumuna döndürülmüştür.
Referanslar
- Sean Metcalf, ADSecurity — Skeleton Key Malware: adsecurity.org/?p=1255
- Sean Metcalf, ADSecurity — Sneaky Active Directory Persistence #12: Malicious Security Support Provider (SSP): adsecurity.org/?p=1760
- gentilkiwi, Mimikatz: github.com/gentilkiwi/mimikatz
- MITRE ATT&CK, Account Manipulation (T1098): attack.mitre.org/techniques/T1098
- MITRE ATT&CK, OS Credential Dumping (T1003): attack.mitre.org/techniques/T1003
- Microsoft, Configure added LSA protection: learn.microsoft.com
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.