Enine Boyuna Windows Audit

1. Giriş: Önce Audit, Sonra Kapatma

NTLMv1, SMBv1 ve Kerberos RC4’ü kapatmak ya da SMB Signing ve LDAP Signing’i zorunlu hale getirmek doğru adımlardır. Ama bunları audit açmadan yaparsanız, eski bir uygulama, yazıcı veya NAS bir sabah sessizce çalışmayı bırakır. Hangi sistemin etkilendiğini de bilemezsiniz.

Bu yüzden kural basittir: önce görünürlük, sonra enforcement. Yani önce ilgili audit’leri açarsınız, en az 2–4 hafta log toplarsınız, eski protokolü kullananları tespit edip düzeltirsiniz, en son kapatırsınız.

Bu rehber, eski protokolleri kapatmadan önce açılması gereken audit ayarlarını, izlenecek Event ID’leri ve adım adım uygulama sırasını tek yerde toplar.

Genel akış:

1. Advanced Audit Policy’yi doğru kurun (Bölüm 2, 3, 8, 9).
2. Protokole özel audit’leri açın: NTLM, Kerberos RC4, SMBv1, SMB/LDAP Signing (Bölüm 4–7).
3. PowerShell’i kayıt altına alın (Bölüm 10).
4. Ayarların gerçekten uygulandığını SCA / secedit ile doğrulayın (Bölüm 11).
5. Event ID tablosu ve kontrol listesiyle geçişi yönetin (Bölüm 12).

Hangi ayarı nereye uygulayacağım?

Rehberde birden fazla tablo var. Kafanız karışmasın diye, uygulanacak tablolar şunlardır:

Nereye	Uygulanacak ayar	Bölüm
Domain Controller’lar	DC audit tablosu	2.2
Üye sunucular	Sunucu audit tablosu	8
İstemci bilgisayarlar	İstemci audit tablosu (sunucuyla aynı)	9
Protokole özel ayarlar	NTLM, RC4, SMBv1, SMB/LDAP Signing	4, 5, 6, 7
PowerShell	Transcription + Script Block + Module Logging	10

Bölüm 2.1 ve Bölüm 3’teki tablolar sadece bilgi amaçlıdır; uygulama yaparken onlara bakmanız gerekmez.

2. Advanced Audit Policy Temelleri ve Domain Controller Yapılandırması

Tüm protokol audit’lerinin temeli Advanced Audit Policy’dir. Eski “Audit Policy” 9 genel kategori sunar; Advanced Audit Policy ise bunları 50’ye yakın alt kategoriye böler. Böylece sadece ihtiyacınız olan olayı açar, log’u gereksiz kayıtla doldurmazsınız.

Advanced kullanılan bir ortamda sadece Advanced Audit Policy’yi yapılandırın. Eski 9 kategorilik “Audit Policy” ayarlarına dokunmayın, hepsini Not Defined olarak bırakın.

Neden ikisi birlikte kullanılmamalı?

Advanced alt kategoriler, eski kategorilerin daha ayrıntılı halidir. Yani aynı ayarı iki farklı yerden yönetmiş olursunuz. İkisi birlikte tanımlanırsa birbirini ezebilirler, hangisinin geçerli olduğu karışır ve beklemediğiniz sonuçlar çıkar. Microsoft da ikisinin karıştırılmamasını öneriyor.

2.1 Üç seviye yaklaşımı

Microsoft her alt kategori için üç seviye önerir. Tablonun tamamı Bölüm 3’te verilmiştir; burada mantığı yeterli:

Profil	Anlamı	Ne zaman kullanılır
Windows Default	Kurulumla gelen ayar	Referans; tek başına yetersizdir
Baseline Recommendation	Microsoft’un genel önerisi	Tüm sunucu ve istemciler için minimum
Stronger Recommendation	Daha geniş kapsam	DC’ler ve kritik sistemler, NTLM/RC4 geçiş projeleri

Tablodaki kısaltmalar: Yes = aç, No = açma, DC = sadece Domain Controller’da aç, IF = ilgili rol varsa aç (örn. IPsec), boş = öneri yok.

NTLMv1 / RC4 kapatma projesi için kritik nokta şudur: Kerberos Authentication Service ve Kerberos Service Ticket Operations sadece “Stronger” profilde açıktır. Baseline ile kalırsanız 4768/4769 olaylarını göremezsiniz.

2.2 Domain Controller için UYGULANACAK ayarlar

Bu tablo Domain Controller’lar için hazırlanmış sıkılaştırılmış yapılandırmadır. (*) ile işaretli iki satır NTLMv1 ve RC4 tespiti için kritiktir. DC’lere bu tabloyu olduğu gibi uygulayın.

