NTLM challenge-response: İstemci, sunucu ve DC arasındaki doğrulama.

1. Core Mechanism / Temel mekanizma

Karar, bir istemci parolasını doğrudan vermeden bir sunucuya kimliğini kanıtlamak istediğinde ortaya çıkar. Sunucu bir sır tutmadığı için doğrulama yetkisi, hesabın parolasından türeyen anahtarı bilen otoriteye aittir (domain hesapları için authoritative bir DC, yerel hesaplar için erişilen makinenin kendisi). Bu ders, o üç taraf arasındaki mesaj ve yetki dağılımını sabitler.

Arabirimler ve belirtimler

• Client (istemci): kullanıcının parolasından türeyen NT hash'e (NTOWFv2 için anahtar) sahiptir. Type 2 içindeki server challenge'ı alır, kendi client challenge'ını üretir ve NTProofStr'i hesaplayarak Type 3 içinde gönderir. Parolanın kendisi hiçbir mesajda gitmez.
• Hedef servis: domain hesabının yanıtını kendi yerel hesap verisiyle doğrulayamaz; doğrulama isteğini Netlogon üzerinden DC’ye iletir. Yerel hesap seçilmişse hedef bilgisayar hesabın otoritesidir ve kendi hesap verisini kullanır. SMB veya HTTP gibi üst protokol NTLM mesajlarını taşır.
• DC: domain hesabının doğrulama otoritesidir. Writable DC’ler kimlik materyalini replike eder. RODC, Password Replication Policy kapsamında cache edilmiş hesap için yerelde doğrulama yapabilir; materyal cache’te değilse writable DC’ye yönlendirir. Buradaki görsel RODC yönlendirmesini emüle etmez.
• Netlogon secure channel: sunucu ile DC arasındaki pass-through doğrulama yolu. Sunucu, NTLM kimlik bilgisini MS-APDS'in tanımladığı biçimde Netlogon (MS-NRPC) üzerinden DC'ye taşır; bu kanal sunucunun bilgisayar hesabıyla kurulur.
• MSV1_0: NTLM credential validation’da kullanılan authentication package. 4776’nın görünmesi ilgili Audit Credential Validation kapsamına bağlıdır; kaydın yokluğu tek başına işlemin yapılmadığını göstermez.

Hesabın otoritesi nerede?

Domain hesabının credential authority’si DC’dir; hedef üye sunucu değildir. Yerel hesapta ise hedef makinenin SAM’i kullanılır. “Domain hesabı yalnız writable DC’de doğrulanır” da eksik bir kuraldır: RODC, izin verilen ve önceden cache edilmiş credential ile WAN kesintisinde yerel doğrulama sağlayabilir. Cache olmayan hesap için erişilebilir writable DC gerekir.

Domain hesabında erişilen üye sunucu, gelen yanıtı kendi başına doğrulayamaz; yaptığı şey rastgele bir server challenge üretmek ve istemcinin bu challenge'a ürettiği yanıtı, kimlik materyalini tutan authoritative bir DC'ye kontrol ettirmektir. Bu durumda doğrulama kararını üye sunucu vermez; soruyu taşır ve DC'nin verdiği evet/hayır cevabına uyar. Yerel hesapta ise tablo değişir: erişilen makine hesabın authoritative otoritesidir ve doğrulamayı pass-through olmadan yerelde kendisi yapar.

Bu ayrım, dersin geri kalanının temelidir. Challenge-response sırrın bilindiğini doğrular; ancak bu, oturumu her taşıma protokolünde belirli hedefe/kanala bağlayan bir kontrol değildir. Relay'e karşı ek savunma hedef protokole göre değişir: SMB signing negotiated session key ile oturum trafiğini korur; LDAP signing mesaj bütünlüğü sağlar; desteklenen TLS servislerinde EPA/channel binding kimlik doğrulamayı hedefe veya TLS kanalına bağlar.

Üç mesaj: NEGOTIATE, CHALLENGE, AUTHENTICATE

NTLM alışverişi üç mesajdan oluşur ve hepsi 'NTLMSSP\0' imzasıyla başlar. İlk mesaj NEGOTIATE_MESSAGE'dır (Type 1, MessageType 0x00000001): istemci desteklediği yetenekleri (negotiate flags) sunucuya bildirir. Bu mesaj henüz kimlik içermez.

