Allah’ın Rahmeti Ve Bereketi Üzerinize Olsun
Selamun aleyküm dostlarım. Bu makalemizde SIEM sistemlerine aktarılan Çeşitli veri kaynaklarını inceleyeceğiz. Veri korelasyonunun önemini anlayacağız ve soruşturma sırasında Windows, Linux, Web ve Ağ Loglarının değerini anlayacağız.
Analistler İçin SIEM’in faydaları
SIEM çözümleri, her Güvenlik Operasyon Merkezi’nde (SOC) ve herhangi bir SOC analistinin günlük çalışma hayatında hayati bir rol oynar.
SIEM’in neden bu kadar değerli olduğunu anlamak ve analiz açısından sunduğu temel avantajları incelemek için kısa bir göz atalım.
Bir örnek üzerinden inceleyelim.
Elimizde iki SOC Seviye 1 analisti var: hasan ve hüseyin. hasan, SIEM çözümüne sahip bir SOC’ta çalışırken, hüseyin böyle bir çözüme sahip değildir.
Her iki analist de aynı anda benzer uyarılar alır:
Hasan büyük resmi hızlıca görebilirken, Hüseyin değerli zamanını yalnızca bilgi toplamakla harcar. Bu durum, SIEM aracılığıyla sağlanan merkezileştirilmiş görünürlüğün daha hızlı ve daha etkili analiz yapılmasına nasıl olanak tanıdığını göstermektedir.
SIEM’inizde, iç ağ keşif etkinliğiyle ilgili bir uyarı aldığınızı düşünün. Elinizdeki tek bilgi, taramayı gerçekleştiren ana makinenin IP adresidir. Başka hiçbir bilgi yoktur. Bu uyarı IDS loglarından gelmektedir.
Bu bilgi tek başına çok yeterli değil, değil mi? Olayı anlamlandırabilmek için veriyi zenginleştirmeniz; IP adresinin hangi cihaza ait olduğunu ve etkinliği kimin başlattığını bulmanız gerekir.
IDS uyarısını ilişkilendirerek Windows Olay Günlüklerini (Event Logs) veya Sysmon kayıtlarını inceleyebilir ve bağlam oluşturabilirsiniz:
Bu etkinliği kimin gerçekleştirdiğini, nerede yapıldığını ve muhtemelen hangi aracın kullanıldığını belirleyebilirsiniz.
Parça parça ilerledikçe yapboz tamamlanır ve bu etkinliğin kötü amaçlı mı yoksa sadece önemsiz bir gürültü mü olduğuna karar vermenize yardımcı olur.
Örneğin, bir kullanıcı için olağandışı bir oturum açma konumuyla ilgili bir uyarı alırsanız, geçmiş logları inceleyerek daha önce bu konumdan veya IP adresinden giriş yapıp yapmadığını görebilirsiniz. Bu, kullanıcının davranışındaki örüntüleri belirlemenize ve etkinliğin kötü amaçlı bir girişim mi yoksa meşru bir işlem mi olduğunu değerlendirmenize yardımcı olur.
Elbette bunlar, SIEM’in SOC için sunduğu tüm avantajlar değildir. Görselleştirme, tespit kuralları ve otomasyon süreçleri gibi daha birçok özellik bulunmaktadır
Günlük Kayıt Kaynaklarına Genel Bakış
Bir analistin SIEM içerisinde karşılaşabileceği log kaynaklarını ve bunların analiste sağlayabileceği değeri inceleyelim.
Her kuruluş, logların SIEM’e aktarılabileceği farklı türde kaynaklara sahiptir. Bunlar arasında iş istasyonları, sunucular, ağ cihazları, kimlik sağlayıcıları, bulut hizmetleri, çeşitli uygulamalar ve daha fazlası bulunur. Bunu bir ağaca benzetmek faydalı olabilir: Kuruluş ağacın kendisini temsil ederken, kökler ise bu ağacı oluşturan kaynakları temsil eder. Bu bileşenler çoğu zaman her kuruluşa özgü olsa da, hepsi bir araya gelerek mantıksal bir yapı oluşturur.
Bu kaynakların tamamından ya da yalnızca bir kısmından gelen loglar SIEM platformuna gönderilir ve analist bu logları analiz yapmak ve olaylar arasında korelasyon kurmak için kullanabilir.
Bu makinelerin tamamından SIEM’e izleme amacıyla önemli miktarda veri gönderilir. Bu durum şaşırtıcı değildir, çünkü neredeyse her saldırı bir şekilde sistemleri (hostları) içerir. Bu nedenle, bu cihazlardan gelen veriler bir soruşturma sırasında son derece değerlidir
Tıpkı bir ağacın köklerinin dalları birbirine bağlayıp desteklemesi gibi, ağ logları da analistlere cihazların birbiriyle nasıl iletişim kurduğunu görme imkânı sağlar.
Bu loglar, farklı kaynaklardan gelen veriler ilişkilendirilirken değerli içgörüler sunabilir ve bu nedenle bütüncül bir tablo oluşturmanın kritik bir parçasıdır.
Saldırganlar genellikle bir kuruluşun ortamına web zafiyetleri üzerinden erişim sağladıkları için, web olaylarının dikkatli bir şekilde izlenmesi, bir SOC ortamında her analistin günlük sorumluluklarının önemli bir parçasıdır.
Yukarıda bahsedilen veri kaynaklarına ek olarak SIEM, AWS ve Azure gibi bulut platformlarından, Entra ID gibi çeşitli kimlik sağlayıcılardan ve üçüncü taraf uygulamalardan da log toplar
Loglar farklı zaman dilimlerindeki sistemlerden gelebilir. Bazıları UTC formatında, bazıları yerel zaman diliminde olabilir ve bazıları ise hiç zaman dilimi bilgisi içermeyebilir.
Kendi yerel zamanınızın SIEM’de ayarlanmış zamandan farklı olabileceğini anlamak önemlidir.
Örneğin UTC-2 zaman diliminde çalıştığınızı, ancak Splunk SIEM’de logların UTC+2’ye normalleştirildiğini düşünelim.
Sizin için saat 17:00 iken, aynı loglar Splunk üzerinde 21:00 olarak görünebilir. Bu, logların dört saat gecikmeli işlendiği anlamına gelmez; yalnızca zaman ayarları arasındaki bir farktır.
Bu yüzden olayları analiz ederken hangi zaman dilimleriyle çalıştığınıza her zaman dikkat etmelisiniz. Bu, gerçekten ne olduğunu ve ne zaman olduğunu anlamada büyük fark yaratabilir.
İşte bu noktada normalizasyon devreye girer.
Amaç, tüm bu formatları tek ve tutarlı bir yapıya dönüştürmektir; böylece loglarla çalışmak daha kolay hale gelir. Analistler SIEM içinde her şeyi tek bir standart görünümde görebilir. Bu da arama yapmayı, filtrelemeyi ve olayları birbirine bağlamayı çok daha basit hale getirir. Normalizasyon olmadan, her log kaynağı tamamen farklı bir bulmacayı çözmek gibi olurdu.
Windows Logs
SIEM kullanarak Windows loglarını analiz ederken genellikle iki ana veri kaynağından bahsederiz: WinEventLogs ve Sysmon. İkincisinin log toplamaya başlayabilmesi için ayrıca kurulması ve yapılandırılması gerekir.
Ancak bu iki veri kaynağının birleştirilmesi, etkinliklerin analiz edilmesinde net bir görünürlük sağlar.
Şimdi her birine kısaca bakalım.
Kötü amaçlı süreç çalıştırma, ağ bağlantıları, olası process injection (süreç enjeksiyonu), registry değişiklikleri ve dosya oluşturma gibi birçok aktivitenin tespit edilmesine yardımcı olur.
PowerShell ile ilgili başlatılan süreçleri (EventCode=1) tespit eden ve EncodedCommand PowerShell parametresini içeren bir arama yazalım
Bu örnekte, WINHOST05 adlı ana bilgisayarda C:\Users\Public dizininden kötü amaçlı update_config.js dosyasının çalıştırıldığı tespit edildi. Bu durum, cmd.exe’nin PowerShell’i encoded (şifrelenmiş) bir komutla başlatmasına yol açtı.
Aşağıdaki görselde gösterildiği gibi, Temp klasöründen çalışan PPn423.exe adlı şüpheli süreç tarafından 83.222.191.2 IP adresindeki alışılmadık 9999 numaralı porta yönelik şüpheli bir bağlantı başlatıldığı tespit edildi. Ayrıca bu IP adresinin tehdit istihbaratı (TI) platformlarında kontrol edilmesi önerilir.
Bunlar Sysmon’un faydalı olabileceği yalnızca iki örnektir; gerçekte, bu logların anormallikleri tespit etmeye yardımcı olabileceği çok daha fazla durum bulunmaktadır.
Saldırgan, büyük olasılıkla kalıcılık (persistence) sağlamak amacıyla bir yedek kullanıcı hesabı oluşturma yoluna gitmiş ve bu hesap WINHOST05 ana bilgisayarında ted-admin tarafından oluşturulup etkinleştirilmiştir.
Bu loglar, servisler üzerinden gerçekleştirilen olası kalıcılık (persistence) veya yetki yükseltme (privilege escalation) girişimlerini incelemek için oldukça uygun bir kaynaktır. Şimdi ele geçirilmiş WINHOST05 sistemindeki aktiviteyi inceleyelim ve anormallikleri tespit etmeye çalışalım. Bunun için 7045 ve 7036 olmak üzere iki olay kodunu kullanacağız. Bu kodlar sırasıyla servis oluşturma ve servis başlatma/durdurma olaylarını ifade eder.
Arama sonuçlarından görebildiğimiz kadarıyla, host üzerinde “User Updates” adlı bir servis oluşturulmuş ve başlatılmıştır. Bu servis, SYSTEM hesabı altında Temp dizini içerisinde yer alan kötü amaçlı RNSfnsjdf.exe dosyasını çalıştırmaktadır.
Bu durum büyük olasılıkla bir yetki yükseltme (privilege escalation) girişimidir; çünkü hatırladığımız üzere saldırgan daha önce yalnızca ted-admin hesabına erişim sağlamıştı.
Linux Logs
SIEM’de Linux sistemlerini analiz ederken genellikle iki temel log kaynağıyla başlanır.
İlk olarak, kullanıcı girişleri ve sudo kullanımı gibi kimlik doğrulama ile ilgili aktiviteleri takip eden auth.log dosyasını görürsünüz. Bu loglar, başarısız giriş denemelerini, yetkisiz erişim girişimlerini veya yetki yükseltme (privilege escalation) faaliyetlerini tespit etmek için oldukça önemlidir.
Daha sonra, genel sistem düzeyindeki olayları kaydeden syslog ile karşılaşırsınız. Buradan servis yeniden başlatmaları, cron job’lar ve arka plan süreçleri gibi aktiviteleri izleyebilirsiniz. Bu veriler, zaman çizelgesi oluştururken veya sistemin zaman içindeki davranışını anlamaya çalışırken oldukça faydalıdır. Bu araçlar görünürlüğü önemli ölçüde artırır.
97 olay tespit edildi ve son kayıtlar, ubuntu kullanıcısına yapılan başarılı giriş denemelerini göstermektedir. Bu durum büyük olasılıkla başarılı bir brute-force saldırısı olarak sınıflandırılabilir ve L2 seviyesine yükseltilmesi gereken bir aktivitedir. Öğrenme açısından, neler olduğunu birlikte inceleyelim.
Aşağıdaki görselden de açıkça görüldüğü üzere, saldırgan root hesabına erişim sağlamayı başarmıştır. Bunun tam olarak nasıl gerçekleştirildiği yalnızca auth.log üzerinden belirlenemez; bunu tespit etmek için ek loglara ihtiyaç vardır.
Bu senaryoda syslog, özellikle cron job’lar veya servisler aracılığıyla kalıcılık oluşturmaya yönelik aktiviteleri aramak için oldukça faydalı olabilir.
Üç ilginç olay tespit ettik. İlk olarak, /tmp klasöründen çalışan şüpheli pnr5433sw.sh dosyasının her 5 dakikada bir cron aracılığıyla çalıştırıldığını görebiliyoruz. Ardından, 10.10.101.12 IP adresine 9999 numaralı port üzerinden bağlantı kurmaya çalışan bir Perl reverse shell’e dair açık belirtiler mevcut.
Web Application Logları
Analiz için diğer önemli veri kaynakları arasında Web de yer alır. Şimdi bunları daha detaylı bir şekilde inceleyelim.
Analiz açısından en faydalı olanlar access loglardır; bu loglar, web sitesi kaynaklarına yapılan istekleri tespit etmenizi sağlar. Bu loglar genellikle tarama (scanning), DDoS girişimleri, çeşitli web tabanlı saldırılar ve web shell gibi kötü amaçlı aktivitelerin izlerini içerir. Ayrıca error loglar da değerli bilgiler sağlayarak olası hataları veya sorunları anlamanıza yardımcı olur.
Şimdi web access logları kullanılarak farklı türde kötü amaçlı aktivitelerin nasıl tespit edilebileceğini inceleyelim.
Brute-force aktiviteleri çok sayıda tekrarlanan deneme içerdiğinden, 5 dakika içinde count > 25 gibi bir eşik belirleyebilirsiniz. Aktivitenin kaynağını tespit etmek için sonuçları clientip alanına göre gruplayın. user-agent gibi diğer alanlar da ek bağlam sağlayabilir. Aşağıda hazır sorgu yer almaktadır.
Sonuç olarak, örneğimizde 167.172.41.141 IP adresinin wp-login.php sayfasına tam 160 istek gönderdiğini tespit edebiliriz. İlginç bir şekilde, User-Agent satırında Hydra ifadesi görülmektedir; bu, saldırganlar tarafından brute-force saldırıları gerçekleştirmek için sıklıkla kullanılan popüler bir araçtır.
Web shell’ler genellikle kısa zaman diliminde birkaç şüpheli istek üretir, bu nedenle count > 2 gibi bir eşik belirlemek faydalı olabilir. Sonuçları domain bazında gruplayarak desenleri tespit edebilir ve clientip ile user-agent alanlarını inceleyerek saldırganla ilgili izleri analiz edebilirsiniz. Aşağıda hazır sorgu yer almaktadır.
Splunk üzerinde olası bir DDoS saldırısını incelerken, sunucunun aşırı yüklenmiş olabileceğini gösteren 503 durum kodunu kontrol edin. Ayrıca, kısa bir zaman diliminde çok yüksek sayıda isteği (örneğin 10 dakika içinde 100.000’den fazla) IP adresine göre filtreleyerek inceleyin. Hedeflenen domain’i, kullanılan user-agent bilgisini ve URI path’i kontrol ederek desenleri veya saldırgan izlerini tespit edin. Aşağıda hazır sorgu yer almaktadır.
Ve bu örnekten, kaynağın son 10 dakika boyunca kullanılamaz durumda olduğunu ve 1,5 milyondan fazla istek aldığını görebiliyoruz; bu da olası bir saldırıyı doğrulamaktadır.
Okuduğunuz için teşekkür ederim
Selamun aleyküm dostlarım. Bu makalemizde SIEM sistemlerine aktarılan Çeşitli veri kaynaklarını inceleyeceğiz. Veri korelasyonunun önemini anlayacağız ve soruşturma sırasında Windows, Linux, Web ve Ağ Loglarının değerini anlayacağız.
Analistler İçin SIEM’in faydaları
SIEM çözümleri, her Güvenlik Operasyon Merkezi’nde (SOC) ve herhangi bir SOC analistinin günlük çalışma hayatında hayati bir rol oynar.
SIEM’in neden bu kadar değerli olduğunu anlamak ve analiz açısından sunduğu temel avantajları incelemek için kısa bir göz atalım.
Merkezileştirme
SIEM’i bir SOC için bu kadar faydalı kılan ilk unsurlardan biri merkezileştirmedir. Ağ cihazları, bulut hizmetleri, kimlik sağlayıcıları ve daha birçok farklı yerde bulunan günlükleri (logları) ayrı ayrı kontrol etmek yerine, SIEM tüm bu verileri tek bir yerde toplamanıza olanak tanır. Bu sayede bir analistin soruşturma sırasında sistemler arasında geçiş yapmasına gerek kalmaz. Her şey tek bir çözüm içinde erişilebilir olduğundan, çalışma süreci çok daha akıcı ve verimli hale gelir.Elimizde iki SOC Seviye 1 analisti var: hasan ve hüseyin. hasan, SIEM çözümüne sahip bir SOC’ta çalışırken, hüseyin böyle bir çözüme sahip değildir.
Her iki analist de aynı anda benzer uyarılar alır:
- Ağ etkinliğinde şüpheli bir artış.
- Bir uç noktada kötü amaçlı bir komut tespit edilmesi.
Hasan büyük resmi hızlıca görebilirken, Hüseyin değerli zamanını yalnızca bilgi toplamakla harcar. Bu durum, SIEM aracılığıyla sağlanan merkezileştirilmiş görünürlüğün daha hızlı ve daha etkili analiz yapılmasına nasıl olanak tanıdığını göstermektedir.
Korelasyon
SIEM’in bir diğer temel gücü ise korelasyondur. Korelasyon, birbirinden bağımsız olayları birbiriyle ilişkilendirerek bir yapbozun parçaları gibi bir araya getirme ve bütüncül bir görünüm oluşturma yeteneğidir. Şimdi bir senaryo üzerinden ilerleyelim.SIEM’inizde, iç ağ keşif etkinliğiyle ilgili bir uyarı aldığınızı düşünün. Elinizdeki tek bilgi, taramayı gerçekleştiren ana makinenin IP adresidir. Başka hiçbir bilgi yoktur. Bu uyarı IDS loglarından gelmektedir.
Bu bilgi tek başına çok yeterli değil, değil mi? Olayı anlamlandırabilmek için veriyi zenginleştirmeniz; IP adresinin hangi cihaza ait olduğunu ve etkinliği kimin başlattığını bulmanız gerekir.
Bu etkinliği kimin gerçekleştirdiğini, nerede yapıldığını ve muhtemelen hangi aracın kullanıldığını belirleyebilirsiniz.
Parça parça ilerledikçe yapboz tamamlanır ve bu etkinliğin kötü amaçlı mı yoksa sadece önemsiz bir gürültü mü olduğuna karar vermenize yardımcı olur.
Geçmiş Olaylar
SIEM ayrıca yalnızca mevcut etkinlikleri değil, geçmişte gerçekleşmiş olayları da incelemenize olanak tanır. Bu sayede daha önce başlamış ancak o anda fark edilmemiş olabilecek desenleri veya tehditleri tespit etmenize yardımcı olur.Elbette bunlar, SIEM’in SOC için sunduğu tüm avantajlar değildir. Görselleştirme, tespit kuralları ve otomasyon süreçleri gibi daha birçok özellik bulunmaktadır
Günlük Kayıt Kaynaklarına Genel Bakış
Bir analistin SIEM içerisinde karşılaşabileceği log kaynaklarını ve bunların analiste sağlayabileceği değeri inceleyelim.
Her kuruluş, logların SIEM’e aktarılabileceği farklı türde kaynaklara sahiptir. Bunlar arasında iş istasyonları, sunucular, ağ cihazları, kimlik sağlayıcıları, bulut hizmetleri, çeşitli uygulamalar ve daha fazlası bulunur. Bunu bir ağaca benzetmek faydalı olabilir: Kuruluş ağacın kendisini temsil ederken, kökler ise bu ağacı oluşturan kaynakları temsil eder. Bu bileşenler çoğu zaman her kuruluşa özgü olsa da, hepsi bir araya gelerek mantıksal bir yapı oluşturur.
Bu kaynakların tamamından ya da yalnızca bir kısmından gelen loglar SIEM platformuna gönderilir ve analist bu logları analiz yapmak ve olaylar arasında korelasyon kurmak için kullanabilir.
Host Tabanlı Log Kaynakları
Host tabanlı log kaynakları, kuruluş içerisindeki iş istasyonları ve sunucular gibi bireysel cihazlardan gelir. Her kuruluş, çalışanların görevlerini yerine getirebilmesi için iş istasyonlarına ve web sunucuları, SQL sunucuları, DNS sunucuları gibi farklı amaçlara hizmet eden sunuculara ihtiyaç duyar. Genellikle sistemlerden gelen bu tür davranışları izleriz.Ağ Tabanlı Log Kaynakları
Ağ tabanlı log kaynakları, firewall’lar, router’lar, IDS ve IPS gibi ağ cihazlarından ve diğer sistemlerden veri toplar. Bu cihazlar, ağ genelindeki trafik ve bağlantıları izleme konusunda kritik bir rol oynar.Bu loglar, farklı kaynaklardan gelen veriler ilişkilendirilirken değerli içgörüler sunabilir ve bu nedenle bütüncül bir tablo oluşturmanın kritik bir parçasıdır.
Web Tabanlı Log Kaynakları
Ve elbette, neredeyse her kuruluşun kendi web uygulaması vardır ve bu uygulamalardan gelen loglar da SIEM’e gönderilir.Saldırganlar genellikle bir kuruluşun ortamına web zafiyetleri üzerinden erişim sağladıkları için, web olaylarının dikkatli bir şekilde izlenmesi, bir SOC ortamında her analistin günlük sorumluluklarının önemli bir parçasıdır.
Zaman Tuzakları
Analistlerin SIEM ile çalışırken karşılaştığı yaygın zorluklardan biri zamandır; özellikle de farklı log kaynakları arasında zamanın nasıl kaydedildiğidir.Loglar farklı zaman dilimlerindeki sistemlerden gelebilir. Bazıları UTC formatında, bazıları yerel zaman diliminde olabilir ve bazıları ise hiç zaman dilimi bilgisi içermeyebilir.
Kendi yerel zamanınızın SIEM’de ayarlanmış zamandan farklı olabileceğini anlamak önemlidir.
Örneğin UTC-2 zaman diliminde çalıştığınızı, ancak Splunk SIEM’de logların UTC+2’ye normalleştirildiğini düşünelim.
Sizin için saat 17:00 iken, aynı loglar Splunk üzerinde 21:00 olarak görünebilir. Bu, logların dört saat gecikmeli işlendiği anlamına gelmez; yalnızca zaman ayarları arasındaki bir farktır.
Bu yüzden olayları analiz ederken hangi zaman dilimleriyle çalıştığınıza her zaman dikkat etmelisiniz. Bu, gerçekten ne olduğunu ve ne zaman olduğunu anlamada büyük fark yaratabilir.
Log Normalizasyonu
Farklı loglar çeşitli formatlarda gelir. Bazıları JSON, bazıları XML, hatta düz metin (plain text) formatında olabilir. Her sistem olayları kendi yöntemine göre, farklı alan adları ve yapılar kullanarak kaydeder.İşte bu noktada normalizasyon devreye girer.
Amaç, tüm bu formatları tek ve tutarlı bir yapıya dönüştürmektir; böylece loglarla çalışmak daha kolay hale gelir. Analistler SIEM içinde her şeyi tek bir standart görünümde görebilir. Bu da arama yapmayı, filtrelemeyi ve olayları birbirine bağlamayı çok daha basit hale getirir. Normalizasyon olmadan, her log kaynağı tamamen farklı bir bulmacayı çözmek gibi olurdu.
Windows Logs
SIEM kullanarak Windows loglarını analiz ederken genellikle iki ana veri kaynağından bahsederiz: WinEventLogs ve Sysmon. İkincisinin log toplamaya başlayabilmesi için ayrıca kurulması ve yapılandırılması gerekir.
Ancak bu iki veri kaynağının birleştirilmesi, etkinliklerin analiz edilmesinde net bir görünürlük sağlar.
Sysmon
Windows üzerinde ek bir ve bazı durumlarda birincil log kaynağı olan Sysmon, son derece güçlü bir araçtır. Geniş bir yelpazede etkinlik türünü kaydederek analiz sırasında yüksek seviyede görünürlük sağlar. Sysmon logları kullanılarak bir analist, sistem davranışına derinlemesine görünürlük kazandıran çeşitli etkinlik türlerini gözlemleyebilir.Kötü amaçlı süreç çalıştırma, ağ bağlantıları, olası process injection (süreç enjeksiyonu), registry değişiklikleri ve dosya oluşturma gibi birçok aktivitenin tespit edilmesine yardımcı olur.
Kötü Amaçlı Süreç Çalıştırma
Şüpheli kodlanmış bir PowerShell komutunun çalıştırılmasıyla ilgili bir uyarı aldığınızı düşünelim. Şimdi bu etkinliği analiz etmeniz gerekiyor. Bu durumda SIEM’i nasıl kullanırsınız? Splunk SIEM üzerinden loglarda hangi faydalı bilgilere ulaşabileceğimizi görmek için bir Splunk sorgusu kullanmayı deneyelim.PowerShell ile ilgili başlatılan süreçleri (EventCode=1) tespit eden ve EncodedCommand PowerShell parametresini içeren bir arama yazalım
Kod:
index=winenv EventCode=1 ** AND *EncodedCommand*
| table _time ComputerName ParentUser ParentImage ParentCommandLine Image CommandLineŞüpheli Ağ Bağlantısı
Bu hikâye burada bitmedi, çünkü birkaç dakika sonra WINHOST05 sisteminden bu kez şüpheli bir ağ bağlantısıyla ilgili başka bir uyarı aldık. Sysmon loglarını kullanarak ne olduğunu anlamaya çalışalım. Bunun için, ağ bağlantılarını tespit eden EventCode 3’ü arayacak ve etkinliğin kaynağı olan WINHOST05 hostuna göre filtreleme yapacağız.
Kod:
index=winenv EventCode=3 ComputerName=WINHOST05
| table _time ComputerName Image SourceIp SourcePort DestinationIp DestinationPort ProtocolWinEventLogs
Windows Event Logs, çok sayıda farklı ve benzersiz log dosyasını içerir. Muhtemelen en çok Security, System ve Application loglarına aşinasınızdır; ancak gerçekte sistem, bu üç logun ötesinde 200’den fazla farklı log kanalına sahiptir.Windows Güvenlik Logları
En sık incelenen ve başvurulan loglar Güvenlik (Security) loglarıdır, peki bunun sebebi nedir? Gelin bu logları neden bu kadar önemli ve soruşturma için neden kritik olduklarını inceleyelim. Analistler Security logları üzerinden kullanıcı kimlik doğrulama denemeleri, hesap oluşturma veya değiştirme, dosyalara ve registry anahtarlarına erişim, süreç çalıştırma, sistem yeniden başlatma veya log temizleme ve denetim ya da güvenlik politikalarında yapılan değişiklikler gibi aktiviteleri tespit edebilir. Bir SOC analisti yeni vardiyasına başladığında, bu host üzerinde şüpheli aktivite olduğuna dair bilgi kendisine iletildi. Sadece birkaç saat içinde aynı makineden bu kez bir kullanıcı hesabı oluşturma uyarısı geldi. Bu durum, saldırganın hâlâ sistemde aktif olduğunu göstermektedir. Ne olduğunu tespit etmek için Security loglarını incelememiz ve bu bilgiyi SOC L2 analistiyle paylaşmamız gerekiyor.
Kod:
index=winenv EventCode=4720 OR EventCode=4722
| table _time EventCode ComputerName Subject_Account_Name Target_Account_Name New_Account_Account_Name KeywordsWindows Sistem Logları
Bu loglar, işletim sistemi ve temel servisleri tarafından oluşturulan olayları kaydeder. Servislerle ilgili olayları, sistem düzeyindeki aktiviteleri ve olası hataları tespit etmeye yardımcı olurlar.Bu loglar, servisler üzerinden gerçekleştirilen olası kalıcılık (persistence) veya yetki yükseltme (privilege escalation) girişimlerini incelemek için oldukça uygun bir kaynaktır. Şimdi ele geçirilmiş WINHOST05 sistemindeki aktiviteyi inceleyelim ve anormallikleri tespit etmeye çalışalım. Bunun için 7045 ve 7036 olmak üzere iki olay kodunu kullanacağız. Bu kodlar sırasıyla servis oluşturma ve servis başlatma/durdurma olaylarını ifade eder.
Kod:
index=winenv EventCode=7045 OR EventCode=7036 ComputerName=WINHOST05
| table _time EventCode ComputerName Service_Name Service_Account Service_File_Name MessageBu durum büyük olasılıkla bir yetki yükseltme (privilege escalation) girişimidir; çünkü hatırladığımız üzere saldırgan daha önce yalnızca ted-admin hesabına erişim sağlamıştı.
Linux Logs
SIEM’de Linux sistemlerini analiz ederken genellikle iki temel log kaynağıyla başlanır.
İlk olarak, kullanıcı girişleri ve sudo kullanımı gibi kimlik doğrulama ile ilgili aktiviteleri takip eden auth.log dosyasını görürsünüz. Bu loglar, başarısız giriş denemelerini, yetkisiz erişim girişimlerini veya yetki yükseltme (privilege escalation) faaliyetlerini tespit etmek için oldukça önemlidir.
Daha sonra, genel sistem düzeyindeki olayları kaydeden syslog ile karşılaşırsınız. Buradan servis yeniden başlatmaları, cron job’lar ve arka plan süreçleri gibi aktiviteleri izleyebilirsiniz. Bu veriler, zaman çizelgesi oluştururken veya sistemin zaman içindeki davranışını anlamaya çalışırken oldukça faydalıdır. Bu araçlar görünürlüğü önemli ölçüde artırır.
Kimlik Doğrulama Logları
Kimlik doğrulama logları, SIEM içinde Linux sistemlerini analiz ederken en önemli veri kaynaklarından biridir. Kullanıcıların sistemle nasıl etkileşim kurduğunu, özellikle giriş denemeleri ve yetki kullanımı açısından anlamanıza yardımcı olur.Olağandışı giriş aktiviteleri
Şimdi gerçek bir senaryoya geçelim ve SOC ortamında bir durumu inceleyelim. Bir SOC L1 analisti olarak, sistemde ubuntu kullanıcısına yapılan olağandışı bir SSH girişine dair bir uyarı aldınız. Bu durumda, ubuntu kullanıcısı için başarılı ve başarısız giriş denemelerini arayan bir sorgu yazalım.
Kod:
index= source="auth.log" *ubuntu* process=
| search "Accepted password" OR "Failed password"Yetki Yükseltme Davranışları
Saldırganlar genellikle sistemdeki belirli dosyalara erişebilmek için root yetkisine ihtiyaç duyar. Şimdi, bizim senaryomuzda bu tür bir aktiviteye dair herhangi bir iz olup olmadığını inceleyelim.
Kod:
index= source="auth.log" *su*
| sort + _timeSistem Logları
Sistem logları, görünürlük sağlamak açısından bir diğer önemli kaynaktır. Servis aktiviteleri, sistem yeniden başlatmaları ve cron görevleri gibi olayları kaydederler. Bu bilgiler, genellikle kalıcılık (persistence) veya yetki yükseltme (privilege escalation) girişimleriyle ilişkilendirilen olağandışı sistem davranışlarını tespit etmek için oldukça faydalıdır.Kalıcılık (Persistence) Mekanizmaları
Bu görevdeki, saldırganın ubuntu hesabından root hesabına başarılı bir şekilde geçtiği vakayı hâlâ hatırlıyor olmalısınız.Bu senaryoda syslog, özellikle cron job’lar veya servisler aracılığıyla kalıcılık oluşturmaya yönelik aktiviteleri aramak için oldukça faydalı olabilir.
Kod:
index= sourcetype=syslog ("CRON" OR "cron")
| search ("python" OR "perl" OR "ruby" OR ".sh" OR "bash" OR "nc")Web Application Logları
Analiz için diğer önemli veri kaynakları arasında Web de yer alır. Şimdi bunları daha detaylı bir şekilde inceleyelim.
Web Log Kaynakları
Neredeyse her kuruluşun kendi web sitesi ve dolayısıyla bu siteyi çalıştıran bir web sunucusu vardır. Bu web sunucularından gelen loglar Apache, Nginx ve diğer kaynaklardan toplanır.Analiz açısından en faydalı olanlar access loglardır; bu loglar, web sitesi kaynaklarına yapılan istekleri tespit etmenizi sağlar. Bu loglar genellikle tarama (scanning), DDoS girişimleri, çeşitli web tabanlı saldırılar ve web shell gibi kötü amaçlı aktivitelerin izlerini içerir. Ayrıca error loglar da değerli bilgiler sağlayarak olası hataları veya sorunları anlamanıza yardımcı olur.
Şimdi web access logları kullanılarak farklı türde kötü amaçlı aktivitelerin nasıl tespit edilebileceğini inceleyelim.
Brute Force Aktivitesi
Bir SOC L1 analisti olarak vardiyanızdasınız ve WordPress giriş sayfasını hedef alan olası bir brute-force saldırısına dair bir uyarı aldığınızı düşünün. Bu durumu incelemek için, öncelikle giriş sayfası URL’sini (örneğin /wp-login.php) belirlemeniz ve POST isteklerini filtrelemeniz önerilir.Brute-force aktiviteleri çok sayıda tekrarlanan deneme içerdiğinden, 5 dakika içinde count > 25 gibi bir eşik belirleyebilirsiniz. Aktivitenin kaynağını tespit etmek için sonuçları clientip alanına göre gruplayın. user-agent gibi diğer alanlar da ek bağlam sağlayabilir. Aşağıda hazır sorgu yer almaktadır.
Kod:
index=* method=POST uri_path="/wp-login."
| bin _time =5m
| stats values(referer_domain) as referer_domain values(status) as status values(useragent) as UserAgent values(uri_path) as uri_path count by clientip _time
| where count > 25
| table referer_domain clientip UserAgent uri_path count statusOlası Web Shell
Kısa bir süre sonra, vardiyanız sırasında olası bir web shell aktivitesine dair ikinci bir uyarı alırsınız. Splunk üzerinde web shell aktivitelerini incelemek için, .php, .asp, .jsp veya .exe gibi script ya da çalıştırılabilir dosya türlerine yapılan istekleri aramanız önerilir. Ayrıca POST ve GET metodlarını ve status=200 yanıt kodunu birlikte filtreleyebilirsiniz.Web shell’ler genellikle kısa zaman diliminde birkaç şüpheli istek üretir, bu nedenle count > 2 gibi bir eşik belirlemek faydalı olabilir. Sonuçları domain bazında gruplayarak desenleri tespit edebilir ve clientip ile user-agent alanlarını inceleyerek saldırganla ilgili izleri analiz edebilirsiniz. Aşağıda hazır sorgu yer almaktadır.
Kod:
index=*
| search status=200 AND uri_path IN(*., *.phtm, *.asp, *.aspx, *.jsp, *.exe) AND (method=POST AND method=GET)
| stats values(status) as status values(useragent) as UserAgent values(method) as method
values() as values(clientip) as clientip count by referer_domain
| where count > 2
| table referer_domain count method status clientip UserAgentDDoS Aktivitesi
Vardiyanız neredeyse bitti, ancak bilgisayarınızı kapatmak için acele etmeyin; bugün için muhtemelen son olan yeni bir uyarı geldi. Bu uyarı, olası bir DDoS saldırısıyla ilgilidir.Splunk üzerinde olası bir DDoS saldırısını incelerken, sunucunun aşırı yüklenmiş olabileceğini gösteren 503 durum kodunu kontrol edin. Ayrıca, kısa bir zaman diliminde çok yüksek sayıda isteği (örneğin 10 dakika içinde 100.000’den fazla) IP adresine göre filtreleyerek inceleyin. Hedeflenen domain’i, kullanılan user-agent bilgisini ve URI path’i kontrol ederek desenleri veya saldırgan izlerini tespit edin. Aşağıda hazır sorgu yer almaktadır.
Kod:
index=* status=503
| bin _time =10m
| stats values(referer_domain) as referer_domain values(status) as status values(useragent) as UserAgent values(uri_path) as uri_path count by clientip _time
| where count > 100000
| table _time referer_domain clientip UserAgent uri_path count statusOkuduğunuz için teşekkür ederim
CW-Ommah
Bug Researchers Tim Sundu...
Bug Researchers Tim Sundu...