Kategori	Alt kategori	Success	Failure
Account Logon	Audit Credential Validation (*)	Yes	Yes
Account Logon	Audit Kerberos Authentication Service	Yes	Yes
Account Logon	Audit Kerberos Service Ticket Operations (*)	Yes	Yes
Account Logon	Audit Other Account Logon Events	Yes	Yes
Account Management	Audit Computer Account Management	Yes	Yes
Account Management	Audit Other Account Management Events	Yes	–
Account Management	Audit Security Group Management	Yes	Yes
Account Management	Audit User Account Management	Yes	Yes
Detailed Tracking	Audit DPAPI Activity	Yes	Yes
Detailed Tracking	Audit PNP Activity	Yes	–
Detailed Tracking	Audit Process Creation	Yes	–
DS Access	Audit Directory Service Access	–	Yes
DS Access	Audit Directory Service Changes	Yes	–
Logon/Logoff	Audit Account Lockout	–	Yes
Logon/Logoff	Audit Group Membership	Yes	–
Logon/Logoff	Audit Logoff	Yes	–
Logon/Logoff	Audit Logon	Yes	Yes
Logon/Logoff	Audit Other Logon/Logoff Events	Yes	Yes
Logon/Logoff	Audit Special Logon	Yes	Yes
Object Access	Audit Application Generated	Yes	–
Object Access	Audit Detailed File Share	–	Yes
Object Access	Audit File Share	Yes	Yes
Object Access	Audit File System	Yes	–
Object Access	Audit Filtering Platform Connection	–	Yes
Object Access	Audit Filtering Platform Packet Drop	Yes	–
Object Access	Audit Kernel Object	Yes	–
Object Access	Audit Other Object Access Events	Yes	Yes
Object Access	Audit Registry	Yes	–
Object Access	Audit Removable Storage	Yes	Yes
Object Access	Audit SAM	Yes	–
Policy Change	Audit Audit Policy Change	Yes	Yes
Policy Change	Audit Authentication Policy Change	Yes	Yes
Policy Change	Audit Filtering Platform Policy Change	Yes	–
Policy Change	Audit MPSSVC Rule-Level Policy Change	Yes	Yes
Policy Change	Audit Other Policy Change Events	–	Yes
Privilege Use	Audit Other Privilege Use Events	Yes	–
Privilege Use	Audit Sensitive Privilege Use	Yes	Yes
System	Audit Other System Events	Yes	–
System	Audit Security State Change	Yes	Yes
System	Audit Security System Extension	Yes	–
System	Audit System Integrity	Yes	Yes

(*) Neden bu iki satırda Success açık? Birçok yapılandırmada bu iki ayar sadece Failure olarak açılır. Bu durumda biri NTLMv1 veya RC4 ile başarıyla bağlandığında log düşmez ve bu sistemleri göremezsiniz. Geçiş projesi boyunca Success açık kalmalıdır. Proje bitince log hacmini azaltmak isterseniz tekrar kapatabilirsiniz.

2.3 Ayarların gerçekten çalışması için

• Eski ve yeni politikayı karıştırmayın. Security Options altındaki “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” ayarını Enabled yapın. Aksi halde eski kategori ayarları alt kategorileri ezebilir.
• Uygulanan ayarı kontrol edin: auditpol /get /category:*
• Tek alt kategori açmak için (test amaçlı): auditpol /set /subcategory:”Credential Validation” /success:enable /failure:enable
• Security log boyutunu büyütün. Varsayılan 20 MB, DC’de birkaç saatte dolar. DC’lerde en az 1–4 GB ya da merkezi log toplama (WEF/SIEM) önerilir. Yol: Computer Configuration > Policies > Administrative Templates > Windows Components > Event Log Service > Security > Specify the maximum log file size.

3. Active Directory Audit Policy Açma ve Düzenleme

AD’de yapılan değişiklikleri ve kimlik doğrulamaları takip etmek için audit politikası DC’ler üzerinde GPO ile açılır. Referans olarak Microsoft Best Practices tablosu (“EK 1”) kullanılır.

3.1 Adım adım

1. Group Policy Management konsolunu açın.
2. Domain Controllers OU’su altındaki Default Domain Controllers Policy’ye sağ tıklayıp Edit deyin. (Öneri: Default politikayı değiştirmek yerine Domain Controllers OU’suna bağlı ayrı bir “DC Audit Policy” GPO’su oluşturmak geri dönüşü kolaylaştırır.)
3. Şu yola gidin:

Computer Configuration > Policies > Windows Settings > Security Settings >
Advanced Audit Policy Configuration > Audit Policies

4. Her kategori ve alt kategoriyi **Bölüm 2.2’deki DC tablosuna** göre Success / Failure olarak ayarlayın.
5. DC’lerde gpupdate /force çalıştırıp auditpol /get /category:* ile sonucu kontrol edin.

3.2 EK 1: AD Audit düzenleme tablosu (sadece bilgi amaçlı)

Bu tabloyu uygulamanız gerekmez. Microsoft’un genel önerisini gösterir ve Bölüm 2.2’deki DC tablosu bundan türetilmiştir. DC’lere uygulayacağınız ayarlar Bölüm 2.2’dedir. Değerler “Success / Failure” sırasındadır; boş hücre (-) öneri olmadığını gösterir.

