Атаки на виртуальную инфраструктуру VMware ESXi в последнее время стали заметно набирать обороты. Сценарий, когда злоумышленник получает доступ к гипервизору, а затем останавливает все виртуальные машины и шифрует их диски, выглядит пугающе реалистично, особенно если компания не подготовлена к таким угрозам. Речь не только о редких случаяx, когда проникают особо изощрённые APT-группы. Всё чаще встречаются относительно простые, но крайне эффективные шифровальщики, которые атакуют хост ESXi, оставляя администраторов и владельцев инфраструктуры с зашифрованными файлами и практически без каких-либо зацепок для быстрого восстановления.

Именно с такой ситуацией я столкнулся в своей деятельности - крупная коммерческая организация скомпрометирована через фишинг и получение доступа во внутреннюю инфраструктуру с использованием VMware Horizon. Следом за этим, используя уязвимость программного обеспечения, VMware злоумышленником получен доступ к ESXI и загружены вредоносные сценарии.

Мое внимание привлек тот факт, что ни одно средство защиты информации не воспринимало эти файлы как вредоносные.

Сам пакет состоит из трёх компонентов. В корне зла находится исполняемый файл под названием «encrypt», ориентированный на 64-битную Linux-платформу. Если посмотреть на его дизассемблированный код, можно увидеть типичные признаки «рансомварного» поведения: он запрашивает ровно один аргумент (путь к файлу или «образу диска»), открывает его в режиме «rb+», а затем пытается распознать структуру MBR или GPT. В случае неудачи создаёт «фейковый» раздел и в любом случае начинает блочное шифрование. Внутри используются серьёзные криптографические механизмы: закодированное в base64 значение, которое впоследствии разделяется на 3 части и передается Curve25519 для генерации общего секрета, SHA-256 для окончательного преобразования ключа и SoSEMANuk как потоковый шифр для записи зашифрованных данных обратно в тот же файл.

Классические антивирусы, особенно если они установлены в гостевых операционных системах, подобного шифрования не видят, потому что действие разворачивается непосредственно на уровне ESXi, в каталоге /vmfs/volumes, куда антивирусы в гости обычно не заглядывают.

Вторым важным компонентом вредоносного ПО является скрипт «encrypt.sh». Его можно назвать «организационным центром» атаки. В самом начале скрипт проверяет, не запущен ли он уже, чтобы исключить множественные параллельные копии. Затем он отключает некоторые защитные опции, связанные с запуском бинарей, пытается модифицировать конфигурации виртуальных машин, чтобы они не могли правильно использовать диски, и наконец выключает все процессы vmx, то есть грубо убивает работающие виртуалки. После этого скрипт запускает «encrypt» по каждому файлу, который связан с виртуальной инфраструктурой: .vmdk, .vmx, .vswp и так далее. Чтобы администратор заметил катастрофу, в каждой папке создаётся «How To Restore Your Files.txt», а в веб-интерфейсе ESXi подменяется index.html, и жертве остаётся только читать требования злоумышленника. В заключение скрипт удаляет логи, вносит изменения в crontab и некоторые системные файлы, чтобы усложнить расследование и восстановление.

Интересно устроен и файл под названием «root». По сути, он выглядит как фрагмент crontab для пользователя root, в котором наряду с типичными для ESXi заданиями вроде auto-backup.sh внезапно появляются строки с запуском encrypt.sh каждые несколько часов. Вредонос прописывает три одинаковые команды, что создаёт избыточность и гарантирует, что шифровальщик запустится неоднократно. Если администратор сумеет восстановить некоторые файлы из резервной копии, через три часа скрипт снова просканирует каталог /vmfs/volumes и снова зашифрует то, что успели вернуть. Это почти полностью исключает шансы на оперативное восстановление, если не были предприняты меры по удалению зловредных записей в cron и самого скрипта.

Сложность подобных атак на ESXi в том, что многие защитные решения нацелены на гостевую операционную систему. Речь идёт не только об антивирусах, но и о системах NTA (Network Traffic Analysis), которые отслеживают сетевые пакеты, но не видят локальные операции на дисках гипервизора, а также SIEM системах, которые зачастую снимают логи только с гостевых ОС. Злоумышленники не пытаются вызвать большой поток трафика или «засветиться» во внешней сети — всё происходит внутри ESXi, поэтому ни сетевые фильтры, ни агенты, установленные в гостях, не замечают, как в каталоге /vmfs/volumes десятки гигабайт данных превращаются в хаотичный зашифрованный набор байт. Этим объясняется тот факт, что подобные шифровальщики часто оказываются вне поля зрения классических решений безопасности. Механизм работы in-place, когда блоки по 10 или 100 МБ читаются, шифруются и перезаписываются на то же место, выглядит незаметно для большинства систем безопасности, а узкая направленность подобного ПО позволяет уходить от поведенческого анализа. Кстати в полученном образце с целью оптимизации используется многоступенчатая схема анализа - кроме возможности шифровать блоки (в зависимости от размера системы по 10 МБ либо по 100 и пропуская следующие 900 МБ) предусмотрена возможность создания в виртуальной системе дополнительного раздела размером 768 Мб, который используется если софт не смог начать работу с разделами диска либо определил, что разделы имеют формат отличный от MBR/GPT.

