다음을 통해 공유

골든 gMSA 공격으로부터 복구하는 방법

  • 아티클

이 문서에서는 도메인 컨트롤러 데이터베이스 노출 인시던트에 의해 영향을 받는 gMSA(그룹 관리 서비스 계정)의 자격 증명을 복구하는 방법을 설명합니다.

증상

Golden gMSA 공격에 대한 설명은 다음 Semperis 문서를 참조하세요.

골든 GMSA 공격 소개

위 문서의 설명은 정확합니다. 문제를 해결하기 위한 방법은 Microsoft 키 배포 서비스(KDS라고도 하는kdssvc.dll) 루트 키 개체와 손상된 KDS 루트 키 개체를 사용하는 모든 gMSA를 대체하는 것입니다.

추가 정보

gMSA에 대한 공격에 성공하면 공격자는 KDS 루트 키 개체의 모든 중요한 특성과 Sid gMSA 개체의 및 msds-ManagedPasswordID 특성을 가져옵니다.

특성은 msds-ManagedPasswordID 도메인의 쓰기 가능한 복사본에만 있습니다. 따라서 도메인 컨트롤러의 데이터베이스가 노출되면 도메인 컨트롤러가 호스트하는 도메인만 Golden gMSA 공격에 노출됩니다. 그러나 공격자가 포리스트에 있는 다른 도메인의 도메인 컨트롤러에 인증할 수 있는 경우 공격자는 의 msds-ManagedPasswordID콘텐츠를 가져올 수 있는 충분한 권한이 있을 수 있습니다. 그런 다음 공격자는 이 정보를 사용하여 추가 도메인에서 gMSA에 대한 공격을 만들 수 있습니다.

한 도메인이 노출된 후 포리스트의 추가 도메인을 보호하려면 공격자가 정보를 사용하기 전에 노출된 도메인의 모든 gMSA를 바꿔야 합니다. 일반적으로 노출된 내용의 세부 정보를 알 수 없습니다. 따라서 포리스트의 모든 도메인에 해결 방법을 적용하는 것이 좋습니다.

사전 예방 조치로 감사를 사용하여 KDS 루트 키 개체의 노출을 추적할 수 있습니다. 읽기가 성공한 SACL(시스템 액세스 제어 목록)은 마스터 루트 키 컨테이너에 배치할 수 있으며, 이를 통해 클래스의 msKds-ProvRootKey 특성에 대한 msKds-RootKeyData 성공적인 읽기를 감사할 수 있습니다. 이 작업은 골든 gMSA 공격과 관련된 개체의 노출 환경을 결정합니다.

참고

감사는 KDS 루트 키 데이터에 대한 온라인 공격을 검색하는 데만 도움이 됩니다.

gMSA를 만든 후 값이 ManagedPasswordIntervalInDays 읽기 전용이 되므로 매개 변수를 15일로 ManagedPasswordIntervalInDays 설정하거나 gMSA를 만들 때 적절한 값을 선택하는 것이 좋습니다.

손상된 경우 이 설정은 다음 롤링 시간을 줄일 수 있습니다.

복원된 백업 날짜와 데이터베이스 노출 종료 사이에 다시 만들 gMSA의 이론적 수를 줄이거나, 시나리오 1을 고수하는 경우 이러한 gMSA가 롤될 때까지의 위험 기간 이상을 줄입니다.

예제 시나리오는 다음과 같습니다.

  1. 데이터베이스가 노출되면 "Day D"에서 복구를 수행합니다.

  2. 복원된 백업은 D-15에서 온 것입니다.

    참고

    D-15는 "D일"의 15일 전의 날을 의미합니다.

  3. gMSA ManagedPasswordIntervalInDays 값은 15입니다.

  4. gMSA가 존재하며 D-1을 롤했습니다.

  5. 최신 gMSA는 D-10에서 만들어졌습니다.

  6. 손상은 D-5에서 발생하며 이 날짜에 일부 gMSA가 생성되었습니다.

결과는 다음과 같습니다.

  1. D와 D-5 간에 생성된 gMSA는 관련이* 없습니다.

  2. D-15(백업 복원)와 D-5(손상)* 사이에 생성된 gMSA를 다시 만들어야 합니다. 또는 D+5에서 D+10까지 기다릴 수 있는 경우 위험 창을 가정해야 합니다. 예:

    • D+5에서는 D-10에서 만든 gMSA를 다시 만들어야 합니다.
    • D+10에서는 D-5에서 만든 gMSA를 다시 만들어야 합니다.

    *손상 또는 백업의 정확한 시간에 따라 달라집니다.

