Parola, hash, anahtar, ticket ve sertifika: Kimlik bilgisi türleri ve DPAPI’nin yeri.

1. Core Mechanism / Temel mekanizma

Bu ders kimlik materyallerini protokol kabiliyeti üzerinden karşılaştırır. Kerberos ticket yapısı RFC 4120, sertifika yapısı RFC 5280, DPAPI protect/unprotect bağlamı Windows API belgeleri üzerinden ele alınır. Hash türlerinin NTLM/Kerberos gibi protokollerdeki ayrıntılı yeniden kullanım yolları bu dersin dışında bırakılır.

Arabirimler ve belirtimler

• Parola: kullanıcının bildiği sır; protokole göre verifier veya anahtar türetim girdisi olabilir.
• Hash/verifier: belirli algoritmayla türetilmiş değer; plaintext parolanın bilindiğini tek başına kanıtlamaz.
• Kriptografik anahtar: belirli algoritma ve amaç için secret/public key material; kimlik veya policy kabulünü tek başına kanıtlamaz.
• Kerberos Ticket: açık realm ve sname ile hedef anahtarla korunan enc-part taşır; ticket tek başına istemcinin session key'e sahip olduğunu kanıtlamaz.
• X.509 certificate: subject/public-key bilgisi, issuer imzası, validity ve extensions taşır; ilgili private key'in elde olduğunu göstermez.
• CryptProtectData/CryptUnprotectData: uygulama verisini kullanıcı/makine bağlamına bağlı DPAPI blob olarak korur veya açar.

Etiketi değil gereken işlemi sor

Bir materyalin 'credential' diye adlandırılması onun her protokolde kullanılabileceği anlamına gelmez. Plaintext parola yeni türetimlere girdi olabilir; bir hash/verifier yalnız onu kabul eden veya hesaplamasında kullanan protokolde anlam kazanır; kriptografik anahtar ise algoritma, yön ve kullanım amacıyla birlikte değerlendirilir.

Kerberos ticket sunumu için ticket'a karşılık gelen session key ile authenticator üretmek gerekir. Sertifika public olabilir; possession kanıtı için private key gerekir. DPAPI blob ise ciphertext'tir ve onu kullanan uygulamanın bağlamı bilinmeden içeriği hakkında hüküm kurulamaz.

Ticket açık metadata ile şifreli bölümü birlikte taşır

RFC 4120 Ticket yapısında tkt-vno, realm ve sname açık alanlardır; enc-part hedef servis anahtarıyla korunan EncryptedData'dır. Artifact bu ayrımı sentetik bir APPLICATION [1] TLV üzerinde gösterir.

Ticket'ı kopyalamak, kullanılabilir bir AP-REQ üretmeye tek başına yetmez. İstemci ayrıca ticket içindeki session key'e karşılık gelen materyalle authenticator üretmelidir. Artifact'in dummy cipher baytları gerçek decrypt sonucu veya kullanılabilir credential değildir.

Sertifika ile private key'i ayır

X.509 sertifikası subject/public-key bilgisini, issuer imzasını, validity aralığını ve extensions alanlarını taşır. Sertifika dağıtılabilir bir public nesnedir; onun bulunması ilgili private key'in ele geçirildiğini göstermez.

Certificate authentication kabiliyeti için private key possession yanında zincir, zaman, amaç ve eşleme policy'sinin kabulü gerekir. Bu yüzden yalnız sertifika dosyasının görülmesi başarılı kimlik doğrulama sonucu sayılmaz.

DPAPI bağlamı blob'un kendisinden geniştir

CryptProtectData plaintext DATA_BLOB alır ve şifreli blob döndürür; uygulama encryption key'i doğrudan API'ye vermez. Varsayılan koruma aynı logon credential ve genellikle aynı bilgisayar bağlamına bağlıdır. Optional entropy kullanılmışsa unprotect sırasında aynı entropy gerekir.

