Kerberos mu NTLM mi? Negotiate ve protokol seçimini etkileyen koşullar.

1. Core Mechanism / Temel mekanizma

Uygulama bir SSPI güvenlik paketi seçer (Kerberos, NTLM veya Negotiate); bu paket seçimi bir uygulama kararıdır, dolayısıyla 'protokol tercihi hiçbir zaman uygulamanın kararı değildir' demek yanlış olur. Ancak uygulama Negotiate'i seçtiğinde, hangi somut protokolün (Kerberos mu NTLM mi) kullanılacağı bir SPNEGO müzakeresiyle (RFC 4178 / MS-SPNG) belirlenir. İstemci tarafı bir NegTokenInit üretir; bu token, initiator'ın sunduğu mekanizmaları tercih sırasıyla listeleyen bir mechTypes alanı taşır (tipik olarak önce Kerberos, sonra NTLM). Bu tercih listesi sabit veya tükenmez değildir; modern Windows ek mekanizma/uzantı sunabilir. Acceptor desteklediği mechanism’i bildirir; token alışverişi taraflar başarıya ulaşana ya da müzakere hata verene kadar sürer. NTLM’e geçiş hatanın türüne, uygulamaya ve politikaya bağlıdır; her Kerberos hatası otomatik fallback anlamına gelmez. Bu dersin sınırı 'Negotiate seçildiğinde hangi protokol neden seçildi' sorusudur: NTLM'in mesaj yapısı 07.01'de, NTLMv2 response/anahtar materyali 07.02'de, signing/EPA/channel binding korumaları 07.04'tedir. Burada odak, seçimi belirleyen koşullar ve seçimin telemetride bıraktığı iz (4624 AuthenticationPackageName) ile bunun yanlış okunma biçimleridir.

Arabirimler ve belirtimler

• RFC 4178: mechTypes, initiator’ın tercih sırasıyla sunduğu OID listesidir. Acceptor sunulan ve kabul ettiği bir mechanism’i seçebilir veya listeyi reddedebilir; her zaman ilk ortak öğeyi seçmek zorunda değildir.
• RFC 4178 §4.2.1 / §5: mechListMIC, seçilen mechanism ile korunan bir MIC'tir ve mechTypes listesinin ortadaki bir taraf tarafından değiştirilmediğini (downgrade) tespit etmeye yarar.
• Bu fixture’da SPNEGO OID’i 1.3.6.1.5.5.2 wrapper’ı tanımlar. mechTypes içinde standart Kerberos V5 OID’i 1.2.840.113554.1.2.2 ve eski Windows’ın truncated Kerberos V5 OID’i 1.2.840.48018.1.2.2 aynı mechanism’i temsil eder (RFC 4178 Appendix C). NTLM SSP OID’i 1.3.6.1.4.1.311.2.2.10’dur. Üç offered OID, üç bağımsız protocol değildir.
• Microsoft Negotiate SSP: uygulama SSPI üzerinden Negotiate paketini seçebilir; paket Kerberos'u, kullanılabildiğinde ve çağıran uygulama hedefi tanımlamak için SPN, UPN veya NetBIOS account name gibi yeterli bilgi sağladığında tercih eder. Seçilen paket 4624 AuthenticationPackageName alanında görünür.
• Microsoft 4624 (Field Descriptions): LogonType 3 (Network) ağ oturumudur; LogonProcessName 'NtLmSsp' NTLM SSP tarafından işlenen bir oturumu, AuthenticationPackageName ise fiilen kullanılan paketi (Kerberos / NTLM / Negotiate) ayırt eder.
• Microsoft 4624: LmPackageName alanı NTLM oturumlarında kullanılan alt sürümü ('NTLM V1' / 'NTLM V2' / 'LM') gösterir; Kerberos oturumlarında '-' olur. KeyLength anahtar uzunluğunu (ör. 128) taşır; Kerberos oturumlarında 0'dır.
• Microsoft NTLM overview / Restrict NTLM: 'Network security: Restrict NTLM' politika ailesi giden/gelen NTLM trafiğini Allow / Audit / Deny olarak yönetebilir; Deny, NTLM'e düşmeyi başarısız kılabilir, yani fallback her ortamda garanti değildir.

