Sodinokibi / REvil Kötü Amaçlı Yazılım Analizi

giriiş​

REvil olarak da adlandırılan Sodinokibi, Nisan 2019'dan beri aktif olan bir fidye yazılımıdır. Eski sürüm zaten analiz edildi, ancak Sodinokibi, özelliklerini ve davranışını değiştirerek sık sık güncellemeler alıyor. Bu makalede , Mart 2020'de PE zaman damgasına göre derlenen bir Amossys CERT görevi sırasında bulunan bir örneği analiz edeceğiz .

Bu makalenin amacı, kötü amaçlı yazılımın nasıl çalıştığını detaylandırmak ve mümkün olduğunda tersine mühendislik ipuçları sağlamaktır. IDA Pro ile statik tersine çevirmenin yeterli olduğu kanıtlandığı için dinamik analiz yapılmadı.

Kötü amaçlı yazılımın tanıtımı​

Sodinokibi bir "Hizmet Olarak Fidye Yazılımı"dır, bu da geliştiricilerin saldırıları gerçekleştirmediği anlamına gelir. Bunun yerine bir yönetim/ödeme altyapısı sürdürürler ve kötü amaçlı yazılımı müşterilere verir veya satarlar. Bu müşteriler, kötü amaçlı yazılımı yayanlardır. Geliştiriciler ödenen her fidye için bir yüzde alır. Bu yaklaşımın birçok avantajı vardır: enfeksiyon kaynakları çoğalır, geliştiriciler koda ve bakıma odaklanırken müşteriler saldıran ve bulaşan hedeflere odaklanabilir.

Siber güvenlik blogu Krebs'e göre , Haziran 2020'de Sodinokibi'nin arkasındaki suçlular, kurbanlar fidyeyi ödemeye meyilli değilse çalınan verileri satmaya başladı 1 . Sodinokibi'de veri çalma özellikleri bulunmadığından, bu, enfeksiyonların manuel olduğunu ve zaten güvenliği ihlal edilmiş sistemi hedef aldığını varsayalım.

Örnek bilgi​

PE hakkında imza ve bilgi almak için örneğimizi Virus Total'e yükledik.



Şekil 1: Virüs Toplam puanı


Şekil 2: Örnek İmzalar

Gizlenmiş IAT​

PE'yi IDA'ya yükledikten hemen sonra, ithalat tablosunun (IAT) muhtemelen gizlendiğini fark ettik. İki nokta bu sonuca yol açabilir. İlk olarak, IDA yalnızca 5 içe aktarılan işlevi algılar; bu, önemli bir şey yapmak için çok az sayıdadır.



Şekil 3: IDA ithalat alt görünümü
Ardından program, geçerli bir işleve işaret etmeyen sözcükleri çağırır. Bu kelimeler, gizlenmiş IAT olabilir.



Şekil 4: Bilinmeyen dwords çağrıları


Şekil 5: Muhtemel karartılmış IAT
Herhangi bir şey yapmadan önce, kötü amaçlı yazılımın IAT'sini gizlemesi gerekir. İlk fonksiyona bakarak dword_40ff40, karışık IAT'nin başlangıcına bir işaretçi olan aşağıdaki döngüyü görebiliriz:


Şekil 6: Gizleme kaldırma döngüsü
sub_406817bilinmeyen kelimeleri geçerli fonksiyon adreslerine çözmek için kullanılır. İşte nasıl çalıştığı:



Şekil 7: Dword çözünürlüğü

1. Gizlenmiş dword dönüştürülür (XOR ve bit kaydırma ile). Yeni dword 2'ye bölünmüştür. En önemli 11 bit bir DLL'yi belirtir. En az önemli 21 bit, bu DLL tarafından dışa aktarılan bir işlevi belirtir.
2. LoadLibrary()11 bitlik değere karşılık gelen DLL, fonksiyonla birlikte belleğe yüklenir .
3. Kitaplık tarafından dışa aktarılan her bir işlevin adı, özel bir algoritma kullanılarak özetlenir. Hash, 21 bitlik değerle karşılaştırılır. Eşleşirlerse, gizlenmiş dword bellekteki doğru işlev adresiyle değiştirilir.

