Merhaba,
SIEM yokken veya EDR alarmı gelmeden önce Windows Event Log hâlâ en yakın dostunuz. Bu yazıda tehdit avında ilk baktığım dört olay kimliğini (4624, 4625, 4688, 1102) ve bunları nasıl sorguladığımı anlatıyorum. Ortam: Windows 11 / Server lab, PowerShell ile.
Önkoşul: audit politikası
4688 (yeni süreç) varsayılanda her yerde dolu olmayabilir. Local Security Policy veya GPO ile "Audit Process Creation" Success açık olmalı; komut satırını da loglamak için:
Kod:
# PowerShell (yönetici) - lab
auditpol /set /subcategory:"Process Creation" /success:enable
# Komut satırı ekleme (Sysmon yoksa)
reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f4624 — başarılı oturum
Logon Type değerleri kritik:
- 2: etkileşimli (konsol)
- 3: ağ (SMB, vs.)
- 10: RemoteInteractive (RDP)
- 5: servis
Kod:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-24)} |
Select-Object TimeCreated,@{n='Target';e={$_.Properties[5].Value}},@{n='LogonType';e={$_.Properties[8].Value}},@{n='Ip';e={$_.Properties[18].Value}} |
Format-Table -AutoSize4625 — başarısız oturum
Brute force ve parola spray burada görünür. Aynı Source IP'den çok sayıda 4625, ardından bir 4624 = klasik pattern.
Kod:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-6)} |
Group-Object { $_.Properties[19].Value } | Sort-Object Count -Descending | Select-Object -First 104688 — yeni süreç
Parent-child ilişkisi ve CommandLine (açıksa) lateral movement / LOLBin avında altındır. Örnek şüpheli: winword.exe -> powershell.exe, veya userinit -> unknown.exe.
Kod:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddHours(-4)} |
Where-Object { $_.Message -match 'powershell|cmd.exe|rundll32|mshta' } |
Select-Object -First 20 TimeCreated, Message1102 — audit log temizlendi
Security günlüğünün temizlenmesi nadiren meşrudur. Görürseniz kim yaptı, ne zaman, hangi süreç sorularını hemen sorun. Bu olay tek başına yüksek öncelikli alarındır.
Hızlı av senaryoları
- RDP brute: 4625 Type 10 yoğunluğu + nadir 4624
- Pass-the-hash şüphesi: Type 3 logon pattern'leri + aynı anda süreç anormallikleri (ileri seviye; tek başına 4624 yetmez)
- Log silme: 1102
- Şüpheli yönetim aracı: 4688 içinde ntdsutil, diskshadow, procdump vb. (ortamınıza göre allowlist)
SIEM'e taşırken
Ham Event Log'u WEF/Winlogbeat ile toplayın. Alanları parse edin (LogonType, IpAddress, CommandLine). Sigma kuralları bu ID'ler üzerine yazılır; yerel PowerShell avı Sigma'ya giden yoldur.
Kaynaklar
- Microsoft Event ID referansları (learn.microsoft.com)
- MITRE ATT&CK: Logon / Process Discovery teknikleri
- SigmaHQ rules (windows)
Sizin ilk baktığınız Event ID hangisi? 4672 (özel yetkiler) ekleyenler de yorumda anlatsın.
wevtutil ve uzak log
Kod:
wevtutil qe Security /q:"*[System[(EventID=4625)]]" /c:20 /f:textSysmon ile zenginleştirme
4688 CommandLine bazen eksik kalır; Sysmon Event ID 1 process create, 3 network connect, 11 file create ile tabloyu tamamlar. SwiftOnSecurity veya Olaf Hartong yapılandırmalarını labda deneyip gürültüyü kendi baselineline göre kırpın.
Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.
Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.
Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.
Ölçüm ve alarm sağlığı
Yanlış pozitifleri susturmak ile körleşmek arasındaki çizgi incedir. Suppress kuralına gerekçe ve gözden geçirme tarihi yazın. Süresi dolunca yeniden değerlendirin.
Kapsam ve izin hatırlatması
Bu adımları change ticket olmadan production'da uygulamayın. Küçük görünen bir audit ayarı bile uygulama uyumluluğunu bozabilir. Önce staging, sonra kontrollü yayılım.
Yedekleme ve geri dönüş
Yılda en az iki kez masabaşı tatbikatı yapın: 'bu kontrol kırılırsa kim fark eder?' sorusunu sorunsuz cevaplayabilmelisiniz. Tatbikat notlarını wiki'ye ekleyin.
Log saklama süresi
Araç çıktısını ekran görüntüsü olarak bırakmak yerine makinece okunur formatta (JSON/CSV) arşivleyin. İki yıl sonraki denetimde arama kolaylaşır.
Yanlış pozitif yönetimi
Yetki ayrımı: bu kontrolü yapılandıran kişi ile alarmı triaj eden kişi mümkünse farklı olsun. Küçük ekiplerde olmasa bile en azından farklı hesap kullanın.
Değişiklik yönetimi ile ilişki
Sürüüm yükseltmelerinden sonra regresyon testi yapın. 'Aynı config' yeni sürümde farklı varsayılanlara bağlanmış olabilir. Release note'daki breaking change bölümünü okuyun.
Eğitim tatbikatı
Dış bağımlılık (feed, imza seti, konteyner imajı) için bütünlük doğrulaması yapın. İmzasız feed ile gelen kural seti tedarik zinciri riskidir.
Doğrulama senaryosu
Bu konuyla ilgili ek bir kontrol: değişikliği yaptıktan sonra en az bir negatif test ve bir pozitif test tanımlayın. Negatif test 'alarm boşyere düşmemeli', pozitif test 'bilinen kötü örneği yakalamalı' der. İkisini de kaydedin.
Lab disiplini
Ortamlar arasında (lab, staging, production) aynı yapılandırmayı kör kopyalamayın. Adresler, sertifikalar ve kimlikler farklıdır. Şablon kullanın, değerleri envanterden doldurun.
Runbook'a taşımak
İlgili log ve kanıtları olaydan sonra en az kurum politikasının öngördüğü süre kadar saklayın. Disk dolunca en eski güvenlik logunu silmek klasik hatadır; ayrı retention politikası tanımlayın.
Uygulama notu
Bu rehberdeki komutları olduğu gibi kopyalamadan önce yolları, arayüz adlarını ve IP adreslerini kendi ortamınıza göre değiştirin. Dağıtım farkları (Debian/Ubuntu/RHEL/Windows sunucu) çıktı biçimini değiştirebilir; man sayfası ve resmi dokümantasyon birincil kaynaktır. Bir adım beklediğiniz sonucu vermezse önce yetki (sudo/Administrator), sonra sürüm, en son da yapılandırma dosyası sırasıyla bakın. Değişiklikleri geri almak için snapshot veya yapılandırma yönetimi (Ansible/Git) kullanın; 'elle bir dokundum' geçmişi denetimde kaybolur. Alarm ve log örneklerini ekip kanalında paylaşırken kişisel veri ve iç IP şemasını maskeleyin.
Yasal uyarı: Bu içerik eğitim amaçlıdır. Anlatılanları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız sistemlerde uygulayın. Yetkisiz erişim ve sistemlere müdahale 5237 sayılı TCK'nın 243, 244 ve 245. maddeleri kapsamında suçtur.