Принудительная авторизация (Coerce Auth) — как заставить систему авторизоваться там, где не надо
Обнаружение принудительной авторизации (Coerce Auth), что это и как используется атакующими
Представьте, что вы заставляете сервер автоматически подключаться к вашему фейковому ресурсу, раскрывая свои учетные данные. Это и есть Coerce Auth.
Минимум теории: как работает принудительная авторизация (Coerce Auth)
Принудительная авторизация — это техника, при которой атакующий заставляет систему (сервер или рабочую станцию) автоматически аутентифицироваться на подконтрольном ему ресурсе. Для этого используется уязвимый RPC-интерфейс.
Такие сервисы, как Print Spooler (MS-RPRN), EFSRPC (MS-EFSR), DFS (MS-DFSNM), работают через RPC и по умолчанию разрешают аутентификацию.
Серверы и рабочие станции автоматически пытаются аутентифицироваться при доступе к сетевым ресурсам (например, при запросе печати или доступа к файлам).
Это фича, а не баг — так задумано для удобства работы в корпоративных сетях.
В результате жертва (система) передаёт свои учетные данные (машинную УЗ), которые можно перехватить и использовать для дальнейших атак.
Microsoft официально классифицирует Coerce Auth как "feature abuse" (злоупотребление функционалом), а не уязвимость.
Шаг 1: Атакующий инициирует запрос к жертве через уязвимый RPC-интерфейс вроде
MS-RPRN. RPC-интерфейсы (Print Spooler, EFS, DFS) — позволяют удалённо вызывать методы, которые заставляют сервер аутентифицироваться. Как правило для эксплуатации нужны валидные учетные данные любого пользователя (даже с минимальными парвами)
Шаг 2: Сервер-жертва автоматически пытается аутентифицироваться на поддельном сервере, оставляя NetNTLM или Kerberos билет своей машинной УЗ (с $ на конце). Жертва может не обязательно аутентифицироваться на атакующем сервере. Авторизация может сразу быть направлена на атакуемый сервер, где, например, настроено неограниченное делегирование.
Шаг 3: Поддельный сервер (контролируемый атакующим) перехватывает данные аутентификации и перенапрвляет их для дальнейшей атаки (NTLM relay). Либо сразу на третий узел (см. Что делать с полученными учетными данными)
Классические примеры Coerce Auth
Метод
Протокол/Сервис
Pipe
Как работает
Printer Bug
MS-RPRN
spoolss
Атакующий имитирует запрос на печать → сервер аутентифицируется.
PetitPotam
MS-EFSRPC
efsrpc lsarpc* samr* lsass* netlogon* *детект обращения к этим pipe может сильно фолзить
Использует вызов EfsRpcOpenFileRaw для принудительной аутентификации DC.
DFSCoerce
MS-DFSNM
netdfs
Эксплуатирует Distributed File System (DFS) через NetrDfsRemoveStdRoot.
ShadowCoerce
MS-FSRVP
FfsagentRpc
Запрашивает доступ к теневых копиям → сервер аутентифицируется.
WSPCoerce
MS-WSP
msftewds
Инструмент, который включает в себя различные известные способы принудительной авторизации:
Обнаружение
Первое, что видим, это, кончено, обращение к именованному каналу, одну из списка выше (зависит от используемой уязвимой функции RPC) - EventID 5145
Атакуемый узел принимает соединение с атакующего, принимает его ядро Windows (system (4)) - EventID 5156/Sysmon EID 3
Этот же system (4) открывает соединение на порт 445 (потому что пытается авторизоваться). Хостом авторизации может быть как изначальный атакующий узел, так и сторонний.
В общем, по логам ОС обнаружить принудительную авторизацию бывает нетривиально. Подобные атаки все же лучше обнаруживаются по сети. Вот пример с PetitPotam:
Что делать с полученными учетными данными
Coerce Auth — только первый шаг.
В теории можно просто перехватить авторизацию и попробовать восстановить исходный пароль из NetNTLM. (Казалось бы, что еще делать с принудительной авторизацией, как не воровать данные для авторизации). Но так как авторизация происходит от машинной УЗ, пароль которой задает не пользовать, атаки по словарю не эффективны.
Поэтому распространенный сценарий - это NTLM Relay (ретрансляция NTLM).
В древние времени, вероятно, был возможен сценарий, когда атакующий приходит к контроллеру домена, просит его авторизовать где-то и перенаправляет авторизацию на этот же контроллер, чтобы сделать DCSync. Но Microsoft очень быстро выпустили патч, который ограничил релей на тот же узел.
Окей, допустим, что в сети 2 контроллера, и можно перенаправить авторизацию одного на другой, чтобы использовать права на репликацию и осуществить тот же DCSync. Не так быстро, но и тут Microsoft выпустили патч, который ограничил релей в тот же протокол. То есть сценарии SMB -> SMB тоже стали неактуальны.
Так что сейчас эксплутация выглдяит больше вот так:
Relay на AD CS (ESC8)
Если в домене развернут AD Certificate Services (AD CS), и в нем активированы службы Web Enrollmen, NTLM-аутентификацию можно переслать на HTTP-эндпоинт сертификатов.
В результате атакующий получает серфикат для авторизации из-под атакуемой машинной учетной записью. Дальше по сертификату запрашивается Kerberos-билет, а тот уже для DCSync или любях других действий.
Злоупотребление делегированием
В Windows-средах есть несколько видов делегирования. Наиболее интересным для атакующих является неограниченное делегирование.
Неограниченное делегирование — это механизм в Active Directory, позволяющий серверу полностью перенимать права пользователя при доступе к другим сервисам в домене. Сейчас про неограниченное делегирование надо знать, что когда пользователь авторизуиется на таком сервере, его TGT сохраняется в памяти этого сервера с неограниченным делегированием.
Атакующий находит сервер с Unconstrained Delegation (например, старый файловый сервер).
Через PetitPotam (или любой другой Coerce) принуждает контроллер домена (DC) аутентифицироваться на этом сервере.
Сервер перехватывает TGT DC$ (компьютерного аккаунта контроллера).
Атакующий извлекает этот TGT и использует для:
DCSync.
Доступа к любым ресурсам домена.
Как защититься
Ограничить доступ к уязвимым функцияс RPC.
А также:
Включить подпись пакетов SMB. Включить MIC, EPA (Extended Protection for Authentication).
Не использовать неограниченное делегирование.
Что почитать
Last updated
Was this helpful?