# Сигурност на виртуализацията: нива на атака и въздействие на неправилната конфигурация

- URL: https://news.nodepoint.bg/article/5954
- Публикувано: 2026-11-08T17:48:32.000Z
- Категория: Наръчници и съвети
- Ниво на заплаха за България: висок
- Оригинален източник: Securelist — "Virtualization security: attack layers and misconfiguration impact" (https://securelist.com/virtualization-security-esxi-and-proxmox-ransomware-cases/121819/)
- Издател: NodePoint News (https://news.nodepoint.bg/about), НодПойнт ЕООД
- Бележка: преведено и обобщено с изкуствен интелект, без предварителна човешка редакция (https://news.nodepoint.bg/editorial-policy)

> Статията разглежда два реални инцидента с рансъмуер в среди на ESXi и Proxmox, причинени от неправилна конфигурация, прекомерни привилегии за мониторинг и лошо управление на администраторски идентификационни данни. Авторите подчертават, че инсталирането на корекции за сигурност трябва да върви ръка за ръка със сигурна конфигурация и строг контрол на достъпа.

#### Въведение

Инцидентите във виртуални среди могат да започнат със софтуерна уязвимост, човешка грешка, слабост в конфигурацията или няколко от тези фактори едновременно. Разследването рядко се ограничава само до работния процес (workload). Хипервайзорите, средите за изпълнение на контейнери, конзолите за управление, платформите за мониторинг, системите за идентичност, виртуалните мрежи, хранилищата за данни (datastores), резервните копия и акаунтите за автоматизация – всички те влияят върху това до какво може да достигне един атакуващ.

Екипът на Kaspersky GERT наскоро разследва още два случая на рансъмуер в среди с ESXi и Proxmox, при които слабият контрол на достъпа, недостатъчното мрежово разделение, откритите административни услуги и лошото управление на привилегировани идентификационни данни са допринесли за мащаба на въздействието. Система за мониторинг, която е имала достъп до слоя за виртуализация, също така е разкрила многократно използвани root идентификационни данни. След като атакуващият е поел контрол над този маршрут, обикновеният административен достъп е бил достатъчен, за да засегне няколко хоста. Не е било необходимо бягство от виртуална машина (VM escape).

Инцидентите показват защо инсталирането на корекции за сигурност и сигурната конфигурация трябва да се управляват заедно. Напълно обновен с корекции за сигурност хипервайзор все още може да бъде компрометиран чрез споделена парола, акаунт за мониторинг с прекомерни привилегии, отворен SSH път или администраторски интерфейс, достъпен от общата сървърна мрежа. Насоките на NIST поставят базовите линии за сигурна конфигурация, ограничения административен достъп, актуалните корекции за сигурност и мониторинга във всички слоеве в един и същ набор от добри практики за сигурност.

В тази статия ще опишем и двата инцидента с допълнителен фокус върху често срещаните опасни практики, които са били експлоатирани и са довели до компрометиране, както и тактиките за отстраняване на проблемите. Ще обсъдим и по-широкия обхват от заплахи, насочени към виртуални среди, за по-добро разбиране на възможните стратегии за защита.

#### Свързаната система, която защитниците трябва да опазят

Една бизнес виртуална среда не е просто Hyper-V, VMware или Docker, а по-скоро свързан стек. Конзолите за управление, инструментите за оркестрация, платформите за мониторинг и акаунтите за автоматизация стоят над хипервайзорите и контейнерните двигатели. Регистрите, хранилищата на образи, виртуалните суичове, хранилищата за данни и системите за резервни копия свързват слоевете. Приложенията и бизнес услугите работят най-отдолу, докато голяма част от административната мощ се намира близо до върха.

Важните граници се простират отвъд връзката между гост и хост. Те включват връзките от работния процес към равнината за управление, от системата за мониторинг към хипервайзора, от регистъра към внедряването, от работната станция на администратора към конзолата, от равнината за управление към хранилището и от един виртуален мрежов сегмент към друг. На атакуващия му е необходим само един използваем маршрут. Възможността за компрометиране може да се крие в едни откраднати или несигурно съхранени администраторски идентификационни данни, а не в сложен експлойт за бягство от виртуална машина. В случая, разследван от GERT, маршрутът на компрометиране е преминал през платформата за мониторинг и е включвал валидни идентификационни данни за платформата за виртуализация.

#### Случай №1: От мрежов мониторинг до криптиране на ESXi

Разследването започна с доказателства за активност на рансъмуера BlackNevas върху Windows система във виртуализиран сегмент на домейн контролер. Артефактите от UserAssist са записали изпълнение на инструмента за отдалечен мониторинг и управление (RMM) AnyDesk и бинарни файлове на GMER. Средата е използвала също така PRTG Network Monitor за наблюдение на своята виртуална инфраструктура.

![Артефакти от UserAssist](https://news.nodepoint.bg/media/articles/5954/img-1.webp)

Наличните доказателства показаха, че внедреният PRTG е имал широк достъп до ESXi хостовете и че една и съща root парола е била използвана многократно в няколко възела. След получаване на достъп до средата за мониторинг, атакуващият е използвал идентификационните данни за ESXi, за да се свърже през SSH към хостовете, които са споделяли същата парола. Този дизайн е обединил мониторинга, съхранението на идентификационни данни и директното администриране в един път за атака.

PRTG поддържа съхраняване на идентификационни данни за VMware на ниво устройство или наследена група. Тази функция е оперативно полезна, но един сървър за мониторинг се превръща в привилегирована инфраструктура, когато държи идентификационни данни, които могат да администрират наблюдаваните от него системи. Следователно въпросът за сигурността не е дали мониторингът се нуждае от достъп, а дали идентичността, привилегиите, методът на съхранение и разрешеният мрежов път са ограничени само до задачата за мониторинг.

Атакуващият е получил root достъп до ESXi средата и е използвал командата `esxcli`, за да заобиколи системното ограничение чрез деактивиране на политиката `execInstalledOnly`, с цел да изпълни криптиращия бинарен файл, както и да извърши анти-криминалистично изтриване на логове. Нека разгледаме отблизо хронологията на първоначалното компрометиране на хоста.

В същото време са последвали следните дейности на друг хост със същата парола за потребителя `root`:

#### Случай №2: Бележки с идентификационни данни засягат цялата Proxmox среда

GERT реагира на инцидент с рансъмуер от групата The Gentlemen, при който атакуващият е получил достъп до Proxmox, използвайки информация, събрана по време на периода на скрито присъствие (dwell time) между първоначалния достъп и видимото въздействие. На компрометирана работна станция на системен администратор атакуващият е открил административни идентификационни данни и детайли за достъп, съхранени в бележки в чист текст (plain text). Тези записи са предоставили информацията, необходима за влизане в Proxmox чрез root акаунта.

След това атакуващият е активирал VNC уеб сокета чрез компрометирания root акаунт, получавайки широк контрол над Proxmox средата. Този достъп впоследствие е бил използван за изтегляне и изпълнение на рансъмуер в рамките на клъстера, което е довело до криптиране на цялата виртуална среда. По-долу са показани записите от логовете, показващи как root акаунтът се използва за достъп до други хостове чрез VNC уеб сокет.

Този инцидент е ясен пример за рисковете от съхраняване на привилегировани идентификационни данни в незащитени бележки или други леснодостъпни файлове. След като работната станция на администратора е била компрометирана, запазените идентификационни данни са позволили на атакуващия да се придвижи от една крайна точка към слоя за управление на виртуализацията. Тъй като идентификационните данни са принадлежали на високопривилегирован root акаунт, една лоша практика за боравене с пароли значително е увеличила обхвата и въздействието на атаката. Вместо това привилегированите идентификационни данни трябва да се съхраняват в одобрен мениджър на пароли или система за управление на привилегирования достъп (PAM), да бъдат защитени с многофакторна автентикация и да се ротират незабавно, ако има съмнение, че работна станция на администратор е компрометирана.

#### Защо неправилната конфигурация доведе до широко въздействие

И двата случая показаха опасни практики на неправилна конфигурация, чието експлоатиране е довело до по-голямо въздействие върху хост системата. По-нататък ще разгледаме всяка неправилна конфигурация поотделно, за да видим как тя е позволила по-нататъшно компрометиране и какво трябва да се направи, за да се избегне.

#### Мониторингът е наследил прекомерни привилегии

В Случай 1 платформата за мониторинг можеше да прави нещо повече от това да събира данни за състоянието и производителността. Тя съхраняваше или можеше да използва идентификационни данни с достатъчно привилегии за директен достъп до ESXi. Поради това компрометирането на системата за мониторинг се превърна в компрометиране на равнината за управление. Идентичностите за мониторинг трябва да бъдат предназначени единствено за тази задача и да им се дават само разрешенията, изисквани от внедрените сензори.

#### Повторно използване на идентификационни данни

Повторното използване на пароли превърна една разкрита тайна в достъп до цялата сървърна ферма. Системното администриране трябва да използва поименни идентичности през централната равнина за управление. Всеки хост трябва да има уникални идентификационни данни и подходяща хигиена за съхранение на пароли. Силата на паролата сама по себе си не ограничава въздействието при кражба, но това къде могат да се използват идентификационните данни и къде се съхраняват те – го прави.

#### Директният root достъп заобиколи централния контрол

Директният SSH достъп позволи на атакуващия да се удостовери като root, да качи двоичен файл и да промени настройка за сигурност, без първо да преминава през контролите на ролите във vCenter. Broadcom, компанията майка на VMware, препоръчва управлението на vSphere да се извършва през vCenter, деактивиране на SSH по време на нормална работа и използване на Lockdown Mode, където е подходящо. Необходимите сервизни акаунти трябва да бъдат изрични изключения, а не членове на широка администраторска група.

#### Липса на разширени настройки за сигурност

Първоначалният опит за изпълнение беше блокиран от `execInstalledOnly`, но атакуващият разполагаше с достатъчно привилегии, за да деактивира тази политика. Broadcom документира опции за принудително прилагане, които комбинират `execInstalledOnly` с UEFI Secure Boot и защита на конфигурацията, подкрепена от TPM. Тези контроли трябва да бъдат активирани, тествани и наблюдавани за промени. Настройка, която може да бъде тихо деактивирана със същите идентификационни данни, използвани за ежедневно администриране, осигурява ограничена устойчивост след компрометиране на акаунт.

#### Небезопасно съхранение на идентификационни данни

Случай 2 демонстрира възможността за компрометиране, криеща се в излагането на риск на привилегировани идентификационни данни. Стратегията за смекчаване на риска включва не само защита на хранилището за административни идентификационни данни, но и общи практики за укрепване на сигурността при боравене с тайни, като управление на привилегиите и редовни одити на достъпа.

#### Как да затворите този път за атака

В този раздел споделяме съвети за отстраняване на проблеми относно това как да смекчите подобни атаки, както и да ги откриете и да предотвратите по-нататъшното им развитие. Препоръчваме следните действия:

- **Отделете мониторинга от администрирането.** Създайте отделна идентичност за мониторинг за всяка платформа и я ограничете до най-малкия набор от обекти и действия, които сензорите за мониторинг изискват. Не използвайте ESXi root или друг акаунт за спешни случаи за рутинно извличане на данни. Предотвратете стартирането на интерактивни администраторски сесии от сървърите за мониторинг, освен ако отделно одобрен работен процес по поддръжката не го изисква. Същият принцип важи и извън VMware.
- **Заменете съхранените root пароли.** Локализирайте всяко копие на идентификационни данни за хипервайзор, управление, съхранение и архивиране в инструменти за мониторинг, скриптове, планирани задачи, мениджъри на връзки и конфигурации на услуги. Заменете статичните пароли с извличане от трезор за пароли (vault), посреднически идентичности или ограничени API токени, където платформата ги поддържа. Записвайте всяко извличане и ротирайте тайната след спешна употреба или компрометиране.
- **Ограничете директния достъп до хоста.**Насочвайте нормалното администриране на ESXi през vCenter и активирайте подходящ режим Lockdown Mode след тестване на зависимостите за мониторинг, архивиране и възстановяване. Дръжте ESXi Shell и SSH спрени по подразбиране. Когато работата по поддръжката изисква SSH, активирайте го за определен период, ограничете източника и настройте известия при активиране на услугата, влизане като root и промени в списъка с изключения на потребителите, на които е разрешено да се свързват чрез SSH.
- **Използвайте специализирано решение за сигурност.**В нашето портфолио Kaspersky Cloud Workload Security (KCWS) е перфектно пригодено за справяне с рисковете във виртуалната среда, предлагайки мощна комбинация от два продукта: Kaspersky Hybrid Cloud Security (KHCS) и Kaspersky Container Security (KCS). Kaspersky Hybrid Cloud Security е специално създадено за защита на виртуализирани инфраструктури, частни центрове за данни и хибридни облаци. Патентованата архитектура Light Agent минимизира въздействието върху ресурсите без компромис с производителността, докато цялостната визуализация на инфраструктурата чрез единна конзола дава на администраторите пълна видимост и контрол върху цялата хибридна мрежа. Kaspersky Container Security покрива всеки етап от жизнения цикъл на контейнеризираното приложение – от разработката до експлоатацията. Наред с другите възможности, решението позволява откриване на неправилни конфигурации с помощта на специализиран скенер за образи, файлови системи и хранилища, които съдържат IaC файлове (като Terraform, CloudFormation, Azure ARM шаблони, Helm чартове и Dockerfiles).
- **Третирайте промените в конфигурацията като събития, свързани със сигурността.**Генерирайте известия, когато `execInstalledOnly`, принудителното прилагане на Secure Boot, Lockdown Mode, SSH, локалните акаунти, потребителите в списъка с изключения, правилата на защитната стена или настройките за отдалечено записване на логове се променят. Установете базово очаквано състояние и тествайте дали екипът по сигурността може да засече неоторизирана промяна. Веднъж зададена сигурна конфигурация не означава, че контролът остава активен на хоста.
- **Изолирайте мрежата за управление.**Поставете хипервайзора, мониторинга, архивирането, съхранението и администрирането на клъстери в ограничени мрежи за управление. Разрешете само точните услуги за източник и дестинация, които се изискват. Административните работни станции трябва да влизат през укрепени междинни хостове (jump hosts) с поименни идентичности и многофакторно удостоверяване.
- **Защитете логовете, архивите и възстановяването.**Препращайте логовете от ESXi, vCenter, мониторинга на Proxmox, идентичностите и мрежата към защитено хранилище, което компрометиран администратор не може да изтрие. Платформите за архивиране трябва да използват отделни идентичности, ограничени пътища за управление и копия за възстановяване извън обикновения административен обсег.

#### Проверки на конфигурацията за наблюдавана виртуализация

По-долу са посочени препоръчителни проверки, които да изпълните при активиране на мониторинг на виртуализацията. Най-безопасното състояние зависи от платформата и метода на мониторинг, но всеки контрол трябва да бъде тестван.

| Област на контрол | По-безопасно състояние | Проверка |
| --- | --- | --- |
| Идентичност за мониторинг | Специализиран сервизен акаунт или токен само с необходимите права за четене и запитване (polling) | Прегледайте назначените роли и тествайте всеки сензор без достъп на ниво root или глобален администратор |
| Съхранение на идентификационни данни | Без възстановима root парола за хоста на сървър за мониторинг или сървър с общо предназначение | Прегледайте конфигурациите на инструментите, скриптовете, планираните задачи и хранилищата за връзки за вградени идентификационни данни, токени за достъп или други тайни |
| Мрежов път | Мониторингът достига само до необходимите услуги за запитване, докато администрирането използва междинен хост (jump host) | Тествайте портовете за управление от сървъра за мониторинг, потребителските сегменти и ненадеждните мрежови сегменти |
| Директен достъп до хоста | Режим на заключване (Lockdown Mode), където е подходящо, със спрени по подразбиране SSH и ESXi Shell | Опитайте директен достъп до хоста чрез клиентски API и SSH, използвайки рутинен акаунт |
| Цялост на конфигурацията | Прилагането на Secure Boot и execInstalledOnly е активирано, където се поддържа и е тествано | Променете тестова настройка чрез одобрения процес и потвърдете, че се генерира предупреждение |
| Доказателства | Журналите на хоста, управлението, идентичността, мониторинга, защитната стена и PAM се съхраняват отдалечено | Генерирайте успешни и неуспешни влизания и проверете източника, акаунта, хоста, времето и действието |

#### По-широката повърхност на атака

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

#### Бягство от виртуална машина и контейнер (VM and container escapes)

При бягство от виртуална машина (VM escape) кодът вътре в гост системата преминава отвъд границата на виртуалната машина и засяга хоста или друга гост система. Слабостта може да бъде във виртуално устройство, функция за интеграция, интерфейс за хиперповиквания (hypercall) или друг компонент, който превежда заявките на госта за хоста. Ако бягството успее, контролът над една виртуална машина може да доведе до контрол над физическия сървър и всяко работно натоварване върху него. VMware CVE-2025-22224 показа този риск: атакуващ с администраторски права вътре във виртуална машина можеше да изпълни код като процеса VMX на хоста, а Broadcom съобщи за експлоатация в реални условия.

Бягството от контейнер може да постигне подобен резултат, но началната точка е различна. Контейнерите в Linux споделят ядрото на хоста, така че техният модел на изолация се различава от този на виртуалната машина. Именните пространства (namespaces) ограничават това, което процесите могат да виждат, контролните групи (cgroups) управляват използването на ресурси, а привилегиите (capabilities) разделят root правата на по-малки части. Грешка в ядрото или в средата за изпълнение (runtime) може да наруши тази изолация. Copy Fail (CVE-2026-31431) е добър пример за пропуск в ядрото. Код, който вече се изпълнява в контейнер, можеше да използва криптографски сокет AF_ALG в Linux, за да променя страници в споделения кеш за страници на ядрото на Linux. Тъй като хостът и другите контейнери могат да четат същите кеширани страници, ефектът не трябваше непременно да остане в рамките на един контейнер. Решението е обновяване на ядрото; Docker Engine 29.4.3 също затегна своите профили за сигурност по подразбиране, за да намали излагането на риск при хостове, на които все още не са инсталирани корекции за сигурност.

Небезопасните настройки също могат да нарушат границата. Привилегированият режим, прекомерните привилегии (capabilities), монтираните директории от хоста с права за запис или достъпът до сокета на Docker могат да премахнат изолацията без никакъв софтуерен експлойт. Например runc CVE-2024-21626 включваше изтекли файлови дескриптори, които можеха да изложат файловата система на хоста пред злонамерен образ или процес в контейнер.

Тази разлика променя разследването. Виртуалната машина често може да се третира като отделен компютър със собствено ядро, памет и диск. Контейнерът е група от процеси на хоста, поставени в именни пространства. Ако разследващите съберат само файловата система на контейнера, те могат да оставят на хоста най-полезните доказателства за процесите, сокетите и контролната равнина.

#### Образи и шаблони

Компрометиран еталонен образ на виртуална машина (golden VM image) или базов образ на контейнер може да се разпространи чрез нормалната автоматизация. Често срещаните слабости включват неофициални публични образи, променливи етикети (mutable tags), токени за изграждане с прекомерни права, възстановими тайни в по-стари слоеве и остарели шаблони, които възстановяват уязвим софтуер или забравени акаунти. Сканирането може да помогне, но то не установява кой е изградил артефакта или дали точно този образ, който е бил тестван и одобрен, е бил онзи, който в крайна сметка е внедрен в продукционна среда. Използвайте контролирани среди за изграждане (builders), записи за произход (provenance records), проверки на подписи и планирани повторни изграждания от доверени източници.

#### Инструменти за управление и API

Открадната идентичност във vCenter, изложен на показ API на Docker, роля в Portainer с прекомерни правомощия или компрометирана конзола за резервни копия могат да дадат на атакуващия по-лесен маршрут от експлойт за бягство. Бюлетинът за сигурност на Portainer GHSA-7fw3-x4r2-g7wc показа как прокси сървър валидира едно представяне на монтиране чрез свързване (bind-mount), но пропуска еквивалентна API форма, позволявайки на удостоверен потребител без администраторски права, но с привилегии за създаване на контейнери, да достигне пътища на хоста. Средата за изпълнение е извършила валидна заявка, след като упълномощаването вече се е провалило в слоя за управление.

Административните операции за копиране на файлове също заслужават внимание. Docker отстрани уязвимости при обработката на архиви и монтирания в CVE-2026-41567, CVE-2026-41568 и CVE-2026-42306. Тези случаи изискваха специфични условия и активност от страна на оператор или API. Те са напомняне да се инсталират корекции за сигурност за демона и да се записва кой е инициирал операциите за копиране, кой контейнер е бил замесен, кои са били изходните и целевите пътища и какъв е бил резултатът.

#### Виртуални мрежи, хранилища за данни и резервни копия

Трафикът в посока изток-запад между виртуалните работни натоварвания може да остане вътре в един хост и да заобиколи физическия сензор. Трафикът за управление, миграция, съхранение и работни натоварвания трябва да използва отделни зони с филтриране между тях. Файловете на моментните снимки (snapshots) и паметта могат да съдържат идентификационни данни, докато слабите права за достъп до хранилището за данни (datastore) могат да изложат на риск цели виртуални дискове. Системите за резервни копия се нуждаят от широк достъп за възстановяване на услугите, което ги прави ценни и за атакуващ, който иска да изтрие точките за възстановяване или да достигне до няколко хоста.

#### Примери за повърхност на атака по слоеве

В обобщение, описаните вектори на атака могат да бъдат смекчени по следния начин:

| Повърхност на атака | Първоначален достъп | Възможно въздействие | Основен контрол |
| --- | --- | --- | --- |
| Идентификационни данни и конфигурация | Парола, възстановена от система за наблюдение или от акаунт с прекомерни привилегии | Пряк контрол над няколко възела на хипервайзора | Уникални идентификационни данни в защитено хранилище, сегментиран достъп и наблюдение на конфигурацията |
| Бягство от виртуална машина (VM escape) | Административен достъп или привилегии за изпълнение на код в гост-система плюс уязвимост в хипервайзора | Компрометиране на процес на хоста или на съседно работно натоварване | Инсталиране на корекции за сигурност за хипервайзора и ограничаване на рисковите виртуални устройства и привилегиите на гост-системата |
| Злонамерен контейнер, засягащ ядрото или средата за изпълнение | Код в контейнер или злонамерен образ | Въздействие върху файловата система на хоста, ядрото или споделения кеш | Инсталиране на корекции за сигурност за ядрото и средата за изпълнение и премахване на привилегированите настройки |
| Образи и шаблони | Компрометиран регистър с входни данни за компилиране или базов образ (golden image) | Многократно разгръщане на компрометирания ресурс | Непроменими хеш стойности (digests), контролирани компилации, проследимост на произхода и верификация |
| API за управление | Открадната идентичност, разкриваща крайна точка, или пропуск в оторизацията | Административни действия върху цялата инфраструктура | Многофакторна автентикация (MFA), принцип на най-малките привилегии, мрежови ограничения и пълна валидация на API |
| Мрежи, съхранение и резервни копия | Плоска мрежа или широко достъпно хранилище за данни и достъп чрез резервни копия | Странично движение, кражба на данни, криптиране и загуба на възможност за възстановяване | Сегментиране, принцип на най-малките привилегии, защитени резервни копия и наблюдение на трафика |

#### Заключение

Случаите на GERT, които представихме в тази статия, не изискваха от атакуващия да пробие границата на виртуалната машина. Пътят на атаката беше създаден от връзка за наблюдение с прекомерни привилегии, несигурен подход за съхранение на пароли, възстановими и повторно използвани root идентификационни данни, широка достъпност на мрежата за управление и директно администриране чрез SSH. Всеки елемент беше легитимен сам по себе си, но заедно те позволиха на един пробив да достигне до хостовете за виртуализация и техните работни натоварвания.

Ето защо неправилната конфигурация трябва да получава същото оперативно внимание като управлението на уязвимостите. Екипите трябва да знаят къде съществуват привилегировани идентификационни данни, кои системи могат да ги използват, кои мрежови пътища ги правят ефективни и кои журнали ще покажат тяхното използване. Уязвимостите за бягство от виртуална машина, небезопасните образи, слабостите в API, излагането на риск на виртуалната мрежа и атаките срещу системите за съхранение или резервните копия остават сериозни заплахи, но затварянето на известния административен маршрут трябва да бъде на първо място.

## Анализ на риска за България

Платформите за виртуализация VMware ESXi и Proxmox, както и решението за мониторинг PRTG, се използват широко от български компании, хостинг доставчици и държавни институции. Описаните неправилни конфигурации и практики за повторно използване на пароли представляват сериозен и реален риск за местната ИТ инфраструктура, тъй като позволяват на атакуващите да криптират цели виртуални среди без нужда от сложни експлойти.

Ключови думи: виртуализация, ESXi, Proxmox, рансъмуер, PRTG, неправилна конфигурация