다음은 타임라인의 예입니다.

예제 gMSA 타임라인 다이어그램

디버깅의 경우 시스템, 보안, 디렉터리 서비스 및 Security-Netlogon 이벤트 로그에 대한 이벤트 ID를 검토할 수 있습니다.

손상에 대한 자세한 내용은 Microsoft 및 Azure 보안 리소스를 사용하여 시스템 ID 손상으로부터 복구를 참조하세요.

해결 방법

이 문제를 해결하려면 상황에 따라 다음 방법 중 하나를 사용합니다. 이 접근 방식에는 새 KDS 루트 키 개체를 만들고 도메인의 모든 도메인 컨트롤러에서 Microsoft 키 배포 서비스를 다시 시작하는 작업이 포함됩니다.

시나리오 1: 노출된 정보 및 시기에 대한 신뢰할 수 있는 정보가 있습니다.

노출이 특정 날짜 이전에 발생했으며 이 날짜가 가장 오래된 gMSA 암호보다 이전인 경우 아래 절차와 같이 gMSA를 다시 만들지 않고 문제를 해결할 수 있습니다.

이 방법은 공격자에게 알려지지 않은 새 KDS 루트 키 개체를 만드는 것입니다. gMSA가 암호를 롤하면 새 KDS 루트 키 개체를 사용하여 로 이동합니다. 이전 KDS 루트 키를 사용하여 최근에 암호를 롤백한 gMSA를 수정하려면 복원 직후 암호 업데이트를 강제로 적용하려면 신뢰할 수 있는 복원이 필요합니다.

참고

  • AD DS(Active Directory Domain Services) 데이터베이스 노출이 종료된 후에 만들어진 gMSA를 수동으로 복구할 필요가 없습니다. 공격자는 이러한 계정의 세부 정보를 알지 못하며 이러한 계정의 암호는 새 KDS 루트 키 개체를 기반으로 다시 생성됩니다.
  • 프로시저가 완료될 때까지 gMSA 개체를 "유지 관리 모드"로 간주하고 시스템, 보안, 디렉터리 서비스 및 Security-Netlogon 이벤트 로그의 계정으로 보고되는 가능한 오류를 무시해야 합니다.
  • 이 가이드에서는 gMSA가 관리 서비스 계정 컨테이너의 자식 개체라고 가정합니다. 계정을 사용자 지정 부모 컨테이너로 이동한 경우 이러한 컨테이너의 gMSA에서 관리 서비스 계정 컨테이너와 관련된 단계를 실행해야 합니다.
  • 신뢰할 수 있는 복원은 gMSA 자격 증명(PrincipalsAllowedToRetrieveManagedPassword)을 검색할 수 있는 계정을 포함하여 백업 당시의 상태로 모든 특성을 롤백합니다.

