• [ Регистрация ]Открытая и бесплатная
  • Tg admin@ALPHV_Admin (обязательно подтверждение в ЛС форума)

Статья Анализируем энкодер для VMware ESXi

stihl

Moderator
Регистрация
09.02.2012
Сообщения
1,167
Розыгрыши
0
Реакции
510
Deposit
0.228 BTC
stihl не предоставил(а) никакой дополнительной информации.
Целью атаки трояна‑шифровальщика может стать не просто компьютер или работающий в сети сервер, а виртуальная машина уровня предприятия, на которой обычно крутится очень много важных сервисов. Сегодня мы разберем принцип действия шифровальщика, ориентированного на VMware ESXi, и поговорим о том, как обезопасить свою виртуальную инфраструктуру.

Компрометация гипервизора или связанной с ним инфраструктуры может поставить под угрозу целую экосистему серверов, баз данных и бизнес‑приложений. Неудивительно, что хакерские группы все чаще фокусируют свои атаки на VMware ESXi, создавая специализированные программы‑шифровальщики, нацеленные на файлы виртуальных машин, такие как *.vmdk, *.vmx, *.vmsn, *.vswp, *.vmem и другие. Сегодня мы рассмотрим конкретный случай, в котором был обнаружен бинарный ELF-файл с именем encrypt и сопровождающий его Bash-скрипт encrypt.sh. Я подробно опишу этапы атаки: от проникновения в сеть и получения доступа к ESXi до запуска файлов, шифрования виртуальных дисков и устранения следов, что оставляет жертву перед выбором — заплатить выкуп или потерять данные.

Уязвимость и общая схема атаки​

Чтобы понять всю глубину этого инцидента, нужно рассмотреть последовательность действий атакующих от момента эксплуатации уязвимости CVE-2021-44228 на VMware Horizon до непосредственного запуска шифрования на ESXi. Уязвимость, получившая название Log4Shell, стала широко известна зимой 2021–2022 годов и давала возможность злоумышленникам выполнять произвольный код в контексте сервера, где используется логирующая библиотека Log4j уязвимых версий. VMware Horizon, будучи сложным продуктом, базирующимся на Java и в прошлом включавшим уязвимые компоненты, иногда оставался непропатченным, что открывало возможность провести RCE-атаку (remote code execution).


Злоумышленник, имея специальный эксплоит, мог переслать серверу Horizon пакет, включавший вызов к JNDI с вредоносным классом. Библиотека Log4j динамически загружала его и исполняла. Как только этот класс попадал в среду исполнения, он раскрывал перед атакующим безграничные возможности — от установки дополнительного malware-инструментария до внедрения скриптов и эскалации на уровень локального администратора. Именно так, согласно собранным данным, в ряде случаев удавалось проникнуть в корпоративную сеть и скомпрометировать сервер Horizon.

После эксплуатации уязвимости CVE-2021-44228 атака не останавливается на одной машине, ведь обычно злоумышленникам интересны более масштабные цели. Поэтому они анализируют сетевую среду, отыскивают уязвимые узлы и, самое важное, осуществляют атаку SAM-хранилища в попытке извлечь NTLM-хеш локального администратора. Если в компании на многих серверах используется один и тот же пароль локального админа (или хотя бы на нескольких ключевых машинах), это дает атакующим возможность перемещаться по сети (lateral movement) при помощи pass-the-hash.

Когда обнаруживается узел, где запущена сессия пользователя из группы «Администраторы домена», то дамп lsass.exe или аналогичное средство позволяет получить NTLM-хеш доменного админа, после чего злоумышленники могут выполнить любые действия от имени доменного администратора, в том числе получить доступ к ESXi, если настроена аутентификация через доменные учетные записи.

