CVE-2026-41089: переполнение буфера в Netlogon — один UDP-пакет роняет весь домен

Представьте: воскресенье, три часа ночи. На контроллере домена падает LSASS. Весь AD — аутентификация, Kerberos, NTLM, групповые политики — встаёт намертво. Никто не может войти ни на один сервер в домене. Через минуту контроллер перезагружается сам. Пока разбираетесь что случилось — падает второй. Это не сбой оборудования. Это CVE-2026-41089.

CVE-2026-41089 — stack-based buffer overflow в службе Windows Netlogon. CVSS 9.8 (Critical), CWE-121. Уязвимость позволяет неаутентифицированному атакующему отправить один UDP-пакет на порт 389 контроллера домена и уронить LSASS, что немедленно кладёт весь домен до перезагрузки. Microsoft опубликовала уязвимость 12 мая 2026 года и закрыла её в майском Patch Tuesday (KB5089549). Центр кибербезопасности Бельгии (CCB) 29 мая 2026 года подтвердил активную эксплуатацию в реальных атаках.

Формально Microsoft в CVSS назвала это RCE с оценкой влияния C:H/I:H/A:H. Технический анализ от Aretiq AI, опубликованный 13 мая 2026 года, даёт более точную картину: из-за особенностей механизма переполнения до arbitrary code execution в большинстве конфигураций дело не доходит — но LSASS гарантированно падает от одного пакета, что для контроллера домена равносильно катастрофе. Разница между DoS и RCE здесь не так важна, когда один пакет кладёт аутентификацию всего предприятия.

ЧТО ТАКОЕ NETLOGON

Если у вас когда-либо падал контроллер домена в рабочее время — вы знаете этот звук. Звонки в техподдержку, «не могу войти», «у меня не открывается», «почтовый сервер недоступен». Всё это потому, что Netlogon — не просто одна из сотен Windows-служб. Это механизм, на котором держится аутентификация всего домена: он устанавливает защищённый канал между рабочими машинами и контроллерами, синхронизирует пароли машинных аккаунтов, поддерживает доверительные отношения между доменами. Когда он падает — домен не деградирует плавно, он встаёт.

Уязвимая часть — DC Locator. Когда клиент включается в сети и ему нужно найти ближайший контроллер домена, он отправляет CLDAP-запрос (Connectionless LDAP, UDP порт 389). В этом запросе — имя домена, имя пользователя и флаг версии протокола (NtVer). DC отвечает пакетом со своими координатами: имя сервера, имена домена и леса в DNS-формате, GUID. Ключевой момент: этот обмен происходит до любой аутентификации. Клиент ещё не вошёл в домен — он только ищет, куда войти. Требовать учётные данные здесь бессмысленно. И именно поэтому этот код обрабатывает запросы от кого угодно, с любым содержимым, без проверки.

КАК РАБОТАЕТ УЯЗВИМОСТЬ

Когда контроллер домена получает CLDAP DC locator ping, функция BuildSamLogonResponse в netlogon.dll собирает ответный пакет. Она последовательно записывает в стековый буфер фиксированного размера (528 байт) несколько полей: имя сервера, имя пользователя из запроса, имя домена, два GUID, и затем DNS-имена леса, домена и хоста в сжатом формате.

Для записи строк используется вспомогательная функция NetpLogonPutUnicodeString. Три аргумента: указатель на строку-источник, максимальное количество символов для копирования, и указатель на текущую позицию в выходном буфере. Если вы уже почувствовали что-то неладное — правильно. Четвёртого аргумента нет. Размер выходного буфера никуда не передаётся. Функция копирует символы в цикле, считает до лимита — и никогда не проверяет, не вышла ли она за край выделенной памяти.

В BuildSamLogonResponse эта функция вызывается три раза с жёстко прошитыми лимитами: 36 символов для имени сервера, 130 символов для имени пользователя (это поле берётся прямо из CLDAP-запроса атакующего), 32 символа для имени домена. После этих строк — GUID (32 байта) и DNS-имена через NlpUtf8ToCutf8. Длина DNS-имён определяется конфигурацией самого сервера.

Вот где становится интересно. Атакующий контролирует поле User — до 130 wide-символов, то есть до 260 байт. Это самый большой одиночный компонент пакета. Он заполняет середину буфера и физически сдвигает DNS-имена сервера к его концу. Байты, которые в итоге вылезают за край 528-байтового буфера — это DNS-имена самого DC, не данные атакующего. Атакующий управляет тем, насколько далеко всё это сдвинется, но не тем, что именно перезапишет память за буфером. Именно поэтому уязвимость зависит от длины DNS-домена: при коротком домене вроде example.com суммарный объём данных не превышает 528 байт и переполнения нет. При длинном — dept.division.engineering.enterprise.corporation.local в сочетании с 63-символьным hostname (максимум по стандарту DNS) — данные не помещаются, и всё ломается.

