Что такое Protected Users и почему они защищают от pass-the-hash атак (или не защищают?)

Итак, во многих гайдах от Microsoft по смягчению атак присутствуют рекомендации добавлять аккаунты администраторов в группу “Protected Users”. Зачем?

Это специальная группа AD, для участников которой действуют следующие ограничения в домене:
🔹отключена аутентификация по NTLM протоколу (только Kerberos)
🔹отключены алгоритмы DES/RC4 для пре-аутентификации Kerberos
🔹эти уч. записи не могут быть использованы для Kerberos-делегации

Немного теории: в Kerberos, прежде чем взаимодействовать с доменными ресурсами, пользователь должен пройти пре-аутентификацию (подтвердить, что он знает свой пароль). Для этого пользователь шифрует временную метку с помощью одного из доступных и разрешенных алгоритмов (DES, RC4, AES128, AES256) и отправляет полученное значение на контроллер домена. Если все верно, пользователь проходит пред-аутентификацию, получает TGT-билет, далее может обращаться к доменным ресурсам.

1️⃣ Но оказывается, тут не все так однозначно. Aurelien Chalot на sensepost выпустил статью, в которой рассказал, что доменный аккаунт с SID *-500 (обычно это администратор домена) все-таки может пройти пре-аутентификацию по Kerberos, используя NTLM-хэш для подписи, даже если он находится в группе Protected Users ( использует запрещенный в РФ RC4 алгоритм для прохождения пре-аутентификации).

2️⃣ Другая проблема связана с делегацией. Как уже было сказано выше, если пользователь в группе Protected Users, его нельзя использовать для делегации. Почему? Когда к контроллеру домена приходит сервис с S4U2SELF запросом, то DC вернет сервису билет без флага FORWARDABLE, а без этого флага запрос S4U2proxy не будет выполнен и делегация будет неуспешна. Так вот, это также неактуально для нашего администратора, для него билеты будут возвращаться с выставленным флагом 🚩 и делегация будет работать. 🤔

🛠 Как исправить?
🟦 Чтобы исправить пре-аутентификацию Kerberos, необходимо выставить параметр ms-DSSupportedProtocolEncryption у пользователя в значение 24 (0x18). Так Администратор будет использовать наборы алгоритмов AES128/AES256 для шифрования
🟦 Для исправления делегации у пользователя нужно явно выставить флаг "Account is sensitive and cannot be delegated" в профиле

----

Очередная "фича, а не баг" от Microsoft добавляется в копилку к неправильным практикам конфигурации. Спасибо чувакам из Редмонда за очередную головную боль. Да и вообще, оказывается, что доменного администратора нужно отключать 🤔