Системы анализа не видят угрозы в файле, который не прописывает себя в места автоматического старта, не пытается перехватить контроль над какими-то запросами или отправить обратный коннект к C&C серверу. Вся дополнительная логика ложится в поставляемый с основным ПО bash скрипт.

В результате единичное проникновение на ESXi-хост может обернуться катастрофой для всей виртуальной инфраструктуры. Остановка всех виртуальных машин, подмена конфигураций, периодический перезапуск атаки через cron, полное игнорирование антивирусов на уровне гостевых ОС — всё это делает защиту сложной, а последствия атаки разрушительными. Многие компании, столкнувшись с зашифрованными .vmdk-файлами, оказываются в ситуации, когда никаких дешёвых способов восстановить виртуальные машины не остаётся. Единственное надёжное решение — иметь внешние бэкапы, которые не доступны злоумышленнику, и внимательно следить за безопасностью самого гипервизора. Политика обновлений, закрытие лишних сервисов, ограничения SSH, специализированные решения мониторинга ESXi — всё это перестаёт быть опциональным, когда на кону стоит вся виртуальная инфраструктура.

Опасность подобных атак

1. Массовое отключение всей виртуальной инфраструктуры.
При успешной атаке шифруются файлы всех виртуалок, что парализует работу компании.

2. Усложнённое восстановление.
Скрипт чистит логи, правит конфиги, убирает crontab-записи, меняет файлы. Если нет резервных копий (или они тоже доступны злоумышленнику), восстановить может быть невозможно.

3. Постоянный авто-запуск.
Вредонос прописывает себя в cron, чтобы повторять атаку каждые 3 часа. Даже если админ начнёт что-то исправлять, скрипт вернётся.

На практике атаки на ESXi стали реальным вызовом в последние пару лет, и случаи с массовым шифрованием виртуальных машин уже вызвали громкие инциденты. Злоумышленники не пытаются придумывать что-то сверхсложное: им достаточно один раз загрузить скрипт, бинарник и cron-файл, настроить их запуск, а дальше сам шифровальщик будет раз за разом портить файлы и показывать при каждом обращении к веб-интерфейсу ESXi свою страницу с требованием выкупа. Можно вспомнить, что администраторы обычно сфокусированы на гостевых ОС, а не на самом гипервизоре, и именно этим пользуются авторы вредоносного ПО. Полноценные EPP или EDR-решения на уровне ESXi нечасто встречаются в продакшене, и если злоумышленникам удалось добраться до SSH или уязвимого сервиса, то они практически беспрепятственно внедряют свой скрипт.

Как противодействовать

• Обновлять ESXi и закрывать все известные уязвимости (особенно CVE-2021-21974, и др.).

• Ограничить SSH-доступ: использовать ключи и ограничение IP, отключать, если не нужно.

• Использовать специализированные решения для защиты гипервизоров (есть отдельные продукты, умеющие мониторить ESXi).

• Регулярно делать бэкапы (вне хоста ESXi, чтобы злоумышленник не мог добраться до них).

• Мониторить изменения в /vmfs/volumes, /etc/crontab, /var/spool/cron, /etc/rc.local.d/, /usr/lib/vmware/ на предмет аномальных скриптов и подмен страниц.

Чтобы противостоять таким атакам, важно не только закрывать свежие уязвимости и держать ESXi в актуальном состоянии, но и иметь полноценную схему резервного копирования, которая не зависит от самого гипервизора. Желательно настроить систему оповещений или мониторинга, которые обращают внимание на появление неизвестных скриптов и бинарных файлов в /tmp или других системных каталогах ESXi. Понимание того, что блокчейн-уровень криптографии в рансомварях давно стал нормой, а атаки охватывают всю инфраструктуру, а не только отдельные машины с Windows, помогает выстраивать комплексную защиту. В противном случае одна пропущенная уязвимость на ESXi может поставить под угрозу все виртуальные машины и привести к застою или даже потере важных данных без шансов на дешёвое восстановление.