İkinci mesaj CHALLENGE_MESSAGE'dır (Type 2, 0x00000002). Sunucu burada 8 baytlık ServerChallenge alanını ve TargetInfo (AV_PAIR'ler; sunucu/domain adları, zaman damgası gibi) üretir. Bu challenge, istemcinin yanıtı hesaplarken kullanacağı rastgele değerdir; her oturum için farklıdır.

AUTHENTICATE_MESSAGE (Type 3) response ve hesap bilgilerini taşır. EncryptedRandomSessionKey her alışverişte dolu bir payload değildir: ilgili KEY_EXCH ve sign/seal pazarlığı koşullarında taşınabilir; key-exchange flag’i yoksa uzunluk alanları sıfırdır. Domain hesabında hedef servis response’u DC’ye doğrulatır; yerel hesapta doğrulama hedefte yapılır.

Doğrulamanın DC'de tamamlanması (pass-through)

Domain hesabında sunucu, Type 3'teki challenge/response çiftini kendisi kontrol edemez çünkü NT hash'e sahip değildir. MS-APDS'in tanımladığı akışta sunucu, istemcinin gönderdiği kimlik doğrulama materyalini Netlogon (MS-NRPC) secure channel'ı üzerinden DC'ye iletir. Bu, 'pass-through authentication' olarak adlandırılır.

DC, hesabın materyaliyle response’u doğrular ve sonucu hedef servise döner. Audit Credential Validation uygun kapsamda açıksa burada 4776 görülebilir. Kaydın Status alanındaki 0x0 başarıdır; nonzero bir sonuç başarısız doğrulamayı gösterir.

Bu mimarinin sonucu, tek bir NTLM oturum açmanın iki farklı makinede iz bırakabilmesidir: kaynak sunucuda oturumun kurulduğunu gösteren 4624 ve DC'de kredinin doğrulandığını gösteren 4776. Blue tarafı bu ikisini birlikte okumadan resmi tamamlayamaz.

Temel challenge-response tek başına hedef/kanal bağı vermez

Server challenge, yanıtı üretmek için sırrı zorunlu kılar; bu yönüyle kimlik bilgisini korur. Ancak temel NTLM challenge-response, tek başına yanıtı taşındığı belirli TCP bağlantısına veya üst protokole (SMB oturumu, TLS kanalı, LDAP bağlantısı) relay'e dayanacak ölçüde bağlamaz. Yani ek koruma yoksa, 'doğru yanıt' üretmiş olmak yanıtın 'bu bağlantıya ait' olduğunu tek başına kanıtlamaz.

Hedef protokole göre farklı ek kontroller bu boşluğu kapatır: zorunlu SMB signing, negotiated key ile oturum mesajlarının bütünlüğünü korur; LDAP signing, LDAP mesajlarını imzalar; desteklenen TLS servislerinde EPA/channel binding kimlik doğrulamayı TLS kanalına veya hedef servise bağlar. Bunların varsayılanları ve enforcement seçenekleri Windows sürümü ile servis desteğine göre değişir. Bu derste yalnızca relay riskinin kökünü sabitliyoruz; uygulama ayrıntıları sonraki derslerde ele alınır.

Bu tek cümlelik gözlem, hem Red tarafındaki relay saldırısının hem de Blue tarafındaki 4776 'Source Workstation' alanının neden yanıltıcı olabildiğinin ortak köküdür.

Durum ve veri akışı

