Windows Netlogon RCE уже эксплуатируют: контроллеры домена нужно патчить в первую очередь

Критическая уязвимость CVE-2026-41089 в Windows Netlogon уже используется в атаках. Проблема затрагивает Windows Server, когда он работает как контроллер домена. Оценка — 9.8 из 10 по CVSS.

Microsoft закрыла уязвимость в майском Patch Tuesday 12 мая 2026 года. Через две с половиной недели Центр кибербезопасности Бельгии обновил предупреждение и сообщил, что CVE-2026-41089 эксплуатируется в реальных атаках.

Главная неприятность — точка входа. Netlogon находится в самом центре доменной инфраструктуры Windows. Через него доменные машины и контроллеры устанавливают доверенную связь, проверяют учетные данные и обслуживают критичные сценарии Active Directory. Если атакующий получает выполнение кода на контроллере домена, дальше речь уже идет о риске для всей доменной среды.

CVE-2026-41089 — stack-based buffer overflow в Windows Netlogon. Проще говоря, служба неправильно обрабатывает сетевой запрос, данные выходят за границы выделенного буфера, память повреждается, а при успешной эксплуатации атакующий может добиться выполнения кода.

NVD и Microsoft описывают сценарий как удаленную эксплуатацию по сети без предварительной аутентификации и без участия пользователя. Поэтому в заголовках ее называют 0-click RCE: жертве не нужно открывать файл, переходить по ссылке или подтверждать действие.

Уязвимость относится к категории CWE-121 — переполнение буфера в стеке. Это старый и хорошо понятный класс ошибок, но в контексте контроллера домена он становится особенно опасным. У доменного контроллера много доверия внутри сети, а LSASS и Netlogon находятся рядом с самыми чувствительными механизмами Windows-домена.

По данным NVD, уязвимы серверные версии Windows, включая:

• Windows Server 2012;

• Windows Server 2012 R2;

• Windows Server 2016;

• Windows Server 2019;

• Windows Server 2022;

• Windows Server 2022 23H2;

• Windows Server 2025.

Риск появляется там, где сервер выполняет роль контроллера домена. Обычная рабочая станция Windows 11 здесь не является главным объектом атаки. Основная цель — Domain Controller, потому что именно на нем работает Netlogon в критичном для домена режиме.

Старые версии Windows Server без актуальных обновлений остаются особенно проблемными. Microsoft выпустила официальный патч для поддерживаемых систем, а 0patch отдельно подготовил микропатчи для ряда устаревших Windows Server, которые уже не получают обычные security updates.

Netlogon уже был в центре крупного инцидента в 2020 году. Тогда CVE-2020-1472, более известная как ZeroLogon, позволяла атакующему получить контроль над доменом через ошибку в криптографической логике Netlogon Remote Protocol.

CVE-2026-41089 — другая проблема. Здесь речь не о той же криптографической ошибке, а о переполнении буфера. Но сравнение с ZeroLogon возникает из-за общей зоны поражения: Netlogon, контроллеры домена, Active Directory и возможность быстрого перехода от одной уязвимости к доменному кризису.

0patch после анализа патча Microsoft описал проблему как pre-authentication remotely exploitable vulnerability в Netlogon на Windows Server, работающем как доменный контроллер (Domain Controller).

В их разборе фигурирует CLDAP DC-locator на UDP/389. Один специально сформированный пакет может вызвать переполнение буфера внутри LSASS, повредить память и привести к падению процесса. После падения LSASS сервер обычно уходит в перезагрузку примерно через минуту.

Это не значит, что атака ограничивается отказом в обслуживании. Microsoft классифицирует CVE-2026-41089 как Remote Code Execution. Повреждение памяти в таком процессе — это путь к выполнению кода, даже если первые публично воспроизводимые сценарии надёжнее демонстрируют crash.

Важно, что поверхность атаки находится в доменной инфраструктуре, а эксплуатация не требует учетной записи. Даже нестабильная эксплуатация опасна: падение LSASS на контроллере домена уже может нарушить аутентификацию, групповые политики, Kerberos/NTLM-сценарии и работу связанных сервисов.

Контроллер домена хранит и обслуживает критичные данные Active Directory. Через него проходят входы пользователей, доверия между системами, политики, группы, служебные учётные записи и доступ к ресурсам.

Компрометация DC часто означает возможность:

• получить доменные хэши и секреты;

• создать или изменить привилегированные учётные записи;

• двигаться по сети от имени легитимных пользователей;

• менять групповые политики;

• атаковать резервные копии и системы управления;

• закрепиться в домене надолго.

Главное действие — установить майские обновления Microsoft на все контроллеры домена Windows Server. Патч должен закрыть CVE-2026-41089 на поддерживаемых версиях.

Следующий шаг — проверить, какие DC доступны из пользовательских VLAN, VPN-сегментов, гостевых сетей, филиалов, DMZ и облачных связок. Контроллеры домена не должны быть широко доступны со всех внутренних сетей без необходимости. Если сетевую доступность нельзя быстро перестроить, хотя бы временно ограничьте ненужный входящий трафик к DC на уровне firewall и ACL.

Также стоит разобрать устаревшие серверы. Windows Server 2012 и 2012 R2 встречаются в инфраструктурах до сих пор. Если они не получают официальные security updates, организация должна либо иметь ESU/другой легальный канал обновлений, либо использовать компенсирующие меры, либо срочно выводить такие DC из эксплуатации.

И проверьте перезагрузки и падения LSASS. Если после 29 мая у контроллеров домена были неожиданные рестарты, ошибки LSASS, сбои Netlogon или краткие провалы аутентификации, это не стоит списывать на «обычный Windows». Нужно провести разбор.

Лучше строить проверку вокруг поведения.

Стоит посмотреть:

• неожиданные перезапуски контроллеров домена;

• падения LSASS;

• события Windows Error Reporting, связанные с lsass.exe;

• ошибки Netlogon в системных журналах;

• аномальные входящие обращения к DC по сетям, откуда их быть не должно;

• рост UDP-трафика к контроллерам домена;

• сбои аутентификации пользователей и сервисов в короткие интервалы;

• изменения в привилегированных группах после возможного инцидента;

• создание новых администраторских учётных записей;

• подозрительные изменения Group Policy.

Отдельно стоит проверить журналы EDR и сетевых сенсоров. Если продукт уже получил сигнатуры под CVE-2026-41089, нужно посмотреть не только блокировки, но и попытки эксплуатации до включения защиты.