Signing, EPA ve channel binding: Hangi güvenlik özelliği neyi korur?

1. Core Mechanism / Temel mekanizma

Bu ders 07.01 (NTLM mesaj akışı) ve 07.02 (NTLMv2 response/oturum anahtarı) üzerine oturur ve 07.03'teki 'protokol neden NTLM seçildi' sorusunun devamında 'seçilen NTLM ne kadar korunuyor' sorusunu yanıtlar. Sınır nettir: burada odak, NTLM oturumunun üstüne konan koruma katmanları (signing/sealing, MIC, channel binding/EPA) ve bunların relay/reflection'ı hangi koşulda kırdığıdır. Kerberos delegasyonu, SMB'nin tüm ayrıntıları veya TLS'in kendi iç işleyişi bu dersin kapsamı dışındadır; TLS burada yalnızca 'channel binding'in bağlandığı dış kanal' olarak görünür.

Arabirimler ve belirtimler

• MS-NLMP §2.2.2.5 (Negotiate flags): NTLMSSP_NEGOTIATE_SIGN mesaj bütünlüğünü (imza), NTLMSSP_NEGOTIATE_SEAL mesaj gizliliğini (şifreleme) ister; ikisi ayrı bayraklardır. NTLMSSP_NEGOTIATE_KEY_EXCH ile AUTHENTICATE mesajı bir EncryptedRandomSessionKey taşır; dışa aktarılan oturum anahtarı KeyExchangeKey ile RC4 şifrelenir.
• MS-NLMP §2.2.2.1 AV_PAIR: MsvAvChannelBindings (0x000A) alanı, dış güvenli kanalın (ör. TLS) gss_channel_bindings_struct değerinin bir MD5 hash'idir; istemci bunu AUTHENTICATE içindeki hedef bilgisine koyarak iç NTLM kimlik doğrulamasını dış kanala bağlar (EPA'nın channel binding bileşeni).
• MS-NLMP §2.2.2.1 / §3.1.5.1.2: MsvAvTargetName (0x0009) hedef servisin SPN'ini (service binding) taşır; MsvAvFlags (0x0006) içindeki 0x00000002 biti bir MIC'in mevcut olduğunu belirtir. AUTHENTICATE mesajında bir MIC mevcut ve doğrulanıyorsa, bu MIC NEGOTIATE + CHALLENGE + AUTHENTICATE üçlüsünü oturum anahtarıyla HMAC-MD5 üzerinden korur ve bayrakların (ör. signing'in kaldırılması) sonradan değiştirilmesini engeller; MIC her oturumda mevcut/zorunlu olmayabilir.
• Microsoft KB4520412 (registry): NTDS\Parameters altında LDAPServerIntegrity signing zorunluluğunu belirler (1 = zorunlu değil, 2 = signing gerekir); LdapEnforceChannelBinding TLS üzerindeki channel binding zorlamasını belirler (0 = hiçbir zaman, 1 = destekleyen istemcilerde, 2 = her zaman).
• 2889, unsigned SASL/cleartext simple-bind girişimini client IP, attempted identity ve Binding Type ile bildirir. Diagnostic level 2 koşuluna bağlıdır; bind kabulünü veya policy enforcement durumunu tek başına kanıtlamaz.
• Microsoft KB4520412 (channel binding events): 3039, LDAP-over-SSL/TLS bir istemcinin LDAP channel binding token doğrulamasında başarısız olduğunu (When Supported veya Always politikası altında; asgari loglama seviyesi 2) raporlar. Politika Never iken 3040 son 24 saatteki korumasız LDAPS bind sayısını, 3041 ise 24 saatlik posture uyarısını (channel binding zorlaması önerilir) raporlar (asgari loglama seviyesi 0).
• MS-SMB2 §2.2.4 (signing): SMB2 oturumunda SMB2_NEGOTIATE_SIGNING_REQUIRED sunucunun imzalamayı zorunlu kıldığını belirtir; imzalama zorunluysa SMB üzerinden relay edilen bir oturum geçerli imza üretemez. Bu, LDAP dışındaki paralel bir bütünlük katmanıdır.

Signing bütünlüktür, sealing gizliliktir — ikisi aynı şey değildir

NTLM oturumunun üstüne konabilecek iki farklı koruma vardır ve bunlar sık sık karıştırılır. Signing (NTLMSSP_NEGOTIATE_SIGN), her mesaja bir imza (MAC) ekler; alıcı mesajın yolda değiştirilmediğini doğrular. Bu bir bütünlük korumasıdır: içerik hâlâ okunabilir, ama kurcalanamaz.

Sealing (NTLMSSP_NEGOTIATE_SEAL) ise mesajı şifreler; bu bir gizlilik korumasıdır. Windows'ta sealing pratikte signing'i de içerir, ama tersi doğru değildir: bir oturum imzalı (signed) olabilir ama şifresiz (unsealed) — içerik ağda görünür ama kurcalanamaz. 'İmzaladım' ile 'şifreledim' bu yüzden aynı cümle değildir.

Relay bağlamında kritik olan ayrım şudur: relay'i kıran şey çoğu zaman gizlilik (sealing) değil, bütünlük (signing) zorunluluğudur. Bir hedef 'imzalı mesaj isterim' dediğinde, araya giren taraf müzakere edilmiş oturum anahtarına sahip olmadığı için sonraki korumalı mesajlar için geçerli imza üretemez — içerik şifreli olmasa bile relay tutmaz.

Service binding ve channel binding: kimliği bağlamak

Extended Protection for Authentication (EPA) iki farklı 'bağlama' fikrini bir araya getirir. Service binding, istemcinin AUTHENTICATE mesajına hedef servisin SPN'ini (MsvAvTargetName, 0x0009) koymasıdır: 'ben şu servise kimlik doğruluyorum' der. Sunucu beklediği SPN ile geleni karşılaştırır; kimlik başka bir servise relay edilmişse SPN uyuşmaz.

Channel binding ise iç kimlik doğrulamayı dış güvenli kanala (TLS) bağlar. İstemci, TLS kanalının bir özetini (gss_channel_bindings_struct'ın MD5 hash'i) MsvAvChannelBindings (0x000A) alanına koyar. Hedef, gelen kimlik doğrulamanın kendi TLS kanalına ait özeti taşıdığını doğrular. Saldırgan kimliği kendi TLS kanalı üzerinden relay ederse, özet hedefin kanalına uymaz ve reddedilir.

Bu ikisi birlikte reflection ve relay'in tam da 'kimliği bir kanaldan alıp başka kanala taşıma' mekaniğini hedefler: MIC bayrakların düşürülmesini, service binding yanlış hedefi, channel binding yanlış kanalı yakalar. EPA'nın gücü, bu bağların hedef tarafından zorunlu kılınmasına bağlıdır.

LDAP: bağlantı bütünlüğü ve channel binding

Port numarası bağlantıdaki bütün korumaları söylemez. Düz LDAP genellikle 389 kullanır; LDAPS 636’da TLS ile başlar, StartTLS ise 389’daki LDAP bağlantısını TLS’e yükseltir. Sonuç çıkarmadan önce gerçek taşıma ve müzakere edilen korumayı incele.

Require signing, TLS olmayan unsigned SASL bağlantısını reddeder. Signed SASL mesaj bütünlüğünü korur; kurulmuş TLS bağlantısı da LDAP bağlantı bütünlüğü koşulunu karşılar. TLS koruması ile doğrulanmış CBT ayrı özelliklerdir: şifreleme, iç kimlik doğrulamayı kendiliğinden o kanala bağlamaz.

CBT policy’si sonucu değiştirir. Never bunu zorlamaz. When Supported, CBT üretemeyen eski istemciye izin verir; destekleyen istemcinin CBT göndermemesini veya geçersiz token’ı reddeder. Always her istemciden geçerli CBT ister. Sahne bu durumları kurulmuş TLS üzerinde karşılaştırır; Windows varsayılanı, certificate doğrulaması veya sunucunun gerçek kontrol sırası iddiası taşımaz.

Relay neden kırılır: oturum anahtarı, MIC ve channel binding

NTLM relay'in mekaniği şudur: saldırgan, kurbanın kimlik doğrulama mesajlarını hedefe iletir ve hedefle kurulan oturumu ele geçirir. Bunun çalışması için hedefin, iletilen kimliği koşulsuz kabul etmesi gerekir. Üç koruma bu koşulsuzluğu bozar.

Birincisi zorunlu signing: hedef imzalı mesaj isterse, sonraki mesajları imzalamak için müzakere edilmiş oturum anahtarı gerekir. Relay eden taraf, kurbanın kimlik materyaline (NTLMv2 response üzerinden türetilen anahtar malzemesine) sahip olmadığı için bu oturum anahtarına genel olarak erişemez ve geçerli imza üretemez — el sıkışmayı iletse bile imzalı oturumu sürdüremez. Müzakere edilen bir varyantta oturum anahtarı KEY_EXCH ile taşınan EncryptedRandomSessionKey içinde KeyExchangeKey altında şifrelenir; bu yolda da relay eden taraf KeyExchangeKey'i türetemediği için anahtarı çözemez. Genel engel şu tek yola bağlı değildir: signing zorunluysa relay eden taraf uygun oturum anahtarından yoksundur.

İkincisi MIC: müzakerede bir MIC mevcut ve doğrulanıyorsa, AUTHENTICATE içindeki MIC üç mesajı birden korur ve relay eden taraf 'signing iste' bayrağını kaldırarak korumayı düşürmeye çalışırsa MIC doğrulaması tutmaz. MIC her oturumda mevcut/zorunlu olmayabilir; olduğunda müzakere bütünlüğünü bağlar. Üçüncüsü channel binding: kimlik relay eden tarafın TLS kanalından geldiği için hedefin kanal özetiyle uyuşmaz. Bu üçünün ortak noktası, relay'i 'imkânsız' değil, hedefin zorunlu kıldığı koşullar altında 'geçersiz' kılmalarıdır.

Zorunlu koruma ile müzakere edilen koruma farkı

Bir korumanın var olması ile zorunlu olması aynı şey değildir. NTLM signing pek çok oturumda müzakere edilir (NEGOTIATE_SIGN bayrağı görünür), ama hedef bunu zorunlu kılmıyorsa saldırgan bayrağı düşürüp korumasız bir oturum kurmaya çalışabilir. Relay'i kıran, korumanın müzakere edilebilir olması değil, hedefin onu şart koşmasıdır.

Savunmada, müzakere edilen özellik ile hedefin zorunlu kıldığı policy’yi ayrı oku. LDAPServerIntegrity, LdapEnforceChannelBinding ve SMB SigningRequired farklı koşulları denetler. 2886 signing posture’ını; 2887 izin verilmiş unsigned/cleartext bind’lerin 24 saatlik özetini; 2888 ise signing zorunluyken reddedilmiş girişimlerin özetini bildirir. 2889 istemci düzeyindeki girişim ayrıntısıdır; tek başına enforcement durumunu söylemez.

2889, istemcinin port 389 üzerinde unsigned SASL veya cleartext simple-bind girişimini IP, attempted identity ve bind type ile gösterir. Bind’in kabul edildiğini, authentication başarısını veya signing’in zorunlu olmadığını bu kayıttan çıkaramazsın. 3039 ise uygun policy/logging koşullarında LDAP over SSL/TLS CBT doğrulama başarısızlığını bildirir. Bu iki gözlem farklı dallara aittir; policy ve bağlantı sonucu ayrıca incelenir.

Durum ve veri akışı

1. WS01, DC01 üzerindeki LDAP hizmetine SASL-NTLM ile bağlanır. NEGOTIATE istemciden sunucuya gider; signing, sealing ve KEY_EXCH ayrı müzakere özellikleridir.
2. DC01 CHALLENGE yanıtını WS01’e gönderir. Bu örnekte LDAP hedefi ve domain hesabının doğrulama otoritesi aynı DC üzerindedir; üçüncü bir ağ alıcısı yoktur.
3. WS01 AUTHENTICATE mesajını DC01’e gönderir. KEY_EXCH ve MIC koşulludur. TLS kullanıldığında CBT’nin gönderilmesi istemci desteğine bağlıdır; kanal eşleşmesi ayrıca denetlenir.
4. DC01 hesap doğrulamasını yerel güvenlik otoritesiyle değerlendirir. Sahnedeki başarılı/başarısız seçim bir örnek sonucudur; secret veya hesap parolası ağda ek bir mesaja dönüşmez.
5. Bağlantı bütünlüğünü ayrı incele: TLS olmayan unsigned SASL, Require signing koşulunu geçmez. Signed SASL veya kurulmuş TLS bu bütünlük koşulunu karşılar; CBT denetiminin yerine geçmez.
6. TLS yolunda Never CBT istemez. When Supported, desteklemeyen eski istemcide eksik CBT’ye izin verir; destekleyen istemcide eksik veya uyuşmayan CBT’yi reddeder. Always eksik CBT’yi her istemcide reddeder. Bind kabulü sonraki directory işleminin yetkisi değildir.
7. İlgili diagnostic level 2 etkinse unsigned girişim 2889, CBT doğrulama hatası 3039 ile görünür. 2889 kabulü kanıtlamaz; 2887/2888 24 saatlik özetlerdir ve tek denemeden hesaplanmaz.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım: 'NTLM kimlik doğrulamasını yakalayıp başka bir hedefe relay edebilirim; hedef kimliği kabul eder ve oturumu ele geçiririm.' Bu, hedefin hiçbir bütünlük/bağlama koruması zorunlu kılmadığı özel durumda doğrudur. Zorunlu signing devredeyse relay eden taraf, korumalı takip mesajlarını üretmek için gereken müzakere edilmiş oturum anahtarına sahip olmadığı için mesajları imzalayamaz (müzakere edilen bir varyantta bu anahtar KEY_EXCH ile EncryptedRandomSessionKey içinde KeyExchangeKey altında taşınır ve yine türetilemez); müzakerede mevcut ve doğrulanan bir MIC, signing bayrağını düşürmeyi engeller; channel binding/EPA, relay edilen kimliği yanlış TLS kanalına bağlı bulup reddeder. Aynı yanılgı savunma tarafında da vardır: 'LDAPS/TLS açtım, relay biter' — TLS transport'u şifreler ama iç kimliği kanala bağlamaz; LDAPS üzerinde relay'i kıran channel binding'dir, signing değil.

Technical prerequisites

• Hedefin bütünlük korumasını zorunlu kılmaması: LDAP'ta LDAPServerIntegrity=1 (signing gerekmez) veya SMB'de imzalamanın zorunlu olmaması — aksi halde relay edilen oturum geçerli imza üretemez.
• TLS üzerinde relay'in sürmesi için hedef bu istemciden eşleşen CBT istememelidir: LdapEnforceChannelBinding=0 (Never) bunu istemez; When Supported (1) CBT gönderebilen istemcilerde doğrular; Always (2) her istemciden CBT ister. Uygun policy enforcement edilirse farklı TLS kanallarından taşınan kimlik reddedilir.
• İstemci tarafının signing'i zorunlu kılmaması veya saldırganın NEGOTIATE bayraklarını düşürebileceği bir yol bulması; müzakerede mevcut ve doğrulanan bir MIC varsa bu düşürme tespit edilir.
• Kimlik doğrulamanın saldırganın araya girebileceği bir yol üzerinden (ör. zorlanmış kimlik doğrulama, ad çözümleme yönlendirmesi) hedefe akıtılabilmesi — bu dersin kapsamı tetikleyici değil, relay'in kabul koşuludur.

Exploitation mechanism / İstismar mekanizması

Bu katman bir tek CVE değil, relay'in neden koşullu bir saldırı olduğunu açıklar. Relay, iletilen kimliğin hedefçe koşulsuz kabul edilmesine dayanır. Zorunlu signing bu koşulsuzluğu bozar: hedef imzalı takip mesajları istediğinde bunları üretmek için müzakere edilmiş oturum anahtarı gerekir ve relay eden taraf, kurbanın NTLMv2 kimlik materyaline sahip olmadığı için bu anahtardan genel olarak yoksundur. Müzakere edilen bir varyantta dışa aktarılan oturum anahtarı KEY_EXCH ile KeyExchangeKey altında şifrelenip EncryptedRandomSessionKey olarak taşınır; bu yolda da KeyExchangeKey türetilemediğinden anahtar çözülemez. Genel engel bu tek yola indirgenemez — signing zorunluysa relay eden taraf uygun oturum anahtarından yoksundur. Müzakerede mevcut ve doğrulanan bir MIC, NEGOTIATE+CHALLENGE+AUTHENTICATE üçlüsünü bağladığı için 'signing iste' bayrağını sonradan kaldırma girişimi doğrulamayı bozar (MIC her oturumda mevcut/zorunlu olmayabilir). Channel binding (MsvAvChannelBindings) ve service binding (MsvAvTargetName), iç kimliği sırasıyla dış TLS kanalına ve hedef SPN'ine bağlar; relay edilen kimlik yanlış kanal/hedef taşıdığından reddedilir. Saldırının fiili kaldıracı bu yüzden 'relay'in evrensel gücü' değil, hedefin bu korumaları zorunlu kılıp kılmadığıdır — ve en sık açık, LDAPS üzerinde signing'in atlanıp channel binding'in de zorlanmamasıdır.

Relay'in koşulu: hedef korumayı zorunlu kılmıyorsa

Relay'i 'her zaman çalışan' bir teknik gibi düşünmek yanlıştır. Relay yalnızca hedef, iletilen kimliği ek bir bağ/imza şartı koymadan kabul ettiğinde tutar. Hedef zorunlu signing istiyorsa, saldırgan el sıkışmayı iletebilir ama oturum anahtarına sahip olmadığı için sonraki imzalı mesajları üretemez; oturum kullanılamaz hâle gelir.

Bu yüzden saldırganın hedef seçimi aslında 'hangi hedef korumayı zorunlu kılmıyor' sorusudur: imzalamayı zorunlu kılmayan bir LDAP servisi, channel binding zorlamayan bir LDAPS ucu ya da imzasız SMB. Saldırının başarısı hedefin yapılandırmasına bağlıdır, saldırganın 'gücüne' değil.

MIC ve channel binding neyi bozar

Saldırganın klasik hamlesi, müzakereyi zayıflatıp korumayı 'düşürmektir': NEGOTIATE bayraklarından signing'i kaldırmak gibi. Müzakerede mevcut ve doğrulanan bir MIC tam da bunu engeller; AUTHENTICATE içindeki MIC üç mesajı birden kapsadığından, ilk mesajdaki bayrakların sonradan değiştirilmesi doğrulamayı bozar (MsvAvFlags 0x2 MIC'in varlığını işaretler). MIC her oturumda mevcut/zorunlu olmayabilir; bu koruma MIC'in üretilip doğrulandığı durumlar için geçerlidir ve tek başına her signing düşürmesini evrensel olarak önlemez.

