Merhaba

Bu bölüme kadar incelediğimiz tüm teknikler Golden Ticket, Silver Ticket, DCSync Kerberos protokolü etrafında dönüyordu ve sonuçta hepsi klasik bir Active Directory ortamının sınırları içinde kalıyordu. Ancak günümüzün kurumsal ortamlarında kimlik doğrulama artık tek başına Kerberos’a dayanmıyor; birçok organizasyon, bulut hizmetlerine (Microsoft 365, Azure, üçüncü parti SaaS uygulamaları) erişimi federasyon protokolleri üzerinden sağlıyor. Bu bölümde, bu federasyon katmanının kendisinin nasıl ele geçirilebileceğini Golden SAML tekniğini inceliyoruz.

Golden SAML

Federasyon mimarilerinde (örneğin AD FS (Active Directory Federation Services)), bir kullanıcı bir bulut hizmetine (örneğin Microsoft 365) erişmek istediğinde, önce kurum içi federasyon sunucusuna (AD FS sunucusu) yönlendirilir, burada Active Directory kimlik bilgileriyle kimlik doğrulaması yapar, ve federasyon sunucusu kullanıcı için imzalı bir SAML token’ı üretir. Bu token, kullanıcının kimliğini ve yetkilerini (claim’lerini) bulut hizmetine kanıtlar; bulut hizmeti token’ın imzasını, federasyon sunucusunun token imzalama sertifikası (token-signing certificate) ile doğrular ve imza geçerliyse kullanıcıyı federasyon sunucusuna hiç geri sormadan içeri alır.

Golden Ticket’ın krbtgt hash’i ile domain genelinde sınırsız Kerberos bileti üretmesine tam olarak paralel bir mantıkla, Golden SAML tekniği de bir saldırganın federasyon sunucusunun token imzalama özel anahtarını ele geçirmesi durumunda ortaya çıkar. Bu özel anahtar ele geçirildiğinde, saldırgan artık federasyon sunucusuna hiç dokunmadan, kendi bilgisayarında istediği herhangi bir kullanıcı kimliğiyle, istediği yetkilerle (örneğin Genel Yönetici / Global Administrator rolüyle) sahte bir SAML token’ı imzalayabilir ve bunu doğrudan bulut hizmetine sunabilir. Bulut hizmeti, imza kriptografik olarak geçerli olduğu için token’ı sorgusuz kabul eder ortada gerçek bir kimlik doğrulama olayı, hatta çoğu zaman kurum içi Active Directory’ye dokunan tek bir iz bile yoktur.

Bu tekniğin özellikle tehlikeli olmasının nedeni, saldırının tamamen federasyon sunucusunun dışında, saldırganın kendi ortamında gerçekleşebilmesidir: token imzalama anahtarı bir kez çalındıktan sonra, saldırgan federasyon sunucusuna veya Active Directory’ye bir daha hiç bağlanmadan, doğrudan bulut kimlik sağlayıcısıyla (örneğin Microsoft Entra ID) konuşabilir. Bu da tespiti kurum içi güvenlik günlüklerine bağımlı olan organizasyonlar için ciddi bir kör nokta yaratır çünkü izlenecek olay, kurum içinde değil bulut tarafında, çoğu zaman farklı bir ekibin sorumluluğunda olan loglarda bulunur.

Token imzalama sertifikasının özel anahtarı genellikle AD FS (Active Directory Federation Services) sunucusunun kendi veritabanında (WID (Windows Internal Database) veya SQL Server) şifreli olarak saklanır ve DPAPI (Data Protection API) ile korunur. Bu anahtarı ele geçirmek için bir saldırganın tipik olarak AD FS (Active Directory Federation Services) sunucusu üzerinde yönetici (Local Administrator veya Domain Admin) düzeyinde erişime sahip olması gerekir bu da Golden SAML’i genellikle bir saldırının erken aşamasında değil, ortam zaten önemli ölçüde ele geçirildikten sonra kullanılan bir “kalıcılık ve yatay/dikey yayılma” tekniği haline getirir.

Golden SAML’i Mitigasyon Etmek

Bu tekniği mitigasyon etmek için aşağıdaki güvenlik kontrolleri uygulanmalıdır:

