Салом КулХацкер!
CVE-2020-1472, или Zerologon, уже получила звание одной из самых опасных уязвимостей, обнаруженных за последние годы. Она позволяет атакующему скомпрометировать учетную запись машинного аккаунта контроллера домена и получить доступ к содержимому всей базы Active Directory. Для эксплуатации достаточно наличия сетевой связности с контроллером домена организации.
Мы провели собственное исследование Zerologon и разработали различные методы обнаружения ее эксплуатации: по событиям журналов аудита Windows, по сетевому трафику и при помощи YARA-правил. В этой статье подробно остановимся на каждом из них.
В чем суть уязвимости Zerologon
Zerologon — это уязвимость в протоколе шифрования, который использует служба Netlogon. Протокол позволяет компьютерам проходить аутентификацию на контроллере домена и обновлять пароль своего аккаунта в Active Directory. Именно эта особенность делает Zerologon опасной. В частности, уязвимость позволяет атакующему выдать себя за контроллер домена и изменить его пароль. Злоумышленник получает доступ к контроллеру домена c наивысшими привилегиями, а следовательно — и к корпоративной сети. После смены пароля атакующий может использовать учетную запись контроллера домена для развития атаки, например, выполнив атаку DCSync (получение учетных записей Active Directory через механизм репликации).
В сентябре голландский исследователь безопасности Том Тервоорт из компании Secura опубликовал подробное описание уязвимости. Выяснилось, что Zerologon вызвана недостатком в схеме криптографической аутентификации, которую использует Netlogon Remote Protocol (MS-NRPC). Рукопожатие и аутентификация MS-NRPC предполагают использование режима AES-CFB8 (с 8-битным режимом обратной связи по шифротексту). Это вариант блочного шифра AES, который предназначен для работы с блоками входных данных по 8 байт вместо обычных 16 байт (128-бит).
Как обнаружил Тервоорт, применение шифрования AES-CFB8 к состоящему из одних нулей открытому тексту приведет к такому же состоящему из одних нулей зашифрованному тексту. Это происходит из-за ошибки реализации для 1 из 256 ключей.
Обычно клиентский компьютер, который хочет взаимодействовать с сервером Netlogon, таким как контроллер домена Windows, начинает с отправки восьми случайных байтов (то, что часто называют nonce, сокращая фразу number used once) на сервер.
В августе 2020 года в рамках «августовского вторника» Microsoft выпустила исправление уязвимости. Этот патч сделал механизмы безопасности Netlogon (которые отключал Zerologon) обязательными для всех аутентификационных операций, что эффективно предотвращает атаки. Релиз второго патча, полностью закрывающего уязвимость, запланирован на февраль 2021 года.
Этапы эксплуатации Zerologon
Согласно техническому документу Secura, процесс эксплуатации Zerologon состоит из трех этапов.
Первый PoC опубликовала компания Secura на GitHub. Скрипт попытается проэксплуатировать уязвимость Zerologon: после успешного установления соединения он немедленно завершит работу и не будет выполнять никаких действий через Netlogon.
Что касается эксплоитов, на момент публикации этой статьи их появилось уже много. Однако все они ведут себя одинаково: либо сбрасывают пароль, либо устанавливают его в определенное пользователем значение.
Есть также альтернативный метод эксплуатации Zerologon, найденный исследователем безопасности Дирк-Яном Моллема. Но он используется вместе с другими уязвимостями и заслуживает отдельной статьи.
Методы обнаружения
Целью нашего исследования было найти все возможные методы обнаружения факта эксплуатации Zerologon. Мы разработали и протестировали логику правил корреляции, сигнатур для сетевых IPS-\IDS-систем, а также YARA-правило для выявления артефактов в памяти процесса LSASS.
Обнаружение с использованием журнала отладки Netlogon
Поскольку эксплуатируется уязвимость в протоколе Netlogon, рассмотрим журнал событий Netlogon. По умолчанию в журналах Windows аудиту подлежит лишь часть событий, однако можно включить режим отладки Netlogon с помощью команды nltest /dbflag:0x2080ffff, которая должна быть запущена от имени администратора. После этого служба Netlogon будет сохранять большую часть важных событий в файл журнала, который можно найти по пути C:\Windows\debug\netlogon.txt. Затем необходимо перезапустить службу Netlogon. На скриншоте ниже — несколько интересных строк, которые были записаны службой Netlogon в журнал в процессе эксплуатации уязвимости Zerologon.
Пример событий, записанных в отладочном журнале 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, указанной в качестве хоста — источника аутентификации.
Событие 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.
При изменении пароля учетной записи компьютера в журнале событий 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 осуществляются на RPC-интерфейс MS-NRPC.
Трафик 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) (см. рисунок ниже).
server_auth = nrpc.hNetrServerAuthenticate3(
rpc_con,
'\\\\' + compname + '\\x00', #\\\\dc
compname + '$\\x00', #dc
nrpc.NETLOGON_SECURE_CHANNEL_TYPE.ServerSecureChannel, #6
compname + '\\x00', #dc
ciphertext, #00000000
flags #0x212fffff
)
Пример вызова функции hNetrServerAuthenticate3 с передаваемыми ей аргументами
Фрагмент дампа адресного пространства процесса lsass с артефактами после эксплуатации уязвимости Zerologon
На фрагменте исходного кода одного из эксплоитов и фрагменте дампа адресного пространства процесса 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.
YARA-правило, разработанное в ходе исследования, представлено ниже.
rule Zerologon_exploit
{
meta:
vulnerability = "CVE-2020-1472"
description = "Memory detection of Zerologon exploits"
reference = "<
reference = "<
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.
CVE-2020-1472, или Zerologon, уже получила звание одной из самых опасных уязвимостей, обнаруженных за последние годы. Она позволяет атакующему скомпрометировать учетную запись машинного аккаунта контроллера домена и получить доступ к содержимому всей базы Active Directory. Для эксплуатации достаточно наличия сетевой связности с контроллером домена организации.
Мы провели собственное исследование Zerologon и разработали различные методы обнаружения ее эксплуатации: по событиям журналов аудита Windows, по сетевому трафику и при помощи YARA-правил. В этой статье подробно остановимся на каждом из них.
В чем суть уязвимости Zerologon
Zerologon — это уязвимость в протоколе шифрования, который использует служба Netlogon. Протокол позволяет компьютерам проходить аутентификацию на контроллере домена и обновлять пароль своего аккаунта в Active Directory. Именно эта особенность делает Zerologon опасной. В частности, уязвимость позволяет атакующему выдать себя за контроллер домена и изменить его пароль. Злоумышленник получает доступ к контроллеру домена c наивысшими привилегиями, а следовательно — и к корпоративной сети. После смены пароля атакующий может использовать учетную запись контроллера домена для развития атаки, например, выполнив атаку DCSync (получение учетных записей Active Directory через механизм репликации).
В сентябре голландский исследователь безопасности Том Тервоорт из компании Secura опубликовал подробное описание уязвимости. Выяснилось, что Zerologon вызвана недостатком в схеме криптографической аутентификации, которую использует Netlogon Remote Protocol (MS-NRPC). Рукопожатие и аутентификация MS-NRPC предполагают использование режима AES-CFB8 (с 8-битным режимом обратной связи по шифротексту). Это вариант блочного шифра AES, который предназначен для работы с блоками входных данных по 8 байт вместо обычных 16 байт (128-бит).
Как обнаружил Тервоорт, применение шифрования AES-CFB8 к состоящему из одних нулей открытому тексту приведет к такому же состоящему из одних нулей зашифрованному тексту. Это происходит из-за ошибки реализации для 1 из 256 ключей.
Обычно клиентский компьютер, который хочет взаимодействовать с сервером Netlogon, таким как контроллер домена Windows, начинает с отправки восьми случайных байтов (то, что часто называют nonce, сокращая фразу number used once) на сервер.
В августе 2020 года в рамках «августовского вторника» Microsoft выпустила исправление уязвимости. Этот патч сделал механизмы безопасности Netlogon (которые отключал Zerologon) обязательными для всех аутентификационных операций, что эффективно предотвращает атаки. Релиз второго патча, полностью закрывающего уязвимость, запланирован на февраль 2021 года.
Этапы эксплуатации Zerologon
Согласно техническому документу Secura, процесс эксплуатации Zerologon состоит из трех этапов.
- Отправка нулевых байтов. Вместо отправки восьми случайных байтов атакующий отправляет 8 нулевых байтов. Злоумышленник повторяет отправку таких сообщений, пока сервер успешно не примет одно из них, и тем самым обходит процесс аутентификации. В случае с Zerologon для успешного соединения с сервером требуется в среднем 256 попыток отправки сообщения ClientChallenge, состоящего из одних нулей.
- Отключение механизма RPC signing and sealing. MS-NRPC использует механизм RPC signing and sealing для шифрования транспортного уровня. Обычно шифрование — обязательный процесс при передаче данных, но в MS-NRPC этот механизм не является обязательным и управляется клиентом. Сервер не будет отказывать в установлении соединения клиентам, которые не запрашивают использование шифрования. Это означает, что вы можете просто отключить шифрование в заголовке сообщения. Собственно, вторая стадия и заключается в отключении механизма RPC signing and sealing, чтобы сообщения отправлялись в открытом виде и атакующий мог использовать методы протокола MS-NRPC.
- Изменение пароля учетной записи. Третья стадия эксплуатации уязвимости Zerologon заключается в изменении пароля для учетной записи контроллера домена, соединение от имени которого было установлено ранее. Атакующие при помощи метода NetrServerPasswordSet в MS-NRPC могут изменить пароль учетной записи компьютера. Самый простой способ использования этого метода заключается в удалении текущего пароля или, другими словами, установке пароля в пустое значение. Также возможно изменить пароль, просто отправив запрос с предпочтительным новым паролем. После смены пароля атакующие могут использовать учетную запись контроллера домена для развития атаки, например, как упоминалось ранее, выполнить репликацию базы данных Active Directory.
Первый PoC опубликовала компания Secura на GitHub. Скрипт попытается проэксплуатировать уязвимость Zerologon: после успешного установления соединения он немедленно завершит работу и не будет выполнять никаких действий через Netlogon.
Что касается эксплоитов, на момент публикации этой статьи их появилось уже много. Однако все они ведут себя одинаково: либо сбрасывают пароль, либо устанавливают его в определенное пользователем значение.
Есть также альтернативный метод эксплуатации Zerologon, найденный исследователем безопасности Дирк-Яном Моллема. Но он используется вместе с другими уязвимостями и заслуживает отдельной статьи.
Методы обнаружения
Целью нашего исследования было найти все возможные методы обнаружения факта эксплуатации Zerologon. Мы разработали и протестировали логику правил корреляции, сигнатур для сетевых IPS-\IDS-систем, а также YARA-правило для выявления артефактов в памяти процесса LSASS.
Обнаружение с использованием журнала отладки Netlogon
Поскольку эксплуатируется уязвимость в протоколе Netlogon, рассмотрим журнал событий Netlogon. По умолчанию в журналах Windows аудиту подлежит лишь часть событий, однако можно включить режим отладки Netlogon с помощью команды nltest /dbflag:0x2080ffff, которая должна быть запущена от имени администратора. После этого служба Netlogon будет сохранять большую часть важных событий в файл журнала, который можно найти по пути C:\Windows\debug\netlogon.txt. Затем необходимо перезапустить службу Netlogon. На скриншоте ниже — несколько интересных строк, которые были записаны службой Netlogon в журнал в процессе эксплуатации уязвимости Zerologon.
Пример событий, записанных в отладочном журнале 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, указанной в качестве хоста — источника аутентификации.
Событие 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.
При изменении пароля учетной записи компьютера в журнале событий 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 осуществляются на RPC-интерфейс MS-NRPC.
Трафик 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) (см. рисунок ниже).
server_auth = nrpc.hNetrServerAuthenticate3(
rpc_con,
'\\\\' + compname + '\\x00', #\\\\dc
compname + '$\\x00', #dc
nrpc.NETLOGON_SECURE_CHANNEL_TYPE.ServerSecureChannel, #6
compname + '\\x00', #dc
ciphertext, #00000000
flags #0x212fffff
)
Пример вызова функции hNetrServerAuthenticate3 с передаваемыми ей аргументами
Фрагмент дампа адресного пространства процесса lsass с артефактами после эксплуатации уязвимости Zerologon
На фрагменте исходного кода одного из эксплоитов и фрагменте дампа адресного пространства процесса 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.
YARA-правило, разработанное в ходе исследования, представлено ниже.
rule Zerologon_exploit
{
meta:
vulnerability = "CVE-2020-1472"
description = "Memory detection of Zerologon exploits"
reference = "<
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
>"reference = "<
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
>"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.