Active Directory Sızma Testi: AD CS (ESC1) ile Yetki Yükseltme, DCSync ile Kalıcılık ve Log Analizi

Active Directory Certificate Services (AD CS), kurumsal ağlarda kimlik doğrulama için kritik bir rol oynar. Yanlış yapılandırılmış sertifika şablonları, saldırganların yetki yükseltmesine ve tüm domaini ele geçirmesine olanak vermektedir.

Bu çalışmada, ESC1 (Misconfigured Certificate Template) zafiyetini sömürerek standart bir kullanıcıdan Domain Admin yetkisine nasıl yükseldiğimi ve ardından DCSync saldırısı ile kalıcılığı nasıl sağladığımı adım adım anlatacağım. Ayrıca saldırıyı yaptıktan sonra Sysmon ve Windows Event Log izlerini inceleyeceğiz.

Active Directory Certificate Services (AD CS) Kurulumu

Saldırı senaryosunu gerçekleştirmek için önce DC sunucumuza (DC01) Active Directory Certificate Services rolünü yapılandırmamız gerekiyor.

Peki neden AD CS?

AD CS, Windows ortamında şifreleme, kimlik doğrulama ve dijital imza işlemleri için kullanılan açık anahtar altyapısı sistemidir (PKI). Bizim uygulayacağımız ESC1 saldırısı, AD CS üzerindeki sertifika şablonlarının yanlış yapılandırılmasından kaynaklanır. Yani AD CS olmadan, bu zafiyeti simüle edemeyiz.

Server Manager kısmından AD CS rolünü seçip kurulum tipi için Enterprise CA seçeneğini işaretledim. Buradaki amaç, Enterprise CA’in Active Directory ile entegre çalışmasını sağlamaktır.

CA type kısmını Root CA olarak belirledim. Kriptografi ve isimlendirme kısmında SHA256 algoritmasını seçip CA ismini hilal-DC01-CA olarak yapılandırdım.

Zafiyetin Hazırlanması “VulnerableUser” Şablonu

AD CS rolünü kurduktan sonra,saldırı senaryomuzun temelini oluşturan ESC1 zafiyetini simüle etmek için sertifika şablonu oluşturmamız gerekiyor. User şablonunu kopyalayarak VulnerableUser isminde hatalı yapılandırılmış bir şablon oluşturdum.

Kullanıcı sertifika istediğinde, AD o sertifikanın kime ait olacağını kendi veritabanından otomatik çeker, şablon özelliklerinden Subject Name sekmesinde Supply in the request seçeneğini işaretliyoruz. Bu ayar sertifikayı talep eden kişiye kim olduğunu ve sertifikayı ona göre basacağını belirler. Saldırganın kendisini Administrator olarak tanıtabilmesini sağlayan yer burasıdır.

Şekil 1: ESC1 zafiyetine neden olan Supply in the request ayarının etkinleştirilmesi.

Bu zafiyetin sömürülebilmesi için, standart bir kullanıcının bu şablonu kullanabilmesi için Security sekmesinden Domain Users grubuna Enroll (sertifika alma) yetkisini verdim.

Şekil 2: Domain Users grubuna sertifika alma yetkisinin verilmesi

Bölüm 1: Sysmon Kurulumu

Saldırıya başlamadan önce, yapılan bütün eylemlerin arka planda nasıl izler bıraktığını kayıt altına alacak bir mekanizmaya ihtiyacımız var. Standart Windows Event Logları, Process Create gibi olaylarda komut satırı detaylarını varsayılan olarak göstermez. Bu körlüğü gidermek adına Sysinternals Sysmon aracını lab ortamındaki tüm makinelere kurdum. (CL01 ve DC01)

Sysmon’u varsayılan ayarlarda kurmak çok fazla log gelmesine sebebiyet vereceğinden dolayı Olaf Hartong’un sysmon-modular konfigürasyon dosyasını kullandım.

Sysinternal Suite içerisinden Sysmon.exe dosyasını indirdim. GitHub üzerinden sysmonconfig.xml dosyasını çekerek, Sysmon’un hangi olayları kaydedip hangilerini görmezden geleceğini belirleyen filtreleri sisteme dahil ettim.

CMD üzerinden konfigürasyon dosyasını göstererek kurulumu tamamladım.

