Перейти к содержанию

Атаки шифровальщиков на VMware ESXi | Блог Касперского


Рекомендуемые сообщения

Есть распространенное мнение, что виртуализация значительно снижает риски от киберугроз. Действительно, на виртуальной машине, как правило, не хранятся данные. И даже если ее пользователь случайно активирует трояна, то все вредоносные изменения автоматом исчезнут после перезапуска: гипервизор просто поднимет свежую машину из образа. Однако, как показывает практика, шифровальщики могут атаковать и виртуальную инфраструктуру. Конкретный пример — атака через уязвимые версии VMware ESXi, о которой не так давно писали в издании ZDNet.

Как минимум, операторы шифровальщика-вымогателя RansomExx точно используют уязвимости в VMware ESXi для атак на виртуальные жесткие диски. Кроме того, есть сведения, что тем же методом пользуется еще и группировка Darkside, да и создатели трояна BabukLocker намекают на то, что могут шифровать ESXi.

Что за уязвимости в ESXi?

Гипервизор VMware ESXi позволяет множеству виртуальных машин хранить информацию на одном сервере. Осуществляется это через протокол Open SLP (Service Layer Protocol), который, помимо всего прочего, позволяет обнаруживать сетевые устройства без предварительной конфигурации. Речь идет о двух уязвимостях этого протокола — CVE-2019-5544 и CVE-2020-3992, обе известны уже достаточно давно, и обе не в первый раз используются злоумышленниками. Первая позволяет провести атаку переполнения динамической памяти (heap overflow), а вторая относится к типу Use-After-Free, то есть связана с некорректным использованием той же самой динамической памяти в процессе работы.

Обе уязвимости достаточно давно закрыты (первая в 2019 году, вторая – в 2020-м), однако атаки через них успешно продолжаются и в 2021-м. А это значит, что, как обычно, обновили софт далеко не все.

Как злоумышленники эксплуатируют уязвимости в ESXi?

При помощи этих уязвимостей злоумышленники могут сформировать вредоносный SLP-запрос и скомпрометировать хранилище данных. Чтобы зашифровать информацию, им, разумеется, необходимо сначала проникнуть в сеть и закрепиться в ней. Но это не такая уж большая проблема — особенно в том случае, если виртуальные машины не имеют защитных решений. Чтобы закрепиться в системе, операторы RansomExx, например, используют уязвимость Zerologon, о которой мы уже писали ранее. То есть они сначала обманом убеждают человека выполнить вредоносный код на виртуальной машине, затем захватывают контроль над контроллером Active Directory, и уже только потом шифруют хранилище, оставляя на нем записку о выкупе.

Впрочем, Zerologon — не единственный вариант. Просто один из самых опасных, поскольку его эксплуатацию практически невозможно обнаружить без специальных сервисов.

Как защититься от атак на ESXi

  • Если в вашей компании используется гипервизор VMware ESXi, имеет смысл обновить его до последней версии.
  • Если по каким-то причинам этого нельзя сделать, то VMware предлагает использовать обходной путь. Правда, тут следует помнить, что его применение повлечет за собой ограничение функций протокола SLP.
  • Если вы все еще не закрыли уязвимость в Microsoft Netlogon — вот лишний повод сделать это поскорее.
  • Защищайте все машины в сети, в том числе и виртуальные.
  • Задумайтесь об использовании сервиса Managed Detection and Response, который позволит выявить даже сложную многоэтапную атаку, которую невозможно заметить с помощью обычных антивирусных решений.

View the full article

