Поделиться через

Как восстановиться после атаки Golden gMSA

  • Статья

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

Симптомы

Описание атаки Golden gMSA см. в следующей статье Semperis:

Введение в атаку Золотой ГМСА

Описание в приведенной выше статье является точным. Способ устранения проблемы заключается в замене корневого объекта ключа KDS (kdssvc.dll) службы распространения ключей Майкрософт и всех GMSAs, использующих скомпрометированный корневой ключ KDS.

Дополнительная информация

В успешной атаке на gMSA злоумышленник получает все важные атрибуты объекта корневого ключа KDS и Sid msds-ManagedPasswordID атрибуты объекта gMSA.

Атрибут msds-ManagedPasswordID присутствует только в записываемой копии домена. Таким образом, если база данных контроллера домена предоставляется, только домен, на котором размещен контроллер домена, открыт для атаки Golden gMSA. Однако если злоумышленник может пройти проверку подлинности в контроллере домена другого домена в лесу, злоумышленник может иметь достаточные разрешения для получения содержимого msds-ManagedPasswordID. Затем злоумышленник может использовать эту информацию для создания атаки на gMSAs в дополнительных доменах.

Чтобы защитить дополнительные домены леса после предоставления одного домена, необходимо заменить все gMSAs в доступном домене, прежде чем злоумышленник сможет использовать эту информацию. Как правило, вы не знаете подробностей того, что было предоставлено. Поэтому рекомендуется применить разрешение ко всем доменам леса.

В качестве упреждающей меры аудит можно использовать для отслеживания воздействия объекта корневого ключа KDS. Список управления доступом системы (SACL) с успешными считываниями можно поместить в контейнер главных корневых ключей, который позволяет выполнять аудит успешных операций чтения по msKds-RootKeyData атрибуту msKds-ProvRootKey класса. Это действие определяет ландшафт воздействия объекта относительно атаки Golden gMSA.

Примечание.

Аудит помогает обнаруживать только сетевые атаки на данные корневого ключа KDS.

Можно задать ManagedPasswordIntervalInDays параметр в 15 дней или выбрать соответствующее значение при создании gMSA, так как ManagedPasswordIntervalInDays значение становится доступным только для чтения после создания gMSA.

В случае компрометации этот параметр может сократить следующее время наката.

Это приведет к сокращению теоретических значений gMSA для повторного создания между датой восстановленной резервной копии и концом воздействия базы данных или, по крайней мере, длительностью окна риска до тех пор, пока эти gMSA не будут выполняться , если придерживаться сценария 1.

Ниже приведен пример сценария:

  1. После воздействия базы данных вы выполните восстановление в day D.

  2. Восстановленная резервная копия выполняется из D-15.

    Примечание.

    D-15 означает день, который 15 дней до "День D".

  3. Значение gMSA ManagedPasswordIntervalInDays равно 15.

  4. GMSAs существуют и имеют свернутый D-1.

  5. Новые gMSAs были созданы из D-10.

  6. Компромисс происходит на D-5, и некоторые gMSAs были созданы на этой дате.

Результаты приведены ниже.

  1. GMSAs, созданные между D и D-5, не обеспокоены*.

  2. GMSAs, созданные между D-15 (восстановление резервной копии) и D-5 (компрометация),* необходимо повторно создать или предположить, что окна риска должны быть выполнены, если можно ожидать от D+5 до D+10. Например:

    • В D+5 необходимо повторно создать gMSAs, созданные на D-10.
    • На D+10 необходимо повторно создать gMSAs, созданные на D-5.

    *Зависит от точного времени компрометации или резервного копирования.

Ниже приведен пример временной шкалы:

Схема примера временной шкалы gMSAs.

Для отладки можно просмотреть идентификаторы событий для журнала событий System, Security, Directory Services и Security-Netlogon.

Дополнительные сведения о компрометации см. в статье "Использование ресурсов безопасности Майкрософт и Azure" для восстановления от системного компрометации удостоверений.

Решение

Чтобы устранить эту проблему, используйте один из следующих подходов в зависимости от вашей ситуации. Подходы включают создание нового объекта корневого ключа KDS и перезапуск службы распространения ключей Майкрософт на всех контроллерах домена.

Сценарий 1. У вас есть надежные сведения о том, какая информация была предоставлена и когда

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

Подход заключается в создании нового объекта корневого ключа KDS, неизвестного злоумышленнику. Когда gMSAs свернуть пароль, они переместятся на новый объект корневого ключа KDS. Чтобы исправить gMSAs, которые недавно свернули пароль с помощью старого корневого ключа KDS, для принудительного обновления пароля сразу после восстановления требуется авторивное восстановление.

