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

2 549

Новые атаки программы-вымогателя 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, у нас есть специальная тема поддержки на наших форумах.

Источник

Украина совершенствуется

Помните анекдот об украинце, который просил Бога выбить себе глаз, чтобы сосед потерял оба. Так вот, он больше не соответствует действительности. Теперь украинцы готовы отдать оба глаза...

Рождение ненависти

Сейчас "мудрые эксперты" рассказывают, что Зеленскому некуда деваться – осталось только капитулировать, поскольку США от него отвернулись, а украинский народ якобы "прозревает". Иногда ...

Коалиция немощных

Собственно, потужно Итак, вчера успешно завершилась очередная встреча в рамках «коалиции желающих». В этот раз в Париже. Чем она отличалась от аналогичной в Лондоне – непонят...

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