CRYPTPROTECT_LOCAL_MACHINE seçilirse aynı bilgisayardaki kullanıcılar blob'u açabilir; dolayısıyla DPAPI her zaman yalnız tek kullanıcı demek değildir. Domain kullanıcıları için AD'deki domain backup key recovery yolu risk modeline girer. Açılan plaintext'in parola, private key veya başka veri olup olmadığı DPAPI'den değil uygulama semantiğinden anlaşılır.

Durum ve veri akışı

1. Uygulama korunacak plaintext'i ve varsa optional entropy'yi CryptProtectData'ya verir.
2. DPAPI kullanıcı veya machine bağlamından gereken koruma materyalini elde eder ve session key üretir.
3. Ciphertext, açıklama ve integrity bilgisi DPAPI blob'a yazılır.
4. Unprotect sırasında gereken bağlam ve kullanılmışsa aynı entropy sağlanır.
5. Domain senaryosunda parola-türetilmiş yol kullanılamazsa domain backup key recovery yolu rol oynayabilir.
6. Dönen plaintext'in kimlik materyali olup olmadığı kullanan uygulamanın veri semantiğiyle belirlenir.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: Ele geçirilen her credential nesnesi aynı şekilde yeniden kullanılabilir.

Technical prerequisites

• Materyalin gerçekten elde edilmiş olması; yalnız dosya adı veya ürün etiketi yeterli değildir.
• Hedef protokolün o materyal türünü kabul etmesi.
• Gereken eş materyalin bulunması: ticket için session key, certificate authentication için private key gibi.
• Geçerlilik süresi, hedef principal/service ve policy koşullarının sağlanması.
• DPAPI için uygun user/machine bağlamı, kullanılmışsa optional entropy veya geçerli recovery yolu.

Exploitation mechanism / İstismar mekanizması

Plaintext parola kabul eden protokol için yeni türetimlere olanak verebilir; hash/verifier yalnız belirli protokol hesabında işe yarar; ticket session key olmadan authenticator üretmez; certificate private key olmadan possession kanıtlamaz; DPAPI blob uygun bağlam veya recovery yeteneği olmadan plaintext değildir. Kabiliyet materyal türü ve hedef işlemin kesişimidir.

Kopyalama ile kullanabilmeyi ayır

Bir ticket dosyasını veya DPAPI blob'u kopyalamak, gereken gizli eş materyali otomatik olarak sağlamaz. Benzer biçimde sertifikanın public bölümü private key possession değildir.

Değerlendirme materyalin scope, validity, target ve policy koşullarını tek tek kaydetmelidir; 'credential bulundu' ifadesi sonuç değildir.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Bu ders Audit DPAPI Activity içindeki auditable protected data denemelerine odaklanır: 4694 protect, 4695 unprotect. Success/Failure ayarı ve çağrının audit koşulları önemlidir.
• Aynı alt kategori 4692 master-key backup ve 4693 master-key recovery denemelerini de kapsar. Master-key işlemlerini doğrudan veriyi protect/unprotect etmekle karıştırma.
• 4694 için CryptProtectData çağrısında CRYPTPROTECT_AUDIT ve boş olmayan description gerekir.
• Bu olaylar nesne SACL'ine bağlı değildir.
• Microsoft belgeleri bu kayıtları troubleshooting açısından ele alır; tek başına saldırı alarmı olarak zayıftır.

Events and relevant fields

• 4694/4695 belgelerinde Subject: Security ID, Account Name, Account Domain ve Logon ID alanları açıklanır.
• Protected Data bölümünde Data Description, Key Identifier, Protected Data Flags ve Protection Algorithms açıklanır.
• Status Information bölümünde Status Code açıklanır.
• Microsoft sayfaları örnek Event XML ve EventData Name değerleri yayımlamadığından bu derste adlandırılmış XML alanları üretilmez.

Telemetri sessizliğini yokluk kanıtı sayma

4694 için özel audit bayrağı ve description koşulu vardır. Bu nedenle olayın bulunmaması CryptProtectData kullanılmadığını göstermez.

Olay bulunsa bile plaintext türü kayıttan belirlenemez. Uygulama, process, dosya erişimi ve hesap bağlamı birlikte incelenmelidir.