Kategori	Alt kategori	Windows Default	Baseline	Stronger
Account Logon	Audit Credential Validation	No / No	Yes / Yes	Yes / Yes
Account Logon	Audit Kerberos Authentication Service	–	–	Yes / Yes
Account Logon	Audit Kerberos Service Ticket Operations	–	–	Yes / Yes
Account Logon	Audit Other Account Logon Events	–	–	Yes / Yes
Account Management	Audit Computer Account Management	–	Yes / DC	Yes / Yes
Account Management	Audit Other Account Management Events	–	Yes / Yes	Yes / Yes
Account Management	Audit Security Group Management	–	Yes / Yes	Yes / Yes
Account Management	Audit User Account Management	Yes / No	Yes / Yes	Yes / Yes
Detailed Tracking	Audit DPAPI Activity	–	–	Yes / Yes
Detailed Tracking	Audit Process Creation	–	Yes / No	Yes / Yes
DS Access	Audit Directory Service Access	–	DC / DC	DC / DC
DS Access	Audit Directory Service Changes	–	DC / DC	DC / DC
Logon/Logoff	Audit Account Lockout	Yes / No	–	Yes / No
Logon/Logoff	Audit IPsec Main Mode	–	–	IF / IF
Logon/Logoff	Audit Logoff	Yes / No	Yes / No	Yes / No
Logon/Logoff	Audit Logon	Yes / No	Yes / Yes	Yes / Yes
Logon/Logoff	Audit Network Policy Server	Yes / Yes	–	–
Logon/Logoff	Audit Other Logon/Logoff Events	–	–	Yes / Yes
Logon/Logoff	Audit Special Logon	Yes / No	Yes / No	Yes / Yes
Policy Change	Audit Audit Policy Change	Yes / No	Yes / Yes	Yes / Yes
Policy Change	Audit Authentication Policy Change	Yes / No	Yes / No	Yes / Yes
Policy Change	Audit MPSSVC Rule-Level Policy Change	–	–	Yes / –
Privilege Use	Audit Sensitive Privilege Use	–	Yes / Yes	Yes / Yes
System	Audit IPsec Driver	–	Yes / Yes	Yes / Yes
System	Audit Other System Events	Yes / Yes	–	–
System	Audit Security State Change	Yes / No	Yes / Yes	Yes / Yes
System	Audit Security System Extension	–	Yes / Yes	Yes / Yes
System	Audit System Integrity	Yes / Yes	Yes / Yes	Yes / Yes

Bu projede neden önemli? NTLM ve Kerberos olaylarının hepsi Account Logon ve Logon/Logoff kategorilerinden gelir. Bu kategoriler “Stronger” seviyede açılmadan Bölüm 4 ve 5’teki tespitler yapılamaz.

4. NTLM Audit: NTLMv1 Kapatılmadan Önce

Amaç, NTLMv1 kullanan istemci ve hesapları bulup Kerberos’a (ya da en azından NTLMv2’ye) taşımak, sonra NTLMv1’i kapatmaktır.

4.1 NTLMv1 neden kapatılmalı?

Başlıca riskler:

• Zayıf şifreleme: AES, SHA-256 gibi güçlü algoritmalar kullanılmaz; hash’ler kolayca kırılabilir.
• Kimlik bilgisi çalınması: mimikatz gibi araçlarla LSA servisine erişilebilir.
• Karşılıklı doğrulama yok: Responder gibi araçlar NTLM trafiğini yakalayıp relay edebilir.

4.2 Event ID 4624 üzerinden tespit

Bir oturum NTLM ile açıldığında Security log’una Event ID 4624 (An account was successfully logged on) düşer. Olayın içindeki Package Name (NTLM only) alanı hangi sürümün kullanıldığını gösterir: NTLM V1 veya NTLM V2.

Basit sorgu:

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} |
  Where-Object { $_.Message -match "NTLM V1" } |
  Format-List > C:\Volsys\NTLMv1.txt

Ön koşul: 4624’ün loglanması için Logon/Logoff > Audit Logon (Success) açık olmalıdır.

Daha hızlı sorgu. Büyük log’larda Message aramak yavaştır. XPath filtresi doğrudan alanı sorgular ve kaynağı tablo olarak verir:

$xpath = "*[System[EventID=4624] and EventData[Data[@Name='LmPackageName']='NTLM V1']]"
Get-WinEvent -LogName Security -FilterXPath $xpath |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}; $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
      Zaman       = $_.TimeCreated
      Kullanici   = "$($d.TargetDomainName)\$($d.TargetUserName)"
      Istemci     = $d.WorkstationName
      IP          = $d.IpAddress
    }
  } | Export-Csv C:\Volsys\NTLMv1.csv -NoTypeInformation -Encoding UTF8

4.3 NTLM audit GPO’ları

4624 sadece oturumun açıldığı makinede görünür. Tüm NTLM trafiğini merkezi görmek için “Restrict NTLM” politikalarını sadece audit modunda açın. Yol:

Computer Configuration > Policies > Windows Settings > Security Settings >
Local Policies > Security Options

Politika	Nereye	Değer
Network security: Restrict NTLM: Audit NTLM authentication in this domain	Domain Controllers	Enable all
Network security: Restrict NTLM: Audit Incoming NTLM Traffic	Tüm sunucular ve DC’ler	Enable auditing for all accounts
Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers	İstemciler ve sunucular	Audit all

Bu ayarlar hiçbir şeyi engellemez, sadece loglar. Olaylar şuraya düşer: Applications and Services Logs > Microsoft > Windows > NTLM > Operational