Uygulama paket seçer; Negotiate mechanism’i belirler

Windows'ta bir istemci 'Negotiate' (SSPI'nin Negotiate paketi) ile bir sunucuya kimlik doğrularken, hangi protokolün kullanılacağı tek tek uygulama koduyla değil, SPNEGO müzakeresiyle belirlenir. İstemci bir NegTokenInit üretir ve bunun içindeki mechTypes listesi, desteklediği mechanism'leri tercih sırasıyla sıralar: önce Kerberos, sonra NTLM.

Acceptor ilk tercihi kabul edebilir, sunulan başka bir mechanism’i seçebilir veya hiçbirini kabul etmeyebilir. Liste seçenekleri gösterir; tamamlanmış context veya başarılı logon göstermez. Uygulamanın doğrudan Kerberos/NTLM seçmesi ile Negotiate üzerinden müzakere başlatması da farklı yollardır.

Aşağıdaki sentetik kayıt yalnız NegTokenInit mechTypes listesini gösterir. İki Kerberos OID’i aynı mechanism’in standart ve legacy tanımlayıcılarıdır; NTLM üçüncü OID ile sunulur. Bu kayıtta sonuç, context establishment veya mechListMIC yoktur; onlara ait kanıt üretilemez.

Kerberos ne zaman kullanılamaz: SPN'in olmadığı durumlar

Uygun SPN/target identity, Kerberos’un önkoşullarından biridir; tek başına başarı garantisi değildir. Ticket yolu, acceptor’ın key bağlamı ve uygulama/policy koşulları da gerekir. Windows varsayılanında IP-literal hedef için Kerberos denenmez; TryIPSPN ve uygun IP-SPN kaydı bu varsayılanı değiştirebilir. NTLM fallback yine uygulama ve policy’ye bağlıdır.

En sık koşullar şunlardır: hedefe IP adresiyle bağlanmak (varsayılan yolda bir IP-literal için karşılık gelen bir SPN yoktur, dolayısıyla özel bir IP-SPN desteği/yapılandırması olmadıkça Kerberos'a çözülmez), hedef servisin SPN'inin hiç kaydedilmemiş veya iki hesaba birden kaydedilmiş (duplicate) olması, hedef için geçerli service ticket cache'te yokken istemcinin KDC'ye ulaşamaması, istemci veya sunucunun bir workgroup/yerel hesap bağlamında olması (domain KDC yok) ve uygulamanın doğrudan NTLM paketi çağırması.

KDC'ye ulaşmak ile eldeki bileti kullanmak ayrı işlerdir. İstemcinin cache'inde hedefe uygun, hâlâ geçerli bir service ticket varsa bunu doğrudan servise sunabilir. KDC kesintisi yeni ticket alma veya yenileme yolunu engeller; mevcut ticket'ı anında geçersiz kılmaz. Yalnız TGT'nin cache'te olması yeterli değildir: hedef için service ticket yoksa onu almak üzere KDC gerekir. Servis PAC doğrulaması gibi bir nedenle DC'ye ihtiyaç duyuyorsa kesinti yine bağlantıyı etkileyebilir.

Bu koşulların hepsi otomatik olarak 'NTLM'e düşüş' anlamına gelmez: koşullar elverdiğinde Negotiate NTLM'e geçebilir, ama SPN/KDC/politika/uygulama koşullarından biri başka bir biçimde başarısız olursa (ör. Restrict NTLM Deny, doğrudan Kerberos çağıran uygulama) düşmek yerine hata dönebilir. Ortak payda şudur: Kerberos'un başarısızlığı çoğu zaman bir saldırı değil, bir adlandırma/erişim/yapılandırma durumudur ve sonucu ortamın politikasına bağlıdır; bu yüzden 'NTLM görüldü' başlı başına bir olay değil, bir koşulun (izin verildiyse) sonucudur.

mechListMIC: downgrade sessiz olmasın diye

Bir liste sunulup en iyi ortak mechanism seçildiğinde akla gelen risk şudur: aradaki bir taraf listeyi kırpıp tarafları daha zayıf bir mechanism'e (ör. Kerberos yerine NTLM) 'düşürebilir' mi? SPNEGO buna karşı mechListMIC alanını tanımlar.

mechListMIC, mechanism context’i üzerinden mechTypes listesini korur. RFC 4178 §5 bunu koşullu tanımlar: seçilen mechanism integrity sağlamıyorsa MIC kullanılmaz; iki tarafın da en yüksek tercihi seçilmişse exchange optional’dır; diğer integrity destekli durumlarda context kurulduktan sonra MIC exchange gerekir. Bu nedenle her NegTokenInit’te MIC bulunduğu veya her alışverişte karşılıklı üretildiği söylenemez.

Bunun pratik anlamı: mechanism seçimi tümüyle 'kör' değildir. Ancak bu koruma müzakerenin bütünlüğünü hedefler; seçilen mechanism'in kendi içindeki korumaları (ör. NTLM'in imzalanması, channel binding) ayrı bir konudur ve 07.04'te ele alınır.

