Zerologon aftermath: аудит Netlogon-трафика и поиск уязвимого легаси

Патч для CVE-2020-1472 вышел в августе, и большинство нормально управляемых инфраструктур его получили достаточно быстро. Но установить патч и закрыть проблему - не одно и то же. Microsoft выбрала поэтапную стратегию: сначала патч переводит DC в режим логирования нарушителей, а принудительное отключение небезопасного Netlogon Secure Channel для всех устройств запланировано на февраль 2021. Это даёт окно для инвентаризации - и его надо использовать, пока оно есть.

Zerologon (CVE-2020-1472) позволяет атакующему сбросить пароль компьютерного аккаунта контроллера домена через уязвимость в реализации MS-NRPC. Никакой аутентификации до атаки не требуется - только сетевой доступ к DC на порту 445 или 135. После патча DC начинает требовать защищённый Netlogon Secure Channel от клиентов. Проблема в том, что старое оборудование - принтеры, МФУ, embedded-устройства, legacy NAS - может не поддерживать актуальную реализацию MS-NRPC и просто перестать работать в домене в феврале.

Что генерирует EventID 5827 и 5828

После установки августовского патча контроллер домена начинает писать в Security Log два события:

• EventID 5827 - DC отказал в небезопасном подключении Netlogon Secure Channel от компьютерного аккаунта. В режиме enforcement это уже реальный отказ; в текущем режиме - только логирование, соединение пропускается.
• EventID 5828 - то же самое, но для трасти (trust relationship) - для межлесных и междоменных доверий.

Фактически Microsoft дала нам встроенный детектор проблемных устройств. Задача - настроить сбор и разобраться, что там логируется, до того как enforcement наступит принудительно.

Как выглядит аудит на практике

Нам пришлось делать это у нескольких заказчиков после того, как экстренный патч был применён. Алгоритм простой, но трудоёмкий:

Первое - сбор событий со всех DC. Если в инфраструктуре несколько контроллеров домена, 5827/5828 нужно собирать с каждого. Использовали wevtutil для выгрузки в xml и PowerShell для агрегации по уникальным именам машин:

Get-WinEvent -ComputerName dc01 -FilterHashtable @{
    LogName='Security'; Id=5827,5828
} | Select-Object TimeCreated,
    @{n='Machine';e={$_.Properties[1].Value}},
    @{n='IP';e={$_.Properties[4].Value}} |
    Sort-Object Machine -Unique

Второе - классификация находок. Список уникальных машин из событий - это и есть потенциальные нарушители. Дальше надо понять, что это такое. На одном из проектов в списке оказались: два сетевых принтера Konica Minolta (встроенный аккаунт для scan-to-folder), старый NAS на FreeBSD с Samba 3.x, один сервер мониторинга на Windows Server 2003 R2 (который формально должен был быть выведен ещё три года назад), и несколько тонких клиентов с прошивкой 2014 года.

Третье - разбор каждого устройства. Для каждой находки нужно выяснить: есть ли обновление прошивки/ПО с поддержкой защищённого канала, и если нет - какие варианты. У принтеров Konica Minolta обновление firmware закрыло проблему. Samba 3.x не поддерживает нужную версию MS-NRPC, и там пришлось поднимать версию. Windows Server 2003 - это отдельная история: патча для него нет и не будет, единственный вариант - вывод из домена или перенос функциональности.

Exception List: когда без него не обойтись

Microsoft предусмотрела механизм исключений - список машинных аккаунтов, которым временно разрешено использовать небезопасный канал даже после включения enforcement. Настраивается через GPO: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Domain controller: Allow vulnerable Netlogon secure channel connections.

Это не решение проблемы, это временный костыль с явным сроком годности. Для устройств, которые никак не обновить к февралю, exception list - способ не уронить сервис одномоментно, но план по выводу или обновлению всё равно нужен. Каждое устройство в exception list - это дыра в защите, которую вы осознанно оставляете.

Что реально нашли

Самой неожиданной находкой в нескольких инфраструктурах оказались устройства, про которые ИТ-отдел уже «забыл» - они просто работали годами без внимания. Принтеры с аккаунтами в домене, которые никто не вспоминал при аудите, потому что принтер просто печатает. Системы видеонаблюдения с Windows XP Embedded, которые оказывается тоже состоят в домене. Промышленные контроллеры с Windows CE, подключённые к корпоративному AD для удобства администрирования.

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

Что делать до февраля

Список задач, с которым имеет смысл двигаться:

• Собрать и проанализировать 5827/5828 со всех DC - это база, без которой дальше работать вслепую.
• Классифицировать каждую машину из списка нарушителей: управляемый хост или embedded/legacy.
• Проверить наличие обновлений для каждого проблемного устройства у производителя.
• Для неуправляемых устройств решить: вывод из домена, сегментация, exception list с планом выхода.
• Задокументировать exception list с обоснованием и датой планируемого закрытия - чтобы в феврале это не превратилось в постоянное решение без владельца.

Ситуация управляема, но только если заниматься ею сейчас, а не ждать, пока enforcement включится сам и что-то перестанет работать в пятницу вечером. Если нужна помощь с аудитом и инвентаризацией - аудит безопасности инфраструктуры как раз для таких случаев.