Channel binding ise farklı bir eksene saldırır: kimliğin hangi TLS kanalından geldiğini bağlar. Saldırgan kurbanla kendi TLS kanalı, hedefle başka bir kanal kurduğu için, kurbanın ürettiği MsvAvChannelBindings özeti hedefin kanalına uymaz. Reflection (kimliği kaynağına geri yansıtma) ve cross-channel relay bu bağla reddedilir. Service binding (MsvAvTargetName) aynı fikri SPN düzeyinde uygular.

Sınır: her TLS relay'i durdurmaz

Yaygın bir yanlış, 'LDAPS/TLS zaten şifreliyor, o hâlde relay imkânsız' demektir. TLS trafiği şifreler ve sunucu kimliğini doğrular, ama iç NTLM kimlik doğrulamasının hangi kanala ait olduğunu kendiliğinden bağlamaz. Channel binding zorlanmıyorsa, saldırgan kurbanı kendi TLS kanalına çekip kimliğini hedefin TLS kanalı üzerinden relay edebilir.

Dolayısıyla bu katmanın çıktısı bir exploit reçetesi değil, bir koşul haritasıdır: relay 'hedef signing/channel binding'i zorunlu kılmıyorsa' mümkündür. Savunmanın işi bu koşulları ortadan kaldırmaktır; saldırının işi ise bu koşulların hâlâ açık olduğu hedefleri bulmaktır. Tetikleme teknikleri (kimlik zorlama) bu dersin kapsamı dışındadır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• 2889, istemci düzeyinde unsigned SASL veya cleartext simple-bind girişimini IP, attempted identity ve bind type ile raporlar. “16 LDAP Interface Events” level 2 gerekir. Bind kabulünü veya policy’nin enforcement durumunu bu olaydan çıkarma; 2886/policy, 2887 ve 2888’i ayrı bağlamla oku.
• AD DS Directory Service log (3039/3040/3041): 3039 kaydı When Supported veya Always policy altında CBT doğrulamasındaki belirli hataları gösterir (minimum logging level 2); bu bir 'enforcement öncesi etkilenecekler' listesi değildir. 3040/3041, policy Never iken son 24 saatlik CBT’siz bind sayımı ve posture uyarısıdır; istemci ayrıntısı sağlamaz.
• Posture kayıtları (2886/2887): 2886 sunucunun signing'i zorunlu kılmadığını (LDAPServerIntegrity=1) bir güvenlik uyarısı olarak; 2887 son 24 saatteki imzasız/cleartext bind sayısının özetini bildirir. Bunlar 'koruma var mı' değil 'koruma zorunlu mu' sorusunu yanıtlar.
• SMB tarafında imzalamanın (MS-SMB2 SigningRequired) sunucu ve istemci politikalarıyla zorunlu kılınıp kılınmadığı ayrı bir eksendir; imzasız SMB, LDAP'takine paralel bir relay yüzeyidir ve ilgili GPO ayarlarıyla ölçülmelidir.
• Tek bir 2889 veya 3039 kaydı 'saldırı' demek değildir; bunlar yapılandırma göstergeleridir. Değerlendirme, hangi istemcilerin kalıcı olarak imzasız/CBT'siz bağlandığını ve bunların meşru eski uygulamalar mı yoksa beklenmedik kaynaklar mı olduğunu bağlamla ayırt etmeyi gerektirir.

