Windows Event Forwarding (WEF) ile NTLMv1 İzleme: Adım Adım Kurulum ve Yapılandırma Rehberi

Kurumsal Active Directory ortamlarında güvenlik seviyesini artırmaya yönelik en önemli çalışmalardan biri, eski kimlik doğrulama protokollerinin kullanımını tespit ederek modern ve daha güvenli yöntemlere geçiş sağlamaktır. Bu kapsamda özellikle NTLMv1 protokolü, günümüzde güvenlik açısından yetersiz kabul edilmekte ve mümkün olan tüm ortamlarda tamamen devre dışı bırakılması önerilmektedir.

Ancak NTLMv1’i doğrudan devre dışı bırakmak, bu protokolü kullanan eski uygulamalar, cihazlar veya servisler nedeniyle beklenmedik kesintilere yol açabilir. Bu nedenle en doğru yaklaşım, öncelikle NTLMv1 kullanan sistemleri tespit etmek, gerekli analizleri yapmak ve sonrasında kademeli olarak bu protokolü ortamdan kaldırmaktır.

Bu noktada Windows Event Forwarding (WEF), herhangi bir üçüncü taraf yazılıma ihtiyaç duymadan Windows istemcileri, üye sunucular ve Domain Controller’lar üzerinde oluşan güvenlik olaylarını merkezi bir sunucuda toplayarak analiz edebilmemizi sağlayan güçlü ve ücretsiz bir Windows bileşeni olarak öne çıkmaktadır. WEF sayesinde NTLMv1 kullanımına ilişkin olaylar merkezi olarak izlenebilir, raporlanabilir ve güvenlik ekipleri tarafından kolayca analiz edilebilir.

Bu makalede, sıfırdan bir Windows Event Forwarding (WEF) altyapısının nasıl kurulacağı, Collector ve Source Computer yapılandırmalarının nasıl gerçekleştirileceği, gerekli Group Policy ayarlarının nasıl uygulanacağı ve XPath sorguları kullanılarak NTLMv1 kimlik doğrulama olaylarının nasıl toplanacağı adım adım ele alınacaktır. Ayrıca kurulum sırasında karşılaşılabilecek yaygın hatalar, bu hataların nedenleri ve çözüm yöntemleri de örneklerle açıklanacaktır.

Makalenin sonunda, yalnızca NTLMv1 kullanımını merkezi olarak izleyebilen bir WEF altyapısı kurmuş olmakla kalmayacak, aynı zamanda NTLM hardening projelerinde kullanılabilecek, ölçeklenebilir ve üretim ortamlarına uygun bir izleme altyapısını da hayata geçirmiş olacaksınız.

Gereksinimler

Windows Event Forwarding (WEF) altyapısını kurmaya başlamadan önce ortamın belirli ön koşulları karşılaması gerekmektedir. Bu gereksinimlerin sağlanması, kurulum sürecinin sorunsuz ilerlemesini ve olay günlüklerinin güvenilir şekilde merkezi olarak toplanmasını sağlayacaktır.

İşletim Sistemi Gereksinimleri

WEF Collector sunucusu ile olay gönderecek istemci ve sunucuların Windows Event Forwarding özelliğini destekleyen bir Windows sürümü çalıştırıyor olması gerekmektedir.

Desteklenen işletim sistemleri;

• Windows Vista ve üzeri tüm istemci işletim sistemleri
• Windows Server 2008 ve üzeri tüm Windows Server sürümleri

Her ne kadar eski sürümler desteklense de üretim ortamlarında Windows Server 2022 veya Windows Server 2025 kullanılması tavsiye edilmektedir.

Ağ Bağlantısı

WEF altyapısının sağlıklı çalışabilmesi için Collector sunucusu ile kaynak bilgisayarlar arasında ağ erişimi bulunmalıdır.

Temel gereksinimler;

• DNS isim çözümlemesinin çalışıyor olması
• WinRM (WSMAN) iletişimi için TCP 5985 portunun açık olması
• Gerekli Windows Firewall kurallarının etkin olması
• Domain ortamlarında Kerberos kimlik doğrulamasının kullanılabiliyor olması

WEF, varsayılan olarak WinRM (Windows Remote Management) servisi üzerinden HTTP 5985 portunu kullanarak olayları güvenli şekilde Collector sunucusuna iletir.

Yetkiler

Kurulum sırasında aşağıdaki yetkiler gerekmektedir.

• WEF Collector sunucusunda yerel yönetici (Local Administrator) yetkisi
• Kaynak bilgisayarlarda yerel yönetici (Local Administrator) yetkisi
• Group Policy oluşturabilmek veya düzenleyebilmek için gerekli Active Directory yetkileri

WEF kurulumu için sürekli Domain Admin yetkisine ihtiyaç duyulmaz. Gerekli Group Policy yapılandırmaları tamamlandıktan sonra sistem normal kullanıcı hakları ile çalışmaya devam eder.