КАК ЭКСПЛУАТИРУЕТСЯ

Атакующему нужно одно: сформировать CLDAP SearchRequest и отправить его на UDP порт 389 контроллера домена. В фильтре запроса — DnsDomain с именем домена, User с полезной нагрузкой из 130 символов и NtVer со значением 0x00000002. Последнее критично: биты 2-3 должны быть сброшены, чтобы Netlogon использовал путь через BuildSamLogonResponse, а не через BuildSamLogonResponseEx. Легитимные клиенты почти всегда используют NtVer=6, что само по себе является индикатором атаки при детектировании.

Весь путь от входящего CLDAP-пакета до уязвимого BuildSamLogonResponse проходится до любой проверки учётных данных — аутентификация здесь не нужна в принципе, потому что DC locator по определению работает до входа в домен.

Когда переполнение происходит, перезаписывается GS stack cookie, установленный компилятором в BuildSamLogonResponse. При обнаружении повреждённого cookie Windows вызывает __fastfail(FAST_FAIL_STACK_COOKIE_CHECK_FAILURE), что завершает LSASS с кодом 0xc0000409 (STATUS_STACK_BUFFER_OVERRUN). LSASS не восстанавливается — система уходит в перезагрузку.

ЧТО ПРОИСХОДИТ ДАЛЬШЕ — ЗАВИСИТ ОТ КОНФИГУРАЦИИ

Сразу после отправки пакета атакующий видит таймаут вместо ответа от DC. На целевом контроллере LSASS падает с исключением 0xc0000409. Поскольку LSASS является хостом для Kerberos, NTLM, Netlogon secure channel и механизмов групповой политики — его падение означает, что весь домен перестаёт аутентифицировать пользователей. Новые входы в систему невозможны, сессии рвутся, сервисы, требующие Kerberos-билетов, теряют доступ.

Если в домене несколько контроллеров, клиенты переключатся на другой DC — но только до тех пор, пока атакующий не отправит такой же пакет на следующий. Единственный контроллер — это полная остановка домена до перезагрузки. При нескольких DC непрерывный поток пакетов по очереди роняет каждый из них — это продуманный сценарий sustained denial of service против Active Directory.

Достичь arbitrary code execution через это переполнение крайне сложно: содержимое переполняющих байт — DNS-данные сервера, не данные атакующего. уже при 2 байтах переполнения GS cookie повреждён, но return address функции NlGetLocalPingResponse лежит в 72 байтах от конца буфера. Максимально измеренное переполнение при 63-символьном DNS hostname — около 51 байта. Для контроля return address не хватает 21 байта даже в наиболее уязвимой конфигурации.

РЕАЛЬНАЯ ЦЕПОЧКА АТАКИ

Типичный сценарий в корпоративной сети: атакующий получает доступ в сегмент сети, из которого достижим UDP порт 389 контроллеров домена. Это могут быть скомпрометированная рабочая станция, гостевой VLAN с недостаточной сегментацией или VPN-туннель. Дальше — просто отправка одного CLDAP-пакета с 130-символьным полем User.

Через несколько секунд DC уходит в перезагрузку. Мониторинг фиксирует неожиданный перезапуск — но пока дежурный администратор открывает ноутбук, атакующий уже переключился на второй контроллер. Потом на третий. В домене без нормальной сегментации UDP 389 доступен с любой машины в сети — это значит, что все DC можно положить последовательно за минуты. Пока они по очереди перезагружаются, никто в домене не может аутентифицироваться: ни пользователи на рабочих станциях, ни сервисы на серверах, ни скрипты с Kerberos-билетами. Именно в этот хаос ransomware-группы и разворачивают шифровальщик — когда у администраторов нет нормального доступа к инфраструктуре, а каждое действие требует объяснить коллеге почему у него не работает вход.

Аналогия из 2020 года — ZeroLogon (CVE-2020-1472): тоже Netlogon, тоже атака на DC без аутентификации, тоже немедленное оружеизирование после публикации. Ransomware-операторы и APT-группы использовали ZeroLogon буквально через дни после раскрытия. CCB явно имел этот паттерн в виду, когда выпускал экстренное предупреждение по CVE-2026-41089.

ХРОНОЛОГИЯ

12 мая 2026 года, майский Patch Tuesday. Microsoft закрывает CVE-2026-41089 патчем KB5089549 и выставляет в MSRC: exploited: No, publiclyDisclosed: No, эксплуатация «маловероятна». В тот же день исследователи Aretiq AI публикуют детальный root cause analysis — с именем уязвимой функции, SHA256-хэшами affected binaries и proof-of-concept кодом. Патч ещё не успел разойтись по корпоративным WSUS-серверам, а технические детали уже в открытом доступе.

Дальше — 17 дней тишины. Точнее, тишины для внешних наблюдателей. 29 мая CCB обновляет своё майское advisory: CVE-2026-41089 эксплуатируется в реальных атаках, рекомендован приоритетный патчинг. 1 июня — отдельный экстренный алерт. Кто именно атакует и кого — публично не раскрывается.

