Что атакующий видит в первые два часа в вашей сети
На каждом втором внутреннем пентесте - одна и та же картина: LLMNR включён по умолчанию, LAPS либо не развёрнут, либо покрывает только рабочие станции, а расширенный аудит Kerberos не настроен. Три проблемы, которые дают атакующему перехватить хеши, вытянуть пароль локального администратора и двигаться по сети, не оставляя следов в логах. И всё это - в первые пару часов после попадания в периметр.
Это не теоретический обзор угроз. Это конкретный план действий, который пентестер или инженер ИБ пройдёт за один рабочий день: проверить состояние LLMNR/NBT-NS, убедиться в корректности развёртывания LAPS и настроить логирование так, чтобы blue team видела атаки, а не только стандартные логины. Всё - штатными средствами Windows, без покупки дорогих решений.
Аудит Active Directory безопасность - не проект на полгода с выделенным бюджетом. Большинство критических мисконфигураций проверяются за часы, а закрываются за дни. Покажу, куда именно смотреть и какие команды запускать - опираясь на реальную практику внутренних пентестов и данные первоисточников.
Русскоязычные руководства по аудиту AD обычно сводятся к перечислению Event ID и описанию GPO-политик в вакууме. Здесь всё иначе: каждая рекомендация привязана к конкретной атаке - вот что делает атакующий, вот как это выглядит в логах, вот как проверить и закрыть за минуты.
LLMNR poisoning атака: почему Responder работает в большинстве сетей
Механика LLMNR poisoning и роль Responder в AD
Когда пользователь обращается к сетевому ресурсу, Windows проходит цепочку разрешения имён. Сначала проверяет DNS-клиентский кеш (включая записи из файла hosts, которые загружаются в кеш), затем шлёт DNS-запрос к серверу. И только если DNS не может разрешить имя - включается LLMNR (Link-Local Multicast Name Resolution) на UDP-порт 5355, а за ним NBT-NS (NetBIOS Name Service) на UDP-порт 137. Эта последовательность описана в документации Microsoft и стабильно воспроизводится на практике.
Проблема: LLMNR и NBT-NS работают через широковещательные запросы в локальной сети. Любой хост в сегменте может ответить на такой запрос. И ни один из этих протоколов не имеет механизма аутентификации ответов. По данным TCM Security, отсутствие аутентификации - причина, по которой LLMNR остаётся одним из самых надёжных начальных векторов при пентесте AD.
На практике выглядит так: пользователь допускает опечатку в UNC-пути (например,
вместо
), DNS не может разрешить несуществующее имя, Windows отправляет LLMNR-запрос мультикастом. Атакующий с запущенным Responder отвечает: «Это я, подключайся». Жертва шлёт NTLM-хеш для аутентификации - и NetNTLMv2-хеш уже у атакующего, готовый к офлайн-бруту. В материалах HackTheBox по детектированию LLMNR-атак разбирают конкретный PCAP, где виден весь цикл: опечатка → LLMNR-запрос → ответ от Kali-машины → утечка хеша.
По классификации MITRE ATT&CK это техника LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001), тактики Credential Access и Collection.
Запуск атаки тривиален:
Код:
sudo responder -I eth0 -dwP
поднимает LLMNR/NBT-NS-отравитель с WPAD-прокси. После перехвата хеша атакующий забирает его в Hashcat:
Код:
hashcat -m 5600 hashes.txt wordlist.txt
(модуль 5600 - NetNTLMv2). Если парольная политика слабая - пароль вскрывается за минуты. По данным TCM Security, пароли типа «Password1» ломаются мгновенно.
Со стороны жертвы ничего подозрительного - ресурс «не открылся», пользователь исправляет опечатку и работает дальше. А хеш уже у атакующего. Именно поэтому Responder AD атака - стандартный первый шаг при внутреннем пентесте. Я ни разу не видел сеть, где Responder не собрал бы хотя бы пару хешей за первые 20 минут (если, конечно, LLMNR не отключён).
Как проверить и отключить LLMNR и NBT-NS
Требования к окружению: доступ к Group Policy Management Console (GPMC), права на редактирование GPO уровня домена или OU, PowerShell 5.1+ на целевых хостах.
Первый шаг - убедиться в текущем состоянии. На любом хосте в домене:
Код:
Код:
# Проверка LLMNR (0 = отключён, отсутствие ключа = включён)
Get-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" `
-Name EnableMulticast -ErrorAction SilentlyContinue
# Проверка NBT-NS (2 = отключён, 0 или 1 = активен)
wmic nicconfig get caption,index,TcpipNetbiosOptions
Если ключ
отсутствует или равен 1 - LLMNR активен. Если
возвращает 0 или 1 - NBT-NS активен. В обоих случаях сеть открыта для Responder.
Отключение LLMNR - через GPO:
Код:
Computer Configuration > Administrative Templates > Network > DNS Client
, параметр «Turn OFF Multicast Name Resolution» - установить в «Enabled». Основная рекомендация, подтверждённая TCM Security и HackTheBox.
Для NBT-NS встроенного параметра GPO нет. Используют PowerShell-скрипт в Startup Scripts (
Код:
Computer Configuration > Policies > Windows Settings > Scripts > Startup
):
Код:
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces\tcpip* -Name NetbiosOptions -Value 2
После применения политик -
на целевых хостах и повторная проверка. Значение
и
Код:
TcpipNetbiosOptions = 2
подтверждают успешное отключение. Чтобы убедиться окончательно, запустите Responder в режиме анализа (без флага
) и проверьте, что хеши больше не прилетают.
LAPS пентест: слабости, которые атакующий находит первыми
Проверка развёртывания LAPS при аудите Active Directory
LAPS (Local Administrator Password Solution) решает конкретную проблему: одинаковый пароль локального администратора на всех машинах домена. Без LAPS компрометация одного хоста означает доступ ко всем остальным через Pass-the-Hash - один хеш открывает lateral movement по всей сети.
Legacy LAPS генерирует уникальный пароль для каждого компьютера и хранит его в атрибутах объекта компьютера в AD:
(пароль в открытом тексте, доступный только субъектам с правом CONTROL_ACCESS / All Extended Rights на OU - обычно Domain Admins и явно делегированные группы) и
Код:
ms-mcs-AdmPwdExpirationTime
(время истечения). С 2023 года Microsoft выпустила Windows LAPS (встроен в Windows 10/11 и Server 2019+), который использует другие атрибуты:
,
Код:
msLAPS-PasswordExpirationTime
и
Код:
msLAPS-EncryptedPassword
(с поддержкой шифрования паролей в AD). При аудите проверяйте оба набора атрибутов - в реальных средах часто живут обе версии одновременно. По данным SentinelOne, контроль доступа к этим атрибутам - ключевой аспект безопасности LAPS.
Проверка покрытия LAPS - первое, что делает пентестер после получения доменной учётки:
Код:
Код:
# Компьютеры с ротацией LAPS (Legacy или Windows LAPS)
$withLAPS = Get-ADComputer -Filter * `
-Properties ms-Mcs-AdmPwdExpirationTime, msLAPS-PasswordExpirationTime |
Where-Object { $_.'ms-Mcs-AdmPwdExpirationTime' -ne $null -or `
$_.'msLAPS-PasswordExpirationTime' -ne $null }
$all = Get-ADComputer -Filter *
Write-Host "LAPS: $($withLAPS.Count) / $($all.Count)"
# В средах с Windows LAPS (2023+) заполнен только msLAPS-*
Разница между числами - машины без LAPS. На практике вижу это регулярно: LAPS развёрнут на рабочих станциях, а серверы - файловые, серверы приложений, SQL-серверы - остались без покрытия. Угадайте, куда атакующий мигрирует в первую очередь? Туда, где один хеш локального администратора открывает всю серверную ферму.
Слабые пароли Active Directory через мисконфигурацию LAPS
Даже при развёрнутом LAPS три мисконфигурации делают его бесполезным. Эти риски описаны в исследовании SentinelOne по оценке уязвимостей LAPS.
Избыточные права на чтение
. По умолчанию пароль доступен только Domain Admins. Но администраторы часто делегируют права чтения сервисным учёткам или группам helpdesk - «чтобы ребята могли быстро заходить на машины». Атакующий перечисляет ACL на компьютерных объектах и находит учётки с правом «All Extended Rights» - этого достаточно для чтения пароля в открытом виде. Проверяйте делегирование командой
Код:
Find-AdmPwdExtendedRights -Identity "OU=Workstations,DC=corp,DC=local"
из модуля
- вывод покажет, кому конкретно делегированы права. В NetExec (преемник архивированного CrackMapExec) ещё проще:
Код:
nxc ldap dc01 -u user -p pass -M laps
- модуль перечислит все пароли, доступные текущей учётке.
Подмена AdmPwd.dll. LAPS использует клиентскую библиотеку
Код:
c:\program files\LAPS\CSE\AdmPwd.dll
для ротации паролей. Атакующий с локальным доступом может подменить DLL на модифицированную версию, перехватывающую пароли при каждой ротации. Защита - периодическая проверка хеша и подписи:
Код:
Get-FileHash 'c:\program files\LAPS\CSE\AdmPwd.dll'
и
Код:
Get-AuthenticodeSignature 'c:\program files\LAPS\CSE\AdmPwd.dll'
. Если подпись недействительна - DLL скомпрометирована.
Модификация searchFlags атрибута
. Значение searchFlags контролирует конфиденциальность атрибута. Флаг CONFIDENTIAL - бит 0x80 (128) в searchFlags. Атакующий с правами на схему может снять этот бит, убрав защиту, после чего любой аутентифицированный пользователь прочитает все пароли LAPS. Конкретное абсолютное значение searchFlags зависит от версии схемы, поэтому проверяйте именно наличие бита 0x80:
Код:
$sf = (Get-ADObject "CN=ms-Mcs-AdmPwd,CN=Schema,CN=Configuration,DC=corp,DC=local" -Properties searchFlags).searchFlags; if ($sf -band 128) { 'CONFIDENTIAL set' } else { 'CONFIDENTIAL missing!' }
.
Рекомендация Microsoft - удалить право «All Extended Rights» с OU, содержащих компьютеры с LAPS: Active Directory Users and Computers → правый клик на OU → Properties → вкладка Security → Advanced → снять галочку «All Extended Rights» для ненужных групп.
Настройка логирования AD: что вы не видите в Windows Event Log
Критические Event ID для обнаружения lateral movement
Большинство компаний, которые я тестирую, имеют включённый базовый аудит - Event ID 4625 (неуспешный вход) и 4624 (успешный вход). Этого категорически мало: базовый аудит не покрывает Kerberoasting, AS-REP Roasting, DCSync и Pass-the-Ticket - основные техники пентестера после попадания в домен. По сути, вы смотрите в замочную скважину, когда атакующий заходит через окно.
Вот события, которые реально нужны для обнаружения атак на Active Directory:
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом
One Level или выше
Получить доступ просто — достаточно проявить активность на форуме
AD базовая гигиена: пентест Active Directory за один рабочий день
Ниже - пошаговый чеклист, который покрывает три критических вектора за восемь часов. Приоритеты расставлены по критичности: сначала закрываем то, что атакующий эксплуатирует в первый час.
Часы 1-2: LLMNR и NBT-NS- Проверить состояние LLMNR на выборке хостов (запрос к реестру
Код:
HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient
, ключ
).
- Проверить состояние NBT-NS через
Код:
wmic nicconfig get caption,index,TcpipNetbiosOptions
.
- Создать или обновить GPO: «Turn OFF Multicast Name Resolution» = Enabled.
- Добавить PowerShell-скрипт отключения NBT-NS в Startup Scripts.
- Протестировать: на хосте, получившем политику, запустить Responder в режиме анализа - хеши не должны прилетать.
Часы 3-4: LAPS- Посчитать покрытие LAPS: количество компьютеров с заполненным
Код:
ms-mcs-AdmPwdExpirationTime
относительно общего числа.
- Проверить делегирование прав на чтение
через
Код:
Find-AdmPwdExtendedRights
по каждой OU.
- Убедиться, что серверы покрыты LAPS, а не только рабочие станции.
- Проверить параметры парольной политики LAPS в GPO: длина не менее 20 символов, максимальный срок действия не более 30 дней.
- На выборке хостов проверить целостность
через
Код:
Get-AuthenticodeSignature
.
Часы 5-6: Аудит и логирование- На контроллере домена выполнить
Код:
auditpol /get /category:*
и зафиксировать текущее состояние.
- Включить расширенный аудит Kerberos (Authentication Service, Service Ticket Operations) на Success и Failure.
- Включить аудит Credential Validation для детекции NTLM-атак.
- Включить аудит DS Access и DS Changes.
- Настроить SACL на корневом объекте домена: добавить аудит-записи для Everyone на extended rights DS-Replication-Get-Changes (
Код:
1131f6aa-9c07-11d1-f79f-00c04fc2dcd2
) и DS-Replication-Get-Changes-All (
Код:
1131f6ad-9c07-11d1-f79f-00c04fc2dcd2
) - без этих конкретных GUID в SACL Event ID 4662 не зафиксирует DCSync. В SIEM исключайте события от компьютерных учёток DC$ (легитимная репликация), чтобы не утонуть в ложных срабатываниях.
Часы 7-8: Верификация и документирование- Дождаться применения политик (
на контроллерах и выборке хостов).
- Убедиться, что Event ID 4768 и 4769 появляются в Security Log контроллера домена при обычных аутентификациях.
- Выполнить тестовый запрос TGS через
из Impacket - проверить, что событие 4769 зафиксировано с корректными полями (имя учётки, запрошенный SPN, IP источника).
- Задокументировать все находки: что было, что изменили, что осталось.
- Составить remediation-план с приоритетами для изменений, требующих change management.
Этот чеклист не заменяет полноценный пентест Active Directory - он закрывает три самых критичных вектора первого часа атаки. После его прохождения сеть перестаёт быть лёгкой добычей для Responder, lateral movement через одинаковые локальные пароли и необнаруженных DCSync-операций. Для глубокого аудита останутся проверки Kerberos-делегирования, ACL на объектах AD, привилегированных учётных записей и доверительных отношений между доменами - но это задача на вторую неделю.
Вопрос к читателям
После отключения LLMNR через GPO часть легаси-приложений теряет связность - особенно те, которые обращаются к хостам по коротким именам без DNS-суффикса. У кого при установке «Turn OFF Multicast Name Resolution» в Enabled ломалось что-то на продуктиве, кроме самописных скриптов с хардкодом NetBIOS-имён? Какой DNS Suffix Search List в GPO по пути
Код:
Computer Configuration > Administrative Templates > Network > DNS Client > DNS Suffix Search List
решил проблему в вашей среде - один суффикс корневого домена или полный список с дочерними зонами? Покажите строку конфига - интересно сравнить подходы в средах с разным количеством доменов в лесу.
Линейный вид