Fallback bir kurtarma değil, bir koşulun sonucudur

Yaygın bir varsayım, 'Kerberos olmazsa NTLM devreye girer ve bağlantı her zaman kurtulur' biçimindedir. Bu iki noktada yanlıştır. Birincisi: NTLM'e düşmek bir çözüm değil, Kerberos'un ön koşullarının (SPN/KDC) sağlanmadığının işaretidir; kök neden hâlâ oradadır.

İkincisi: fallback her ortamda mümkün değildir. 'Network security: Restrict NTLM' politikaları giden veya gelen NTLM'i Deny olarak ayarlarsa, NTLM denemesi başarısız olur ve bağlantı hiç kurulmayabilir. Yani NTLM'in varlığı bir 'garanti' değil, politika ve yapılandırmaya bağlı bir olasılıktır.

Saldırgan perspektifinden de bu önemlidir: NTLM'e düşürebilmek bir yetenek gibi görünse de, mechListMIC downgrade'i tespit edebilir, Restrict NTLM denemeyi bloklayabilir ve bazı uygulamalar zaten belirli bir paketi doğrudan çağırır. 'Her zaman NTLM'e düşürürüm' bir kural değil, ortama bağlı bir ihtimaldir.

Seçimin kanıtı 4624'te nasıl okunur

Bir oturumun hangi protokolle kurulduğu, başarılı logon'da 4624 kaydında görünür. AuthenticationPackageName alanı fiilen kullanılan paketi (Kerberos, NTLM veya Negotiate) verir. LogonType 3 bir ağ oturumudur; LogonProcessName 'NtLmSsp' NTLM SSP tarafından işlenmiş bir oturuma işaret eder.

NTLM oturumlarında LmPackageName alt sürümü ('NTLM V2' beklenir; 'NTLM V1'/'LM' eski/zayıf) ve KeyLength anahtar uzunluğunu (ör. 128) gösterir; Kerberos oturumlarında LmPackageName '-' ve KeyLength 0 olur. Böylece tek bir 4624 kaydı, hem hangi protokolün seçildiğini hem de NTLM ise hangi alt sürümün kullanıldığını söyler.

Ancak bu alanları tek başına 'iyi/kötü' etiketiyle okumak yanıltıcıdır: NTLM V2 network logon pek çok meşru durumda (IP-literal hedef, eksik SPN, workgroup) beklenen sonuçtur. Kanıtı doğru okumak için AuthenticationPackageName ile hedefin adlandırılışı ve SPN durumu birlikte değerlendirilir — bu dersin artifact'i bu birlikte-okuma alıştırmasıdır.

Durum ve veri akışı

