NTLM Kullanımını Denetleme ve Kısıtlama: Sahada Uygulama Sırası

Kerberos’un çalışmadığı her yerde Windows sessizce NTLM’e düşer ve kimse bunu fark etmez. IP adresiyle bağlanan bir ağ sürücüsü, domain dışı bir tarayıcı, SPN’i eksik bir hizmet hesabı: hepsi NTLM’i ayakta tutar. Bu rehberde Active Directory ortamında NTLM bağımlılıklarını denetim politikalarıyla bulmayı, NTLMv1 ve LM’yi kapatmayı, SMB ve LDAP tarafında relay’i kesmeyi ve kapatılamayan uygulamalar için istisna yönetimini, sahada uyguladığımız sırayla anlatıyoruz.

NTLM neden hâlâ sorun

NTLM bir challenge–response protokolüdür: sunucu rastgele bir değer gönderir, istemci bu değeri kullanıcının parola özetinden (NT hash) türetilen anahtarla işleyip geri yollar. Tasarımın yapısal sonuçları şunlar:

• Özet, parolanın yerine geçer. Yanıtı üretmek için açık metin parola gerekmez; NT hash yeter. Bir makineden çalınan özet başka sistemlerde kimlik doğrulamak için kullanılabilir.
• Karşılıklı kimlik doğrulama yoktur. İstemci, konuştuğu sunucunun gerçekten hedeflediği sunucu olup olmadığını doğrulamaz. Araya girip kimlik doğrulamayı başka bir hedefe aktarmak (relay) bu yüzden mümkündür.
• NTLMv1 ve LM kriptografik olarak zayıftır. Yakalanan NTLMv1 yanıtlarından NT hash elde etmek pratikte mümkündür. LM özeti ise hiç kullanılmamalıdır.
• Doğrulama DC üzerinden yapılır. Domain hesaplarında sunucu, yanıtı doğrulamak için DC’ye başvurur (pass-through). NTLM trafiğinin izi bu yüzden en net DC’lerde görülür.

Microsoft, NTLM’in tüm sürümlerini kullanımdan kaldırılan özellikler listesine aldı; uzun vadede NTLM’in kapsadığı senaryoları IAKerb gibi Kerberos genişletmeleriyle karşılamayı hedefliyor, NTLMv1 desteği de yeni Windows sürümlerinde ayrıca daraltılıyor. Sürüm bazlı güncel durumu Microsoft’un NTLM genel bakış dokümantasyonundan doğrulayın. Pratik sonuç basit: NTLM bir günde kapanmaz. Önce görünür olur, sonra daralır.

Relay ve pass-the-hash: neyi kesiyoruz

Kısıtlama adımlarının hangi saldırıyı hedeflediğini bilmeden GPO açmak, kör uçuştur. İki senaryoyu savunma tarafından bakarak ele alalım.

NTLM relay

Saldırgan ağ içindeki bir istemcinin kendisine kimlik doğrulaması yapmasını sağlar: LLMNR/NBT-NS zehirlenmesiyle ya da bir sunucuyu zorla kimlik doğrulamaya iten (coercion) RPC çağrılarıyla. Gelen NTLM mesajlarını gerçek zamanlı olarak başka bir hedefe aktarır: imzalama zorunlu olmayan bir SMB sunucusuna, imzasız LDAP kabul eden bir DC’ye veya HTTP üzerinden kimlik doğrulama kabul eden AD CS web kaydı (certsrv) arayüzüne. Kurban bir DC’nin bilgisayar hesabıysa ve hedef AD CS ise iş domain’in tamamen ele geçirilmesine kadar gider. Relay’i kesen kontroller bellidir: SMB imzalama, LDAP imzalama, LDAP kanal bağlama (channel binding) ve HTTP hizmetlerinde Extended Protection for Authentication (EPA).

Pass-the-hash

Bir iş istasyonunda yerel yönetici olan saldırgan, LSASS belleğinden o makinede oturum açmış hesapların NT hash’lerini toplar ve bunlarla NTLM üzerinden başka sunuculara erişir. Burada NTLM kısıtlaması tek başına yetmez. Asıl kontroller yönetici hesaplarının hangi makinelerde oturum açtığını sınırlamak (Active Directory tier modeli), her makinede farklı yerel yönetici parolası kullanmak (Windows LAPS), Credential Guard ve ayrıcalıklı hesapları Protected Users grubuna almaktır. Protected Users üyeleri NTLM ile kimlik doğrulayamaz; grup aynı zamanda iyi bir NTLM kısıtlama aracıdır.