Kaynak Bilgisayar Yapılandırması

Olayların merkezi olarak toplanabilmesi için kaynak bilgisayarlarda aşağıdaki yapılandırmaların uygulanması gerekmektedir.

• WinRM servisinin etkin olması
• Event Forwarding Group Policy ayarlarının uygulanması
• Güvenlik olaylarının (Security Log) oluşturulabilmesi için gerekli denetim (Audit) politikalarının etkin olması
• İlgili Event Log kanallarının erişilebilir durumda olması

Ayrıca yalnızca ihtiyaç duyulan olayların toplanması amacıyla uygun XPath filtrelerinin kullanılması önerilmektedir.

Donanım Gereksinimleri

Collector sunucusunun donanım ihtiyacı, ortamdaki istemci sayısı ve günlük olay hacmine göre değişiklik gösterebilir. Küçük ve orta ölçekli ortamlar için aşağıdaki yapılandırma önerilmektedir.

Bileşen	Önerilen Değer
İşlemci	En az 4 çekirdek
Bellek	En az 16 GB RAM
İşletim Sistemi Diski	En az 80 GB SSD
Depolama	SSD önerilir
Ağ	En az 1 Gbps Ethernet

SSD kullanılması özellikle Forwarded Events günlüğüne yapılan yoğun yazma işlemleri nedeniyle önemli ölçüde performans artışı sağlayacaktır.

Collector Kapasitesi

Microsoft’un önerilerine göre tek bir Windows Event Collector sunucusu yaklaşık 4.000 istemciden olay toplayabilecek kapasiteye sahiptir.

Ortamdaki istemci sayısının bu değeri aşması durumunda;

• Birden fazla Collector sunucusu kurulması,
• Yükün Collector sunucuları arasında dağıtılması,
• Merkezi izleme altyapısının ölçeklendirilmesi

önerilmektedir.

Performans Güncellemeleri

Windows Server 2016 ve Windows Server 2019 için Windows Event Forwarding performansını artıran bazı güncellemeler yayınlanmıştır.

İşletim Sistemi	Güncelleme
Windows Server 2016	KB4537806
Windows Server 2019	KB4537818

Bu güncellemeler normal Windows Update süreci kapsamında yüklenebilmektedir ve WEF performansını artırdığı için üretim ortamlarında uygulanması tavsiye edilmektedir.

Not: Windows Server 2022 ve Windows Server 2025 sürümlerinde bu güncellemeler ilgili işletim sistemi sürümlerine entegre edilmiştir. Bu nedenle ayrıca yüklenmeleri gerekmez.

Windows Server 2016/2019 İçin WinRM Collector Yapılandırması

Windows Event Forwarding (WEF) altyapısında Windows Event Collector (WEC) ve Windows Remote Management (WinRM) servisleri, olayların merkezi Collector sunucusuna iletilmesini sağlayan temel bileşenlerdir.

Windows Server 2016 ve Windows Server 2019 sürümlerinde bu iki servis, HTTP URL Reservation (URL ACL) adı verilen rezervasyonları kullanarak 5985 (HTTP) ve 5986 (HTTPS) portları üzerinden iletişim kurmaktadır.

Windows Server 2016’da varsayılan olarak WinRM ve WEC servisleri aynı svchost.exe işlemi içerisinde çalıştığından herhangi bir sorun yaşanmaz. Ancak servislerin farklı süreçlerde çalışacak şekilde yapılandırılması durumunda Windows Event Collector (WecSvc) servisi ilgili URL rezervasyonlarına erişemeyebilir ve Windows Event Forwarding çalışmayı durdurabilir.

Windows Server 2019’da ise sistem belleğinin 3,5 GB üzerinde olması durumunda WinRM ve WEC servisleri varsayılan olarak farklı svchost.exe süreçlerinde çalıştırılmaktadır. Bu nedenle bazı ortamlarda WEF Collector sunucusu olayları kabul edemeyebilir.

Bu problemi gidermek amacıyla Microsoft, aşağıdaki URL ACL yapılandırmasının uygulanmasını önermektedir.

netsh http delete urlacl url=http://+:5985/wsman/
netsh http add urlacl url=http://+:5985/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)

netsh http delete urlacl url=https://+:5986/wsman/
netsh http add urlacl url=https://+:5986/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)

Bu değişiklik uygulandıktan sonra WinRM servisi veya sunucu yeniden başlatılmalıdır.

Mevcut URL Reservation yapılandırmasını görüntülemek için aşağıdaki komut kullanılabilir.

netsh http show urlacl

Windows Server 2022 ve Windows Server 2025 İçin Not

Bu düzeltme yalnızca Windows Server 2016 ve Windows Server 2019 sistemleri ile bu sürümlerden Windows Server 2022’ye yükseltilmiş (in-place upgrade) sunucular için geçerlidir.