1. tunahan, WKS17'den paylaşılan bir kaynağa (FS01) 'Negotiate' ile bağlanmak ister; SSPI bir SPNEGO NegTokenInit üretir ve mechTypes listesinde önce Kerberos'u, sonra NTLM'i sunar.
2. Uygun target identity/SPN Kerberos için gereklidir; uygun ticket, acceptor key ve uygulama/policy koşullarıyla birlikte değerlendirilir. Offered liste seçimin veya başarının kanıtı değildir.
3. İstemci önce hedef için geçerli service ticket olup olmadığını dikkate alır. Cache'te uygun bilet varsa KDC erişilemese de servise sunulabilir; hedefin doğrulama koşulları ayrıca geçerlidir. Yeni bilet gerekiyorsa eksik SPN veya KDC kesintisi talebi engelleyebilir. NTLM fallback'in olup olmayacağını uygulama ve politika belirler; Restrict NTLM Deny varsa bağlantı hata verebilir.
4. NTLM seçilirse SSPI NTLM challenge-response akışını yürütür (07.01); başarılı ağ oturumu 4624'te LogonType=3, LogonProcessName='NtLmSsp', AuthenticationPackageName=NTLM, LmPackageName='NTLM V2', KeyLength=128 olarak kaydedilir.
5. Ortamda 'Restrict NTLM: Deny' etkinse, NTLM denemesi başarısız olur; bağlantı kurulmaz ve Kerberos olmadan bir çıkış yolu kalmayabilir — fallback garanti değildir.
6. mechListMIC, RFC 4178 §5 koşullarında liste bütünlüğünü korur. Kullanıldığı ve doğrulandığı bağlamda değiştirme tespit edilebilir; her exchange’de MIC varsayma.
7. Analist 4624'ü okurken AuthenticationPackageName=NTLM'i tek başına alarm saymaz; hedefin IP mi FQDN mi olduğu, ilgili SPN'in kayıtlı olup olmadığı ve LmPackageName'in V2 mi olduğu ile birlikte yorumlar.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: 'Kerberos başarısız olursa NTLM her zaman devreye girer, dolayısıyla NTLM'e düşürme benim elimde güvenilir bir kaldıraçtır.' Gerçekte protokol seçimi SPNEGO müzakeresine ve ortamın koşullarına bağlıdır: NTLM'e geçiş Kerberos kullanılamadığında veya çağıran uygulama yeterli hedef bilgisi sağlamadığında mümkün olabilir; SPN/KDC koşulu tek başına geçişin gerçekleştiğini kanıtlamaz; mechListMIC liste üzerinde oynanmasını tespit edebilir; ve 'Restrict NTLM' politikaları denemeyi tümden bloklayabilir. Bu yüzden 'her zaman NTLM'e düşürürüm' bir kural değil, ortama bağlı bir ihtimaldir. Aynı şekilde savunma tarafında da 'NTLM gördüm demek saldırı var demek' hatalıdır; NTLM pek çok meşru koşulun doğal sonucudur.

Technical prerequisites

• Windows varsayılanında IP literal hedef Kerberos SPN’i olarak denenmez; istemcide TryIPSPN etkin ve karşılık gelen IP tabanlı SPN kayıtlıysa istisna değişebilir. Eksik/duplicate SPN de Kerberos ticket alımını bozabilir; NTLM fallback uygulama, hata ve politikaya bağlıdır.
• Workgroup veya local-account bağlamı domain Kerberos kullanmaz; domain hesabında DC’ye erişilememesi uygulama ve hata türüne göre NTLM fallback yerine doğrudan başarısızlıkla sonuçlanabilir.
• Ortamda giden/gelen NTLM'in 'Restrict NTLM: Deny' ile bloklanmamış olması — bloklanmışsa fallback başarısızdır.
• Uygulamanın belirli bir paketi doğrudan çağırmaması; doğrudan Kerberos çağıran bir uygulama, koşullar sağlanmazsa NTLM'e sessizce geçmez, hata döndürür.

Exploitation mechanism / İstismar mekanizması

İncelenen yanlış varsayım “Kerberos kullanılamıyorsa NTLM her zaman başarılı olur” cümlesidir. Hedef adı/SPN, ticket yolu, uygulamanın paket seçimi ve Restrict NTLM policy’si sonucu birlikte belirler. Offered liste ile seçilmiş mechanism’i ayır; mechListMIC’in kullanım koşullarını kontrol et. NTLM seçilmiş olması da signing veya channel binding’in kapalı olduğunu göstermez. Buradaki örnekler bu sınırları açıklıyor; bir downgrade veya relay uygulaması çalıştırmıyor.