NTLM kullanımını denetleme politikaları

Kısıtlamadan önce envanter. İlgili ayarlar Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options altında, “Network security: Restrict NTLM” ön ekiyle durur. Denetim aşamasında hiçbir şey engellenmez, yalnız olay üretilir.

Ayar	Nereye	Denetim değeri
Audit NTLM authentication in this domain	Domain Controllers GPO	Enable all
Audit Incoming NTLM Traffic	Sunucular, DC’ler	Enable auditing for all accounts
Outgoing NTLM traffic to remote servers	İstemciler, sunucular	Audit all

Olaylar Applications and Services Logs → Microsoft → Windows → NTLM → Operational günlüğüne düşer. DC’lerde domain genelindeki NTLM doğrulamaları için 8004, istemci tarafında giden NTLM trafiği için 8001 olayı en çok işe yarayan kaynaklardır. Bu günlüğün varsayılan boyutu küçüktür. Sahada en sık gördüğümüz hata da budur: denetim açılır, günlük birkaç saatte kendi üstüne yazar, haftalar sonra elde anlamlı veri yoktur. Denetim süresince boyutu büyütün veya olayları SIEM’e iletin.

İkinci kaynak Security günlüğü. Başarılı oturum açma olayı 4624’te Authentication Package ve Package Name (NTLM only) alanları hangi protokolün ve NTLM sürümünün kullanıldığını gösterir. DC’lerde 4776 olayı NTLM kimlik bilgisi doğrulamasını kaydeder.

# DC'de son NTLM doğrulamaları (8004) - kaynak iş istasyonu ve hedef sunucu
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -MaxEvents 5000 |
  Where-Object Id -eq 8004 |
  Select-Object TimeCreated, Message |
  Export-Csv .\ntlm-8004.csv -NoTypeInformation -Encoding UTF8

