March 29, 2023


Server VMware ESXi dienkripsi

Serangan ransomware ESXiArgs baru sekarang mengenkripsi data dalam jumlah yang lebih luas, membuatnya jauh lebih sulit, jika bukan tidak mungkin, untuk memulihkan mesin virtual VMware ESXi terenkripsi.

Jumat lalu, besar-besaran dan serangan ransomware otomatis yang tersebar luas dienkripsi lebih dari 3.000 server VMware ESXi yang terpapar Internet menggunakan ransomware ESXiArgs baru.

Laporan awal menunjukkan bahwa perangkat dibobol menggunakan kerentanan VMware SLP lama. Namun, beberapa korban menyatakan bahwa SLP dinonaktifkan pada perangkat mereka dan masih dilanggar dan dienkripsi.

Saat mengenkripsi perangkat, skrip ‘encrypt.sh’ mencari file mesin virtual yang cocok dengan ekstensi berikut:

.vmdk
.vmx
.vmxf
.vmsd
.vmsn
.vswp
.vmss
.nvram
.vmem

Untuk setiap file yang ditemukan, skrip memeriksa ukuran file, dan jika file lebih kecil dari 128 MB, mengenkripsi seluruh file dengan peningkatan 1 MB.

Namun, untuk file yang lebih besar dari 128 MB, itu akan menghitung ‘size_step’, yang akan menyebabkan encryptor bergantian antara mengenkripsi 1 MB data dan tidak mengenkripsi bongkahan (size_step dalam megabita) data.

Skrip encrypt.sh menggunakan rumus berikut (sedikit dimodifikasi agar mudah dibaca) untuk menentukan size_step apa yang harus digunakan:

size_step=((($size_in_kb/1024/100)-1))

Ini berarti untuk file 4,5 GB, itu akan menghasilkan size_step dari ’45,’ menyebabkan encryptor bergantian antara mengenkripsi 1 MB file dan melewatkan 45 MB file. Jadi, seperti yang Anda lihat, cukup banyak data yang tetap tidak terenkripsi saat selesai mengenkripsi file.

Untuk file yang lebih besar lagi, seperti file 450 GB, jumlah data yang dilewati meningkat secara dramatis, dengan size_step menjadi ‘4607,’ sekarang bergantian antara mengenkripsi 1 MB dan melewatkan 4,49 GB data.

Karena potongan besar data yang tidak terenkripsi ini, para peneliti merancang sebuah metode untuk memulihkan mesin virtual menggunakan file datar yang besar dan tidak terenkripsi, tempat data disk mesin virtual disimpan.

Skrip yang dibuat oleh CISA kemudian mengotomatiskan proses pemulihan ini.

Proses enkripsi berubah

Sayangnya, gelombang ransomware ESXiArgs kedua dimulai hari ini dan menyertakan rutinitas enkripsi yang dimodifikasi yang mengenkripsi jauh lebih banyak data dalam file besar.

BleepingComputer pertama kali mengetahui gelombang kedua setelah admin diposting di topik dukungan ESXiArgs menyatakan bahwa server mereka dienkripsi dan tidak dapat dipulihkan menggunakan metode yang berhasil sebelumnya.

Setelah membagikan sampel dengan BleepingComputer, kami melihat bahwa enkripsi tidak berubah, tetapi rutinitas ‘size_step’ skrip encrypt.sh telah dihapus dan hanya disetel ke 1 di versi baru.

Perubahan ini diilustrasikan di bawah dalam perbandingan antara komputasi size_step encrypt.sh asli (kiri) pada serangan gelombang pertama, dengan skrip shell baru (kanan) pada gelombang kedua.

Skrip asli di sebelah kiri, skrip baru di sebelah kanan menyetel size_step ke 1
Skrip asli di sebelah kiri, skrip baru di sebelah kanan menyetel size_step ke 1
Sumber: BleepingComputer

Pakar ransomware Michael Gillespie memberi tahu BleepingComputer bahwa perubahan ini menyebabkan enkripsi bergantian antara mengenkripsi 1 MB data dan melewatkan 1 MB data.

Semua file lebih dari 128 MB sekarang akan memiliki 50% dari datanya yang dienkripsi, membuatnya kemungkinan besar tidak dapat dipulihkan.

Perubahan ini juga mencegah alat pemulihan sebelumnya berhasil memulihkan mesin, karena file flat akan memiliki terlalu banyak data yang dienkripsi untuk dapat digunakan.

Serangan gelombang kedua ini juga membuat perubahan kecil pada catatan tebusan dengan tidak lagi menyertakan alamat bitcoin dalam catatan tebusan, seperti yang ditunjukkan di bawah ini.

Catatan tebusan ESXiArgs baru
Catatan tebusan ESXiArgs baru
Sumber: BleepingComputer

Penghapusan alamat bitcoin kemungkinan besar terjadi karena mereka dikumpulkan oleh peneliti keamanan untuk melacak pembayaran uang tebusan.

Namun, yang lebih memprihatinkan lagi, admin yang membagikan sampel baru mengatakan bahwa SLP dinonaktifkan di server mereka tetapi masih dilanggar lagi. Mereka juga memeriksa backdoor vmtool.py yang terlihat pada serangan sebelumnya, dan itu tidak ditemukan.

Dengan SLP dinonaktifkan, semakin membingungkan bagaimana server ini dibobol.

BleepingComputer masih merekomendasikan untuk mencoba memulihkan server ESXi terenkripsi menggunakan Skrip pemulihan CISA.

Namun, kemungkinan tidak akan berfungsi lagi jika Anda terinfeksi dalam serangan gelombang kedua yang menggunakan rutin enkripsi baru.

Jika Anda memiliki pertanyaan atau memerlukan dukungan pada ransomware ESXiArgs, kami memiliki topik dukungan khusus di forum kami.



Leave a Reply

Your email address will not be published. Required fields are marked *