Event ID	Nerede oluşur	Anlamı
8001	İstemci	Uzak sunucuya giden NTLM doğrulaması
8002	Sunucu	Yerel hesapla gelen NTLM doğrulaması
8003	Sunucu	Domain hesabıyla gelen NTLM doğrulaması
8004	Domain Controller	DC’ye iletilen NTLM doğrulaması (kullanıcı, istemci ve hedef sunucu bilgisiyle)

Ayrıca DC’de Security log’undaki Event ID 4776 (The computer attempted to validate the credentials for an account) NTLM ile doğrulanan her hesabı gösterir. Bunun için Account Logon > Audit Credential Validation (Success ve Failure) açık olmalıdır.

4.4 Geçiş adımları

1. Audit Logon ve Credential Validation alt kategorilerini açın.
2. Restrict NTLM audit politikalarını yukarıdaki gibi uygulayın.
3. 2–4 hafta boyunca 4624 (NTLM V1) ve 8004 olaylarını toplayın, kaynak makine ve uygulamaları listeleyin.
4. Eski cihazları güncelleyin veya NTLMv2/Kerberos’a taşıyın.
5. NTLMv1 olayı kalmayınca kapatın: “Network security: LAN Manager authentication level” = Send NTLMv2 response only. Refuse LM & NTLM (registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel = 5).

5. Kerberos RC4 Auditing

NTLM’den Kerberos’a geçmek tek başına yetmez; Kerberos biletleri hala RC4 (ARC4) ile şifreleniyor olabilir. DES’in kaldırılması gibi RC4’ün de kaldırılması önerilir. Windows Server 2008 ve Vista’dan beri AES128/AES256 desteklenir. Ancak bazı uygulama ve cihazlar (örneğin bazı NetApp sürümleri) sadece RC4 destekler. Bu yüzden önce kimin RC4 kullandığı bulunmalıdır.

5.1 İzlenecek olay

Alan	Değer
Event ID	4769 – A Kerberos service ticket was requested
Log	Security (DC üzerinde)
Task Category	Kerberos Service Ticket Operation
Gerekli audit	Account Logon > Audit Kerberos Service Ticket Operations (Success + Failure)
RC4 göstergesi	Ticket Encryption Type = 0x17 veya 0x18

Encryption Type değerlerinin anlamı:

Değer	Algoritma	Durum
0x1, 0x3	DES	Kapatılmalı
0x11	AES128-CTS-HMAC-SHA1-96	Güvenli
0x12	AES256-CTS-HMAC-SHA1-96	Güvenli (hedef)
0x17	RC4-HMAC	Kaldırılacak
0x18	RC4-HMAC-EXP	Kaldırılacak

Not: TGT talepleri için de aynı kontrol Event ID 4768 (A Kerberos authentication ticket (TGT) was requested) üzerinden yapılır. Bunun için Audit Kerberos Authentication Service açık olmalıdır.

5.2 PowerShell ile RC4 kullananları listeleme

$xpath = "*[System[(EventID=4768 or EventID=4769)] and EventData[Data[@Name='TicketEncryptionType']='0x17' or Data[@Name='TicketEncryptionType']='0x18']]"
Get-WinEvent -LogName Security -FilterXPath $xpath |
  ForEach-Object {
    $x = [xml]$_.ToXml(); $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
      Zaman    = $_.TimeCreated
      EventID  = $_.Id
      Hesap    = $d.TargetUserName
      Servis   = $d.ServiceName
      IP       = $d.IpAddress
      EncType  = $d.TicketEncryptionType
    }
  } | Export-Csv C:\Volsys\RC4.csv -NoTypeInformation -Encoding UTF8

5.3 Adımlar

1. DC’lerde Kerberos Authentication Service ve Kerberos Service Ticket Operations alt kategorilerini açın.
2. 4768/4769 olaylarında 0x17 ve 0x18 olanları filtreleyin.
3. Hesap ve servis bazlı liste çıkarın. Servis hesaplarında msDS-SupportedEncryptionTypes değerini kontrol edin; AES için parolayı değiştirmek gerekebilir.
4. RC4 kullanımı sıfırlanınca “Network security: Configure encryption types allowed for Kerberos” politikasından RC4’ü kaldırın.

6. SMBv1 Auditing

SMBv1 ciddi güvenlik açıkları taşır (WannaCry/EternalBlue bunun en bilinen örneğidir). Ancak doğrudan kapatılırsa eski yazıcı, tarayıcı, NAS veya uygulamalar dosya paylaşımına erişemez. Bu yüzden önce audit açılır.

Sürüm bilgisi: SMBv2 Windows Vista / Server 2008 ile, SMBv3 Windows 8 / Server 2012 ile gelmiştir. Bu sürümlerden yeni sistemlerin SMBv1’e ihtiyacı yoktur.

6.1 Adımlar

1. Mevcut durumu kontrol edin. AuditSmb1Access değeri varsayılan olarak False‘tur:

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, AuditSmb1Access

2. Audit’i açın:

Set-SmbServerConfiguration -AuditSmb1Access $true

3. Tekrar kontrol edin; AuditSmb1Access artık True olmalıdır.