Events and relevant fields

• 2889: unsigned/cleartext LDAP bind girişiminde istemci IP’si, attempted identity ve Binding Type. Diagnostic level 2 gerekir; kabul/başarı veya saldırı kanıtı değildir.
• 3039 (AD DS · Directory Service): When Supported veya Always policy altında malformed CBT, When Supported altında CBT destekleyen istemcinin CBT göndermemesi ya da Always altında istemcinin CBT göndermemesi nedeniyle LDAP-over-SSL/TLS channel binding doğrulamasının başarısız olduğunu gösterir; minimum logging level 2. Bağlantı reddedilse de event yazılabilir.
• 2886 (AD DS · Directory Service): dizin sunucusunun LDAP signing'i zorunlu kılmadığını (LDAPServerIntegrity=1) bildiren güvenlik posture uyarısı.
• 2887 (AD DS · Directory Service): son 24 saat içinde gerçekleşen imzasız/cleartext bind sayısının özet kaydı (istemci ayrıntısı olmadan sayım).
• 3040 (AD DS · Directory Service): son 24 saat içinde channel binding token doğrulaması yapılmadan gerçekleşen bind'lerin özet sayımı.
• AD DS Diagnostics · '16 LDAP Interface Events' = 2: 2889/3039 gibi istemci düzeyi kayıtların üretilmesi için gereken teşhis seviyesi; varsayılan seviyede bu ayrıntı üretilmez, dolayısıyla 'kayıt yok' güvenlik değil, telemetri eksikliği olabilir.
• 2888: signing zorunlu sunucuda reddedilen unsigned SASL/cleartext simple-bind girişimlerinin 24 saatlik özeti; istemci ayrıntısı değildir.

