Привет, Хабр. Это Александр Махновский, технический директор Avanpost. В компании Avanpost мы занимаемся разработкой собственной службы каталогов Avanpost DS. Она плотно интегрируется с Microsoft Active Directory для обеспечения долговременного сосуществования инфраструктур: поддерживает различные виды доверительных отношений, включая двусторонние, специфичные расширения Kerberos и еще много закрытых функций, имплементация которых требует глубокого понимания устройства доменных служб MS. Для их реализации нам пришлось изучить множество документации, а кое-где и прибегнуть к реверс-инжинирингу. Соответственно, сейчас мы следим за изменениями, которые вносит MS в свой продукт и, в особенности, за изменениями в области безопасности, ведь чаще всего именно они приводят к нарушению работоспособности интеграций.
Наткнувшись на статью Giulio Pierantoni на Medium, мы не смогли пройти мимо и решили поделиться ей с русскоязычным сообществом. Далее представлен перевод оригинальной статьи.
Администраторы домена могут манипулировать атрибутами пользователей для получения MS-SNMP хешей паролей учетных записей, не являющихся компьютерами. Данная возможность может быть использована как альтернативная техника кражи учетных данных с повышенными привилегиями. Я называю этот метод “Targeted timeroasting” благодаря его схожести с такими атаками как “targeted kerberoasting” и “AS-REP roasting”, в которых учетные записи, не подверженные данным видам атак в нормальном случае, подделываются для того чтобы стать уязвимыми, что потенциально позволяет злоумышленникам получить пароль пользователя в открытом виде при последующем автономном взломе хеша.
Timeroasting — интересная атака, обнаруженная и задокументированная Томом Тервуртом из компании Secura. Атака основана на особенностях MS-SNTP, собственного аутентификационного расширения Microsoft для протоколов NTP и SNTP, используемых узлами, подключенными к домену, для синхронизации времени с контроллером домена.
Неаутентифицированные клиенты могут взять список RID-ов и отправить MS-SNTP-запросы на контроллер домена, чтобы собрать MD5-хеши, вычисленные по хешам компьютеров домена. Это делает timeroasting эффективным методом определения и взлома предсозданных машинных аккаунтов и других слабых машинных паролей более скрытым способом, чем использование словарей или инструментов типа pre2k.
Как я уже упоминал в статье о слабых компьютерных паролях, timeroasting имеет два слабых места:
он может быть использован только для получения хешей компьютеров;
он требует мапинга RID на имена пользователей, так что нужна либо возможность анонимного доступа к каталогу, либо действительные учетные данные любого пользователя домена.
Мне показалась интересной потенциальная возможность использования NTP для потенциальной компрометации учетных записей пользователей Active Directory, но варианты оказались очень ограничены. Именно поэтому я начал думать об альтернативных способах расширения сферы применения timeroasting-а.
Я спросил себя: как контроллер проверяет, является ли учетная запись компьютером или пользователем? Можем ли мы обмануть Windows, заставив ее думать, что учетная запись пользователя является компьютером, и отправить нам ее хеш? Несомненно, мы можем.
Так пользователь или компьютер?
Все пользователи AD имеют атрибут sAMAccountType, который информирует нас, к какому подтипу учетной записи относится данный объект. Вот так выглядят наиболее распространенные значение этих полей:
SAM_NORMAL_USER_ACCOUNT (0x30000000) = users
SAM_MACHINE_ACCOUNT (0x30000001) = computers
Напрямую этот атрибут невозможно изменить, даже администратору домена.
К счастью для нас, sAMAccountType объекта обновляется автоматически, в зависимости от значения флагов userAccountControl. Этот атрибут по факту представляет собой набор флагов для определения характеристик учетной записи:
UF_NORMAL_ACCOUNT = 512 (users)
UF_WORKSTATION_TRUST_ACCOUNT = 4096 (computers)
UF_SERVER_TRUST_ACCOUNT = 8192 (domain controllers)
Эти флаги являются взаимоисключающими, одновременно может быть задано только одно из возможных значений. Когда значение userAccountControl меняется на 4096, sAMAccountType автоматически обновляется на SAM_MACHINE_ACCOUNT, заставляя контроллер домена воспринимать учетную запись как компьютер.
По спецификации MS_SAMSR, в нормальных условиях у существующего аккаунта нельзя изменить значение атрибута userAccountControl с UF_NORMAL_ACCOUNT на UF_WORKSTATION_TRUST_ACCOUNT или наоборот, даже имея полные права на целевой объект, однако, администраторы домена являются исключением из этого правила.
Это означает, что, к сожалению, targeted timeroasting не может быть использован в качестве техники захвата с использованием непривилегированной учетной записи, как, например, targeted kerberoasting and AS-REP roasting, shadow credentials, ESC14 и т. д.
Перед тем, как вычислить MS-SNTP хеш для учетной записи, контроллер проверяет, что значение атрибута sAMAccountName заканчивается на $. Но для администратора домена смена значения будет тривиальной задачей (конечно, если в домене уже нет другой учетной записи с таким же именем + “$” в конце).
Как только значения userAccountControl и sAMAccountName объекта будут модифицированы, контроллер домена начнет свободно раздавать хеш этого аккаунта всем, кто пошлет такой запрос.
PoC
Важно заметить, что пользовательские аккаунты не могут быть использованы для входа на рабочие станции, когда userAccountControl установлен в значение UF_WORKSTATION_TRUST_ACCOUNT.
На уже открытые сессии изменение атрибутов никак не влияет, поэтому, если восстановить оригинальное значение атрибутов сразу после получения хеша, пользователь ничего не заметит.
Я модифицировал скрипт PowerShell timeroasting от Jacopo Scannella, чтобы сделать черновой PoC, который вы можете увидеть на моем GitHub. Он требует запуск от имени доменного администратора с компьютера, присоединенного к домену, на котором предустановлен модуль Active Directory для PowerShell. Он работает следующим образом:
получает атрибуты objectSid и userAccountControl целевого аккаунта;
устанавливает атрибуту userAccountControl значение UF_WORKSTATION_TRUST_ACCOUNT (4096);
добавляет символ $ к sAMAccountName объекта;
проверяет, что атрибуты изменились корректно (опционально);
извлекает RID и посылает клиентский запрос MS-SNTP к контроллеру домена;
извлекает хеш из ответа сервера;
восстанавливает оригинальные значения атрибутов userAccountControl и sAMAccountName;
проверяет, что восстановление прошло успешно (опционально).
Если мы посмотрим на обмен пакетами, то увидим буквально только NTP транзакцию, с указанным в запросе RID и ответ, содержащий подпись, сгенерированную на основе NT-хеша аккаунта. Соль, присоединенная к хешу, также извлекается из ответного NTP-пакета.
Еще раз хочу отметить, что это всего лишь быстрый и неаккуратный PoC, написанный человеком без серьезного опыта в PowerShell, и, поскольку скрипт модифицирует атрибуты каждого пользователя, он вряд ли пригоден для атаки на весь домен, однако может быть использован для взлома нескольких пользователей.
Режим 31300 Hashcat-а может помочь нам с подбором этих хешей, для чего мы можем собрать его из исходников или загрузить бета-версию:
hashcat -a 0 -m 31300 hashes.txt dictionary.txt
В моем случае он не сработал, пока я не удалил RID из каждого хеша.
Заключение
Главными маркерами для этого вида атаки являются:
множественные клиентские MS-SNTP запросы, отправляемые с одного хоста с разными RID-ами;
RID-ы в этих запросах принадлежат пользователям, а не компьютерам;
изменение атрибута userAccountControl пользовательской учетной записи с UF_NORMAL_ACCOUNT (0x0200) на UF_WORKSTATION_TRUST_ACCOUNT (0x1000) и обратно;
добавление завершающего символа “$” к sAMAccountName пользовательского аккаунта.
Эта техника применима, когда злоумышленник с правами доменного администратора хочет получить пароль одного или нескольких пользователей организации, не привлекая к себе лишнего внимания, которое могут вызвать более распространенные методы.
Ссылки
https://www.secura.com/uploads/whitepapers/Secura-WP-Timeroasting-v3.pdf
https://github.com/SecuraBV/Timeroast/blob/main/timeroast.ps1
Заключение от переводчика
В статье впервые публично описано новое применение давно известной атаки. Без сомнения, данный инструментарий будет взят на вооружение злоумышленниками разных видов в самое ближайшее время. Кроме того, не стоит забывать про внутреннего нарушителя, который, потенциально, без повышения доменных привилегий сможет воспользоваться методом, поскольку его эксплуатация крайне проста для администратора. Представьте, что вы руководитель компании, а ваш админ хочет почитать вашу личную почту. Насколько сильно отличаются пароли в домене и ваших личных аккаунтах?
Для того, чтобы не стать жертвой атаки, мы можем дать следующие рекомендации простым пользователям:
использовать сложные пароли в корпоративных доменах, не ограничиваться сложностью, требуемой политиками организации;
не переиспользовать пароли и принципы их формирования для личных и корпоративных аккаунтов;
использовать двухфакторную аутентификацию везде, где она поддерживается.
Администраторам и архитекторам инфраструктуры:
внедрять средства двухфакторной аутентификации для всех критичных сервисов;
внедрить проверку паролей по спискам (а в идеале – и по логике формирования, точнее, ее отсутствию) в доменных службах;
по возможности уходить в сторону технологий passwordless.
Специалистам ИБ:
поставить маркеры, описанные автором на мониторинг;
внедрить PAM: он значительно повышает защиту от внутреннего нарушителя;
максимально сократить число лиц, допущенных к использованию привилегированных УЗ, входящих в группу Domain Admins.