6.2 İzlenecek olay

Alan	Değer
Log	Microsoft-Windows-SMBServer/Audit (Applications and Services Logs > Microsoft > Windows > SMBServer > Audit)
Event ID	3000
Level	Information
Anlamı	Bir istemci bu sunucuya SMBv1 ile bağlanmaya çalıştı; olayda istemci adresi yer alır

Olayları toplu okuma

Get-WinEvent -LogName 'Microsoft-Windows-SMBServer/Audit' -FilterXPath '*[System[EventID=3000]]' |
  Select-Object TimeCreated, Message | Export-Csv C:\Volsys\SMBv1.csv -NoTypeInformation -Encoding UTF8

Audit, dosya sunucusu ve DC gibi paylaşım sunan tüm sunucularda açılmalıdır. Birden çok sunucu için GPO ile bir başlangıç betiği veya Invoke-Command kullanılabilir.

6.3 Kapatma (olay kalmadıktan sonra)

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Unutmayın: SMBv1 kapatıldıktan sonra sunucu veya istemcinin yeniden başlatılması gerekir.

7. SMB Signing ve LDAP Signing Öncesi Audit

Mantık önceki bölümlerle aynıdır: önce imzasız bağlanan istemcileri bulun, düzeltin, sonra imzalamayı zorunlu yapın.

7.1 SMB Signing audit

SMB Signing zorunlu yapıldığında imzalamayı desteklemeyen eski istemciler (bazı NAS, yazıcı, Linux/Samba, eski cihazlar) paylaşıma erişemez. Eylül 2025 ve sonrası güncellemelerle sunucu tarafında imza audit’i gelmiştir; istemci tarafı audit’i Windows 11 24H2 / Server 2025 ile desteklenir.

PowerShell ile açma:

# Sunucu tarafı: imzalamayı desteklemeyen istemcileri logla
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true
# İstemci tarafı: imzalamayı desteklemeyen sunuculara bağlantıyı logla (Win11 24H2+)
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

GPO ile açma:

GPO	Yol	Taraf
Audit client does not support signing	Computer Configuration > Administrative Templates > Network > Lanman Server	Sunucu
Audit server does not support signing	Computer Configuration > Administrative Templates > Network > Lanman Workstation	İstemci

Sunucu tarafı registry karşılığı: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\AuditClientDoesNotSupportSigning = 1 (REG_DWORD).

İzlenecek olaylar:

Event ID	Log	Anlamı
3021	Microsoft-Windows-SMBServer/Audit	SMB2/3 istemcisi imzalamayı desteklemiyor (istemci adı ve kullanıcı yazılır)
3027	Microsoft-Windows-SMBServer/Audit	SMBv1 istemcisinde imzalama açık değil (yanlış pozitif/negatif olabilir)
3022	Microsoft-Windows-SMBServer/Audit	İstemci şifrelemeyi desteklemiyor (encryption audit açıksa)
31998 / 31999	Microsoft-Windows-SMBClient/Audit	İstemci tarafı imza / şifreleme audit olayları

Zorunlu hale getirme (olay kalmadıktan sonra):

• “Microsoft network server: Digitally sign communications (always)” = Enabled (LanManServer\Parameters\RequireSecuritySignature = 1)
• “Microsoft network client: Digitally sign communications (always)” = Enabled (LanManWorkstation\Parameters\RequireSecuritySignature = 1)

7.2 LDAP Signing ve Channel Binding audit

LDAP Signing zorunlu olduğunda, DC’ye imzasız SASL veya düz metin (389 portu üzerinden simple bind) bağlanan uygulamalar çalışmaz. Tipik kurbanlar: eski yazıcı/tarayıcı “scan to email”, Linux sunucular, firewall ve VPN cihazlarının LDAP entegrasyonları, eski Java uygulamaları.

Adım 1 – DC’lerde LDAP tanılama loglarını açın. Event 2889 ancak bu ayarla oluşur:

reg add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2 /f

Yeniden başlatma gerekmez. 2 = Basic seviyedir; daha yüksek değerler log’u hızla şişirir.

Adım 2 – Directory Service log’unu izleyin. Log: Applications and Services Logs > Directory Service, Source: ActiveDirectory_DomainService, Kategori: LDAP Interface.

Event ID	Ne zaman oluşur	Anlamı
2886	24 saatte bir / servis başlangıcında	LDAP signing zorunlu değil, uyarı
2887	24 saatte bir	Son 24 saatte kaç imzasız SASL ve düz metin simple bind yapıldığının özeti
2888	24 saatte bir (zorunlu modda)	Son 24 saatte reddedilen imzasız bind sayısı
2889	Her imzasız bind’da	İstemci IP:port, kullanılan hesap ve bind tipi (0 = imzasız SASL, 1 = düz metin simple bind). Tespitin asıl kaynağı
3039	Channel binding “When Supported/Always” iken	LDAPS bağlantısında channel binding doğrulaması başarısız
3040	24 saatte bir (CBT = Never)	Son 24 saatteki korumasız LDAPS bind sayısı
3041	24 saatte bir (CBT = Never)	Channel binding zorunlu değil, uyarı
3074	CBT “When Supported” iken	Zorunlu olsaydı channel binding doğrulaması başarısız olacaktı
3075	CBT “When Supported” iken	İstemci channel binding bilgisi göndermiyor; zorunlu olsaydı reddedilecekti

