Bugünkü yazımda BlackEnergy zararlısının bir parçası olan KillDisk analizimize “WriteFile” çağrısı ile kaldığımız yerden devam edeceğiz. Bir WriteFile işlevi verileri, belirtilen dosya veya giriş/çıkış (I/O) aygıtına dosyada belirtilen konumdan başlayarak yazar. Bu işlev hem senkron hem de asenkron çalışma için tasarlanmıştır.


Kodlar arasında ilginç bir kısmı kaçırmadığımızdan emin olmak için gösterge panosuna ve yığına tekrar bir göz atıyoruz:

Hex View-EBP penceresinde ikinci fonksiyon argümanı (veri tamponu) tarafından ele alınan bir alanı işaretledik. 0x200h (512). Komutu F8 tuşuna basarak çalıştırıyoruz ve değişikliği aşağıdaki gibi gözlemliyoruz.

Beklendiği gibi, Proses İzleyicisinde 0 pozisyonundan başlayarak 512 baytlık yazımı düzeltiyor.
Sonra prosedürden çıkıyor ve ancak şimdi farklı değerler ile tekrar çağırıyor: Şimdi, mavi bir çerçeve ile işaretlediğimiz önceki argüman yığınının aksine 0x200’de görülebilen bir sonraki 512 baytı alıyor.

Bu işlem 0x40C865h adresi, 0x100h’ye eşit oluncaya kadar “EBX” kaydı değerini 255 kez çeviriyor. Bunun gerçekleştiğinden emin olmak için, “yıkım” kısır döngüsünü izleyen talimatlara bir durma noktası koyduk.
 

Toplam olarak 256 adet yeniden yazma işlemi yapıyoruz.

Sonrasında “CloseHandle” işlevini çağırarak dosya işleyicisini kapatıyor. CloseHandle işlevi, açılan nesnenin bir nesne işleyicisini kapatır.

ESI register’in içerisinde ne var ?

Beklendiği gibi tanımlayıcımız 0x44h fonksiyon argümanı olarak yığına geçirilir.
EAX kaydındaki fonksiyon tarafından döndürülen değerleri görüyoruz:

Fonksiyon başarılı bir şekilde geri dönüş ile biterse “non-null” değerini alıyor. Bir hatalı fonksiyon varsa, döndürülen değer “null”‘dur. Bu işlemi process monitor’da aşağıdaki gibi izleyebiliriz.

Her şey normal olarak çalıştı ve dosya kapatıldı.

Daha rahat algılanması için işlevini yeniden adlandırdık ve “Eraser” ismini verdik.
Verileri başarılı bir şekilde yok ettikten sonra “PhysicalDrive0″‘da bulunan sayaç “ESI” Kayıt tarafından “1” artırıldı. “0x0Ah (10) değeriyle kontrol edildi ve yeniden yazma işlemini yeni bir değerle başlattı.

ve böylece 10’a ulaşana kadar bu döngü devam ediyor. Böylelikle bu zararlı yazılım tüm fiziksel sürücülere doğru ilerlemeye devam ediyor ve siliyor.
512 * 255 = 128kb  (bu zararlı yazılım, disk geometrisini bildiği ve öğrendiği için bir sektördeki baytların miktarına bağlı olarak ilerliyor.)
Ancak bu sefer “CreateFileW” fonksiyonun sonucu aşağıdaki değer olacaktır:

Bu değer sanal laboratuarımızda ikinci fiziksel disk (veya 0’dan büyük sıralı herhangi bir disk yok) bulunmadığı ve çevrimin yeniden yazılacak bir şeye sahip olmadığı anlamına gelir.
Şimdi yeni kazanılmış bir bilgi ile silahlandık. Yıkıcı işlevi devre dışı bırakmaya çalışalım. Kod modifikasyonunun verileri yeniden yazılmasını engellemesine izin verecek şekilde değiştirdiğini öğrendik.

“CreateFileW” işlev çağrısını içeren “sub_40E080” prosedürünü hatırlayalım. “0xFFFFFFFF” değerinin, “CreateFileW” işlevinin tamamlanmasından sonra, yalnızca fiziksel sürücü olmadığında ve bu senaryoda “veri imhası” işlevinin bir çıkış gerçekleştirmesi durumunda ortaya çıkacağını bildiğimizden”0x0040C7E4h” adresinde bulunan bir koşullu ayrılma talimatını koşulsuz olarak değiştirelim:

IDA Pro güzel bir programdır ve komut yazmamıza müsade ettiği için değişik reaksiyonları gözlemleme şansını bize sunuyor. Gözönünde bulundurmamız gereken tek şey, önce ve sonra komut boyutudur, bu yüzden koşullu sırayla kaç bayt kullanıldığını kontrol edelim:

Koşullu ayrım talimatı görebileceğimiz gibi 6’ya eşittir. Baytlar, koşulsuz dizi sadece 5 alırken ve böylece eşit tutmak için başka bir komut (NOP) ekleyeceğiz:

Daha önce içerdiği şeyden bağımsız olarak bir sonraki komut NOP’dur. (biz orada 0 görsek bile)

Komut adreslerinin şu komutun adresine göre şimdi eşitlendiğini iki kez kontrol ediyoruz.

ve iptal et tuşuna basıyoruz. İşleme tamam. Bu manipulasyonlardan sonra prosedür daha basit görünecektir: giriş ve çıkış, boş bir döngü oluşturma (programın diğer bölümlerinin ne işe yaradığını bilemediğimizden, sadece böyle bir durumda kalmalıyız.)

Process Monitor tarafından tespit edilen son durum, KillDisk uygulamasının sonucunda hiçbir fiziksel sürücünün zarar görmediğine işaret ediyor.

Bu iki yazı dizisinde BlackEnergy 3’ün bir parçası olarak entegre edilen KillDisk zararlı kısmını inceledik. Bir sonraki yazımda BlackEnergy zararlısının ana kodlarını detaylı bir şekilde incelemeye devam edeceğiz.