Hermes Ransomware Teknik Analizi

Ocak 2018’in sonunda KrCERT tarafından CVE-2018-4878 adında Adobe Flash ile ilgili yeni bir sıfırıncı gün açığı (0-Day) yayınlanmıştı. Yayınlanan güvenlik açığı  Adobe Flash Player 28.0.0.137 ve önceki versiyonlarını kapsıyordu. Bu istismar ise ofis dosyalarının içerisine yerleştirilip, dağıtılarak kullanıcıları hedef almıştı. Adobe Flash Player’a ait açık yayınlanmadan önceki haftalarda ise kullanıcıları çoktan hedef almaya başlamıştı. 1 Şubat itibariyle de Adobe tarafından açığın kapatıldığı duyuruldu.

Hermes Ransomware’ın nasıl yayıldığı ile ilgili kısa açıklamadan ile teknik analiz kısmına geçebiliriz.

Davranışsal Analiz

Zararlı yazılımı ilk çalıştırdığımızda, zararlıya ait dosyaların AppData-->Local-->Temp altında kopyalandığını görüyoruz. Burada ayrıca Svchosta adında bir exe dosyasının da oluşturulduğunu fark ediyoruz.

Bazı zararlılar çalıştırıldığında bu tarz dosyaları oluşturup, belli bir süreden sonra kaldırıyordu. Fakat analiz sürecinde buna rastlamadığımı belirtmek istiyorum.

Bunun yanında zararlı çalıştırıldıktan bir iki dakika içerisinde yönetici izni ile bir dosyanın çalıştırılmasını istiyor. Açıkcası kullanıcı ne kadar iptal etmek istesede, her defasından karşısına çıkıyor. Kullanıcıyı bu şekilde zorlayarak kabul etmeleri amaçlanmış diyebiliriz. Açıkcası bunu amaçlamışlar :)

Çalıştırılmak istenen ilgili dosya ile ilgili bilgiler yukarıdaki resimde yer aldığı gibidir. Batch Script‘den anlaşıldığı kadarıyla gölge dosyalar (shadows) ve alınan tüm yedekleri silme işlevini yerine getiriyor.

Yine Bash Script’in Public altına kopyalan diğer dosyaları yukarıdaki resimde gözüktüğü gibi yer alıyor.

Bunun dışında 2 tane 1 KB‘lık dosyanın oluşturulduğunu görüyoruz. Bunlardan ilki olan PUBLIC dosyasını açtığımızda RSA public key‘i oluşturulduğunu görebiliyoruz. Anladığım kadarıyla her bir kurban için ayrı ayrı RSA public key üretiliyor. Çünkü yukarıdaki resimde gördüğünüz gibi RSA1 adı altında üretilmiş.

İkinci dosyayı yani UNIQUE_ID_DO_NOT_REMOVE açtığımızda ise tamamiyle RSA ile şifrelenmiş kod bloglarını görüyoruz.

Üçüncü dosyamızı DECRYPT_INFORMATION.html açtığımızda da pek çok ransomware de olduğu gibi bilgilendirme ekranı çıkıyor karşımıza. 5 farklı dilde bilgilendirme sunduğu ilk gözüme çarpan diyebilirim. Özellikle ödeme sonrasında dosyaları açacağı ile ilgili güven vermek adına da bir tane şifrelenmiş dosyayı açılmasını sağlıyor. Güven önemli mesele tabi ki :)

Bunun dışında zararlıyı yazan kişi iki tane iletişim adresi vermiş. Bunlardan biri gmail, diğeri de keemail.me olmuş. Fakat bazı analistçilerin yaptığı analizlere baktığımda başka iletişim adreslerine de rastlamışlar. Bir tane inceleme yazısında ProtonMail diğer yazıda Bitmessage bir diğerinde ise india.com vardı mesela. Fakat benim incelediğim zararlının dosyasında sadece yukarıdakiler vardı.

Unpacking İşlemi

Davranışsal analizi tamamladıktan sonra exe dosyasına unpacking işlemini uygulamaya başlayabiliriz.

