Merhaba
Önceki bölümde Domain Controller’ın kimlik doğrulama sürecinin kendisini ele geçiren Skeleton Key’i inceledik. Bu bölümde, modern, şifresiz (passwordless) kimlik doğrulama altyapısının Windows Hello for Business’ın kendine özgü bir zayıflığını istismar eden Shadow Credentials tekniğini ele alıyoruz. İroni şu ki, kuruluşları şifre tabanlı saldırılara karşı daha güvenli hale getirmesi beklenen bir özellik, doğru yapılandırılmadığında yeni bir kalıcılık ve yetki yükseltme yolu haline gelebiliyor.
Shadow Credentials’ın Ele Geçirilmesi
Shadow Credentials, saldırganların kullanıcı ve bilgisayar nesneleri üzerindeki ‘msDS-KeyCredentialLink’ özniteliğini değiştirerek yetki yükseltmesi ve yanal hareket (lateral movement) yapması için kullandığı bir tekniktir. Bu, saldırganların bu nesneler olarak kimlik doğrulamasını ve onların erişimini devralmasını sağlar. ‘msDS-KeyCredentialLink’ özniteliği, Windows Hello for Business dahil şifresiz kimlik doğrulama mekanizmalarını desteklemek için Windows Server 2016 Domain Functional Level ile tanıtılmıştır.
Bir saldırgan bir nesne üzerinde yeterli izne sahipse veya yüksek ayrıcalıklı bir güvenlik grubunun (örneğin Domain Admins) üyesiyse, bu özniteliği değiştirerek kötü niyetli bir anahtar kimlik bilgisi (key credential) ekleyebilir. Bu, saldırganın hedef nesne olarak sertifika tabanlı kimlik doğrulama kullanarak kimlik doğrulamasını ve bir Domain Controller’dan bir TGT (Ticket Granting Ticket) talep etmesini sağlar. TGT (Ticket Granting Ticket) elde edildikten sonra, saldırgan hedef nesneyi taklit edebilir ve onun ayrıcalıklarını devralabilir.
Shadow Credentials kalıcı erişim sağlayabilir, çünkü kötü niyetli anahtar kimlik bilgisi, kullanıcı veya bilgisayar nesnesinin şifresi değiştirilse bile geçerli kalır. Tek bir nesneyle birden fazla anahtar kimlik bilgisi ilişkilendirilebildiğinden, yetkili ve yetkisiz kimlik bilgileri bir arada var olabilir. Bu, saldırganların meşru şifresiz kimlik doğrulama çözümleri kullanılırken bile erişimlerini sürdürmesine olanak tanır.
Varsayılan olarak:
- Domain Admins güvenlik grubunun üyeleri, bir domain’deki tüm kullanıcı ve bilgisayar nesneleri için ‘msDS-KeyCredentialLink’ özniteliğini değiştirebilir.
- Key Admins ve Enterprise Key Admins güvenlik gruplarının üyeleri, bir domain’deki tüm bilgisayar nesneleri için bu özniteliği değiştirebilir.
Shadow Credentials’ı Mitigasyon Etmek
Shadow Credentials’ı mitigasyon etmek için kuruluşlar, yalnızca yetkili kullanıcıların kullanıcı ve bilgisayar nesneleri üzerindeki ‘msDS-KeyCredentialLink’ özniteliğini değiştirebilmesini sağlamalıdır. Bu şu şekillerde başarılabilir:
- Domain Admins, Key Admins ve Enterprise Key Admins dahil ayrıcalıklı güvenlik gruplarının üyeliğini kısıtlayın.
- ‘msDS-KeyCredentialLink’ özniteliğinin değiştirilmesine izin veren devredilmiş (delegated) izinleri gözden geçirin ve en aza indirin.
- Nesneleri yetkisiz anahtar kimlik bilgileri açısından düzenli olarak gözden geçirin.
Shadow Credentials’ı Tespit Etmek
Shadow Credentials’ı tespit etmek, kullanıcı ve bilgisayar nesneleri üzerindeki ‘msDS-KeyCredentialLink’ özniteliğine yapılan yetkisiz değişikliklerin belirlenmesini gerektirir.
Directory Service Değişikliklerinin Günlüğe Kaydedilmesi: Kuruluşlar, Active Directory nesne değişikliklerinin denetimini etkinleştirmeli ve ‘msDS-KeyCredentialLink’ özniteliğindeki değişiklikleri izlemelidir. Tipik olarak, yalnızca Windows Hello for Business gibi yetkili şifresiz kimlik doğrulama iş akışları bu özniteliği değiştirir. Bu öznitelik değiştirildiğinde, değişikliği işleyen Domain Controller’da bir olay üretilir. Onaylı kayıt (registration) iş akışları dışındaki hesaplar, hizmetler veya sistemler tarafından yapılan değişiklikler araştırılmalıdır.
Bu tespiti uygulamak için:
- Group Policy’de Security Settings altında ‘Advanced Audit Policy Configuration’ kapsamında ‘Audit Directory Service Changes’i etkinleştirin.
- İlgili tüm Active Directory nesneleri için, denetlenen nesnelerde ‘msDS-KeyCredentialLink’ değişikliklerini denetlemek üzere System Access Control List’leri (SACL) yapılandırın.
Yapılandırıldığında, directory service değişiklikleri Domain Controller’larda Security Log’da Event ID 5136 üretir. Event ID 5136, Shadow Credentials’a özgü değildir ve diğer meşru veya kötü niyetli directory service değişiklik etkinlikleri tarafından da üretilebilir.
Bir Shadow Credentials ele geçirilmesi gerçekleştiğinde, bu olay şunları içerir:
- Attribute LDAP Display Name alanı ‘msDS-KeyCredentialLink’tir.
- Subject Name alanı, yetkili bir kayıt hizmetiyle ilişkili değildir.
- Subject Account Name alanı, değişikliği yapan nesneyi tanımlar. Bu alan bilinen bir şifresiz kimlik doğrulama çözümüne karşılık gelmiyorsa, bir Shadow Credentials ele geçirilmesine işaret edebilir. Kuruluşlar, ‘msDS-KeyCredentialLink’ özniteliğini değiştirmesine izin verilen şifresiz kimlik doğrulama hizmetlerinin yetkili bir listesini tutmalıdır bir saldırgan, yalnızca hesap adı tanımasına dayanarak tespitten kaçınmak için meşru görünen yetkisiz bir hizmet dağıtabilir.
‘msDS-KeyCredentialLink’ Özniteliğinin Denetlenmesi: Özniteliğe yapılan değişikliklerin tespitine ek olarak, kuruluşlar yetkisiz anahtar kimlik bilgilerini belirlemek için bu özniteliği tüm kullanıcı ve bilgisayar nesneleri için düzenli olarak gözden geçirmelidir. Bu metadata, kimlik bilgisini oluşturan sistemi veya kullanıcıyı içermez, dolayısıyla tek başına yetkili olup olmadığını belirlemek için kullanılamaz; ancak şunları belirlemeye yardımcı olacak bağlamsal bilgi sağlar: beklenmedik şekilde tek bir nesneyle ilişkilendirilmiş birden fazla anahtar kimlik bilgisi değeri; şifresiz kimlik doğrulama kullanmayan nesnelerle ilişkilendirilmiş anahtar kimlik bilgisi değerleri; bilinen provizyon etkinlikleriyle uyuşmayan yakın zamanda eklenmiş anahtar kimlik bilgileri.
Shadow Credentials’ı Tespit Eden Olay
| Olay ID | Kaynak | Açıklama |
|---|---|---|
| 5136 | Domain Controller’lar | Bir Active Directory nesnesindeki bir öznitelik değiştirildiğinde üretilir. Shadow Credentials için kuruluşlar, Attribute LDAP Display Name’in ‘msDS-KeyCredentialLink’ olduğu ve Subject Name’in yetkili bir kayıt hizmetiyle ilişkili olmadığı bu Olay ID’sini izlemelidir. |
Lab Uygulaması
Bu bölümün lab uygulaması, W25DC (bakicubuk.local) üzerinde nihat.cubuk test hesabına karşı uçtan uca gerçek bir Shadow Credentials denemesidir. Kullanılan araç Whisker (Elad Shamir); resmi depoda derlenmiş bir binary bulunmadığından, topluluğun güvendiği SharpCollection gece derlemesi (nightly build) deposundan indirildi. Aynı şekilde Rubeus da SharpCollection üzerinden temin edildi.
1. Adım – Whisker ile sahte anahtar kimlik bilgisi ekleme:
W25DC‘de, Run as administrator (Yönetici olarak çalıştır), nihat.cubuk hesabının msDS-KeyCredentialLink özniteliğine sahte bir sertifika eklendi:
.\Whisker.exe add /target:nihat.cubuk /domain:bakicubuk.local /dc:w25dc.bakicubuk.local /path:C:\Temp\nihat5.pfx /password:P@ssword5Komut ilk denemede sorunsuz çalıştı: hedef hesap bulundu, sertifika üretildi, msDS-KeyCredentialLink özniteliği başarıyla güncellendi ve sertifika C:\Temp\nihat5.pfx olarak diske kaydedildi. Whisker, çıktısının sonunda bir sonraki adımda kullanılacak Rubeus komutunu da otomatik olarak önerdi.
2. Adım – Sertifika ile PKINIT kimlik doğrulama:
Elde edilen .pfx sertifikası, Rubeus’un asktgt modülüyle kullanılarak, nihat.cubuk‘un gerçek şifresi hiç bilinmeden bir TGT (Ticket Granting Ticket) talep edildi. İlk denemede Rubeus’un varsayılan şifreleme türü (RC4) ile istek gönderildi:
.\Rubeus.exe asktgt /user:nihat.cubuk /certificate:C:\Temp\nihat5.pfx /password:"P@ssword5" /domain:bakicubuk.local /dc:w25dc.bakicubuk.local /getcredentials /showBu istek, Windows Server 2025 KDC’sinden KDC_ERR_ETYPE_NOTSUPP; hatasıyla reddedildi modern KDC, PKINIT için artık RC4 şifreleme türünü kabul etmiyor.
Komut, SpecterOps’un Rubeus dokümantasyonunda doğrulanan /enctype:aes256 parametresi eklenerek tekrar çalıştırıldı:
.\Rubeus.exe asktgt /user:nihat.cubuk /certificate:C:\Temp\nihat5.pfx /password:"P@ssword5" /domain:bakicubuk.local /dc:w25dc.bakicubuk.local /enctype:aes256 /getcredentials /showBu sefer istek aes256_cts_hmac_sha1 ile başarıyla tamamlandı ve nihat.cubuk için geçerli bir TGT (Ticket Granting Ticket) elde edildi hesabın gerçek şifresi hiçbir anda kullanılmadı veya bilinmedi.
/getcredentials parametresiyle Rubeus, elde edilen TGT (Ticket Granting Ticket)’yi U2U (User-to-User) ile kullanarak hesabın NTLM hash’ini de çözdü:
Böylece saldırgan, hedef hesabın parolasını hiç bilmeden veya sıfırlamadan, yalnızca msDS-KeyCredentialLink özniteliğine yazma yetkisiyle hem TGT (Ticket Granting Ticket) hem de hesabın NTLM hash’ini elde etmiş oldu.
3. Adım – Tespit doğrulaması:
Raporun önerdiği tespit yönteminin gerçekten çalışıp çalışmadığı test edildi. İlk denemede yalnızca auditpol /set /subcategory:"Directory Service Changes" etkinleştirilmesine rağmen Event ID 5136 üretilmedi – bunun nedeni, domain kökünde msDS-KeyCredentialLink özniteliğine özel bir SACL (System Access Control List) tanımlı olmamasıydı. Şemadan canlı olarak alınan schemaIDGUID kullanılarak bir SACL kuralı eklendi, ancak ilk deneme de sessizce başarısız oldu 4 parametreli ActiveDirectoryAuditRule kurucusu yalnızca domain kökü nesnesinin kendisine uygulanıyor, alt nesneleri (kullanıcı hesaplarını) kapsamıyordu. Kural, kalıtım kapsamını "Descendents" olarak genişleten 5 parametreli kurucuyla yeniden oluşturulduktan sonra sorun çözüldü:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5136} -MaxEvents 5 | Format-ListDüzeltmenin ardından Event ID 5136 doğru şekilde üretildi. Olay kaydı, Attribute LDAP Display Name: msDS-KeyCredentialLink değerini ve Subject Account Name: Administrator bilgisini açıkça gösteriyor raporun belirttiği gibi, bu hesap bilinen bir parolasız kimlik doğrulama sağlayıcısı (passwordless-auth provisioning) hizmetiyle ilişkili olmadığından şüpheli olarak işaretlenmesi gereken bir davranış.
Bu üç aşamalı sonuç, raporun hem saldırı vektörünü (parola bilmeden TGT (Ticket Granting Ticket) ve NTLM hash elde etme) hem de önerdiği tespit yöntemini (Event ID 5136 + öznitelik bazlı SACL) doğrulayan eksiksiz bir kanıt zinciri oluşturuyor.
Uyumluluk ve Çerçeve Eşlemesi Tablosu
| Çerçeve | İlgili Kontrol/Madde |
|---|---|
| PCI DSS | Gereksinim 7.1 (Erişim kısıtlaması), Gereksinim 10.2 (Denetim izleri) |
| HIPAA | 164.312(a)(1) – Erişim Kontrolü, 164.312(b) – Denetim Kontrolleri |
| ISO 27001 | A.9.2 (Kullanıcı Erişim Yönetimi), A.12.4 (Günlükleme ve İzleme) |
| KVKK | Madde 12 – Veri Güvenliğine İlişkin Yükümlülükler |
| TCMB | Bilgi Sistemleri Yönetimi Tebliğ – Erişim ve Yetkilendirme Kontrolleri |
| NIST CSF | PR.AC-4 (Erişim izinleri ve yetkilendirmeleri yönetilir), DE.CM-1 (Ağ izlenir) |
| CIS Controls | CIS 5 (Hesap Yönetimi), CIS 6 (Erişim Kontrol Yönetimi) |
MITRE ATT&CK: T1098.005 (Account Manipulation: Device Registration), T1558 (Steal or Forge Kerberos Tickets)
Sonuç
Shadow Credentials, güvenliği artırmak için tasarlanmış bir özelliğin (şifresiz kimlik doğrulama) bile, yetersiz izin kontrolleriyle birleştiğinde saldırganlar için yeni bir kalıcılık yolu haline gelebileceğini gösteriyor.
Serinin bir sonraki ve son bölümünde, tüm bu teknikleri “canary” (tuzak) hesaplar ve nesnelerle nasıl proaktif olarak tespit edebileceğimizi ve serinin genel bir özetini ele alacağız.