Содержание статьи
В мае 2020 года я представил некоторые темы о безопасности Active Directory в Trimarc Webcast called “Securing Active Directory: Resolving Common Issues” и включил собранную мной информацию о безопасности групповых управляемых
учетных записей служб AD (GMSA). Этот пост включает расширенную версию атаки и защиты GMSA, о которой я рассказывал в веб-трансляции. Я собрал эту информацию после разговора кое с кем о использовании GMSA для запуска сервисов на серверах с привилегированными правами AD, и возникла путаница в том, что GMSA на самом деле делают, а что нет. Путаница, похоже, коренится в убеждении, что учетные данные GMSA защищены больше, чем обычные учетные записи (а это не так).
Ключевым преимуществом является то, что их пароли меняются автоматически, а не то, что учетные данные имеют более надежную защиту.
Этот пост призван подчеркнуть, что могут делать GMSA и что может сделать злоумышленник, если GMSA не защищены должным образом. Мы наблюдали ограниченное использование групповых управляемых учетных записей служб в средах AD при выполнении Active Directory Security Assessments at Trimarc. GMSA следует использовать везде, где это возможно, для замены учетных записей пользователей в качестве учетных записей служб, поскольку их пароли меняются автоматически.
Group Managed Service Accounts (GMSAs)
Учетные записи пользователей, созданные для использования в качестве учетных записей служб, редко изменяют свой пароль. Групповые управляемые учетные записи служб (GMSA) обеспечивают лучший подход (начиная с Windows 2012).
Пароль управляется AD и изменяется автоматически. Это означает, что GMSA должен иметь учётки, явно делегированных, чтобы иметь доступ к паролю в виде открытого текста. Как и в других областях, где делегирование контролирует доступ (LAPS),
необходимо тщательно продумать определение того, кому должен быть делегирован доступ.
Ключевые моменты Group Managed Service Accounts (GMSA):
Эти свойства включают:
Запустив командлет
которая имеет полные права администратора AD и DC в домене. На скриншоте показано, что пароль был изменен недавно и не будет меняться в течение нескольких недель - изменен 11.05.2020 и настроен на изменение каждые 30 дней.
Это означает, что если мы сможем получить пароль для этой учетной записи, у нас будет почти месяц, чтобы использовать учетные данные учетной записи, прежде чем она изменится. Мы также можем идентифицировать группу,
которая может получить данные пароля.
Получает доступ к серверу с запущеной службой GMSA
Как только мы попадаем на сервер / серверы, на которых запущены службы в контексте GMSA, у нас есть несколько вариантов. Давайте взглянем…
Мы можем определить, что сервер LCNSQL01 зарегистрирован как SPN в GMSA, и мы видим, что этот сервер находится в OU серверов.
Если мы cможем скомпрометировать учетную запись с правами на серверное подразделение или делегированные права администратора через группы с ограниченным доступом GPO или аналогичные,
или у нас появилась возможность изменить объект групповой политики, который связан с этим подразделением, мы можем получить права администратора на сервере LCN.
После получения прав администратора на сервере, связанном с GMSA, мы можем увидеть, что в контексте GMSA работает служба (здесь я вас обманул и настроил службу диспетчера лицензий Windows для запуска с этой учетной записью).
Поскольку в контексте учетной записи работает служба, мы можем получить данные пароля, связанные с учетной записью службы.
Здесь мы используем Mimikatz для сброса LSASS с помощью
Что интересно, пароль выглядит странно:
Это не стандартный пароль (и не тот, который связан с учетной записью). Более того, этот хэш пароля неверный!
Microsoft загружает учетные данные GMSA в LSASS, но, похоже, не использует их.
Чтобы получить правильный хэш пароля NT, нам нужно использовать команду Mimikatz
После выполнения этой команды, мы можем получить хэш пароля. С помощью этого хэша пароля мы можем передать хеш (Pass The Hash Attack) для взлома AD.
Но что, если мы не можем получить доступ к самому серверу?
Взлом учётки с помощью пароля GMSA
Мы знаем, что существует группа, у которой есть права на получение пароля GMSA, давайте взглянем:
msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) - этот атрибут содержит группу под названием «SVC-LAB-GMSA1 Group».
Этот атрибут определяет, кто может запрашивать и получать пароль в открытом виде.
При перечислении членства в группе «SVC-LAB-GMSA1 Group» получем компьютеры, пользователи и другая группа («Администраторы сервера»), поэтому давайте проверим членов этой группы:
Теперь у нас есть список всех учетных записей, которые могут получить пароль в открытом виде для GMSA. Существует 11 учетных записей пользователей с такой возможностью, и 9 из них выглядят как обычные учетные записи пользователей
(подсказка: они есть!). Это большая проблема. Взломав один из них, аккаунт GMSA будет скомпрометирован, и, поскольку он входит в группу администраторов в домене, мы завладеем доменом.
Как только мы скомпрометируем учетную запись пользователя (или компьютера!), Которая может получить пароль в виде открытого текста. (PrincipalsAllowedToRetriveManagedPassword), мы можем запросить его с помощью командлета
Мы можем использовать командлет
мы можем преобразовать большой двоичный объект пароля в виде открытого текста в хэш NT.
Если учетная запись, которую мы можем взломать, является учетной записью компьютера, нам необходимо запустить эти команды как SYSTEM на компьютере. Этот метод будет использоваться,
если мы сможем получить права admin/SYSTEM на сервере с правами на получение пароля GMSA, но GMSA не работает в контексте службы (поэтому запуск Mimikatz не помогает, поскольку GMSA нет в памяти).
Здесь я использую PSEXEC для создания командной оболочки, работающей в контексте локальной учетной записи SYSTEM. Запустившись как SYSTEM, мы можем выполнить то же действие, что показано выше.
Учетная запись компьютера имеет право запрашивать пароль, но не пользователь на этом компьютере, поэтому я повышаю уровень до SYSTEM, который затем взаимодействует с AD в качестве связанной учетной записи компьютера AD.
Теперь я могу получить пароль GMSA.
Следующим шагом, который я выполняю в лабораторной работе, является подтверждение того, что хэш пароля NT, который предоставляет DSInternals, соответствует таковому в Active Directory.
Я использую команду
Предотвращение атак
Большое спасибо Michael Grafnetter за его пост , предоставивший мне информацию, необходимую для прохождения этого процесса.
Также выжараю благодарность Benjamin Delpy, за помощь в тестировании последней версии Mimikatz с данными LSASS, содержащими учетные данные GMSA.
От ТС
Оригинал на en вот.
Спасибо weaver , за то что подкинул ресурс.
Перевод:
Azrv3l cпециально для xss.pro
- Вступление
- Group Manage Service Accounts
- Ключевые моменты
- Получает доступ к серверу с запущеной службой GMSA
- Взлом учётки с помощью пароля GMSA
- Предотвращение атак
- Благодарности
В мае 2020 года я представил некоторые темы о безопасности Active Directory в Trimarc Webcast called “Securing Active Directory: Resolving Common Issues” и включил собранную мной информацию о безопасности групповых управляемых
учетных записей служб AD (GMSA). Этот пост включает расширенную версию атаки и защиты GMSA, о которой я рассказывал в веб-трансляции. Я собрал эту информацию после разговора кое с кем о использовании GMSA для запуска сервисов на серверах с привилегированными правами AD, и возникла путаница в том, что GMSA на самом деле делают, а что нет. Путаница, похоже, коренится в убеждении, что учетные данные GMSA защищены больше, чем обычные учетные записи (а это не так).
Ключевым преимуществом является то, что их пароли меняются автоматически, а не то, что учетные данные имеют более надежную защиту.
Этот пост призван подчеркнуть, что могут делать GMSA и что может сделать злоумышленник, если GMSA не защищены должным образом. Мы наблюдали ограниченное использование групповых управляемых учетных записей служб в средах AD при выполнении Active Directory Security Assessments at Trimarc. GMSA следует использовать везде, где это возможно, для замены учетных записей пользователей в качестве учетных записей служб, поскольку их пароли меняются автоматически.
Group Managed Service Accounts (GMSAs)
Учетные записи пользователей, созданные для использования в качестве учетных записей служб, редко изменяют свой пароль. Групповые управляемые учетные записи служб (GMSA) обеспечивают лучший подход (начиная с Windows 2012).
Пароль управляется AD и изменяется автоматически. Это означает, что GMSA должен иметь учётки, явно делегированных, чтобы иметь доступ к паролю в виде открытого текста. Как и в других областях, где делегирование контролирует доступ (LAPS),
необходимо тщательно продумать определение того, кому должен быть делегирован доступ.
Ключевые моменты Group Managed Service Accounts (GMSA):
- Пароли GMSA управляются AD
- Компьютеры с развёрнутыми GMSA службами, должны запросить у AD актуальный пароль для того что-бы запустить службу.
- Доступ учёных записей компьютеров к паролю, требует настройки GMSA
- Если злоумышленник взламывает службы хостинга с помощью GMSA, GMSA считается скомпрометированным.
- Если злоумышленник скомпрометирует учетную запись с правами на запрос пароля GMSA, GMSA считается скомпрометированным.
Эти свойства включают:
- msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) - хранит учётки, которые могут получить доступ к паролю GMSA.
- msds-ManagedPassword - этот атрибут содержит BLOB с паролем для учетных записей служб.
- msDS-ManagedPasswordId – этот сконструированный атрибут содержит идентификатор ключа для данных текущего управляемого пароля .
- msDS-ManagedPasswordInterval – этот атрибут используется для получения количества дней до автоматической смены управляемого пароля для группы MSA.
Запустив командлет
Get-ADServiceAccount, мы можем получить информацию о GMSA, включая конкретные атрибуты GMSA. Этот GMSA является членом группы администраторов домена, которая имеет полные права администратора AD и DC в домене. На скриншоте показано, что пароль был изменен недавно и не будет меняться в течение нескольких недель - изменен 11.05.2020 и настроен на изменение каждые 30 дней.
Это означает, что если мы сможем получить пароль для этой учетной записи, у нас будет почти месяц, чтобы использовать учетные данные учетной записи, прежде чем она изменится. Мы также можем идентифицировать группу,
которая может получить данные пароля.
Получает доступ к серверу с запущеной службой GMSA
Как только мы попадаем на сервер / серверы, на которых запущены службы в контексте GMSA, у нас есть несколько вариантов. Давайте взглянем…
Мы можем определить, что сервер LCNSQL01 зарегистрирован как SPN в GMSA, и мы видим, что этот сервер находится в OU серверов.
Если мы cможем скомпрометировать учетную запись с правами на серверное подразделение или делегированные права администратора через группы с ограниченным доступом GPO или аналогичные,
или у нас появилась возможность изменить объект групповой политики, который связан с этим подразделением, мы можем получить права администратора на сервере LCN.
После получения прав администратора на сервере, связанном с GMSA, мы можем увидеть, что в контексте GMSA работает служба (здесь я вас обманул и настроил службу диспетчера лицензий Windows для запуска с этой учетной записью).
Поскольку в контексте учетной записи работает служба, мы можем получить данные пароля, связанные с учетной записью службы.
Здесь мы используем Mimikatz для сброса LSASS с помощью
sekurlsa::logonpasswords. Что интересно, пароль выглядит странно:
“_SA_{262E99C9-6160-4871-ACEC-4E61736B6F21}”Это не стандартный пароль (и не тот, который связан с учетной записью). Более того, этот хэш пароля неверный!
Microsoft загружает учетные данные GMSA в LSASS, но, похоже, не использует их.
Чтобы получить правильный хэш пароля NT, нам нужно использовать команду Mimikatz
Sekurlsa::ekeys, которая используется для получения билетов Kerberos.
После выполнения этой команды, мы можем получить хэш пароля. С помощью этого хэша пароля мы можем передать хеш (Pass The Hash Attack) для взлома AD.
Но что, если мы не можем получить доступ к самому серверу?
Взлом учётки с помощью пароля GMSA
Мы знаем, что существует группа, у которой есть права на получение пароля GMSA, давайте взглянем:
msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) - этот атрибут содержит группу под названием «SVC-LAB-GMSA1 Group».
Этот атрибут определяет, кто может запрашивать и получать пароль в открытом виде.
При перечислении членства в группе «SVC-LAB-GMSA1 Group» получем компьютеры, пользователи и другая группа («Администраторы сервера»), поэтому давайте проверим членов этой группы:
Теперь у нас есть список всех учетных записей, которые могут получить пароль в открытом виде для GMSA. Существует 11 учетных записей пользователей с такой возможностью, и 9 из них выглядят как обычные учетные записи пользователей
(подсказка: они есть!). Это большая проблема. Взломав один из них, аккаунт GMSA будет скомпрометирован, и, поскольку он входит в группу администраторов в домене, мы завладеем доменом.
Как только мы скомпрометируем учетную запись пользователя (или компьютера!), Которая может получить пароль в виде открытого текста. (PrincipalsAllowedToRetriveManagedPassword), мы можем запросить его с помощью командлета
Get-ADServiceAccount. Мы можем использовать командлет
Get-ADServiceAccount, чтобы получить данные пароля в открытом виде для GMSA (атрибут msds-ManagedPassword). Используя модуль DSInternals (ConvertTo-NTHash), мы можем преобразовать большой двоичный объект пароля в виде открытого текста в хэш NT.
Если учетная запись, которую мы можем взломать, является учетной записью компьютера, нам необходимо запустить эти команды как SYSTEM на компьютере. Этот метод будет использоваться,
если мы сможем получить права admin/SYSTEM на сервере с правами на получение пароля GMSA, но GMSA не работает в контексте службы (поэтому запуск Mimikatz не помогает, поскольку GMSA нет в памяти).
Здесь я использую PSEXEC для создания командной оболочки, работающей в контексте локальной учетной записи SYSTEM. Запустившись как SYSTEM, мы можем выполнить то же действие, что показано выше.
Учетная запись компьютера имеет право запрашивать пароль, но не пользователь на этом компьютере, поэтому я повышаю уровень до SYSTEM, который затем взаимодействует с AD в качестве связанной учетной записи компьютера AD.
Теперь я могу получить пароль GMSA.
Следующим шагом, который я выполняю в лабораторной работе, является подтверждение того, что хэш пароля NT, который предоставляет DSInternals, соответствует таковому в Active Directory.
Я использую команду
Get-ADReplAccount из DSInternals, чтобы получить хэш пароля AD и могу заверить, что хеш пароля, полученный из GMSA, такой же, как полученный из AD.
Предотвращение атак
- Определите фактически необходимые права и убедитесь, что к GMSA применимы только необходимые ограниченные права.
- Не добавляйте в привилегированные группы AD, если серверы, на которых используются GMSA, не ограничены уровнем 0 (контроллеры домена).
- Ограничьте доступ и местоположение GMSA (особенно, если есть привилегии).
Большое спасибо Michael Grafnetter за его пост , предоставивший мне информацию, необходимую для прохождения этого процесса.
Также выжараю благодарность Benjamin Delpy, за помощь в тестировании последней версии Mimikatz с данными LSASS, содержащими учетные данные GMSA.
От ТС
Оригинал на en вот.
Спасибо weaver , за то что подкинул ресурс.
Перевод:
Azrv3l cпециально для xss.pro