Примечание.

  • Вам не нужно вручную восстанавливать объекты GMSAs, созданные после завершения воздействия базы данных домен Active Directory Служб (AD DS). Злоумышленник не знает сведения об этих учетных записях, а пароли для этих учетных записей будут повторно создаваться на основе нового объекта корневого ключа KDS.
  • Следует учитывать объект gMSA в режиме обслуживания, пока процедура не будет завершена, и игнорировать возможные ошибки, сообщаемые с учетными записями в журнале событий System, Security, Directory Services и Security-Netlogon.
  • В руководстве предполагается, что gMSAs являются дочерними объектами контейнера управляемых учетных записей служб. Если учетные записи перемещены в пользовательские родительские контейнеры, необходимо выполнить действия, связанные с контейнером управляемых учетных записей служб в gMSA в этих контейнерах.
  • Авторитетное восстановление откатывает все атрибуты в состояние, в которое они находились во время резервной копии, включая учетные записи, разрешенные для получения учетных данных gMSA (PrincipalsAllowedToRetrieveManagedPassword).

В домене с gMSAs, которые требуется восстановить, выполните следующие действия:

  1. Отключите контроллер домена и изолируйте его от сети.

  2. Восстановите контроллер домена из резервной копии, созданной до воздействия базы данных AD DS.

    Если интервал пароля для gMSAs превышает возраст резервной копии, может потребоваться разрешить окно, в котором по-прежнему работает предыдущий материал ключа. Если вы не можете ждать, что долго, и сопоставление более старой резервной копии отсутствует слишком много gMSAs, необходимо переключить план на сценарий 2.

  3. Выполните достоверную операцию восстановления в контейнере управляемых учетных записей служб домена. Убедитесь, что операция восстановления включает все дочерние объекты контейнеров, которые могут быть связаны с этим контроллером домена. Этот шаг откатает состояние последнего обновления пароля. При следующем получении пароля служба будет обновлена до новой, основанной на новом объекте корневого ключа KDS.

  4. Остановите и отключите службу распространения ключей Майкрософт на восстановленном контроллере домена.

  5. На другом контроллере домена выполните действия, описанные в разделе "Создание корневого ключа KDS служб распространения ключей" для создания нового объекта корневого ключа KDS.

    Примечание.

    В рабочей среде необходимо ждать 10 часов, чтобы обеспечить доступность нового корневого ключа KDS. Проверьте атрибут, EffectiveTime чтобы узнать, когда новый корневой ключ KDS будет использоваться.

  6. Перезапустите службу распространения ключей Майкрософт на всех контроллерах домена.

  7. Создание нового gMSA. Убедитесь, что новый объект gMSA использует новый объект корневого ключа KDS для создания значения атрибута msds-ManagedPasswordID .

    Примечание.

    Этот шаг является необязательным, но он позволяет проверить, что новый корневой ключ KDS в настоящее время используется и используется в службе распространения ключей Майкрософт.

  8. msds-ManagedPasswordID Проверьте значение первого созданного gMSA. Значением этого атрибута являются двоичные данные, которые включают GUID соответствующего объекта корневого ключа KDS.

    Например, предположим, что объект корневого ключа KDS имеет следующее CN.

    Снимок экрана: значение атрибута CN объекта корневого ключа KDS.

    Объект gMSA, созданный с помощью этого объекта, имеет msds-ManagedPasswordID значение, похожее на следующее.

    Снимок экрана: значение атрибута msDS-ManagedPasswordId объекта gMSA, показывающее, как он включает в себя части атрибута CN корневого ключа KDS.

    В этом значении данные GUID начинаются со смещения 24. Части GUID находятся в другой последовательности. На этом изображении красные, зеленые и синие разделы определяют переупорядоченные части. Оранжевый раздел определяет часть последовательности, которая совпадает с исходным ИДЕНТИФИКАТОРом GUID.

    Если первый созданный ключ GMSA использует новый корневой ключ KDS, все последующие gMSAs также используют новый ключ.

  9. Отключите и остановите службу распространения ключей Майкрософт на всех контроллерах домена.

  10. Повторно подключитесь и верните восстановленный контроллер домена в режим "в сети". Убедитесь, что репликация работает.

    Теперь реплицируются достоверные изменения и все остальные изменения (включая восстановленные gMSAs).

  11. Повторно включите и запустите службу распространения ключей Майкрософт на всех контроллерах домена. Секреты восстановленных gMSAs будут свернуты, и новые пароли будут созданы на основе нового объекта корневого ключа KDS по запросу.

    Примечание.

    Если gMSA восстановлены, но не используются, и они PrincipalsAllowedToRetrieveManagedPassword заполнены параметром, можно запустить Test-ADServiceAccount командлет в восстановленной gMSA с помощью субъекта, который разрешено получить пароль. Если требуется изменение пароля, этот командлет перевернет gMSAs в новый корневой ключ KDS.

  12. Убедитесь, что все gMSAs свернуты.

    Примечание.

    GMSA без заполненного параметра никогда PrincipalsAllowedToRetrieveManagedPassword не будет выполняться.

  13. Удалите старый объект корневого ключа KDS и проверьте репликацию.

  14. Перезапустите службу распространения ключей Майкрософт на всех контроллерах домена.