# Herhangi bir sunucuda NTLMv1 ile yapılan oturum açmalar
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4624] and EventData[Data[@Name='LmPackageName']='NTLM V1']]" -MaxEvents 500 |
  ForEach-Object { $x = [xml]$_.ToXml()
    [pscustomobject]@{
      Zaman  = $_.TimeCreated
      Hesap  = ($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text'
      Kaynak = ($x.Event.EventData.Data | Where-Object Name -eq 'IpAddress').'#text'
    } }

Toplanan veriyi kaynak cihaz – hedef sunucu – hesap üçlüsüne indirip gruplayın. Listenin başında hep aynı şüpheliler çıkar: IP adresiyle haritalanmış ağ sürücüleri (Kerberos SPN’i ada bağlı olduğundan IP ile erişim NTLM’e düşer), çok fonksiyonlu yazıcıların “taramayı klasöre gönder” özelliği, domain’e üye olmayan cihazlar, SPN’i eksik veya yinelenmiş hizmet hesapları, DNS CNAME arkasındaki sunucular ve eski uygulama sunucuları. Bunların çoğu NTLM’e dokunmadan önce düzelir: doğru SPN kaydı, isimle erişim, setspn -X ile yinelenen SPN temizliği. Envanterin yarısı yapılandırma hatasıdır.

NTLMv1 ve LM’yi kapatmak

NTLMv1 ve LM, tam NTLM kısıtlamasından çok önce kapatılabilir ve kapatılmalıdır. Kontrol eden ayar Network security: LAN Manager authentication level (kayıt defterinde HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel).

Değer	Anlamı	Not
3	Yalnız NTLMv2 yanıtı gönder	İstemci tarafı güvenli, DC hâlâ v1 kabul eder
5	Yalnız NTLMv2 gönder; LM ve NTLM’i reddet	Hedef değer; DC’ler v1’i reddeder

Sıra şöyle: önce yukarıdaki 4624 sorgusuyla NTLMv1 kullanan kaynakları bulun, düzeltin, ardından değeri 5 olarak DC’lerden başlayarak tüm sistemlere uygulayın. DC’de değer 5 olduğunda istemci ne gönderirse göndersin domain hesapları için NTLMv1 doğrulaması reddedilir. Belirleyici olan DC’dir. Aynı GPO’da şunları da sıkılaştırın:

• Network security: Do not store LAN Manager hash value on next password change → Enabled (güncel Windows sürümlerinde varsayılan olarak açıktır; açıkça zorlamak denetimde kanıt sağlar).
• Network security: Minimum session security for NTLM SSP based clients / servers → Require NTLMv2 session security ve Require 128-bit encryption.

SMB imzalama, LDAP imzalama ve kanal bağlama

Relay, aktarılan kimlik doğrulamanın hedefte oturum açmasına dayanır. İmzalama, oturumun kimlik doğrulamadan türetilen bir anahtarla bütünlük korumasına alınmasını zorunlu kılar; araya giren taraf geçerli imza üretemez. Aktarım boşa gider.

Kontrol	GPO ayarı	Hedef değer
SMB sunucu imzalama	Microsoft network server: Digitally sign communications (always)	Enabled
SMB istemci imzalama	Microsoft network client: Digitally sign communications (always)	Enabled
LDAP imzalama (DC)	Domain controller: LDAP server signing requirements	Require signing
LDAP istemci	Network security: LDAP client signing requirements	Negotiate signing veya Require signing
LDAP kanal bağlama	Domain controller: LDAP server channel binding token requirements	Önce When supported, sonra Always

LDAP imzalamayı zorlamadan önce imzasız bind yapan istemcileri bulun. DC’lerde Directory Service günlüğündeki 2887 olayı 24 saatlik özet verir; tanılama kaydını açtığınızda 2889 olayı imzasız bind yapan istemci IP’sini ve hesabı tek tek listeler:

# DC'de LDAP Interface Events tanılama seviyesini 2'ye çek (2889 olayları için)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" /v "16 LDAP Interface Events" /t REG_DWORD /d 2 /f

# İmzasız bind yapan istemciler
Get-WinEvent -LogName 'Directory Service' -FilterXPath "*[System[EventID=2889]]" -MaxEvents 1000 |
  Select-Object TimeCreated, Message

Kanal bağlama, LDAPS (TLS) üzerindeki relay’e karşı koruma sağlar ve imzalamanın kapsamadığı boşluğu kapatır. Tespit tamamlanınca tanılama seviyesini tekrar 0’a çekin; açık unutulan tanılama günlüğü DC’de gereksiz yük ve gürültüdür. SMB imzalamada takıldığımız yer genelde eski NAS cihazları ve yazıcılardır: bazı modeller imzalı SMB’yi desteklemez, bazıları destekler ama yavaşlar. Yeni Windows sürümlerinde SMB imzalama varsayılanları sıkılaştırıldı; ortamınızdaki sürümlerin varsayılan davranışını kontrol edin. AD CS kullanıyorsanız web kaydı ve CES/CEP gibi HTTP uç noktalarında HTTPS ile EPA’yı açın, kullanılmayan web kaydı rolünü kaldırın.

Uygulama uyumluluğu ve istisna listesi

Denetimden çıkan her NTLM bağımlılığı için tek bir karar verilir: düzelt, değiştir veya istisna tanı. İstisna son seçenektir. Sahibi, gerekçesi ve bitiş tarihi olan bir kayıt olarak tutulur; aksi halde kalıcı hale gelir.

• Düzeltilebilir: IP ile erişim, eksik SPN, CNAME kaynaklı SPN uyuşmazlığı, Kerberos destekli ama NTLM’e zorlanmış uygulama ayarları.
• Değiştirilmesi gereken: Üreticisi tarafından desteklenmeyen, NTLMv1 kullanan cihaz ve yazılımlar.
• İstisna: Yakın vadede değiştirilemeyen, iş için zorunlu sistemler.

İstisnalar için iki ayar var: DC’lerde Network security: Restrict NTLM: Add server exceptions in this domain, istemci/sunucu tarafında Add remote server exceptions for NTLM authentication. Listeye sunucu adları (FQDN veya NetBIOS) satır başına bir giriş olarak yazılır; ad başında * joker karakteri kullanılabilir. Dikkat: geniş joker kalıplar istisnayı fiilen domain geneline yayar. İstisna tanımlanan sunucuyu ayrı bir VLAN’da tutmak, yalnız gerekli istemcilerin erişimine izin vermek ve bu sunucuya yönetici hesaplarıyla oturum açmamak riski sınırlar.

Kademeli kısıtlama planı

Aşağıdaki sıra kesinti riskini düşük tutarken saldırı yüzeyini her adımda daraltır. Aşamalar arasında en az bir ay sonu kapanışı ve bir yama döngüsü geçsin. Ayda bir çalışan bordro işi de, çeyrekte bir çalışan rapor da ancak böyle görünür.

1. Görünürlük: Tüm denetim ayarlarını açın, NTLM ve Security günlüklerini SIEM’e alın, envanter tablosunu oluşturun.
2. Hızlı kazanımlar: LLMNR ve NBT-NS’yi kapatın, DC’lerde Print Spooler hizmetini devre dışı bırakın, Protected Users grubunu ayrıcalıklı hesaplara uygulayın.
3. NTLMv1 ve LM: LmCompatibilityLevel değerini 5 yapın.
4. İmzalama: SMB imzalamayı sunucu ve istemcide zorlayın; LDAP imzalamayı ve kanal bağlamayı önce uyumluluk modunda, sonra zorunlu modda açın.
5. Hedefli engelleme: Tier 0 sistemlerden (DC’ler, AD CS, yedekleme ve kimlik altyapısı) giden NTLM’i Outgoing NTLM traffic to remote servers = Deny all ile engelleyin; gerekirse istisna ekleyin.
6. Domain geneli: Envanter temizlendikçe NTLM authentication in this domain ayarını önce “Deny for domain accounts to domain servers” gibi dar bir seviyede, sonra daha geniş seviyelerde uygulayın.

Her aşama aynı yöntemle doğrulanır: 8004 olay sayısının ve tekil kaynak–hedef çiftlerinin azaldığını izleyin, engelleme sonrası yardım masası kayıtlarını NTLM ile eşleştirin. “Paylaşıma erişemiyorum” çağrısı geldiğinde ilk bakılacak yer, o istemcinin 8001 ve o sunucunun 8004 kayıtlarıdır. Kerberos tarafındaki tamamlayıcı çalışma için Kerberoasting tespit ve korunma rehberine, genel denetim maddeleri için Active Directory güvenlik kontrollerine bakın. Ortamın tamamında NTLM envanteri ve kısıtlama planı, Active Directory güvenlik denetiminin doğal bir parçasıdır; GPO tarafındaki ayarlar da sunucu sıkılaştırma standartlarına girmelidir.

Sık sorulan sorular

NTLM’i domain genelinde tamamen kapatmak mümkün mü?

Teknik olarak mümkün, ama çoğu ortamda önce uzun bir envanter ve düzeltme süreci gerekir. Gerçekçi hedef şudur: NTLMv1 ve LM tamamen kapalı, Tier 0 sistemlerden NTLM engelli, relay imzalamayla kesilmiş, kalan NTLM kullanımı sahibi belli istisnalara inmiş.

Denetim modunu açmak performansı etkiler mi?

Denetim ayarları yalnız olay üretir, kimlik doğrulamayı engellemez. Yoğun ortamlarda NTLM Operational günlüğü hızla dolar; günlük boyutunu artırın veya olayları SIEM’e iletin.

SMB imzalama dosya sunucularını yavaşlatır mı?

İmzalama ek işlem yükü getirir; etkisi donanıma, SMB sürümüne ve iş yüküne bağlıdır. Yüksek trafikli dosya sunucularında zorlamadan önce pilot ölçüm yapın, eski NAS ve yazıcıların imzalı SMB desteğini ayrıca test edin.

Protected Users grubu NTLM kısıtlamasının yerine geçer mi?

Hayır. Protected Users yalnız üye hesapların NTLM ile kimlik doğrulamasını engeller. Hizmet hesapları ve normal kullanıcılar için denetim, NTLMv1 kapatma, imzalama ve Restrict NTLM ayarları ayrıca gerekir.