그룹 관리 서비스 계정을 안전하게 보호하기

그룹 관리 서비스 계정 개요

일반 사용자 계정을 서비스 계정으로 사용하는 기존 방식은 비밀번호 관리 책임을 사용자에게 전가합니다. 그 결과 계정 비밀번호가 수년 동안 그대로 유지되는 경우가 많아지며, 이는 무차별 대입 공격(brute force)과 오용에 매우 취약하게 만듭니다. 그룹 관리 서비스 계정(gMSAs)은 자동 작업, 서비스 및 애플리케이션을 실행하는 더 안전한 방법을 제공합니다.

gMSA는 Windows Server 2016에 도입되었으며, Windows Server 2012 이상에서 활용할 수 있습니다. gMSA 비밀번호는 Windows에서 완전히 처리합니다. 비밀번호는 무작위로 생성되고 자동으로 주기적으로 교체됩니다. 또한 서비스 계정 자체가 런타임에 비밀번호 정보를 조회할 서버에 ‘설치’되기 때문에, 어떤 사용자도 비밀번호를 알 필요가 없습니다. Active Directory 그 결과, gMSA는 서비스 계정으로 사용되는 사용자 계정보다 오용 및 유출(침해) 가능성에 훨씬 덜 취약합니다.

그룹 관리 서비스 계정 보안

gMSA는 Active Directory의 특정 개체 유형입니다. 즉 msDS-GroupManagedServiceAccount 입니다. 이 개체들은 비밀번호와 비밀번호의 주기적 교체(로테이션)와 관련된 특별한 특성(속성)을 가집니다. LAPS 와 마찬가지로, gMSA 특성이 이를 액세스해야 하는 Active Directory 개체에만 제한되도록 잠가 두는 것이 중요합니다.

gMSA 특성 및 권한

gMSA에는 다음과 같은 특성이 있습니다.

• msDS-ManagedPassword— gMSA의 비밀번호를 포함하는 BLOB
• msDS-ManagedPasswordID— 현재 gMSA 비밀번호를 생성하는 데 사용되는 키 ID
• msDS-ManagedPasswordPreviousID— 이전 gMSA 비밀번호를 생성하는 데 사용된 키 ID
• msDS-GroupMSAMembership— gMSA의 비밀번호를 조회할 권한이 있는 개체 목록
• msDS-ManagedPasswordInterval— 비밀번호를 순환(교체)하는 주기(일)

암호 정보는 msDS-ManagedPassword 특성에 저장되므로, 환경에서 누가 암호를 조회할 수 있는지 반드시 확인해야 합니다. 이 정보는 msDS-GroupMSAMembership 특성에 설정됩니다.

다만 Active Directory 권한이 함께 적용되므로, 이 특성만으로는 조금 더 복잡합니다. 어떤 이유로든 사용자 또는 개체가 msDS-GroupMSAMembership 계정을 통해 암호를 조회할 수 있는 권한이 구성되어 있다면, gMSA의 msDS-ManagedPassword 특성에 대해 ‘Read’ 권한도 여전히 필요합니다.

즉, gMSA 암호를 보호하는 방법에는 두 가지 경로가 있습니다.

• 암호를 조회할 수 있는 권한을 필요한 개체만 갖도록 하고, 해당 개체가 msDS-GroupMSAMembership에 존재하는지 확인하세요.
• 접근이 필요한 관리 사용자와 gMSA가 설치된 컴퓨터 계정만 해당 특성을 읽을 수 있는 권한을 갖도록 하세요. 또한, gMSA 및 해당 특성을 수정할 수 있는 권한은 관리자에게만 있어야 하므로, 누구도 msDS-GroupMSAMembership 특성에 자신을 추가할 수 없게 하세요.

이상적으로는 공격자가 위의 두 시나리오 중 어느 하나를 악용할 수 있는 선택지를 갖지 못하도록, gMSA를 두 경로 모두를 통해 잠가 두는 것이 좋습니다. 아래에서는 gMSA에 대한 권한 또는 구성이 제대로 관리되지 않을 경우, 해당 계정이 손상되고 권한 상승 또는 측면 이동으로 이어질 수 있는 과정을 살펴보겠습니다.

gMSA 비밀번호 악용

gMSA를 악용하는 것은 개념적으로 비교적 간단합니다. 먼저 Mimikatz 같은 도구를 사용해 비밀번호를 얻거나, Active Directory의 보안이 취약한 구성 때문에 이를 직접 조회할 수 있습니다. gMSA는 서비스 계정이므로 대개 비교적 권한이 크기 때문에, 그 다음에는 보통 측면 이동을 하거나 권한을 상승시킬 수 있습니다.

