Методы обнаружение уязвимости Zerologon

CVE-2020-1472, или  Zerologon. Обнаружение уязвимости Zerologon, уже вошла в число самых опасных уязвимостей, обнаруженных за последние годы. Это позволяет злоумышленнику взломать учетную запись компьютера контроллера домена и получить доступ к содержимому всей базы данных Active Directory. Для работы достаточно сетевого подключения к контроллеру домена организации.Мы провели исследование Zerologon и разработали различные методы обнаружения его использования: через события журнала аудита Windows, сетевой трафик и правила YARA. В этой статье мы подробно остановимся на каждом из них.

 

Zerologon — это уязвимость в протоколе шифрования, используемом службой Netlogon. Протокол позволяет компьютерам аутентифицироваться на контроллере домена и обновлять пароль для учетной записи Active Directory. Именно эта особенность делает Zerologon опасным. В частности, уязвимость может позволить злоумышленнику выдать себя за контроллер домена и изменить его пароль.Злоумышленник получает доступ к контроллеру домена с наивысшими привилегиями и, следовательно, к корпоративной сети. После изменения пароля злоумышленник может использовать учетную запись контроллера домена для эскалации атаки, например, путем выполнения атаки DCSync (получения учетных записей из Active Directory через механизм репликации).

Обычно клиентский компьютер, который хочет связаться с сервером Netlogon, например контроллером домена Windows, начинает с отправки на сервер восьми случайных байтов (то, что часто называют nonce, сокращая фразу number used once) на сервер.

Этапы эксплуатации Zerologon

Согласно техническому документу Secura, процесс эксплуатации Zerologon состоит из трех этапов.

1.Отправка нулевых байтов. Вместо отправки восьми случайных байтов злоумышленник отправляет 8 нулевых байтов. Злоумышленник повторяет отправку этих сообщений до тех пор, пока сервер не примет одно из них, тем самым минуя процесс аутентификации. В случае Zerologon для успешного подключения к серверу требуется в среднем 256 попыток отправки сообщения ClientChallenge, состоящего из нулей.

2.Отключение механизма RPC signing and sealing. MS-NRPC использует механизм RPC signing and sealing для шифрования транспортного уровня. Обычно шифрование является обязательным процессом для передачи данных, но в MS-NRPC этот механизм не является обязательным и контролируется клиентом. Сервер не откажется установить соединение с клиентами, которые не запрашивают использование шифрования. Это означает, что вы можете просто отключить шифрование в заголовке сообщения. Фактически, второй этап заключается в отключении механизма подписи и запечатывания RPC, чтобы сообщения отправлялись в виде открытого текста, и злоумышленник мог использовать методы протокола MS-NRPC.

3.Изменение пароля учетной записи. Третий шаг в использовании уязвимости Zerologon — изменение пароля учетной записи контроллера домена, соединение которой для учетной записи было установлено ранее. Злоумышленники, использующие метод NetrServerPasswordSet в MS-NRPC, могут изменить пароль учетной записи компьютера. Самый простой способ использовать этот метод — удалить текущий пароль или, другими словами, установить пустой пароль. Также можно изменить пароль, просто отправив запрос с новым предпочтительным паролем. После изменения пароля злоумышленники могут использовать учетную запись контроллера домена для эскалации атаки, например, как упоминалось ранее, для репликации базы данных Active Directory.

PoC и эксплоиты

Первый PoC опубликовала компания Secura на GitHub. Скрипт попытается проэксплуатировать уязвимость Zerologon: после успешного установления соединения он немедленно завершит работу и не будет выполнять никаких действий через Netlogon.

Что касается эксплойтов, то на момент написания этой статьи их уже предостаточно. Однако все они ведут себя одинаково: сбрасывают пароль или устанавливают для него значение, определенное пользователем.

Есть также альтернативный метод эксплуатации Zerologon, найденный исследователем безопасности Дирк-Яном Моллема. Но он используется вместе с другими уязвимостями и заслуживает отдельной статьи.

Методы обнаружения

Целью нашего исследования было найти все возможные методы определения того, что Zerologon работает. Мы разработали и протестировали логику правил корреляции, сигнатур для сетевых систем IPS / IDS, а также правило YARA для обнаружения артефактов в памяти процесса LSASS.

Zerologon,CVE-2020-1472,Netlogon

Поскольку используется уязвимость протокола Netlogon, следует учитывать журнал событий Netlogon. По умолчанию проверяется только подмножество событий в журналах Windows, но вы можете включить режим отладки Netlogon с помощью команды nltest / dbflag: 0x2080ffff, которую необходимо запускать от имени администратора. Затем служба Netlogon запишет большинство важных событий в файл журнала, который можно найти в папке C: \ Windows \ debug \ netlogon.txt. Затем вам нужно перезапустить службу Netlogon. На снимке экрана ниже показаны некоторые интересные строки, которые Netlogon зарегистрировал при эксплуатации уязвимости Zerologon.

