04.11.2020
Zerologon – это последняя обнаруженная критическая уязвимость в Windows Server, затрагивающая все версии данной операционной системы, начиная с 2008 года и до последней доступной от Microsoft версии. Она позволяет атакующему скомпрометировать учетную запись машинного аккаунта контроллера домена и получить доступ к содержимому всей базы Active Directory. Для эксплуатации достаточно наличия сетевой связности с контроллером домена организации. Эта уязвимость имеет рейтинг серьезности 10.0, и уже есть примеры того, как можно легко использовать эту брешь безопасности.
Как работает Zerologon?
Zerologon — это уязвимость в протоколе шифрования, который использует служба Netlogon. Протокол позволяет компьютерам проходить аутентификацию на контроллере домена и обновлять пароль своего аккаунта в Active Directory. Именно эта особенность делает Zerologon опасной. В частности, уязвимость позволяет атакующему выдать себя за контроллер домена и изменить его пароль. Злоумышленник получает доступ к контроллеру домена c наивысшими привилегиями, а следовательно — и к корпоративной сети. После смены пароля атакующий может использовать учетную запись контроллера домена для развития атаки, например, выполнив атаку DCSync (получение учетных записей Active Directory через механизм репликации).
Методы обнаружения
Обнаружение с использованием журнала отладки Netlogon
Поскольку эксплуатируется уязвимость в протоколе Netlogon, рассмотрим журнал событий Netlogon. По умолчанию в журналах Windows аудиту подлежит лишь часть событий, однако можно включить режим отладки Netlogon с помощью команды
nltest /dbflag:0x2080ffff
, которая должна быть запущена от имени администратора. После этого служба Netlogon будет сохранять большую часть важных событий в файл журнала, который можно найти по пути C:\Windows\debug\netlogon.txt
. Затем необходимо перезапустить службу Netlogon. На скриншоте ниже — несколько интересных строк, которые были записаны службой Netlogon в журнал в процессе эксплуатации уязвимости Zerologon.При настроенном режиме отладки Netlogon в журнале фиксируется каждый этап атаки и даже присутствует MD5-хеш пароля, который был установлен для учетной записи контроллера домена. MD5-хеш записывается в формате little-endian. Однако подобный способ мониторинга не очень удобный с точки зрения сбора событий в SIEM-систему, кроме того, он требует включения режима отладки Netlogon на всех контроллерах домена.
Обнаружение артефактов, оставленных эксплоитами
Первая стадия процесса эксплуатации — это фактически брутфорс. Эксплоит множество раз пытается аутентифицироваться с помощью Netlogon на контроллере домена с сообщением ClientChallenge, состоящим из 8 нулевых байт. Множественные неуспешные попытки аутентификации приводят к генерации события 5805 на контроллере домена: «The session setup from the computer failed to authenticate. The following error occurred: Access is denied» (см. пример события на скриншоте ниже).
Кроме того, если в эксплоите было указано неверное имя учетной записи контроллера домена, то попытка аутентификации с неверной учетной записью вызывает генерацию события 5723 на контроллере домена: «The session setup from computer ’’ failed because the security database does not contain a trust account ’’ referenced by the specified computer» (на скриншоте ниже).
В случае эксплуатации Zerologon при помощи утилиты mimikatz или других эксплоитов, запущенных с хоста с именем kali, в событиях остаются артефакты (имя хоста с установленной ОС Kali Linux меняется крайне редко, поэтому и учитывается в правиле). Mimikatz с неизмененным исходным кодом оставляет артефакт в виде подстроки mimikatz в событиях 5805 и 5723.
В рамках исследования мы также рассмотрели различные вариации использования эксплоитов и выявили случаи эксплуатации уязвимости Zerologon с виртуальной машины под управлением ОС Kali Linux, при которых в событиях 5805 и 5723 оставался артефакт в виде подстроки kali, указанной в качестве хоста — источника аутентификации.
Таким образом, логика первого правила обнаружения попытки эксплуатации уязвимости Zerologon будет выглядеть следующим образом:
(EventID = ’5805′ OR EventID = ’5723′) AND (Message contains ’kali’ OR Message contains ’mimikatz’).
Обнаружение на основании различий легитимной смены пароля от эксплуатации уязвимости
Теперь рассмотрим методы обнаружения, основанные на различном наборе событий при периодическом легитимном обновлении пароля учетной записи компьютера и при его смене при эксплуатации Zerologon.
Максимальный срок действия пароля учетной записи компьютера по умолчанию — 30 дней. По истечении этого срока пароль будет изменен средствами операционной системы с использованием протокола Netlogon. Данное значение может быть изменено при помощи локальной или групповой политики:
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Domain member: Maximum machine account password age.
При изменении пароля учетной записи компьютера в журнале событий Security будет сгенерировано несколько событий. Первое из них — это событие с EventID 4742 «A computer account was changed», которое имеет TargetUserName, равное имени учетной записи контроллера домена, а PasswordLastSet установлено в дату смены пароля. Это событие означает, что пароль учетной записи компьютера контроллера домена был изменен.
В журнале событий System есть еще одно интересное событие с EventID 5823 — «The system successfully changed its password on the domain controller. This event is logged when the password for the computer account is changed by the system. It is logged on the computer that changed the password». Это событие означает, что учетная запись компьютера была легитимно изменена системой.
Таким образом, при легитимной смене пароля учетной записи контроллера домена будет сгенерировано два события: 5823 и 4742. Однако при эксплуатации Zerologon событие 5823 будет отсутствовать в журнале аудита.
Логика второго правила обнаружения эксплуатации уязвимости Zerologon может выглядеть следующим образом:
when both of (EventID = ’4742′ AND TargetUserName IN «Domain_Controller_Accounts_List» AND PasswordLastSet != ’-’) and not (EventID = ’5823′) were detected on the same host within 1 minute
Реализованное по описанной выше логике правило позволит с высокой точностью обнаружить факты эксплуатации уязвимости Zerologon. Дополнительной настройки политики аудита для его работы не потребуется. Единственное, что потребуется, — подготовить список контроллеров домена организации и поместить его в набор Domain_Controller_Accounts_List.
Однако можно посмотреть на процесс обнаружения эксплуатации уязвимости Zerologon под другим углом. Ранее мы писали, что первая стадия эксплуатации — это брутфорс. Поэтому, если в течение одной минуты на одном контроллере домена будут обнаружены оба события — 5805 и 4742, это также будет свидетельствовать о факте успешной эксплуатации Zerologon.
Логика нашего третьего правила для обнаружения эксплуатации уязвимости Zerologon, может выглядеть следующим образом:
when both of (EventID = ’4742′ AND TargetUserName IN «Domain_Controller_Accounts_List» AND PasswordLastSet != ’-’) and (EventID = ’5805′) were detected on the same host within 1 minute
Обнаружение эксплуатации на основе сетевого трафика
Как мы упоминали в начале статьи, первый этап эксплуатации уязвимости подразумевает множественные попытки отправки ClientChallenge с предустановленным нулевым значением ключа для обхода аутентификации. Как показала практика, в подавляющем большинстве случаев для обхода механизма аутентификации необходимо не менее 10 попыток. Такая аномалия может быть легко обнаружена в сетевом трафике. Обращения по протоколу DCE/RPC с отправкой запросов на получение ServerChallenge методом NetrServerReqChallenge и попытками аутентификации методами NetrServerAuthenticate с нулевым значением ClientChallenge осуществляются на RPC-интерфейс MS-NRPC.
Трафик Mimikatz версии 2.2.0-20200916 без шифрования нагрузки DCE/RPC при обходе аутентификации с нулевым значением ключа содержит артефакт в переменной Computer Name метода NetrServerReqChallenge (Opnum 4).
Трафик Mimikatz версии 2.2.0-20200918 с шифрованием нагрузки DCE/RPC (посредством использования NTLMSSP с уровнем аутентификации RPC_C_AUTHN_LEVEL_PKT_PRIVACY) не содержит уникальных артефактов. Однако атаку можно выявить по многократно повторяющимся методам NetrServerReqChallenge (Opnum 4) и NetrServerAuthenticate2 (Opnum 15) в трафике от единственного источника за промежуток времени в несколько секунд.
Посредством PoC отправка пар методов NetrServerReqChallenge и NetrServerAuthenticate осуществляется в отдельных TCP-сессиях. При этом концептуально подход к выявлению на основе повторяющихся пар NetrServerReqChallenge и NetrServerAuthenticate остается тем же.
На заключительном этапе атаки при помощи метода NetrServerPasswordSet2 (Opnum 30) с последовательностью из 516 нулевых байтов для учетной записи компьютера контроллера домена устанавливается пустой пароль.
Таким образом, обнаружить атаку Zerologon по сетевому трафику возможно по аномально большому количеству запросов от единственного источника по протоколу DCE/RPC с парами методов NetrServerReqChallenge и NetrServerAuthenticate за короткий промежуток времени. При определенных условиях можно более точно идентифицировать активность, основываясь на уникальных артефактах в трафике, а не на статистических аномалиях.
Обнаружение артефактов в адресном пространстве LSASS
Поскольку во время эксплуатации уязвимости Zerologon происходит аутентификация на контроллере домена с использованием MS-NRPC функции hNetrServerAuthenticate2 (hNetrServerAuthenticate3)
, в процессе аутентификации задействуется сервис проверки подлинности локальной системы (LSASS). В результате обращения к серверу проверки подлинности в адресное пространство процесса lsass.exe
попадает артефакт — структура, содержащая параметры, переданные в функцию hNetrServerAuthenticate2 (hNetrServerAuthenticate3)
(см. рисунок ниже).
На фрагменте исходного кода одного из эксплоитов и фрагменте дампа адресного пространства процесса lsass с артефактами, оставшимися после эксплуатации, видна взаимосвязь. Переданные в функцию аргументы остались в памяти, общая структура данных сохранилась. Если смотреть с конца, 4 байта (0×212fffff) представляют собой флаги — Netlogon Negotiable Options. Перед ним располагаются 8 нулевых байтов, представляющие собой нулевой шифротекст. Затем перед ними трижды записывается имя хоста DC в таком же виде и порядке, в котором аргументы были переданы в функцию. Также в памяти виден байт, означающий тип безопасного канала Netlogon ServerSecureChannel (06).
Однако иногда по неустановленным причинам этот и другие байты могут принимать различные значения, не связанные с описанием выше. Артефакты в адресном пространстве процесса lsass.exe
хранятся в сегменте, который не подразумевает долговременного хранения данных, и могут быть удалены в любой момент после появления. Наше исследование показало, что в большинстве случаев артефакты остаются в памяти процесса lsass.exe
не дольше получаса, после чего перезаписываются другими данными.
Основным маркером, позволяющим находить данный участок адресного пространства и использовать его для дальнейших проверок, являются флаги Netlogon Negotiable Options. Они представляют собой 32-битное число, которое формируется в бинарном виде из набора различных параметров.
По информации из технического документа компании Secura, а также других исследований данной уязвимости, второй этап эксплуатации Zerologon — это отключение механизма RPC signing and sealing посредством отключения нужного бита во флаге. Во всех рассмотренных эксплоитах и исследованиях для отключения данного механизма используется значение флагов 0×212fffff. Однако наше исследование показало, что единственный влияющий на успешную эксплуатацию параметр — это 25-й бит, отвечающий за включение поддержки AES-CFB8 «Supports Advanced Encryption Standard (AES) encryption (128 bit in 8-bit CFB mode) and SHA2 hashing». Для успешной эксплуатации уязвимости требуется лишь этот флаг, остальные могут быть установлены в 1 или 0, это не повлияет на результат. Тем самым изменение нескольких бит во флаге влечет за собой потерю искомого якоря в адресном пространстве lsass в виде байт ff ff 2f 21, содержащих в себе флаги, которые используют все протестированные во время исследования эксплоиты.
Помимо обхода детектирующей логики YARA-правил, о которых расскажем ниже, использование некоторых флагов Netlogon Negotiable Options приводит к тому, что в адресном пространстве lsass не остается артефактов, по которым возможно выявить факт эксплуатации уязвимости Zerologon. Один из таких флагов — 0×312fffff. Так подтверждается гипотеза о том, что флаги, которые по результатам исследований позволяют отключить механизм RPC signing and sealing, на самом деле для этого не предназначены.
В ходе исследования мы проанализировали различные YARA-правила (в том числе разработанное специалистами из компании Cynet), нацеленные на обнаружение следов эксплуатации уязвимости Zerologon в памяти системы. Мы установили, что существующие правила не учитывают различных аномалий, связанных с модификацией некоторых значащих байт в адресном пространстве, и решили реализовать новое YARA-правило, учитывающее эти аномалии.
Необходимо напомнить, что эксплуатация возможна при практически любом сочетании флагов Netlogon Negotiable Options, но при этом именно флаги служат якорем для обнаружения артефактов в памяти. Поэтому мы приняли такое ограничение: использовать в нашем YARA-правиле распространенное сочетание флагов 0×212fffff. В процессе разработки мы протестировали различные эксплоиты, в том числе модуль zerologon утилиты mimikatz. Полученное правило протестировано на ОС Windows Server 2012R2 и Windows Server 2016.
Сокращение окна возможностей
Корпорация Microsoft опубликовала патч для устранения уязвимости Zerologon вместе с серией изменений в канале безопасного подключения Netlogon, и этот патч администраторам следует обязательно применить.
Как и в случае со всеми уязвимостями, крайне важно, чтобы IT-специалисты или менеджеры по информационной безопасности внедряли патчи и обновления как можно скорее, чтобы сократить «окно возможностей», используемое кибер-атаками, то есть время до момента применения обновления для предотвращения использования уязвимости. Новости о том, что информационные системы той или иной компании зашифрованы в ходе атаки с использованием Zerologon, появляются все чаще. Поэтому не стоит забывать, что одной лишь возможности обнаружить факты эксплуатации Zerologon для защиты недостаточно. Значительно снизить риски поможет установка закрывающих уязвимость обновлений безопасности от Microsoft.
Компания "Первый номер" в усиленном режиме работает над устранением уязвимости Zerologon.