Отражение аутентификации существует уже более 20 лет, но его последствия в современных сетях Windows далеко не устарели. Даже после того, как все исправления, которые Microsoft выпустила на протяжении многих лет, отражение атак по-прежнему можно использовать
В этом посте рассказывается о том, что на самом деле представляет собой отражение аутентификации, почему оно остается опасным сегодня и как самые последние открытия доказывают, что отражение продолжает возвращаться туда, где на самом деле не должно. Мы рассмотрим, как недавнее поведение Windows привело к появлению совершенно новых поверхностей атак с участием Kerberos, NTLM, SMB, HTTP и DCE/RPC. Мы также рассмотрим Ghost SPN CredMarshalTargetInfo (CMTI) трюк, и несколько случаев, когда одной отраженной аутентификации было достаточно, чтобы скомпрометировать весь домен.
Цель также состоит в том, чтобы пояснения были достаточно ясными для читателей, которые не являются экспертами в этих темах, не теряя при этом важных технических деталей
В зависимости от вектора принуждения это приводит к
➔ Повышение местных привилегий (LPE)
➔ Удаленная эскалация привилегий (RPE)
➔ Полнодоменный компромисс когда отраженная аутентификация попадает на LDAP/LDAPS на постоянном токе при определенных условиях
Отражательные атаки не крадут учетные данные.
Они заставляют Windows проходить аутентификацию от вашего имени.
В конечном итоге Microsoft исправила классическое отражение NTLM в петле, включая
➔ Одинаковое отражение протокола (NTLM→NTLM)
➔ Межпротокольное отражение (NTLM→различный сервис)
Но история не закончилась, локальная аутентификация NTLM все же была...
Хорошо, - сказал я, - сложнее, но, конечно, не невозможно
Для этого нам необходимо контролировать имя принципала службы (SPN), которое Kerberos и NTLMv2 также используют для идентификации целевой службы.
Другими словами, для нашего поддельного SPN идеальная ситуация заключается в том, что клиент использует SPN/TARGET, где TARGET переходит на IP-адрес, который мы контролируем, но клиент по-прежнему считает его локальным.
В сценарии DCOM, злоупотребляя различными ‘*картофель’ методы, мы можем создать поддельный OXID Resolver. Это позволяет нам дать клиенту указание использовать SPN, связанный с жертвой (SPN/VICTIM), сохраняя при этом контакт с конечной точкой, находящейся под нашим контролем. Это дает нам аутентификацию жертвы, которую мы затем можем отразить обратно в службу самой жертвы, потому что он является жертвой
Однако если мы хотим использовать другие протоколы, такие как SMB, которые не дают нам контроля над SPN, нам нужна альтернатива.
Вводить CredMarshalTargetInfo()описан Джеймсом Форшоу
Windows SSPI поддерживает формат “Special” SPN, который включает встроенный блок информации о цели маршала:
➔ ServiceClass/Сервер [TargetInfo]
где:
TargetInfo представляет собой сериализованную структуру, подобную базе64, называемую Credential Target Information
Самая короткая допустимая капля:
➔ 1UWHRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaawbEAYBAAAA
Этой крошечной капли достаточно для Windows, чтобы считать SPN хорошо сформированным, но она также позволяет нам подделать имя хоста внутри SPN таким образом, чтобы оно пережило канонизацию SPN, обработку Kerberos и анализ AV-пар NTLM.
Еще лучше: стандартный пользователь домена по умолчанию может создавать DNS-записи, а это значит, что он может свободно вводить новые имена, указывающие на IP-адреса, контролируемые злоумышленником.
Когда SPN включает в себя каплю CMTI, вот что происходит:
➔ Kerberos запросит TGS для СервисКласс/Сервер
➔ NTLM встроит значение в MsvAvTargetName
➔ Клиент (SMB, RPC, DCOM, ...) действительно свяжется с хостом по имени
➔ <сервер>1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaaawbEAYBAAAA
Если этот “hostname” переходит на IP-адрес, контролируемый злоумышленником, но внутренний TargetInfo заставляет Windows относиться к ней как к локальной, тогда мы получаем точную ситуацию, на которую опираются атаки с отражением:
На серверах Windows с установленной ролью "Службы сертификатов" система предоставляет Запрос AD CS CertSrv интерфейс, который может быть создан удаленно любым пользователем домена и запускает исходящую машинную аутентификацию с сервера AD CS.
Я уже освещал это в своем посте ‘Здравствуйте, я ваш сервер ADCS и хочу пройти аутентификацию против вас’, где я также продемонстрировал, что можно отразить аутентификацию Kerberos на сервере и злоупотреблять ею в сценарии ESC8.
Невозможно отразить DCOM → SMB, поскольку SMB обеспечивает защиту от отражения как для Kerberos, так и для NTLM. На этом пути ISC_REQ_UNVERIFIED_TARGET_NAME флаг, установленный клиентом DCOM, фактически выполняется клиентом SMB, что предотвращает повторное использование аутентификации на том же хосте путем удаления SPN в случае обратной аутентификации.
Злоупотребляя ЦМТИ, удаленный злоумышленник может злоупотребить Kerberos и NTLM рефлексивной аутентификации и в конечном итоге получить SYSTEM привилегии.
Подробное описание можно найти здесь и здесь
В случае NTLM это вызовет локальную аутентификацию NTLM; подробнее об этом позже...
Microsoft исправила поведение SMB-клиента CVE-2025-33073, отклонение недействительно и пусто CMTI TargetInfo данные при установлении сессий SMB.
После CVE-2025-33073 я задался вопросом, можно ли по-прежнему злоупотреблять отражением аутентификации после исправления.
Введите ПРИЗРАК СПН: SPN, который ссылается на имена хостов, которые не зарегистрированы (или больше не зарегистрированы) в DNS. Если он присутствует, то Kerberos SMB➔SMB-рефлексией все равно можно злоупотреблять!
Создав Ghost SPN в DNS и указав его на IP-адрес, контролируемый злоумышленником, злоумышленник может обманом заставить целевую машину выполнить отражающую аутентификацию с помощью Kerberos, в результате чего для несуществующего компьютера Ghost появится действительный сервисный билет.
Мое подробное описание нападения можно найти здесь
MS исправила это в октябре 2025 года в драйвере сервера SMB (SRV2).SYS) путем проверки адресов циклического возврата (CVE‑2025‑58726)
В локальной аутентификации NTLM “Reserved Field” в сообщении NTLM 2 не пуст, но будет ссылаться на дескриптор LSASS “Context”, с которым должен связываться клиент
Сообщение NTLM 3 Authenticate будет полностью пустым:
Первым злоупотреблением этим конкретным местным отражением было наше “Местный Картофель” местное злоупотребление SMB DCOM➔.
Перемещая контексты аутентификации между привилегированным клиентом RPC/DCOM и SMB-клиентом, контролируемым злоумышленником, непривилегированный пользователь может выдать себя за СИСТЕМУ. Фактически это привело к повышению местных привилегий и было исправлено Microsoft в соответствии с CVE-2023-2174
Однако удаленные варианты оставались жизнеспособными до 2025 года.
Как уже упоминалось, в локальной аутентификации NTLM сообщение NTLM3 совершенно пусто, а это означает, что проверки NTLMv2 MIC, MsAVFlags, NtProofStr, вероятно, были пропущены...
Так что же это значит? Это позволило нам это сделать сбросить флаг SIGN без вмешательство в проверку целостности сообщения (MIC), который открыл дверь для отражения аутентификации по протоколам, даже в таких случаях, как SMB → LDAP (S), где подписание должен остановили это.
Но на этом не остановилось. При использовании LDAPS или HTTPS требование привязки каналов будет полностью обойдено!!!
Внесением некоторых небольших изменений в нтлмрелайкс , в основном удаляя SIGN/SEAL, сохраняя при этом NTLM3 нетронутым, я мог заставить контроллер домена пройти аутентификацию, а затем отразить эту аутентификацию обратно в LDAPS, что привело к полному захвату домена у стандартного пользователя домена!
Это означало, что до июня 2025 года ЛЮБОЙ пользователь домена может захватить домен AD
Фактически, препятствуя трюку CMTI в SMB, такого рода крайне разрушительные злоупотребления больше были невозможны.
И вот еще один интересный аспект: с DCE/RPC нам больше не нужно подделывать SPN или манипулировать записями DNS. Используя IP-адрес злоумышленника достаточно, NTLM с радостью договорится о локальной аутентификации
Это могло бы позволить ЛЮБОЙ пользователь домена возьмет на себя управление постоянным током Windows Server 2025 с включенным PrintSpooler
Поскольку я не смог найти много подробностей по этому поводу, я построил свой собственный PoC, реализующий the новый обратный вызов DCE/RPC PrinterBug.
В этом посте рассказывается о том, что на самом деле представляет собой отражение аутентификации, почему оно остается опасным сегодня и как самые последние открытия доказывают, что отражение продолжает возвращаться туда, где на самом деле не должно. Мы рассмотрим, как недавнее поведение Windows привело к появлению совершенно новых поверхностей атак с участием Kerberos, NTLM, SMB, HTTP и DCE/RPC. Мы также рассмотрим Ghost SPN CredMarshalTargetInfo (CMTI) трюк, и несколько случаев, когда одной отраженной аутентификации было достаточно, чтобы скомпрометировать весь домен.
Цель также состоит в том, чтобы пояснения были достаточно ясными для читателей, которые не являются экспертами в этих темах, не теряя при этом важных технических деталей
Что такое отражение аутентификации на самом деле
Отражение аутентификации обманчиво простое:- Жертву (машину или пользователя) принуждают пройти аутентификацию на конечной точке, контролируемой злоумышленником.
- Злоумышленник отражает эту попытку аутентификации обратно в службу, которую хост-жертва запускает сам.
- В конечном итоге жертва проходит аутентификацию в собственном сервисе, используя свою личность.
В зависимости от вектора принуждения это приводит к
➔ Повышение местных привилегий (LPE)
➔ Удаленная эскалация привилегий (RPE)
➔ Полнодоменный компромисс когда отраженная аутентификация попадает на LDAP/LDAPS на постоянном токе при определенных условиях
Отражательные атаки не крадут учетные данные.
Они заставляют Windows проходить аутентификацию от вашего имени.
Очень старая проблема: MS08-68
Отражение аутентификации было впервые широко использовано в 2008 году МС08-68, где аутентификация NTLM может быть отражена обратно в SMB на том же хосте, что дает системные привилегии.В конечном итоге Microsoft исправила классическое отражение NTLM в петле, включая
➔ Одинаковое отражение протокола (NTLM→NTLM)
➔ Межпротокольное отражение (NTLM→различный сервис)
Но история не закончилась, локальная аутентификация NTLM все же была...
Отражение Кербероса: HardeR, невозможно
Kerberos не имеет универсального механизма обнаружения отражения, но требование контроля над целевым SPN и действительными билетами Kerberos существенно затрудняет использование таких атак на практике.Хорошо, - сказал я, - сложнее, но, конечно, не невозможно
Уловка CredMarshaltargetinfo (cmti): злоупотребление метаданными spn
Чтобы выполнить атаку с отражением, мы должны убедить Windows направить аутентификацию обратно на себя. На практике это означает подмену имени хоста, чтобы аутентификация отправлялась в конечную точку, находящуюся под нашим контролем, в то время как клиент по-прежнему считает, что имя целевого хоста является локальным.Для этого нам необходимо контролировать имя принципала службы (SPN), которое Kerberos и NTLMv2 также используют для идентификации целевой службы.
Другими словами, для нашего поддельного SPN идеальная ситуация заключается в том, что клиент использует SPN/TARGET, где TARGET переходит на IP-адрес, который мы контролируем, но клиент по-прежнему считает его локальным.
В сценарии DCOM, злоупотребляя различными ‘*картофель’ методы, мы можем создать поддельный OXID Resolver. Это позволяет нам дать клиенту указание использовать SPN, связанный с жертвой (SPN/VICTIM), сохраняя при этом контакт с конечной точкой, находящейся под нашим контролем. Это дает нам аутентификацию жертвы, которую мы затем можем отразить обратно в службу самой жертвы, потому что он является жертвой
Однако если мы хотим использовать другие протоколы, такие как SMB, которые не дают нам контроля над SPN, нам нужна альтернатива.
Вводить CredMarshalTargetInfo()описан Джеймсом Форшоу
Windows SSPI поддерживает формат “Special” SPN, который включает встроенный блок информации о цели маршала:
➔ ServiceClass/Сервер [TargetInfo]
где:
TargetInfo представляет собой сериализованную структуру, подобную базе64, называемую Credential Target Information
Самая короткая допустимая капля:
➔ 1UWHRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaawbEAYBAAAA
Этой крошечной капли достаточно для Windows, чтобы считать SPN хорошо сформированным, но она также позволяет нам подделать имя хоста внутри SPN таким образом, чтобы оно пережило канонизацию SPN, обработку Kerberos и анализ AV-пар NTLM.
Еще лучше: стандартный пользователь домена по умолчанию может создавать DNS-записи, а это значит, что он может свободно вводить новые имена, указывающие на IP-адреса, контролируемые злоумышленником.
Когда SPN включает в себя каплю CMTI, вот что происходит:
➔ Kerberos запросит TGS для СервисКласс/Сервер
➔ NTLM встроит значение в MsvAvTargetName
➔ Клиент (SMB, RPC, DCOM, ...) действительно свяжется с хостом по имени
➔ <сервер>1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaaawbEAYBAAAA
Если этот “hostname” переходит на IP-адрес, контролируемый злоумышленником, но внутренний TargetInfo заставляет Windows относиться к ней как к локальной, тогда мы получаем точную ситуацию, на которую опираются атаки с отражением:
Именно это позволяет SMB→SMB отражаться даже без прямого управления SPN, и именно поэтому спуфинг на основе CMTI стал таким мощным инструментом в современных отраженных атаках.Аутентификация отправляется злоумышленнику, но обрабатывается так, как если бы она направлялась в локальную службу.
Удаленное отражение Kerberos — DCOM → HTTP
Злоупотребление DCOM не новость, но Windows разоблачает интерфейсы, особенно полезные для принуждения.На серверах Windows с установленной ролью "Службы сертификатов" система предоставляет Запрос AD CS CertSrv интерфейс, который может быть создан удаленно любым пользователем домена и запускает исходящую машинную аутентификацию с сервера AD CS.
Я уже освещал это в своем посте ‘Здравствуйте, я ваш сервер ADCS и хочу пройти аутентификацию против вас’, где я также продемонстрировал, что можно отразить аутентификацию Kerberos на сервере и злоупотреблять ею в сценарии ESC8.
Невозможно отразить DCOM → SMB, поскольку SMB обеспечивает защиту от отражения как для Kerberos, так и для NTLM. На этом пути ISC_REQ_UNVERIFIED_TARGET_NAME флаг, установленный клиентом DCOM, фактически выполняется клиентом SMB, что предотвращает повторное использование аутентификации на том же хосте путем удаления SPN в случае обратной аутентификации.
SMB → SMB Kerberos/NTLM Отражение
До июня 2025 года принуждение SMB к обратному вызову с использованием PrintSpooler, EFSRPC или DFS могло заставить клиентов SMB пройти аутентификацию на произвольных конечных точках.Злоупотребляя ЦМТИ, удаленный злоумышленник может злоупотребить Kerberos и NTLM рефлексивной аутентификации и в конечном итоге получить SYSTEM привилегии.
Подробное описание можно найти здесь и здесь
В случае NTLM это вызовет локальную аутентификацию NTLM; подробнее об этом позже...
Microsoft исправила поведение SMB-клиента CVE-2025-33073, отклонение недействительно и пусто CMTI TargetInfo данные при установлении сессий SMB.
Призрачные SPN и “Ghost Reflection” Attack
После CVE-2025-33073 я задался вопросом, можно ли по-прежнему злоупотреблять отражением аутентификации после исправления.
Введите ПРИЗРАК СПН: SPN, который ссылается на имена хостов, которые не зарегистрированы (или больше не зарегистрированы) в DNS. Если он присутствует, то Kerberos SMB➔SMB-рефлексией все равно можно злоупотреблять!
Создав Ghost SPN в DNS и указав его на IP-адрес, контролируемый злоумышленником, злоумышленник может обманом заставить целевую машину выполнить отражающую аутентификацию с помощью Kerberos, в результате чего для несуществующего компьютера Ghost появится действительный сервисный билет.
Мое подробное описание нападения можно найти здесь
MS исправила это в октябре 2025 года в драйвере сервера SMB (SRV2).SYS) путем проверки адресов циклического возврата (CVE‑2025‑58726)
локальная аутентификация NTLM и отражающие злоупотребления
локальная аутентификация NTLM - это особый тип аутентификации, происходящий в одном и том же машинном контексте и согласованный Клиентом и Сервером.В локальной аутентификации NTLM “Reserved Field” в сообщении NTLM 2 не пуст, но будет ссылаться на дескриптор LSASS “Context”, с которым должен связываться клиент
Сообщение NTLM 3 Authenticate будет полностью пустым:
Первым злоупотреблением этим конкретным местным отражением было наше “Местный Картофель” местное злоупотребление SMB DCOM➔.
Перемещая контексты аутентификации между привилегированным клиентом RPC/DCOM и SMB-клиентом, контролируемым злоумышленником, непривилегированный пользователь может выдать себя за СИСТЕМУ. Фактически это привело к повышению местных привилегий и было исправлено Microsoft в соответствии с CVE-2023-2174
Однако удаленные варианты оставались жизнеспособными до 2025 года.
Удаленное отражение NTLM против контроллеров домена
До июня 2025 года существовал низко висящий плод, о котором официально не сообщалось и который был непреднамеренно зафиксирован с помощью CVE-2025-33073.Как уже упоминалось, в локальной аутентификации NTLM сообщение NTLM3 совершенно пусто, а это означает, что проверки NTLMv2 MIC, MsAVFlags, NtProofStr, вероятно, были пропущены...
Так что же это значит? Это позволило нам это сделать сбросить флаг SIGN без вмешательство в проверку целостности сообщения (MIC), который открыл дверь для отражения аутентификации по протоколам, даже в таких случаях, как SMB → LDAP (S), где подписание должен остановили это.
Но на этом не остановилось. При использовании LDAPS или HTTPS требование привязки каналов будет полностью обойдено!!!
Внесением некоторых небольших изменений в нтлмрелайкс , в основном удаляя SIGN/SEAL, сохраняя при этом NTLM3 нетронутым, я мог заставить контроллер домена пройти аутентификацию, а затем отразить эту аутентификацию обратно в LDAPS, что привело к полному захвату домена у стандартного пользователя домена!
Это означало, что до июня 2025 года ЛЮБОЙ пользователь домена может захватить домен AD
Фактически, препятствуя трюку CMTI в SMB, такого рода крайне разрушительные злоупотребления больше были невозможны.
Удаленное злоупотребление отражением аутентификации NTLM на сервере 2025
В Windows Server 2025 Microsoft ужесточила безопасность печати . В рамках этого РаспечататьУведомление() обратный вызов был перенесен из именованных труб (SMB) и теперь использует DCE/RPC. Непредвиденный побочный эффект заключается в том, что DCE/RPC по-прежнему поддерживает трюк CMTI.И вот еще один интересный аспект: с DCE/RPC нам больше не нужно подделывать SPN или манипулировать записями DNS. Используя IP-адрес злоумышленника достаточно, NTLM с радостью договорится о локальной аутентификации
Это могло бы позволить ЛЮБОЙ пользователь домена возьмет на себя управление постоянным током Windows Server 2025 с включенным PrintSpooler
Поскольку я не смог найти много подробностей по этому поводу, я построил свой собственный PoC, реализующий the новый обратный вызов DCE/RPC PrinterBug.