Temiz (Clean Installation) Windows Server 2022 ve Windows Server 2025 kurulumlarında bu URL ACL kayıtları işletim sistemi tarafından otomatik olarak oluşturulduğu için bu komutların çalıştırılmasına gerek yoktur.

Kurulum öncesinde aşağıdaki komut ile mevcut yapılandırmanın kontrol edilmesi önerilir.

netsh http show urlacl | findstr /i wsman

Çıktıda aşağıdaki kayıtların bulunması yeterlidir.

http://+:5985/wsman/
https://+:5986/wsman/

Bu kayıtlar mevcutsa URL ACL yapılandırmasının yeniden oluşturulmasına gerek yoktur.

Windows Event Collector (WEC) Kurulumu

Windows Event Collector (WEC), Windows Event Forwarding altyapısının merkezinde yer alan bileşendir. Domain içerisindeki istemci ve sunuculardan gönderilen olay günlüklerini kabul eder, Forwarded Events günlüğünde saklar ve merkezi olarak analiz edilmesini sağlar.

Bir sonraki bölümde Windows Event Collector sunucusunun hazırlanması, WinRM yapılandırması, gerekli servislerin etkinleştirilmesi ve WEF Subscription oluşturulması adım adım ele alınacaktır.

WinRM Yapılandırmasının Doğrulanması

Windows Event Forwarding (WEF) altyapısının çalışabilmesi için Collector sunucusunda Windows Remote Management (WinRM) servisinin doğru yapılandırıldığının doğrulanması gerekir.

Aşağıdaki komut ile WinRM yapılandırmasını görüntüleyebilirsiniz.

winrm get winrm/config

Kontrol edilmesi gereken başlıca ayarlar şunlardır:

• HTTP Port : 5985
• HTTPS Port : 5986
• Kerberos Authentication : True
• Negotiate Authentication : True
• AllowRemoteAccess : True

Bu değerler WinRM servisinin WEF istemcilerinden gelecek bağlantıları kabul edecek şekilde yapılandırıldığını göstermektedir.

Windows Güvenlik Duvarı Kuralının Doğrulanması

WinRM trafiğinin Collector sunucusuna ulaşabilmesi için ilgili Windows Firewall kuralının etkin olması gerekmektedir.

Aşağıdaki PowerShell komutu ile Domain profili için Windows Remote Management (HTTP-In) kuralı kontrol edilebilir.

Get-NetFirewallRule |
Where-Object {$_.DisplayName -Like "Windows Remote Management (HTTP-In)*" -and $_.Profile -like "*Domain*"} |
Select Enabled

Komut çıktısında True değeri görülüyorsa gerekli güvenlik duvarı kuralı etkin durumdadır.

WinRM Servisinin Doğrulanması

Windows Event Forwarding (WEF) altyapısının çalışabilmesi için Windows Remote Management (WinRM) servisinin otomatik olarak başlaması gerekmektedir.

Aşağıdaki komut ile WinRM servisinin başlangıç türü kontrol edilir.

Get-Service -Name WinRM | Select StartType

Beklenen çıktı aşağıdaki gibidir.

StartType
---------
Automatic

Eğer WinRM yapılandırılmamışsa aşağıdaki komut çalıştırılarak PowerShell Remoting etkinleştirilebilir.

Enable-PSRemoting

Bu komut gerekli WinRM yapılandırmasını gerçekleştirir, servis ayarlarını düzenler ve PowerShell uzaktan yönetim özelliğini etkinleştirir.

HTTP URL Reservation (URL ACL) Kontrolü

WEF Collector sunucusunda WinRM servisinin kullandığı HTTP URL Reservation (URL ACL) kayıtlarının doğru oluşturulduğu doğrulanmalıdır.

Aşağıdaki komut mevcut URL Reservation kayıtlarını görüntüler.

netsh http show urlacl

Özellikle aşağıdaki kayıtların bulunması beklenmektedir.

http://+:5985/wsman/
https://+:5986/wsman/

Bu kayıtlar WinRM servisinin HTTP ve HTTPS üzerinden gelen bağlantıları kabul edebilmesi için gereklidir.

Enable-PSRemoting

Windows Event Collector (WEC) Servisinin Etkinleştirilmesi

WinRM yapılandırması tamamlandıktan sonra Windows Event Collector (WEC) servisi etkinleştirilmelidir.

Bunun için Event Viewer konsolu açılır ve sol menüden Subscriptions bölümü seçilir.

İlk kez erişildiğinde aşağıdaki uyarı görüntülenir.

“Windows Event Collector Service must be running and configured…”

Bu uyarı, Windows Event Collector servisinin henüz etkin olmadığını belirtmektedir.

Yes butonuna tıklanarak servis otomatik olarak başlatılır ve başlangıç türü Automatic olarak yapılandırılır.