Hangi kayıt neyi söyler

AD DS'te relay yüzeyini okumanın ilk adımı üç kayıt ailesini ayırmaktır: 2886/2887 sunucunun signing'i zorunlu kılıp kılmadığını (posture), 2889 hangi istemcilerin fiilen imzasız bağlandığını (IP + kimlik), 3039 ise LDAP-over-SSL/TLS channel binding doğrulamasının hangi bağlantıda başarısız olduğunu söyler. 3040/3041 ise politika Never iken 24 saatlik posture bilgisidir. Bu ayrım, 'kapı açık mı, kimler geçiyor, hangi CBT doğrulaması başarısız' sorularını birbirine karıştırmamayı sağlar.

İkinci adım teşhis seviyesini doğrulamaktır: 2889/3039 yalnızca '16 LDAP Interface Events'=2 iken üretilir. Bu ayar kapalıysa 'hiç kayıt yok' güvenli olduğunuz anlamına gelmez; sadece görmediğiniz anlamına gelir. Telemetri eksikliğini güvenlikle karıştırmamak gerekir.

Olay   Anlam
2886   Signing zorunlu değil (posture)
2887   İzin verilmiş unsigned/cleartext bind; 24 saatlik özet
2888   Reddedilmiş unsigned/cleartext girişim; 24 saatlik özet
2889   Unsigned/cleartext girişim; kabulü kanıtlamaz
3039   İlgili policy/logging koşulunda CBT doğrulama hatası
3040   CBT doğrulanmadan gerçekleşen bind; toplu özet