Sysmon.exe -i sysmonconfig.xml

Mimikatz gibi araçların çalıştırdığı zararlı komutları Sysmon Event ID 1 altında yakalayabileceğiz.

Şekil 3: Sysmon konfigürasyon dosyası

Bölüm 2: Saldırı ve Yetki Yükseltme (Exploitation)

Saldırıya geçmeden önce, saldırgan makinesi (CL01) üzerindeki aktiviteleri kayıt altına almak kritikti. Bu sayede yapacağımız saldırının kendi makinemizde nasıl izler bıraktığını analiz edecektik. Bunun için CL01 makinesinde Yönetici haklarıyla komut satırına Sysmon kurulumunu aşağıdaki spesifik parametrelerle gerçekleştirdim.

sysmon64.exe -i sysmonconfig.xml -accepteula -h md5,sha256,imphash

-i sysmonconfig.xml = Olaf Hartong’un filtreleme kurallarını içeren konfigürasyon dosyasını yükler.

-accepteula = Lisans sözleşmesini otomatik kabul eder.

*h md5,sha256,imphash = Sysmon’un çalıştırılan her dosya için bu üç hash değerini hesaplamasını sağlar. Özellikle imphash*, zararlı yazılımların tespiti ve takibinde kullanılan çok değerli bir parmak izidir.

Şekil 4: Saldırgan makinesinde (CL01) Sysmon’un gelişmis hash algoritmalarıyla aktif edilmesi.

Sysmon da hazır olduğuna göre artık harekete geçebiliriz. Certify.exe ve Rubeus.exe dosyalarını GitHub (SharpCollection) üzerinden indirip C:\tools klasörüne taşıdım.

Buradaki amacımız; hatalı yapılandırılmış sertifika şablonunu tespit etmek, bu şablonu kullanarak Administrator adına sahte bir sertifika üretmek ve bu sertifikayı Kerberos biletine çevirerek Domain Admin olmaktır.

Adım 1: Reconnaissance

İlk olarak ortamdaki zafiyetli şablonları tespit etmek için Certify aracını kullandım.

Certify.exe find /vulnerable

Bu komutun çıktısında, VulnerableUser isimli şablonda msPKI-Certificate-Name-Flag: ENROLLEE_SUPPLIES_SUBJECT ayarı aktifti. Yani CA sunucusu, “Bana sertifikanın, kimin adına sertifika istersen onun adına sertifika veririm”, diyor.

Şekil 5: Certify aracı ile Enrollee Supplies Subject zafiyetinin tespit edilmesi.

Adım 2: Sahte Sertifika Üretimi (Weaponization)

Zafiyeti doğruladıktan sonra, kendimi Administrator olarak tanıtarak bir sertifika talebinde bulunuyorum.

Certify.exe request /ca:DC01.hilal.com\hilal-DC01-CA /template:VulnerableUser /altname:Administrator

İşlem başarılı oldu ve sertifika sisteme yüklendi. Lakin bir sonraki adımda (Rubeus) bu sertifikayı kullanabilmek için sertifikanın Thumbprint (SHA1 Hash) değerine ihtiyacım vardı ve Certify bunu o an ekrana yansıtmadı.

Bu sorunu aşmak için Windows’un yerleşik aracı olan Certutil ile kişisel depolamaya bakarak yeni üretilen sertifikanın hash değerini aldım:

certutil -user -store My

Çıktıda, Subject kısmının Administrator olduğunu ve saldırıda kullanacağım Hash değerini net bir şekilde görüntüledim.

Şekil 6: Administrator adına üretilen sertifikanın doğrulanması ve hash değerlerinin alınması.

Subject: CN=Administrator, CN=Users, DC=hilal, CD=com = Normalde hilal kullanıcısı ile oturum açtığım için CN=hilal yazması gerekiyordu ama ESC1 zafiyetini kullandığımız için sertifikayı talep ederken “Ben Administrator’ım” dedik. CA sunucusu bunu aldı ve sertifikanın üzerine “CN=Administrator” yazdı.

Template: VulnerableUser = VulnerableUser adında bir zafiyetli şablon oluşturmuştuk. Bu satır, saldırganın (CL01) standart bir şablonu değil, özellikle o zayıf şablonu kullanarak bu sahte kimliği ürettiğinin kanıtıdır.

