SMB Signing Açık. Bu Grafikte Sadece Bir Kenarı Kapattı

Series · 4 partsInternal Network TriagePart 2 · You are here

1Kerberoasting Triyajı: Çoğu Servis Bileti Zaman Kaybıdır
2SMB Signing Açık. Bu Grafikte Sadece Bir Kenarı KapattıYou are here
3Kerberos Delegasyon Triyajı: Unconstrained, Constrained ve RBCD
4BloodHound Edge Analizi: Çizge Var, Peki Saldırı Yolu Kanıtı Nerede?

60 saniyede NTLM relay

“SMB signing tüm ortamda zorunlu kılındı” cümlesi genellikle relay tartışmalarının bittiği yerdir. Bu gerçek bir iyileştirmedir ve somut bir saldırıyı engeller. Ancak bu durum, konu tamamen çözülmüş gibi ele alınır; oysa çözülmemiştir. Çünkü imzalama (signing), domain’in genel bir özelliği değildir; her protokolün kendi özelinde geçerli olan bir niteliktir.

Relay bir çizge (graph) problemidir. İmzalama kenarları (edges) ortadan kaldırır. Çizgenin kendisini ortadan kaldırmaz.

İmzalama aslında neyi korur?

Bir NTLM relay saldırısı iki şeye ihtiyaç duyar: yakalayabileceğiniz bir kimlik doğrulama (authentication) ve bunun yeniden oynatıldığını (replayed) fark etmeden kabul edecek bir hedef. Mesaj imzalama (message signing) bu sürecin ikinci yarısını bozar — oturum orijinal alışverişe bağlandığı için relay edilen handshake başarısız olur.

Buradaki kritik nokta, her protokolün buna kendi başına karar vermesi ve henüz ortak bir standartta buluşmamış olmalarıdır:

SMB, uzun süredir imzalama desteğine sahiptir. Domain controller’lar bunu varsayılan olarak zorunlu tutar. Üye sunucular (member servers) ve iş istasyonları tarihsel olarak bunu zorunlu tutmazdı; relay listelerinin çoğunlukla diğer çalışanların dizüstü bilgisayarlarından oluşmasının nedeni buydu. Güncel Windows sürümleri artık hem istemci hem de sunucu tarafında imzalamayı varsayılan olarak etkinleştirmeye başladı; dolayısıyla klasik SMB-to-SMB kenarı gerçekten kapanıyor — ancak yavaşça ve yalnızca cihaz filosu yenilendikçe.

LDAP ise işin ilginç kısmıdır; çünkü insanların birbirine karıştırdığı iki ayrı kontrole sahiptir: İmzalama (signing), 389 portundaki düz LDAP’ı kapsar. Channel binding ise 636 portundaki LDAPS’ı kapsar. Birini etkinleştirip diğerini de kapsadığını varsaymak oldukça yaygındır ve oluşan bu boşluk, relay edilen kimlik doğrulamanın tam olarak indiği yerdir.

HTTP, NTLM’i hiçbir şekilde imzalayamaz. Şemanın içinde bir imzalama mekanizması yoktur. NTLM kabul eden bir HTTP endpoint’i bir relay hedefidir ve her zaman öyle kalacaktır; tek koruma TLS tarafındaki channel binding’dir.

Bu son satır, zafiyetin sıkılaştırma programlarından neden sağ çıktığını açıklar. Emek; anlaşılır olan ve bir GPO’su bulunan SMB’ye harcanır; hiçbir koruması olmayan protokol ise kimsenin önünde bir onay kutusu (checkbox) bulunmayan protokoldür.

İmzalama protokol bazında belirlenir. SMB'yi kapatmak yalnızca bir kenarı ortadan kaldırır; zorlama (coercion) basitçe imzalama yapamayan bir taşıma protokolüne geçer ve kendi imzalaması ertelenmiş bir hedefe ulaşır.

İçselleştirilmesi gereken asimetri

Relay protokoller arasıdır (cross-protocol). SMB’yi SMB’ye relay etmek zorunda değilsiniz.

Verimli yön; imzalama yapamayan bir protokol üzerinden gelen (inbound), imzalamanın zorunlu kılınmadığı bir protokole giden (outbound) yöndür. Kimlik doğrulamayı HTTP üzerinden zorlayın (coerce), bunu LDAP’a relay edin; SMB signing bu sürecin hiçbir noktasında denkleme dahil olmaz.