예시 시나리오를 살펴보겠습니다.

1. 먼저 피싱 같은 기법을 통해 일반 Windows 사용자 계정 ‘notadmin’을 침해합니다. 이 계정은 Active Directory에서 권한이 거의 없지만, 우리가 침투한 컴퓨터에서는 로컬 관리자입니다.

2. 다음으로, gMSA가 존재하는지 확인해 보겠습니다. Windows PowerShell cmdlet에 액세스할 수 있다면 이는 매우 간단합니다. 간단한 스크립트를 실행하면 Active Directory에 있는 모든 관리되는 서비스 계정을 얻을 수 있습니다:

      Get-ADServiceAccount -Filter *
      

3. 스크립트를 약간 수정하면 gMSA 암호를 조회할 수 있는 사람이 누구인지 식별할 수 있습니다:

      Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
      

보시는 것처럼, Kevin Joyce 계정만이 이러한 서비스 계정의 암호를 조회할 수 있습니다:

4. 이러한 서비스 계정이 어떤 특권 그룹의 구성원인지 확인함으로써, 우리가 원하는 대상의 범위를 좁힐 수 있습니다. 그리고 거기서부터 개체 중 하나에 설정된 권한을 더 깊이 파고들 수 있습니다:

      Get-ADServiceAccount -Filter * -Properties memberof
      

여기 결과를 보면 gMSA 서비스 계정이 Domain Admins의 구성원인 것을 확인할 수 있습니다. 따라서 이 계정을 대상으로 악용을 시도할 것입니다.

5. Microsoft LAPS에 관한 게시물에 제공된 스크립트를 수정하여, 특정 gMSA 속성에 대해 Full Control, Write All Properties 또는 Write Property 권한이 있는 관리되는 서비스 계정에 대한 모든 개체의 목록을 얻을 수 있었습니다. 아래에 출력 결과가 있으며, 스크립트는 하단에 연결되어 있습니다.

6. 보시다시피 notadmin 계정에는 gMSA 계정에 대한 Full Control 권한이 있습니다. 이를 통해 msDS-GroupMSAMembership 속성을 수정할 수 있으며, 그러면 관리되는 서비스 계정의 비밀번호를 검색할 수 있습니다:

      Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
      

7. 이제 실제로 비밀번호를 조회할 수 있으니, 이를 가지고 무엇을 할 수 있는지 살펴보겠습니다:

      Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
      

      $pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword
      

8. 해당 속성에 저장된 값은 비밀번호 자체가 아니라 비밀번호의 데이터를 포함하는 BLOB입니다. 따라서 DSInternals 같은 도구를 사용해 비밀번호를 디코딩해야 합니다:

      $pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword
      

이렇게 하면 SecureCurrentPassword와 CurrentPassword를 얻을 수 있습니다. CurrentPassword는 유용해 보이지 않는데, 그 이유는 모든 문자가 UTF-16이기 때문입니다. SecureCurrentPassword는 NTLM 해시로 변환할 수 있으며, 이를 패스 더 해시(pass the hash) 공격에 사용해 mimikatz로 권한을 상승시킬 수 있습니다.

9. 패스 더 해시(pass the hash)를 하려면, mimikatz를 실행하고 다음 명령어를 사용하기만 하면 됩니다:

      sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9
      

10. 이제 Domain Admins의 구성원이었던 gMSA 서비스 계정으로 실행되는 셸을 확보했으므로, Active Directory를 손상시키기 위해 원하는 대로 무엇이든 할 수 있습니다. 가장 빠른 방법 중 하나이면서도 아마 가장 눈에 띄는(조금은 시끄러운) 방법은 DCSync 공격을 실행하고 krbtgt 계정의 해시를 훔치는 것입니다:

      lsadump::dcsync /user:krbtgt /domain:sbpmlab.net
      

gMSA 보호 및 모니터링

gMSA 악용을 방지하고 탐지하기 위해 사용할 수 있는 전략이 있습니다.

권한

가장 명백하고(논쟁의 여지가 있지만) 가장 중요한 보호 방법은 그룹 관리 서비스 계정에 적절한 권한이 설정되도록 하는 것입니다. 이러한 개체에 누가 쓰기 권한을 가지고 있는지 이해하는 것은 이를 보호하는 데 중요합니다. 이론적으로 암호를 조회할 수 있는 사람을 제어하는 속성에 자신을 추가할 수 있는 사람은 이미 해당 계정을 장악하고 그 권한을 남용할 수 있는 접근 권한을 갖고 있는 셈입니다.

