## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-DEPTHSECURITY-RELAYKING-DEPTH
# RelayKing v1.10
### Властвуйте над доменом. Релейте к королевскому статусу.
**RelayKing** — это комплексный инструмент для обнаружения и инвентаризации ретрансляционных атак, предназначенный для выявления возможностей ретрансляции NTLM в средах Active Directory. Реальные возможности построения отчетов. Широкое покрытие атак. Находите скрытые векторы ретрансляции и формируйте отчеты в нужном формате. Передавайте в ntlmrelayx.py от Impacket тщательно подобранный список целей (обнаруженных, доступных для ретрансляции узлов). Больше никогда не пропускайте критически важный, эксплуатируемый путь NTLM-ретрансляции в домене.
## Блог/Рекомендуемое чтение:
Подробнее см. в соответствующей статье на сайте Depth Security: https://www.depthsecurity.com/blog/introducing-relayking-relay-to-royalty/
## Содержание
* Блог/Рекомендуемое чтение
* Прочтите перед использованием
* Соображения OPSEC
* Возможности
* Обнаружение протоколов
* Расширенное обнаружение
* Анализ путей ретрансляции
* Параметры целеуказания
* Форматы вывода
* Прочие возможности
* Установка
* Использование
* Параметры командной строки
* Примеры
* Примечания по функциональности
* Производительность
* Группировка
* Примечания по поведению функций
* Запланировано
* Известные ошибки/ограничения
* Отправка проблем/Pull Request
* Проблемы
* Pull Request
* Благодарности
* Отказ от ответственности
* Лицензия
## ПРОЧТИТЕ ПЕРЕД ИСПОЛЬЗОВАНИЕМ:
### СООБРАЖЕНИЯ OPSEC:
**RelayKing НЕ ЯВЛЯЕТСЯ OPSEC-БЕЗОПАСНЫМ ИНСТРУМЕНТОМ В ОПРЕДЕЛЁННЫХ РЕЖИМАХ, ОСОБЕННО В РЕЖИМЕ `--audit`. **RelayKing предоставляется КАК ЕСТЬ, БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ. См. нижнюю часть readme.**
## Установка
root@kitploit:~
# Используйте venv. Избавьте себя от лишних хлопот.
# Клонируйте репозиторий:
git clone https://github.com/depthsecurity/RelayKing-Depth.git
# Перейдите в клонированную директорию:
cd RelayKing-Depth/
# Настройте виртуальное окружение Python:
virtualenv --python=python3 .
source bin/activate
# Установите зависимости:
pip3 install -r requirements.txt
# Проверьте успешность установки RelayKing:
python3 relayking.py -h
### Обнаружение протоколов
* **SMB/SMB2/SMB3** : Требования к подписи, привязка канала, определение версии _(не требует аутентификации)_
* **HTTP/HTTPS** : Принудительное применение EPA/CBT _(требуется аутентификация для надёжной проверки HTTPS)_
* **LDAP/LDAPS** : Требования к подписи, привязка канала _(требуется аутентификация для надёжной проверки CBT на LDAPS)_
* **MSSQL** : Применение EPA _(требуется аутентификация для надёжной проверки)_
* **RPC** : Инвентаризация конечных точек MS-RPC, требования к аутентификации _(требуется аутентификация для надёжной проверки)_
* **WINRM/WINRMS** : WS-Management, применение EPA, привязка канала _(аутентифицированная проверка)_ (**WIP**)
* **SMTP** : Обнаружение аутентификации NTLM, поддержка STARTTLS (**WIP**)
* **IMAP/IMAPS** : Аутентификация NTLM, зашифрованный доступ к почте (**WIP**)
### Расширенное обнаружение
* **Отражение NTLM** : Определяет узлы, уязвимые для атак отражения NTLM (CVE-2025-33073)
* **CVE-2025-54918** : Обнаруживает незапатченные узлы Windows Server 2025, уязвимые для отражения NTLM через принуждение PrintSpooler по RPC к LDAPS. Сообщается как MEDIUM на любом незапатченном сервере 2025; повышается до CRITICAL, если узел является контроллером домена с включённым PrintSpooler. Проверяется через UBR (Update Build Revision), запрашиваемый из реестра.
* **CVE-2019-1040 (Drop the MIC)** : Обнаруживает узлы с UBR ниже порога июньского патча 2019 года, что позволяет удалять поле MIC для межпротокольной ретрансляции (SMB в LDAP/LDAPS) с помощью `--remove-mic` в ntlmrelayx. Сообщается как HIGH. Использует уже запрошенный для каждого узла UBR, без дополнительных сетевых запросов.
* **Обнаружение Ghost SPN** : В режиме `--audit` запрашивает Active Directory для поиска Service Principal Names, имена хостов которых не имеют DNS-записи. Злоумышленник может зарегистрировать отсутствующее DNS-имя, чтобы перехватить аутентификацию NTLM, предназначенную для этого субъекта службы. Результаты делятся на _уязвимые_ (вообще нет DNS-записи) и _вероятно уязвимые_ (разрешаются только через подстановочный DNS). Сообщается как MEDIUM. Полные результаты записываются в `possible-ghost-spns.txt`. Подавить с помощью `--no-ghosts`.
* **WebDAV/WebClient** : Обнаруживает узлы с запущенной службой WebDAV WebClient
* **Поддержка NTLMv1** : Проверяет поддержку аутентификации NTLMv1 (индивидуально или на уровне GPO)
* **Уязвимости принуждения** : Обнаруживает неаутентифицированные (если указано) PetitPotam, PrinterBug, DFSCoerce
### Анализ путей ретрансляции
* Автоматически выявляет жизнеспособные пути атак через ретрансляцию (функционирует, требует доработки)
* Приоритизирует пути по степени воздействия (critical, high, medium, low)
* Обнаружение межпротокольной ретрансляции (требует `--ntlmv1` или `--ntlmv1-all` — межпротокольное обнаружение только при подтверждённом использовании Net-NTLMv1)
* Пути отражения NTLM (включая пути с частичным удалением MIC/межпротокольной ретрансляцией)
* Пути CVE-2025-54918: MEDIUM на любом незапатченном сервере 2025, CRITICAL на незапатченном DC с включённым PrintSpooler
* Пути CVE-2019-1040: HIGH, межпротокольная ретрансляция SMB-в-LDAP через удаление MIC (`--remove-mic`)
* Пути Ghost SPN: MEDIUM, до 5 отображается в отчёте, полный вывод в `possible-ghost-spns.txt`
* Логика оценки серьёзности находится в разработке, присылайте PR для улучшений! В настоящее время учтены не все ситуации/сценарии — цель состоит в том, чтобы охватить все возможные примитивы.
### Параметры целеуказания
* **Аудит Active Directory`(--audit)`**: Получение списка всех компьютеров из AD через LDAP. Требуются учётные данные с минимальными привилегиями AD и _работающий DNS_ в среде. Принудительно с помощью `--dc-ip` или правки `/etc/resolv.conf`.
* **Ввод из файла** : Загрузить цели из текстового файла
* **CIDR-нотация** : Сканирование целых подсетей (например, `10.0.0.0/24`)
* **Диапазоны IP** : Сканирование диапазонов IP (например, `10.0.0.1-254`)
* **Отдельные узлы** : Нацеливание на конкретные узлы или FQDN (`python3 relayking.py -u blah -p pass -d domain.local <ваш_целевой_ip_или_имя_узла>`)
### Форматы вывода
* **Простой текст** : Удобочитаемый вывод с подробными результатами
* **JSON** : Структурированные данные для программного анализа
* **XML** : Иерархический формат данных
* **CSV** : Формат, совместимый с электронными таблицами
* **Grep-able** : Одна строка на результат для лёгкого парсинга
* **Markdown** : Формат, готовый для документации
### Прочие возможности
* **Массовое принуждение** : `--coerce-all` в сочетании с `--audit` и учётными данными с низкими привилегиями для принуждения КАЖДОЙ машины домена к массовой ретрансляции учётных записей компьютеров. Чрезвычайно полезно в средах с включённым Net-NTLMv1.
* **Обнаружение Net-NTLMv1** : `--ntlmv1` или `--ntlmv1-all` для обнаружения GPO LanMan на уровне домена. `--ntlmv1-all` проверяет ВСЕ узлы из AD и их значения реестра через RemoteRegistry. **(требуются права локального администратора)**.
* **Генерация списка ретрансляции** : `--gen-relay-list <файл>` для создания файла целей, готового к импорту в ntlmrelayx.py с ключом `-tf`.
* **Проверка Ghost SPN** : Автоматически выполняется в режиме `--audit` при наличии учётных данных. Подавить с помощью `--no-ghosts`. Полные результаты записываются в `possible-ghost-spns.txt` вместе с основным отчётом; в самом отчёте отображаются первые 5, чтобы избежать загромождения.
* **Гибкая аутентификация Kerberos** : Аутентификация Kerberos через (и FQDN для ) должна работать достаточно хорошо. Если в среде есть контроллеры домена, на которых NTLM полностью отключён, но терпим везде, можно использовать , чтобы он не мешал проверкам. Также доступны и для работы через прокси SOCKS/другие тунели. В этом сценарии даже Kerberos работает довольно легко.
## Использование
#### Вывод аргументов командной строки/использования с помощью `-h`, как и ожидается:
root@kitploit:~
python3 relayking.py -h
### Примеры
#### Рекомендуемые флаги для полного покрытия сети + вывод отчёта в простой текст и JSON:
root@kitploit:~
python3 relayking.py -u 'lowpriv' -p 'lowpriv-password' -d client.domain.local --dc-ip 10.0.0.1 -vv --audit --protocols smb,ldap,ldaps,mssql,http,https --threads 10 -o plaintext,json --output-file relayking-scan --proto-portscan --ntlmv1 --gen-relay-list relaytargets.txt
#### Облегчённая аутентифицированная проверка без HTTP(S) + вывод отчёта в простой текст и JSON:
root@kitploit:~
python3 relayking.py -u 'lowpriv' -p 'lowpriv-password' -d client.domain.local --dc-ip 10.0.0.1 -vv --audit --protocols smb,ldap,ldaps,mssql -o plaintext,json --output-file relayking-scan --proto-portscan --gen-relay-list relaytargets.txt
#### Аутентифицированная проверка одной цели (единичная цель = позиционный, последний аргумент) + вывод отчёта ТОЛЬКО на stdout в простой текст:
root@kitploit:~
python3 relayking.py -u 'lowpriv' -p 'lowpriv-password' -d client.domain.local -vv --protocols smb,ldap,ldaps,mssql,http,https -o plaintext SERVER1-EXAMPLE.LAB.LOCAL
#### Неаутентифицированное сканирование с CIDR-диапазоном в качестве цели + без файла отчёта/stdout только в простой текст:
root@kitploit:~
python3 relayking.py --null-auth -vv --protocols smb,ldap,http -o plaintext 10.0.0.0/24
#### Полный аудит, проверка ВСЕХ узлов на Net-NTLMv1 через RemoteRegistry (ТЯЖЁЛО):
root@kitploit:~
python3 relayking.py -u 'lowpriv' -p 'lowpriv-password' -d client.domain.local --dc-ip 10.0.0.1 -vv --audit --protocols smb,ldap,ldaps,mssql,http,https --threads 10 -o plaintext,json --output-file relayking-scan --proto-portscan --ntlmv1-all --gen-relay-list relaytargets.txt
## Примечания по функциональности:
### Производительность
* По умолчанию используется 10 основных потоков сканера/заданий, задаются с помощью `--threads`. Каждый основной поток получает рабочие потоки для определённых задач под собой. Например, HTTP использует 20 потоков на один основной поток. В результате открывается ~200 потоков HTTP для сканирования аутентификации NTLM на HTTP. В большинстве случаев это достаточно хорошо переносится, но если вызывает задержки/проблемы с сетью, уменьшите количество потоков. По умолчанию 10 потоков в любом случае работают исключительно быстро.
* Вероятно, вы почти всегда захотите использовать `--proto-portscan` со всеми сканированиями. Это значительно повышает производительность и предотвращает ожидание сканером таймаутов на портах, которых на самом деле нет. Если это вызывает проблемы, вы можете удалить этот флаг в ущерб производительности сканирования (но этого не должно происходить!).
### Группировка
* Сканирование может проводиться с группировкой путём разделения узлов на группы. Опции `--max-scangroup`, `--split-into` и `--skip` могут использоваться для управления группировкой.
* Вы можете указать `--max-scangroup`, чтобы задать количество целей для каждой группы. Например, `--max-scangroup 100` разобьёт 299 целей на 3 группы. Группы будут содержать по 100, 100 и 99 целей соответственно.
* Вы можете указать `--split-into`, чтобы задать количество групп. Например, `--split-into 3` разобьёт 299 целей на 3 группы. Группы будут содержать по 100, 100 и 99 целей. Нельзя указывать одновременно `--max-scangroup` и `--split-into`.
* Вы можете указать `--skip`, чтобы пропустить группы. Например, `--max-scangroup 3 --skip 1` разобьёт 299 целей на 3 группы по 100, 100 и 99 целей, а затем пропустит первую группу и начнёт сканирование со второй. Это помогает при необходимости перезапустить инструмент.
### Примечания по поведению функций:
* `--ntlmv1` или `--ntlmv1-all`: Добавление `--ntlmv1` извлекает все GPO LanMan для домена и ничего больше. Требуются учётные данные AD с низкими привилегиями. `--ntlmv1-all` требует учётные данные администратора и проверяет **каждый отдельный узел в домене** с открытым SMB на ключ реестра LMCompatibilityLevel. Запуск хотя бы `--ntlmv1` **необходим для отображения/обнаружения межпротокольных путей ретрансляции SMB**.
* Отключённый удалённый реестр может вызвать проблемы с `--ntlmv1-all`. Также очень тяжело и небезопасно с точки зрения OPSEC, но тщательно. Вероятно, не рекомендуется, если вы не действуете по принципу «всё или ничего» или отчаянно.
* **Вывод в различных форматах**. Указание форматов через запятую (`-o json,plaintext`) и `--output-file relayking-scan` создаёт файлы relayking-scan.json + relayking-scan.txt, поэтому нет необходимости запускать дважды для нескольких форматов. Доступны: `plaintext, json, xml, csv, grep, markdown` (**по умолчанию: plaintext**)
* Функциональность `--coerce-all` будет использовать PetitPotam, DFSCoerce и PrinterBug на ВСЕХ ЦЕЛЕВЫХ УЗЛАХ. Она также массово принуждает каждую машину в домене без выполнения полного аудита протоколов. Одновременное указание \+ приведёт к доменному аудиту массовому принуждению. ()
## Запланировано
* Гораздо больше тестирования (ВЫ МОЖЕТЕ ПОМОЧЬ)
* Дроппер для файлов принуждения + очистка. (Требует определённых возможностей — обращайтесь напрямую, если хотите добавить это)
* Создание вики по использованию
* Ретрансляция Kerberos + пути. Создание логики, охватывающей все техники Kerberos-ретрансляции, включая отражение.
* Потенциальный режим `--opsec-safe`, который избегает использования Impacket/других библиотек Python с характерными сигнатурами. Реализовать нетривиально.
## ИЗВЕСТНЫЕ ПРОБЛЕМЫ
* Из-за множества вспомогательных инструментов и функций, которые сами запрашивают LDAPS, возникла ЧРЕЗВЫЧАЙНО БЕЗУМНАЯ логика: они не консолидированы, и каждый делает что-то своё. В настоящее время, как я считаю, `--ntlmv1`, валидатор учётных данных, модуль Ghost SPN и анализатор целей — все делают свою аутентификацию по-своему. ЭТО АБСОЛЮТНО НЕЛЕПО и требует консолидации для использования одного модуля аутентификации.
* Вероятно, дополнительные глупые причуды с различными комбинациями подписи LDAP и привязки канала.
* Серьёзные проблемы с RPC на новейших сборках Server 2025/Win11. Требует исправления.
* Глупые граничные случаи с сервисами HTTP(S), которые трудно учесть, дающие ложноположительные/ложноотрицательные результаты.
## Отправка проблем/Pull Request
### Проблемы
* Проблемы, открытые с ошибками/сбоями инструмента без каких-либо подробностей («это не работает»/«почему не работает»), будут закрыты.
* Как правило, запускайте инструмент с `-vv` или `-vvv`, если сталкиваетесь с ошибками. Журналирование улучшается с каждой версией.
* При отправке проблем крайне желательно предоставить как можно больше подробностей для возможности отладки/устранения. Пожалуйста, удалите любую конфиденциальную информацию из отладочного вывода, такую как домены клиента/цели, имена машин и т.д. Вы не хотите раскрывать миру скелеты ретрансляции вашего клиента.
* Аргументы использования, вызвавшие проблемы/ошибки/некорректное поведение, также необходимы.
* Проблемы, возникающие из-за ошибок пользователя или некорректно настроенных сред, будут рассмотрены и, вероятно, закрыты. **Исключениями** являются ситуации, когда инструмент **ДОЛЖЕН** корректно обрабатывать специфичную для среды особенность, но он не работает / выдаёт исключения+стек вызовов. Такие ситуации должны быть довольно очевидными. Примеры ошибок пользователя/неправильной настройки сети приведены ниже:
* Например, вы запускаете `--audit`, и RelayKing не может разрешить ни один узел в DNS, потому что их DNS-сервер(ы) просто отказываются разрешать FQDN компьютеров в целевой DNS-зоне. Это не проблема RelayKing.
* Или, например, не удаётся правильно настроить DNS на вашем тестовом узле (проверив /etc/resolv.conf), и после этого компоненты не разрешаются должным образом — это не проблема RelayKing.
* Всё остальное PEBKAC.
### Pull Request:
* PR всегда приветствуются. Новые функции, улучшения и рефакторинг, повышающие производительность/общую логику, желательны.
* Запросы функций можно отправлять через PR. Описание функции, конкретное поведение и потенциальные флаги/аргументы использования обычно являются минимумом, необходимым для рассмотрения внедрения.
* PR должны быть тщательно протестированы, желательно в нескольких средах перед отправкой. Мы протестируем PR перед слиянием, но чем больше тестирования в уникальных средах (особенно после серьёзных изменений/рефакторинга), тем лучше. Я хочу сохранить RelayKing надёжным, устойчивым и высокопроизводительным, что требует тщательного тестирования.
## Благодарности
* **Моя команда — Depth Security (https://www.depthsecurity.com/)**: Поддержка, помощь, руководство и тестирование. Этот инструмент был бы бесполезен без команды бирюзовых (teal).
* **Nick Powers (SpecterOps) (https://github.com/zyn3rgy) — RelayInformer**: Вдохновение и справочная логика обнаружения
* **Многочисленные разработчики / Alex Neff (https://github.com/NeffIsBack) — NetExec**: Реализации различной логики обнаружения.
* **Fortra/SecureAuthCorp/Многочисленные разработчики — Impacket** : Реализации протоколов. Разные прочие вещи.
* **Dirk-jan Mollema (https://github.com/dirkjanm) krbrelayx**: Техники ретрансляции Kerberos, работа с DNS.
* **Garrett Foster (SpecterOps) (https://github.com/garrettfoster13) SCCMHunter**: Логика обнаружения SCCM. Использование лаборатории для тестирования (БОЛЬШОЕ СПАСИБО!)
* **Oliver Lyak (https://github.com/ly4k) Certipy-AD**: Логика обнаружения ADCS
* **Andrea Pierini (https://github.com/decoder-it)**: Многочисленные техники и тактики ретрансляции.
* **p0dalirius (https://github.com/p0dalirius/GhostSPN)**: Концепция и методология обнаружения Ghost SPN.
* Возможно, я кого-то упустил — этот инструмент был бы невозможен без широкого сообщества специалистов по информационной безопасности и их вклада.
## Отказ от ответственности
**Как есть. Конечно, существует множество ошибок. См. выше. Не предназначен и не предполагается для незаконной/несанкционированной деятельности, очевидно.**
**Учитывайте поведение и природу ВСЕХ инструментов, которые вы запускаете для клиента и в его сети(ях). Это достигается путём чтения исходного кода инструмента и понимания внутренних механизмов до выполнения, а не слепым запуском кода, найденного на GitHub. Хотя я могу заверить вас, что в RelayKing нет намеренно вредоносного/разрушительного кода, перед запуском любых новых/неиспользованных инструментов проверять их — хорошая практика. Доверяй, но проверяй.**
**Будьте осторожны при использовании в упражнениях Red Team, особенно с аутентифицированными проверками и`--audit`. Вас ОБЯЗАТЕЛЬНО обнаружат, и это будет ваша вина! Вы должны были прочитать предупреждение в верхней части README, если каким-то образом читаете это предложение и не знали об этом раньше.**
**Хотя это крайне маловероятно, если RelayKing каким-то образом что-то сломает, вы действуете на свой страх и риск, и ни Автор, ни Depth Security не несут ответственности за любые последствия/проблемы/перевёрнутые-геопространственные-битовые-флип-ядерные-взрывы, которые могут возникнуть (как бы маловероятно это ни было) в результате выполнения RelayKing. Результаты могут отличаться. RelayKing, ещё раз, предоставляется БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ ИЛИ ГАРАНТИЙ КОНКРЕТНЫХ РЕЗУЛЬТАТОВ, ФУНКЦИЙ, ПОЛЕЗНОСТИ ИЛИ ПОВЕДЕНИЯ — ЯВНО УПОМЯНУТЫХ ЗДЕСЬ (И/ИЛИ НЕ УПОМЯНУТЫХ) ИЛИ ПОДРАЗУМЕВАЕМЫХ.**
**Единственный легитимный репозиторий на GitHub от Автора (logansdiomedi) находится по адресуhttps://github.com/depthsecurity/RelayKing-Depth — все остальные являются форками/копиями/чем-то ещё, Автор, вероятно, не читал, не проверял, не тестировал, не анализировал и не проверял на предмет функциональности/поведения/легитимности. Используйте голову.**
## Лицензия
Лицензия MIT — подробнее см. в файле LICENSE