İlgili zararlı dosyasını x64Dbg üzerinde açıyoruz. İlk iş olarak VirtualAlloc üzerinde breakpoint koymak olacak. Bu yüzden Ctr+G yapıp, gerekli etiketi yani VirtualAlloc yapıyoruz ve tamam diyoruz.

Bu adımı gerçekleştirdikten sonraki ilk ilgi çeken kısmı görecek olacaksınız. Çünkü bu adımla Kernel32.dll dosyasının içerisine adım atmış oluyoruz. İkinci ilgili noktamız ise VirtualAlloc fonksiyonuna gelmiş olmamız diyebilirim.

Fakat şunu belirtmekte fayda şuanki olduğumuz yerde herhangi bir gerçek koda ulaşmış olmuyoruz. Görüleceği üzere sadece başka bir DLL dosyasının içerisine giden JMP’ı görüyoruz.

Following in Disassemble-->Value yapıp takip ettiğimizde Virtual Alloc fonksiyonun Kernel base dll içerisindeki yerine ulaşıyoruz. Microsoft, Windows 7’de bazı Core API’lerini KernelBase DLL adında bir yere taşıdı ve VirtualAlloc‘ta bunlardan biridir. Hatta kernel32.dll dosyasını içe aktarıp, VirtualAlloc işlevi kullanılmasına rağmen sadece Kernel Base’e yönlendiriliyor. Bunu neden yaptıklarıyla ilgili olarak çok fazla araştırma yapamadım fakat baktığım kadarıyla Windows’un çalışması için var olan API’leri minimum düzeye çekmeye çalışmak istemişler diyebilirim.

Yukarıdaki gibi VirtualAlloc üzerine Breakpoint koymak istediğimiz zaman, aslında Kernel32 içerisinde değil KernelBase içerisinde olduğumuzu hatırlamamız gerekiyor.

Kısa bir bilgi aşamasından sonra kaldığımız yerden devam ediyoruz. Şimdiki adımımızda VirtualAlloc’taki return kısmına breakpoint koyuyoruz. Çünkü return olduğu zaman, ona ayrılan veya tahsis edilen hafızanın temel adresini alacaktır.

Pek çok analizde olduğu gibi her zaman RET 10 kısmına breakpoint koyuyoruz. Burada bizi en çok ilgilendiren nokta EAX değerlerini incelemek olacaktır. Bu kısım bize yeni bellek bölümünün (memory segment) temel adresini (base address) verecektir. Görüleceği üzere de şuan için tahsil edildiğini görüyoruz.

Bir sonraki adımımız ise hafızanın nerede ayrıldığını görmek adına, run yapıyoruz. Run işleminden sonra gelen ekrandan göreceğimiz üzere ilk breakpoint imiz giriş noktasında (entry point) bulunuyor. İkinci defa run işlemini yaptıktan sonra ikinci breakpoint noktamız olan RET kısmına geldiğimizi görüyoruz. EAX değerlerini incelediğimizde, EAX için ayrılmış olan yeni sanal bellek bölümü adresini görmüş olacağız.

İlgili bölümü Dump yaptığımız zaman bize hafıza bölümünü gösterecek. Tamamına göz gezdirdiğinizde NULL bytes olduğu fark ediliyoruz çünkü bu bölüm sadece tahsil edilmiş. Bu yüzden run tuşuna basıp yolumuza devam ediyoruz.

Bu işlemden sonra dump bölümünü aşağılara doğru incelediğimizde text, rdata, data, rsrc gibi PE dosyasına ait bölüm tablolarına rastlıyoruz. Bu dosyamızda dump edip, yolumuza devam ediyoruz. Unpacking işlememizin ilk kısmını tamamlamış olduk. Daha sonrada elde ettiğimiz dosyayı UPX unpacker ile açıyoruz. Ve IDA Pro ile incelenebilir durumdadır artık.

IDA Pro tarafındaki incelemeyi yazı tarafına dökmeyeceğim. Sadece bazı ekran görüntüleri paylaşacağım.

Sabırla okuduğunuz için teşekkürler. Bilgi noktasında herhangi bir yanlışlık bulursanız eğer, geri dönüşlerinizi bekliyorum.

Bir sonraki incelemede görüşmek üzere.