• AD FS sunucularını Tier 0 varlık olarak ele alın. Token imzalama anahtarına erişim, pratikte krbtgt hash’ine erişimle eşdeğer bir yetki seviyesi sağlar; bu sunuculara erişim domain controller’lara uygulanan aynı sıkı ayrıcalıklı erişim çalışma alanı (Privileged Access Workstation) ve katmanlı yönetim (tiering) kurallarına tabi olmalıdır.
• Token imzalama sertifikasını düzenli olarak döndürün (rotate edin). Varsayılan olarak AD FS bu sertifikayı belirli aralıklarla otomatik olarak yeniler; bu otomatik döngünün devre dışı bırakılmadığından emin olun ve gerektiğinde manuel döngüyü tetikleyebilecek bir süreç tanımlayın.
• Mümkün olduğunda bulut tabanlı kimlik doğrulamaya (Microsoft Entra ID’nin doğrudan kimlik doğrulaması, Password Hash Sync veya Pass-through Authentication) geçmeyi değerlendirin. Federasyonun ortadan kaldırılması, token imzalama anahtarının çalınması riskini de ortadan kaldırır.
• AD FS sunucularında ve destek veritabanlarında (WID/SQL) ayrıcalıklı erişimi sıkı biçimde sınırlayın ve izleyin. Özellikle veritabanına doğrudan erişimi olan hesapları (yedekleme hesapları dahil) gözden geçirin.
• Koşullu Erişim (Conditional Access) politikalarını, federasyon token’larının yanı sıra ek sinyaller (cihaz uyumluluğu, oturum konumu, risk skoru) gerektirecek şekilde yapılandırın. Bu, çalınmış bir token’ın tek başına yeterli olmasını önler.
• Bulut tarafı oturum açma günlüklerini (Microsoft Entra ID Sign-in Logs / Audit Logs) kurum içi güvenlik günlükleriyle aynı SIEM’de birleştirin. Golden SAML’in izleri neredeyse tamamen bulut tarafında olduğu için, bu görünürlük olmadan teknik pratikte tespit edilemez hale gelir.

Golden SAML’i Tespit Etmek

Golden SAML’in tespiti, önceki Kerberos tabanlı tekniklerden temelde farklıdır: izlenecek olaylar kurum içi Active Directory’de değil, büyük ölçüde bulut kimlik sağlayıcısının kendi günlüklerindedir.

Golden SAML’i Tespit Eden Olaylar

Kaynak	Açıklama
Microsoft Entra ID Oturum Açma Günlükleri	Bir kullanıcı için, bilinen bir cihaz/konum/tarayıcı deseniyle uyuşmayan, beklenmeyen bir federasyon oturum açması; özellikle o kullanıcının normalde federasyon üzerinden hiç oturum açmadığı durumlarda anlamlıdır.
Microsoft Entra ID Denetim Günlükleri (Audit Logs)	Yüksek ayrıcalıklı rollere (Genel Yönetici gibi) beklenmeyen bir federasyon oturumu üzerinden erişim; rol atamalarının/kullanımlarının zaman ve kaynak deseni analiz edilmelidir.
AD FS Sunucu Güvenlik/Olay Günlükleri	Token imzalama sertifikasına veya AD FS (Active Directory Federation Services) yapılandırma veritabanına yapılan beklenmeyen erişim denemeleri; özellikle sertifika dışa aktarma (export) işlemleriyle ilişkili olay kayıtları.
SAML Token Claim Analizi	Bulut tarafında, gelen SAML token’larındaki IssueInstant, NotBefore/NotOnOrAfter gibi zaman damgalarının anormal (örneğin çok uzun geçerlilik süreli) olması veya beklenmeyen claim kombinasyonları.
Ağ Trafiği	AD FS sunucusundan beklenmeyen dışa aktarma/veritabanı erişim trafiği; sunucunun WID (Windows Internal Database) veya SQL Server bileşenine normal işletim dışı erişim desenleri.

Lab Uygulaması: Windows Server 2025 Üzerinde Golden SAML

Bu bölümde lab ortamımızda önce sıfırdan bir AD FS kurulumu yaptık (W25DC üzerine ki bu tercihin kendisi, birazdan göreceğimiz gibi, tekniğin önüne beklenmedik engeller çıkardı), ardından token imzalama sertifikasını ele geçirmeyi denedik.

Adım 1-4: AD FS Federasyon Rolünü Kurmak

W25DC üzerinde sırasıyla AD FS rolünü kurduk, adfs.bakicubuk.local için self-signed bir SSL sertifikası ve DNS A kaydı oluşturduk, federasyon hizmetinin çalışacağı svc_adfs adında bir hizmet hesabı oluşturduk ve son olarak çiftliği devreye aldık:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

New-SelfSignedCertificate -DnsName "adfs.bakicubuk.local" -CertStoreLocation "cert:\LocalMachine\My" -KeyExportPolicy Exportable -KeySpec KeyExchange -FriendlyName "ADFS Lab SSL"