17 дней между патчем и подтверждённой эксплуатацией — это уже норма, а не исключение. AI-инструменты анализа бинарных патчей научились восстанавливать уязвимый путь кода за часы. Пока ваш change management комитет согласовывает патчинг продакшн-DC, кто-то уже написал эксплойт и тестирует его на незащищённых целях. Это не повод для паники, но повод пересмотреть то, насколько «осторожный» подход к патчингу критической инфраструктуры вписывается в реальный threat landscape 2026 года.

ПОЧЕМУ ЭТО ВАЖНО

Контроллер домена — не обычный сервер. Это плоскость управления идентификацией всей организации. RCE или sustained DoS на DC не требует дополнительных шагов для получения влияния: упавший DC означает, что никто в домене не может аутентифицироваться, пока он не поднимется обратно. В крупной корпоративной инфраструктуре это переводится в прямые финансовые потери — каждая минута простоя аутентификации блокирует работу сотен или тысяч сотрудников.

Для Linux-администраторов, которые работают в смешанных средах, это означает следующее: ваши Linux-серверы, скорее всего, не уязвимы напрямую. Но если они используют Kerberos для аутентификации в домене (что типично для enterprise-сред с SSSD или winbind) — падение DC влияет и на них. Сервисы, которые получают Kerberos-билеты при старте, потеряют аутентификацию. PAM-модули на Kerberos перестанут пускать пользователей.

Отдельный вопрос — насколько ваш домен вообще уязвим. Конфигурации с коротким DNS-доменом вроде corp.local или example.com могут не пострадать: буфер в 528 байт не переполнится при малом объёме DNS-данных. Но enterprise-среды с несколькими уровнями поддоменов — servers.eu.division.company.internal — уже в зоне риска. Проверьте длину DNS-домена вашего контроллера. Если она превышает 50 символов, и hostname тоже не короткий — KB5089549 нужен немедленно, не в следующий maintenance window.

ОБНОВЛЕНИЕ

Патч для CVE-2026-41089 — KB5089549 для Windows Server 2025 (build 26100.32860). Для других поддерживаемых версий Windows Server патчи вышли в том же майском Patch Tuesday. Для legacy-систем — Windows Server 2008 R2, 2012, 2012 R2 — компания Acros Security выпустила micropatch через платформу 0patch, поскольку эти версии выходят за пределы стандартной поддержки Microsoft.

Проверить версию netlogon.dll на Windows Server 2025:

Get-Item C:\Windows\System32\netlogon.dll | Select-Object -ExpandProperty VersionInfo | Select FileVersion, ProductVersion

Уязвимая версия: 10.0.26100.32684 (SHA256: C1F5FA84AE46E1A39592284EBB354BD055743D72AB417C1B90A7D99383289594). Пропатченная версия содержит строку Feature_404993339 и использует RtlStringCbCopyExW вместо небезопасного цикла копирования.

Проверить установленные обновления:

Get-HotFix -Id KB5089549

Если команда возвращает результат — патч установлен. Пустой вывод означает уязвимость.

Как справедливо отметил Jason Kikta, CTO Automox: «half-patched forests are not a defensible state for a pre-auth DC bug» — патчить нужно все контроллеры домена в одно окно обслуживания. Частично запатченный лес остаётся уязвимым: атакующий просто переключится на незапатченный DC.

До применения патча временная мера — ограничить доступ к UDP 389 на уровне сети. На периметре это означает блокировку CLDAP-трафика из внешних и ненадёжных сегментов. Внутри сети — сегментация: рабочие станции и серверы не должны иметь прямого доступа к UDP 389 DC, если только это не требуется для работы конкретного сервиса. Это не закрывает вектор полностью (CLDAP нужен для DC Locator), но существенно сужает поверхность атаки.

Индикаторы возможной эксплуатации: неожиданные перезапуски службы Netlogon, аномальный трафик CLDAP с нехарактерных источников (не с DC и не с клиентских машин домена), ошибки аутентификации сразу после подозрительной сетевой активности на DC.

ВЫВОДЫ

CVE-2026-41089 — это напоминание о том, что самые опасные уязвимости живут не в экзотических компонентах, а в базовой инфраструктуре, которой доверяют абсолютно. Netlogon присутствует в каждом Windows-домене, UDP 389 открыт на каждом DC, и исторически Netlogon уже был вектором для одних из самых разрушительных атак последнего десятилетия.

Если у вас есть Windows Server в роли контроллера домена — установите KB5089549 немедленно. Проверьте длину DNS-домена, ограничьте доступ к UDP 389 там, где это возможно без нарушения работы домена, и мониторьте Event Log на DC на предмет неожиданных перезапусков LSASS. В условиях активной эксплуатации «потестируем патч сначала» — не лучшая стратегия. Тестируйте, но быстро.