Изменение метода шифрования ESXiArgs осложнило возврат данных без выкупа

Изменение метода шифрования ESXiArgs осложнило возврат данных без выкупа

Изменение метода шифрования ESXiArgs осложнило возврат данных без выкупа

Зафиксирована новая волна атак шифровальщика ESXiArgs. Как оказалось, его создатели скорректировали код, и разработанные экспертами методы восстановления виртуальных машин VMware ESXi перестали работать.

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

Анализ предоставленного семпла показал, что сценарий encrypt.sh вредоноса слегка изменился, в результате он стал шифровать намного больше данных в крупных файлах.

Названный bash-скрипт вначале ищет файлы виртуальных машин по списку расширений:

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

Для каждой находки он проверяет размер файла; если вес меньше 128 Мбайт, содержимое шифруется целиком, блоками по 1 Мбайт. Для более емких файлов по заданной схеме вычисляется значение size_step, и зловред начинает шифровать данные с пропуском.

Так, при размере шага «45» содержимое обработанного файла в 4,5 Гбайт выглядит следующим образом: 1 Мбайт шифрованных данных – 45 Мбайт нешифрованных, 1 Мбайт шифрованных данных – 45 Мбайт нешифрованных, и т. д. И чем крупнее файл, тем больше блоки данных, оставленных без изменений.

На этом и сыграли турецкие исследователи, предложив действенный способ восстановления серверов, атакованных ESXiArgs. Их наработки легли в основу декриптора, созданного в CISA.

В новой версии вредоноса эта возможность закрыта: шифратор остался без изменений, но для метода size_step задали значение «1». В итоге зловред теперь преобразует большие файлы, чередуя одинаковые блоки данных: 1 Мбайт шифрует, 1 Мбайт игнорирует, то есть половина содержимого становится непригодной для восстановления ВМ прежним способом.

 

Вирусописатели также убрали BTC-адрес из текста записки о выкупе. Возможно, такое изменение вызвано повышенным интересом ИБ-сообщества к биткоин-кошелькам вымогателей — такие адреса начали активно отслеживать.

 

Экспертов особо заинтересовали новые сообщения форумчан, в которых говорилось, что на атакованном сервере был отключен протокол SLP. Это означает, что уязвимость, которую прежде считали причиной заражений ВМ ESXi, теперь не используется. Проверки на наличие бэкдора vmtool.py, замеченного во время первой волны атак ESXiArgs, дали отрицательный результат.

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

81-88% первичных вердиктов сканеров кода оказались ложными

Количество обнаруженных в коде уязвимостей за год выросло на 70%, тогда как очередь на их разбор — лишь на 18%. Сканеры явно научились находить больше, а вот дополнительных инженеров безопасности к ним в комплекте не положили.

AppSec Solutions проанализировала обезличенные данные платформы AppSec.Hub: 4 214 кодовых баз общим объёмом около 510 млн строк и более 3,1 млн находок SAST-, SCA- и DAST-сканеров. В выборку вошли ИТ-компании, финтех и организации реального сектора.

Исследователи подчёркивают: рост числа проблем не обязательно означает, что разработчики внезапно стали писать хуже. С начала 2025 года по май 2026-го объём анализируемого кода увеличился с 333 до 510 млн строк, а количество кодовых баз — с 2 563 до 4 214. Чем больше кода подключают к проверке, тем больше находок получают, особенно на фоне массового вайбкодинга.

Настоящее узкое место начинается после сканирования. Среди ещё не исправленных находок 69% ждут вердикта инженера ИБ. Медианный срок устранения критических проблем за год вырос со 103 до 153 дней. Из уязвимостей, уже переданных разработчикам, закрывают от 12% до 50%.

При этом большая часть лавины — шум, ложными оказываются 81-88% первичных вердиктов сканеров. Доля действительно серьёзных находок High и Critical остаётся стабильной — около 23%. В OWASP Top 10 лидируют нарушения контроля доступа с долей 44%.

По данным разработчика, конвейер AppSec.Hub за полгода превратил 18,7 млн сырых срабатываний в 428 тыс. уникальных находок, а затем — в 9,4 тыс. групп задач на исправление. Поток ужался почти в две тысячи раз.

Правила и ИИ-помощник автоматически закрывают уже 58% первичного разбора. Когда помощник признаёт срабатывание ложным, на крупнейшей проверенной выборке он оказывался прав примерно в 97% случаев. Реальные уязвимости подтверждает человек.

RSS: Новости на портале Anti-Malware.ru