복구하려는 gMSA가 있는 도메인에서 다음 단계를 수행합니다.

  1. 도메인 컨트롤러를 오프라인으로 전환하고 네트워크에서 격리합니다.

  2. AD DS 데이터베이스 노출 전에 만든 백업에서 도메인 컨트롤러를 복원합니다.

    gMSA의 암호 간격이 백업 기간보다 긴 경우 이전 키 자료가 계속 작동하는 창을 허용하도록 결정할 수 있습니다. 오래 기다릴 수 없고 일치하는 이전 백업에 너무 많은 gMSA가 누락된 경우 계획을 시나리오 2로 전환해야 합니다.

  3. 도메인의 관리 서비스 계정 컨테이너에서 신뢰할 수 있는 복원 작업을 실행합니다. 복원 작업에 이 도메인 컨트롤러와 연결될 수 있는 모든 컨테이너의 자식 개체가 포함되어 있는지 확인합니다. 이 단계에서는 마지막 암호 업데이트 상태를 롤백합니다. 다음에 서비스에서 암호를 검색하면 새 KDS 루트 키 개체를 기반으로 암호가 새 암호로 업데이트됩니다.

  4. 복원된 도메인 컨트롤러에서 Microsoft 키 배포 서비스를 중지하고 사용하지 않도록 설정합니다.

  5. 다른 도메인 컨트롤러에서 키 배포 서비스 KDS 루트 키 만들기의 단계에 따라 새 KDS 루트 키 개체를 만듭니다.

    참고

    프로덕션 환경에서는 새 KDS 루트 키를 사용할 수 있도록 10시간을 기다려야 합니다. EffectiveTime 특성을 확인하여 새 KDS 루트 키를 사용할 수 있는 시기를 확인합니다.

  6. 모든 도메인 컨트롤러에서 Microsoft 키 배포 서비스를 다시 시작합니다.

  7. 새 gMSA를 만듭니다. 새 gMSA에서 새 KDS 루트 키 개체를 사용하여 특성에 대한 msds-ManagedPasswordID 값을 만들어야 합니다.

    참고

    이 단계는 선택 사항이지만 새 KDS 루트 키가 현재 사용 중이며 Microsoft 키 배포 서비스에서 사용되고 있는지 확인할 수 있습니다.

  8. msds-ManagedPasswordID 만든 첫 번째 gMSA의 값을 확인합니다. 이 특성의 값은 일치하는 KDS 루트 키 개체의 GUID를 포함하는 이진 데이터입니다.

    예를 들어 KDS 루트 키 개체에 다음 CN가 있다고 가정합니다.

    KDS 루트 키 개체의 CN 특성 값을 보여 주는 스크린샷

    이 개체를 사용하여 만든 gMSA에는 msds-ManagedPasswordID 다음과 유사한 값이 있습니다.

    gMSA 개체의 msDS-ManagedPasswordId 특성 값의 스크린샷- KDS 루트 키 CN 특성의 부분을 포함하는 방법을 보여 줍니다.

    이 값에서 GUID 데이터는 오프셋 24에서 시작합니다. GUID 부분은 다른 시퀀스에 있습니다. 이 이미지에서 빨간색, 녹색 및 파란색 섹션은 순서가 다시 지정된 부분을 식별합니다. 주황색 섹션은 원래 GUID와 동일한 시퀀스의 일부를 식별합니다.

    만든 첫 번째 gMSA에서 새 KDS 루트 키를 사용하는 경우 모든 후속 gMSA도 새 키를 사용합니다.

  9. 모든 도메인 컨트롤러에서 Microsoft 키 배포 서비스를 사용하지 않도록 설정하고 중지합니다.

  10. 복원된 도메인 컨트롤러를 다시 연결하고 다시 온라인 상태로 설정합니다. 복제가 작동하는지 확인합니다.

    이제 신뢰할 수 있는 복원 및 기타 모든 변경 내용(복원된 gMSA 포함)이 복제됩니다.

  11. 모든 도메인 컨트롤러에서 Microsoft 키 배포 서비스를 다시 사용하도록 설정하고 시작합니다. 복원된 gMSA의 비밀이 롤되고 요청 시 새 KDS 루트 키 개체를 기반으로 새 암호가 만들어집니다.

    참고

    gMSA가 복원되었지만 사용되지 않고 매개 변수가 PrincipalsAllowedToRetrieveManagedPassword 채워진 경우 암호를 검색할 수 있는 보안 주체를 사용하여 복원된 gMSA에서 cmdlet을 실행할 Test-ADServiceAccount 수 있습니다. 암호 변경이 필요한 경우 이 cmdlet은 gMSA를 새 KDS 루트 키로 롤아웃합니다.

  12. 모든 gMSA가 압연되었는지 확인합니다.

    참고

    매개 변수가 PrincipalsAllowedToRetrieveManagedPassword 채워지지 않은 gMSA는 롤되지 않습니다.

  13. 이전 KDS 루트 키 개체를 삭제하고 복제를 확인합니다.

  14. 모든 도메인 컨트롤러에서 Microsoft 키 배포 서비스를 다시 시작합니다.

시나리오 2: KDS 루트 키 개체 노출의 세부 정보를 모르고 암호가 롤되기를 기다릴 수 없습니다.