Adım 3 – 2889 olaylarını raporlayın:

Get-WinEvent -LogName 'Directory Service' -FilterXPath '*[System[EventID=2889]]' |
  ForEach-Object {
    $x = [xml]$_.ToXml(); $d = $x.Event.EventData.Data
    [pscustomobject]@{ Zaman=$_.TimeCreated; IstemciIP=$d[0]; Hesap=$d[1]; BindTipi=$d[2] }
  } | Sort-Object IstemciIP -Unique | Export-Csv C:\Volsys\LDAP-Unsigned.csv -NoTypeInformation -Encoding UTF8

Adım 4 – Zorunlu hale getirin (2889 kalmadıktan sonra):

GPO (Security Options)	Değer	Registry
Domain controller: LDAP server signing requirements	Require signing	NTDS\Parameters\LDAPServerIntegrity = 2
Domain controller: LDAP server channel binding token requirements	Önce When Supported, sonra Always	NTDS\Parameters\LdapEnforceChannelBinding = 1 / 2
Network security: LDAP client signing requirements	Negotiate signing veya Require signing	İstemci tarafı

Microsoft’un önerisi: imzasız bind olayı uzun bir süre boyunca hiç görülmedikten sonra zorunlu yapın.

8. Windows Server İçin Advanced Audit Configuration

Aşağıdaki tablo Tier 1 (üye sunucular: uygulama, dosya, veritabanı sunucuları) için önerilen yapılandırmadır. Bu ayarlar Domain Controller’lar dışındaki sunuculara, sunucuların bulunduğu OU’ya bağlı ayrı bir GPO ile uygulanır.

Kategori	Alt kategori	Success	Failure
Account Logon	Audit Credential Validation	Yes	Yes
Account Management	Audit Security Group Management	Yes	–
Account Management	Audit User Account Management	Yes	Yes
Detailed Tracking	Audit PNP Activity	Yes	–
Detailed Tracking	Audit Process Creation	Yes	–
Logon/Logoff	Audit Account Lockout	–	Yes
Logon/Logoff	Audit Group Membership	Yes	–
Logon/Logoff	Audit Logon	Yes	Yes
Logon/Logoff	Audit Other Logon/Logoff Events	Yes	Yes
Logon/Logoff	Audit Special Logon	Yes	–
Object Access	Audit Detailed File Share	–	Yes
Object Access	Audit File Share	Yes	Yes
Object Access	Audit Other Object Access Events	Yes	Yes
Object Access	Audit Removable Storage	Yes	Yes
Policy Change	Audit Audit Policy Change	Yes	–
Policy Change	Audit Authentication Policy Change	Yes	–
Policy Change	Audit MPSSVC Rule-Level Policy Change	Yes	Yes
Policy Change	Audit Other Policy Change Events	–	Yes
Privilege Use	Audit Sensitive Privilege Use	Yes	Yes
System	Audit Other System Events	Yes	Yes
System	Audit Security State Change	Yes	–
System	Audit Security System Extension	Yes	–
System	Audit System Integrity	Yes	Yes

Neden önemli? Sunucularda Audit Logon (S/F) açık olduğu için NTLMv1 ile açılan oturumlar 4624 olayında görünür (Bölüm 4.2). Audit File Share ve Detailed File Share ise SMB erişimlerinin kim tarafından yapıldığını gösterir; SMB imza / SMBv1 çalışmasında istemciyi doğrulamak için kullanışlıdır (Event 5140, 5145).

9. Windows İstemciler İçin Advanced Audit Configuration

Aşağıdaki ayarlar Tier 2 (kullanıcı bilgisayarları) için önerilir. Alt kategori listesi ve Success/Failure değerleri, Bölüm 8’deki sunucu tablosuyla birebir aynıdır. Fark, uygulandığı yerdir: istemci bilgisayarların bulunduğu OU’ya bağlı ayrı bir GPO.

İstemci tarafında öne çıkan alt kategoriler:

Alt kategori	Neden istemcide önemli
Audit Credential Validation (S/F)	Yerel hesaplarla yapılan doğrulamaları gösterir
Audit Logon (S/F)	İstemciye gelen bağlantıları ve NTLM sürümünü (4624) gösterir
Audit PNP Activity (S)	Takılan harici cihazları gösterir
Audit Removable Storage (S/F)	USB bellek erişimlerini gösterir
Audit Process Creation (S)	Çalıştırılan programları gösterir (4688)
Audit MPSSVC Rule-Level Policy Change (S/F)	Windows Firewall kural değişikliklerini gösterir

Neden önemli? NTLMv1 trafiğinin asıl üreticisi genellikle istemcilerdir. İstemcilerde ayrıca Bölüm 4.3’teki “Restrict NTLM: Outgoing NTLM traffic to remote servers = Audit all” ayarı açılırsa, her istemci hangi sunucuya NTLM ile gittiğini Event 8001 ile kaydeder. Windows 11 24H2 ve sonrasında SMB istemci imza audit’i de istemci GPO’suna eklenebilir (Bölüm 7.1).