Bu işlem aynı zamanda wecutil qc komutunun gerçekleştirdiği temel yapılandırmayı grafik arayüz üzerinden uygulamaktadır.

Yeni Bir WEF Subscription Oluşturulması

Collector servisi etkinleştirildikten sonra Subscriptions bölümüne sağ tıklanarak Create Subscription seçeneği seçilir.

Bu işlem, istemci ve sunuculardan toplanacak olayların merkezi olarak yönetileceği yeni bir Windows Event Forwarding aboneliği oluşturur.

Subscription Yapılandırması

Yeni oluşturulan abonelikte öncelikle anlamlı bir isim belirlenmelidir. Bu makalede NTLMv1 kimlik doğrulama olaylarının izlenmesi amaçlandığından abonelik adı Ntlmv1 olarak belirlenmiştir.

Ardından aşağıdaki yapılandırmalar uygulanır.

• Destination Log: Forwarded Events
• Subscription Type: Source Computer Initiated

Source Computer Initiated yöntemi, Group Policy ile yapılandırılan istemci ve sunucuların Collector sunucusuna kendilerinin bağlanarak olay günlüklerini iletmesini sağlar. Microsoft tarafından büyük ölçekli ortamlarda önerilen yöntem de budur.

Sonraki adımlarda;

• Olay gönderecek bilgisayar grupları tanımlanacak,
• Toplanacak güvenlik olayları (Event Filter) belirlenecek,
• İleri düzey teslim ayarları (Advanced Settings) yapılandırılacaktır.

Neden Source Computer Initiated?
Bu yöntemde Collector sunucusunun istemcilere tek tek bağlanmasına gerek kalmaz. Kaynak bilgisayarlar Group Policy üzerinden Collector bilgilerini alır ve olay günlüklerini otomatik olarak iletir. Bu yapı hem daha ölçeklenebilir hem de binlerce istemcinin bulunduğu ortamlarda yönetimi önemli ölçüde kolaylaştırır.

Kaynak Bilgisayar Gruplarının Belirlenmesi

Windows Event Forwarding altyapısında olay gönderecek bilgisayarlar Select Computer Groups seçeneği kullanılarak belirlenir.

Bu makalede hem istemci bilgisayarlar hem de Domain Controller’lardan güvenlik olaylarının toplanması amaçlandığından aşağıdaki iki varsayılan Active Directory grubu aboneliğe eklenmiştir.

• Domain Computers
• Domain Controllers

Önemli: Domain Controller’lar, Domain Computers grubunun üyesi değildir. Bu nedenle yalnızca Domain Computers grubunun eklenmesi Domain Controller’lardan olay toplanması için yeterli değildir. Domain Controller’ların da ayrıca aboneliğe dahil edilmesi gerekmektedir.

Bu yapılandırma sayesinde Group Policy ile yapılandırılan tüm istemci bilgisayarlar, üye sunucular ve Domain Controller’lar Collector sunucusuna olay günlüklerini otomatik olarak iletecektir.

Gelişmiş Ayarlarının Yapılandırılması

Advanced menüsünde olayların Collector sunucusuna hangi sıklıkla gönderileceği belirlenir.

Windows Event Forwarding üç farklı teslim modeli sunmaktadır.

• Normal – Olaylar yaklaşık 15 dakikada bir gönderilir.
• Minimize Bandwidth – Ağ trafiğini azaltmak amacıyla olaylar yaklaşık 6 saatte bir gönderilir.
• Minimize Latency – Olaylar yaklaşık 30 saniye içerisinde Collector sunucusuna iletilir.

Bu makalede NTLMv1 kimlik doğrulama olaylarının mümkün olan en kısa sürede merkezi olarak görüntülenebilmesi amacıyla Minimize Latency seçeneği tercih edilmiştir.

İletişim protokolü olarak ise varsayılan HTTP yapılandırması kullanılmıştır.

Olay Filtresinin XML Modunda Düzenlenmesi

Windows Event Viewer, temel filtreleme işlemlerini grafik arayüz üzerinden gerçekleştirebilmektedir. Ancak NTLMv1 kimlik doğrulama olaylarını tespit edebilmek için gelişmiş XPath sorgularının kullanılması gerekmektedir.

Bu nedenle Select Events ekranında XML sekmesine geçilir ve Edit query manually seçeneği işaretlenir.

İlk kez manuel düzenleme etkinleştirildiğinde aşağıdaki uyarı görüntülenir.

“If you choose to manually edit the query…”

Bu uyarı, sorgu manuel olarak düzenlendikten sonra grafik filtreleme ekranının artık kullanılamayacağını belirtmektedir.

Yes seçeneği ile devam edilir.

NTLMv1 XPath Filtresinin Eklenmesi