1. İstemci sunucuya bir NEGOTIATE_MESSAGE (Type 1) gönderir ve desteklediği yetenekleri bildirir.
2. Sunucu 8 baytlık server challenge ve TargetInfo içeren bir CHALLENGE_MESSAGE (Type 2) üretip döner.
3. İstemci, kullanıcının NT hash'inden NTOWFv2 anahtarını türetir ve kendi client challenge'ını üretir.
4. İstemci, server challenge ile client challenge yapısını birleştirip NTProofStr'i hesaplar.
5. İstemci NtChallengeResponse, kullanıcı/domain/workstation adlarını içeren AUTHENTICATE_MESSAGE (Type 3) gönderir.
6. Domain hesabında FS01 doğrulama isteğini Netlogon yoluyla DC01’e iletir. Yerel hesapta FS01 kendi hesap verisini kullanır; DC’ye aktarım yoktur.
7. Hesabın otoritesi response’u değerlendirir. Kabul ve ret örneklerini karşılaştır; ilgili audit açıksa bu noktada 4776 görülebilir.
8. Hedef servis sonucu alır ve kabul durumunda security context kurar. İlgili audit ile 4624/4625 görülebilir. Ardından kaynak isteğini ayrı değerlendir: bu örnekte READ var, WRITE yok.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: 'İstemci doğru NTLM yanıtını ürettiyse, o yanıt yalnızca istemcinin bağlanmak istediği sunucuya karşı geçerlidir.' Gerçekte temel challenge/response tek başına belirli bir hedefe veya kanala bağlanmaz; hedef protokolünde session signing zorunlu değilse ya da desteklenen service/target/channel binding (EPA) enforce edilmiyorsa, aradaki bir taraf aynı çifti başka bir sunucuya taşıyıp o sunucuda kimlik doğrulayabilir.

Technical prerequisites

• Saldırganın, kurbanı kendi kontrolündeki bir uç noktaya NTLM ile kimlik doğrulamaya yönlendirebilmesi gerekir (ör. tetiklenen bir SMB/HTTP bağlantısı). Bu, ağ üzerinde araya girebilecek veya zorlama tetikleyebilecek bir konum ister.
• Hedefin kullandığı protokolde relay’i engelleyen session signing zorunlu olmamalı; TLS kullanan servislerde mevcutsa uygun EPA/channel-binding denetimi de enforcement edilmemelidir. Korumanın türü protokole ve servise bağlıdır.
• Kurbanın hesabının, saldırganın relay ettiği hedef serviste anlamlı bir yetkisi olmalıdır; aksi halde başarılı relay bile işe yaramaz.
• SPN’in bulunması tek başına Kerberos kullanımını zorlamaz. Uygun target identity ve ticket yolu, uygulamanın paket seçimi ve policy birlikte değerlendirilir; gerçekten Kerberos’a zorlanan bir yol NTLM akışını oluşturmayabilir.

Exploitation mechanism / İstismar mekanizması

Relay, NTLM'in üç taraflı doğasını kötüye kullanır: saldırgan, sunucunun oynadığı 'challenge taşıyıcı' rolüne aradan girer. Kurbandan gelen NEGOTIATE'i hedef sunucuya iletir, hedefin ürettiği CHALLENGE'ı kurbana geri verir, kurbanın hesapladığı AUTHENTICATE'i tekrar hedefe iletir. Kurban sırrı bilir ve doğru yanıtı üretir; ama bu yanıt tek başına kanala bağlı olmadığından ve hedef protokolünde session signing zorunlu tutulmadığından veya desteklenen EPA/channel-binding denetimi enforce edilmediğinden, hedef sunucu oturumu saldırganın bağlantısında açar. Böylece saldırgan hiçbir parola veya hash kırmadan, kurbanın kimliğiyle hedefte iş yapar.

Challenge doğruluğu ile hedef bağlılığı farkı

Relay'in çalışması, kriptografinin kırılmasına değil, doğrulanan şeyin kapsamına dayanır. NTProofStr, sırrı bilmeden üretilemez; bu yönüyle güçlüdür. Ama NTProofStr, protokolün belirlediği challenge girdilerine verilen yanıtı doğrular; tek başına her taşıma protokolünde oturumu aynı TCP bağlantısına bağlayan bir kontrol değildir.

Saldırgan bu yüzden hiçbir zaman yanıtı değiştirmez veya çözmez; olduğu gibi taşır. İş, mesajların hangi bağlantıya ait olduğunun garanti edilmemesinden çıkar. Bu, 'MITM ile şifre çözme' değil, 'geçerli bir kimlik kanıtının yanlış bağlama yerleştirilmesi'dir.

Neden pass-through mimarisi relay'i görünmez kılar

Hedef sunucu, gelen response'u zaten kendisi doğrulamıyor; DC'ye pass-through yapıyor. DC ise yalnızca 'bu kullanıcı, bu challenge'a doğru yanıt verdi mi' sorusuna bakar; yanıtın hangi fiziksel bağlantıdan geldiğini bilmez ve doğrular. Kanalı koruma yöntemi hedef protokole göre değişir: örneğin zorunlu SMB signing oturum trafiğinin bütünlüğünü negotiated key ile korur; desteklenen TLS servislerinde EPA/channel binding kimlik doğrulamayı hedefe veya TLS kanalına bağlar.

