Log Analizinde İşe Yarayan 7 Pratik: Nöbet Masasından Notlar

Gece 23:40 sularıydı. Vardiyanın bitmesine yirmi dakika kala alarm paneline sarıdan kırmızıya dönen bir kural düştü: Multiple Failed Logons Followed by Success. Klasik parola püskürtme (password spraying) şüphesi. Ekrana dökülen loglara hızla baktım. Peş peşe gelen onlarca Event ID 4625 (başarısız oturum) ve hemen ardından gelen tek bir Event ID 4624 (başarılı oturum). Gözlerim parladı; faili bulduğumu sanıp ilgili IP adresini engellemek ve hedef sunucuyu ağdan izole etmek için butona uzandım. Yarım saat sonra sistem yöneticisi telefonun diğer ucunda öfkeyle nefes alıyordu. İzole ettiğim makine, şirket içi yedekleme sunucusuydu ve parola politikası gereği servisin şifresi güncellenmişken eski script arka planda SMB üzerinden oturum açmayı deniyordu. Saldırı falan yoktu. Yanlış alarmı gerçek sanmış, gece yarısı kritik bir operasyonu durdurmuştum.

O gece bana log analizinin yalnızca kurallara tıklayıp panodaki renkleri takip etmek olmadığını çok sert bir biçimde öğretti. Yıllar geçtikçe, gereksiz gürültüyü gerçek tehlikeden ayırmamı sağlayan belirli refleksler edindim. İşte doğrudan masada işe yarayan yedi pratik.

1. Tek Log Satırına Asla Güvenmeyin: Bağlam Her Şeydir

Bir log kaydı, bir filmin tamamı değil, yalnızca tek bir karesidir. Örneğin şüpheli bir powershell.exe çalıştırma kaydı gördünüz. Tek başına bu kayıt size hiçbir şey söylemez. Powershell'i kim çağırdı? Üst süreç (Parent Process) neydi? Eğer üst süreç cmd.exe veya wscript.exe ise durum başkadır; explorer.exe üzerinden kullanıcının kendi açtığı bir oturumsa bambaşkadır.

Windows ortamında çalışıyorsanız Event ID 4688 (Yeni Süreç Oluşturma) loglarında mutlaka komut satırı denetimini (Process Command Line Auditing) açmış olmanız gerekir. Yalnızca sürecin adını görmek yetersizdir. Sürecin aldığı parametreler, base64 ile kodlanmış komutlar veya -enc argümanı saldırının gerçek yüzünü ortaya koyar. Tek bir satıra bakıp karar vermeyin; üst süreci, alt süreci ve komut satırını aynı karede birleştirin.

2. Oturum Tiplerini (Logon Type) Ezbere Bilin

Windows Event ID 4624 gördüğümüzde çoğumuz kullanıcının başarıyla giriş yaptığını anlarız. Ancak analistin farkı Logon Type alanında ortaya çıkar. Bu numarayı yanlış okursanız benim yukarıda anlattığım hataya düşersiniz.

• Logon Type 2 (Interactive): Kullanıcı doğrudan konsolun, klavyenin başındadır veya yerel ekrandan giriş yapmıştır.
• Logon Type 3 (Network): Ağ üzerinden paylaşılan bir klasöre (SMB), yazıcıya veya IIS sunucusuna erişilmiştir. Parola denemeleri ve iç ağ taramaları sıklıkla burada görünür.
• Logon Type 10 (RemoteInteractive): RDP oturumudur. Bir saldırgan uzak masaüstü ile makineye girdiyse arayacağınız numara budur.

Olay anında filtreleme yaparken bu tipleri ayırt edemiyorsanız, normal bir dosya paylaşım trafiğini saldırı sanıp saatlerinizi çöpe atarsınız.

3. En Çok Tekrar Edenleri Değil, Tek Kalanları İnceleyin (Long-Tail Analizi)

Analistler genellikle en çok log üreten kaynaklara odaklanma eğilimindedir. Oysa saldırganlar nadir görülen yolları tercih eder. Splunk, ELK veya Sentinel üzerinde sorgu yazarken stats count by process_name yapıp listeyi küçükten büyüğe sıralamak (rare analysis) inanılmaz sonuçlar verir.

