Что такое NTLM Relay? В прошлом посте разобрали Responder и увидели типичную цепочку:

LLMNR / NBT-NS
        ↓
Responder
        ↓
NTLM-аутентификация

Теперь следующий логичный вопрос:

Что происходит, если эти данные не подбирать, а попытаться использовать сразу?

Здесь и появляется NTLM Relay. 🔁 Что такое NTLM Relay? NTLM Relay — это техника, при которой атакующий не подбирает пароль, а перенаправляет NTLM-аутентификацию пользователя на другой сервер. Упрощённо:

Пользователь
   ↓
NTLM-аутентификация
   ↓
Атакующий
   ↓
Перенаправление
   ↓
Другой сервер

📌 Главное: пароль при этом может вообще не быть известен. Причём здесь SMB Signing? Если на SMB-сервере:

SMB Signing = Required

классический SMB Relay становится значительно сложнее. Если же:

SMB Signing = Enabled but not required

сервер может принимать неподписанные SMB-сессии, что создаёт условия для relay-атаки. Почему это опасно? Если перенаправить аутентификацию пользователя, у которого есть повышенные права на целевом сервере, атакующий может получить доступ с его привилегиями. Поэтому здесь сразу сходятся несколько тем:

NTLM
   ↓
Responder
   ↓
SMB Signing
   ↓
NTLM Relay
   ↓
Права пользователя

🛡 Как защищаться — требовать SMB Signing; — сокращать использование NTLM; — отключать LLMNR/NBT-NS там, где они не нужны; — использовать принцип минимальных привилегий; — не работать постоянно под административными учётными записями. 📌 Главная мысль

NTLM Relay — это не взлом пароля, а использование уже происходящей NTLM-аутентификации против другого сервиса.

#ntlm #ntlmrelay #smb #responder #windows #ad #pentest

🕵️ Что такое Responder? Когда начинают разбирать внутренний пентест Windows-сети, довольно быстро встречается инструмент Responder. Особенно часто он появляется рядом с такими понятиями: LLMNR → NBT-NS → mDNS → NTLM → Responder

📌 Responder — это инструмент для анализа небезопасных механизмов разрешения имён и NTLM-аутентификации внутри локальной сети.

Проще говоря, он помогает пентестеру проверить, может ли компьютер пользователя по ошибке обратиться не к тому устройству и попытаться передать ему данные для NTLM-аутентификации. 🧠 Откуда вообще появляется проблема? Представим ситуацию. Пользователь пытается открыть:

\\fileserver\docs

Но случайно вводит:

\\filesevrer\docs

DNS не знает такого имени. Windows может попытаться найти устройство другими способами, используя локальные механизмы разрешения имён, например: — LLMNR; — NBT-NS; — в некоторых сценариях mDNS. В сети появляется вопрос:

«Кто такой

filesevrer

?»

И если злоумышленник или пентестер находится в том же сетевом сегменте, он может попытаться ответить:

«Это я».

📌 Что происходит дальше Упрощённо схема выглядит так:

Пользователь
      ↓
Не может найти сервер через DNS
      ↓
LLMNR / NBT-NS запрос
      ↓
Responder отвечает
      ↓
Windows пытается выполнить NTLM-аутентификацию

Именно здесь появляется возможность обнаружить небезопасную передачу NTLM-аутентификационных данных. 💀 Почему это интересно пентестеру? Потому что такая ситуация показывает сразу несколько проблем инфраструктуры: — используются устаревшие механизмы разрешения имён; — рабочие станции доверяют ответам внутри локального сегмента; — используется NTLM; — отсутствует достаточная сегментация сети; — пользователи и сервисы могут автоматически инициировать аутентификацию. При внутреннем пентесте Responder часто помогает показать, насколько легко атакующий, уже оказавшийся внутри сети, может получить дополнительную информацию об учётных записях. 🔐 Responder не «ворует пароль напрямую» Это важный момент. Обычно речь идёт не о получении пароля пользователя в открытом виде. В NTLM-аутентификации используется механизм challenge-response. Упрощённо:

Сервер → challenge
Клиент → response

Поэтому пентестер получает данные, связанные с процессом NTLM-аутентификации, а не просто:

user:password

Дальше риск зависит от: — сложности пароля; — конфигурации сети; — настроек NTLM; — возможности дальнейшего relay-сценария. ⚔️ А причём здесь NTLM Relay? Вот здесь начинается самое интересное. Полученные NTLM-аутентификационные данные не всегда обязательно пытаться подбирать. В некоторых конфигурациях их можно попытаться перенаправить другому сервису. Это называется: NTLM Relay И здесь становится понятна наша предыдущая тема — SMB Signing. Цепочка начинает складываться:

LLMNR / NBT-NS
        ↓
Responder
        ↓
NTLM-аутентификация
        ↓
SMB Signing не требуется
        ↓
Возможность NTLM Relay

Поэтому все эти темы мы разбираем именно последовательно. 🔎 Что проверяет пентестер Во время аудита важно понять: — включены ли LLMNR и NBT-NS; — используется ли NTLM; — требуется ли SMB Signing; — какие устройства находятся в одном сетевом сегменте; — могут ли рабочие станции инициировать NTLM-аутентификацию к неизвестным узлам. Responder здесь выступает прежде всего как инструмент, позволяющий продемонстрировать последствия неправильной конфигурации. 🧠 Главная мысль Responder сам по себе не создаёт уязвимость. Он показывает уже существующую проблему:

компьютер не смог найти нужный ресурс, доверился ответу внутри локальной сети и попытался автоматически пройти NTLM-аутентификацию.

Именно поэтому Responder считается одним из классических инструментов внутреннего инфраструктурного пентеста. 📌 Наша цепочка теперь выглядит так:

SMB
 ↓
SMB Signing
 ↓
NTLM
 ↓
LLMNR / NBT-NS
 ↓
Responder
 ↓
NTLM Relay

#responder #ntlm #llmnr #smb #activedirectory #windows #pentest #infra