Bu durum WebClient servisini, iç ağ değerlendirmelerinde değeri en az bilinen tekil öğe haline getirir. Bir Windows host’unun WebDAV konuşmasını sağlayan şey budur; sunucularda varsayılan olarak kapalıdır ancak iş istasyonlarında sıklıkla çalışır ve genellikle uzaktan başlatılabilir. WebClient’ın çalıştığı bir host, kimlik doğrulamasını HTTP üzerinden —tasarımı gereği imzasız olarak— elde edebileceğiniz bir host’tur.

Triyaj: Sırasıyla üç soru

Herkesin ürettiği tarama çıktısı, SMB signing bulunmayan host’ların bir listesidir. Bu, tek bir protokolün tek bir kenarıdır. Bulguyu asıl şekillendiren üç soru şunlardır:

1. Neyi zorlayabilirim ve hangi protokol üzerinden? “Zorlayabilir miyim (coerce)?” değil — zorlama primitive’leri zaten iyi bilinmektedir. Ortaya çıkan kimlik doğrulamasının hangi taşıma (transport) katmanında ulaştığı, akıştaki sonraki her şeyi belirler.

2. Hangi hedefler bunu imzasız kabul ediyor? Host bazında değil, protokol bazında. LDAP ve LDAPS ayrı yanıtlardır.

3. Bu hedef bana ne yapma izni veriyor? Bir iş istasyonu hesabı olarak LDAP’a relay etmek, bir domain controller hesabı olarak relay etmekle aynı şey değildir. Yakaladığınız kimlik, elde edeceğiniz sonucun tavan sınırıdır.

İlk ikisi için numaralandırma (enumeration) oldukça hızlıdır:

# İmzalanmamış SMB'ye hâlâ izin veren host'lar — tanıdık liste ve en az faydalı olanı
$ nxc smb 10.0.0.0/24 --gen-relay-list relay-targets.txt

# Genellikle atlanan soru: LDAP signing ve channel binding zorunlu mu?
$ nxc ldap dc01.lab.local -u svc-audit -p '...' -M ldap-checker
LDAP-CHECKER  dc01.lab.local  LDAP signing NOT enforced
LDAP-CHECKER  dc01.lab.local  LDAPS channel binding is set to "never"

# Hangi host'lar WebDAV konuşacak — yani HTTP üzerinden imzasız kimlik doğrulama teslim edecek
$ nxc smb 10.0.0.0/24 -u svc-audit -p '...' -M webdav
WEBDAV  10.0.0.51  WebClient service is running

Üç satır; ve üçüncü satır, ilkinin bir önemi olup olmadığını belirleyen satırdır.

Bunun dönüştüğü sonuç

İmzasız LDAP ve bir HTTP zorlama kaynağı ile relay saldırısının SMB’ye hiç ihtiyacı kalmaz:

$ ntlmrelayx.py -t ldap://dc01.lab.local --delegate-access --no-smb-server -smb2support
[*] Servers started, waiting for connections
[*] HTTPD: Received connection from 10.0.0.51
[*] Authenticating against ldap://dc01.lab.local as LAB/WS02$ SUCCEED
[*] Delegation rights modified successfully!
[*] WS02$ can now impersonate users on WS02$ via S4U2Proxy

Delegasyon notunu okuduysanız bu son satır tanıdık gelmelidir — relay’in çıktısı bir RBCD yazma işlemidir. Bu iki bulgu, farklı kılıklara bürünmüş aynı bulgudur: bir bilgisayar nesnesine yazabilecek bir şey ve o şeye dönüşmeye giden bir saldırı yolu.

Kanıt matrisi (Evidence matrix)

