Allah’ın Rahmeti Ve Bereketi Üzerinize Olsun
Selamun aleyküm dostlarım. Bu makalemizde bir SOC ortamında uyarıların nasıl doğru şekilde incelendiğine, Linux sistemlerinde brute force saldırılarının nasıl araştırılacağını, windows sistemlerindeki kalıcılık mekanizmasının ne olduğunu inceleyeceğiz. Güvenlik açığı bulunan bir web sunucusundaki web shell’i analiz edeceğiz ve son olarak vediğimiz konu başlıklarından ilerleyerek, saldırıları splunk vasıtasıyla inceleyeceğiz Allah’ın izniyle.
İlk Erişim Uyarısı
Bir analist olarak vardiyanız sırasında karşılaşabileceğiniz üç farklı senaryoyu inceleyeceğiz. İlk senaryo bir Linux ana sisteminde gerçekleşecek ve soruşturma sürecimiz boyunca burada tam olarak neler yaşandığını ortaya çıkaracağız.
IP adresiyle başlayacak olursak, gördüğümüz üzere bu yerel bir IP adresidir. Bu durum, eğer gerçekten bir saldırgan söz konusuysa, organizasyon ağı içerisine zaten sızmış olabileceğini gösterir. Muhtemelen VPN’i başarılı şekilde ele geçirmiş ya da başka bir yöntemle erişim sağlamıştır.
Ana sistem adına (hostname) baktığımızda ise elimizde çok fazla bilgi bulunmuyor. Bir varlık envanteri tablomuz yok ve yalnızca hostname’e bakarak bunun hangi sistem olduğunu anlamak zor. Büyük ihtimalle organizasyona ait bir sunucu türü olduğu söylenebilir.
Etkinlik zamanı normal görünüyor; sabah 09:00, yani standart çalışma saatleri içerisinde gerçekleşmiş. Bu nedenle şimdi SIEM ortamına geçip burada gerçekten bir brute-force etkinliği olup olmadığını ya da bunun yanlış pozitif (false positive) bir alarm mı olduğunu kontrol edelim. Bunun için Splunk üzerinde şu sorguyu kullanacağız.
Bu sorgu; başarılı ve başarısız giriş denemelerini, ayrıca geçersiz kullanıcılarla ilgili olayları arayacaktır. Bu tür olaylar genellikle saldırganların belirli bir kullanıcıya yönelik brute-force saldırısına başlamadan önce hesapları enumerate etmeye çalıştığı durumlarda görülür.
İlk fark ettiğimiz şey, bu IP adresiyle ilişkili oldukça fazla sayıda olayın bulunmasıdır. İkinci olarak ise dikkat çekici olan nokta, var olmayan kullanıcılar için birden fazla oturum açma denemesinin yapılmış olmasıdır. Bunun şüpheli bir durum olduğunu siz de kabul edersiniz, değil mi?
Şu ana kadar brute-force saldırısına dair herhangi bir belirti bulamadık. Bu nedenle şimdi her kullanıcı için yapılan oturum açma denemelerinin sayısını görmek amacıyla başka bir sorgu çalıştıralım.
Şimdi sonuçlar daha ilgi çekici hale geldi. Arama çıktısından görebildiğimiz üzere, bu IP adresinden yapılan oturum açma denemeleri dört farklı kullanıcıyı hedef almış. Ancak yalnızca john.smith kullanıcısında dikkat çekici derecede yüksek, toplam 503 deneme bulunuyor. Bu durum, brute-force faaliyetinin açık bir göstergesidir.
Brute-force denemelerinin john.smith kullanıcısını hedef aldığını biliyoruz, ancak şu aşamada saldırının başarılı olup olmadığını henüz bilmiyoruz. Bu nedenle, saldırganın gerçekten sisteme erişim sağlayıp sağlamadığını belirlemek için aşağıdaki sorguyu kullanalım.
Sonuç olarak, yalnızca john.smith hesabı için başarılı bir oturum açma tespit ediyoruz. Bu durum, brute-force saldırısının başarılı olduğunu ve tehdit aktörünün tryhackme-2404 adlı ana sisteme erişim sağladığını doğrulamak için yeterli kanıt sunmaktadır.
Bu etkinliği artık net göstergeler doğrultusunda True Positive olarak sınıflandırabiliriz. Ayrıca, daha ileri düzey inceleme yapılabilmesi ve gerekirse Olay Müdahale (Incident Response) ekibinin devreye girmesi için durumu derhal SOC L2 analistine eskale etmemiz gerekmektedir.
Kalıcılık Alarmı
İkinci senaryo, SOC analistlerinin düzenli olarak karşılaştığı bir Windows ortamındaki aktiviteler üzerine odaklanacaktır. Bu nedenle, analizi nasıl gerçekleştireceğinizi bilmek sizin için gerçekten büyük önem taşımaktadır.
Host (ana makine) ve User (kullanıcı) bilgilerine odaklanın. Öncelikle bunun ne tür bir sistem olduğunu belirleyin: bir workstation mı yoksa server mı? Devam etmeden önce bu bağlamı anlamak kritik öneme sahiptir. Birçok kurumda bunun için bir Asset Inventory (Varlık Envanteri) bulunur (bazen Confluence veya Notion üzerinde tutulur); ancak böyle bir yapı yoksa isimlendirme standartları yardımcı olabilir.
Sunucular genellikle SRV, WEB, MSQL gibi önekler kullanırken, workstation sistemleri WIN veya HOST şeklinde adlandırılır. Bizim örneğimizde WIN-H015, bunun bir workstation olduğunu göstermektedir.
Sonraki adımda kullanıcıyı inceleyin. Kullanıcının görevini görmek için identity table’ı kontrol edin. Bu, gerçekleştirilen aktivitenin kullanıcının işiyle uyumlu olup olmadığını anlamanıza yardımcı olur. Örneğin, İnsan Kaynakları (HR) çalışanının görev zamanlayıcı oluşturması şüpheli olabilirken, IT personeli için bu normal karşılanabilir. Ayrıca kullanıcının konumunu ve çalışma saatlerini inceleyerek aktivitenin zamanlamasının mantıklı olup olmadığını değerlendirebilirsiniz. Bizim senaryomuzda, Oliver Thompson bir System Engineer’dır.
Bu bilgileri topladıktan sonra, aktivitenin nerede gerçekleştiğine ve kim tarafından yapıldığına dair ilk genel tabloyu elde etmiş oluruz. Şimdi daha derin bir analiz için SIEM’e geçebiliriz.
Başlangıç olarak, AssessmentTaskOne görev adıyla birlikte, zamanlanmış bir görevin oluşturulduğunu gösteren 4698 Event ID’sini sorgulayacağız. Aktivitenin tam zamanını da bildiğimiz için, aramayı hızlandırmak amacıyla timestamp filtresi uygulayabiliriz.
Not: Şimdilik host filtresi kullanmayacağız. Böylece aktivitenin yalnızca tek bir makineye mi ait olduğunu yoksa birden fazla host üzerinde mi gerçekleştiğini kontrol edebiliriz.
Aramamızın sonucunda, bu aktiviteyle ilişkili yalnızca tek bir olay (event) bulunduğunu görebiliyoruz.
Şimdi, bu görevin gerçekte ne yaptığını anlamak için Message alanını inceleyelim. Adım adım ilerleyerek önce Triggers bölümünden başlayacağız.
Görevin, bir kullanıcı workstation’ında her gün aynı saatte çalıştığını görebiliyoruz; bu oldukça sıra dışı bir durumdur. Şimdi analizimize devam ederek Message alanındaki Exec ve Principals bölümlerine odaklanacağız. Böylece hangi görevin çalıştırıldığını ve bunun hangi kullanıcı hesabı altında yürütüldüğünü görebileceğiz.
Bu noktada artık kötü amaçlı aktivitenin ilk belirtilerini açıkça görebiliyoruz. Bu görev, certutil aracını kullanarak tryhotme domaininden rv.exe dosyasını indirip, bunu Temp klasörüne DataCollector.exe adıyla kaydedecektir. Ardından bu dosya, bir Start-Process PowerShell komutu kullanılarak çalıştırılacaktır. Tüm bu işlemler oliver.thompson kullanıcısı altında gerçekleştirilecektir. Bu durum, persistence (kalıcılık) mekanizmasına açık bir örnektir.
Peki başka neler öğrenebilirsiniz? Domain bilgisini Threat Intelligence platformlarında araştırmayı deneyin; bu domain bilinen bir saldırgan altyapısıyla ilişkili olabilir. Biz bu aktiviteyi True Positive olarak sınıflandırdık. Ayrıca bu olay, daha derinlemesine analiz yapılabilmesi için bir Seviye 2 (L2) analistine eskale edilmelidir.
Web Shell Uyarıları
Son senaryo, zafiyet barındıran bir web sunucusundaki aktivitelere odaklanacaktır. Olası bir web shell istismarını inceleyeceğiz.
Bir diğer önemli nokta ise şüpheli IP adresidir. Bu IP hakkında daha fazla bilgi edinmek için çeşitli Threat Intelligence platformları üzerinden kontrol edebiliriz. Örneğin AbuseIPDB’yi kullanarak inceleme yapalım.
Görüldüğü üzere, bu IP adresi 3000’den fazla kez kötü amaçlı olarak işaretlenmiştir. Bunu not ediyoruz.
Şimdi SIEM’e geçerek bu IP adresi tarafından gerçekleştirilen spesifik aktiviteleri inceleyelim.
Bu IP ile ilişkili çok sayıda isteği hemen tespit edebiliyoruz. Özellikle dikkat çekici olan nokta, User-Agent değerinin Hydra olarak ayarlanmış olmasıdır. Bu, saldırganlar tarafından brute force (kaba kuvvet) saldırıları gerçekleştirmek için sıkça kullanılan bir araçtır ve bizim senaryomuzda wp-login.php sayfasına yönelik denemeler yapılmaktadır.
Bu durum zaten başlı başına açık bir kötü amaçlı aktivite göstergesidir; yani yetkisiz erişim elde etmeye yönelik girişimler söz konusudur. Ancak mevcut alarmımız bir web shell ile ilgili olduğu için, olayın devamında başka neler gerçekleştiğine daha yakından bakmamız gerekiyor
Aramamızdan Hydra User-Agent’ını hariç tuttuk ve sonuçları yeniden inceledik.
Arama sonuçlarını incelediğimizde hemen dikkat çeken bir detay ortaya çıkıyor. admin-ajax.php için bir POST isteği gözlemlenmiş ve bu isteğin referer (yönlendirme) bilgisi theme-editor.php?file=b374k.php olarak görünmektedir.
Bu durum oldukça sıra dışıdır çünkü tema editörünün rastgele .php dosyalarına referans vermesi beklenmez. Özellikle file=b374k.php ifadesinin varlığı, saldırganın bir web shell yüklemiş olabileceğini veya bu shell ile etkileşimde bulunduğunu güçlü bir şekilde göstermektedir.
Şimdi b374k.php ile ilgili loglara daha yakından bakalım.
Tehdit aktörünün b374k.php adlı olası bir web shell dosyasına başarılı şekilde erişim sağladığını tespit ettik. Bunun ardından, bu dosya üzerinden faaliyet yürütmeye başladığı görülüyor; özellikle dört adet başarılı POST isteği gözlemlendi.
Ne yazık ki loglar, saldırganın web shell’i sunucuya ilk olarak nasıl yüklediğine dair bir bilgi sağlamıyor.
Bazen saldırganlar, yaygın kullanılan web shell’leri dosya adını değiştirmeden doğrudan kullanabilirler. Bu yüzden tespit edilen web shell hakkında biraz araştırma yapmak faydalı olacaktır.
Google’da şu şekilde arama yapabilirsiniz: “b374k.php web shell”
Google araması: b374k.php web shell
Bu arama, b374k web shell’inin ne olduğu, nasıl çalıştığı ve genellikle hangi saldırı senaryolarında kullanıldığı hakkında bilgi edinmenizi sağlayacaktır.
Bu bulgu, tespit edilen dosyanın bir web shell olduğunu ek olarak doğrulamaktadır. Özetle, web sunucusunu hedef alan Vietnam kökenli 171.251.232.40 IP adresinden gelen kötü amaçlı bir aktivite tespit ettik. Şüpheli faaliyet, wp-login.php üzerinde Hydra kullanılarak gerçekleştirilen bir brute force saldırısıyla başlamış, ardından b374k.php ile ilişkili web shell aktivitesine dair net kanıtlarla devam etmiştir.
Bu aktiviteyi güvenle True Positive olarak sınıflandırabilir ve daha derin bir inceleme gerektirdiği için bir SOC Seviye 2 analistine eskale edebiliriz. Bu vaka aynı zamanda Olay Müdahale (Incident Response) ekibinin de devreye girmesini gerektirecektir.
Okuduğunuz için teşekkür ederim
Selamun aleyküm dostlarım. Bu makalemizde bir SOC ortamında uyarıların nasıl doğru şekilde incelendiğine, Linux sistemlerinde brute force saldırılarının nasıl araştırılacağını, windows sistemlerindeki kalıcılık mekanizmasının ne olduğunu inceleyeceğiz. Güvenlik açığı bulunan bir web sunucusundaki web shell’i analiz edeceğiz ve son olarak vediğimiz konu başlıklarından ilerleyerek, saldırıları splunk vasıtasıyla inceleyeceğiz Allah’ın izniyle.
İlk Erişim Uyarısı
Bir analist olarak vardiyanız sırasında karşılaşabileceğiniz üç farklı senaryoyu inceleyeceğiz. İlk senaryo bir Linux ana sisteminde gerçekleşecek ve soruşturma sürecimiz boyunca burada tam olarak neler yaşandığını ortaya çıkaracağız.
Uyarının İncelenmesi
Araştırmamıza başlayalım. İlk olarak uyarı verilerine odaklanacağız; özellikle de ilgi çekebilecek iki alana: Target Host Time ve Source IP.IP adresiyle başlayacak olursak, gördüğümüz üzere bu yerel bir IP adresidir. Bu durum, eğer gerçekten bir saldırgan söz konusuysa, organizasyon ağı içerisine zaten sızmış olabileceğini gösterir. Muhtemelen VPN’i başarılı şekilde ele geçirmiş ya da başka bir yöntemle erişim sağlamıştır.
Ana sistem adına (hostname) baktığımızda ise elimizde çok fazla bilgi bulunmuyor. Bir varlık envanteri tablomuz yok ve yalnızca hostname’e bakarak bunun hangi sistem olduğunu anlamak zor. Büyük ihtimalle organizasyona ait bir sunucu türü olduğu söylenebilir.
Etkinlik zamanı normal görünüyor; sabah 09:00, yani standart çalışma saatleri içerisinde gerçekleşmiş. Bu nedenle şimdi SIEM ortamına geçip burada gerçekten bir brute-force etkinliği olup olmadığını ya da bunun yanlış pozitif (false positive) bir alarm mı olduğunu kontrol edelim. Bunun için Splunk üzerinde şu sorguyu kullanacağız.
Bu sorgu; başarılı ve başarısız giriş denemelerini, ayrıca geçersiz kullanıcılarla ilgili olayları arayacaktır. Bu tür olaylar genellikle saldırganların belirli bir kullanıcıya yönelik brute-force saldırısına başlamadan önce hesapları enumerate etmeye çalıştığı durumlarda görülür.
Kod:
index="-alert" sourcetype="linux_secure" 10.10.242.248
| search "Accepted password for" OR "Failed password for" OR "Invalid user"
| sort + _time
Kod:
index="-alert" sourcetype="linux_secure" 10.10.242.248
| rex field=_raw "^\d{4}-\d{2}-\d{2}T[^\s]+\s+(?<log_hostname>\S+)"
| rex field=_raw "\[\d+\]:\s*(?<action>Failed|Accepted)\s+\S+\s+for(?: invalid user)? (?<username>\S+) from (?<src_ip>\d{1,3}(?:\.\d{1,3}){3})"
| eval process=""
| stats count values(src_ip) as src_ip values(log_hostname) as hostname values(process) as process by usernameŞimdi sonuçlar daha ilgi çekici hale geldi. Arama çıktısından görebildiğimiz üzere, bu IP adresinden yapılan oturum açma denemeleri dört farklı kullanıcıyı hedef almış. Ancak yalnızca john.smith kullanıcısında dikkat çekici derecede yüksek, toplam 503 deneme bulunuyor. Bu durum, brute-force faaliyetinin açık bir göstergesidir.
Kod:
index="-alert" sourcetype="linux_secure" 10.10.242.248
| rex field=_raw "^\d{4}-\d{2}-\d{2}T[^\s]+\s+(?<log_hostname>\S+)"
| rex field=_raw "\[\d+\]:\s*(?<action>Failed|Accepted)\s+\S+\s+for(?: invalid user)? (?<username>\S+) from (?<src_ip>\d{1,3}(?:\.\d{1,3}){3})"
| eval process=""
| stats count values(action) values(src_ip) as src_ip values(log_hostname) as hostname values(process) as process by usernameBu etkinliği artık net göstergeler doğrultusunda True Positive olarak sınıflandırabiliriz. Ayrıca, daha ileri düzey inceleme yapılabilmesi ve gerekirse Olay Müdahale (Incident Response) ekibinin devreye girmesi için durumu derhal SOC L2 analistine eskale etmemiz gerekmektedir.
Sonraki İnceleme Adımları
Bu noktada, bir SOC Seviye 1 analisti olarak bu aktiviteye yönelik incelemeniz sona ermektedir; çünkü sizin sorumluluğunuz kötü amaçlı etkinliği tespit etmek ve durumu Seviye 2 analistine eskale etmektir. Şimdi ise bu vakayla ilgili süreçte bundan sonra neler olacağını ve SOC ekibi açısından hâlâ hangi soruların cevap beklediğini ele alalım.- Saldırgan neden yerel bir IP adresine sahipti? Ağımızın zaten içinde bulunuyor olabilir mi? Eğer öyleyse, ne kadar süredir içerideydi?
- Saldırgan, özellikle kullanıcı adları olmak üzere kullanıcı bilgilerini nasıl elde etti?
- Saldırgan, tryhackme-2404 ana makinesine erişim sağladıktan sonra neler yaptı?
Kalıcılık Alarmı
İkinci senaryo, SOC analistlerinin düzenli olarak karşılaştığı bir Windows ortamındaki aktiviteler üzerine odaklanacaktır. Bu nedenle, analizi nasıl gerçekleştireceğinizi bilmek sizin için gerçekten büyük önem taşımaktadır.
Alarmın İncelenmesi
Bu analize nasıl yaklaşmanız gerektiğine bakalım. İlk olarak durup düşünün — doğrudan SIEM’e atlamayın. Önce alarm detaylarıyla başlayın.Host (ana makine) ve User (kullanıcı) bilgilerine odaklanın. Öncelikle bunun ne tür bir sistem olduğunu belirleyin: bir workstation mı yoksa server mı? Devam etmeden önce bu bağlamı anlamak kritik öneme sahiptir. Birçok kurumda bunun için bir Asset Inventory (Varlık Envanteri) bulunur (bazen Confluence veya Notion üzerinde tutulur); ancak böyle bir yapı yoksa isimlendirme standartları yardımcı olabilir.
Sunucular genellikle SRV, WEB, MSQL gibi önekler kullanırken, workstation sistemleri WIN veya HOST şeklinde adlandırılır. Bizim örneğimizde WIN-H015, bunun bir workstation olduğunu göstermektedir.
Sonraki adımda kullanıcıyı inceleyin. Kullanıcının görevini görmek için identity table’ı kontrol edin. Bu, gerçekleştirilen aktivitenin kullanıcının işiyle uyumlu olup olmadığını anlamanıza yardımcı olur. Örneğin, İnsan Kaynakları (HR) çalışanının görev zamanlayıcı oluşturması şüpheli olabilirken, IT personeli için bu normal karşılanabilir. Ayrıca kullanıcının konumunu ve çalışma saatlerini inceleyerek aktivitenin zamanlamasının mantıklı olup olmadığını değerlendirebilirsiniz. Bizim senaryomuzda, Oliver Thompson bir System Engineer’dır.
Bu bilgileri topladıktan sonra, aktivitenin nerede gerçekleştiğine ve kim tarafından yapıldığına dair ilk genel tabloyu elde etmiş oluruz. Şimdi daha derin bir analiz için SIEM’e geçebiliriz.
Başlangıç olarak, AssessmentTaskOne görev adıyla birlikte, zamanlanmış bir görevin oluşturulduğunu gösteren 4698 Event ID’sini sorgulayacağız. Aktivitenin tam zamanını da bildiğimiz için, aramayı hızlandırmak amacıyla timestamp filtresi uygulayabiliriz.
Not: Şimdilik host filtresi kullanmayacağız. Böylece aktivitenin yalnızca tek bir makineye mi ait olduğunu yoksa birden fazla host üzerinde mi gerçekleştiğini kontrol edebiliriz.
Kod:
index="win-alert" EventCode=4698 AssessmentTaskOne
| table _time EventCode user_name host Task_Name MessagePeki başka neler öğrenebilirsiniz? Domain bilgisini Threat Intelligence platformlarında araştırmayı deneyin; bu domain bilinen bir saldırgan altyapısıyla ilişkili olabilir. Biz bu aktiviteyi True Positive olarak sınıflandırdık. Ayrıca bu olay, daha derinlemesine analiz yapılabilmesi için bir Seviye 2 (L2) analistine eskale edilmelidir.
Sonraki İnceleme Adımları
Elbette hâlâ cevaplanması gereken bazı açık sorular bulunmaktadır:- Bu zamanlanmış görev (scheduled task) nasıl oluşturuldu?
- Saldırgan, WIN-H015 ana makinesine nasıl erişim sağladı?
- oliver.thompson hesabı nasıl ele geçirildi?
Web Shell Uyarıları
Son senaryo, zafiyet barındıran bir web sunucusundaki aktivitelere odaklanacaktır. Olası bir web shell istismarını inceleyeceğiz.
Alarmın İncelenmesi
Önceki vakalarda olduğu gibi, analize yine alarm detaylarını inceleyerek başlıyoruz. İlk dikkat çeken unsur, aktivitenin gerçekleştiği kaynaktır. Bu durumda bu kaynak http://web.trywinme.thm olup, organizasyonun web sunucusunda barındırılan web sitesini temsil etmektedir.Bir diğer önemli nokta ise şüpheli IP adresidir. Bu IP hakkında daha fazla bilgi edinmek için çeşitli Threat Intelligence platformları üzerinden kontrol edebiliriz. Örneğin AbuseIPDB’yi kullanarak inceleme yapalım.
Görüldüğü üzere, bu IP adresi 3000’den fazla kez kötü amaçlı olarak işaretlenmiştir. Bunu not ediyoruz.
Kod:
index=web-alert 171.251.232.40
| table _time clientip useragent uri_path method status
| sort + _timeBu durum zaten başlı başına açık bir kötü amaçlı aktivite göstergesidir; yani yetkisiz erişim elde etmeye yönelik girişimler söz konusudur. Ancak mevcut alarmımız bir web shell ile ilgili olduğu için, olayın devamında başka neler gerçekleştiğine daha yakından bakmamız gerekiyor
Kod:
index=web-alert 171.251.232.40 useragent!="Mozilla/5.0 ()"
| table _time clientip useragent uri_path referer referer_domain method statusBu durum oldukça sıra dışıdır çünkü tema editörünün rastgele .php dosyalarına referans vermesi beklenmez. Özellikle file=b374k.php ifadesinin varlığı, saldırganın bir web shell yüklemiş olabileceğini veya bu shell ile etkileşimde bulunduğunu güçlü bir şekilde göstermektedir.
Kod:
index=web-alert 171.251.232.40 b374k.
| table _time clientip useragent uri_path referer referer_domain method status
| sort + _timeNe yazık ki loglar, saldırganın web shell’i sunucuya ilk olarak nasıl yüklediğine dair bir bilgi sağlamıyor.
Google’da şu şekilde arama yapabilirsiniz: “b374k.php web shell”
Google araması: b374k.php web shell
Bu arama, b374k web shell’inin ne olduğu, nasıl çalıştığı ve genellikle hangi saldırı senaryolarında kullanıldığı hakkında bilgi edinmenizi sağlayacaktır.
Bu aktiviteyi güvenle True Positive olarak sınıflandırabilir ve daha derin bir inceleme gerektirdiği için bir SOC Seviye 2 analistine eskale edebiliriz. Bu vaka aynı zamanda Olay Müdahale (Incident Response) ekibinin de devreye girmesini gerektirecektir.
Okuduğunuz için teşekkür ederimCW-Ommah
Bug Researchers Tim Sundu...
Bug Researchers Tim Sundu...
