AD CS Domain Escalation
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Bu, gönderilerin yükseltme teknikleri bölümlerinin bir özetidir:
Kayıt hakları, Kurumsal CA tarafından düşük ayrıcalıklı kullanıcılara verilmektedir.
Yönetici onayı gerekmemektedir.
Yetkili personelden imza gerekmemektedir.
Sertifika şablonlarındaki güvenlik tanımlayıcıları aşırı izinlidir, bu da düşük ayrıcalıklı kullanıcıların kayıt hakları elde etmesine olanak tanır.
Sertifika şablonları, kimlik doğrulamayı kolaylaştıran EKU'ları tanımlamak için yapılandırılmıştır:
Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0) veya EKU yok (SubCA) gibi Genişletilmiş Anahtar Kullanımı (EKU) tanımlayıcıları dahildir.
Sertifika İmzalama Talebi (CSR) içinde subjectAltName ekleme yeteneği şablon tarafından izin verilmektedir:
Active Directory (AD), bir sertifikada kimlik doğrulama için subjectAltName (SAN) varsa öncelik verir. Bu, CSR'de SAN belirterek, herhangi bir kullanıcıyı (örneğin, bir alan yöneticisi) taklit etmek için bir sertifika talep edilebileceği anlamına gelir. Talep edenin bir SAN belirleyip belirleyemeyeceği, sertifika şablonunun AD nesnesinde mspki-certificate-name-flag özelliği aracılığıyla gösterilmektedir. Bu özellik bir bitmask'tır ve CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bayrağının varlığı, talep edenin SAN'ı belirtmesine izin verir.
Açıklanan yapılandırma, düşük ayrıcalıklı kullanıcıların istedikleri herhangi bir SAN ile sertifika talep etmelerine izin vererek, Kerberos veya SChannel aracılığıyla herhangi bir alan ilkesinin kimliğini doğrulamalarını sağlar.
Bu özellik, bazen ürünler veya dağıtım hizmetleri tarafından HTTPS veya ana bilgisayar sertifikalarının anında oluşturulmasını desteklemek için veya anlayış eksikliği nedeniyle etkinleştirilir.
Bu seçeneği kullanarak bir sertifika oluşturmanın bir uyarı tetiklediği, ancak mevcut bir sertifika şablonunun (örneğin, WebServer şablonu, CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT etkin) kopyalanıp ardından bir kimlik doğrulama OID'si eklemek için değiştirilmesi durumunda böyle bir durumun söz konusu olmadığı belirtilmiştir.
Zayıf sertifika şablonlarını bulmak için şunu çalıştırabilirsiniz:
Bu açığı kötüye kullanarak bir yöneticiyi taklit etmek için şunu çalıştırabilirsiniz:
Sonra oluşturulan sertifikayı .pfx formatına dönüştürebilir ve bunu Rubeus veya certipy kullanarak tekrar kimlik doğrulamak için kullanabilirsiniz:
Windows ikili dosyaları "Certreq.exe" ve "Certutil.exe", PFX oluşturmak için kullanılabilir: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
AD Ormanı'nın yapılandırma şemasındaki sertifika şablonlarının, özellikle onay veya imza gerektirmeyen, Client Authentication veya Smart Card Logon EKU'suna sahip olan ve CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT bayrağı etkin olanların sayımı, aşağıdaki LDAP sorgusunu çalıştırarak gerçekleştirilebilir:
İkinci kötüye kullanım senaryosu, birincisinin bir varyasyonudur:
Kayıt hakları, Kurumsal CA tarafından düşük ayrıcalıklı kullanıcılara verilir.
Yönetici onayı gerekliliği devre dışı bırakılmıştır.
Yetkili imzaların gerekliliği atlanmıştır.
Sertifika şablonundaki aşırı izinli bir güvenlik tanımlayıcısı, düşük ayrıcalıklı kullanıcılara sertifika kayıt hakları verir.
Sertifika şablonu, Any Purpose EKU'yu veya hiç EKU'yu içerecek şekilde tanımlanmıştır.
Any Purpose EKU, bir saldırganın herhangi bir amaçla, istemci kimlik doğrulaması, sunucu kimlik doğrulaması, kod imzalama vb. dahil olmak üzere bir sertifika almasına izin verir. Bu senaryoyu istismar etmek için ESC3 için kullanılan aynı teknik uygulanabilir.
Hiç EKU'su olmayan sertifikalar, alt CA sertifikaları olarak hareket eder ve herhangi bir amaçla istismar edilebilir ve yeni sertifikaları imzalamak için de kullanılabilir. Bu nedenle, bir saldırgan, bir alt CA sertifikası kullanarak yeni sertifikalarda keyfi EKU'lar veya alanlar belirleyebilir.
Ancak, alan kimlik doğrulaması için oluşturulan yeni sertifikalar, alt CA NTAuthCertificates nesnesi tarafından güvenilir değilse çalışmayacaktır; bu varsayılan ayardır. Yine de, bir saldırgan herhangi bir EKU ve keyfi sertifika değerleri ile yeni sertifikalar oluşturabilir. Bunlar, potansiyel olarak geniş bir yelpazede amaçlar için kötüye kullanılabilir (örneğin, kod imzalama, sunucu kimlik doğrulaması vb.) ve SAML, AD FS veya IPSec gibi ağdaki diğer uygulamalar için önemli sonuçlar doğurabilir.
AD Ormanı'nın yapılandırma şemasında bu senaryoya uyan şablonları listelemek için aşağıdaki LDAP sorgusu çalıştırılabilir:
Bu senaryo, birinci ve ikinci senaryoya benzer ancak farklı bir EKU (Sertifika Talep Ajanı) ve 2 farklı şablon istismar etmektedir (bu nedenle 2 set gereksinimi vardır).
Sertifika Talep Ajanı EKU (OID 1.3.6.1.4.1.311.20.2.1), Microsoft belgelerinde Kayıt Ajanı olarak bilinir, bir kullanıcının başka bir kullanıcı adına sertifika için kayıt olmasına izin verir.
“kayıt ajanı”, böyle bir şablona kayıt olur ve elde edilen sertifikayı diğer kullanıcı adına bir CSR'yi eş imzalamak için kullanır. Daha sonra eş imzalı CSR'yi CA'ya gönderir, “adına kayıt olma” izni veren bir şablona kayıt olur ve CA, “diğer” kullanıcıya ait bir sertifika ile yanıt verir.
Gereksinimler 1:
Kayıt hakları, Enterprise CA tarafından düşük ayrıcalıklı kullanıcılara verilir.
Yönetici onayı gereksinimi atlanmıştır.
Yetkili imzalar için bir gereksinim yoktur.
Sertifika şablonunun güvenlik tanımlayıcısı aşırı derecede izin vericidir, düşük ayrıcalıklı kullanıcılara kayıt hakları verir.
Sertifika şablonu, diğer ilkeler adına diğer sertifika şablonlarının talep edilmesini sağlayan Sertifika Talep Ajanı EKU'sunu içerir.
Gereksinimler 2:
Enterprise CA, düşük ayrıcalıklı kullanıcılara kayıt hakları verir.
Yönetici onayı atlanmıştır.
Şablonun şema versiyonu ya 1'dir ya da 2'yi aşar ve Sertifika Talep Ajanı EKU'sunu gerektiren bir Uygulama Politikası Yayınlama Gereksinimi belirtir.
Sertifika şablonunda tanımlanan bir EKU, alan kimlik doğrulamasına izin verir.
Kayıt ajanları için kısıtlamalar CA üzerinde uygulanmamaktadır.
Bu senaryoyu istismar etmek için Certify veya Certipy kullanabilirsiniz:
The kullanıcılar who are allowed to almak an kayıt ajanı sertifikası, the templates in which enrollment ajanları are permitted to enroll, and the hesaplar on behalf of which the enrollment agent may act can be constrained by enterprise CAs. This is achieved by opening the certsrc.msc snap-in, sağa tıklayarak CA'ya, Özellikler'e tıklayarak, and then navigating to the “Enrollment Agents” tab.
However, it is noted that the varsayılan setting for CAs is to “Kayıt ajanlarını kısıtlamayın.” When the restriction on enrollment agents is enabled by administrators, setting it to “Kayıt ajanlarını kısıtla,” the default configuration remains extremely permissive. It allows Herkes access to enroll in all templates as anyone.
The güvenlik tanımlayıcısı on sertifika şablonları defines the izinler specific AD ilkeleri possess concerning the template.
Should an saldırgan possess the requisite izinler to değiştirmek a şablon and kurmak any istismar edilebilir yanlış yapılandırmalar outlined in önceki bölümler, privilege escalation could be facilitated.
Notable permissions applicable to certificate templates include:
Sahip: Grants implicit control over the object, allowing for the modification of any attributes.
TamKontrol: Enables complete authority over the object, including the capability to alter any attributes.
YazmaSahibi: Permits the alteration of the object's owner to a principal under the attacker's control.
YazmaDacl: Allows for the adjustment of access controls, potentially granting an attacker FullControl.
YazmaÖzellik: Authorizes the editing of any object properties.
An example of a privesc like the previous one:
ESC4 is when a user has write privileges over a certificate template. This can for instance be abused to overwrite the configuration of the certificate template to make the template vulnerable to ESC1.
As we can see in the path above, only JOHNPC has these privileges, but our user JOHN has the new AddKeyCredentialLink edge to JOHNPC. Since this technique is related to certificates, I have implemented this attack as well, which is known as Shadow Credentials. Here’s a little sneak peak of Certipy’s shadow auto command to retrieve the NT hash of the victim.
Certipy, bir sertifika şablonunun yapılandırmasını tek bir komutla geçersiz kılabilir. Varsayılan olarak, Certipy yapılandırmayı ESC1'e karşı savunmasız hale getirmek için geçersiz kılar. Ayrıca, saldırımızdan sonra yapılandırmayı geri yüklemek için eski yapılandırmayı kaydetmek üzere -save-old parametresini de belirtebiliriz.
Sertifika şablonları ve sertifika otoritesinin ötesinde birkaç nesneyi içeren, ACL tabanlı ilişkilerin geniş ağı, tüm AD CS sisteminin güvenliğini etkileyebilir. Güvenliği önemli ölçüde etkileyebilecek bu nesneler şunlardır:
CA sunucusunun AD bilgisayar nesnesi, S4U2Self veya S4U2Proxy gibi mekanizmalar aracılığıyla tehlikeye girebilir.
CA sunucusunun RPC/DCOM sunucusu.
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM> belirli konteyner yolundaki herhangi bir alt AD nesnesi veya konteyner. Bu yol, Sertifika Şablonları konteyneri, Sertifikasyon Otoriteleri konteyneri, NTAuthCertificates nesnesi ve Kayıt Hizmetleri Konteyneri gibi konteynerler ve nesnelerle sınırlı olmamakla birlikte, bunları içerir.
PKI sisteminin güvenliği, düşük ayrıcalıklı bir saldırgan bu kritik bileşenlerden herhangi birine kontrol sağlamayı başarırsa tehlikeye girebilir.
CQure Academy gönderisinde tartışılan konu, Microsoft tarafından belirtilen EDITF_ATTRIBUTESUBJECTALTNAME2 bayrağının etkilerini de ele almaktadır. Bu yapılandırma, bir Sertifikasyon Otoritesi (CA) üzerinde etkinleştirildiğinde, herhangi bir istek için konu alternatif adı içinde kullanıcı tanımlı değerlerin dahil edilmesine izin verir; bu, Active Directory®'den oluşturulanları da içerir. Sonuç olarak, bu düzenleme, bir saldırganın alan kimlik doğrulaması için ayarlanmış herhangi bir şablon aracılığıyla kaydolmasına olanak tanır—özellikle, standart Kullanıcı şablonu gibi ayrıca ayrıcalıksız kullanıcı kaydına açık olanlar. Sonuç olarak, bir sertifika güvence altına alınabilir ve saldırganın alan yöneticisi veya alan içindeki herhangi bir başka aktif varlık olarak kimlik doğrulaması yapmasına olanak tanır.
Not: Sertifika İmzalama Talebi (CSR) içine alternatif adların eklenmesi için certreq.exe içindeki -attrib "SAN:" argümanı aracılığıyla kullanılan yaklaşım, ESC1'deki SAN'ların istismar stratejisinden bir fark sunar. Burada, fark, hesap bilgilerinin nasıl kapsüllendiği ile ilgilidir—bir sertifika niteliği içinde, bir uzantı yerine.
Ayarın etkin olup olmadığını doğrulamak için, kuruluşlar certutil.exe ile aşağıdaki komutu kullanabilir:
Bu işlem esasen uzaktan kayıt defteri erişimi kullanır, bu nedenle alternatif bir yaklaşım şu olabilir:
Certify ve Certipy gibi araçlar, bu yanlış yapılandırmayı tespit etme ve bunu istismar etme yeteneğine sahiptir:
Bu ayarları değiştirmek için, domain yönetici haklarına veya eşdeğerine sahip olunduğu varsayılarak, aşağıdaki komut herhangi bir iş istasyonundan çalıştırılabilir:
Bu yapılandırmayı ortamınızda devre dışı bırakmak için, bayrak şu komutla kaldırılabilir:
Mayıs 2022 güvenlik güncellemelerinden sonra, yeni verilen sertifikalar, istek sahibinin objectSid özelliğini içeren bir güvenlik uzantısı içerecektir. ESC1 için, bu SID belirtilen SAN'dan türetilir. Ancak, ESC6 için, SID istek sahibinin objectSid'sini yansıtır, SAN'ı değil.
ESC6'ı istismar etmek için, sistemin ESC10'a (Zayıf Sertifika Eşleştirmeleri) karşı hassas olması gerekmektedir; bu, yeni güvenlik uzantısından ziyade SAN'ı önceliklendirir.
Bir sertifika otoritesinin erişim kontrolü, CA eylemlerini yöneten bir dizi izin aracılığıyla sürdürülmektedir. Bu izinler, certsrv.msc'ye erişerek, bir CA'ya sağ tıklayarak, özellikleri seçerek ve ardından Güvenlik sekmesine giderek görüntülenebilir. Ayrıca, izinler PSPKI modülü kullanılarak şu komutlarla sıralanabilir:
Bu, "CA yöneticisi" ve "Sertifika Yöneticisi" rollerine karşılık gelen ManageCA ve ManageCertificates gibi temel haklar hakkında bilgiler sunar.
Bir sertifika otoritesinde ManageCA haklarına sahip olmak, yetkilinin PSPKI kullanarak ayarları uzaktan manipüle etmesine olanak tanır. Bu, herhangi bir şablonda SAN belirtimine izin vermek için EDITF_ATTRIBUTESUBJECTALTNAME2 bayrağını değiştirmeyi içerir; bu, alan yükseltmesinin kritik bir yönüdür.
Bu sürecin basitleştirilmesi, doğrudan GUI etkileşimi olmadan değişikliklere izin veren PSPKI’nin Enable-PolicyModuleFlag cmdlet'inin kullanımıyla mümkündür.
ManageCertificates haklarına sahip olmak, bekleyen taleplerin onaylanmasını kolaylaştırır ve "CA sertifika yöneticisi onayı" korumasını etkili bir şekilde aşar.
Bir Certify ve PSPKI modüllerinin kombinasyonu, bir sertifika talep etmek, onaylamak ve indirmek için kullanılabilir:
Önceki saldırıda Manage CA izinleri ESC6 saldırısını gerçekleştirmek için EDITF_ATTRIBUTESUBJECTALTNAME2 bayrağını etkinleştirmek için kullanıldı, ancak bu, CA hizmeti (CertSvc) yeniden başlatılmadıkça herhangi bir etki yaratmayacaktır. Bir kullanıcının Manage CA erişim hakkı olduğunda, kullanıcı aynı zamanda hizmeti yeniden başlatma iznine de sahiptir. Ancak, bu kullanıcının hizmeti uzaktan yeniden başlatabileceği anlamına gelmez. Ayrıca, ESC6 çoğu yamanmış ortamda kutudan çıktığı gibi çalışmayabilir çünkü Mayıs 2022 güvenlik güncellemeleri nedeniyle.
Bu nedenle, burada başka bir saldırı sunulmaktadır.
Gereksinimler:
Sadece ManageCA izni
Manage Certificates izni (bu ManageCA üzerinden verilebilir)
Sertifika şablonu SubCA etkinleştirilmiş olmalıdır (bu ManageCA üzerinden etkinleştirilebilir)
Teknik, Manage CA ve Manage Certificates erişim hakkına sahip kullanıcıların başarısız sertifika talepleri verebileceği gerçeğine dayanır. SubCA sertifika şablonu ESC1'e karşı savunmasızdır, ancak yalnızca yöneticiler şablona kaydolabilir. Böylece, bir kullanıcı SubCA'ya kaydolmak için talep edebilir - bu reddedilecektir - ancak sonrasında yönetici tarafından verilecektir.
Kendinize Manage Certificates erişim hakkını, kullanıcıyı yeni bir yetkili olarak ekleyerek verebilirsiniz.
SubCA şablonu, -enable-template parametresi ile CA üzerinde etkinleştirilebilir. Varsayılan olarak, SubCA şablonu etkindir.
Eğer bu saldırı için ön koşulları yerine getirmişsek, SubCA şablonuna dayalı bir sertifika talep etmeye başlayabiliriz.
Bu talep reddedilecektir, ancak özel anahtarı kaydedeceğiz ve talep kimliğini not alacağız.
CA Yönet ve Sertifikaları Yönet ile, ca komutunu ve -issue-request <request ID> parametresini kullanarak başarısız sertifika talebini verebiliriz.
Ve sonunda, req komutunu ve -retrieve <request ID> parametresini kullanarak verilen sertifikayı alabiliriz.
AD CS yüklü olan ortamlarda, eğer kötü niyetli bir web kayıt noktası varsa ve en az bir sertifika şablonu yayımlanmışsa ve bu şablon alan bilgisayarı kaydı ve istemci kimlik doğrulamasına izin veriyorsa (varsayılan Machine şablonu gibi), spooler servisi aktif olan herhangi bir bilgisayarın bir saldırgan tarafından tehlikeye atılması mümkün hale gelir!
AD CS, yöneticilerin yükleyebileceği ek sunucu rolleri aracılığıyla sunulan birkaç HTTP tabanlı kayıt yöntemi desteklemektedir. HTTP tabanlı sertifika kaydı için bu arayüzler NTLM relay saldırılarına karşı hassastır. Bir saldırgan, tehlikeye atılmış bir makineden, gelen NTLM aracılığıyla kimlik doğrulayan herhangi bir AD hesabını taklit edebilir. Mağdur hesabını taklit ederken, bu web arayüzleri bir saldırgan tarafından User veya Machine sertifika şablonlarını kullanarak bir istemci kimlik doğrulama sertifikası talep etmek için erişilebilir.
Web kayıt arayüzü (http:///certsrv/ adresinde bulunan eski bir ASP uygulaması), varsayılan olarak yalnızca HTTP'yi destekler ve bu da NTLM relay saldırılarına karşı koruma sağlamaz. Ayrıca, yalnızca NTLM kimlik doğrulamasına izin vererek, Kerberos gibi daha güvenli kimlik doğrulama yöntemlerinin uygulanamaz hale gelmesine neden olur.
Sertifika Kayıt Servisi (CES), Sertifika Kayıt Politikası (CEP) Web Servisi ve Ağ Cihazı Kayıt Servisi (NDES) varsayılan olarak, yetkilendirme HTTP başlıkları aracılığıyla müzakere kimlik doğrulamasını destekler. Müzakere kimlik doğrulaması hem Kerberos'u hem de NTLM'yi destekleyerek, bir saldırganın NTLM kimlik doğrulamasına geçiş yapmasına olanak tanır. Bu web hizmetleri varsayılan olarak HTTPS'yi etkinleştirse de, HTTPS tek başına NTLM relay saldırılarına karşı koruma sağlamaz. HTTPS hizmetleri için NTLM relay saldırılarına karşı koruma, HTTPS'nin kanal bağlama ile birleştirilmesiyle mümkündür. Ne yazık ki, AD CS, kanal bağlama için gerekli olan IIS'de Genişletilmiş Kimlik Doğrulama Korumasını etkinleştirmemektedir.
NTLM relay saldırılarındaki yaygın bir sorun, NTLM oturumlarının kısa süresi ve saldırganın NTLM imzalamayı gerektiren hizmetlerle etkileşimde bulunamamasıdır.
Yine de, bu sınırlama, bir kullanıcı için bir sertifika edinmek amacıyla bir NTLM relay saldırısını kullanarak aşılmaktadır, çünkü sertifikanın geçerlilik süresi oturumun süresini belirler ve sertifika, NTLM imzalamayı zorunlu kılan hizmetlerle kullanılabilir. Çalınan bir sertifikanın nasıl kullanılacağına dair talimatlar için bakınız:
AD CS Account PersistenceNTLM relay saldırılarının bir diğer sınırlaması, bir saldırgan kontrolündeki makinenin bir mağdur hesabı tarafından kimlik doğrulanması gerektiğidir. Saldırgan ya bekleyebilir ya da bu kimlik doğrulamayı zorlamaya çalışabilir:
Force NTLM Privileged AuthenticationCertify’nin cas komutu, etkin HTTP AD CS uç noktalarını listeler:
msPKI-Enrollment-Servers özelliği, kurumsal Sertifika Otoriteleri (CA'lar) tarafından Sertifika Kaydı Servisi (CES) uç noktalarını depolamak için kullanılır. Bu uç noktalar, Certutil.exe aracını kullanarak ayrıştırılabilir ve listelenebilir:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Certipy, varsayılan olarak, iletilen hesap adının $ ile bitip bitmediğine bağlı olarak Machine veya User şablonuna dayalı olarak bir sertifika talep eder. Alternatif bir şablonun belirtilmesi -template parametresi kullanılarak gerçekleştirilebilir.
Kimlik doğrulamasını zorlamak için PetitPotam gibi bir teknik kullanılabilir. Alan denetleyicileri ile çalışırken, -template DomainController belirtilmesi gereklidir.
Yeni değer CT_FLAG_NO_SECURITY_EXTENSION (0x80000) için msPKI-Enrollment-Flag, ESC9 olarak adlandırılır, bir sertifikada yeni szOID_NTDS_CA_SECURITY_EXT güvenlik uzantısının gömülmesini engeller. Bu bayrak, StrongCertificateBindingEnforcement 1 (varsayılan ayar) olarak ayarlandığında önem kazanır; bu, 2 ayarıyla çelişir. Daha zayıf bir sertifika eşlemesinin Kerberos veya Schannel için istismar edilebileceği senaryolarda (ESC10'da olduğu gibi) önemi artar, çünkü ESC9'un yokluğu gereksinimleri değiştirmez.
Bu bayrağın ayarının önemli hale geldiği koşullar şunlardır:
StrongCertificateBindingEnforcement 2 olarak ayarlanmamışsa (varsayılan 1), veya CertificateMappingMethods UPN bayrağını içeriyorsa.
Sertifika, msPKI-Enrollment-Flag ayarındaki CT_FLAG_NO_SECURITY_EXTENSION bayrağı ile işaretlenmişse.
Sertifika tarafından herhangi bir istemci kimlik doğrulama EKU'su belirtilmişse.
Başka bir hesabı tehlikeye atmak için herhangi bir hesap üzerinde GenericWrite izinleri mevcutsa.
Diyelim ki John@corp.local, Jane@corp.local üzerinde GenericWrite izinlerine sahip ve amacı Administrator@corp.local'ı tehlikeye atmaktır. Jane@corp.local'ın kaydolmasına izin verilen ESC9 sertifika şablonu, msPKI-Enrollment-Flag ayarında CT_FLAG_NO_SECURITY_EXTENSION bayrağı ile yapılandırılmıştır.
İlk olarak, Jane'in hash'i, John'ın GenericWrite'ı sayesinde Shadow Credentials kullanılarak elde edilir:
Sonrasında, Jane'in userPrincipalName'i Administrator olarak değiştirilir, @corp.local alan kısmı kasıtlı olarak atlanır:
Bu değişiklik, Administrator@corp.local'ın Administrator'ın userPrincipalName'i olarak farklı kalması koşuluyla kısıtlamaları ihlal etmez.
Bunun ardından, savunmasız olarak işaretlenmiş ESC9 sertifika şablonu Jane olarak talep edilir:
Belirtilmiştir ki, sertifikanın userPrincipalName değeri Administrator olarak yansımaktadır ve herhangi bir “object SID” içermemektedir.
Jane'in userPrincipalName değeri daha sonra orijinaline, Jane@corp.local olarak geri döndürülmektedir:
Verilen sertifika ile kimlik doğrulama denemesi artık Administrator@corp.local NT hash'ini veriyor. Sertifikanın alan belirtimi eksik olduğundan, komut -domain <domain> içermelidir:
ESC10 tarafından belirtilen iki kayıt defteri anahtar değeri alan denetleyicisinde bulunmaktadır:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel altında CertificateMappingMethods için varsayılan değer 0x18 (0x8 | 0x10), daha önce 0x1F olarak ayarlanmıştı.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc altında StrongCertificateBindingEnforcement için varsayılan ayar 1, daha önce 0 idi.
Durum 1
StrongCertificateBindingEnforcement 0 olarak yapılandırıldığında.
Durum 2
Eğer CertificateMappingMethods UPN bitini (0x4) içeriyorsa.
StrongCertificateBindingEnforcement 0 olarak yapılandırıldığında, GenericWrite izinlerine sahip bir A hesabı, herhangi bir B hesabını tehlikeye atmak için kullanılabilir.
Örneğin, Jane@corp.local üzerinde GenericWrite izinlerine sahip bir saldırgan, Administrator@corp.local hesabını tehlikeye atmayı hedefler. Prosedür ESC9'u yansıtır ve herhangi bir sertifika şablonunun kullanılmasına izin verir.
İlk olarak, Jane'in hash'i Shadow Credentials kullanılarak elde edilir, GenericWrite'ı suistimal ederek.
Sonrasında, Jane'in userPrincipalName'i Administrator olarak değiştirilir, kısıtlama ihlalini önlemek için @corp.local kısmı kasıtlı olarak atlanır.
Bunun ardından, varsayılan User şablonunu kullanarak Jane olarak istemci kimlik doğrulamasını sağlayan bir sertifika talep edilir.
Jane'in userPrincipalName'i daha sonra orijinaline, Jane@corp.local olarak geri döndürülür.
Elde edilen sertifika ile kimlik doğrulama, Administrator@corp.local'ın NT hash'ini verecektir; bu, sertifikada alan bilgileri bulunmadığı için komutta alanın belirtilmesini gerektirir.
CertificateMappingMethods içinde UPN bit bayrağı (0x4) bulunan bir A hesabı, userPrincipalName özelliğinden yoksun olan herhangi bir B hesabını, makine hesapları ve yerleşik alan yöneticisi Administrator dahil olmak üzere, tehlikeye atabilir.
Burada amaç, Jane'in hash'ini Shadow Credentials aracılığıyla elde ederek DC$@corp.local'ı tehlikeye atmaktır ve GenericWrite'ı kullanmaktır.
Jane'in userPrincipalName değeri DC$@corp.local olarak ayarlanır.
Jane olarak varsayılan User şablonunu kullanarak bir istemci kimlik doğrulama sertifikası talep edilir.
Jane'in userPrincipalName'i bu işlemden sonra orijinal haline geri döner.
Schannel üzerinden kimlik doğrulamak için, Certipy'nin -ldap-shell seçeneği kullanılır ve kimlik doğrulama başarısı u:CORP\DC$ olarak belirtilir.
LDAP shell aracılığıyla, set_rbcd gibi komutlar, kaynak tabanlı kısıtlı delege etme (RBCD) saldırılarına olanak tanır ve bu da etki alanı denetleyicisini tehlikeye atabilir.
Bu zafiyet, userPrincipalName'ı olmayan veya sAMAccountName ile eşleşmeyen herhangi bir kullanıcı hesabını da kapsamaktadır; varsayılan Administrator@corp.local, yükseltilmiş LDAP ayrıcalıkları ve varsayılan olarak userPrincipalName'ın olmaması nedeniyle birincil hedefdir.
Eğer CA Sunucusu IF_ENFORCEENCRYPTICERTREQUEST ile yapılandırılmamışsa, RPC hizmeti aracılığıyla imzalamadan NTLM iletme saldırıları gerçekleştirilebilir. Burada referans bulunmaktadır.
Enforce Encryption for Requests devre dışıysa, certipy kullanarak durumu belirleyebilirsiniz ve certipy ESC11 Zafiyetlerini gösterecektir.
Bir relay sunucusu kurmak gerekiyor:
Not: Alan denetleyicileri için -template parametresini DomainController'da belirtmemiz gerekir.
Ya da sploutchy'nin impacket çatallamasını kullanarak:
Yönetici, Sertifika Otoritesini "Yubico YubiHSM2" gibi harici bir cihazda depolamak için ayarlayabilir.
USB cihazı CA sunucusuna bir USB portu aracılığıyla bağlıysa veya CA sunucusu sanal bir makineyse bir USB cihaz sunucusu varsa, YubiHSM'de anahtarları oluşturmak ve kullanmak için Anahtar Depolama Sağlayıcısı tarafından bir kimlik doğrulama anahtarı (bazen "şifre" olarak adlandırılır) gereklidir.
Bu anahtar/şifre, HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword altında açık metin olarak kayıt defterinde saklanır.
Burada referans.
Eğer CA'nın özel anahtarı fiziksel bir USB cihazında saklanıyorsa ve shell erişimi elde ettiyseniz, anahtarı geri almak mümkündür.
Öncelikle, CA sertifikasını (bu kamuya açıktır) elde etmeniz ve ardından:
Son olarak, CA sertifikası ve özel anahtarını kullanarak yeni bir keyfi sertifika oluşturmak için certutil -sign komutunu kullanın.
msPKI-Certificate-Policy niteliği, sertifika şablonuna ihraç politikasının eklenmesine olanak tanır. İhraç politikalarından sorumlu msPKI-Enterprise-Oid nesneleri, PKI OID konteynerinin Yapılandırma İsimlendirme Bağlamı'nda (CN=OID,CN=Public Key Services,CN=Services) keşfedilebilir. Bir politika, bu nesnenin msDS-OIDToGroupLink niteliği kullanılarak bir AD grubuna bağlanabilir ve bu, bir sistemin sertifikayı sunan bir kullanıcıyı grubun üyesiymiş gibi yetkilendirmesine olanak tanır. Burada referans.
Diğer bir deyişle, bir kullanıcının bir sertifika kaydetme izni olduğunda ve sertifika bir OID grubuna bağlandığında, kullanıcı bu grubun ayrıcalıklarını miras alabilir.
OIDToGroupLink bulmak için Check-ADCSESC13.ps1 kullanın:
Bir kullanıcı izni bulun, certipy find veya Certify.exe find /showAllPermissions kullanabilir.
Eğer John, VulnerableTemplate'e kaydolma iznine sahipse, kullanıcı VulnerableGroup grubunun ayrıcalıklarını miras alabilir.
Tek yapması gereken şablonu belirtmek, OIDToGroupLink haklarına sahip bir sertifika alacaktır.
Çapraz orman kaydı için yapılandırma oldukça basittir. Kaynak ormandan gelen kök CA sertifikası, yöneticiler tarafından hesap ormanlarına yayımlanır ve kaynak ormandan gelen kurumsal CA sertifikaları, her hesap ormanındaki NTAuthCertificates ve AIA konteynerlerine eklenir. Bu düzenleme, kaynak ormandaki CA'ya, yönettiği PKI için tüm diğer ormanlar üzerinde tam kontrol sağlar. Eğer bu CA saldırganlar tarafından ele geçirilirse, hem kaynak hem de hesap ormanlarındaki tüm kullanıcılar için sertifikalar saldırganlar tarafından sahte olarak oluşturulabilir, böylece ormanın güvenlik sınırı ihlal edilmiş olur.
Çoklu orman ortamlarında, sertifika şablonları yayımlayan Kurumsal CA'lar konusunda dikkatli olunmalıdır; bu şablonlar Kimlik Doğrulanmış Kullanıcılar veya yabancı prensiplerin (Kurumsal CA'nın ait olduğu ormanın dışındaki kullanıcılar/gruplar) kayıt ve düzenleme haklarına izin verir. Bir güven ilişkisi üzerinden kimlik doğrulama yapıldığında, Kimlik Doğrulanmış Kullanıcılar SID'si AD tarafından kullanıcının token'ına eklenir. Dolayısıyla, eğer bir alan, Kimlik Doğrulanmış Kullanıcılar için kayıt hakları veren bir Kurumsal CA'ya sahipse, bir farklı ormandan bir kullanıcı tarafından bir şablon kaydedilebilir. Benzer şekilde, eğer bir şablon tarafından bir yabancı prense açıkça kayıt hakları verilirse, bu durumda çapraz orman erişim kontrol ilişkisi oluşturulur, bu da bir ormandan bir prensibin başka bir ormandan bir şablona kaydolmasını sağlar.
Her iki senaryo da bir ormandan diğerine saldırı yüzeyinin artmasına yol açar. Sertifika şablonunun ayarları, bir saldırgan tarafından yabancı bir alanda ek ayrıcalıklar elde etmek için istismar edilebilir.