다음으로, 이러한 계정에서 암호를 조회할 수 있는 권한을 가진 사람이 누구인지, 그리고 정확히 누가 그러한 접근이 필요한지 파악해야 합니다. 실제로 gMSA의 암호를 가져올 수 있어야 하는 유일한 계정은 gMSA가 설치된 컴퓨터 계정입니다.

이벤트 로그

기본 이벤트 로그에서 확인할 수 있는 이벤트가 하나 있으며, 이를 통해 gMSA 계정의 암호를 누가 조회하고 있는지 식별하는 데 도움이 됩니다. 도메인에 대해 ‘Audit directory service access’ 정책을 활성화하고 모니터링하려는 gMSA에 SACL을 구성하면, 사용자가 msDS-ManagedPassword 속성을 조회할 때 이벤트 로그가 생성됩니다:

이 설정을 켜고 새 SACL을 생성하면 이벤트 ID 4662가 포함된 이벤트 로그가 생성됩니다. 예시는 다음과 같습니다:

보시다시피 이 로그에는 ‘notadmin’ 계정이 gMSA 계정의 속성을 읽었다고 기록되어 있습니다. 읽힌 속성은 Active Directory용 스키마에 저장된 GUID이지만, ADSI 편집을 사용하면 강조 표시된 GUID이 msDS-ManagedPasssword 특성에 해당함을 확인할 수 있습니다.

어떤 형태로든 이벤트 로그 포워딩을 하거나 SIEM 솔루션을 사용하고 있다면, 이 로그는 누가 이러한 속성에 액세스하고 있는지 파악하는 데 매우 유용할 것입니다.

Netwrix StealthDEFEND

또 다른 방법은 Netwrix StealthDEFEND 같은 도구입니다. Netwrix StealthDEFEND 는 기본(네이티브) 이벤트 로그에 의존하지 않으며, gMSA 암호 액세스 및 고위험 권한 할당을 바로 즉시 탐지할 수 있습니다. 예를 들어 위에 표시된 시나리오는 ‘notadmin’ 계정이 암호를 조회했을 때 다음과 같은 위협을 생성합니다:

또한 Netwrix StealthDEFEND를 사용하면 gMSA 오용이 감지될 때 실행할 플레이북을 손쉽게 만들 수 있습니다. 플레이북에는 가해자 사용자 계정이 MFA 요청에 응답하도록 요구하는 것, 계정을 비활성화하는 것, 또는 ServiceNow 인시던트를 생성하는 것과 같은 여러 단계가 포함될 수 있습니다.

부록

gMSA 권한 코드:

      <#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'

##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target


<#Get objects that have specific permissions on the target(s): 
Full Control(GenericAll) 
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize 
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}
      

원문 보기gMSA_Permissions_Collection.ps1 에 의해 호스팅됨 GitHub

자주 묻는 질문

gMSA란 무엇인가요?

관리형 서비스 계정(Managed Service Accounts, MSA)과 유사하게, 그룹 관리형 서비스 계정(Group Managed Service Accounts, gMSAs)은 서비스를 보호하고 액세스 관리를 지원하는 데 사용되는 관리 도메인 계정입니다. gMSA 기능은 도메인 컨트롤러(DC)가 자동으로 비밀번호를 관리하고, 서비스 주체 이름(Service Principal Name, SPN) 관리를 간소화하며, 관리를 다른 관리자에게 위임할 수 있도록 해 Active Directory 보안을 개선하는 동시에, 높은 권한(특권) 액세스를 가진 계정을 최소화합니다.

MSA와 gMSA의 차이점은 무엇인가요?

MSA와 달리, gMSA는 여러 컴퓨터에 연결할 수 있습니다.

그룹 관리 서비스 계정(gMSA)을 찾는 방법은 무엇인가요?

도메인 컨트롤러에서 gMSA 목록을 보려면 서버 관리자(Server Manager) > 도구(Tools) > Active Directory Users and Computers > Managed Service Accounts를 여세요.

gMSA를 Domain Admin으로 지정할 수 있나요?

예, gMSA 계정은 Domain Admins의 구성원이 될 수 있습니다. 하지만 이와 같은 방식은 정보 보안에 위험할 수 있습니다.

gMSA를 어떻게 생성하나요?

그룹 관리 서비스 계정은 New-ADServiceAccount cmdlet으로 생성합니다.