Как защитить контроллеры домена и центр сертификации от атак PetitPotam NTLM Relay

Содержание

Что такое PetitPotam
Схема атаки PetitPotam
Защита контроллера домена
Отключение фильтров [MS-ESFR] (EFSRPC) на контроллере домена через GPO
Защита центра сертификации
Настройка на стороне IIS
Включение Negotiate:Kerberos для Windows Authentication
Дополнительные ссылки

PetitPotam NTLM Relay

Добрый день! Уважаемые гости блога. В сегодняшнем посте хочу продолжить ранее начатый цикл статей посвященный улучшению информационной безопасности в вашем домене, ранее мы уже отключили протокол LLMNR и устранили уязвимость ASLR. В это статье я буду выражаться непонятным и странным словом PetitPotam, поговорим про тип атак NTLM Relay. Самое главное применим рекомендации к вашим контроллерам домена и центрам сертификации. Эти простые шаги помогут хоть немного, но улучшить защиту вашей инфраструктуры.

Что такое PetitPotam

PetitPotam — это серьезная уязвимость в операционных системах Windows, обнаруженная в июле 2021 года французским исследователем безопасности Жилем Лионелем (известным как Topotam). Эта атака позволяет злоумышленнику с доступом к внутренней сети заставить контроллер домена аутентифицироваться на подконтрольном атакующему сервере, что может привести к полному компрометированию домена Active Directory.

Особенность PetitPotam заключается в том, что она не требует от атакующего наличия учетных данных и может быть использована для принудительной аутентификации критически важных серверов, таких как контроллеры домена. В сочетании с атаками NTLM Relay это создает мощный вектор для эскалации привилегий в корпоративной среде.

PetitPotam использует протокол MS-EFSRPC (Microsoft Encrypting File System Remote Protocol), который предназначен для удаленного управления зашифрованными данными. Конкретно атака направлена на метод EfsRpcOpenFileRaw, который отвечает за открытие и восстановление зашифрованных объектов

Когда атакующий отправляет специально сформированный запрос к интерфейсу MS-EFSRPC уязвимой системы, он может заставить целевой хост (включая контроллер домена) инициировать процесс аутентификации по протоколу NTLM на сервере, контролируемом злоумышленником. В результате атакующий получает NTLM-хэш учетной записи компьютера, который затем может быть использован для дальнейших атак.

Схема атаки PetitPotam

Инициация аутентификации: Атакующий с помощью скрипта PetitPotam отправляет запрос к уязвимому хосту (например, контроллеру домена), принуждая его аутентифицироваться на машине атакующего.
Перехват NTLM-хэша: Атакующий перехватывает NTLM-хэш учетной записи компьютера.
Ретрансляция NTLM (NTLM Relay): Перехваченный хэш ретранслируется на другой сервер в домене, чаще всего на сервер служб сертификации Active Directory (AD CS).
Получение сертификата: В случае успешной ретрансляции атакующий получает цифровой сертификат, который можно использовать для аутентификации в домене.
Эскалация привилегий: С помощью полученного сертификата атакующий запрашивает TGT-билет Kerberos и получает доступ к критически важным ресурсам домена

Более детально про этапы читайте по ссылке - https://habr.com/ru/companies/deiteriylab/articles/581758/

Защита контроллера домена

Наша задача создать специальные RDC фильтры, которые будут блокировать EFSRPC, используемой PetitPotam. Напомню, это RPC Interface UUID "{c681d488-d850-11d0-8c52-00c04fd90f7e}" и "{df1941c5-fe89-4e79-bf10-463657acf44d}". Сначала покажу точечный ручной подход. Создайте текстовый файл с именем block_efsr.txt и содержимым:

rpc
filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
quit

Далее запускаем командную строку в режиме администратора и выполняем команду:

cd c:\temp (Тут я перехожу в папку, где у меня лежит данный файл, но можно и в одну команду netsh -f "c:\temp\block_efsr.txt")
netsh -f block_efsr.txt

В результате вы должны увидеть примененных два фильтра "FilterKey: 98db55a9-9893-11f0-b83e-002590649371" и "FilterKey: 98db55aa-9893-11f0-b83e-002590649371Э

Давайте проверим, что данные фильтры появились, для этого введите команду:

netsh rpc filter show filter

Если вдруг вам потребуется восстановить настройки по умолчанию и удалить все фильтры, это можно будет сделать командой:

netsh rpc filter delete filter filterkey=

Если хотите удалить определенный фильтр, то допишите его filterkey, например

netsh rpc filter delete filter filterkey=36956c5c-98e9-11f0-9ac5-000c295de3a3

Следующим, но очень долгим шагом будет, это отключение NTLM трафика на контроллерах домена. Как это делать читайте по ссылке.

На промежуточном этапе, хотя бы выключите NTLmv1 и LM трафик, сделать это можно в разделе:

Computer Configuration - Polices - Windows Settings - Local Polices - Security Options (Конфигурация компьютера - Политики - Конфигурация Windows - Параметры безопасности - Локальные политики - Параметры Безопасности)

Network security: Do not store LAN Manager hash value on next password change (Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля) - Enabled (Включено)
Network security: LAN Manager authentication level (Сетевая безопасность: уровень проверки подлинности LAN Manager) - Send NTLMv2 response only. Refuse LM & NTLM (Отправлять только NTLMv2-ответ. Отказывать LM и NTLM)

