Принудительная авторизация (Coerce Auth) — как заставить систему авторизоваться там, где не надо
Обнаружение принудительной авторизации (Coerce Auth), что это и как используется атакующими
Представьте, что вы заставляете сервер автоматически подключаться к вашему фейковому ресурсу, раскрывая свои учетные данные. Это и есть Coerce Auth.
Coerce Auth — это не баг, а фича Windows (но фича, которой любят злоупотреблять). Эти атаки существуют много лет, не патчатся, потому что не признаются Microsoft уязвимостями. То есть будут аткуальны еще долгое врнмя.
Минимум теории: как работает принудительная авторизация (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) — позволяют удалённо вызывать методы, которые заставляют сервер аутентифицироваться. Как правило для эксплуатации нужны валидные учетные данные любого пользователя (даже с минимальными парвами)
PetitPotam (маленький бегемот) - единственный, получивший патч. До патча он не требовал никаких учетных данных. При наличии ESС 8 AD CS позволял взять домен в 2 шага, не имея ничего (ни одной учетной записи или подконтрольного узла).
Шаг 2: Сервер-жертва автоматически пытается аутентифицироваться на поддельном сервере, оставляя NetNTLM или Kerberos билет своей машинной УЗ (с $ на конце). Жертва может не обязательно аутентифицироваться на атакующем сервере. Авторизация может сразу быть направлена на атакуемый сервер, где, например, настроено неограниченное делегирование.
Шаг 3: Поддельный сервер (контролируемый атакующим) перехватывает данные аутентификации и перенапрвляет их для дальнейшей атаки (NTLM relay). Либо сразу на третий узел (см. Что делать с полученными учетными данными)
Принудительная авторизация редко используется в вакууме, чаще в связке с другими техниками: неограниченное делегирование, AD CS, 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 (netNTLM) pass-the-hash провести не получится: Сетевые хеши, Responder и Relay (почему тут не получится сделать PtH)
Поэтому распространенный сценарий - это NTLM Relay (ретрансляция NTLM).
Возможна только если отключена подпись пакетов SMB. Да, почти всегда отключена.
В древние времени, вероятно, был возможен сценарий, когда атакующий приходит к контроллеру домена, просит его авторизовать где-то и перенаправляет авторизацию на этот же контроллер, чтобы сделать DCSync. Но Microsoft очень быстро выпустили патч, который ограничил релей на тот же узел.
Окей, допустим, что в сети 2 контроллера, и можно перенаправить авторизацию одного на другой, чтобы использовать права на репликацию и осуществить тот же DCSync. Не так быстро, но и тут Microsoft выпустили патч, который ограничил релей в тот же протокол. То есть сценарии SMB -> SMB тоже стали неактуальны.
Так что сейчас эксплутация выглдяит больше вот так:
Relay на AD CS (ESC8)
Если в домене развернут AD Certificate Services (AD CS), и в нем активированы службы Web Enrollmen, NTLM-аутентификацию можно переслать на HTTP-эндпоинт сертификатов.
В результате атакующий получает серфикат для авторизации из-под атакуемой машинной учетной записью. Дальше по сертификату запрашивается Kerberos-билет, а тот уже для DCSync или любях других действий.
При запросе TGT по сертификату в поле типо авторизации (Pre-Authentication type) будет значение 16 - PA-PK-AS-REQ (Request sent to KDC in Smart Card authentication scenarios).
Злоупотребление делегированием
В Windows-средах есть несколько видов делегирования. Наиболее интересным для атакующих является неограниченное делегирование.
Неограниченное делегирование — это механизм в Active Directory, позволяющий серверу полностью перенимать права пользователя при доступе к другим сервисам в домене. Сейчас про неограниченное делегирование надо знать, что когда пользователь авторизуиется на таком сервере, его TGT сохраняется в памяти этого сервера с неограниченным делегированием.
Атакующий находит сервер с Unconstrained Delegation (например, старый файловый сервер).
Через PetitPotam (или любой другой Coerce) принуждает контроллер домена (DC) аутентифицироваться на этом сервере.
Сервер перехватывает TGT DC$ (компьютерного аккаунта контроллера).
Атакующий извлекает этот TGT и использует для:
DCSync.
Доступа к любым ресурсам домена.
Как защититься
Ограничить доступ к уязвимым функцияс RPC.
А также:
Включить подпись пакетов SMB. Включить MIC, EPA (Extended Protection for Authentication).
Не использовать неограниченное делегирование.
Что почитать
Кстати, в случае в WebDav исходящее соединение от system (4) будет на порт 80, а не 445. Но при этом в логе останется старт процесса со специфичным коммандлпйном:
rundll32.exe * davclnt.dll * http:// * /PIPE/
Last updated
Was this helpful?