10. PowerShell Auditing

NTLM, SMB ve LDAP ayarları genellikle PowerShell ile değiştirilir; saldırganlar da aynı aracı kullanır. Bu yüzden geçiş projesine başlamadan PowerShell kayıt altına alınmalıdır. PowerShell 5.0 ve sonrasında her oturumu kimin açtığını, hangi komutları çalıştırdığını ve hangi çıktıyı gördüğünü TXT dosyasına yazmak için aşağıdaki yapılandırma kullanılır. Kayıtlar C:\PSLogs klasöründe tarih/saate göre klasörlenerek tutulur.

10.1 GPO ayarları

Yol: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell

Ayar	Değer	Ne sağlar	Nereye yazar
Turn on PowerShell Transcription	Enabled, Output directory = C:\PSLogs, “Include invocation headers” işaretli	Oturumun tam dökümü: kullanıcı, komut ve çıktı	C:\PSLogs<tarih>*.txt
Turn on PowerShell Script Block Logging	Enabled	Çalıştırılan betik bloklarının içeriği, gizlenmiş (obfuscated) kod dahil	Event 4104
Turn on Module Logging	Enabled, Module Names = *	Modül ve cmdlet çağrıları	Event 4103

Script block ve module olayları Applications and Services Logs > Microsoft > Windows > PowerShell > Operational log’una düşer. Process Creation audit’i (4688) ile birlikte “Include command line in process creation events” ayarı da açılırsa powershell.exe komut satırı Security log’unda da görünür.

10.2 Dikkat edilecekler

• Transcript dosyaları parola veya hassas veri içerebilir. C:\PSLogs klasörüne normal kullanıcıların okuma yetkisi olmamalıdır; mümkünse merkezi ve yazma-only bir paylaşıma yönlendirin.
• Bu özellikler PowerShell 5.0 ve sonrasında çalışır. Saldırganların PowerShell 2.0 ile atlatmaması için Windows PowerShell 2.0 özelliğini kaldırın.

11. Security Configuration and Analysis (SCA) ile Doğrulama

GPO’yu yazmak, ayarın sunucuda gerçekten uygulandığı anlamına gelmez. SCA, bir sunucunun mevcut güvenlik ayarlarını bir şablonla (.inf) karşılaştırır ve farkı gösterir. Aynı iş komut satırından secedit.exe ile yapılır.

Önemli sınır: SCA, modern Advanced Audit Policy ayarlarını tam kapsamaz. Audit alt kategorilerini auditpol /get /category:* ile kontrol edin. SCA ise NTLM, SMB ve LDAP Security Options ayarlarını (LmCompatibilityLevel, RequireSecuritySignature, LDAPServerIntegrity vb.) doğrulamak için idealdir.

11.1 SCA kapsamı (secedit alanları)

Alan	İçerik
securitypolicy	Hesap politikaları, audit policy, security options
group_mgmt	Restricted Groups
user_rights	Kullanıcı hakları
regkeys	Registry izinleri
filestore	Dosya sistemi izinleri
services	Servis ayarları

11.2 MMC ile adım adım

1. mmc.exe’yi yönetici olarak açın. File > Add/Remove Snap-in > Security Configuration and Analysis (isteğe bağlı Security Templates) ekleyin, SCA.msc olarak kaydedin.
2. Sağ tık > Open Database. Olmayan bir dosya adı verirseniz yeni veritabanı (C:\SecDB\Baseline.sdb) oluşur. Sistem veritabanı %windir%\Security\Database\secedit.sdb çalışma için kullanılmamalıdır.
3. Şablonu seçin (örn. VOLSYS-Baseline.inf). Birden çok şablon içe aktarılabilir; çakışan ayarlarda sıra önemlidir.
4. Sağ tık > Analyze Computer Now. Bu adım sadece okur ve karşılaştırır, hiçbir şeyi değiştirmez.
5. Sonuçları okuyun: yeşil = uyumlu, kırmızı = uyumsuz, Not Defined = değerlendirilmedi (kapalı demek değildir).
6. Gerekirse “Define this policy in the database” ile sadece veritabanını değiştirin.
7. Export Template ile .inf dışa aktarın.
8. Configure Computer Now ayarları uygular. En riskli adımdır; özellikle DC’lerde ve Restricted Groups’ta dikkat gerekir.

11.3 Komut satırı (secedit)

:: 1. Mevcut durumu yedekle
secedit /export /cfg C:\SecDB\CurrentSecurity.inf
:: 2. Şablonun sözdizimini kontrol et
secedit /validate C:\SecDB\Baseline.inf
:: 3. Analiz (değişiklik yapmaz)
secedit /analyze /db C:\SecDB\Baseline.sdb /cfg C:\SecDB\Baseline.inf /log C:\SecDB\Analysis.log
:: 4. Geri dönüş şablonu oluştur
secedit /generaterollback /db C:\SecDB\Baseline.sdb /cfg C:\SecDB\Baseline.inf /rbk C:\SecDB\Rollback.inf /log C:\SecDB\Rollback.log
:: 5. ACL yedeği
icacls C:\Application /save C:\SecDB\Application-ACL.txt /t
:: 6. Uygula (önce test sunucusunda)
secedit /configure /db C:\SecDB\Baseline.sdb /cfg C:\SecDB\Baseline.inf /overwrite /log C:\SecDB\Configure.log