Сценарий 2. Вы не знаете подробности воздействия объекта корневого ключа KDS, и вы не можете ждать, пока пароли будут свернуты.

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

В ходе следующего процесса необходимо создать новый объект корневого ключа KDS. Затем этот объект используется для замены всех gMSAs в доменах леса, использующих предоставленный корневой ключ KDS.

Примечание.

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

Выполните следующие действия:

  1. Отключите все существующие gMSAs и пометьте их как учетные записи, которые нужно удалить. Для этого для каждой учетной записи задайте для атрибута userAccountControl значение 4098 (это значение объединяет флаги WORKSTATION_TRUST_ACCOUNT и ACCOUNTDISABLE (отключено).

    Для задания учетных записей можно использовать сценарий PowerShell, как показано ниже.

     $Domain = (Get-ADDomain).DistinguishedName
 $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter 'objectclass=msDS-GroupManagedServiceAccount').DistinguishedName
 ForEach ($GMSA In $DomainGMSAs)
 {
     Set-ADObject "$GMSA" -Add @{ adminDescription='cleanup-gsma' } -Replace @{ userAccountControl=4098 }
 }

  2. Используйте один контроллер домена и выполните следующие действия.

    1. Выполните действия, описанные в разделе "Создание корневого ключа KDS служб распространения ключей" для создания нового объекта корневого ключа KDS.

    2. Перезапустите службу распространения ключей Майкрософт. После перезапуска служба получает новый объект.

    3. Резервное копирование имен узлов DNS и имен субъектов-служб, связанных с каждой gMSA, помеченной как удаленная.

    4. Измените существующие gMSAs, чтобы удалить имена субъектов-служб и DNS-узлов.

    5. Создайте новые gMSAs для замены существующих gMSAs. Они также должны быть настроены с именами узлов DNS и именами субъектов-служб, которые вы только что удалили.

      Примечание.

      Кроме того, необходимо просмотреть все записи разрешений с помощью непосредственно удаленных идентификаторов SID GMSA, так как они больше не разрешаются. При замене записи управления доступом (ACE) рекомендуется использовать группы для управления записями разрешений gMSA.

  3. Проверьте новые gMSAs, чтобы убедиться, что они используют новый объект корневого ключа KDS. Для этого выполните следующие шаги.

    1. Обратите внимание на CN значение (GUID) объекта корневого ключа KDS.

    2. msds-ManagedPasswordID Проверьте значение первого созданного gMSA. Значением этого атрибута являются двоичные данные, которые включают GUID соответствующего объекта корневого ключа KDS.

      Например, предположим, что объект корневого ключа KDS имеет следующее CN.

      Снимок экрана: значение атрибута CN объекта корневого ключа KDS.

      Объект gMSA, созданный с помощью этого объекта, имеет msds-ManagedPasswordID значение, похожее на изображение.

      Снимок экрана: значение атрибута msDS-ManagedPasswordId объекта gMSA, показывающее, как он включает в себя части атрибута CN корневого ключа KDS.

      В этом значении данные GUID начинаются со смещения 24. Части GUID находятся в другой последовательности. На этом изображении красные, зеленые и синие разделы определяют переупорядоченные части. Оранжевый раздел определяет часть последовательности, которая совпадает с исходным ИДЕНТИФИКАТОРом GUID.

      Если первый созданный ключ GMSA использует новый корневой ключ KDS, все последующие gMSAs также используют новый ключ.

  4. Обновите соответствующие службы, чтобы использовать новые gMSAs.

  5. Удалите старые объекты gMSAs, которые использовали старый объект корневого ключа KDS с помощью следующего командлета:

    $Domain = (Get-ADDomain).DistinguishedName
$DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter '(&(objectClass=msDS-GroupManagedServiceAccount)(adminDescription=cleanup-gsma))').DistinguishedName
ForEach ($GMSA In $DomainGMSAs)
{
    Remove-ADObject "$GMSA" -Confirm:$False
}

  6. Удалите старый объект корневого ключа KDS и проверьте репликацию.

  7. Перезапустите службу распространения ключей Майкрософт на всех контроллерах домена.

Сценарий 3. Отставка администратора домена, информация не была украдена в то время, и вы можете ждать, пока пароли будут свернуты.

Если член с высоким уровнем привилегий с администраторами домена или эквивалентными правами ушел в отставку, в то время нет доказательств воздействия корневого ключа KDS, и вы можете позволить себе временное окно для переключения паролей. Вам не нужно повторно создавать gMSAs.

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

Создается новый объект корневого ключа KDS, и gMSAs будет выполняться естественным образом.

Примечание.

Сведения о компрометации, связанной с администратором домена, см. в сценарии 1 или сценарии 2 в соответствии с тем, что было предоставлено, и следуйте локальным действиям по исправлению в разделе "Использование ресурсов безопасности Microsoft и Azure для восстановления от системного компрометации удостоверений".

В домене с gMSAs, которые требуется свернуть, выполните следующие действия:

  1. На контроллере домена выполните действия, описанные в разделе "Создание корневого ключа служб распространения ключей KDS", чтобы создать новый объект корневого ключа KDS.

    Примечание.

    В рабочей среде необходимо ждать 10 часов, чтобы обеспечить доступность нового корневого ключа KDS. Проверьте атрибут, EffectiveTime чтобы узнать, когда новый корневой ключ KDS будет использоваться.

  2. Перезапустите службу распространения ключей Майкрософт на всех контроллерах домена.

  3. Создание нового gMSA. Убедитесь, что новый объект gMSA использует новый объект корневого ключа KDS для создания значения атрибута msds-ManagedPasswordID .

    Примечание.

    Этот шаг является необязательным, но он позволяет проверить, что новый корневой ключ KDS в настоящее время используется и используется в службе распространения ключей Майкрософт.

  4. msds-ManagedPasswordID Проверьте значение первого созданного gMSA. Значением этого атрибута являются двоичные данные, которые включают GUID соответствующего объекта корневого ключа KDS.

    Например, предположим, что объект корневого ключа KDS имеет следующее CN.

    Снимок экрана: значение атрибута CN объекта корневого ключа KDS.

    Объект gMSA, созданный с помощью этого объекта, имеет msds-ManagedPasswordID значение, похожее на следующее изображение.

    Снимок экрана: значение атрибута msDS-ManagedPasswordId объекта gMSA, показывающее, как он включает в себя части атрибута CN корневого ключа KDS.

    В этом значении данные GUID начинаются со смещения 24. Части GUID находятся в другой последовательности. На этом изображении красные, зеленые и синие разделы определяют переупорядоченные части. Оранжевый раздел определяет часть последовательности, которая совпадает с исходным ИДЕНТИФИКАТОРом GUID.

    Если первый созданный ключ GMSA использует новый корневой ключ KDS, все последующие gMSAs также используют новый ключ.

  5. В зависимости от следующего свертывания паролей секреты gMSAs будут естественно свернуты, а новые пароли будут созданы на основе нового объекта корневого ключа KDS по запросу.

    Примечание.

    Если используемые gMSAs свернуты, но неиспользуемые gMSAs с тем же интервалом свертки не были, и они PrincipalsAllowedToRetrieveManagedPassword заполнены параметром, можно запустить Test-ADServiceAccount командлет. Он использует субъект, который может получить пароль gMSA, и этот шаг затем перемещает gMSA в новый корневой ключ KDS.

  6. Убедитесь, что все gMSAs свернуты.

    Примечание.

    GMSA без параметра никогда PrincipalsAllowedToRetrieveManagedPassword не будет выполняться.

  7. После того как все gMSAs перевернулись в новый объект корневого ключа KDS, удалите старый объект корневого ключа KDS и проверьте репликацию.

  8. Перезапустите службу распространения ключей Майкрософт на всех контроллерах домена.

Ссылки

Group Managed Service Accounts Overview (Обзор групповых управляемых учетных записей служб);

Заявление об отказе от ответственности за контактные данные сторонней организации

Корпорация Майкрософт предоставляет контактные данные сторонних производителей в целях получения дополнительных сведений по данной теме. Эти данные могут быть изменены без предварительного уведомления. Корпорация Майкрософт не гарантирует точность контактных данных сторонних производителей.