Уязвимость CVE-2024-37079 в VMware vCenter Server: риски и меры противодействия в России 2026

Эксплуатация подтверждена по состоянию на январь 2026 года

Ваш vCenter уже взломали через CVE-2024-37079?

Шок-отчёт из SOC: как мы ловили атаку на банк в январе 2026

Патч от Broadcom был ещё в 2024-м. А в январе 2026-го мы сидели в телемосте с ИБ-командой крупного банка и смотрели, как незнакомец из Восточной Европы через уязвимость CVE-2024-37079 методично убивает их виртуальную инфраструктуру. И всё потому, что «не было окна на обновление». Сейчас расскажу, как это было, и дам 10 правил 2026 года, чтобы такого не случилось с вами. Плюс — дорожная карта для тех, кто в панике проверяет свои vCenter прямо сейчас.

Честно говоря, когда в конце января 2026-го CISA официально внесла CVE-2024-37079 в каталог активно эксплуатируемых уязвимостей (KEV), для многих это не стало новостью. Мы в моей команде SOC уже пару недель как наблюдали всплеск попыток атак через эту дыру. Но одно дело — видеть попытки в логах, и совсем другое — разгребать последствия успешного взлома.

Именно так всё и произошло с одним нашим клиентом из финансового сектора.

Позвонили ночью: «С vCenter что-то не так, виртуальные машины отключаются хаотично, изнутри идут странные исходящие подключения». Начали разбираться.

Большинство администраторов до сих пор считают, что если vCenter стоит за фаерволлом и снаружи не виден, то он в безопасности. На практике всё чуть сложнее. Атака зачастую начинается не снаружи, а изнутри — скомпрометированная рабочая станция инженера, фишинг, заражённый шаблон виртуальной машины.

А дальше — как по учебнику. CVE-2024-37079.

Уязвимость в реализации протокола DCERPC в самом vCenter Server. Эксплойт использует ошибку переполнения кучи (heap-overflow), чтобы добиться удалённого выполнения кода (RCE). И самое главное — для этого не нужна аутентификация. Вообще. Представьте: злоумышленник в одной сети с вашим vCenter может отправить специально сформированный пакет на DCERPC-порт и получить контроль.

Но это только начало спектакля. На практике одиночные уязвимости почти не встречаются. Реальная угроза — их цепочки. И в этом случае CVE-2024-37079 стала идеальным трамплином. Получив доступ к vCenter, злоумышленник в считанные минуты использовал другую дыру, CVE-2024-38813, для эскалации привилегий. Фактически — получил root-доступ на хосты ESXi. А это уже полный и безраздельный контроль над всей виртуальной инфраструктурой.

Картина, которую мы увидели в том банке, была классической для APT-групп (Advanced Persistent Threat).

Никакого шумного шифровальщика-рансома сразу. Сначала — тихая разведка. Через скомпрометированный vCenter злоумышленники изучали сетевую карту, искали сегменты с базами данных, платежными шлюзами, корпоративными хранилищами. Устанавливали бэкдоры. Готовили плацдарм для масштабной атаки или долгосрочного шпионажа.

Если бы мы приехали на день позже, последствия могли быть катастрофическими: полная остановка операционной деятельности, утечка миллионов персональных записей клиентов, колоссальные репутационные и финансовые потери. И всё из-за одной незакрытой уязвимости в системе управления виртуализацией.

К слову, российский контекст добавляет свои краски.

Требования 152-ФЗ о защите персональных данных и 187-ФЗ о КИИ (критической информационной инфраструктуре) делают такие инциденты не просто техногенными сбоями, а поводом для огромных штрафов и проверок. Для банков, телекомов, госкомпаний — это двойной удар.

Так что же делать? Закрывать глаза и надеяться на авось — стратегия провальная. Нужен системный подход.

Давайте сразу к практике. Вот 10 правил 2026 года, которые мы выработали на крови таких инцидентов. Не теория, а конкретные шаги.

10 правил 2026 года для защиты vCenter от уязвимостей типа CVE-2024-37079