Если учетка Domain Admin без жесткой изоляции тоже имеет право подключаться к ESXi, то злоумышленники этим непременно воспользуются, ведь, овладев доменными привилегиями, они без труда загрузят нужную вредоносную программу в /tmp или другой каталог на гипервизоре (с помощью SCP или иным способом). В нашем случае атакующие загружают файлы encrypt и encrypt.sh — двух компонентов, которые действуют в связке.

Для просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или ЗарегистрируйсяДля просмотра ссылки Войди или Зарегистрируйся

Анализ вредоносных файлов​

Анализ показал, что ELF-бинарь encrypt представляет собой модуль‑вымогатель, написанный под 64-битную Linux-платформу. В ESXi внутренне используется Linux-образ, поэтому запуск ELF-файла напрямую там возможен, особенно если установлен параметр execInstalledOnly = 0 (или скомпилированы нужные shared-библиотеки).

Для просмотра ссылки Войди или Зарегистрируйся

Логика запуска файла encrypt — обработка ошибки, когда нет ссылки на файл для шифрования. Если ссылка присутствует, то запускается процесс шифрования.

Для просмотра ссылки Войди или Зарегистрируйся

Бинарь при старте ждет от пользователя аргумента — пути к файлу, который будет шифроваться. При этом, если верить дизассемблеру, в коде реализованы криптопримитивы Curve25519 (для обмена или генерации ключей) и Sosemanuk (для быстрого шифрования). Давай разберем всю последовательность действий этой софтины.

Для просмотра ссылки Войди или Зарегистрируйся
Вот примерный пошаговый алгоритм выполнения функции.

  1. Открытие файла. Файл открывается для чтения и записи в бинарном режиме. Если открыть файл не удалось (fopen64 вернул NULL), функция возвращает 1.
    Для просмотра ссылки Войди или Зарегистрируйся
  2. Выделение памяти под ключ и инициализация базы данных значениями.
    Для просмотра ссылки Войди или Зарегистрируйся
  3. Декодирование строки Base64 и генерация ключа.
    Для просмотра ссылки Войди или Зарегистрируйся
В коде можно найти вот такие константы:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
Они используются для Base64 в процессе декодирования встроенной строки‑ключа, «вшитой» прямо в бинарь. Исходная длина decoded_length записывается сюда же, прочитанная строка используется для генерации нового ключа функцией generate_key.

Для просмотра ссылки Войди или Зарегистрируйся
Функция generate_key принимает шесть аргументов:

  • _int64 privateKey1 — первый приватный ключ для Curve25519;
  • _int64 privateKey2 — второй приватный ключ для Curve25519;
  • _BYTE *sosemanukStateBuffer — указатель на буфер состояния Sosemanuk (поточного шифра);
  • _BYTE *curve25519PrivateArray — указатель на 32-байтовый массив для работы с Curve25519;
  • _int64 sharedSecret1 — буфер для результата первого вызова функции curve25519_donna;
  • _int64 sharedSecret2 — буфер для результата второго вызова функции curve25519_donna.
Шаги выполнения этой части вредоносного приложения.

  • Очистка памяти. На этом этапе очищаются массивы для последующего использования, чтобы гарантировать отсутствие остаточных данных.
  • Модификация битов (в первом и последнем байтах массива). Это стандартная процедура для корректной настройки закрытого ключа для алгоритма Curve25519.
  • Генерация общего секрета с использованием алгоритма Диффи — Хеллмана посредством Curve2579. Функция curve25519_donna задействована для выполнения операций Диффи — Хеллмана с использованием алгоритма Curve25519. Значения sharedSecret1 и sharedSecret2 генерируются с помощью закрытого ключа curve25519PrivateArray и двух разных открытых ключей privateKey1 и privateKey2.
  • После вычислений закрытый ключ curve25519PrivateArray очищается с помощью функции secure_memset, чтобы предотвратить утечку чувствительной информации.
  • Создается хеш SHA-256 от sharedSecret2. sha256_init() и sha256_hash(), подготавливается и вычисляется хеш.
  • secure_memset(); очищает память, использованную для вычисления SHA-256, чтобы удалить промежуточные данные.
  • sosemanuk_schedule() готовит внутренние состояния для шифра Sosemanuk на основе ключа (результата SHA-256).
  • sosemanuk_init() завершает инициализацию шифра, передавая подготовленный контекст.
  • После использования ключа из SHA-256 он очищается с помощью secure_memset.
