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

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

  • Статья

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

Симптомы

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

Представляем золотую атаку GMSA

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

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

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

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

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

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

Примечание.

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

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

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

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

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

  1. После раскрытия базы данных восстановление выполняется в "День D".

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

    Примечание.

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

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

  4. gMSA существуют и имеют прокат D-1.

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

  6. Компрометация происходит в D-5, и некоторые gMSA были созданы в эту дату.

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

  1. gMSA, созданные между D и D-5, не связаны*.

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

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

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

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

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

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

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

Решение

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

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

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

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

Примечание.

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

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

  1. Переведите контроллер домена в автономный режим и изолируйте его от сети.

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

    Если интервал пароля для gMSA больше, чем возраст резервной копии, вы можете разрешить окно, в котором по-прежнему работает предыдущий материал ключа. Если вы не можете ждать так долго, а в соответствующей более старой резервной копии отсутствует слишком много gMSA, необходимо переключить план на сценарий 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, все последующие gMSA также используют новый ключ.

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

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

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

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

    Примечание.

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

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

    Примечание.

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

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

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

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

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

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

Примечание.

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

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

  1. Отключите все существующие gMSA и пометьте их как учетные записи для удаления. Для этого для каждой учетной записи присвойте 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 и субъектов-служб( SPN), связанных с каждым gMSA, помеченным как удаляемая.

    4. Измените существующие gMSA, чтобы удалить имена узлов SPN и DNS.

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

      Примечание.

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

  3. Проверьте новые gMSA, чтобы убедиться, что они используют новый объект корневого ключа 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, все последующие gMSA также используют новый ключ.

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

  5. Удалите старые gMSA, которые использовали старый объект корневого ключа 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, и вы можете позволить себе временной период для смены паролей. Вам не нужно повторно создавать gMSA.

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

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

Примечание.

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

В домене, где содержится gMSA, которые необходимо свернуть, выполните следующие действия.

  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, все последующие gMSA также используют новый ключ.

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

    Примечание.

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

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

    Примечание.

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

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

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

Ссылки

Общие сведения о групповых управляемых учетных записях служб

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

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