Manuel düzenleme etkinleştirildikten sonra NTLMv1 kimlik doğrulama olaylarını filtreleyen XPath sorgusu XML alanına eklenir.

Bu sorgu;

• 4624 (Successful Logon) güvenlik olaylarını filtreler,
• LmPackageName alanında NTLM V1 veya LM kullanan kimlik doğrulamalarını seçer,
• ANONYMOUS LOGON kayıtlarını ise sonuçlardan hariç tutar.

Bu sayede yalnızca NTLMv1 kullanan gerçek kullanıcı oturumları Collector sunucusundaki Forwarded Events günlüğüne iletilir.

Not: XPath sorgularının yazımı oldukça hassastır. Hatalı veya desteklenmeyen bir sorgu kullanılması durumunda Subscription durumu Inactive olabilir ve 0x138C – Query returns no active channel hatası alınabilir. Bu nedenle XML sorgusunun test edilmesi ve üretim ortamına uygulanmadan önce doğrulanması önerilir.

Forwarded Events Günlüğünün Yapılandırılması

Collector sunucusunda olayların uzun süre saklanabilmesi ve yüksek hacimli ortamlarda kayıt kaybının önlenebilmesi için Forwarded Events günlüğünün yapılandırılması önerilmektedir.

Bu makalede günlük boyutu 1 GB olarak belirlenmiş ve günlük dolduğunda otomatik arşivleme etkinleştirilmiştir.

Aşağıdaki komutlar kullanılarak bu yapılandırma gerçekleştirilebilir.

wevtutil sl ForwardedEvents /ms:1000000000
wevtutil sl ForwardedEvents /ab:true /rt:true

Bu komutların işlevleri aşağıdaki gibidir.

• /ms : Günlüğün maksimum boyutunu belirler.
• /ab:true : Günlük dolduğunda otomatik arşivleme yapar.
• /rt:true : Günlüğün kayıtları üzerine yazmak yerine arşivleyerek saklanmasını sağlar.

Yapılandırma aşağıdaki komut ile doğrulanabilir.

wevtutil gl ForwardedEvents

Bu yapılandırma özellikle yoğun olay üreten ortamlarda geçmiş kayıtların korunmasını sağlayarak daha güvenilir bir denetim altyapısı oluşturur.

WEF İstemcileri İçin Group Policy Oluşturulması

Collector sunucusundaki yapılandırma tamamlandıktan sonra olay gönderecek bilgisayarlar için ayrı bir Group Policy Object (GPO) oluşturulmalıdır.

Bu makalede iki farklı GPO kullanılmıştır.

• WEF Clients
• WEF Domain Controllers

Bu sayede istemciler, üye sunucular ve Domain Controller’lar için gerekli ayarlar merkezi olarak yönetilebilmektedir.

Event Log Readers Grubunun Yapılandırılması

Kaynak bilgisayarların Security Event Log’unu okuyabilmesi için NETWORK SERVICE hesabının Event Log Readers grubuna üye olması gerekmektedir.

Bunun için aşağıdaki konum izlenir.

Computer Configuration
 └─ Policies
     └─ Windows Settings
         └─ Security Settings
             └─ Restricted Groups

Burada Event Log Readers grubu oluşturulur ve grup üyelerine aşağıdaki hesap eklenir.

NETWORK SERVICE

Bu yapılandırma Windows Event Forwarding servisinin Security Event Log kayıtlarını okuyabilmesi için kritik öneme sahiptir.

Windows Event Collector Servisinin Yapılandırılması

WEF istemcilerinin olayları Collector sunucusuna iletebilmesi için Windows Event Collector servisinin çalışır durumda olması gerekir.

Bu nedenle aşağıdaki Group Policy ayarı yapılandırılır.

Computer Configuration
 └─ Policies
     └─ Windows Settings
         └─ Security Settings
             └─ System Services

Servis başlangıç türü aşağıdaki şekilde ayarlanmalıdır.

Windows Event Collector
Startup Type : Automatic

Bu sayede servis sistem açılışında otomatik olarak başlatılır.

WEF Kaynak Bilgisayar Performans Ayarı

Çok sayıda istemcinin bulunduğu ortamlarda kaynak bilgisayarların Collector sunucusuna göndereceği olay sayısı sınırlandırılabilir.

Bu ayar aşağıdaki konumdan yapılandırılır.

Computer Configuration
 └─ Policies
     └─ Administrative Templates
         └─ Windows Components
             └─ Event Forwarding

Configure forwarder resource usage politikası etkinleştirilerek saniyede gönderilebilecek maksimum olay sayısı belirlenebilir.

Bu makalede değer aşağıdaki şekilde yapılandırılmıştır.

Maximum Forwarding Rate : 500 Events / Second

Bu ayar özellikle yüksek hacimli ortamlarda Collector sunucusunun aşırı yüklenmesini önlemeye yardımcı olur.