Add-DnsServerResourceRecordA -Name "adfs" -ZoneName "bakicubuk.local" -IPv4Address "192.168.1.200"

New-ADUser -Name "svc_adfs" -SamAccountName "svc_adfs" -UserPrincipalName "[email protected]" -AccountPassword (ConvertTo-SecureString "..." -AsPlainText -Force) -Enabled $true -PasswordNeverExpires $true -CannotChangePassword $true

$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*adfs.bakicubuk.local*" } | Select-Object -First 1
$svcCred = Get-Credential -UserName "bakicubuk\svc_adfs"
Install-AdfsFarm -CertificateThumbprint $cert.Thumbprint -FederationServiceName "adfs.bakicubuk.local" -FederationServiceDisplayName "Bakicubuk Lab AD FS" -ServiceAccountCredential $svcCred

Kurulum DeploymentSucceeded mesajıyla başarıyla tamamlandı; bir yeniden başlatmanın ardından Get-Service adfssrv servisin Running durumda olduğunu doğruladı.

Adım 5: Demo Bir Relying Party Oluşturmak

Sahte token’ı sunacağımız hedef olarak, gerçek bir bulut hizmeti yerine kendi oluşturduğumuz zararsız bir demo relying party ekledik Silver Ticket’ta kendi paylaşımımızı hedef almamızla aynı mantık:

Add-AdfsRelyingPartyTrust -Name "SAMLDemoApp" -Identifier "https://samldemo.bakicubuk.local/" -WSFedEndpoint "https://samldemo.bakicubuk.local/wsfed"

Adım 6: Token İmzalama Sertifikasını Ele Geçirmeyi Denemek

Burada, tekniğin gerçek dünyadaki karmaşıklığını gösteren üç ayrı engelle karşılaştık.

İlk engel: Get-AdfsCertificate -CertificateType Token-Signing komutu bize sertifikanın Thumbprint değerini (a0f045d6401fd2dc810f181deb22f6f8d10a12ac) ve StoreLocation değerinin CurrentUser olduğunu gösterdi yani özel anahtar, komutu çalıştıran yöneticinin değil, AD FS’in çalıştığı hizmet hesabının (svc_adfs) kendi profilinde saklanıyor. Administrator bağlamında sertifikayı Cert:\CurrentUser\My altında aramak boş sonuç döndürdü; anahtara ulaşmak için svc_adfs kimliğiyle bir oturum açmamız gerekti.

Ancak runas /user:bakicubuk\svc_adfs powershell.exe denemesi şu hatayla başarısız oldu:

RUNAS ERROR: Unable to run - powershell.exe
1385: Logon failure: the user has not been granted the requested logon type at this computer.

Bunun nedeni, domain controller’larda varsayılan olarak yalnızca belirli ayrıcalıklı gruplara (Administrators, Account Operators, Backup Operators, Server Operators, Print Operators vb.) yerel/interaktif oturum açma hakkının tanınmasıydı Default Domain Controllers Policy GPO’sundaki Allow log on locally ayarı bunu kısıtlıyor. Bu, AD FS’i bir domain controller üzerine kurmanın (ki bu zaten en iyi pratiklere aykırıdır) pratikte de sorun çıkardığı bir andı: servis kendisi Log on as a service hakkıyla sorunsuz çalışıyor, ama interaktif bir oturum bu hakka sahip değil.

Lab’ı ilerletebilmek için svc_adfs‘i geçici olarak bu politikaya ekledik:

Default Domain Controllers Policy içinde Allow log on locally ayarına BAKICUBUK\svc_adfs hesabının eklenmesi; AD FS’in bir domain controller üzerine kurulmasının gerektirdiği ek (ve normalde önerilmeyen) bir yapılandırma değişikliği.

gpupdate /force sonrası runas başarılı oldu ve svc_adfs bağlamında açılan pencerede sertifikayı bulabildik.

İkinci engel: Sertifikayı bulduktan sonra doğrudan dışa aktarmayı denedik:

Export-PfxCertificate -Cert $signingCert -FilePath C:\temp\adfs_signing.pfx -Password $pwd

Sonuç:

Export-PfxCertificate : Cannot export non-exportable private key.

AD FS, otomatik ürettiği token imzalama sertifikasının özel anahtarını varsayılan olarak non-exportable işaretliyor tıpkı Bölüm 11’de karşılaştığımız KDC’nin RC4 reddi gibi, burada da doğrudan bir sertleştirme kontrolüyle karşılaştık.

