Виртуальный шифр

Ком­про­мета­ция гипер­визора или свя­зан­ной с ним инфраструк­туры может пос­тавить под угро­зу целую эко­сис­тему сер­веров, баз дан­ных и биз­нес‑при­ложе­ний. Неуди­витель­но, что хакер­ские груп­пы все чаще фокуси­руют свои ата­ки на 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 и генера­ция клю­ча.

   

В коде мож­но най­ти вот такие кон­стан­ты:

Они исполь­зуют­ся для 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 счи­тыва­ется раз­мер фай­ла, вычис­ляет­ся количес­тво нуж­ных про­ходов, а внут­ри цик­ла все стан­дар­тно. Понят­но, что, убе­див­шись в работос­пособ­ности сво­ей прог­раммы, зло­умыш­ленни­ки добави­ли скрипт для очис­тки сле­дов.

На завер­шающем эта­пе про­исхо­дит очис­тка ресур­сов и запись пер­вично­го пуб­лично­го клю­ча.

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

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

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

Скрипт encrypt.sh

Вто­рой ком­понент — encrypt.sh — край­не важен, потому что этот скрипт выпол­няет мас­су под­готови­тель­ных и завер­шающих шагов. Преж­де все­го он про­веря­ет, не был ли уже запущен этот же скрипт рань­ше. Для это­го исполь­зует­ся про­вер­ка такого вида:

Она поз­воля­ет не кон­флик­товать с собс­твен­ным PID.

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

Даль­ше — изме­нение лимитов (ulimit -p, -n), что сни­мает огра­ниче­ния на чис­ло про­цес­сов и дес­крип­торов. Это нуж­но, что­бы парал­лель­но запус­тить как мож­но боль­ше про­цес­сов шиф­рования.

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

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

Для каж­дого фай­ла он вызыва­ет 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 сле­дует миними­зиро­вать, исполь­зуя их толь­ко в слу­чае край­ней необ­ходимос­ти и отклю­чая пос­ле завер­шения работы.

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