Not: Küçük ve orta ölçekli ortamlarda varsayılan yapılandırma çoğu zaman yeterlidir. Bu politika daha çok binlerce istemcinin bulunduğu büyük kurumsal ortamlarda performans optimizasyonu amacıyla kullanılmaktadır.

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

NTLM Denetim Politikalarının Yapılandırılması

NTLMv1 kimlik doğrulama olaylarının doğru şekilde oluşturulabilmesi için ilgili güvenlik politikalarının Group Policy üzerinden etkinleştirilmesi gerekmektedir.

Bu ayarlar aşağıdaki konumda yer almaktadır.

Computer Configuration
 └─ Policies
     └─ Windows Settings
         └─ Security Settings
             └─ Local Policies
                 └─ Security Options

Audit Incoming NTLM Traffic

İlk olarak aşağıdaki politika etkinleştirilir.

Network Security: Restrict NTLM: Audit Incoming NTLM Traffic

Politika değeri aşağıdaki şekilde yapılandırılır.

Enable auditing for domain accounts

Bu ayar, bilgisayara gelen NTLM kimlik doğrulama isteklerinin Security Event Log içerisine kaydedilmesini sağlar.

Uygulama Kapsamı: Tüm domain üyeleri (İstemci bilgisayarlar, üye sunucular ve Domain Controller’lar)

Audit Outgoing NTLM Traffic

Daha sonra aşağıdaki politika etkinleştirilir.

Network Security: Restrict NTLM: Outgoing NTLM Traffic to Remote Servers

Politika değeri aşağıdaki şekilde ayarlanır.

Audit All

Bu yapılandırma sayesinde bilgisayarın uzak sistemlere gönderdiği tüm NTLM kimlik doğrulama istekleri denetlenir. Böylece NTLM kullanan eski uygulamalar, servisler veya sunucular kolayca tespit edilebilir.

Uygulama Kapsamı: Tüm domain üyeleri (İstemci bilgisayarlar, üye sunucular ve Domain Controller’lar)

Audit NTLM Authentication in this Domain

Son olarak yalnızca Domain Controller’lara uygulanacak aşağıdaki politika etkinleştirilir.

Network Security: Restrict NTLM: Audit NTLM Authentication in this Domain

Politika değeri aşağıdaki şekilde yapılandırılır.

Enable All

Bu ayar sayesinde Domain Controller üzerinde gerçekleşen tüm NTLM kimlik doğrulama işlemleri Security Event Log içerisine kaydedilir. Windows Event Forwarding (WEF) altyapısı da bu olayları merkezi Collector sunucusuna ileterek NTLMv1 kullanımının analiz edilmesini sağlar.

NTLMv1 Olaylarının Toplanması İçin Gerekli Denetim ve Group Policy Ayarları

Windows Event Forwarding (WEF) altyapısının yalnızca kurulmuş olması, NTLMv1 kimlik doğrulama olaylarının merkezi olarak toplanacağı anlamına gelmez. İlgili güvenlik olaylarının oluşturulabilmesi için gelişmiş denetim (Advanced Auditing) yapılandırılmalı ve NTLM denetim politikaları uygun Group Policy (GPO) ayarları ile etkinleştirilmelidir.

Gelişmiş Denetim (Advanced Auditing)

Windows, varsayılan olarak oturum açma olaylarını (Logon Events) denetleyecek şekilde yapılandırılmış olsa da, kurulum öncesinde bu yapılandırmanın doğrulanması tavsiye edilir.

Aşağıdaki komut ile mevcut denetim yapılandırmasını kontrol edebilirsiniz.

auditpol.exe /get /category:"Logon/Logoff"

Logon kategorisi için en az Success denetiminin etkin olması gerekmektedir. Aksi halde 4624 numaralı başarılı oturum açma olayları oluşturulmayacak ve WEF tarafından toplanamayacaktır.

NTLM Denetim Politikalarının Yapılandırılması

NTLM kullanımını izleyebilmek için aşağıdaki güvenlik politikalarının uygun bilgisayarlara uygulanması gerekmektedir.

Bu ayarlar aşağıdaki konumda bulunmaktadır.

Computer Configuration
 └─ Policies
     └─ Windows Settings
         └─ Security Settings
             └─ Local Policies
                 └─ Security Options

Yapılandırmanın Doğrulanması

Group Policy uygulandıktan sonra istemcilerde aşağıdaki komut çalıştırılarak politikaların güncellenmesi önerilir.

gpupdate /force

Ardından tekrar aşağıdaki komut çalıştırılarak gelişmiş denetim ayarları doğrulanabilir.

auditpol.exe /get /category:"Logon/Logoff"

Başarılı bir yapılandırmada Logon kategorisinin en az Success olarak yapılandırılmış olması beklenmektedir.

Test Ortamında NTLMv1 Oluşturma

