Ransomware’lar kullanılarak sistemlere yapılan saldırılar her geçen gün daha da artmakta daha da karmaşıklaşmaktadır. Bu tür zararlıları kullanan kişi veya gruplar yöntemlerini ve zararlılarını her geçen gün karşılaştıkları veya karşılaşacakları önlemlere karşı geliştirmektedir. Aşağıdaki grafikte Mcafee Labs Haziran 2017 raporundan alınan grafik bulunmaktadır ve son yıllarda tespit edilen yeni Ransomware’lere ait sayısal veriyi yansıtmaktadır.
Ransomware’ların mantıkları basit olarak şu şekilde açıklanabilir;
- Hedef sistem için hayati olabilecek (.doc, .xls, .ppt, .pdf vb.) dosyaları güçlü algoritmalar ile şifrele.
- Hedef sisteme ait benzersiz bir değer üret ve bu değer ile Private Key’i (dosyaları şifrelemek için kullanılan anahtar) komuta-kontrol merkezine gönder.
- Ödemeyi bekle.
Neden Powershell Destekli Ransomware?
Yazının ana konusu olan analiz kısmına geçmeden bir konudan bahsetmenin iyi olacağını düşünüyorum. Aşağıda örnek iki ekran görüntüsü bulunmakta, iki ekran görüntüsünde de kullanılan dosyalar tamamen aynı işi yapmaktadır. Bu ekran görüntüleri aynı işi yapan iki dosya için güvenlik çözümlerinin verdiği farklı tepkileri içermektedir.
Üst düzey bir RAT olan Meterpeter’in özellikle sızma testlerinde kullanımı çok yaygındır ve verilecek örnek için iyi bir seçimdir. Meterpreter’i seçmemin sebeplerinden bazıları, hali hazırda kaynak koduna erişilebilir, imzaları, davranışları güvenlik çözümleri tarafından bilinir durumdadır.
Aşağıdaki ilk VirusTotal ekran görüntüsü C dilinde geliştirdiğim ve Meterpreter Stage’ini enjekte eden Loader’a ait, ilgili kod içerisinde tespitlere karşı herhangi bir üst düzey önlem almadım. Bu yazı için 32-Bit derlenmiş halini taradım. 64-Bit olarak derlendiğinde hiçbir çözüm tarafından yakalanmamaktadır. 32-Bit 64-Bit farkı bir başka yazı konusu olsun. 🙂 İkinci ekran görüntüsü ise Powershell dilinde yazılan ve yine aynı işi yapan Powershell Script’ine aittir.
32-Bit PE Loader Sonucu;
Powershell Script Loader Sonucu;
Yukarıdaki sonuçları gördükten sonra değinilmek istenilen konuya gelelim; taranan her iki dosyada aynı işi yapıyor ancak sonuçlar çok farklı, peki neden?
Çok uzun bir cevabı olan bu sorunun cevabını özetlersek; PE hale getirilen dosyaya önlemlerin bakışı kesinlikle farklıdır çünkü yıllardır PE dosyalar (.EXE, .DLL) zararlı aktiviteler için birçok kez kullanıldı ve önlemlerin tespit yetenekleri de aynı oranda arttı. Ayrıca güvenlik önlemlerinin bu tür dosyaları incelemek için çok daha fazla efor sarf etmelerine gerek yok, imza tabanlı veya davranışsal analiz gerçekleştirebilirler.
Diğer taraftan Powershell vb. herhangi bir yorumlanan dil kullanarak bir zararlı geliştirilirse ki bu tür zararlılar script-based malware olarak adlandırılır çözümlere karşı saldırganın avantajı doğar. Güvenlik çözümlerinin bu tür script tabanlı zararlıları incelerken yapabileceklerini özetlersek; imza tabanlı tespit yapabilir veya satır satır inceleyip parse ederek çağırdığı fonksiyon veya API desenlerine göre çıkarımda bulunabilir. Ancak tam olarak ne iş yaptığı tespit edilmek isteniyor ise ilgili script dilinin Interpreter’ine ihtiyaç duyulacaktır ki kodu gerçek anlamda yorumlayıp ne yaptığını anlayabilsin. Güvenlik ürünlerinin kendi içlerinde her bir scripting dili için özelleştirilmiş bir Interpreter barındırdığını düşünelim? Bu durum hem o kadar kolay değil hem de mantıklı değildir. İşte bu yüzden script tabanlı zararlılar diğer derlenmiş, çalıştırılabilir hale getirilmiş zararlılara oranla daha az tespit edilme oranına sahiptir.
Eğer hedefinizde bir Windows sistem varsa Powershell tabanlı saldırılar gerçekleştirmek en mantıklı yoldur. Nedenlerini ise;
- Vista sonrası tüm Windows ailesi işletim sistemlerinde varsayılan olarak yüklü geliyor.
- .NET Framework’ü tam erişim sağlıyor, .NET Framework’ü kullanarak yapabildiğiniz herşeyi Powershell ile pekala yapabilirsiniz.
- Powershell.exe’nin kendisi Signed ve Legal’dir.
- Office ailesi yazılımlarda Macro üzerinden, .BAT, .EXE, .DLL, .HTA gibi uzantılı dosyalardan normal şartlarda Powershell’i çağırabilir ve işlem yapabilirsiniz.
- Yukarıda da açıkladığım üzere güvenlik ürünleri script-based zararlılar karşı henüz ileri düzeyde yetenekli değildir.
…şeklinde özetleyebiliriz.
Analiz
Geçtiğimiz günlerde Twitter üzerinde bir hesap üzerinde paylaşılan Powershell dilinde yazılmış Ransomware örneği ile karşılaştım.
Zararlı .JS uzantılı dosya olarak e-posta ekinde hedeflere gönderilmiş. .JS dosyası decode edilmiş durumda ve decode edilen Ransomware koduna linki üzerinden erişilebilir.
Toplamda 69 satırdan oluşan bu Ransomware tam da tanımına uygun bir şekilde çalışmak için yazılmıştı. Güvenlik önlemlerine karşı hem JavaScript kodunda hem de Powershell kodunda herhangi bir ileri düzey teknik kullanılmamıştı sadece ileri düzeyde olmayan obfuscation kullanılmıştı.
Kodu incelendiğinde Ransomware öncelikle bir kayıt defteri girdisini kontrol ediyor. Eğer hedef sistemde “HKCU:\Software\ENCRDEC\Scripts” kayıt defteri yolu var ise 4. satırda tanımlandığı üzere kodun devamını çalıştırmıyor. Bu kontrol şu anlama gelmektedir; eğer daha önce bu sisteme bulaştıysan çalışma anlamına gelmektedir. Çünkü zararlı başarılı şekilde çalıştıktan sonra ilgili kayıt defteri yolunda “Version” anahtarını oluşturup değerini “0” olarak atmaktadır. Bu kayıt defteri değerini oluşturma işlemini 7- 9 satırları arasında gerçekleştirmektedir.
Ransomware yukarıdaki kontrolü gerçekleştirdikten sonra 10., 11. ve 12. satırlarda görülecek olan rastgele değerleri üretmekte ve bunları değişkenlere atamaktadır. Ardından oluşturulan değerler http:// joelosteel.gdn / pi.php adresine POST metotudunu kullanarak, isteğin payload kısmında “string=<Rasgele Oluşturulan 1. Değer>&string2=<Rasgele Oluşturulan 2. Değer>&uuid=<Rasgele Oluşturulan 3. Değer>” değeri olacak şeklinde gönderiliyor.
Oluşturulan birinci ve ikinci değerler dosyaları şifrelemek için kullanılan değerler, oluşturulan üçüncü değer hedef sistem için benzersiz değer olarak kullanılıyor, yani hedef sistemin ID’si olarak kullanılıyor ödeme yapılacaksa saldırgana bu değer veriliyor. Sonraki adım da ise 22-52 satırları arasında tanımlanan asıl işini gerçekleştirmektedir, 455 farklı uzantıya sahip dosyayı diskte tespit edip oluşturduğu anahtar ile şifreliyor. 55. ve 58. satırlar arasındaki işlemlerde de _README-Encrypted-Files.html isimde bir dosya oluşturuluyor. Dosyanın içeriğine standart Ransomware uyarı mesajı yazılıyor ve sonrasında hedef sisteme ait benzersiz değer ekleniyor. Bu noktaya kadar işlemler başarılı ile gerçekleştikten sonra 65. ve 68. satırlarda tanımlanan işlem gerçekleştiriliyor; kayıtlı Shadow dosyaları siliniyor.
Powershell’de yazılmış olan bu Ransomware’in aynı gün gerçekleştirdiğim VirusTotal tarama sonuç adresi ve ekran görüntüsü aşağıdaki gibidir;
Bknz: .
İlerleyen günlerde ürünlerin kendilerini güncelleştirmeleriyle yakalanma oranları artmaya başladı.
Saldırılarda Powershell Nasıl Kullanılabilir?
Normal şartlarda Powershell’de yazılan kodlar .PS1 uzantısına sahip olurlar ve Powershell Interpreter’i tarafından yorumlanmak üzere çağırılırlar. Ancak Powershell dilinde yazılan bir kodu .BAT uzantılı dosyalara, Office ailesindeki dosyalara (.DOC, .DOCX, XLX, XLXS, .PPT, PPTX vs.) Macro olarak veya .HTA uzantılı dosyalara gömülebilir. Burada temelde “powershell.exe” çağırılarak ilgili kod çalıştırılır. Aynı zamanda Powershell kodu bir .DLL veya .EXE içerisine de çalıştırılabilir.
Örneğin son kullanıcıya Powershell’de yazılmış bir zararlıyı bulaştırmak isteniliyorsa pekala .PS1 dosyasını e-posta ile göndermek mantıklı olmayacaktır. Genelde Powershell’de yazılmış bu tür kodlar yukarıda da belirttiğim üzere çeşitli dosyalar içerisine gömülür.
Yazı için örnek olarak ilgili Meterpreter Loader’ının Powershell halini Word dokümanın içerisine Macro olarak ekledim ve oluşturduğum dosyaya ait tarama sonuçları da aşağıdaki gibidir;
Ekran görüntüsünde de görüleceği üzere pazarı büyük oranda domine eden çoğu güvenlik çözümü herhangi bir tepki vermemiştir, ilgili Word dosyası oluşturulurken de herhangi bir üst düzey teknik kullanılmamıştır.
Bu ve benzeri payload örnekleri için Powershell Empire projesi incelenebilir.
“powershell.exe”nin son kulanıcı sisteminde yasaklanmış olması durumu zorlaştırsa da bypass edilebilir bir durumdur. C# ve Powershell .NET Framework’ün üzerinde işlem yapan dillerdir ve powershell.exe .NET Framework’te kendisi ile ilgili olan runspace’te işlem yapar. Powershell.exe’nin engellenmesi, yapının temelinde .NET Framework olduğu için System. Management. Automation. Runspaces kütüphanesi çağırıldığında kolaylıkla bypass edilebilir. Bu konu ile ilgili yayınlanmış projeler bulunmaktadır, PowerOPS ve p0wnedShell projeleri incelenebilir.
Powershell Kullanılan Saldırılardan Korunmak İçin Neler Yapılabilir?
Powershell üzerinden gerçekleştirilebilecek gerek Ransomware gerekse diğer saldırılara karşı sistemlere bağışıklık kazandırmak için temelde yapılması gerekenler;
- Son kullanıcı sisteminde yetkisiz kullanıcılar için Command Prompt ve Powershell erişimi kısıtlanmalıdır.
- Son kullanıcı sistemlerinde Office ailesindeki ürünler kullanırken Macrolar kullanmıyorsa, Office ayarlarından tüm Macrolar uyarı vermeksizin kapatılmalıdır ve çalıştırılmamalıdır.
- Genelde bu tür zararlılarla son kullanıcı e-posta yolu ile karşı karşıya kalmaktadır. E-posta ekinde gönderilen dosyalar bir sandbox çözümü tarafından incelenmelidir. Ayrıca son kullanıcılara sosyal mühendislik farkındalık eğitimleri verilmeli ve simülasyonların gerçekleştirilmesi sağlıklı olacaktır.
- Powershell +5.0 versiyonuna upgrade edilmelidir. Powershell ilgili versiyonu ile beraber ileri düzey loglama kabiliyetleri kazandı. Powershell üzerinde çalışıtırılan komutlar, scriptler ve çıktıları loglanmalı ayrıca uygun kolerasyon kuralları işletilmelidir.
…şeklinde özetlenebilir.
Yazar: Halil Dalabasmaz
Referanslar:
- .
