Merhabalar,
Bu yazımla beraber log analiz serisine başlıyoruz. Belirli saldırı senaryolarını kurduğum lab ortamında test edeceğim ardından bu saldırıları log analizi yaparak nasıl tespit edeceğimizi göreceğiz. Devamında bu analizler ile siem kuralları oluşturmaya çalışacağız.
Hadi gelin şimdi ilk senaryomuzu hazırlayıp test edelim.
Senaryo :
Lab ortamımızda bulunan Kali Linux makinasından ürettiğimiz bir reverse shell exe isini bir windows makinası üzerinde çalıştırarak windows makine üzerinde shell erişimi elde edeceğiz. Shell erişimi aldıktan sonra bazı işlemler yapacağız. Tüm bu işlemleri log analizi yaparak tespit etmeye çalışacağız.
Ortamımızdan bahsedecek olursak ortamımızda bir adet kali linux makinamız, bir tane windwos ve bir tane de ELK Stack kurulu ubuntu makinamız olacak. Kali linux üzerinden windows makinamıza saldırı testimiz yapacağız ardından windows makinası üzerinde oluşan logları winlogbeat ile toplayıp ELK Stack e ileteceğiz. Ve log analizlerimizi ELK Stack üzerinde yapacağız.
Windows sistemler linux sistemlere kıyasla çok daha ayrıntılı ve zengin loglar barındırır. Windows sistemler de yapılan hemen hemen her işlemin logu üretilebilir. Fakat windowsta varsayılan olarak birçok işlemin loglama politikası aktif olarak gelmemektedir. Sağlıklı ve kayda değer bir log analizi yapmak için windowsta bazı loglama politikalarını aktif etmemiz gerekiyor.
Log politikalarından bizim için en önemli olanlardan biri Audit Process Creation politikasıdır. Bu politika aktif edildiği zaman sistem üzerinde oluşan işlemlere (process) ait detaylı loglama yapılır. Hangi işlem , ne zaman , kim tarafından oluşturuldu gibi bilgileri üretilen loglarda bulabiliriz. Bu loglar 4688 event id si ile numaralandırılır. Bu politikayı local group policylerden aktif edebiliriz.
Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Detailed Tracking > Audit Process Creation
Ayrıca bu politikaya ek olarak oluşan processlerin cmd üzerinde hangi komutları çalıştırdığına dair bilgileri de tutulmasını istiyorsak ekstra bir politika da aktif etmemiz gerekiyor. Bu politika sayesinde 4688 loglarımız daha da zenginleştirilir.
Computer Configuration > Administrative Templates> System > Audit Process Creation > Include command line in process creation events
(Bu politakları aktif etmek yerine direk sysmon aracıda kullanabiliriz fakat şu an sysmon kullanmayacağız . Sysmon kullanarak log analizi de başka bir yazımızın konusu olsun)
Bu iki politikayı aktif edip testimize başlıyoruz.
İlk olarak Kali linux makinası üzerinden basit bir tane reverse shell exe si oluşturup windows makinesine kopyalıyoruz.
Ardından windows makinesi üzerinde bu exe yi çalıştırıp , windows makinesi üzerinde shell erişimi elde ediyoruz.
İlk olarak hangi kullanıcı ile erişim aldığımıza bakalım ardından sistemde kalıcılığı sağlamak için bir tane kullanıcı oluşturalım. Oluşturduğumuz kullanıcıyı yetkili local gruba ve rdp user grubuna ekleyelim. Son olarak logları temizleyip işlemlerimizi bitirelim.
Şimdi Kibana arayüzüne gidiyoruz ve winlogbeat ile topladığımız logları incelemeye başlayalım. Yukarda da bahsettiğimiz gibi ilk olarak 4688 loglarını filtereliyoruz. Sistem üzerinde çok fazla process çalıştığı için , analiz etmek biraz karmaşıklaşabilir özellikle uygulamalar update alırken çok fazla işlemin ve bunların loglarının oluştuğuna göreceksiniz .Ben hızlıca bazı filtereler uyguladım ve gereksiz logları çıkardım.
Şimdi sırasıyla loglarımızı inceleyelim :
(1) Ritim68.exe dosyası çalıştırılıyor. Yeni bir porcess oluşuyor Ritim68.exe (0x2818).
(2-3) Ritim68.exe processi cmd.exe(0x1484) processini oluşturuyor. Oluşan cmd(0x1484) process i ise conhost.exe(0x2604) porcessi ni çalıştırıyor ve saldırgan makinamızla iletişim kuruyor. (Tam bu noktada shell erişimi sağlamış oluyoruz.)
(4) Oluşan cmd processi üzerinden sırasıyla önce whoami komutu çalıştırılmış.
(5-6 ) Ardından yine aynı cmd(0x1484) proccesi “net user /add svc_update M4nd1rAk3!!!” komut ve parametereleri ile net.exe(0x1774) processini oluşturuyor. net.exe(0x1774) processi ise “user /add svc_update M4nd1rAk3!!!” parametreleri ile net1.exe(0x1d24) processini oluşturuyor. Bu işlemler ile beraber svc_update kullanıcısı oluşturulmuş oluyor.
(7-8) cmd.exe(0x1484) processimiz tekrardan “net localgroup administrators svc_update /add” komut ve parametereleri ile net.exe(0x2bac) processini oluşturuyor.Oluşan net.exe (0x2bac) processi “localgroup administrators svc_update /add” parametreleri ile net1.exe(0x1a50) processini oluşturuyor. Bu işlemler ile beraber svc_update kullanıcısı Administartor gruba eklenmiş oluyor.
(9-10) cmd.exe(0x1484) processimiz tekrardan “net localgroup “Remote Desktop Users” svc_update /add” komut ve parametreleri ile net.exe(0xf14) processini oluşturuyor. Oluşan net.exe (0xf14) processi “localgroup “Remote Desktop Users” svc_update /add” parametreleri ile net1.exe(0x3b8) processini oluşturuyor. Bu işlemler ile beraber svc_update kullanıcısı RDP Users grubuna eklenmiş oluyor.
(11) Yine aynı cmd exe mizde logları silme işleminende kullanıdığımız komutun ayrıntılarını gösteriyor. Bu log tek başına anlam ifade etmeyecektir çünkü gözüken komut windows event kanallarını listelemek için kullanılan bir komut. Bizde logları silmek için kullandığımız komut/scriptte dedik ki önce tüm event kanallarını listele ardından her birini tek tek temizle. Bu logun devamında ise listelenen her bir kanalın tek tek temizlendiğini gösteren loglar mevcut. Bunlarında bir kısmını aşağıda paylaşıyorum.
Bir sonraki yazımızda bu olayla ilgili nasıl siem kuralları geliştirebileceğimize bakacağız.
Kendinize iyi bakın…