Bakalım tüm bu adımlar IDA Pro'da nasıl görünüyor.

Hash dönüşümü​

Gizlenmiş dword ( arg_iat_hashburada adlandırılmıştır) bu satırla dönüştürülür:



Şekil 8: Gizlenmiş dword dönüşümü

Yer değiştir​

dll_hashBurada switch / case ifadesi, değişkene bağlı olarak belirli bir DLL dosyasını yüklemek için kullanılır . Switch / Case ifadeleri genellikle şöyle görünecek şekilde derlenir:

Şekil 9: Derlenmiş anahtar / vaka ifadesi
Dikkate alınan değer (burada dll_hash) doğrudan değerlerle karşılaştırılmak yerine çıkarılır ve 0 ile karşılaştırılır. Her derleyicinin koşullu ifadeleri işlemek için kendi yolu vardır, ancak bunu birkaç kez gördük.

Yük Kitaplığı()​

LoadLibrary()DLL'ler işlevle yüklenir .



Şekil 10: LoadLibrary() işlevi karması
LoadLibrary()Kernel32 kitaplığı tarafından dışa aktarılır. Bu nedenle LoadLibrary(), gizlenmiş IAT'de kendisinin çözülmesi gerektiğinde, Kernel32 yüklenemez. Birkaç karmaşık olmayan işlev sayesinde (bkz. Şekil 3 ), işlem başladığında Kernel32 zaten yüklenmiştir. Çözülmesi LoadLibrary()gerektiğinde, program yüklü modüller için İşlem Ortamı Bloğuna bakar ve bir başka karma mekanizma ile Kernel32'nin adresini alır.



Şekil 11: PEB yapısından DLL alımı

İşlev adı ve adres çözünürlüğü​

DLL adresi bilindiğinde, aşağıdaki kod yürütülür:



Şekil 12: Bilinmeyen kod
Bir PE dosyası için 0x3C ve 0x78 ofsetleri fark edilir. 0x3C, PE başlığının ofsetidir ve 0x78, bu PE başlığındaki IMAGE_DATA_DIRECTORY yapısının ofsetidir. Veri dizinleri, PE dosyası hakkında çeşitli bilgiler içerir. İlki (IMAGE_DATA_DIRECTORY'de 0x00 ofset), dışa aktarılan işlevler hakkında bilgi içeren IMAGE_EXPORT_DIRECTORY'dir. İşte düzeni:


Bu yapıyı IDA'ya aktarabilir ve v18değişken türünü değiştirebiliriz. Artık yapının hangi alanlarına erişildiğini görüyoruz.

Şekil 13: Dışa aktarılan işlev erişimi
Dışa aktarılan her işlev adı daha sonra hashlenir ve bilinmeyen hash ile karşılaştırılır. Eşleşirlerse, bilinmeyen dword doğru işlev adresiyle değiştirilir.



Şekil 14: İşlev karmaları karşılaştırması

İşlev adı karması​

İşlev adları aşağıdaki kodla özetlenir:



Şekil 15: Karma işlevi
IDA forkod çözücü tarafından görüntülenen döngü çok net olmayabilir. İşte python'da bir eşdeğer:



Potansiyel girdiler ortak DLL'den gelen işlev adlarıyla sınırlı olduğundan, bu karma işlevin çok sağlam olması gerekmez.

Otomasyon​

Artık gizleme mekanizmasını anladığımıza göre, gizlenmiş IAT'deki her dword'ü doğru işlev adıyla yeniden adlandırabiliriz. OALabs ekibi, özellikle Sodinokibi için bu süreci otomatikleştirmek için IDA komut dosyaları sağlar. İlk komut dosyası 2 , yaygın olarak kullanılan DLL'deki işlevler için karmalar oluşturur. İkinci komut dosyası 3 , gizlenmiş IAT'deki her dword'ü daha önce oluşturulmuş karmalarla karşılaştırır. Eşleşirlerse, dword karşılık gelen işlev adıyla yeniden adlandırılır.

Komut dosyalarını yürüttükten sonra, işlevler başarıyla yeniden adlandırılır. Örnek olarak, Şekil 4'teki dword'ler ve CreateMutexW()şeklinde çözümlenmiştir RtlGetLastWin32Error().



Şekil 16: Çözümlenen çağrılar

Şifrelenmiş dizeler​

Kötü amaçlı yazılım anlamlı dizeler içermiyor. Gizlenmiş veya şifrelenmiş olabilirler. CreateMutexW()Az önce çözdüğümüz çağrıya bir göz atalım :



Şekil 17: Bilinmeyen muteks adı
Burada, v2muteks adını içeren bir dize olmalıdır. Yalnızca , ilk argüman olarak sub_4056E3()birçok başka yerde çağrılan bir işlevde kullanılır:unk_4101C0



Şekil 18: sub_4056E3 dış referansları
Ne sıklıkta sub_4056E3()çağrıldığı göz önüne alındığında, muhtemelen bir şekilde dizeleri başlatmak için kullanılır. Buna bakarak aşağıdaki kodu bulabiliriz:



Şekil 19: İkili dosyadan RC4 özü
0'dan 255'e (0x100 değerleri) giden iki döngü görüyoruz. Bu şema, RC4 şifreleme algoritmasının özelliğidir. İşte RC4 Wikipedia sayfasından alınan eşdeğer sözde kod :



Şekil 20: RC4 sözde kodu
RC4'ün anahtarı, şifrelenecek veya şifresi çözülecek verileri ve bunların ilgili boyutlarını bilmesi gerekir. sub_4056E3()Argümanları aşağıdaki gibi yeniden adlandırabiliriz :



Şekil 21: Dize şifre çözme işlevi argümanları
unk_4101C0(renamed ptr_to_enc_str) şifrelenmiş dizeleri ve bunların şifre çözme anahtarını içeren bir veri bloğuna yönelik bir işaretçidir. Sonraki bağımsız değişken, veri bloğundaki anahtarın mahsupudur. Daha sonra key ve string boyutları verilir. Blobdaki dize uzaklığı, anahtar uzaklığı ve anahtar boyutu eklenerek elde edilir. Bu, veri bloğunda anahtarın ve karşılık gelen dizenin bitişik olduğu anlamına gelir.

Otomasyon​

Burada yine OAlabs , sokmaların şifre çözmesini otomatikleştirmek için bir komut dosyası 4 sağlar. Komut dosyası, öğesine yapılan her çağrı için sub_4056E3()bağımsız değişkenleri getirir ve dizenin şifresini çözer. Şifresi çözülen dize, çağrının yanına bir yorum olarak eklenir. Mutex adının sonucu:



Şekil 22: Şifresi çözülmüş muteks adı

Eşzamanlılık denetimi​

Önceki iki bölümde (Gizlenmiş IAT ve Şifreli Dizeler), kötü amaçlı yazılımın bir Mutex açtığı ve zaten var olup olmadığını kontrol ettiği kısa bir kod parçasını örnek olarak aldık. Bu kod, kötü amaçlı yazılımın iki örneğinin aynı anda çalışmasını önlemek için burada. Normalde, kötü amaçlı yazılım bunu önlemek için tasarlanmıştır, ancak dosyalar iki kez şifrelenirse, kurban fidyeyi ödedikten sonra bile onları kurtaramayabilir. Ancak Sodinokibi yazarları veri kurtarma oranına büyük önem veriyor gibi görünüyor. İşte ödeme talimatının bir parçası:

2019'un ikinci çeyreğinde, bir şifre çözücü için ödeme yapan kurbanlar, şifrelenmiş verilerinin %92'sini kurtardı. Bu istatistik, fidye yazılımı türüne bağlı olarak önemli ölçüde değişiyordu.
Örneğin, Ryuk fidye yazılımı ~%87 ile nispeten düşük bir veri kurtarma oranına sahipken, Sodinokibi %100'e yakındı. "
Artık dosyalarınızın %100 iade edileceğine dair bir garantiniz var.

Genişletmek için tıkla ...

Kötü amaçlı yazılımın veri kurtarma oranı düşükse ve kötü bir itibar kazanırsa, mağdurlar ödeme yapmaya daha az meyilli olacak ve yazarlar için kayıplara neden olacaktır.

Ayrıcalıkların elde edilmesi​

Kötü amaçlı yazılım, sistemdeki dosyaları okumak ve üzerine yazmak için yönetici ayrıcalıklarına ihtiyaç duyar. Kötü amaçlı yazılımın yeterli ayrıcalığa sahip olup olmadığını kontrol etmek için üç test yapılır:



Şekil 23: Ayrıcalıklar doğrulaması
İlk olarak, Windows sürümünün Windows XP veya daha düşük olup olmadığını kontrol eder. Ardından, işlem Token haklarının yükseltilip yükseltilemeyeceğini kontrol eder. Son olarak, süreç SID'sini kontrol eder. Tüm testler başarısız olursa (yönetici ayrıcalığı yoksa), kötü amaçlı yazılım, kullanıcı onayını almak için UAC istemine spam gönderir:



Şekil 24: Sonsuz kullanıcı onayı isteği
İşlev ShellExecuteExW(), verilen parametrelerle bir ikili yürütmek için kullanılır. Komut , runasonu Yönetici olarak yürütür ve kullanıcıdan onay ister. ShellExecuteExW()sonsuz döngüde çağrılır. Farkında olmayan bir kullanıcı, sinirlenmeden önce defalarca "hayır" diyebilir ve "evet" diyebilir. Alternatif olarak, kötü amaçlı yazılım, güvenliği ihlal edilmiş bir sistemde zaten yönetici ayrıcalıklarına sahip olan bir saldırgan tarafından yürütülebilir.

Yapılandırma​

Yönetici ayrıcalıklarını aldıktan sonra kötü amaçlı yazılım, JSON yapılandırmasını okur. Dizeler olarak, yapılandırma RC4 şifrelidir. Burada adı verilen ikili dosyanın özel bir bölümüne gömülüdür .11hix. Bu ad muhtemelen kötü amaçlı yazılımın her sürümünde değiştirilir.



Şekil 25: PE bölümleri adları
Örneğimizin yapılandırmasındaki tüm alanlar şunlardır:



Şekil 26: JSON yapılandırma alanları
Şifresi çözüldüğünde, tüm alan verilerini belleğe yüklemek için yapılandırma ayrıştırılır. Kötü amaçlı yazılım yazarlarının bir JSON ayrıştırıcısı geliştirmek için zaman harcaması pek olası değildir. Muhtemelen zaten var olan bir çözümü kullandılar. Sık kullanılan ayrıştırıcıyı arayalım:



Şekil 27: JSON Ayrıştırıcı araması
En iyi 2 sonuç cJSONve json-parser. Bu iki ayrıştırıcının JSON veri türlerini işlemek için farklı bir yolu olduğunu görebiliriz. cJSONtürler şu şekilde tanımlanır :

DEVAMI İSTENİRSE GELECEKTİR

keşki kendin sıfırdan analiz etseydin zararlı yazılımı ama yinede eline sağlık diyorum

Daeky' Alıntı:

Sodinokibi / REvil Malware Analysis

www.amossys.fr

keşki kendin sıfırdan analiz etseydin zararlı yazılımı ama yinede eline sağlık diyorum

Genişletmek için tıkla ...

bu tarz platforumlarda henüz ilk tercübem fakat güzel egitim setlerim bulunmakta farklı farklı türlerde şuanlık etkileşim için bunu paylaştım mecburiyeten söz konusu benim onun analizi degil önemli olan insanlara birşeyler suna bilmek sunulan tabi doğru ise bu işin içinde herkes birinden birşeyler almadımı ? gerek bilgi gerek fikir merak etmeyin gereken şeyleri paylaşmış bulunmaktayım şuan ise yapmam gerekicek tek şey etkileşimimi yerine oturtmak güzel derin aramalar dilerim