NTLM'e düşürme bir yetenek değil, bir koşul

'Kerberos'u devre dışı bırakıp NTLM'e zorlarım' ifadesi tek başına yeterli değildir. Uygulama hedef için Kerberos bilgisini sağlayabiliyorsa Negotiate Kerberos'u deneyebilir; SPN hatası, IP literal veya KDC erişim sorunu NTLM'e otomatik ve her uygulamada aynı biçimde geçileceğini garanti etmez.

Dolayısıyla 'NTLM'e düşürme' evrensel bir kaldıraç değildir; hedefin nasıl adlandırıldığına ve ortamın SPN/KDC durumuna bağlıdır. Bu, hem saldırı planının hem de savunma beklentisinin ortamı bilmeden kurulamayacağı anlamına gelir.

Downgrade sessiz değildir

RFC 4178 §5 koşullarında gereken veya sağlanıp doğrulanan mechListMIC, offered listenin bütünlüğünü kontrol eder. İlk token’ı görmek, bu sonraki kontrolün gerçekleştiğini kanıtlamaz.

Bu, downgrade'in imkânsız olduğu anlamına gelmez; mechanism ve sürüm kombinasyonlarına, uygulamanın MIC'i zorunlu tutup tutmadığına bağlıdır. Ama 'listeyi sessizce değiştiririm ve kimse fark etmez' varsayımı, mechListMIC devredeyken güvenilir değildir.

Sınır: seçim ≠ koruma

Bu ders protokolün hangi koşulda seçildiğini açıklar; seçilen protokolün relay'e veya dinlemeye karşı ne kadar dayanıklı olduğunu değil. NTLM seçildi diye oturum otomatik olarak savunmasız değildir: signing/sealing ve channel binding devredeyse relay kırılır (07.04).

Bu yüzden bu katmanın çıktısı bir 'exploit' değil, bir okuma çerçevesidir: 'NTLM neden seçildi' sorusu ile 'seçilen NTLM ne kadar korunuyor' sorusu ayrıdır ve ikincisi bir sonraki derstedir.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Audit Logon (Success) — 4624: başarılı oturumlarda AuthenticationPackageName seçilen paketi (Kerberos / NTLM / Negotiate) verir; bu alan protokol seçiminin birincil kanıtıdır ve endpoint/sunucu tarafında üretilir.
• NTLM oturumlarında LogonProcessName 'NtLmSsp', LmPackageName alt sürüm ('NTLM V2' beklenir) ve KeyLength birlikte okunur; Kerberos oturumlarında LmPackageName '-' ve KeyLength 0 olur, bu da ayrımı netleştirir.
• DC'de NTLM kimlik doğrulaması ayrıca 4776 (The computer attempted to validate the credentials for an account) ile görünür; bu, sunucudan DC'ye giden NTLM credential validation'ın kaydıdır ve endpoint 4624'ünden farklı bir gözlem noktasıdır.
• NTLM'in nerede kullanıldığını envanterlemek için 'Restrict NTLM: Audit' politikaları ve NTLM Operational log'u kullanılır; bunlar 'Deny'e geçmeden önce hangi bağlantıların NTLM'e bağımlı olduğunu gösterir.
• Tek bir 4624 kaydı 'iyi/kötü' kararı vermez; AuthenticationPackageName hedefin adlandırılışı (IP mi FQDN mi), ilgili SPN'in kayıtlı olup olmadığı ve kaynak/varış bağlamı ile birlikte değerlendirilmelidir.
• KDC kesintisinde yalnız hedef adı ve SPN'e bakma; istemcide hedefe uygun geçerli service ticket var mı, yoksa yeni ticket mı gerekiyor, bunu ayır. 4624 seçilen paketi gösterir; bu alan tek başına cache durumunu veya fallback nedenini kanıtlamaz.

Events and relevant fields