Bütün gün sistemde 40.000 kez çalışan svchost.exe normaldir. Ancak sistem dizininde olmayan, örneğin C:\Users\Public\ altında sadece 1 kez çalışmış ve adı svchost.exe olan bir süreç varsa, avınız oradadır. Güvenliğin kalbi nadirlikte yatar; gürültüyü filtreleyin ve kuyruğun en ucunda yapayalnız duran tekil kayıtlara bakın.

4. Sysmon Yoksa Kör Noktanız Çoktur

Standart Windows Security logları iyidir ancak saldırgan tekniklerini yakalamada yetersiz kalır. Örneğin bellek içi enjeksiyon (Process Injection - MITRE ATT&CK T1055) vakalarında standart 4688 logu genellikle hiçbir şey yakalayamaz; çünkü yeni bir süreç başlamaz, var olan meşru bir sürecin belleğine zararlı kod yazılır.

Burada devreye Sysmon girer. Sysmon Event ID 8 (CreateRemoteThread) veya Sysmon Event ID 10 (ProcessAccess) logları olmadan gelişmiş bir saldırıyı tespit etmek neredeyse imkansızdır. Bir sürecin başka bir sürecin belleğine yazma hakkı talep ettiğini gördüğünüz an, elinizde somut bir gösterge vardır. Altyapınızda Sysmon yoksa, log analizi yapmıyorsunuz; yalnızca etrafta dolaşan kırıntıları süpürüyorsunuz demektir.

5. Zaman Damgası Tuzağı: UTC ile Yerel Saat Ayrımı

İki farklı kaynaktan gelen logları korele ederken yapılan en yaygın hata saat dilimleridir. Güvenlik duvarı UTC log üretirken, uç nokta (EDR) yerel saatle (+03:00) log basıyorsa, saldırganın ilk adımını tespit ederken üç saatlik bir kayma yaşarsınız. Bu kayma nedeniyle saldırı zincirinin sırasını tamamen ters anlar, sebep ile sonucu birbirine karıştırırsınız.

SIEM içerisine giren tüm logların ayrıştırma (parsing) aşamasında UTC standardına çekildiğinden emin olun. Kendi analiz ekranınızda yerel saate dönüştürseniz bile, arka plandaki aramanızı kesinlikle UTC epoch zamanı üzerinden kurgulayın. Zamanı doğru hizalamayan bir analist, pusulasız gemi kullanır.

6. MITRE ATT&CK Eşlemesini Etiket Gibi Değil, Mekanizma Olarak Kullanın

Birçok raporda veya alarmda rastgele iliştirilmiş teknik numaraları görürsünüz. "Bu T1059 (Command and Scripting Interpreter)" demek kimseye bir şey kazandırmaz. Önemli olan o tekniğin logdaki ayak izidir.

Örneğin bir saldırgan T1059.001 (PowerShell) kullanıyorsa, sistemde Script Block Logging (Event ID 4104) aktif mi? Eğer aktif değilse, saldırganın çalıştırdığı script bellekte kaybolur gider. Tehdit modellemesi yaparken tekniği bir isim olarak değil, log kaynağındaki karşılığı olarak düşünmelisiniz. Neyi görüp neyi göremediğinizi bilmek, analiz hızınızı üç katına çıkarır.

7. Logların Bittiği Yerde Israr Etmeyin: Uç Noktaya Geçin

Bazen analistler SIEM ekranında saatlerce aynı log dökümünü yukarı aşağı kaydırarak bir ipucu bulmaya çalışır. Bu bir tuzaktır. Loglar bize sadece bir anomalinin olduğunu söyler; her zaman hikayenin tamamını içermez.

Şüpheli bir ağ bağlantısı veya açıklanamayan bir PowerShell etkinliği gördünüz ve loglar daha fazlasını vermiyor mu? Hemen durun. Uç noktaya bağlanın. İlgili sürecin ağ soketlerini canlı inceleyin, geçici dizinlerdeki dosya artıklarını kontrol edin, gerekirse bellek dökümü (memory dump) alın. Log analizi masada başlar ancak gerektiğinde canlı sistem analizine evrilmek zorundadır. Loglara gereğinden fazla anlam yükleyip vaktinizi ekranda tüketmeyin.