На следующем этапе выполняется инициализация списка разделов и проверка файловой системы.

Для просмотра ссылки Войди или Зарегистрируйся
Эта часть кода, как можно понять из названия функций, отвечает за создание списка разделов init_partition, а также за добавление нового раздела, если таковых нет или получено неверное значение функции check_file_system.

Для просмотра ссылки Войди или Зарегистрируйся
Затем программа проверяет, является ли входная структура валидной MBR или GPT.

Для просмотра ссылки Войди или Зарегистрируйся
Эта функция обеспечивает динамическое увеличение массива (если массив заполнен, его емкость удваивается) и при необходимости управляет созданием новых разделов, предотвращая разрыв между последним разделом и только что созданным.

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

Для просмотра ссылки Войди или Зарегистрируйся
Эта функция итеративно обрабатывает массив разделов, вызывая одну из двух функций шифрования:

  • encrypt_other_partition — используется для разделов, которые не являются первым или которые имеют специфические типы;
  • encrypt_file_block — вызывается для первого раздела без данных или для разделов типа 9 (нестандартный или устаревший тип разделов).
Давай глубже изучим, как устроена каждая из этих функций.

Для просмотра ссылки Войди или Зарегистрируйся
Функция обрабатывает раздел файловой системы блоками по 100 Мбайт, после чего вызывает функцию шифрования блока и выполняет смещение на такой же объем данных.

Для просмотра ссылки Войди или Зарегистрируйся

Функция encrypt_file_block обеспечивает шифрование части файла, обработка которого происходит блоками фиксированного размера (до 10 Мбайт). Сначала выделяется память временного буфера, который будет использоваться для чтения и обработки данных. Затем функция начинает цикл, в котором данные из файла читаются в буфер, шифруются с помощью алгоритма Sosemanuk, а затем записываются обратно в файл на то же место. При вызове encrypt_file_block считывается размер файла, вычисляется количество нужных проходов, а внутри цикла все стандартно. Понятно, что, убедившись в работоспособности своей программы, злоумышленники добавили скрипт для очистки следов.

info​

Sosemanuk — потоковый шифр, построенный на основе SNOW 2.0 и идей блок‑шифра Serpent. Он дает высокую пропускную способность при сравнительно небольшой нагрузке на CPU, что очень выгодно для обработки больших файлов.
На завершающем этапе происходит очистка ресурсов и запись первичного публичного ключа.

Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся

Функция write_public_key проверяет, передан ли корректный путь к файлу. Если путь не указан, выполнение программы завершается с ошибкой. Затем функция шифрует данные, основываясь на предоставленном списке разделов и ключе шифрования, и сохраняет зашифрованный результат в файл с временным расширением.

После этого формируется новое имя для файла путем добавления того же расширения к исходному пути. Длина нового имени проверяется, чтобы убедиться, что она не превышает допустимого предела. Если это условие соблюдается, временный файл переименовывается в итоговый. В случае успешного выполнения всех операций функция возвращает положительный результат. Если на каком‑либо этапе происходит ошибка, возвращается значение, указывающее на неудачу.

Таким образом, *.vmdk оказывается зашифрованным «на месте», при этом сама структура данных на низком уровне портится — виртуальные машины не смогут прочитать нужные блоки и запуститься.


Скрипт encrypt.sh​

Второй компонент — encrypt.sh — крайне важен, потому что этот скрипт выполняет массу подготовительных и завершающих шагов. Прежде всего он проверяет, не был ли уже запущен этот же скрипт раньше. Для этого используется проверка вида ps -c | grep <script_name> | grep -v $$, чтобы не конфликтовать с собственным PID.