Bu nedenle relay, doğrulama kanıtının hedef hizmete bağlanmadığı durumlarda mümkün olur. Savunma protokolüne uygun kontrolü gerektirir: SMB'de signing, TLS kullanan uygun servislerde EPA/channel binding; bu kontroller aynı şey değildir ve her hizmette bulunmaz.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• 4776 ilgili audit kapsamı açıksa credential authority’de görülür: domain hesabında DC, yerel hesapta hedef bilgisayar. Hedef makine yerel hesabın otoritesiyse burada 4776 beklenebilir.
• Başarılı network logon hedefte 4624 ile görülebilir. Domain hesabında bu hedef, 4776’yı yazan DC’den ayrıdır; yerel hesapta iki gözlem aynı makinede olabilir.
• 4776 'Audit Credential Validation', 4624/4625 ise 'Audit Logon' alt kategorisindedir; ikisi ayrı ayrı etkinleştirilir. Biri açık diğeri kapalıysa korelasyon resmi eksik kalır.
• 4776’nın Workstation alanı authentication kaynağını bildirir; domain hesabında kayıt DC’de üretilir. Alanı pass-through doğrulamayı DC’ye ileten member server veya erişilen hedef olarak yorumlama; hedef oturumunu 4624 ile ayrıca incele.

Events and relevant fields

• 4776 / PackageName: doğrulamayı yapan authentication package; domain NTLM için her zaman MICROSOFT_AUTHENTICATION_PACKAGE_V1_0'dır. Bu, olayın MSV1_0 tarafından üretildiğini gösterir.
• 4776 / TargetUserName: credential validation denemesinde değerlendirilen hesap (Logon Account). Başarı/başarısızlık Status ile birlikte okunur; bu hesap adı hedef resource erişimini kanıtlamaz.
• 4776 / Workstation: Source Workstation, yani logon denemesinin kaynağı. Microsoft’un CLIENT-1 → SERVER-1 örneğinde bu alan CLIENT-1’dir; SERVER-1 hedefi bu event’te bulunmaz. Ad tek başına relay veya makine kimliğinin güvenilir doğrulaması değildir.
• 4776 / Status: sonuç kodu ('Error Code'). 0x0 başarıyı, sıfırdan farklı değerler başarısızlık nedenini kodlar (ör. dokümantasyon örneğindeki 0xC0000234 hesabın kilitli olması).
• 4624 / LogonType: NTLM ağ oturumu için 3 (Network). LogonProcessName 'NtLmSsp' ve AuthenticationPackageName 'NTLM' ile birlikte NTLM ağ oturumunu işaret eder.

İki olayı birlikte okumak

En sık yapılan hata, NTLM erişimini tek bir olayda aramaktır. Oysa credential validation (4776) ile oturumun açıldığı yer (4624) farklı makinelerdedir. DC'de 4776 görüp kaynak sunucuda 4624 görmemek ya da tersi, çoğu zaman toplama boşluğudur, saldırı değil.

Doğru okuma, aynı kullanıcı ve yakın zaman penceresinde iki olayı eşleştirip kaynak/hedef adlarının tutarlılığını sorgulamaktır. Bu, hem meşru çok atlamalı erişimi anlamayı hem de anormal desenleri ayırmayı sağlar.

Neden 4776 hedefi göstermez

4776’nın Workstation alanı logon denemesinin authentication kaynağıdır; doğrulamayı DC’ye ileten member server’ı veya erişilen hedefi tek başına tanımlamaz. Microsoft’un CLIENT-1’den SERVER-1’e domain hesabıyla authentication örneğinde Workstation CLIENT-1 olur; SERVER-1 bilgisi 4776’da yer almaz.

Bu alanı “relay’in araya girdiği makine kesin burada görünür” diye de okuma. 4776’daki account/source, hedefteki 4624 ve ilgili network/service gözlemleri birlikte değerlendirilir; isim veya zaman eşleşmesi tek başına aynı exchange’i veya relay’i kanıtlamaz.

Detection logic · KQL