Ссылка на комментарий
Поделиться на другие сайты

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • KL FC Bot
      Автор KL FC Bot
      4 марта Broadcom выпустила экстренные обновления для устранения трех уязвимостей — CVE-2025-22224, CVE-2025-22225 и CVE-2025-22226, которые затрагивают несколько продуктов VMware, включая ESXi, Workstation и Fusion. В бюллетене упоминается, что по информации Broadcom как минимум CVE-2025-22224 эксплуатируется в реальных атаках. Уязвимости позволяют выполнить «побег» из виртуальной машины и выполнить код в гипервизоре ESX (hypervisor escape). По информации из GitHub VMware, Microsoft Threat Intelligence Center первым обнаружил эксплойт в реальной среде и уведомил Broadcom. Но кто и против кого использовал этот эксплойт, компании не разглашают.
      Уязвимости по данным Broadcom затрагивают VMware ESXi 7.0-8.0, Workstation 17.x, vSphere 6.5-8, Fusion 13.x, Cloud Foundation 4.5-5.x, Telco Cloud Platform 2.x-5.x, Telco Cloud Infrastructure 2.x-3.x, хотя некоторые эксперты считают, что список затронутых продуктов несколько шире. В частности, более старые версии, например 5.5, тоже должны быть подвержены уязвимости, но патчи для них выпущены не будут, эти версии не поддерживаются. По имеющимся оценкам на конец недели, уязвимостям подвержены более 41 тысячи серверов ESXi, расположенных во всех частях света — больше всего в Китае, Франции, США, Германии, Иране и Бразилии.
      Какие ошибки устранены VMware
      Наиболее серьезная уязвимость CVE-2025-22224 в VMware ESXi и Workstation получила рейтинг CVSS 9.3. Она связана с переполнением кучи (heap overflow) в VMCI и позволяет злоумышленнику с локальными административными привилегиями на виртуальной машине выполнить код от имени процесса VMX на хосте (то есть в гипервизоре).
      Уязвимость CVE-2025-22225 в VMware ESXi (CVSS 8.2) позволяет злоумышленнику записать произвольный код в область ядра (arbitrary kernel write), то есть тоже подразумевает побег из «песочницы». CVE-2025-22226 является утечкой информации в HGFS (CVSS 7.1) и позволяет злоумышленнику с административными привилегиями на виртуальной машине извлекать содержимое памяти процесса VMX. Этой уязвимости подвержены VMware ESXi, Workstation и Fusion.
       
      View the full article
    • Алексей_
      Автор Алексей_
      Добрый день, коллеги!
      Помогите разобраться почему не работает 
      на KSC 15.1.0 добавил "Kaspersky Security для виртуальных сред 6.2 Легкий агент" + необходимые плагины по инструкции
      хочу развернуть SVM, с помощью развертывания из оболочки - не работает. (ввожу логин root и пароль, единственный полный админ на VMware ESXi) - скрин1
      хотя в параметрах подключения к инфраструктуре пишет все ок - скрин2
      подключаюсь к хосту в той же подсети VMware ESXi 6.5 - скрин3
       


       

    • KL FC Bot
      Автор KL FC Bot
      В последние годы в блоге Kaspersky Daily мы стали уделять ransomware заметно меньше внимания, чем в былые времена. Но это вовсе не потому, что атаки вымогателей прекратились. Скорее наоборот — такие инциденты происходят настолько часто, что они уже давно стали привычным, практически фоновым явлением.
      Однако некоторые атаки вымогателей по-прежнему привлекают внимание своей экстраординарностью. В этом посте мы перечислим связанные с шифровальщиками-вымогателями инциденты 2024 года, которые выделялись на общем фоне своим масштабом, последствиями или необычными методами атакующих.
      Январь 2024: атака вымогателей на зоопарк Торонто
      Одним из первых значительных инцидентов 2024 года, связанных с ransomware, стала январская атака на крупнейший канадский зоопарк, расположенный в Торонто. Администрация зоопарка поспешила заверить общественность в том, что атака вымогателей не повлияла на работоспособность систем, связанных с уходом за животными. Более того, веб-сайт организации и сервис продажи билетов также не были затронуты, так что зоопарк продолжил принимать посетителей в обычном режиме.
      Официальный сайт зоопарка Торонто сообщает о кибератаке и уверяет, что с животными все в порядке. Источник
      Через некоторое время после атаки выяснилось, что атакующим удалось похитить значительное количество личной информации сотрудников зоопарка за период с 1989 года до наших дней. Таким образом, данный инцидент послужил очередным напоминанием о том, что даже очень далекие от критических секторов организации могут стать объектами атак вымогателей.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Атаки на open source чаще всего сводятся к публикации новых вредоносных пакетов в репозиториях. Атака, произошедшая 14 марта, из другой лиги — злоумышленники скомпрометировали популярный процесс (GitHub Action) tj-actions/changed-files, который применяется более чем в 23000 репозиториев.  Инцидент получил номер CVE-2025-30066, этой уязвимости подвержены все репозитории, в которых использовался заражённый процесс changed-files. Хотя администрация заблокировала changed-files, а затем откатила его к безопасной версии, все, кто пользовался им должны провести реагирование на инцидент, а сообщество разработчиков — извлечь из него более общие уроки.
      Что такое GitHub Actions
      Рабочие процессы (GitHub Actions) упрощают разработку ПО при помощи автоматизации типовых задач DevOps. Они могут стартовать при наступлении каких-то событий в GitHub, например коммитов. У GitHub есть условный «магазин приложений», в котором можно взять готовый процесс и применить его в своём репозитории, например популярны процессы для автоматической инсталляции вспомогательных инструментов. Чтобы интегрировать в свой сборочный конвейер CI/CD такой готовый процесс GitHub, достаточно всего одной строчки кода.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Чуть больше года назад в посте Google OAuth и фантомные аккаунты мы уже обсуждали, что использование опции «Вход с аккаунтом Google» в корпоративные сервисы дает возможность сотрудникам создавать фантомные Google-аккаунты, которые не контролируются администратором корпоративного Google Workspace и продолжают работать после оффбординга. Недавно выяснилось, что это не единственная проблема, связанная с OAuth. Из-за недостатков этого механизма аутентификации любой желающий может получить доступ к данным многих прекративших деятельность организаций, перерегистрировав на себя брошенные компаниями домены. Рассказываем подробнее об этой атаке.
      Как работает аутентификация при использовании «Вход с аккаунтом Google»
      Некоторые могут подумать, что, доверяя опции «Вход с аккаунтом Google», компания получает надежный механизм аутентификации, использующий продвинутые технологии Google и широкие возможности интернет-гиганта по мониторингу пользователей. Однако на деле это не так: при входе с Google OAuth применяется достаточно примитивная проверка. Сводится она, как правило, к тому, что у пользователя есть доступ к почтовому адресу, который привязан к Google Workspace организации.
      Причем, как мы уже говорили в предыдущем материале о Google OAuth, это вовсе не обязательно Gmail — ведь привязать Google-аккаунт можно совершенно к любой почте. Получается, что при использовании «Входа с аккаунтом Google» доступ к тому или иному корпоративному сервису защищен ровно настолько надежно, насколько защищен почтовый адрес, к которому привязан Google-аккаунт.
      Если говорить несколько более подробно, то при аутентификации пользователя в корпоративном сервисе Google OAuth отправляет этому сервису следующую информацию:
      В теории в ID-токене Google OAuth есть уникальный для каждого Google-аккаунта параметр sub, но на практике из-за проблем с его использованием сервисы проверяют лишь домен и адрес электронной почты. Источник
       
      View the full article
×
×
  • Создать...