Если скрипт уже загружен в память, то он завершает свою работу, если нет, производится установка системных параметров:

esxcli system settings advanced set -o /User/execInstalledOnly -i 0
Дальше — изменение лимитов (ulimit -p, -n), что снимает ограничения на число процессов и дескрипторов. Это нужно, чтобы параллельно запустить как можно больше процессов шифрования.

Далее идет поиск конфигурационных файлов ESXi, где содержатся ссылки на .vmdk и .vswp, и замена их ссылками на 1.vmdk, 1.vswp и так далее при помощи sed. Такое действие ломает конфигурацию, чтобы администратор не смог легко запустить виртуальные машины и «в лоб» восстановить их работоспособность. Также скрипт отыскивает и убивает процессы VMX. С точки зрения злоумышленника, это необходимо, чтобы освобожденные виртуальные диски гарантированно лежали на диске в консистентном виде, ведь если идет активная запись, шифрование может столкнуться с конфликтами. Вдобавок остановка виртуальной машины гарантирует, что жертве будет труднее быстро экспортировать виртуальные диски в intact-состоянии.

Для просмотра ссылки Войди или Зарегистрируйся
Когда подготовительная фаза завершается, bash-скрипт запускает собственно бинарь encrypt для всех найденных файлов:

find "/vmfs/volumes/" -type f -name *.vmdk, *.vmx, *.vmsn, *.vswp, *.vmem, *.vmss, *.nvram
Для каждого файла он вызывает nohup /tmp/encrypt "filename" >/dev/null 2>&1&, что означает: процесс запускается в фоне, перенаправив вывод, и позволяет скрипту двигаться дальше, не дожидаясь окончания процесса шифрования.

Параллельно может запуститься множество таких encrypt-процессов, которые максимально быстро зашифруют несколько гигабайтов данных. В процессе скрипт копирует motd в файл How To Restore Your Files.txt, который размещает рядом с каждым шифруемым файлом, — типичное поведение вымогателей, оставляющих инструкцию для жертвы. Также encrypt.sh может менять index.html, чтобы при обращении к интерфейсу ESXi жертве показывалось сообщение с требованием выкупа.

Последним шагом идет удаление логов (find / -name *.log -exec rm -rf {} ;), правка cron (удаление строк либо подмена crontabs/root), чтобы скрыть следы проникновения и исключить быстрый rollback конфигурации через встроенные механизмы.

Для просмотра ссылки Войди или Зарегистрируйся

Общий анализ атаки​

Чтобы провести более глубокий анализ, важно рассмотреть криптографические детали. Как уже упоминалось, криптографическая эллиптическая кривая Curve25519 обычно используется для вычисления общего секрета по схеме Диффи — Хеллмана, часто при умножении на приватный скаляр, предварительно «маскированный» (сброс младших битов, установка одного из старших). У троянов‑энкодеров этот метод нередко служит для формирования ephemerical-ключа, который потом может быть либо сохранен на стороне преступников, либо упакован в специальный файл. Если у злоумышленников есть «публичная часть», то они смогут расшифровать файлы при помощи хранящегося у них «приватного» компонента.

В комбинированных реализациях также присутствует SHA-256, который хеширует промежуточный ключ, а затем передает его в sosemanuk_schedule для генерации раундовых подключей. Авторы троянов очень любят Sosemanuk за высокую скорость, которая критически важна при шифровании больших файлов, таких как *.vmdk, достигающих десятков гигабайтов. Возникает вопрос: как минимизировать риск такой атаки?

Наиболее важными мерами можно считать следующие. Во‑первых, регулярно обновлять VMware Horizon и связанные с ней Java-компоненты, что позволяет закрыть уязвимость Log4Shell. Во‑вторых, категорически запретить использовать единый пароль локального администратора на многих серверах: если бы злоумышленник не смог применить NTLM-хеш локального админа, он не смог бы расширить свое присутствие в сети и дойти до ESXi. В‑третьих, нужно избегать сценариев, где Domain Admin обладает SSH-доступом к гипервизору.