• 4624 / AuthenticationPackageName: fiilen kullanılan paket — 'Kerberos', 'NTLM' veya 'Negotiate'; seçimin doğrudan kanıtı.
• 4624 / LogonType: 3 (Network) ağ oturumu; protokol seçimi ağ kimlik doğrulamasında anlamlıdır.
• 4624 / LogonProcessName: 'NtLmSsp' NTLM SSP'nin işlediği oturumu, 'Kerberos'/'Negotiate' diğer akışları işaret eder.
• 4624 / LmPackageName: NTLM alt sürümü — 'NTLM V2' (beklenen), 'NTLM V1' / 'LM' (eski/zayıf); Kerberos oturumlarında '-'.
• 4624 / KeyLength: oturum anahtarı uzunluğu (ör. 128); Kerberos oturumlarında 0. NTLM oturumlarında IpAddress/IpPort çoğu zaman '-' olur, çünkü NTLM ağ oturumları TCP/IP ayrıntısı taşımayabilir.
• 4776 / (DC) Package/TargetUserName/Workstation/Status: DC'nin NTLM credential validation kaydı; endpoint 4624'ünden bağımsız ikinci bir NTLM göstergesidir.

Hangi alan neyi söyler

Protokol seçimini okumanın ilk adımı, 4624'te üç alanı birlikte görmektir: AuthenticationPackageName (hangi paket), LogonProcessName (NtLmSsp mi) ve LmPackageName/KeyLength (NTLM ise alt sürüm ve anahtar). Bu üçlü, 'Kerberos mu NTLM mi ve NTLM ise ne kadar eski' sorusunu yanıtlar.

İkinci adım, bu kaydı bağlamla eşlemektir: hedef IP ile mi çağrıldı, ilgili SPN kayıtlı mı, kaynak host beklenen bir istemci mi. Alanı bağlamdan koparıp 'NTLM = kötü' demek, meşru koşulların çoğunu yanlış pozitife çevirir.

Alan                         Kerberos oturumu   NTLM oturumu
---------------------------  -----------------  ------------------
AuthenticationPackageName    Kerberos           NTLM
LogonProcessName             Kerberos/Negotiate NtLmSsp
LmPackageName                -                  NTLM V2 (beklenen)
KeyLength                    0                  128 (ornek)
IpAddress/IpPort             genelde dolu       cogu zaman -

Aynı belirti, farklı koşul

'NTLM göründü' tek bir kök nedene işaret etmez. Kök neden bir IP-literal hedef, eksik/duplicate SPN, ulaşılamayan KDC veya workgroup bağlamı olabilir; dördü de aynı 4624 NTLM kaydını üretir. Doğru soru 'NTLM neden seçildi' sorusudur, 'NTLM neden kötü' değil.

Bu yüzden tespit, seçimi bir koşul göstergesi olarak ele alır: NTLM oranındaki ani artış, eski alt sürümlerin (LM/NTLM V1) belirmesi veya beklenmedik kaynaklardan NTLM, incelemeye değer sinyallerdir; tek bir NTLM logon'u ise çoğu zaman rutindir.

Detection logic · XPath

