Bu rehber, savunma ve yetkili yönetim amacıyla hazırlanmıştır. Amaç saldırı aracı çalıştırmak değil; mevcut bağımlılıkları ölçmek, denetim günlüklerini toplamak, uyumsuz istemcileri düzeltmek ve politikaları kontrollü biçimde zorunlu hale getirmektir.
NTLM relay nasıl mümkün olur?
NTLM challenge-response mekanizması parolayı açık metin olarak taşımaz. Ancak kimlik doğrulama, istemcinin bağlandığı kanal veya hedef servisle kriptografik olarak bağlanmadığında aradaki saldırgan yanıtı başka bir servise aktarabilir. Hedef servis aynı kimliği kabul ederse saldırgan, hesabın o servisteki yetkileriyle işlem yapabilir.
Relay ile parola tahmini aynı şey değildir. Brute force veya password spraying yeni bir kimlik doğrulama üretmeye çalışır; relay ise geçerli bir doğrulama akışını başka hedefe taşır. Bu nedenle karmaşık parola politikası gerekli olsa da tek başına relay’i durdurmaz.
| Kontrol | Koruduğu yol | Temel etki |
|---|---|---|
| SMB signing | SMB oturumları | Mesaj bütünlüğü ve relay direnci |
| LDAP signing | SASL LDAP bind | İmzalanmamış LDAP oturumlarını reddeder |
| LDAP channel binding | LDAPS üzerinde NTLM/Simple Bind | Kimlik doğrulamayı TLS kanalına bağlar |
| EPA | HTTP/IIS ve destekleyen servisler | SPN/CBT ile hedef ve kanal bağlama |
| NTLM kısıtlama | Genel NTLM kullanımı | Gereksiz eski protokol bağımlılığını azaltır |
Önce görünürlük: körlemesine zorlamayın
LDAP signing veya EPA’yı doğrudan “Require” seviyesine almak eski cihazları, yazıcıları, NAS sistemlerini, Java tabanlı uygulamaları ve özel entegrasyonları bozabilir. Güvenli geçiş; envanter, denetim, düzeltme, pilot ve zorlama sırasını izlemelidir.
- Etki alanı denetleyicileri, dosya sunucuları, AD CS, IIS uygulamaları ve yönetim servislerini envantere alın.
- NTLM kullanan istemci ve servisleri olay günlüklerinden belirleyin.
- İmzasız LDAP bind ve channel binding uyumsuzluklarını denetim modunda ölçün.
- SMB signing gerektirmeyen sunucu ve istemcileri raporlayın.
- Uyumsuz uygulamaları Kerberos, LDAPS+CBT veya modern kimlik doğrulamaya taşıyın.
- Önce düşük riskli OU ve sunucu gruplarında zorunlu politikayı pilotlayın.
- Kimlik doğrulama hatalarını, yardım masası çağrılarını ve güvenlik olaylarını izleyerek halkaları genişletin.
LDAP signing nedir?
LDAP signing, SASL ile kurulan LDAP mesajlarının bütünlüğünü doğrular. Etki alanı denetleyicisi imzalamayı zorunlu tuttuğunda imza istemeyen SASL LDAP bind işlemlerini ve şifrelenmemiş bağlantıdaki simple bind işlemlerini reddeder. Microsoft, LDAP signing ile channel binding’i ayrı kontroller olarak ele alır; birinin etkin olması diğerinin yerine geçmez.
Etki alanı denetleyicisindeki ilke Group Policy üzerinden Domain controller: LDAP server signing requirements ayarıyla yönetilir. Geçişte “None” durumundan doğrudan zorunlu moda geçmeden önce imzasız bağlanan istemciler belirlenmelidir. Uygulama sahibine kaynak IP, hesap, hedef DC ve zaman bilgisi verilmesi düzeltmeyi hızlandırır.
LDAP channel binding ve CBT
LDAPS trafiğinin şifreli olması tek başına relay’e karşı tam koruma sağlamaz. Channel Binding Token, içteki kimlik doğrulama bağlamını dıştaki TLS kanalına kriptografik olarak bağlar. Saldırgan iki ayrı TLS kanalı oluşturup doğrulama mesajını iletmeye çalıştığında kanal bilgisi uyuşmaz ve sunucu isteği reddedebilir.
Microsoft belgelerinde LDAP channel binding için LdapEnforceChannelBinding politikası ve olay günlükleri açıklanır. Uyumluluğu ölçmek için desteklenen denetim yaklaşımı kullanılmalı, ardından “When Supported” benzeri ara durumdan zorunlu doğrulamaya geçilmelidir. Denetim modu koruma sağlamaz; yalnız geçiş verisi üretir.
SMB signing
SMB signing, SMB mesajlarına bütünlük doğrulaması ekler ve relay saldırısının başka bir SMB oturumunda kullanılmasını zorlaştırır. Modern Windows sürümlerinde varsayılan davranış sürüme ve role göre değişebilir; kurum güvenliği varsayımlara değil, Group Policy sonuçlarına ve gerçek oturum telemetrisine dayanmalıdır.
Sunucu tarafında Microsoft network server: Digitally sign communications (always), istemci tarafında ise Microsoft network client: Digitally sign communications (always) ilkeleri değerlendirilir. Zorlama öncesinde SMBv1 kullanan eski sistemler ve signing desteklemeyen üçüncü taraf NAS/cihazlar bulunmalıdır. SMBv1 mümkünse tamamen kaldırılmalıdır.
CODE TERMINAL
Get-SmbServerConfiguration | Select EnableSecuritySignature,RequireSecuritySignature
Get-SmbClientConfiguration | Select EnableSecuritySignature,RequireSecuritySignatureBu komutlar mevcut yapılandırmayı okumak içindir. Sonuçlar GPO, Intune veya yapılandırma yönetimi kaynağıyla karşılaştırılmalı; yerel ayarın etki alanı politikasınca ezilip ezilmediği gpresult ile doğrulanmalıdır.
Extended Protection for Authentication
EPA, Windows Integrated Authentication kullanan servislerde kimlik doğrulamayı hizmet adına ve mümkün olduğunda TLS kanalına bağlar. Channel Binding Token ile dış TLS oturumu, NTLM veya Kerberos gibi iç doğrulama bağlamıyla ilişkilendirilir. Service Binding ise istemcinin amaçladığı servis adını doğrulamaya yardımcı olur.
IIS üzerinde Windows Authentication kullanan uygulamalarda EPA desteği uygulama ve barındırma mimarisine göre test edilmelidir. TLS sonlandıran reverse proxy veya yük dengeleyici varsa kanal bağlama davranışı özellikle önemlidir. Microsoft’un uygulamaya özgü belgesi görülmeden genel bir registry ayarı kopyalanmamalıdır.
AD CS neden ayrıca incelenmeli?
Active Directory Certificate Services web enrollment ve sertifika kayıt uçları, NTLM relay zincirlerinde yüksek etkili hedeflere dönüşebilir. IIS üzerinde HTTPS zorunluluğu, EPA, uygun kimlik doğrulama ayarları ve gereksiz web enrollment rollerinin kaldırılması savunmanın temel parçalarıdır. Sertifika şablonları da ayrı olarak incelenmeli; istemcinin SAN belirleyebilmesi, aşırı enrollment yetkileri ve ayrıcalıklı EKU kombinasyonları sınırlandırılmalıdır.
AD CS sertleştirmesi yalnız web sunucusu ayarı değildir. CA yöneticileri, Active Directory yöneticileri, PKI sahipleri ve uygulama ekipleri ortak değişiklik planı yürütmelidir. CA üzerinde yapılan her değişiklik önce test ortamında denenmeli ve kurtarma prosedürü doğrulanmalıdır.
NTLM kullanımını denetleme
NTLM’i bir anda kapatmak çoğu üretim ortamında gerçekçi değildir. Önce Network security: Restrict NTLM: Audit NTLM authentication in this domain ve ilgili gelen/giden trafik denetim ilkeleriyle kullanım haritası çıkarılabilir. Operational günlüklerdeki NTLM olayları merkezi SIEM’e gönderilmeli ve kaynak sistem, hedef servis, hesap türü ve uygulama sahibiyle zenginleştirilmelidir.
| Bulgu | Muhtemel neden | Düzeltme yönü |
|---|---|---|
| Kullanıcı hesabıyla sık NTLM | SPN/DNS sorunu veya eski uygulama | Kerberos akışını düzelt, SPN çakışmasını gider |
| Bilgisayar hesabıyla LDAP | Cihaz/ajan entegrasyonu | Signing ve CBT destekleyen sürüme yükselt |
| Dosya sunucusunda unsigned SMB | Eski NAS/istemci | Firmware yükselt, signing zorla veya izole et |
| IIS üzerinde NTLM | Windows Authentication yapılandırması | Kerberos ve EPA uyumluluğunu test et |
| Simple bind port 389 | Eski dizin entegrasyonu | LDAPS ve güvenli kimlik doğrulamaya taşı |
Kerberos’a geçişte SPN ve DNS
Bir uygulamanın Kerberos yerine NTLM’e düşmesi çoğu zaman “NTLM gerekli” olduğu anlamına gelmez. Yanlış DNS adı, eksik veya yinelenen Service Principal Name, IP adresiyle erişim, load balancer adı ve servis hesabı yapılandırması Kerberos’u bozabilir. Geçiş sırasında klist, setspn sorguları, olay günlükleri ve uygulama bağlantı adı birlikte incelenmelidir.
CODE TERMINAL
setspn -Q HTTP/uygulama.example.local
setspn -X
klist sessionsDeğişiklik yapmadan önce SPN sahibini ve uygulamanın çalıştığı hesabı doğrulayın. Yanlış hesaba SPN eklemek kimlik doğrulamayı bozabilir veya güvenlik riski oluşturabilir.
Kademeli GPO tasarımı
Tek bir “Domain Security” GPO’sunda tüm relay kontrollerini aynı anda zorlamak sorun gidermeyi güçleştirir. Ayrı politikalar; denetim, SMB signing istemci, SMB signing sunucu, LDAP signing ve NTLM kısıtlama olarak bölünebilir. Her GPO’nun amacı, kapsamı, sahibi, pilot grubu ve geri alma koşulu tanımlanmalıdır.
- Aşama 0 — Envanter: Salt okunur raporlama ve sahiplik eşleştirme
- Aşama 1 — Denetim: LDAP, NTLM ve SMB uyumsuzluk olaylarını merkezi toplama
- Aşama 2 — Pilot: BT cihazları ve düşük riskli sunucularda zorunlu imzalama
- Aşama 3 — Kritik servisler: DC, dosya sunucusu, AD CS ve yönetim uçları
- Aşama 4 — Genel dağıtım: İstemci ve sunucuların kalanına yayma
- Aşama 5 — Kısıtlama: İstisnaları süreli hale getirip NTLM kullanımını azaltma
SIEM için izlenecek sinyaller
Etki alanı denetleyicilerindeki Directory Service ve NTLM Operational günlükleri merkezi toplanmalıdır. İmzasız LDAP bind, channel binding token bulunmaması veya doğrulama hatası, NTLM kullanımında ani artış ve yeni kaynak cihaz gibi sinyaller alarm üretmelidir. Ancak zorlama öncesi dönemde yüksek hacim beklenebilir; alarm eşikleri varlık kritikliğine ve uygulama sahibine göre ayarlanmalıdır.
Başarılı relay’i tek bir Windows olayından kesin biçimde çıkarmak zordur. Ağ telemetrisi, kimlik doğrulama olayları, sertifika kayıtları, yeni grup üyelikleri ve yönetim protokolü etkinliği zaman çizelgesinde birleştirilmelidir. Özellikle aynı hesabın kısa aralıkla farklı kaynaklardan farklı servislere doğrulanması incelenmelidir.
İstisna yönetimi
Signing veya CBT desteklemeyen bir cihaz için kalıcı “çalışmıyor” istisnası açmak relay riskini yıllarca sürdürebilir. İstisna kaydında iş sahibi, teknik neden, ağ segmenti, erişebildiği hedefler, telafi edici kontroller, yükseltme planı ve son kullanma tarihi bulunmalıdır.
Desteklenmeyen cihaz ayrı VLAN’a alınmalı, etki alanı denetleyicilerine ve kritik sunuculara yalnız gerekli portlarda erişmeli, mümkünse farklı düşük yetkili hesap kullanmalı ve trafiği izlenmelidir. İstisna süresi dolduğunda otomatik inceleme bileti açılması yararlıdır.
Doğrulama kontrol listesi
- Pilot sistemlerde SMB signing’in hem istemci hem sunucu tarafında zorunlu olduğu doğrulandı mı?
- Etki alanı denetleyicileri imzasız LDAP bind işlemlerini reddediyor mu?
- LDAPS kullanan uygulamalar CBT ile sorunsuz doğrulanıyor mu?
- IIS ve AD CS uçlarında HTTPS ve EPA uygulamaya özgü belgelerle yapılandırıldı mı?
- NTLM denetim olayları SIEM’de kaynak, hedef ve sahip bilgisiyle görülebiliyor mu?
- Kerberos’a geçemeyen her uygulama için süreli istisna ve dönüşüm planı var mı?
- GPO sonucu gpresult ve gerçek bağlantı telemetrisiyle doğrulandı mı?
- Yardım masası ve olay müdahale ekipleri yeni hata modelleri için bilgilendirildi mi?
Sonuç
NTLM relay savunması tek bir registry anahtarından ibaret değildir. SMB signing, LDAP signing, LDAP channel binding, EPA, AD CS sertleştirmesi ve NTLM azaltma birlikte ele alınmalıdır. Başarılı programın ölçütü yalnız politikanın “Enabled” görünmesi değil; imzasız ve kanala bağlanmamış kimlik doğrulamanın kritik servislerce gerçekten reddedildiğinin, uyumsuz uygulamaların ise kontrollü biçimde dönüştürüldüğünün kanıtlanmasıdır.
Kaynaklar
- Microsoft Learn — LDAP signing for Active Directory Domain Services
- Microsoft Learn — LDAP session security and channel binding
- Microsoft Learn — Supporting Extended Protection for Authentication
- Microsoft Learn — SMB signing overview
- Microsoft Defender for Identity — Enforce SMB signing assessment
TR Siber Ekibi