Пример событий, записанных в отладочном журнале Netlogon в ходе эксплуатации уязвимости Zerologon

Когда настроен режим отладки Netlogon, каждый этап атаки записывается в журнал, и есть даже хэш MD5 пароля, который был установлен для учетной записи контроллера домена. Хеш MD5 записывается в формате с прямым порядком байтов. Однако этот метод мониторинга не очень практичен с точки зрения захвата событий в SIEM-системе. Кроме того, на всех контроллерах домена должен быть активирован режим отладки Netlogon.

Обнаружение артефактов, оставленных эксплоитами

Первым этапом процесса эксплуатации является брутфорс. Эксплойт пытается повторно пройти аутентификацию со службой входа в сеть на контроллере домена с 8-байтовым сообщением ClientChallenge. Несколько неудачных попыток проверки подлинности генерируют событие 5805 на контроллере домена: «Не удалось выполнить проверку подлинности сеанса с компьютера. Произошла следующая ошибка: Доступ запрещен »(см. Пример события на снимке экрана ниже).

Кроме того, если в эксплоите было указано неверное имя учетной записи контроллера домена, то попытка аутентификации с неверной учетной записью вызывает генерацию события 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, указанной в качестве хоста — источника аутентификации.

Событие 5805. Ошибка аутентификации сессии с хоста kali. Доступ запрещен

Событие 5723. Ошибка установления сессии с хоста mimikatz из-за отсутствия в базе данных безопасности аккаунта evildc

Таким образом, логика первого правила обнаружения попытки эксплуатации уязвимости 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.

Максимальный срок действия пароля учетной записи компьютера по умолчанию — 30 дней. По истечении этого срока пароль будет изменен средствами операционной системы с использованием протокола Netlogon. Данное значение может быть изменено при помощи локальной или групповой политики:

При изменении пароля учетной записи компьютера в журнале событий Security будет сгенерировано несколько событий. Первое из них — это событие с EventID 4742 «A computer account was changed», которое имеет TargetUserName, равное имени учетной записи контроллера домена, а PasswordLastSet установлено в дату смены пароля. Это событие означает, что пароль учетной записи компьютера контроллера домена был изменен.

Событие 4742. Пароль учетной записи DC$ был изменен в 5:46:34 PM

В журнале событий 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. Пароль учетной записи контроллера домена был успешно изменен системой в 5:46:34 PM

Таким образом, при легитимной смене пароля учетной записи контроллера домена будет сгенерировано два события: 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, выполняются в интерфейсе MS-NRPC RPC.

Как мы видим трафик Mimikatz версии 2.2.0-20200916 без шифрования нагрузки DCE/RPC при обходе аутентификации с нулевым значением ключа содержит артефакт в переменной Computer Name метода NetrServerReqChallenge (Opnum 4).

Трафик Mimikatz версии 2.2.0-20200916 при обходе аутентификации

Трафик Mimikatz версии 2.2.0-20200918 с шифрованием нагрузки DCE/RPC (посредством использования NTLMSSP с уровнем аутентификации RPC_C_AUTHN_LEVEL_PKT_PRIVACY) не содержит уникальных артефактов. Однако атаку можно выявить по многократно повторяющимся методам NetrServerReqChallenge (Opnum 4) и NetrServerAuthenticate2 (Opnum 15) в трафике от единственного источника за промежуток времени в несколько секунд.

Зашифрованный трафик Mimikatz версии 2.2.0-20200918 при обходе аутентификации

Посредством PoC отправка пар методов NetrServerReqChallenge и NetrServerAuthenticate выполняется в отдельных сеансах TCP. В то же время концептуальный подход к обнаружению на основе повторяющихся пар NetrServerReqChallenge и NetrServerAuthenticate остается прежним.

Последний этап атаки с использованием метода NetrServerPasswordSet2 (Opnum 30) с последовательностью из 516 нулевых байтов устанавливает пустой пароль для учетной записи компьютера контроллера домена.

Трафик запроса на сброс пароля методом NetrServerPasswordSet2

Таким образом, можно за короткое время обнаружить атаку Zerologon по сетевому трафику по аномально большому количеству запросов от одного источника по протоколу DCE / RPC с парами методов NetrServerReqChallenge и NetrServerAuthenticate. При определенных условиях можно более точно идентифицировать действия на основе уникальных артефактов движения, а не статистических аномалий.

Обнаружение артефактов в адресном пространстве LSASS