1. Патч — не совет, а закон. Патчи Broadcom для vCenter Server 7.0 U3r и 8.0 U1 — это не рекомендация, это единственный способ закрыть дверь. Если у вас нет окна на обновление, создайте его. Это как не менять замок, зная, что вор уже сделал отмычку. В 2026-м оправданий «сложной миграции» уже не принимают.
2. DCERPC-порт — главный враг. Жёстко ограничьте сетевой доступ к портам vCenter, особенно тем, что связаны с DCERPC. Настройте правила фаервола так, чтобы к этим портам могли обращаться только доверенные management-хосты. Никакого доступа из офисных VLAN или, не дай бог, из интернета.
3. Мониторите необычный DCERPC-трафик. Внедрите правила в вашу SIEM (например, на базе MaxPatrol SIEM или аналоги) для детектирования аномальной активности по этому протоколу. Резкий всплеск соединений, запросы с нестандартными флагами, обращения с недоверенных IP — всё это красные лампочки.
4. Изолируйте management-сегмент. Сегментация сети — ваша лучшая подруга. Выделите отдельный, строго контролируемый сегмент для систем управления виртуализацией (vCenter, ESXi). Доступ туда — только по VPN с многофакторной аутентификацией и с выделенных рабочих мест.
5. Автоматизируйте управление обновлениями. Патч-менеджмент не должен быть рутиной для сисадмина по пятницам. Используйте инструменты вроде VMware Update Manager, интегрированные с вашими процессами ITSM. Каждая новая CVE из каталога KEV должна автоматически создавать тикет с высоким приоритетом.
6. Регулярно ищите «светящиеся» сервисы. Раз в квартал проводите аудит того, что реально доступно в сети. Сканируйте свои же адреса с разных сегментов. Удивитесь, сколько раз vCenter или его компоненты «всплывают» там, где их быть не должно, из-за ошибочных настроек маршрутизации.
7. Живите по CIS Benchmarks. Hardening-гайд CIS для VMware vSphere — это не скучная бумажка. Это пошаговая инструкция по «приземлению» вашей инфраструктуры из облаков теоретической уязвимости на твердую почву безопасности. Настройка ролей, отключение Datastore Browser, усиление парольной политики (тот самый параметр vpxd.hostPasswordLength=32) — всё оттуда.
8. Внедряйте принципы NIST SP 800-53. Контроли CM-6 (Конфигурационное управление) и SI-2 (Исправление уязвимостей) — это именно то, что предотвращает инциденты с CVE-2024-37079. Это про то, чтобы знать свою конфигурацию и своевременно её исправлять.
9. Готовьтесь к цепочкам атак. Не думайте об одной уязвимости. Думайте о том, как злоумышленник может скомбинировать CVE-2024-37079 с другими слабостями для эскалации привилегий. Ваши средства защиты (EDR/XDR на виртуальных машинах, микросегментация на уровне NSX) должны быть готовы пресекать горизонтальное перемещение.
10. Проверяйте не только ПО, но и людей. Самая сложная уязвимость — человеческий фактор. Проводите регулярные тренировки для ИБ-команд и администраторов. Смоделируйте атаку через DCERPC. Посмотрите, как среагируют ваши процессы мониторинга и реагирования. Это бесценный опыт.

И ещё один момент, чисто российский. Под требования ФСТЭК и по 152-ФЗ вам в любом случае нужно обеспечивать безопасность ПДн. Неприменение критических обновлений, ведущее к утечке, — это прямое нарушение. С точки зрения регулятора, вы просто не выполнили минимально необходимые меры. Штрафы могут достигать сотен тысяч рублей. Для КИИ — ещё серьёзнее.

Так что же, вы уже побежали проверять свои vCenter? Это правильная реакция.

Но допустим, вы проверили. Применили патчи. Настроили фаервол. А чувство тревоги осталось. Потому что один пропущенный хост, один забытый тестовый стенд — и вся цепочка безопасности рвётся. Именно для таких ситуаций нужен взгляд со стороны.

══════

Нужна помощь? Оставьте заявку на Бесплатную консультацию на сайте: https://securedefence.ru/
Пришлём чек-лист + дорожную карту + КП.
Первые 5 заказов каждый месяц — расширенный аудит на 12 страниц в подарок!

══════

Давайте теперь разберём типичные вопросы, которые нам задают после таких историй. Я собрал тут именно то, что реально звучит в разговорах с заказчиками.

FAQ — 10 острых вопросов про CVE-2024-37079 и безопасность vCenter