Detection logic · XPath

*[System[(EventID=4694 or EventID=4695)]]

Query assumptions

• İfade yalnız Event ID seçer; named-field XPath eklenmemiştir.
• Success/Failure ayrımı backend'in System/Keywords eşlemesi doğrulandıktan sonra yapılmalıdır.
• Sorgu gerçek Windows sistemi veya SIEM üzerinde çalıştırılmadı; veri kümesi ve eşik yoktur.

False positives

• Meşru uygulamaların protect ve unprotect işlemleri olağandır.
• Çoğu DPAPI kullanımı CRYPTPROTECT_AUDIT olmadan gerçekleşebilir; olay yokluğu DPAPI kullanılmadığını göstermez.
• Başarılı unprotect, dönen plaintext'in credential olduğunu göstermez.
• Bu olay ailesi tek başına kötüye kullanımı ayırt etmekte zayıftır.

Hardening

• DPAPI blob'u plaintext veya kendi başına güvenli kabul etme; uygulamanın ACL ve execution context'ini değerlendir.
• CRYPTPROTECT_LOCAL_MACHINE'i yalnız machine-wide erişim gerçekten gerekiyorsa seç.
• Optional entropy kullanılıyorsa onu blob ile aynı yerde saklamama tasarımını değerlendir.
• Domain DPAPI backup key'lerini ve DC/AD yedeklerini yüksek değerli sır olarak koru.
• Audit DPAPI Activity'yi troubleshooting veya pilot kapsamda aç; düşük analitik değer nedeniyle tek başına saldırı alarmı yapma.

Örnekler üzerinde oku / Read the examples

61 61 30 5f a0 03 02 01 05 a1 11 1b 0f 49 59 45
4c 41 42 53 2e 45 58 41 4d 50 4c 45 a2 27 30 25
a0 03 02 01 02 a1 1e 30 1c 1b 04 63 69 66 73 1b
14 46 53 30 31 2e 69 79 65 6c 61 62 73 2e 65 78
61 6d 70 6c 65 a3 1c 30 1a a0 03 02 01 12 a1 03
02 01 03 a2 0e 04 0c a5 5a a5 5a 01 02 03 04 05
06 07 08

İki yanlış kanı / Two reality checks

Sanılan: Sertifika kimliğin gizli kanıtıdır; sertifikayı elde etmek kimlik doğrulamak için yeterlidir.

Gerçekte: Sertifika public key ve issuer imzalı kimlik bağını taşır. Possession kanıtı için ilgili private key ile kabul edilen amaç, zincir, zaman ve eşleme policy'si gerekir.

Sanılan: DPAPI ile korunmuş blob yalnız kullanıcının parolası biliniyorsa açılabilir.

Gerçekte: Varsayılan koruma logon credential ve genellikle host bağlamına bağlıdır; machine scope, optional entropy ve domain backup-key recovery koşulları modeli değiştirir. Blob'un kendisi plaintext değildir.

Kaynaklar / Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §5.3 Ticket, §5.2.9 EncryptedData, §3.2.2–3.2.3 ve §5.5.1 AP-REQ/authenticator.
• RFC 5280 · Internet X.509 Public Key Infrastructure Certificate Profile
  §4.1 ve §4.1.2.7; certificate yapısı ve subject public key info.
• Microsoft · CryptProtectData function
  Giriş, dwFlags ve Remarks; varsayılan bağlam, LOCAL_MACHINE ve audit koşulları.
• Microsoft · CryptUnprotectData function
  Parameters ve Remarks; optional entropy ve integrity davranışı.
• Microsoft · CNG DPAPI backup keys on AD domain controllers
  Domain backup key recovery mekanizması ve rotation sınırı.
• Microsoft · Audit DPAPI Activity
  Events List ve audit kapsamı.
• Microsoft · 4694(S, F) Protection of auditable protected data was attempted
  Event Schema ve CryptProtectData audit tetik koşulu.
• Microsoft · 4695(S, F) Unprotection of auditable protected data was attempted
  Event Schema ve Recommendations.