Üretim ortamlarında NTLMv1’in etkinleştirilmesi önerilmez. Ancak laboratuvar ortamında Windows Event Forwarding yapılandırmasının doğrulanabilmesi amacıyla kontrollü şekilde NTLMv1 kimlik doğrulaması oluşturulabilir.

Test senaryosunda;

• Domain Controller üzerinde LAN Manager Authentication Level politikası NTLMv1’e izin verecek şekilde yapılandırılır.
• Test istemcisinde Send LM & NTLM responses seçeneği etkinleştirilir.
• Ardından SMB paylaşımı veya NTLM kimlik doğrulaması kullanan bir IIS uygulamasına IP adresi üzerinden bağlantı gerçekleştirilir.

Başarılı bir test sonrasında Domain Controller üzerinde 4624 numaralı güvenlik olayı oluşacak ve Windows Event Forwarding altyapısı doğru yapılandırılmışsa bu olay yaklaşık 30 saniye içerisinde Collector sunucusundaki Forwarded Events günlüğüne iletilecektir.

Sorun Giderme (Troubleshooting)

Windows Event Forwarding (WEF) altyapısı doğru yapılandırıldığında oldukça kararlı çalışan bir mekanizmadır. Ancak WinRM yapılandırması, Group Policy ayarları, güvenlik izinleri veya Event Log filtreleri nedeniyle istemciler Collector sunucusuna bağlanamayabilir ya da olaylar iletilmeyebilir.

Bu bölümde WEF kurulumu sırasında en sık karşılaşılan sorunlar ve çözüm yöntemleri ele alınmaktadır.

WEF Loglarının Kontrol Edilmesi

Sorun giderme işlemine başlamadan önce WEF ile ilgili olay günlükleri incelenmelidir.

Aşağıdaki Event Viewer günlükleri en önemli bilgi kaynaklarıdır.

Applications and Services Logs
 └─ Microsoft
      └─ Windows
            ├─ Eventlog-ForwardingPlugin
            ├─ Windows Remote Management
            └─ EventCollector

Bu günlükler;

• WinRM bağlantı hataları
• Subscription problemleri
• XPath sorgu hataları
• Kimlik doğrulama problemleri

gibi birçok sorunun tespit edilmesini sağlar.

Güvenlik Duvarının Kontrol Edilmesi

Collector sunucusunda WinRM için gerekli Windows Firewall kurallarının etkin olduğundan emin olunmalıdır.

Kontrol edilmesi gereken kurallar;

• Windows Remote Management (HTTP-In) – TCP 5985
• Windows Remote Management (HTTPS-In) – TCP 5986 (HTTPS kullanılıyorsa)

Bağlantı aşağıdaki komut ile test edilebilir.

Test-NetConnection <CollectorFQDN> -Port 5985

Bağlantının başarılı olması beklenmektedir.

WinRM Bağlantısının Test Edilmesi

Kaynak bilgisayardan Collector sunucusuna WinRM bağlantısı aşağıdaki komut ile doğrulanabilir.

Test-WSMan <CollectorFQDN>

Başarılı bir bağlantıda WinRM servis bilgileri görüntülenmelidir.

Ayrıca aşağıdaki komut da kullanılabilir.

winrm id -remote:<CollectorFQDN> -auth:none

WinRM Yapılandırmasının Kontrol Edilmesi

WinRM yapılandırmasını doğrulamak için aşağıdaki komutlar kullanılabilir.

winrm get winrm/config

İstemci kimlik doğrulama ayarları

winrm get winrm/config/client/auth

Sunucu kimlik doğrulama ayarları

winrm get winrm/config/service/auth

WinRM servis durumu

Get-Service WinRM

Gerekirse WinRM varsayılan ayarlarına aşağıdaki komut ile döndürülebilir.

winrm invoke restore winrm/config @{}

Subscription Durumunun Kontrol Edilmesi

Collector sunucusunda kayıtlı istemciler aşağıdaki komut ile görüntülenebilir.

wecutil gr <SubscriptionName>

Örneğin;

wecutil gr Ntlmv1

Burada istemcilerin;

• Active
• Inactive

durumları görülebilir.

Inactive istemciler için ayrıntılı hata mesajları da görüntülenmektedir.

0x138C Hatası

Kurulum sırasında karşılaşılan yaygın hatalardan biri aşağıdaki hatadır.

Code (0x138C)

Windows Event Forward plugin can't read any event from the query since the query returns no active channel.

Bu hata çoğunlukla aşağıdaki nedenlerden kaynaklanmaktadır.

• Hatalı XPath sorgusu
• Yanlış Event Log adı
• Event Log erişim izinleri
• Event Log Readers grubunun eksik olması

İlk olarak aşağıdaki komut ile Event Log’un mevcut olduğu doğrulanmalıdır.

Get-WinEvent -ListLog Security

Daha sonra XPath sorgusu PowerShell üzerinde test edilmelidir.