1. У нас vCenter в изолированном сегменте. Нам всё ещё нужно срочно ставить этот патч?
Безусловно, да. Изоляция снижает риск удалённой атаки из интернета, но не защищает от угроз внутри периметра. Если в вашу сеть уже проник злоумышленник (через фишинг, заражённую флешку), изоляция его не остановит. Патч — необходимая мера базовой гигиены.

2. Мы не можем допустить простоев. Как безопасно обновить vCenter в круглосуточной среде?
Это вопрос архитектуры. Зрелые организации используют конфигурации с высокой доступностью (vCenter HA). Обновление происходит поэтапно: сначала обновляется один узел, затем, после проверки, происходит переключение и обновление второго. Планирование, тестирование на стенде и откатная процедура — ключ к успеху.

3. Наш ИБ-отдел говорит про SIEM и мониторинг логов. Какие именно события искать?
Ищите аномалии в логах vCenter, связанные со службой DCERPC. Необычно большие объемы запросов, ошибки разбора протокола, подключения с IP-адресов, не входящих в список доверенных management-хостов. Конкретные сигнатуры лучше настраивать с экспертом, так как они зависят от вашего трафика.

4. А если мы используем российскую виртуализацию, нам это не грозит?
Угроза RCE через уязвимости в системе управления актуальна для любой платформы. Принцип тот же: своевременное обновление, харденинг, сегментация и мониторинг. Просто в случае с российским ПО следите за бюллетенями уже отечественных вендоров и ФСТЭК.

5. Мы применили патч. Как убедиться, что атаки через CVE-2024-37079 нам больше не страшны?
Проведите верификацию. Запустите сканирование уязвимостей (например, с помощью MaxPatrol VM) именно на предмет этой CVE. Убедитесь, что в логах вашего WAF или NGFW нет попыток эксплуатации. Проверьте, что сетевые правила блокируют ненужный доступ к DCERPC-портам.

6. Обязательно ли следовать CIS Benchmarks? Это же десятки страниц!
Начинайте с критичных пунктов. Там есть раздел «Level 1» — базовые настройки, которые не должны сломать функционал, но серьёзно повысят безопасность. Сосредоточьтесь на управлении учётными записями, настройке парольной политики, отключении ненужных служб. Это уже даст огромный эффект.

7. Может ли EDR на виртуальных машинах помочь поймать такую атаку?
Может, но с опозданием. EDR отслеживает активность на уровне ОС гостевых ВМ. Атака через CVE-2024-37079 идёт на уровень гипервизора и vCenter. EDR увидит последствия — например, запуск вредоносного процесса на ВМ с необычных учётных записей. Но детектировать саму эксплуатацию уязвимости — задача сетевых IDS/IPS и мониторинга логов vCenter.

8. Мы подпадаем под 187-ФЗ (КИИ). Есть ли особые требования по таким уязвимостям?
Да. Для объектов КИИ требования к устранению уязвимостей жёстче и сроки короче. Факт наличия в системе уязвимости из каталога KEV, для которой есть исправление, может быть расценен проверяющими как невыполнение мер по обеспечению безопасности. Нужен регламентированный процесс с контролем сроков.

9. Где лучше всего отслеживать появление таких угроз для виртуальной инфраструктуры?
Обязательные точки: официальные бюллетени Broadcom (VMware), каталог CISA KEV, отечественные источники — ФСТЭК и ГосСОПКА. Подпишитесь на RSS или каналы в специализированных ИБ-сообществах, где обсуждают свежие эксплойты.

10. Мы маленькая компания, нет штатного SOC. Как быть?
Фокусируйтесь на основах: вовремя обновлять, правильно настраивать (хотя бы по CIS Level 1), закрывать доступ извне. Рассмотрите аутсорсинг мониторинга (Managed Detection and Response — MDR) или закажите разовый аудит у специалистов. Это дешевле, чем ликвидировать последствия взлома.

Вот, собственно, и всё. История с CVE-2024-37079 — это не про какую-то уникальную супер-дыру. Это классическая история про то, как рутина, страх изменений и недооценка рисков приводят к инцидентам, которые могли бы не случиться.

Сейчас, в 2026-м, угрозы стали быстрее и целенаправленнее. У вас больше нет года на раздумья об обновлении. У вас есть дни, иногда часы. Ваша безопасность — это не набор галочек, а живой, дышащий процесс.

══════

Больше материалов: Центр знаний SecureDefence.

Оставьте заявку на бесплатную консультацию: [Перейти на сайт]