Comments 5
Начал пилить SPN Honeypot, осталось допилить уведомления наверное и уже будет первая версия "спн ханипота"
https://github.com/whoamins/SPN-Honeypot
kerberos armoring это конечно здорово, но стоит включить те политики на контроллере домена и пользователи домена с клиентских машин в домене не могут даже залогинится на свои раб.станции, wireshark показывает ту же ошибку что и в статье (хорошо что это всё в виртуалках происходит, а не в "продакшене"), и это не говоря про всякие легаси системы и софт, а всё потому что эти политики сами не приедут на клиентские машины, т.е. получается это надо на каждой из сотен(а у кого-то и тысяч) машин их руками включить. Вопрос: are you f kidding me?!
Любая политика ужесточающая сетевой обмен в домене AD должна применяться аккуратно: это относится и к отключению легаси механизмов аутентификации, и к требованию по использованию LDAPs и пр.
И тут есть два варианта:
Подождать, пока MS сделает соответствующую политику дефолтной – они это делают с учетом груза легаси, медленно и аккуратно. Например, сейчас те же соединения LDAP по умолчанию уже требуют безопасное соединение, а LM hash (наконец-то) больше не формируется вообще. Но надо понимать, что все время, пока MS не сделает эту опцию опцией по умолчанию – ваши системы будут уязвимы.
Можно внедрить эту настройку, но аккуратно, как это делается для любых других харденингов взаимодействия клиент-сервер. Для этого нужно:
Проверить, что домен удовлетворяет требованиям (все контроллеры домена с ОС не ниже Win server 2012, соответствующие функциональные уровни домена и леса).
Включаем на серверах опцию использования FAST в рекомендуемом режиме (“Always provide claims”) – естественно, с помощью GPO, а не вручную. Далее, ту же опцию развертываем на клиенты (и тоже с помощью GPO). А потом долго и нудно мониторим события на предмет наличия клиентов, которые не смогли сформировать запрос с поддержкой FAST. И для каждого вида ПО изучаем, что можно сделать – обновить, заменить, сменить настройки и пр.
Повторюсь, что это верно для любой другой опции, которая ужесточает взаимодействие клиента и сервера – будь то переход на SMB новой версии, отключение уязвимых протоколов аутентификации или требование обязательного шифрования канала.
Спасибо за статью! Правда, тема FAST не раскрыта. Сделаю это за вас. Из прочитанного не совсем понятно: почему мы не можем провести атаку, что именно нам мешает это сделать, а мешает отсутствие машинного ключа
FAST позволяет создать защищенный канал связи между DC и пользователем, который достигается за счет шифрования всех сообщений определенным сессионным ключом. Если хост, с которого пользователь пытается взаимодействовать с Kerberos, подключен к домену, то такой сессионный ключ получается за счет общения с KDC от лица машинного аккаунта. Каждый компьютер, подключенный к домену, будет иметь свои Kerberos-ключи (их можно посмотреть с помощью #mimikatz lsadump::secrets), и именно эти ключи будут использоваться для получения данного TGT (и сессионного ключа). Без знания этого сессионного ключа и при попытке обычной аутентификации пользователь получит ошибку.
Я, конечно, не тестил, но подразумеваю, что при попытке проведения Kerberoasting на скомпрометированной машине с помощью Rubeus будет успешной, не смотря на FAST
Rubeus.exe kerberoast /outfile:<path\to\store\TGS>
Kerberoasting v2