Event Log Readers Yetkisi

Security Event Log’un okunabilmesi için kaynak bilgisayarda aşağıdaki hesabın Event Log Readers grubunda bulunması gerekmektedir.

NETWORK SERVICE

Bu yapılandırma Group Policy kullanılarak merkezi olarak uygulanabilir.

Security Log Access Yetkisi

Windows Server 2025 ortamlarında yalnızca Event Log Readers grubuna üyelik yeterli olmayabilir.

Security Event Log erişimi için aşağıdaki Configure Log Access ayarının da doğru yapılandırıldığından emin olunmalıdır.

O:BAG:SYD:
(A;;0xf0005;;;SY)
(A;;0x5;;;BA)
(A;;0x1;;;S-1-5-32-573)
(A;;0x1;;;S-1-5-20)

Bu SDDL değeri;

• SYSTEM
• Administrators
• Event Log Readers
• NETWORK SERVICE

hesaplarının Security Event Log’u okuyabilmesini sağlar.

NTLM Denetim Politikalarının Kontrolü

NTLM olaylarının oluşabilmesi için aşağıdaki politikaların etkin olması gerekmektedir.

Tüm Domain Üyeleri

• Audit Incoming NTLM Traffic
• Audit Outgoing NTLM Traffic

Sadece Domain Controller

• Audit NTLM Authentication in this Domain

Ayrıca aşağıdaki komut ile Logon denetimi kontrol edilmelidir.

auditpol /get /category:"Logon/Logoff"

Logon kategorisinde en az Success etkin olmalıdır.

LmCompatibilityLevel Değerleri

NTLM davranışı aşağıdaki Registry anahtarı ile belirlenmektedir.

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Değer adı

LmCompatibilityLevel

Değer	Açıklama
0	LM ve NTLM kullanılır.
1	LM ve NTLM kullanılır, mümkünse NTLMv2 oturum güvenliği kullanılır.
2	Sadece NTLM kullanılır.
3	Sadece NTLMv2 yanıtı gönderilir (Windows varsayılanı).
4	NTLMv2 kullanılır, LM reddedilir.
5	Sadece NTLMv2 kabul edilir, LM ve NTLM reddedilir.

Önemli: Üretim ortamlarında önerilen değer 3 veya üzeridir. 5 değeri en yüksek güvenliği sağlar ancak eski uygulamalarla uyumluluk sorunlarına yol açabileceğinden, NTLM kullanım envanteri çıkarılmadan uygulanmamalıdır.

Eski kimlik doğrulama protokollerinin kullanımının tespit edilmesi, Active Directory güvenliğinin artırılması ve modern kimlik doğrulama yöntemlerine geçiş sürecinin en önemli adımlarından biridir. Özellikle NTLMv1 gibi günümüz güvenlik standartlarını karşılamayan protokollerin doğrudan devre dışı bırakılması yerine, öncelikle kullanım alanlarının doğru şekilde tespit edilmesi ve analiz edilmesi büyük önem taşımaktadır.

Bu makalede, Windows Event Forwarding (WEF) altyapısının sıfırdan kurulumu, Windows Event Collector (WEC) yapılandırması, WinRM ayarları, Group Policy konfigürasyonları, NTLM denetim politikalarının uygulanması ve NTLMv1 olaylarının XPath filtreleri kullanılarak merkezi olarak toplanması adım adım ele alındı. Ayrıca kurulum sırasında karşılaşılabilecek yaygın sorunlar ve çözüm yöntemleri de incelenerek, yalnızca teorik değil, üretim ortamlarında uygulanabilir bir rehber oluşturulması hedeflendi.

Kurulumu tamamladıktan sonra artık ortamınızdaki istemci bilgisayarlar, üye sunucular ve Domain Controller’lar üzerinde gerçekleşen NTLM kimlik doğrulama olaylarını merkezi olarak izleyebilir, NTLMv1 kullanan sistemleri kolayca tespit edebilir ve güvenli bir geçiş planı oluşturabilirsiniz.

WEF altyapısı yalnızca NTLMv1 tespiti için değil; güvenlik denetimi, olay korelasyonu, saldırı analizi ve merkezi log yönetimi gibi birçok farklı senaryoda da kullanılabilecek güçlü ve ücretsiz bir Windows bileşenidir. Doğru şekilde yapılandırıldığında, herhangi bir üçüncü taraf yazılıma ihtiyaç duymadan kurumsal ortamlarda etkili bir merkezi olay toplama altyapısı sunmaktadır.

Bir sonraki adım ise elde edilen bu envanter doğrultusunda NTLM kullanımını kademeli olarak azaltmak, uyumluluk testlerini tamamlamak ve son aşamada NTLMv1’i tamamen devre dışı bırakarak daha güvenli bir Active Directory altyapısına geçiş yapmaktır.