어떤 정보가 노출되었는지 또는 언제 노출되었는지 모르는 경우 이러한 노출은 Active Directory 포리스트에 대한 전체 노출의 일부일 수 있습니다. 이렇게 하면 공격자가 모든 암호에 대해 오프라인 공격을 실행할 수 있는 상황이 발생할 수 있습니다. 이 경우 포리스트 복구를 실행하거나 모든 계정 암호를 다시 설정하는 것이 좋습니다. gMSA를 정리 상태로 복구하는 것은 이 작업의 일부입니다.

다음 프로세스 중에는 새 KDS 루트 키 개체를 만들어야 합니다. 그런 다음 이 개체를 사용하여 노출된 KDS 루트 키 개체를 사용하는 포리스트 도메인의 모든 gMSA를 바꿉니다.

참고

다음 단계는 그룹 관리 서비스 계정 시작의 절차와 유사합니다. 그러나 몇 가지 중요한 변경 사항이 있습니다.

다음 단계를 따릅니다.

  1. 모든 기존 gMSA를 사용하지 않도록 설정하고 제거할 계정으로 표시합니다. 이렇게 하려면 각 계정에 대해 특성을 4098로 설정합니다userAccountControl(이 값은 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. Microsoft 키 배포 서비스를 다시 시작합니다. 다시 시작되면 서비스에서 새 개체를 선택합니다.

    3. 제거된 것으로 표시된 각 gMSA와 연결된 DNS 호스트 이름 및 SPN(서비스 사용자 이름)을 백업합니다.

    4. 기존 gMSA를 편집하여 SPN 및 DNS 호스트 이름을 제거합니다.

    5. 기존 gMSA를 대체할 새 gMSA를 만듭니다. 또한 방금 제거한 DNS 호스트 이름 및 SPN으로 구성해야 합니다.

      참고

      또한 더 이상 확인할 수 없으므로 직접 제거된 gMSA SID를 사용하여 모든 권한 항목을 검토해야 합니다. ACE(액세스 제어 항목)를 바꿀 때 그룹을 사용하여 gMSA 권한 항목을 관리하는 것이 좋습니다.

  3. 새 gMSA를 확인하여 새 KDS 루트 키 개체를 사용하는지 확인합니다. 이렇게 하려면 다음과 같이 하십시오.

    1. CN KDS 루트 키 개체의 (GUID) 값을 확인합니다.

    2. msds-ManagedPasswordID 만든 첫 번째 gMSA의 값을 확인합니다. 이 특성의 값은 일치하는 KDS 루트 키 개체의 GUID를 포함하는 이진 데이터입니다.

      예를 들어 KDS 루트 키 개체에 다음 CN가 있다고 가정합니다.

      KDS 루트 키 개체의 CN 특성 값 스크린샷

      이 개체를 사용하여 만든 gMSA에는 이미지와 msds-ManagedPasswordID 유사한 값이 있습니다.

      gMSA 개체의 msDS-ManagedPasswordId 특성 값의 스크린샷- KDS 루트 키 CN 특성의 부분을 포함하는 방법을 보여 줍니다.

      이 값에서 GUID 데이터는 오프셋 24에서 시작합니다. GUID 부분은 다른 시퀀스에 있습니다. 이 이미지에서 빨간색, 녹색 및 파란색 섹션은 순서가 다시 지정된 부분을 식별합니다. 주황색 섹션은 원래 GUID와 동일한 시퀀스의 일부를 식별합니다.

      만든 첫 번째 gMSA에서 새 KDS 루트 키를 사용하는 경우 모든 후속 gMSA도 새 키를 사용합니다.

  4. 새 gMSA를 사용하도록 적절한 서비스를 업데이트합니다.

  5. 다음 cmdlet을 사용하여 이전 KDS 루트 키 개체를 사용한 이전 gMSA를 삭제합니다.

    $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. 모든 도메인 컨트롤러에서 Microsoft 키 배포 서비스를 다시 시작합니다.

시나리오 3: 도메인 관리자 사임, 당시 정보가 도난당하지 않았으며 암호가 롤되기를 기다릴 수 있습니다.

도메인 관리자 또는 동등한 권한을 가진 권한이 높은 멤버가 사임하는 경우 당시 KDS 루트 키 노출에 대한 증거가 없으며 암호 롤링에 대한 기간을 감당할 수 있습니다. gMSA를 다시 만들 필요가 없습니다.

예방 조치로서 악용 후 공격을 방지하기 위해 KDS 루트 키를 롤백해야 합니다. 예를 들어, 이전 도메인 관리자는 불량으로 판명되어 일부 백업을 유지했습니다.

새 KDS 루트 키 개체가 만들어지고 gMSA가 자연스럽게 롤됩니다.

참고

도메인 관리자와 관련된 손상은 노출된 내용에 따라 시나리오 1 또는 시나리오 2 를 참조하고 "Microsoft 및 Azure 보안 리소스를 사용하여 시스템 ID 손상으로부터 복구하는 데 도움"의 온-프레미스 수정 작업을 따릅니다.

롤하려는 gMSA가 있는 도메인에서 다음 단계를 수행합니다.

  1. 도메인 컨트롤러에서 키 배포 서비스 KDS 루트 키 만들기의 단계에 따라 새 KDS 루트 키 개체를 만듭니다.

    참고

    프로덕션 환경에서는 새 KDS 루트 키를 사용할 수 있도록 10시간을 기다려야 합니다. EffectiveTime 특성을 확인하여 새 KDS 루트 키를 사용할 수 있는 시기를 확인합니다.

  2. 모든 도메인 컨트롤러에서 Microsoft 키 배포 서비스를 다시 시작합니다.

  3. 새 gMSA를 만듭니다. 새 gMSA에서 새 KDS 루트 키 개체를 사용하여 특성에 대한 msds-ManagedPasswordID 값을 만들어야 합니다.

    참고

    이 단계는 선택 사항이지만 새 KDS 루트 키가 현재 사용 중이며 Microsoft 키 배포 서비스에서 사용되고 있는지 확인할 수 있습니다.

  4. msds-ManagedPasswordID 만든 첫 번째 gMSA의 값을 확인합니다. 이 특성의 값은 일치하는 KDS 루트 키 개체의 GUID를 포함하는 이진 데이터입니다.

    예를 들어 KDS 루트 키 개체에 다음 CN가 있다고 가정합니다.

    KDS 루트 키 개체의 CN 특성 값 스크린샷

    이 개체를 사용하여 만든 gMSA에는 msds-ManagedPasswordID 다음 이미지와 유사한 값이 있습니다.

    gMSA 개체의 msDS-ManagedPasswordId 특성 값의 스크린샷- KDS 루트 키 CN 특성의 부분을 포함하는 방법을 보여 줍니다.

    이 값에서 GUID 데이터는 오프셋 24에서 시작합니다. GUID 부분은 다른 시퀀스에 있습니다. 이 이미지에서 빨간색, 녹색 및 파란색 섹션은 순서가 다시 지정된 부분을 식별합니다. 주황색 섹션은 원래 GUID와 동일한 시퀀스의 일부를 식별합니다.

    만든 첫 번째 gMSA에서 새 KDS 루트 키를 사용하는 경우 모든 후속 gMSA도 새 키를 사용합니다.

  5. 다음 암호 롤에 따라 gMSA의 비밀이 자연스럽게 롤되며 요청 시 새 KDS 루트 키 개체를 기반으로 새 암호가 만들어집니다.

    참고

    사용된 gMSA가 롤되었지만 동일한 롤 간격으로 사용되지 않는 gMSA가 없는 PrincipalsAllowedToRetrieveManagedPassword 경우 매개 변수가 채워져 있는 경우 cmdlet을 Test-ADServiceAccount 실행할 수 있습니다. gMSA 암호를 검색할 수 있는 보안 주체를 사용하고, 이 단계에서는 gMSA를 새 KDS 루트 키로 이동합니다.

  6. 모든 gMSA가 압연되었는지 확인합니다.

    참고

    매개 변수가 없는 gMSA는 PrincipalsAllowedToRetrieveManagedPassword 롤되지 않습니다.

  7. 모든 gMSA를 새 KDS 루트 키 개체로 압연한 후 이전 KDS 루트 키 개체를 삭제하고 복제를 확인합니다.

  8. 모든 도메인 컨트롤러에서 Microsoft 키 배포 서비스를 다시 시작합니다.

참조

그룹 관리 서비스 계정 개요

타사 연락처 고지

Microsoft는 이 항목에 대한 추가 정보를 찾는 데 도움이 되는 타사 연락처 정보를 제공합니다. 이 연락처 정보는 공지 없이 변경될 수 있습니다. Microsoft는 타사 연락처 정보의 정확성을 보장하지 않습니다.