Как и во время эксплуатации уязвимости Zerologon, проверка подлинности происходит на контроллере домена с помощью функции MS-NRPC hNetrServerAuthenticate2 (hNetrServerAuthenticate3), в процессе проверки подлинности задействована служба проверки подлинности локальной системы (LSASS). В результате вызова сервера аутентификации в адресное пространство процесса lsass.exe отправляется артефакт — структура, содержащая параметры, переданные в функцию hNetrServerAuthenticate2 (hNetrServerAuthenticate3) (см. Рисунок ниже).

Пример вызова функции hNetrServerAuthenticate3 с передаваемыми ей аргументами

Фрагмент дампа адресного пространства процесса lsass с артефактами после эксплуатации уязвимости Zerologon

Фрагмент исходного кода одного из эксплойтов и фрагмент дампа адресного пространства процесса lsass с артефактами, оставшимися после его использования, указывают на связь. Аргументы, переданные в функцию, остаются в памяти, общая структура данных сохраняется. Если смотреть с конца, 4 байта (0x212fffff) представлены флагами — Netlogon Negotiable Options. Ему предшествуют 8 нулевых байтов, которые представляют собой зашифрованный нулевой текст. Затем к ним добавляется префикс имени хоста контроллера домена три раза в том же порядке и формате, что и аргументы, переданные в функцию. В памяти также отображается байт, указывающий тип защищенного канала Netlogon ServerSecureChannel (06).

Однако иногда по неизвестным причинам этот и другие байты могут принимать разные значения, не связанные с приведенным выше описанием. Артефакты в адресном пространстве процесса lsass.exe хранятся в сегменте, не связанном с долгосрочным хранением данных, и могут быть удалены в любое время после их возникновения. Наше исследование показало, что в большинстве случаев артефакты остаются в памяти процесса lsass.exe более получаса, после чего перезаписываются другими данными.

Основным маркером, позволяющим находить данный участок адресного пространства и использовать его для дальнейших проверок, являются флаги Netlogon Negotiable Options. Они представляют собой 32-битное число, которое формируется в бинарном виде из набора различных параметров.

Согласно официальному документу Secura и другим исследованиям этой уязвимости, второй этап эксплуатации Zerologon заключается в отключении механизма подписи и запечатывания RPC путем отключения необходимого бита во флаге. Во всех рассмотренных эксплойтах и ​​исследованиях значение флага 0x212fffff используется для отключения этого механизма. Однако наше исследование показало, что единственный параметр, влияющий на успешную работу, — это 25-й бит, отвечающий за включение поддержки AES-CFB8. Поддерживает шифрование Advanced Encryption Standard (AES) (128-битное в 8-битном режиме CFB) и хеширование SHA2. Только этот флаг необходим для успешного использования уязвимости. Остальные могут быть установлены на 1 или 0. Это не влияет на Результат: изменение нескольких битов в флаге приводит к потере желаемой привязки в адресном пространстве lsass в виде 21 байта ff ff 2f, которые содержат флаги, которые используются всеми эксплойтами, протестированными во время исследования.

Помимо обхода детектирующей логики 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.

 

YARA-правило, разработанное в ходе исследования, представлено ниже.

 

rule Zerologon_exploit
{
    meta:
        vulnerability = "CVE-2020-1472"
        description = "Memory detection of Zerologon exploits"
        reference = "<https://www.secura.com/blog/zero-logon>"
        reference = "<https://www.cynet.com/zerologon>"

    strings:
        $pattern = {00 ?? ?? (0? | 10 | 11) 00 00 00 00 00 00 00 (0? | 10 | 11) 00 00 00 (4? | 5? | 6? | 7? | 2D) 00 [1-27] 00 (24 | 00) 00 00 00 ( 00 00 | 06 00 | 06 00 00 00) (0? | 10) 00 00 00 00 00 00 00 (0? | 10) 00 00 00  (4? | 5? | 6? | 7? | 2D) 00 [1-27] 00 00 00 [8] FF FF 2F 21}

    condition:
        $pattern YARA-правило для обнаружения фактов эксплуатации Zerologon

Выводы

Описанные выше правила, основанные на журналах событий Windows, сетевой телеметрии и правиле YARA.Их можно использовать по отдельности или вместе. Это не только идентифицирует факты эксплуатации Zerologon, но также увеличивает скорость классификации инцидентов.

Новости о том, что информационные системы той или иной компании зашифрованы во время атаки с помощью Zerologon, возвращаются все чаще и чаще. Поэтому помните, что простой возможности обнаружить факты работы Zerologon недостаточно для защиты. Установка обновлений безопасности от Microsoft, закрывающих уязвимость, значительно снизит риск.