Sinyal	Neyi kanıtlar	Negatif kontrol	Savunucu doğrulaması
Kaynak, HTTP/WebClient üzerinden bir kimlik doğrulama tetikleyicisini kabul eder	Zorlanabilen bir kimlik bilgisi, relay edilebilir bir taşıma katmanı üzerinden kaynaktan ayrılabilir	Lab kaynağında WebClient’ı devre dışı bırakın ve HTTP kenarının kaybolduğunu doğrulayın	Host rolüne göre WebClient durumunun ve kimlik doğrulama yeteneğine sahip HTTP yüzeylerinin envanterini çıkarın
LDAP hedefi, test edilen yol için signing veya channel binding gerektirmez	Hedef, relay edilen NTLM’i orijinal kanala bağlamadan kabul edecektir	İlgili LDAP kontrolünü zorunlu kılın ve relay’in başarısız olmasını bekleyin	Domain controller politikasını doğrulayın ve yalnızca kayıt defteri (registry) değerini değil, ret olayını da (reject event) yakalayın
Kontrollü relay, geri döndürülebilir bir RBCD veya eşdeğer yazma işlemi gerçekleştirir	Kaynak ve hedef kenarları operasyonel bir zincir halinde birleşir	Özniteliği (attribute) geri yükleyin ve sıkılaştırılmış bir hedefe karşı tekrarlayın	Dizin yazma işlemlerini denetleyin; kaynak zorlamasını, relay host’unu ve değiştirilen nesneyi birbiriyle ilişkilendirin
HTTP-to-LDAP başarılı olurken SMB-to-SMB relay başarısız olur	SMB signing bir kenarı kapatmıştır ancak relay sınıfını kapatmamıştır	SMB’den genel çıkarım yapmak yerine her protokol çiftini ayrı ayrı test edin	Kaynaklar, taşıma katmanları ve hedefler için bir protokol çifti matrisi tutun

Sürekli gördüğüm model

İmzalama, bitiş tarihi olan bir proje olarak dağıtılır. Kapsamı SMB ile sınırlanır çünkü rehberlerin yazıldığı yer SMB’dir; dağıtım yapılır, bilet (ticket) kapatılır ve ortam düzeltilmiş olarak kaydedilir. LDAP signing ertelenir çünkü eski (legacy) bind işlemlerini bozar ve birinin önce bunları bulması gerekir. Channel binding de aynı nedenle ertelenir. WebClient konusu ise hiçbir zaman gündeme gelmez; çünkü o bir güvenlik kontrolü değildir ve kimse envanterini tutmaz.

İki yıl sonra relay bulgusu geri gelir ve bir regresyon (gerileme) gibi görünür. Oysa hiçbir zaman bir regresyon olmamıştır. Kapanan kenar kapalı kalmıştır; rapor sadece tek bir kenarı, tüm çizgenin kendisiymiş gibi tarif etmiştir.

Savunuculara teslim edilmesi gerekenler

Tüm ortam genelinde değil, protokol bazında raporlayın. SMB signing zorunlu, LDAP signing zorunlu değil, LDAPS channel binding kapalı. Üç durum, üç sahip, üç bilet. “NTLM relay mümkündür” diyen tek bir satır, SMB dağıtımı gösterilerek kolayca kapatılır.

Zorlama taşıma katmanını açıkça adlandırın. Saldırı yolu HTTP üzerinden geçtiyse bunu açıkça belirtin; çünkü bu hangi hafifletmenin (mitigation) geçerli olduğunu değiştirir ve henüz gerçekleşmeden “ama imzalama açık” yanıtının önünü keser.

WebClient kolay ve ucuz kazanımdır. İş istasyonlarının ezici çoğunluğunda buna ihtiyaç yoktur; devre dışı bırakılması imzasız HTTP kaynağını tamamen ortadan kaldırır ve LDAP sıkılaştırmasının aksine, önce eski bağımlılıkları avlamayı gerektirmez.

Ardından kalıcı olanı ele alın. Channel binding ve LDAP signing zorunlu kılınmalı ve NTLM’in emekliye ayrılabileceği yerlerde emekliye ayrılması için bir plan yapılmalıdır. Bu yavaş ilerleyen bir iştir; bu çeyrekte yapılabilecek şeylerden ayrı bir bulgu olması tam olarak bu yüzdendir.

Kaynaklar ve güncellik

Bu teknik not ne kadar güncel?

Kontrol edilen kaynaklar11 Eylül 2025

En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.

İnceleme DurumuYazar incelemesi tamamlandı

Yazar teknik incelemeyi tamamladı. Bu etiket tek başına laboratuvar yeniden üretimi iddiası taşımaz.

Birincil referanslar