вы думали, что находитесь в безопасности, ?
31 октября 2022 года был объединен PR на CrackMapExec от Томаса Сеньёре (@Zblurx). Этот PR исправил аутентификацию Kerberos в среде CrackMapExec. Увидев это, мне сразу захотелось попробовать и немного поиграть. При этом я обнаружил странное поведение группы «Защищенные пользователи». В этом сообщении блога я объясню, что такое группа «Защищенные пользователи», почему это хорошая функция безопасности и почему она неполная для пользователя «Администратор» (RID500).
I/ Обычный сценарий внутренней оценки и PtH/OPtH
В моем предыдущем посте о токенах доступа Windows я описал один из наиболее распространенных сценариев, с которыми мы сталкиваемся при внутренних оценках. По сути, мы компрометируем один сервер, сбрасываем его базу данных SAM и память LSASS, чтобы получить учетные данные в открытом виде или NT-хэши. Мы также можем сбросить билеты Kerberos и вообще любой другой материал, который мы могли бы использовать для подключения где-либо еще:
Будь то в базе данных SAM или в памяти процесса LSASS, вы наверняка найдете NT-хэши:
В Windows наличие NT-хеша эквивалентно наличию пароля в виде открытого текста. Если мы посмотрим на протокол аутентификации NTLM, то увидим, что запрос зашифрован с использованием NT-хеша пользователя:
Поскольку у нас есть NT-хеш, мы можем зашифровать запрос, не зная соответствующего пароля в виде открытого текста.
На Kerberos все примерно так же. Протокол аутентификации Kerberos основан на четырех пакетах:
Важной частью является «метка времени, зашифрованная ключом, полученным из пароля пользователя». Как пользователь, мы можем зашифровать временную метку с помощью ключа, который можно получить с помощью одного из следующих алгоритмов:
Интересно то, что RC4 шифрует метку времени, используя NT-хэш пользователя. Поскольку у нас есть действительный NT-хеш, мы можем зашифровать временную метку и получить действительный пакет KRB_AS_REQ. С помощью платформы CrackMapExec мы теперь можем подключаться к удаленным серверам, используя две хорошо известные атаки:
Эти атаки основаны на том факте, что можно использовать NT-хэш для шифрования секрета, используемого для аутентификации пользователя. Чтобы защититься от этого, можно добавить конфиденциальных пользователей в группу «Защищенные пользователи».
II/ Группа защищенных пользователей
Группа «Защищенные пользователи» появилась в Windows Server 2012R2. Если мы посмотрим на статью MSDN, то увидим, что пользователи в этой группе имеют усиленные параметры безопасности:
Как видите, аутентификация NTLM отключена, алгоритм RC4 не может использоваться для шифрования метки времени для аутентификации Kerberos и, наконец, делегирование Kerberos отключено. Давайте проверим это.
Сначала я добавлю нового пользователя-администратора домена (admin2), который находится в группе «Защищенные пользователи»:
Теперь попробуем пройти аутентификацию с помощью NTLM:
Как видите, это не работает, мы получаем «STATUS_ACCOUNT_RESTRICTION». А теперь попробуем использовать Kerberos:
Это тоже не работает (KDC_ERR_PREAUTH_FAILED). Так что да, похоже, что ожидаемые функции безопасности Защищенных пользователей применимы к пользователю admin2. Но применимы ли они ко всем пользователям?
III/ Странное поведение
Пока я играл с CrackMapExec PR, я случайно пытался пройти аутентификацию с использованием Kerberos в качестве учетной записи WHITEFLAG/Администратора, и я понял, что это работает, даже если пользователь находится в группе Защищенные пользователи:
Аутентификация NTLM, напротив, не удалась:
Это означает, что ограничение группы «Защищенные пользователи» не является полным, когда речь идет о пользователе RID500 домена Active Directory. Мы не можем подключиться, используя протокол аутентификации NTLM, но можем подключиться, используя протокол аутентификации Kerberos с RC4.
Еще одно странное поведение связано с делегированием Kerberos. Обычно, когда пользователь входит в группу «Защищенные пользователи», его нельзя делегировать. Здесь я пытаюсь злоупотребить сценарием делегирования RBCD из OCD$ в ADCS1$, чтобы получить билет службы сначала как pu_user, который является защищенным пользователем, а затем как not_pu_user, что не является таковым. Во-первых, давайте посмотрим на делегацию:
Давайте посмотрим на разницу между делегированием pu_user и not_pu_user с помощью RBCD:
Мы ясно видим разницу: Защищенных пользователей нельзя делегировать. Но подождите, давайте посмотрим, как обстоят дела с учетной записью администратора RID 500…
Даже если учетная запись администратора RID 500 находится в группе «Защищенные пользователи», ее можно делегировать. Хорошо, но почему ?
Злоупотребление делегированием RBCD состоит из следующих двух этапов:
- S4U2Self: запросить билет службы для произвольного пользователя для контролируемой учетной записи.
- S4U2Proxy: запросите билет службы от имени произвольного пользователя для учетной записи целевого компьютера, используя ранее полученный билет службы в качестве дополнительного билета.
Когда вы пытаетесь выдать себя за защищенного пользователя, S4U2Self выдает вам билет службы без установленного флага пересылки. Вот почему часть S4U2Proxy завершается с ошибкой KDC_BADOPTION. Однако при олицетворении пользователя администратора RID 500 флаг пересылки устанавливается независимо от того, является ли пользователь защищенным пользователем:
IV/ Сценарий разработки
Используя эту ошибку, мы можем выполнить определенный сценарий. Допустим, у нас есть вымышленная компания Whiteflag. Два года назад они создали свой домен Active Driectory (whiteflag.local), не позаботившись о безопасности. Таким образом, они использовали учетную запись домена RID500 (WHITEFLAG/Администратор) для администрирования своих серверов.
Перенесемся год назад, они попросили провести внутреннюю оценку. Пентестерам удалось скомпрометировать домен и приказали команде безопасности добавить всех пользователей-администраторов домена в группу «Защищенные пользователи». Команда безопасности сделала это, но поскольку они не закрывали сеансы RDP должным образом, NT-хэш учетной записи WHITEFLAG/Администратора все еще хранился в памяти процесса LSASS.
Сегодня вас наняли для тестирования их недавно усиленной сети Active Directory. Если вам удастся скомпрометировать сервер, на котором сеанс RDP все еще активен для учетной записи WHITEFLAG/Администратора, вы сможете получить его NT-хэш. Поскольку ограничения защищенных пользователей для этого пользователя не применяются, вы сможете подключиться к контроллеру домена, используя проверку подлинности Kerberos.
Да, я знаю, это очень специфический сценарий, но эй, такое может случиться! Еще интересно то, что для этой учетной записи также будет работать делегирование Kerberos.
Здесь сценарий более прямолинеен. Если каждая учетная запись администратора входит в список «Защищенные пользователи» и вам необходимо злоупотребить сценарием делегирования RBCD (или любым другим делегированием Kerberos), вы можете просто выдать себя за учетную запись администратора RID 500, и это будет работать!
V/ Исправление
Если мы посмотрим на атрибуты учетной записи RID500, мы увидим, что для значения ms-DSSupportedProtocolEncryption установлено значение 0x0:
Этот атрибут содержит шестнадцатеричное значение, указывающее, какой тип протокола аутентификации включен для этой учетной записи. Поскольку значение равно 0x0, мы можем сделать вывод, что можно использовать любой протокол аутентификации. Если мы установим это значение равным 24 (0x18), что включает только AES-128 и AES-256:
Мы увидим, что мы все еще можем подключиться с помощью атаки OverPass-the-Hash. Единственный способ полностью отключить RC4 — ограничить его для всей среды Active Directory, что может быть опасно, если серверы/приложения по-прежнему полагаются на этот тип аутентификации.
Чтобы избежать трюка с делегированием, вам необходимо отметить опцию «Учетная запись конфиденциальна и не может быть делегирована», даже если учетная запись RID500 находится в категории «Защищенные пользователи».
Другим решением было бы просто отключить учетную запись домена RID500, которая, согласно документации Microsoft, также опасна:
Обратите внимание, что об этой ошибке было сообщено в MSRC. Они ответили, что такое поведение задумано и не является ошибкой. Тем не менее, учетной записью RID500 можно злоупотреблять, так что имейте это в виду ;)!
Эту статью написали Орельен ШАЛОТ ( @Defte_ ) и Томас Сеньёре ( @_zblurx ). Мы также хотели бы поблагодарить некоторых друзей за эти ночные беседы, которые мы провели, чтобы попытаться понять, что происходит: Чарли БРОМБЕРГ ( @_nwodtuhs ) , Марсьяль ПЮГРЕНЬЕ ( @mpgn_x64 ), Вилфрид БЕКАРД ( @tiyeuse ), а также Сообщество Hide&Sec .
Этот пост был впервые опубликован на https://sensepost.com/blog/2023/protected-users-you- Thought-you-were-safe-uh/.