Zorunlu mu, yoksa yalnızca mevcut mu

Relay savunmasında belirleyici soru 'koruma zorunlu mu' sorusudur. Bir oturumda NEGOTIATE_SIGN bayrağının görünmesi, hedefin imzayı şart koştuğu anlamına gelmez; hedef zorunlu kılmıyorsa saldırgan korumayı düşürmeye çalışabilir. Bu yüzden 2886 (signing zorunlu değil) uyarısı, tek bir imzasız bind'den daha stratejik bir sinyaldir.

Aynı mantık LDAPS için de geçerlidir: TLS'in varlığı channel binding'in zorunlu olduğunu göstermez. 3039, When Supported/Always policy altında başarısız CBT doğrulamasını kaydeder; bu, enforcement öncesi uyumluluk listesi değildir. Policy Never iken 3040 son 24 saatin CBT’siz bind sayısını, 3041 ise posture uyarısını verir; bu ikisi de istemci düzeyinde etkilenecekler listesini sağlamaz. Uygun uyumluluk değerlendirmesinden sonra channel binding'i zorunlu kıl ve policy ile istemci sonucunu doğrula.

Detection logic · XPath

<!-- AD DS Directory Service belgesinde imzasiz bind (2889) veya channel binding (3039) kayitlarini secer. -->
<!-- Tek bir Event XML belgesi uzerinde secim yapar; korelasyon/temel cizgi yoktur. -->
<!-- Bu kayitlar yapilandirma gostergesidir; tek basina saldiri kaniti degildir. -->
<!-- Uretim icin '16 LDAP Interface Events'=2 gerekir; aksi halde kayit hic olusmaz. -->
//*[local-name()='Event']
  [*[local-name()='System']/*[local-name()='Provider'][@Name='Microsoft-Windows-ActiveDirectory_DomainService']]
  [*[local-name()='System']/*[local-name()='EventID']='2889'
     or *[local-name()='System']/*[local-name()='EventID']='3039']

Query assumptions

• XPath yalnızca verilen tek Event XML belgesi üzerinde seçim yapar; birden çok DC, oturum veya zaman penceresi arasında korelasyon kurmaz.
• 2889/3039 kayıtlarının üretilmesi '16 LDAP Interface Events' teşhis seviyesi 2'ye bağlıdır; bu ayar kapalıysa kayıt hiç oluşmaz ve 'temiz' görünüm yanıltıcı olur.
• Bu ifade bu oturumda yalnızca örnek Event XML belgeleri üzerinde değerlendirildi; canlı bir sistemde çalıştırılmadı ve bir temel çizgiyle kıyaslanmadı. 3039 örneğinin EventData alan düzeni Microsoft'ça yayımlanmadığından adsız Data ile modellendi (sentetik yeniden kurulum).

False positives

• İmzasız/cleartext bind (2889) çoğu zaman eski veya yanlış yapılandırılmış meşru uygulamalardan gelir (eski LDAP istemcileri, appliance'lar); bu bir yapılandırma borcudur, saldırı değil.
• Channel binding uyarısı (3039) CBT'yi desteklemeyen eski istemcilerden kaynaklanabilir; LdapEnforceChannelBinding'i 2'ye çekmeden önce bu istemciler envanterlenmelidir.
• Negatif örnek: bir istemci LDAPS üzerinden geçerli channel binding ve signing ile bağlanırsa bu kayıtları hiç üretmez; kaydın yokluğu her zaman güvenlik değil, bazen yalnızca teşhis seviyesinin kapalı olması olabilir.

Hardening

• Signing ile TLS channel binding’i ayrı planla. TLS olmayan bağlantılarda LDAP signing’i zorunlu kıl; TLS yolunda CBT uyumluluğunu ölçüp enforcement’ı kademeli test et. StartTLS de 389 kullandığı için yalnız port numarasına bakıp şifresiz bağlantı varsayma. İstemci sonucu ile etkin policy’yi ayrı doğrula.
• İmzasız LDAP bind’leri için 2889’u kullan. 3039’u When Supported/Always altındaki CBT doğrulama hatası olarak oku; enforcement öncesi etkilenecek istemcilerin listesi değildir. Never altında 3040/3041 yalnızca günlük sayım/posture verir. CBT’yi zorunlu kılmadan önce desteklenen audit yöntemleri ve kademeli testle istemci uyumluluğunu ölç.
• İstemci tarafında LDAP signing’i teşvik/zorunlu kıl; fakat sunucudaki Require Signing politikasını ayrıca uygula. Mevcut ve doğrulanan MIC yalnız bulunduğu müzakeredeki mesaj değişikliğini yakalar; her oturumda bulunduğu varsayılmaz.
• SMB imzalamayı sunucu ve istemci tarafında zorunlu kıl (SigningRequired); imzasız SMB, LDAP'takine paralel bir relay yüzeyi bırakır. Bu, MS-SMB2 signing politikalarıyla yönetilir.
• Veri gizliliği gerekiyorsa sealing/TLS kullan; TLS üzerinden NTLM relay’i azaltmak için desteklenen yerde channel binding’i enforcement et. LDAP signing, sealing/TLS ve channel binding farklı kontrollerdir; biri diğerinin yerine geçmez.
• Doğrulama adımı: LDAPServerIntegrity=2 ile imzasız SASL bind reddedilmeli. LdapEnforceChannelBinding=2 altında CBT’siz/uygunsuz LDAPS bind reddedilebilir ve minimum logging level 2 etkinse 3039 kaydı oluşabilir. Başarıyı hem policy hem istemci sonucu üzerinden doğrula; 3039’un görünmesi enforcement’ın başarısız olduğu anlamına gelmez.

Örnekler üzerinde oku / Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-ActiveDirectory_DomainService"/><EventID>2889</EventID><Level>4</Level><Channel>Directory Service</Channel><Computer>DC01.outreason.example</Computer></System><EventData><Data>198.51.100.44:51873</Data><Data>CN=svc-reporting,OU=Service Accounts,DC=outreason,DC=example</Data><Data>0</Data></EventData></Event>

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-ActiveDirectory_DomainService"/><EventID>3039</EventID><Channel>Directory Service</Channel><Computer>DC01.outreason.example</Computer></System></Event>

İki yanlış kanı / Two reality checks

Sanılan: İmzalamak (signing) ile şifrelemek (sealing) aynı şeydir; imzaladıysam trafiğim de gizlidir.

Gerçekte: Hayır. Signing (NTLMSSP_NEGOTIATE_SIGN) yalnızca bütünlük sağlar: mesaj kurcalanamaz ama içeriği ağda okunabilir. Sealing (NTLMSSP_NEGOTIATE_SEAL) ise gizlilik sağlar (şifreleme). Windows'ta sealing signing'i içerir ama tersi doğru değildir; bir oturum imzalı olup şifresiz olabilir. Relay bağlamında kritik ayrım da budur: relay'i kıran çoğu zaman gizlilik değil, hedefin zorunlu kıldığı bütünlüktür (signing). Saldırgan oturum anahtarını bilmediği için geçerli imza üretemez — içerik şifreli olmasa bile relay tutmaz. 'İmzaladım' ile 'şifreledim' bu yüzden ayrı cümlelerdir.

Sanılan: LDAPS/TLS kullanmak tek başına NTLM relay'ini durdurur.

Gerçekte: TLS taşıma katmanını korur ama tek başına NTLM kimlik doğrulamasını o kanala bağlamaz. Bu bağı seçili policy altında CBT doğrulaması kurar. When Supported, CBT desteklemeyen istemcilere istisna tanır; Always her istemciden geçerli CBT ister. Signing, TLS, hesap doğrulaması ve kaynak yetkisi ayrı kontrollerdir.

Kaynaklar / Sources

• Microsoft · LDAP channel binding and LDAP signing requirements (KB4520412)
  LDAPServerIntegrity (1/2) ve LdapEnforceChannelBinding (0/1/2) registry değerleri; channel binding olayları 3039/3040/3041 ve imzasız bind için 2889.
• Microsoft · How to enable LDAP signing (KB935834 · 16 LDAP Interface Events)
  '16 LDAP Interface Events' teşhis seviyesi 2; posture olayları 2886/2887 ve istemci düzeyi 2889; LDAP server/client signing requirements politikaları.
• Microsoft Open Specifications · [MS-NLMP] NT LAN Manager (NTLM) Authentication Protocol
  §2.2.2.5 Negotiate flags (SIGN/SEAL/KEY_EXCH); §2.2.2.1 AV_PAIR (MsvAvTargetName 0x0009, MsvAvChannelBindings 0x000A, MsvAvFlags 0x0006/MIC biti); MIC ve EncryptedRandomSessionKey.
• Microsoft Security Advisory 973811 · Extended Protection for Authentication (EPA)
  Channel binding (dış TLS kanalına bağlama) ve service binding (SPN) kavramları; relay/reflection karşısında Extended Protection'ın amacı ve kapsamı.
• Microsoft Open Specifications · [MS-SMB2] Server Message Block (SMB) Protocol Versions 2 and 3 — signing
  SMB2 signing: SMB2_NEGOTIATE_SIGNING_REQUIRED/ENABLED; imzalamanın zorunlu kılınması ve relay yüzeyine paralel etkisi.
• Microsoft Learn · Supporting Extended Protection for Authentication (EPA) in a service
  Session-key signing/encryption and EPA/channel binding are distinct; audit-only EPA does not prevent relay.
• Windows Event manifest standard level values
  Predefined level values: Information4,Warning3