Лучшей практикой остается сегментация управления: ESXi отделяется от доменных учетных записей, доступ к SSH разрешается только через уникальных локальных пользователей с ротацией паролей. Также требуется регулярно контролировать целостность crontab и выполнять ротацию backup-образа ESXi (auto-backup.sh в ESXi обычно сохраняет конфигурацию, но злоумышленник также может его повредить).

Анализируя поведение bash-скрипта, можно заметить, что он предусматривает и подмену index.html внутри /usr/lib/vmware. На практике это делается злоумышленниками, чтобы при заходе на веб‑интерфейс ESXi жертва видела не стандартные экраны, а сообщение наподобие «All your data is encrypted. Pay X BTC or lose everything». В таких сценариях троян действительно выводит из строя систему, ведь ESXi без конфигурации не может запускать виртуалки, а файлы *.vmdk становятся бесполезны. Некоторые версии скрипта также меняют /etc/motd и /etc/note на угрожающие послания. Чтобы удостовериться, что все задуманное выполнено, злоумышленники используют команду kill -9 для hostd и vmx, а потом подменяют hostd-probe.sh, rhttpproxy/endpoints.conf и прочие файлы. Это очень агрессивный подход, в результате которого наступает полный паралич инфраструктуры.

Еще один признак продуманности атаки — использование nohup и фоновых процессов. Шифрование больших файлов может занять время, поэтому вредонос запускает несколько процессов, каждый шифрует свою цель, параллельно выполняя операции ввода‑вывода. При наличии хорошей сети хранения данных (SAN) и высоких IOPS сам процесс может идти достаточно быстро. Администратор, заметивший аномальную нагрузку, может попытаться остановить скрипт, но будет уже поздно: процессы шифровальщика все еще запущены. Кроме того, bash-скрипт периодически ждет завершения encrypt, подсчитывая /bin/ps | /bin/grep encrypt | /bin/wc -l, чтобы потом выполнить завершающую очистку и восстановить некоторые файлы (например, hostd-probe.bak).

Авторы трояна также позаботились о том, чтобы удалить файлы журналов с расширением *.log, которые могли бы пролить свет на происходившие в системе события. На практике многие компании сводят логи ESXi в централизованные источники, но, если этого не делать, расследование может столкнуться с трудностями. При попытках инцидент‑респонса нередко выясняется, что логи на уровне /var/log/ просто пусты или уже вычищены. К тому же cron-таски, которые могли бы выполнять резервное копирование, уничтожаются. Злоумышленники после завершения операции восстанавливают /sbin/hostd-probe из .bak, чтобы вернуть ESXi в рабочее состояние, но с зашифрованными VMDK.

Таким образом, архитектура атаки со стороны выглядит следующим образом: в сеть компании проникает хакер через уязвимый Horizon (Log4Shell), получает права локального админа, затем с помощью pass-the-hash доходит до ESXi, загружает туда два файла (encrypt и encrypt.sh), выставляет им права chmod +x, выполняет скрипт, который отключает виртуалки, ломает конфиг, запускает массовое шифрование. Затем — чистит логи, подменяет веб‑интерфейс, вставляет сообщения для жертвы и уходит. Компания остается без виртуальных машин и без журналов, зато с инструкцией по оплате выкупа в каждой директории. Основываясь на известных образцах энкодеров, можно сделать вывод, что подобная схема уже неоднократно встречалась, а использование современных криптопримитивов Curve25519 + Sosemanuk надежно блокирует возможность дешифровки файлов без ключа. Администраторам и службам безопасности остается лишь надеяться на офлайн‑бэкапы, которые не были затронуты шифровальщиком.


Как предотвратить?​

