1. Bölüm: BlackEnergy – KillDisk Detaylı Analizi

21 Aralık 2018
0 Paylaşımlar

Bugünkü yazımda daha önce türevlerinden bahsetmiş olduğum BlackEnergy zararlısının en son versiyonunu analiz edeceğiz. İlk olarak BlackEnergy içerisinde bulunan KillDisk’i 2 bölümde detaylı olarak inceleyeceğiz. Analiz sırasında Mark Russinovich tarafından geliştirilen “SysInternals – Process Monitor” ve IDA Pro Disassembler’ı kullanacağız. Tüm incelemeler Windows XP işletim sistemi üzerinde sanal ortamda gerçekleştirilecektir. Analiz öncesi Virtual Machine üzerine windows XP kurulumunu hızlı bir şekilde yapıyoruz ve enfekte etmeden önce Virtual Machine’den anlık görüntü oluşturuyoruz. Zararlıyı sisteme enfekte ettikten sonra ilgili tüm olayları takip edebilmek için “SysInternals – Process Monitor” ‘ü başlatıyoruz ve çalışmalarımız boyunca görünür kalmasını sağlıyoruz.

KillDisk zararlısı resmi olarak “ololo.exe” olarak geçmektedir. “ololo.exe” zararlısı çalıştırıldıktan sonra “Process Monitor” uygulamasında filtreleyerek zararlı yazılımı aşağıdaki gibi çalıştığını görüyoruz.

Ardından, zararlı yazılımı IDA Pro Disassembler’a yüklüyoruz ve aşağıdaki resimdeki değere dikkatlice bakınız. Bu, WinMain işlevidir, yani ana işlevdir, dolayısıyla ilk analize başlayacağımız sub_40E070 adlı yordam çağrısı olacağını görürsünüz.

Öyleyse analizlerimize doğrudan bu yordam ile başlayalım. Burada, dosya uzantılarının belleğe çıkarılmasından sorumlu olan prosedürleri ve sub_40E070 olarak adlandırılan ilginç bir şeyi çağırdıktan sonraki ilk prosedürü aşağıda bulabilirsiniz.

Şimdi bu içeriğe aşağıda paylaştığımız resimden daha yakından bakalım.

Yukarıda da göreceğiniz gibi iç kısımlardan ilginç bir sistem çağrısı bulunmakta. “CreateFile” ile “sub_40C390” ve “sub_40C400” prosedürleri çağırılıyor. Sanal makinemizde şimdiki durumun anlık görüntüsünü alıp analize devam ediyoruz.

Şimdi “CreateFile” işlev çağrısını inceleyelim, üzerinde BreakPoint’i ayarlayalım.

“CreateFile” işlevi bir dosya veya “I/O aygıtı” oluşturur veya açar. En yaygın kullanılan I/O aygıtları şu şekildedir: dosya, dosya akışı, dizin, fiziksel disk, birim, konsol arabelleği (CONIN$ veya CONOUT$), teyp sürücüsü, iletişim kaynağı, mailslot vb. İşlev, dosya veya aygıta ve belirtilen flag’lere ve özniteliklere (attributes) bağlı olarak çeşitli I/O türleri için dosyaya veya aygıta erişmek için kullanılabilecek bir işlev döndürür. Bildiğimiz gibi, başlangıçta C ile yazılmış bir örnekle uğraştığımızdan derleyicilerin çoğunun argümanları bir yığıt üzerinden bir işleve aktarması ve C direktiflerine göre argümanlar birinci fonksiyon argümanının olduğu şekilde sağdan sola yığının üzerine itilir.

Yığın ile çalışmak için özel bir ESP ( Extended Stack Pointer/Genişletilmiş Yığın İşaretçisi) Register bulunmaktadır. ESP, tanım olarak, her zaman yığının üstüne işaret etmektedir.

Aşağıdaki resimdeki yığına bakalım.

Yığın içine itilmiş olan son argüman (üstte bir tane) fonksiyon tarafından kabul edilen ilk argümandır. (CreateFile fonksiyonunun sözdizimine göre) ve \\. \ PHYSICALDRIVE0 dosya ismini içerir, böylece hedef ilk fiziksel sürücüdür.

Şimdi, işleve gönderilen diğer argümanların değerlerini yığından alarak analiz ediyoruz:

  • lpFileName – açılmış veya oluşturulmuş dosyanın adını (yolunu) içeren “ASCIIZ-string” işaretçisi
  • dwDesiredAccess – dosyaya erişim tipi: bizim durumumuzda değer 0C0000000h’dir. Bunun anlamı “GENERIC_READ + GENERIC_WRITE” veya okuma-yazma erişimidir.
  • DwShareMode – dosyaların farklı işlemlerle paylaşılmasını sağlayan bir moddur ve bu parametrenin bizim durumumuzda pf 00000003b değerini çeviren farklı değerleri olabilir. Bunun anlamı “FILE_SHARE_READ + FILE_SHARE_WRITE” veya diğer işlemler okuma/yazma için dosyayı açabilmesidir.
  • LpSecurityAttributes – güvenlik ayarlanmamışsa, çekirdek dosya nesnesine ilişkin güvenlik ayarlarını tanımlayan SecurityAttributes yapısındaki (file winbase.h) işaretçisi “NULL” değeri kullanılıyor.
  • dwCreationDistribution – dosya mevcut olduğunda veya mevcut olmadığında eylemlerin kararlaştırılmasından sorumludur. 3 değeri “OPEN_EXISTING” veya dosyayı açın ve mevcut değilse bir hata döndürün anlamına gelmektedir.
  • DwFlagsAndAttributes – flag’ler ve öznitelikler; Bu parametre oluşturulan dosyanın özelliklerini ayarlamak için kullanılır ve “0” okuma modunda dikkate alınmaz anlamındadır.
  • hTemplateFile – parametre sadece yeni dosya “0” oluşturulduğunda kullanılır.

