Новая версия шифровальщика ESXiArgs предотвращает восстановление VMware ESXi

2 496

Новые атаки программы-вымогателя ESXiArgs теперь шифруют более большие объемы данных, что значительно усложняет, если не делает невозможным, восстановление зашифрованных виртуальных машин VMware ESXi.

В пятницу (4 февраля 2023 г.) в результате масштабной и широковещательной автоматической атаки вымогателей было зашифровано более 3000 открытых для доступа к Интернету серверов VMware ESXi с помощью новой программы-вымогателя ESXiArgs.

В предварительных отчетах указывалось, что устройства были взломаны с использованием старых уязвимостей VMware SLP. Однако некоторые жертвы заявили, что SLP был отключен на их устройствах, но также был взломан и зашифрован.

При шифровании устройства 'encrypt.sh ' скрипт ищет файлы виртуальной машины, соответствующие следующим расширениями:

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

Для каждого найденного файла скрипт проверяет размер файла и, если размер файла меньше 128 МБ, шифрует весь файл с шагом 1 МБ.

Однако для файлов размером более 128 МБ будет вычислен параметр 'size_step', который заставит шифровальщик чередовать шифрование 1 МБ данных и нешифрованных фрагментов (размер_шага в мегабайтах) данных.

encrypt.sh скрипт использует следующую формулу (слегка измененную для удобства чтения), чтобы определить, какой размер_шага следует использовать:

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

Это означает, что для файла размером 4,5 ГБ будет генерироваться значение size_step равное '45', в результате чего шифровальщик будет чередовать шифрование 1 МБ файла и пропуск 45 МБ файла. Итак, как вы можете видеть, довольно много данных остается незашифрованным к моменту завершения шифрования файла.

Для файлов даже большего размера, таких как файл объемом 450 ГБ, объем пропущенных данных резко возрастает, а шаг size_step становится "4607", что теперь чередуется между шифрованием 1 МБ и пропуском 4,49 ГБ данных.

Из-за этих больших объемов незашифрованных данных исследователи разработали метод восстановления виртуальных машин с использованием больших и в основном незашифрованных плоских файлов, в которых хранятся дисковые данные виртуальной машины.

Сценарий, созданный CISA, позже автоматизировал этот процесс восстановления.

Изменен процесс шифрования

К сожалению, 8 февраля началась вторая волна программ-вымогателей ESXiArgs, которая включает в себя модифицированную процедуру шифрования, которая шифрует гораздо больше данных в больших файлах.

BleepingComputer впервые узнал о второй волне после того, как администратор опубликовал в разделе поддержки ESXiArgs сообщение о том, что их сервер был зашифрован и не может быть восстановлен с помощью методов, которые работали ранее.

После обмена образцами с BleepingComputer мы заметили, что шифратор не изменился, но encrypt.sh процедура 'size_step' скрипта была удалена и просто установлена на 1 в новой версии.

Это изменение показано ниже в сравнении с оригиналом encrypt.sh вычисление размера шага (слева) в первой волне атак, с новым сценарием оболочки (справа) во второй волне.

Исходный сценарий слева, новый сценарий справа, устанавливающий size_step равным 1
Источник: BleepingComputer

Эксперт по программам-вымогателям Майкл Гиллеспи сообщил BleepingComputer, что это изменение заставляет шифровальщик чередовать шифрование 1 МБ данных и пропуск 1 МБ данных.

Все файлы размером более 128 МБ теперь будут зашифрованы на 50%, что делает их, скорее всего, невосстановимыми.

Это изменение также препятствует успешному восстановлению компьютеров предыдущими средствами восстановления, поскольку в плоских файлах будет зашифровано слишком много данных, чтобы их можно было использовать.

Эта вторая волна атаки также внесла незначительные изменения в уведомление о выкупе, больше не включая биткойн-адреса в уведомление о выкупе, как показано ниже:

Удаление биткойн-адресов, вероятно, было связано с тем, что они были собраны исследователями безопасности для отслеживания платежей за выкуп.

Однако, что еще более тревожно, администратор, предоставивший доступ к новым образцам, сказал, что на их сервере был отключен SLP, но он все равно был снова взломан. Они также проверили наличие vmtool.py бэкдор видели в предыдущих атаках, и он не был найден.

При отключенном SLP становится еще более непонятным, как был взломан этот сервер.

BleepingComputer по-прежнему рекомендует пытаться восстановить зашифрованные серверы ESXi с помощью сценария восстановления CISA.

Однако, скорее всего, она больше не будет работать, если вы были заражены во время второй волны атак с использованием новой процедуры шифрования.

Если у вас есть какие-либо вопросы или вам нужна поддержка по программе-вымогателю ESXiArgs, у нас есть специальная тема поддержки на наших форумах.

Источник

Цыганская ОПГ отправляла сибиряков на СВО, а сама жила в их квартирах и на их выплаты

В Новосибирске накрыли целую ОПГ, которая изощрённо зарабатывала на доверчивых жителях города. Банда цыган промышляли тем, что обманным путём отправляла на СВО новосибирцев, а сами поль...

Обсудить
  • Первое админское правило -БЕКАП. Иначе админ лох.