С точки зрения предотвращения подобных атак важно не только «патчить Horizon» или «не использовать одинаковые пароли», но и грамотно проектировать всю инфраструктуру. Также стоит проводить антивирусный мониторинг, хотя и не всегда это помогает при запуске ELF-файлов в особой среде ESXi. Но по крайней мере анализ системных каталогов /tmp может выявить внезапно появившиеся там исполняемые файлы. При регулярном экспорте логов (syslog) на внешнее хранилище хотя бы удастся понять, когда была выполнена команда kill -9, когда появились те или иные строки в cron. Это существенно облегчает расследование инцидента.

Если же атака уже произошла, а виртуальные диски зашифрованы, то наилучшее решение — это откат из офлайн‑бэкапов. А при их отсутствии, скорее всего, придется вести переговоры со злоумышленниками. Однако, как показывает практика, такие переговоры не всегда завершаются расшифровкой файлов, ведь хакеры могут запросто исчезнуть, получив деньги. Важно отметить, что некоторые группировки раньше применяли RC4, AES, но теперь все чаще встречаются гибридные схемы (эллиптические кривые и быстрая потоковая криптография). Это говорит о «повзрослевшем» уровне ransomware-разработчиков, которые не хотят оставлять шансов на «самодельный» криптоанализ.

В заключение хочу подчеркнуть, что этот энкодер, сопровождающийся скриптом encrypt.sh, представляет собой изощренный инструмент: бинарь обеспечивает надежное и быстрое шифрование, а bash-скрипт управляет всем процессом от отключения виртуалок и ломки конфигов до уничтожения логов и подмены веб‑интерфейса. Многочисленные команды внутри скрипта показывают, что авторы прекрасно понимают среду ESXi, знают, какие процессы отвечают за работу VM, какие файлы критичны и в каком порядке их надо править.

Наиболее действенный набор защитных мер сводится к тому, чтобы ставить свежие патчи на VMware Horizon (закрывая Log4Shell), не допускать одинаковых NTLM-хешей локального администратора, жестко сегментировать ESXi, отключать неиспользуемые сервисы, регулярно выносить логи в централизованную SIEM или на Syslog-сервер, а также делать полные офлайн‑бэкапы, которые должны храниться вне досягаемости злоумышленников. При появлении в /tmp или в другом каталоге незнакомого ELF-файла и скрипта нужно провести срочную проверку, ведь в случае срабатывания encrypt.sh последствия могут быть катастрофическими.

Желательно на всякий случай следить за кронтасками, проверяя, не появились ли там посторонние строки. Важно включить многофакторную аутентификацию (MFA), особенно для систем, использующих Horizon, чтобы повысить уровень защиты от несанкционированного доступа. Также рекомендуется регулярно проверять настройки системы на соответствие Hardening Guide от VMware. Это позволит отслеживать и корректировать конфигурацию в соответствии с рекомендациями по безопасности.

Все компоненты ESXi должны быть подписаны цифровой подписью VMware, а изменение уровня приемлемости (Acceptance Level) для неподписанных модулей не рекомендуется и запрещено в сертифицированных средах, таких как PCI DSS. Если необходимо обеспечить максимальную безопасность, можно активировать Lockdown Mode и настроить пустое значение DCUI.Access. Это полностью отключает доступ через SSH, CLI и DCUI, в дополнение к стандартным Secure Boot и Host Profiles. Однако этот подход усложняет диагностику и восстановление системы в случае сбоев, поэтому он применяется только в средах с очень высокими требованиями по безопасности. Кроме того, доступ через SSH и CLI следует минимизировать, используя их только в случае крайней необходимости и отключая после завершения работы.

Остается лишь надеяться, что сегодняшний разбор этой вредоносной программы поможет администраторам и специалистам по информационной безопасности вовремя распознать угрозу, принять меры и организовать грамотную защиту своей виртуальной инфраструктуры.
 
Activity
So far there's no one here
Сверху Снизу