// NTLM erişiminin iki ayrı makinedeki izini eşleştirir: DC'de kredi doğrulama (4776)
// ile erişilen hedef (resource) sunucudaki NTLM ağ oturumu (4624, LogonType 3, NtLmSsp).
// SourceWorkstation (4776) ile WorkstationName (4624) farki sezgisel bir isarettir;
// tek basina saldiri/relay kaniti degildir, yalnizca korelasyonu gorunur kilar.
let cred = SecurityEvent
  | where EventID == 4776 and Status == "0x0"
  | project CredTime = TimeGenerated, TargetUserName, SourceWorkstation = Workstation, Status;
let logon = SecurityEvent
  | where EventID == 4624 and LogonType == 3 and LogonProcessName has "NtLmSsp"
  | project LogonTime = TimeGenerated, DestServer = Computer, TargetUserName, WorkstationName, IpAddress;
cred
| join kind=inner logon on TargetUserName
| where abs(datetime_diff('second', LogonTime, CredTime)) <= 10
| where SourceWorkstation != WorkstationName
| project CredTime, LogonTime, TargetUserName, SourceWorkstation, WorkstationName, DestServer, IpAddress, Status

Query assumptions

• Domain hesabı için DC’de 4776 toplamak Audit Credential Validation kapsamını, hedef resource server’da 4624 toplamak Audit Logon kapsamını gerektirir. Collector alan eşlemesi ve iki kaynağın toplama kapsamı ayrıca doğrulanmalıdır.
• SecurityEvent tablosu ve alan adları (EventID, TargetUserName, Workstation, Computer, LogonType, LogonProcessName, IpAddress) bu şemaya göre yazılmıştır; farklı toplama hattında alan adları değişebilir.
• TargetUserName üzerinden join yapılır; aynı kullanıcı için eşzamanlı çok sayıda oturum varsa 10 saniyelik pencere yanlış eşleştirmeler üretebilir.
• SourceWorkstation ile WorkstationName farkı normal senaryolarda da (isim çözümleme, çok adlı ana bilgisayarlar) oluşabilir; bu bir sinyaldir, karar değildir.
• 4776 tarafı Status=0x0 ile yalnız başarılı doğrulamayı seçer. Başarısız 4776 ayrı analiz edilir; isim/zaman eşleşmesi aynı authentication exchange’i kanıtlamaz.

False positives

• Meşru çok atlamalı erişim (bir sunucunun başka bir sunucuya kullanıcı adına NTLM ile erişmesi) kaynak ile workstation adının farklı görünmesine yol açabilir.
• İsim çözümleme ve NetBIOS/DNS farkları Workstation alanının beklenenden farklı yazılmasına neden olabilir; bu, gerçek bir relay olmadan eşitsizlik üretir.
• Yük dengeleyici, proxy veya VPN arkasındaki istemcilerde IpAddress ve workstation bilgileri gerçek kaynağı gizleyerek beklenmedik eşleşmeler doğurabilir.
• Zaman senkronizasyonu bozuk toplama hatlarında 10 saniyelik pencere meşru olayları kaçırabilir veya ilgisizleri birleştirebilir.

Hardening

• NTLM kullanımını önce görünür kıl: 'Restrict NTLM: Audit' politikalarıyla hangi sunucu ve hesapların NTLM'e bağımlı olduğunu ölç, sonra kademeli olarak engellemeye geç.
• Relay riskini protokole uygun signing/binding ile azalt: SMB’de session signing’i zorunlu kıl; LDAP’te signing ve channel binding’i uyumlu istemcilerle uygula. Zorunlu hale getirmeden önce ortamın Windows sürümüne göre SMB/LDAP varsayılanları ve istemci desteğini değerlendir.
• TLS kullanan ve Extended Protection for Authentication (EPA) destekleyen servislerde EPA’yı etkinleştirerek kimlik doğrulamayı hedefe/kanala bağla; yalnız audit mode enforcement yerine geçmez.
• 4776 (DC) ile 4624 (kaynak sunucu) toplamayı birlikte planla; korelasyon olmadan tek başına hiçbiri relay'i güvenilir gösteremez.
• Mümkün olan her yerde Kerberos'a yönlendir (doğru SPN, güncel DNS); NTLM'e düşen yolları envanterle ve azalt.
• Kritik sunucularda NTLM'i tümden engellemeden önce bağımlılıkları test ortamında doğrula; aksi halde meşru erişimler kesilir.