Отключение фильтров [MS-ESFR] (EFSRPC) на контроллере домена через GPO

Так же по-хорошему, чтобы эти фильтры не потерлись лучше сделать отдельную политику или политику в автозапуске, чтобы данные фильтры добавлялись с GPO. Для этого можно использовать простенький PowerShell скрипт.

Как запускать данный скрипт через групповую политику я описывал.

# Создание временного файла с командами для netsh
$tempFile = Join-Path $env:TEMP "block_efsr.txt"
# Содержимое файла с правилами фильтрации RPC
@"
rpc
filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=c681d488-d850-11d0-8c52-00c04fd90f7e
add filter
add rule layer=um actiontype=block
add condition field=if_uuid matchtype=equal data=df1941c5-fe89-4e79-bf10-463657acf44d
add filter
quit
"@ | Out-File -FilePath $tempFile -Encoding ASCII
# Выполнение команды netsh с созданным файлом
try {
netsh -f $tempFile
Write-Host "Фильтры EFSRPC успешно заблокированы" -ForegroundColor Green
}
catch {
Write-Error "Ошибка при выполнении команды netsh: $_"
}
# Удаление временного файла
Remove-Item $tempFile -Force -ErrorAction SilentlyContinue

Защита центра сертификации

Первое, что вы должны сделать для Центра сертификации, это полностью запретить входящий NTLM трафик. Делать это лучше всего и правильнее с помощью групповой политики.

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

В созданной политике перейдите:

Computer Configuration - Polices - Windows Settings - Local Polices - Security Options - Network security: Restrict NTLM: Incoming NTLM traffic (Конфигурация компьютера - Политики - Конфигурация Windows - Параметры безопасности - Локальные политики - Параметры Безопасности - Сетевая безопасность: ограничения NTLM: входящий трафик NTLM)

Выставляем там значение "Deny all accounts (Запретить все учетные записи)".

Настройка на стороне IIS

По рекомендации Microsoft на IIS у ваших центров сертификации нужно включить механизм EPA и перевести сайт на HTTPS.

Основная угроза, от которой защищает EPA, — это атаки пересылки (relay attacks). Злоумышленник может перехватить сетевой трафик аутентификации и переслать его на сервер, выдавая себя за легитимного пользователя

EPA решает эту проблему с помощью двух ключевых механизмов:

Привязка канала (Channel Binding): Криптографически связывает ключ сеанса протокола аутентификации (Kerberos/NTLM) с ключом сеанса TLS-соединения. Сервер проверяет эту привязку, что гарантирует: клиент, прошедший аутентификацию, является тем же самым, что установил безопасное TLS-соединение.
Привязка службы (Service Binding): Служит дополнительной мерой защиты. Сервер проверяет, что имя службы, для которой клиент запросил аутентификацию, соответствует имени, указанному в сертификате сервера TLS. Это помогает предотвратить атаки, когда злоумышленник перенаправляет трафик на неправильную службу.

В IIS находим у сайта подраздел заканчивающийся на _CES_Kerberos и выбираем раздел "Authentication".

Убедитесь, что у вас отключена Anonymous Authentication. Выберите Windows Authentication и перейдите в "Advanced Settings".

В "Extended Protection" выберите "Required" - Все клиенты обязаны предоставлять сведения о привязке канала; запросы от клиентов без EPA отклоняются (максимальная защита)

Сделав эту настройку вы изменили конфигурационный файл web.config по пути:

C:\Windows\systemdata\CES\Ваш_ICA_CES_Kerberos

Там будет добавлен код:

<transport clientCredentialType="Windows">
<extendedProtectionPolicy policyEnforcement="Always" />
</transport>

Теперь открываем подраздел сайта CertSrv настройка "SSL Settings"

Включаем галку Require SSL и "Client certificates" со значением "Ignore".

Для _CES_Kerberos можно так же сделать Require SSL

Далее обязательно перезапустите службу IIS. В командной строке введите:

iisreset /restart

Включение Negotiate:Kerberos для Windows Authentication

Для CertSrv и _CES_Kerberos в настройках Windows Authentication выберите в провайдерах Negotiate:Kerberos.

Удалите "Negotiate" и добавьте "Negotiate:Kerberos".

Если выскочит ошибка "The following Negotiable 2 based providers cannot be used when kernel mode authentication is enabled"

Отключите галку:

Enable Kernel-mode authentication

Так же перезапускаем IIS

1️⃣Эти действия позволят избежать атак Petitpotam

✅Частично для данных сервисов да, но это не означает, что нет других лазеек

2️⃣Что еще можно предпринять для защиты от PetitPotam

✅Самое главное, это по возможности полностью уйти от NTLM трафика. Но это сложно, так что начинайте поэтапно, главное на DC включите аудит NTLM, оно поможет вам в этом направлении.

3️⃣Применимы ли данные настройки для рабочих станций с Windows 11

✅Microsoft в целом в будущих релизах хочет полностью запретить использование NTLM по умолчанию, в пользу Kerberos, так что да RPC фильтры применимы и будут полезны

На этом все. Это то, что вы можете сделать для уменьшения фронта атак NTLM Relay. По-хорошему постарайтесь полностью отключить NTLM трафик в вашем домене, это будет хороший шаг к усилению информационной безопасности инфраструктуры.

Дополнительные ссылки

https://posts.specterops.io/certified-pre-owned-d95910965cd2

https://kb.cert.org/vuls/id/405600

https://support.microsoft.com/en-us/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429