<!-- Ornek 4624 belgesi icinde NTLM ile kurulmus network logon'lari secer. -->
<!-- Tek bir Event XML belgesi uzerinde secim yapar; korelasyon/temel cizgi yoktur. -->
<!-- NTLM network logon cogu ortamda mesrudur; bu secim bir kapsam, kanit degildir. -->
//*[local-name()='Event']
  [*[local-name()='System']/*[local-name()='EventID']='4624']
  [*[local-name()='EventData']/*[local-name()='Data'][@Name='LogonType']='3']
  [*[local-name()='EventData']/*[local-name()='Data'][@Name='AuthenticationPackageName']='NTLM']

Query assumptions

• XPath yalnızca verilen tek Event XML belgesi üzerinde seçim yapar; birden çok host, oturum veya zaman penceresi arasında korelasyon kurmaz.
• AuthenticationPackageName ve LogonType metin olarak ('NTLM', '3') karşılaştırılır; bir backend değerleri farklı türde saklıyorsa eşleşme uyarlanmalıdır.
• Bu ifade bu oturumda yalnızca örnek 4624 belgesi üzerinde değerlendirildi; canlı bir sistemde çalıştırılmadı ve bir temel çizgiyle kıyaslanmadı.

False positives

• NTLM V2 network logon pek çok meşru durumda beklenir: hedefe IP ile erişim, ilgili SPN'in kayıtlı olmaması, workgroup/yerel hesap, doğrudan NTLM çağıran uygulamalar. Bu seçim bunları da yakalar.
• Bir yönetim aracının veya yedekleme ajanının IP-literal ile bağlanması rutin NTLM üretebilir; bu bir yapılandırma tercihidir, saldırı değildir.
• Uygun SPN ile Kerberos seçilmiş bir erişim bu NTLM selector’a uymaz. SPN’in varlığı tek başına hangi package’in seçildiğini kanıtlamaz.

Hardening

• Servislerin SPN’lerini doğru ve tekil kaydet; varsayılan Windows davranışında IP literal yerine FQDN kullanımını teşvik et. TryIPSPN ve IP tabanlı SPN kaydı varsa, bu istisnayı ayrıca envantere al.
• Duplicate SPN'leri envanterle ve tekilleştir (bkz. 06.03); duplicate SPN Kerberos'u kırar ve dolaylı olarak NTLM'e kaymaya yol açar.
• 'Network security: Restrict NTLM' ailesini önce Audit ile ölç, hangi bağlantıların NTLM'e bağımlı olduğunu gör; sonra kademeli olarak Deny'e geçir — doğrudan Deny meşru akışları kırabilir.
• 'Network security: LAN Manager authentication level' ile LM ve NTLMv1'i devre dışı bırak (yalnız NTLMv2); LmPackageName telemetrisinde 'LM'/'NTLM V1' görünmeleri hedef alınmalıdır.
• NTLM'e bağımlı kalması gereken uygulamalar için 07.04'teki korumaları (signing, EPA/channel binding) zorunlu kıl; seçim NTLM olsa bile relay yüzeyi daralsın.
• Kontrollü doğrulamada FQDN/SPN ile IP-literal erişimleri karşılaştır; seçilen package’i gerçekten gözle. Kerberos veya NTLM sonucunu yalnız hedef adından varsayma; cache, TryIPSPN, uygulama ve policy koşullarını kaydet.

Örnekler üzerinde oku / Read the examples

60 32 06 06 2b 06 01 05 05 02 a0 28 30 26 a0 24
30 22 06 09 2a 86 48 86 f7 12 01 02 02 06 09 2a
86 48 82 f7 12 01 02 02 06 0a 2b 06 01 04 01 82
37 02 02 0a

<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>4624</EventID>
    <Version>2</Version>
    <Level>0</Level>
    <Task>12544</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T07:41:12.6180000Z" />
    <EventRecordID>884213</EventRecordID>
    <Correlation />
    <Execution ProcessID="784" ThreadID="9044" />
    <Channel>Security</Channel>
    <Computer>FS01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="SubjectUserSid">S-1-0-0</Data>
    <Data Name="SubjectUserName">-</Data>
    <Data Name="SubjectDomainName">-</Data>
    <Data Name="SubjectLogonId">0x0</Data>
    <Data Name="TargetUserSid">S-1-5-21-3623811015-3361044348-30300820-1462</Data>
    <Data Name="TargetUserName">tunahan</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetLogonId">0x2a9f1c3</Data>
    <Data Name="LogonType">3</Data>
    <Data Name="LogonProcessName">NtLmSsp </Data>
    <Data Name="AuthenticationPackageName">NTLM</Data>
    <Data Name="WorkstationName">WKS17</Data>
    <Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="LmPackageName">NTLM V2</Data>
    <Data Name="KeyLength">128</Data>
    <Data Name="ProcessId">0x0</Data>
    <Data Name="ProcessName">-</Data>
    <Data Name="IpAddress">-</Data>
    <Data Name="IpPort">-</Data>
    <Data Name="ImpersonationLevel">%%1833</Data>
  </EventData>
</Event>

İki yanlış kanı / Two reality checks

Sanılan: Kerberos başarısız olursa NTLM her zaman devreye girer ve bağlantı kurtulur.

Gerçekte: Hayır. NTLM'e geçiş Kerberos kullanılamadığında veya uygulama yeterli hedef kimliği bilgisi vermediğinde mümkün olabilir; her Kerberos hatası otomatik fallback değildir. Windows'un varsayılan IP-literal davranışı ile TryIPSPN istisnası da hedef adlandırmasının önemini gösterir. 'Restrict NTLM' Deny politikası NTLM denemesini engelleyebilir; SPNEGO'da doğrulanan mechListMIC ise müzakere listesinin değiştirilmesini tespit etmeyi hedefler.

Sanılan: 4624'te AuthenticationPackageName=NTLM görmek tek başına relay/saldırı kanıtıdır.

Gerçekte: Hayır. NTLM V2 network logon pek çok meşru koşulun doğal sonucudur: varsayılan Windows ayarında IP literal ile erişim (TryIPSPN etkin ve IP tabanlı SPN kayıtlıysa istisna mümkündür), ilgili SPN'in kayıtlı olmaması veya duplicate olması, workgroup/yerel hesap bağlamı ve doğrudan NTLM çağıran uygulamalar. Bu yüzden tek bir NTLM kaydı bir koşul göstergesidir, kötü niyet kanıtı değildir. Anlamlı sinyal, NTLM'in bağlamıyla belirir: eski alt sürümler (LmPackageName 'LM'/'NTLM V1'), beklenmedik kaynaklardan NTLM veya oran değişimleri incelenir; kanıt için AuthenticationPackageName tek başına değil, hedef adı ve SPN durumu ile birlikte okunur.

Kaynaklar / Sources

• IETF · RFC 4178 — The SPNEGO Negotiation Mechanism
  §4.2 NegTokenInit (mechTypes tercih listesi); §4.2.1 / §5 mechListMIC ve downgrade tespiti.
• Microsoft Open Specifications · [MS-SPNG] Simple and Protected GSS-API Negotiation
  Negotiate mechanism OID'leri: Kerberos V5 1.2.840.113554.1.2.2, MS Kerberos 1.2.840.48018.1.2.2, NTLM SSP 1.3.6.1.4.1.311.2.2.10; mechanism listesi ve tercih sırası.
• Microsoft · 4624(S) An account was successfully logged on
  Field Descriptions: AuthenticationPackageName (Negotiate seçim cümlesi), LogonProcessName (NtLmSsp), LmPackageName (NTLM V1/V2/LM), KeyLength; Logon Types (3=Network); NTLM oturumlarında IP ayrıntısının bulunmaması.
• Microsoft · Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
  Outgoing NTLM için Allow all / Audit all / Deny all; gönderen bilgisayardaki NTLM Operational log, remote-server exception listesi ve uyumluluk etkisi.
• Microsoft · Network security: Restrict NTLM: Incoming NTLM traffic
  Allow all / Deny all domain accounts / Deny all accounts. Gelen trafiği engelleme ayarı; audit ayrı bir politikadır.
• Microsoft · Network security: Restrict NTLM: Audit incoming NTLM traffic
  Disable / Enable auditing for domain accounts / Enable auditing for all accounts; alıcı bilgisayardaki NTLM Operational log. Bu politika trafiği engellemez.
• Microsoft · 4776(S, F) The computer attempted to validate the credentials for an account
  DC'de NTLM credential validation kaydı: Authentication Package (MICROSOFT_AUTHENTICATION_PACKAGE_V1_0), Logon Account, Source Workstation, Error Code alanları.
• Microsoft · NTLM overview (kimlik doğrulama ve azaltım bağlamı)
  NTLM'in Kerberos'a göre konumu ve NTLM kullanımını azaltma önerileri; protokol seçimi bağlamı.
• Microsoft Learn · Configuring Kerberos for IP Address
  Default Windows behavior does not attempt Kerberos for IP-address hostnames; TryIPSPN plus a registered IP-address SPN enables the exception.
• Microsoft Learn · Microsoft Negotiate SSP
  Negotiate selects Kerberos unless it cannot be used or the calling application lacks sufficient target identity information; supported target identifiers include SPN, UPN, or NetBIOS account name.
• Microsoft Learn · Kerberos authentication overview
  More efficient authentication to servers: yeniden kullanılan service ticket ve PAC doğrulamasında DC ihtiyacı.