Sadece bir alanı uygulamak için: secedit /configure /db Baseline.sdb /areas user_rights (ya da group_mgmt, regkeys, filestore, services).

11.4 Önerilen üretim sırası

Mevcut durumu export et > şablonu doğrula > veritabanı oluştur > import > analiz > uyumsuzlukları incele > rollback şablonu oluştur > ACL yedekle > test sunucusunda configure > tekrar analiz > doğrula > üretim.

Ek araçlar: Security Compliance Toolkit içindeki Policy Analyzer, LGPO.exe, SetObjectSecurity.exe ve GPO2PolicyRules de aynı karşılaştırma işi için kullanılabilir.

12. Toplu Event ID Tablosu ve Geçiş Kontrol Listesi

Tüm projeyi tek bakışta yönetmek için aşağıdaki tabloyu SIEM / log toplama kurallarınıza ekleyin.

Proje	Event ID	Log	Nerede	Önce açılması gereken audit
NTLMv1 kapatma	4624 (Package Name = NTLM V1)	Security	Tüm sunucu/istemci	Audit Logon (S/F)
NTLMv1 kapatma	4776	Security	DC	Audit Credential Validation (S/F)
NTLMv1 kapatma	8001 / 8002 / 8003	Microsoft-Windows-NTLM/Operational	İstemci / sunucu	Restrict NTLM: Outgoing = Audit all, Incoming = Enable auditing for all accounts
NTLMv1 kapatma	8004	Microsoft-Windows-NTLM/Operational	DC	Restrict NTLM: Audit NTLM authentication in this domain = Enable all
Kerberos RC4 kaldırma	4768 (Encryption Type 0x17/0x18)	Security	DC	Audit Kerberos Authentication Service (S/F)
Kerberos RC4 kaldırma	4769 (Encryption Type 0x17/0x18)	Security	DC	Audit Kerberos Service Ticket Operations (S/F)
SMBv1 kapatma	3000	Microsoft-Windows-SMBServer/Audit	Dosya sunucuları, DC	Set-SmbServerConfiguration -AuditSmb1Access $true
SMB Signing zorunlu	3021, 3027	Microsoft-Windows-SMBServer/Audit	Sunucular	Audit client does not support signing
SMB Signing zorunlu	31998 / 31999	Microsoft-Windows-SMBClient/Audit	İstemciler (Win11 24H2+)	Audit server does not support signing
LDAP Signing zorunlu	2886, 2887, 2888	Directory Service	DC	Varsayılan olarak gelir
LDAP Signing zorunlu	2889	Directory Service	DC	16 LDAP Interface Events = 2
LDAP Channel Binding	3039, 3040, 3041, 3074, 3075	Directory Service	DC	16 LDAP Interface Events = 2, CBT = When Supported
PowerShell izleme	4103, 4104	Microsoft-Windows-PowerShell/Operational	Tüm sistemler	Module Logging, Script Block Logging
PowerShell izleme	Transcript dosyaları	C:\PSLogs	Tüm sistemler	PowerShell Transcription
Genel	4688	Security	Tüm sistemler	Audit Process Creation (S)

Geçiş kontrol listesi

Faz 1 – Hazırlık (1. hafta)

• Advanced Audit Policy GPO’larını Tier 0 (DC), Tier 1 (sunucu) ve Tier 2 (istemci) için ayrı ayrı oluştur
• “Force audit policy subcategory settings” = Enabled
• Security log boyutunu büyüt, logları SIEM/WEF’e yönlendir
• PowerShell Transcription, Script Block ve Module Logging’i aç
• auditpol /get /category:* ve SCA ile ayarların uygulandığını doğrula

Faz 2 – Protokol audit’leri (2–6. hafta)

• DC’lerde Credential Validation ve Kerberos alt kategorilerinde Success + Failure aç
• Restrict NTLM audit politikalarını uygula (8001–8004)
• Tüm dosya sunucularında AuditSmb1Access ve AuditClientDoesNotSupportSigning aç
• DC’lerde 16 LDAP Interface Events = 2 yap
• Haftalık rapor: NTLMv1, RC4, SMBv1, imzasız SMB ve imzasız LDAP kullanan sistemler

Faz 3 – Düzeltme

• Her kaynak sistem için sahip, çözüm ve tarih belirle (güncelleme, ayar, yeni cihaz)
• Olay sayısı sıfıra inene kadar izlemeye devam et

Faz 4 – Enforcement (pilot OU, sonra tüm ortam)

• SMBv1 kapat (EnableSMB1Protocol $false, yeniden başlat)
• LmCompatibilityLevel = 5 (NTLMv1 kapalı)
• Kerberos encryption types: RC4’ü kaldır, AES128/AES256 bırak
• SMB Signing (always) sunucu ve istemcide Enabled
• LDAP server signing = Require signing, Channel binding = When Supported > Always
• Enforcement sonrası audit’leri kapatma; hata olaylarını (örn. 2888) izlemeye devam et