Başarı durumunda fonksiyon yeni dosyanın “ЕАХ” denetimcisine döner ve eğer işlev başarısız olursa “Null” değeri “ЕАХ” register’ine yazılır.

“CreateFile” çağrıldıktan sonra”EAX” için sıfır olmayan bir değer alırız, yani “\\. \ PHYSICALDRIVE0” istenen dosyanın işleyicisini içerir.

İşleyicimizi aldık, böylece bir sonraki “sub_40C390” fonksiyon çağrısına geçelim.

Prosedürün içine detaylı olarak baktığımızda başka ilginç bir çağrı betiği görüyoruz:

DeviceIoControl işlevi, belirli bir aygıt sürücüsüne doğrudan bir kontrol kodu göndererek, ilgili aygıtın ilgili işlemi gerçekleştirmesine neden olur. Bu işlevi çağırmadan hemen önce yığının detaylarına hızlıca bakalım;

  • hDevice – cihaz tanımlayıcısı \\. \ PHYSICALDRIVE0
  • dwIoControlCode – operasyon kodudur. Bizim durumumuzda değeri 0x70000h bunun anlamı “IOCTL_DISK_GET_DRIVE_GEOMETRY” veya disk geometrisi ile ilgili bilgilerin alınması (disk silindir miktarı, medya türü, disk silindiri üzerindeki parçalar, parça başına sektörler, sektör başına bayt vb.)
  • lpInBuffer – giriş verileri ile tampon. Herhangi bir girdi verilerine ihtiyacımız olmadığından bu değer “NULL” dur.
  • nInBufferSize – giriş arabelleğinin bayt cinsinden eşit boyutudur. Değerimiz “0”‘dır.
  • lpOutBuffer – çıktı arabelleği işaretçisidir. Türü dwIoControlCode parametresi 0x0011FCA8h tarafından ayarlanır.
  • nOutBufferSize – bayt cinsinden çıktı arabelleği boyutu 0x18h’dır.
  • lpBytesReturned – 0x0011FCA4h çıkışına yazılan bayt miktarını içeren bir işaretçi değişkenidir.
  • lpOverlapped – Yapısal OVERLAPPED işaretçisidir. Çağrı işlendikçe, arabelleğe bakarız. (lpOutBuffer’a argüman olarak gönderilen adreste tam olarak 0x0011FCA8h değerindedir.)

Yukarıdaki adreslerdeki detayları şu şekilde yorumlayabiliriz.

  • 0x0011FCA4h adresinde; 24 sembol için sorduğumuz kadarıyla aldığımız fonksiyonla (yeşil ile işaretlenmiş) belirtildiği gibi çıktı tamponuna yazılan bayt miktarının geri döndüğü bilgisine sahibiz.
  • 0x0011FCA8h adresinde; İlk fiziksel disk geometrisi hakkında bilgileri aldık. (\\. \ PHYSICALDRIVE0) Bunlar şu şekildedir.
    • silindir miktarı – 0x519h (1305)
    • ortam türü – 0x0Ch (12) sabit sabit disk anlamına gelir.
    • silindir başına izler – 0x0FFh (255)
    • parça başına sektörler – 0x3Fh (63)
    • sektör başına bayt – 0x200 (512)

Şimdi sub_40C400’dan çağrılan prosedürü inceliyoruz.

Prosedürün içinde iki çağrı “SetFilePointerEx” ve “WriteFile” hemen dikkatimizi çekiyor. “SetFilePointerEx” işlevi, belirtilen açılmış dosyanın dosya tanıtıcısını taşır. “SetFilePointerEx” fonksiyon çağrısının içeriğine detaylı bir şekilde bakalım.

  • hfile – cihaz tanımlayıcısı “\\. \ PHYSICALDRIVE0”
  • liDustanceToMove – Yazmaya başlamak için başlangıç pozisyonunu tanımlar. değeri “0” dır.
  • lpNewFilePointer – 0x0011FCA8h dosyasından yeni bir konum işaretçisi alan bir değişken işaretçisidir. Parametrenin EMPTY (NULL) olduğu bir durumda, dosyaya yeni bir işaretçi döndürülmez.
  • dwMoveMethod – giriş arabelleğinin bayt cinsinden boyutudur. Bizim incelediğimiz durumda sektördeki 0x200h (512) – bayt değerindedir.

Okunabilirliği ve takip edilebilirliği açısından BlackEnergy zararlısının detaylı analizini bölümlere ayırarak sizlerle paylaşacağım. Bir sonraki yazımda kaldığımız yerden “WriteFile” çağrısı ile incelemeye devam edeceğiz.

0 0 Oy
Article Rating
0 Paylaşımlar
Yazı Etiketleri:
· · ·
Abone ol
Bildir
0 Yorum
Satır İçi Geri Bildirimler
Tüm yorumları görüntüleyin
0
Makalem ile ilgili yorumlarınız varsa lütfen yorum yapın.x
()
x
error: Uyarı: İçerik korunmaktadır !!