Global tehdit istihbaratı çerçevesince Palo Alto’nun Unit 42 raporunda da belirtildiği üzere geçtiğimiz 3 yıl içerisinde ağırlıklı olarak sağlık, finans gibi çeşitli sektörlerde hizmet veren şirketleri hedeflediklerini ve başarılı atak senaryolarında şirketlerden “veri çalınması” ile yüksek miktarlarda para talep edildiğine ilişkin oran artışını aşağıda bulabilirsiniz. Bu artış aynı zamanda “veri hırsızlığı” için kullanılan teknik ve taktiklerin yıllar içerisinde saldırganlar tarafından kullanımının yaygınlaştığının ve bu tekniklerin verimliliğini göstermektedir.
Günümüzde APT gruplarının bir organizasyon yapısına verecekleri tek zarar kritik iş süreçlerinin aksaması/bozulmasına ilişkin sunucu sistemlerine verilecek zarar değildir. Bunun yanında siber güvenlik çözümlerinin etkin kullanılmadığı/başarılı bir şekilde konfigüre edilmeyen yapılarda uzun süre tespit edilmeden zararlı aktivitelerine devam etmelerine olanak sağlayacak stealthy metodlar mevcuttur. Netsmart siber güvenlik mühendisleri olarak, bu makalemizde internetin belki de en zayıf bileşeni olan DNS ile çeşitli APT grupları tarafından kullanılan, uygulandığı zaman başarı oranının yüksek olduğu bir metodu inceleyeceğiz.
DNS protokolünü kullanarak bir exfiltrate işlemi için saldırganların yapması gereken ön şartlar ve hazırlıklar mevcuttur.
Aşağıdaki şema üzerinde adımların görselleştirilmiş halini bulabilirsiniz.
Peki saldırganlar bir endpoint üzerinde verilere erişebiliyorken neden DNS protokolünü kullanarak veri hırsızlığı metodu kullanırlar? Basit bir şekilde veriyi kendi command & control sunucularına upload işlemi ile yapmaları daha optimal bir yöntem değil mi?
Açıkçası daha optimal bir yöntem olmasına rağmen tespit edilmesi daha kolay olduğundan firewall cihazlarındaki default politikalar ile bu veri hırsızlığı yöntemi kolayca tespit edilip engellenebilmektedir.
Günümüzde bu exfiltration metodunun APT grupları tarafından tercih edilmesinin bir diğer temel sebebi, DNS log yönetimine ilişkin şirketlerin gözden kaçırdığı ve kullanılan güvenlik ürünlerinde yapılmayan konfigürasyonlardır.
Veri güvenliği konusunda best practice uygulama konusunda maalesef çoğu kurumun “legacy security monitoring” sistemleri ve default politikalar ile bu tip bir veri hırsızlığı tekniğini engellemesi imkansıza yakın.
İmkansıza yakın olmasının en temel nedeni, kullandığımız güvenlik ürünlerinden aldığımız raw log ile bu tip bir aktiviteyi anlayamıyor ve kısa sürede bir cevap geliştiremiyor olmamızdır.
Raw log yerine analiz edilmiş güvenlik metrikleri kullanımı ve AI/ML modelleri ile DNS sorguları paketlerinin detaylı inceleniyor olması, bu incelemelere ilişkin istatistiklere ilişkin istatistiklerin (QPS değerlerindeki değişiklikler, kategori bazlı domain sorgularının ağırlıklı dağılımı) güvenlik analistleri tarafından incelenmesi ile birlikte siber olay tespit & müdahale mekanizmaları iyileştirilebilir, düzenli olarak geliştirilebilir.
Bu yazımızda bir organizasyon içerisindeki bir Linux sunucunun malware tarafından enfekte olduğunu ve impact çerçevesince saldırganların DNS protokolünü kullanarak organizasyon içerisindeki kritik bilgileri tespit edilmeden çalmak istediklerini düşünelim. Bu atak senaryosunun tespit yöntemi için Splunk SIEM (Security Information and Event Management) üzerinde bir demo gerçekleştireceğiz.
Splunk, big data ile ilgilenen ve çok sayıda makine loglarını analiz etmek için kullanılan ölçeklendirilebilir bir enterprise log management ve SIEM ürünüdür. Her SIEM ürününün logları normalize ve kategorize etme işlemleri farklılık göstermekte olup, Splunk Enterprise, bu işlemi “App” veya ”Add-on” olarak isimlendirdiğimiz uygulama ve eklentiler sayesinde gerçekleştirmektedir. Gelen raw datayı anlamlandırabilmek ve normalizasyonunu sağlamak için eklentiler kullanılmaktadır. Appler ise; anlamlandırılan datanın görselleştirilmesi, zenginleştirilmesi için kullanılır. Splunk üzerinde birçok ücretsiz App ve Add-on bulunmaktadır.
Bu yazımızda ağırlıklı olarak “Splunk Stream” isimli uygulamayı kullanacağız.
Organizasyonlar tarafından en sık ve yaygın kullanıldığını düşündüğümüz bir Windows environment içerisindeki DNS Server rolüne sahip sunucudan universal forwarder (Splunk log toplama ajanı) logları toplayabileceğimiz gibi, bu makalemizde farklı bir metod kullanarak Splunk Stream add-on sayesinde pasif bir şekilde network katmanında gerçekleşen eventleri “packet sniff” özelliği ile toplayıp filtreleyeceğiz.
Single node instance Splunk Enterprise platformu üzerine kurduğumuz Splunk Stream konfigürasyonlarına ilişkin ekran görüntüleri aşağıdaki gibidir:
Stream app içerisine girdikten sonra Configuration>New Stream>Metadata Stream seçenekleri ile network katmanından tercih edeceğimiz L4 veya L7 protokollerine ilişkin paketleri ve hangi paket header/body kısımlarını dahil edeceğimizi seçebiliriz.
Tüm bu log management için ayrılması gereken depolama boyutunu da düşünecek olursak toplayacağımız log üzerinde hangi fieldları dahil etmemiz gerektiği ve bir sonraki aşama olan hangi filtreleri uygulayarak uzun dönemli bu logları tutmamız gerektiği ile ilgili field filtrelemesi yapabiliriz. Örnek olması açısından DNS sorgusuna ilişkin RESPONSE paketlerinde reply_code alanının filtrelenmesini bulabilirsiniz.
Esneklik olması açısından her field üzerine gerekirse birebir eşleşme gerekirse farklı regex patternleri ile bir filtreleme işlemi gerçekleştirilebilir.
Sıradaki görselde elimizdeki verinin hangi index üzerinde tutulacağını da seçtikten sonra artık DNS paketlerinin capture edilmiş ve loglanmış halini saklayabiliyor konuma gelmekteyiz.
Splunk componentlari üzerinde kurduğumuz Stream App yanı sıra, en başta da belirttiğimiz gibi, network eventlerini Splunk log toplama ajanları (universal forwarder veya heavy forwarder) ile değil, independent stream forwarder isimli bileşen ile toplayacağız. Independent stream forwarder için kurulum oldukça kolay olup sadece Linux işletim sistemlerince desteklenen bir programdır. Kurulumu ve tüm konfigürasyonları için tekrar Configuration > Distributed Forwarder Management > Install Stream Forwarders sekmesinden gerekli curl komutunu stream verisi toplayacak Linux sunucuda çalıştırmamız yeterlidir.
Son aşamada yaptığımız tüm konfigürasyonların sonucunu topladığımız veriyi görmek adına aşağıdaki SPL sorgusu çalıştırılarak DNS logları incelenebilir.
SPL Sorgusu : index=dns sourcetype=”stream:dns”
Örnek olması açısından bir DNS sorgusunun hangi DNS sunucusundan cevap döndürüldüğü, query tipi (A, AAAA, MX gibi), query adı, DNS paketlerinin büyüklüğü gibi alanları içeren bu loglar sayesinde src_ip, bytes, bytes_in, bytes_out, query, query_type, reply_code fieldları ile birlikte detection kurallarımızı yazmaya başlayabiliriz.
İncelediğimiz veri hırsızlığı metodunu simüle etmek adına saldırganların *.netsmart.security domainine sahip olduğunu ve bir Linux endpointe girdikten sonra sensitive bilgiyi encode ve encryption işlemlerini uyguladıktan sonra veriyi daha ufak “chunck” (parça) halinde dışarı çıkarttığını düşünelim.
Bu şüpheli DNS trafiği Splunk Search üzerinde tablo haline getirilirse aşağıdaki şekilde görünecektir.
NOT: Bu atak metodu yalnızca kritik bilgilerin dışarı çıkarılmasında değil ayrıca DNS protokolü üzerinden saldırganların C2 sunucuları ile haberleşmeleri için de kullanılabilir, bu tip bir DNS Tunneling metodu için open source araçlar bulunmaktadır ve burada açıkladığımız tespit yöntemi dns2tcp gibi tunneling araçlarıyla oluşturulacak zararlı trafiği ayırt etmek için de kullanılabilir.
Bu görselde dikkat etmemiz gereken belki de en önemli detay Non-Existent Domain kategorisindeki DNS querylerinin uzun sürmesi ve valid DNS querylerinin (ubuntu.com, download.docker.com, *.cloudfront.net gibi CDN ler gibi) time_taken değerinin çok daha düşük olmasıdır.
İlgili security ekipleri tarafından istatistiksel metodlar yardımıyla belirlenecek QPS değeri (Query per Second) ve DNS sorgusunun lifecycle tamamlayana kadar geçen süredeki threshold değerinin aşılması sayesinde potansiyel DNS exfiltration ataklarının Splunk üzerinden tespiti yapılabilir.
Anlamaya yardımcı olması açısından endpointlerin QPS değerleri aşağıdaki gibi basit bir SPL sorgusu ile izlenebilir ve buna ilişkin alert mekanizmaları geliştirilebilir.
Günümüzde kurumların tek başına yüksek miktardaki log verisi tutmaları tek başına bir anlam içermediği gibi düzenli şekilde analizi yapılmalı ve gerektiği durumlarda güvenlik olaylarına ilişkin “response” verilebilir derecede siber güvenlik personellerine ışık tutabilmelidir.
Log management stratejisinin doğru planlaması, network katmanında beklenmeyen davranışların & anomaliler oluşması, güvenlik olaylarının doğru bir şekilde tespit edilip adreslenmesi, bu tip bir atak vektörüne karşı alınması gereken en temel planlama stratejilerindendir.
Günümüzde yukarıda bahsettiğim veri hırsızlığı metodunun doğasına özgü detaylar sebebiyle detection konusunda gerekli önem verilmemiş her türlü sunucu ortamı veya client cihazları için tespit ve engelleme konusunda gerekli adımlar alınmamışsa veri hırsızlığı yöntemlerinin geçmişe dönük tespiti ve oluşabilecek veri sızıntısı olayları bir kurum için kaçınılmazdır.
Zararlı yazılımların doğası incelendiği zaman tipik bir ransomware saldırısından iyi bir yedekleme planınız ile basitçe 24 saat öncesine dönüp minimum veri kaybı ve down time ile bir kurum operasyonuna devam edebilirken, başarılı olan veri hırsızlığı senaryoları bir kere yaşandıktan sonra önlem mekanizmaları ve stratejiniz hazır değilse, yarattığı hasar geri alınamaz.
-
Kuantum bilgisayarlar, klasik bilgisayarların ötesine geçen hesaplama yetenekleriyle, modern kriptografi altyapılarını tehdit eden yeni bir dönemi beraberinde getirmektedir.
Windows Event Forwarding, Windows tabanlı sistemlerde yerel olarak desteklenen günlük merkezileştirme özellikleri sağlar. Microsoft, sunucular üzerindeki logların tek bir yerde toplanması WEF mimarisi ile sağlamaktadır.
Veri Koruma Günü, her yıl 28 Ocak’ta, kişisel verilerin korunması ve veri gizliliği konusunda farkındalık yaratmak amacıyla belirlenmiş bir gündür.
Veri keşfi konusu 7 Nisan 2016 tarihinde yürürlüğe giren 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) ile hayatımıza girdi. Bu kanunla beraber bu zamana kadar dağınık olan verilerimizin nerede tutulduğunun ve ne derece kritik olduğunun önemi giderek artmaktadır.