Cert Hash(sha1): e25d12ebd50a80f4c40fbd97d02572550176985e = Sertifikanın benzersiz kimlik numarasıdır. Rubeus komutuna kopyalayıp kullanacağımız kod budur. Bu kodu kullanmazsak Rubeus hangi sertifikanın Admin sertifikası olduğunu bilemez. (TGT biletini almak için kopyalanmıştır.)

Adım 3: Yetki Yükseltme (Pass the Ticket)

Şuan elimde Administrator’a ait bir sertifika var, ancak AD ile konuşabilmek için bir Kerberos biletine (TGT) ihtiyacım var.

Rubeus aracını kullanarak, az önce aldığımız sertifika hash’i ile TGT talep ettim ve /ptt (Pass-the-Ticket) parametresi ile bu bileti mevcut oturuma enjekte ettim.

Rubeus.exe asktgt /user:Administrator /certificate:<e25d12ebd50a80f4c40fbd97d02572550176985e > /ptt

Şekil 7: Sertifikanın Kerberos biletine (TGT) dönüştürülmesi ile oturuma enjekte edilmesi.

[+] Ticket successfully imported! = Rubeus, DC’dan aldığı TGT biletini, o an kullandığım Windows oturumunun LSA’ya enjekte etti.

Username: Administrator (NT_PRINCIPAL)= Aldığımız biletin kime ait olduğunu ve yetki yükseltme işleminin başarılı olduğunu gösteriyor.

StartTime ve EndTime ise TGT biletinin 10 saat geçerli olduğunu gösteriyor. Çünkü Kerberos biletleri sonsuza kadar geçerli kalmıyor.

Bölüm 3: Log Analizi

Saldırıyı başarılı bir şekilde gerçekleştirdik. Analiz kapsamında, saldırının oluş sırasına göre logları inceleyeceğiz.

Event ID 4886

Saldırgan Certify.exe aracını çalıştırıp talep ettiği anda, DC01 üzerindeki güvenlik loglarına Event ID 4886 düşer.

Şekil 8: CA sunucusunun sertifika talebini aldığı an

Event ID 4887

ESC1 zafiyetinin ortaya çıktığı log budur. CA sunucusu isteği onaylayıp sertifikayı bastığında Event ID 4887 oluşur.

Şekil 9: Requester ve Subject uyuşmazlığını gösteren log

Requester: HİLAL\Administrator = saldırıyı yapan gerçek hesap.

Subject: CN= Administrator = sertifikanın içinde yazan sahte kimlik

Uç Nokta Tespiti — Sysmon Event ID 7

DC01 makinede log kayıtlarını gördük. Şimdi ise CL01 makinedeki saldırı esnasında yapılan işlemleri Sysmon’da inceleyeceğiz.

Saldırgan Certify.exe aracını çalıştırdığı zaman, Sysmon bu işlemin yüklediği kütüphaneleri (DLL) Event ID 7 olarak kaydeder.

Şekil 10: Saldırgan makinesinde Certify aracının çalıştığını gösteren Sysmon kaydı.

Log detaylarında Image: C:\tools\Certify.exe yolunu görüyoruz. Bu, saldırganın hangi klasörde hangi hack aracını kullandığını gösteriyor.

Bölüm 4: DCSync & Golden Ticket ile Kalıcılığı Sağlamak

Önceki adımlarda Domain Admin yetkisine ulaştık. Log kayıtlarını inceledik ama bir saldırgan için anlık yetki yeterli değildir. Asıl hedef sürekli erişimi sağlamaktır. Sistem yöneticisi yarın şifreleri değiştirse bile hala içeri girmek isteriz.

Bunun yolu ise Active Directory’de KRBTGT’yi ele geçirmekten geçer.

(Not: Mimikatz aracının kurulumunu, çalışma mantığı ve Splunk ile tespiti hakkında daha önce yazdığım detaylı yazımı buradan inceleyebilirsiniz, çünkü şimdi mimikatz aracını kullanacağız: Active Directory Saldırılarının Mimikatz & Splunk ile Tespiti)

Adım 1: Yetki Kontrolü

Saldırıya başlamadan önce, Rubeus ile elde ettiğimiz Domain Admin biletinin (TGT) oturumumuzda aktif olduğunu doğrulamamız gerekir. Eğer bilet hafızada yoksa, Mimikatz erişim engellendi hatası verir.