Örnekler üzerinde oku / Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4776</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>14336</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T07:41:12.503118600Z" />
    <EventRecordID>90714</EventRecordID>
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="PackageName">MICROSOFT_AUTHENTICATION_PACKAGE_V1_0</Data>
    <Data Name="TargetUserName">abdulvehhab</Data>
    <Data Name="Workstation">WKSTN-07</Data>
    <Data Name="Status">0x0</Data>
  </EventData>
</Event>

İki yanlış kanı / Two reality checks

Sanılan: NTLM ile bir sunucuya bağlanınca, parolam veya NT hash'im o sunucuya gider ve orada doğrulanır.

Gerçekte: Parola hiçbir mesajda gitmez; sunucu NT hash'i de bilmez. İstemci yalnızca server challenge'a sırrıyla ürettiği bir yanıtı (NTProofStr) gönderir. Domain hesabında sunucu bu yanıtı kendisi doğrulayamaz, Netlogon üzerinden DC'ye pass-through yapar; asıl doğrulama DC'de olur ve orada 4776 üretilir.

Sanılan: İstemci doğru yanıtı ürettiyse, o yanıt sadece bağlanmak istediği sunucuda geçerli olur.

Gerçekte: Temel NTLM challenge-response kendi başına her protokolde hedef/kanal bağı sağlamaz. Relay'e karşı kontrol protokole göre seçilir: SMB signing negotiated key ile oturum mesajlarını korur; LDAP signing mesaj bütünlüğünü sağlar; EPA/channel binding desteklenen TLS servislerinde kimlik doğrulamayı hedefe/kanala bağlar. Destek ve varsayılanlar her ortamda aynı değildir.

Kaynaklar / Sources

• Microsoft Open Specifications · [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol
  §1.3 mesaj akışı (NEGOTIATE/CHALLENGE/AUTHENTICATE); §2.2.1 mesaj türleri ve MessageType 0x1/0x2/0x3; §2.2.1.1 NEGOTIATE, §2.2.1.2 CHALLENGE (ServerChallenge 8 bayt), §2.2.1.3 AUTHENTICATE (NtChallengeResponse).
• Microsoft Open Specifications · [MS-APDS]: Authentication Protocol Domain Support
  §1 sunucu ile DC arasında Netlogon üzerinden pass-through kimlik doğrulama; NTLM kredisinin DC'de doğrulanması (server-to-DC).
• Microsoft · NTLM overview
  NTLM challenge-response modeli, sunucunun kimlik bilgisini tutmaması ve domain hesaplarında doğrulamanın DC'ye taşınması; Kerberos'a yönlendirme önerileri.
• Microsoft · 4776(S, F) The computer attempted to validate the credentials for an account
  EventData alanları: Authentication Package (PackageName), Logon Account (TargetUserName), Source Workstation (Workstation), Error Code (Status 0x0 başarı); olay yalnız kimlik bilgisi için authoritative makinede üretilir.
• Microsoft · 4624(S) An account was successfully logged on
  Logon Type 3 (Network), Logon Process 'NtLmSsp', Authentication Package 'NTLM' alanlarının NTLM ağ oturumundaki anlamı.
• Microsoft Open Specifications · [MS-NRPC]: Netlogon Remote Protocol
  Sunucu ile DC arasındaki Netlogon secure channel; pass-through kimlik doğrulamanın taşındığı arayüz ailesi (genel kapsam).
• Microsoft Learn · SMB security hardening
  SMB signing prevents credential-relay attacks; Windows 11 24H2 and Windows Server 2025 require inbound and outbound SMB signing by default.
• Microsoft Learn · LDAP signing for AD DS
  LDAP signing protects message integrity; channel binding binds application authentication to TLS; defaults vary by Windows Server version and deployment type.
• Microsoft Learn · Supporting Extended Protection for Authentication (EPA) in a service
  Session-key signing/encryption protects authenticated traffic; EPA/channel binding protects forwarding over TLS; audit without enforcement does not protect against relay.
• MS-NLMP AUTHENTICATE_MESSAGE
  EncryptedRandomSessionKey KEY_EXCH field-length condition
• MS-NLMP Client Receives a CHALLENGE_MESSAGE
  MsvAvTimestamp or Currenttime; conditional KEY_EXCH/sign/seal
• RODC cached and forwarded authentication
  Cached permitted credentials versus uncached forwarding