Üçüncü engel: Bunu aşmak için mimikatz’ın crypto::cng modülünü denedik bu modül, CNG (Cryptography API: Next Generation) katmanını bellekte yamalayarak non-exportable anahtarları da dışa aktarılabilir hale getirebiliyor. Mimikatz’ı svc_adfs bağlamında (özel anahtarın bulunduğu profilde) çalıştırdık:

crypto::cng

Sonuç:

ERROR kull_m_patch_genericProcessOrServiceFromBuild ; OpenProcess (0x00000005)

0x00000005 (Access Denied) hatası, yamanın uygulanabilmesi için gereken düşük seviyeli bellek erişiminin svc_adfs gibi sıradan bir domain hesabı için mümkün olmadığını gösterdi, bu işlem etkin biçimde yerel yönetici ayrıcalığı gerektiriyor. crypto::certificates /export komutu her iki AD FS sertifikasını (Encryption ve Signing) da listeledi, genel anahtarları dışa aktardı, ama özel anahtar dışa aktarımı her ikisinde de CryptAcquireCertificatePrivateKey (0x80090016) hatasıyla başarısız oldu.

Bulgunun Değerlendirilmesi

Bu üç engel üst üste bindiğinde ortaya gerçek bir savunma derinliği (defense in depth) örneği çıktı:

1. Domain Controller’ların varsayılan olarak sıradan hesaplara interaktif oturum hakkı vermemesi.
2. AD FS’in token imzalama anahtarını varsayılan olarak dışa aktarılamaz üretmesi.
3. Bu korumayı aşmak için kullanılan araçların (mimikatz’ın crypto::cng yaması gibi) kendisinin yükseltilmiş ayrıcalık gerektirmesi.

Bu üç katmanın aynı anda aşılabilmesi için saldırganın ya svc_adfs hesabının kendisini de yerel yönetici yapması (ki bu ciddi ve kolayca tespit edilebilir bir yanlış yapılandırma olurdu) ya da tamamen farklı bir yol (örneğin AD FS yapılandırma veritabanına WID (Windows Internal Database)/SQL Server doğrudan erişip DKM container’ından anahtarı çözmek) izlemesi gerekirdi.

Bu sonuç, makalenin başındaki mitigasyon önerilerinden birini lab ortamında somut biçimde doğruluyor: AD FS’i asla bir domain controller üzerine kurmayın. Bizim lab’ımızda karşılaştığımız ilk engelin (interaktif oturum kısıtlaması) hiç var olmaması, sadece AD FS’i ayrı, üye bir sunucuya kurmuş olsaydık ortadan kalkacaktı, bu da saldırganın işini bir kademe daha kolaylaştırırdı. Gerçek dünyada Golden SAML saldırıları, tam olarak bu nedenle, çoğunlukla AD FS’in kendi özel sunucusunda ve genellikle DKM container’ına AD üzerinden doğrudan erişimle (bizim burada denemediğimiz bir yöntemle) gerçekleştirilir.

Uyumluluk ve Çerçeve Eşlemesi Tablosu

Çerçeve	İlgili Kontrol/Madde
PCI DSS	Gereksinim 7.1 (Erişim kısıtlaması), Gereksinim 8.2 (Güçlü kimlik doğrulama)
HIPAA	164.312(a)(1) – Erişim Kontrolü, 164.312(d) – Kimlik Doğrulama
ISO 27001	A.9.2 (Kullanıcı Erişim Yönetimi), A.9.4 (Sistem ve Uygulama Erişim Kontrolü)
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-1 (Kimlik ve kimlik bilgisi yönetimi), PR.AC-7 (Kimlik doğrulama mekanizmaları)
CIS Controls	CIS 5 (Hesap Yönetimi), CIS 6 (Erişim Kontrol Yönetimi)

MITRE ATT&CK: T1606.002 (Forge Web Credentials: SAML Tokens)

Sonuç

Golden SAML, serinin önceki bölümlerinde gördüğümüz Kerberos tabanlı sahteciliklerin federasyon dünyasındaki karşılığı ve tespiti en zor tekniklerden biri, çünkü izler artık kurum içi Active Directory’nin dışında, bulut kimlik sağlayıcısının kendi günlüklerinde. Bu da savunma stratejisinin, yalnızca kurum içi günlüklere değil, bulut tarafı oturum açma ve denetim günlüklerine de aynı özenle bakmasını zorunlu kılıyor.

Serinin bir sonraki bölümünde, hibrit kimlik senaryolarının merkezinde yer alan bir başka bileşeni Microsoft Entra Connect’in ele geçirilmesini inceleyeceğiz.