Bu komutu tekrardan çalıştırıyorum:

Rubeus.exe asktgt /user:Administrator /certificate:e25d12ebd50a80f4c40fbd97d02572550176985e /ptt

Şekil 11: Saldırı öncesi Domain Admin yetkisine sahip Kerberos biletinin doğrulanması

Çıktıda görüleceği üzere Ticket successfully imported! Mesajı ve Administrator kimliği, saldırı için hazır olduğunu gösteriyor.

Adım 2: DCSync Saldırısı ve KRBTGT

AD yapısında, DC veritabanlarını birbirleriyle senkronize ederler. DCSync saldırısı, Mimikatz aracını kullanarak DC’ye Domain Admin yetkisine sahip olduğumu belirtecek ve veritabanındaki kullanıcı bilgilerini talep edeceğim. Hedef KRBTGT hesabıdır.

Mimikatz klasörüne giderek mimikatz_trunk\x64 bu komutu çalıştırdım:

mimikatz.exe "lsadump::dcsync /domain:hilal.com /user:krbtgt" exit

Bu komut ile hilal.com domainindeki krbtgt kullanıcısının verilerini replikasyon yoluyla talep ettim.

Şekil 12: Mimikatz DCSync saldırısı ile KRBTGT hash’inin ele geçirilmesi

SAM Username: krbtgt = AD’deki tüm kerberos biletlerini imzalayan ve şifreleyen ana hesaptır. Kimin biletinin geçerli olup olmadığına karar verir.

Hash NTLM: b39ba894b869723c427177fa9b15d715 = Elde edilen Hash NTLM değeri, Active Directory’nin bilet dağıtım hesabı olan KRBTGT’nin parolasına aittir. Bu hash kullanılarak, Domain Controller ile hiç iletişim kurmadan, istenilen yetkide ve 10 yıl geçerlilik süresine sahip sahte Kerberos biletleri (Golden Ticket) üretilebilir.

aes256_hmac : NTLM’e göre daha güvenli olan AES şifreleme anahtarıdır. Modern sistemler NTLM yerine AES kullanmayı tercih etse de, saldırgan bu anahtarı da ele geçirdiği için güvenlik önlemini aşmış durumdadır.

Mimikatz çıktısının alt kısımlarında görülen Primary:Wdigest listesi, kullanıcının supplementalCredentials özniteliğini temsil eder. Bu alan, AD’nin geriye dönük uyumluluk için sakladığı farklı şifreleme türlerini ve parola bilgilerini içerir.

Şekil 13: KRBTGT Password History

KRBTGT hesabı için bu verilerin çalınması, saldırgan sadece mevcut şifreyle değil, sistemin hafızasındaki eski şifrelerle de bilet üretebileceği anlamına gelir. Bu yüzden bir KRBTGT saldırısı tespit edildiğinde, parolanın mutlaka iki kez üst üste değiştirilmesi önerilir.

DCSync Saldırısının tespiti

Sysmon Event ID 1

Şekil 14: Sysmon Event Id 1 ile Mimikatz komut satırı parametrelerinin yakalanması

Event ID 4662

Logda Properties kimlik numarası (GUID) kısmıdır.

{1131f6ad-9c07–11d1-f79f-00c04fc2dcd2} DS-Replication-Get-Changes-All = Veritabanındaki her şey, gizli olan parolalar

{19195a5b-6da0–11d0-afd3–00c04fd930c9} DS-Replication-Get-Changes = Veritabanındaki genel güncellemelerin bilgisini verir.

Şekil 15: Active Directory veritabanına yapılan replikasyon isteğinin tespiti

Bu çalışmada, Active Directory ortamında sıkça rastlanan ESC1 zafiyetini sömürerek standart bir kullanıcıdan nasıl Domain Admin yetkisine yükseldiğimizi uygulamalı olarak inceledik. Ayrıca saldırganın gerçekleştirdiği DCSync aktivitesinin Sysmon ve Event Logları üzerinde bıraktığı izleri analiz ettik.

Bu zafiyetin kapatılması, sertifika şablonlarının güvenli hale getirilmesi ve sistemlerin sıkılaştırılması adımlarını, serinin ikinci yazısında detaylıca ele alacağım.