BadSuccessor: Active Directory에서 dMSA를 악용해 권한 상승
요약 보고서
Akamai 연구원 유발 고든(Yuval Gordon)은 Windows Server 2025에서 공격자가 AD(Active Directory)의 모든 사용자를 감염시킬 수 있는 권한 상승 취약점을 발견했습니다.
이 공격은 Windows Server 2025에서 도입된 dMSA(delegated Managed Service Account) 기능을 악용하며, 기본 설정 상태에서도 작동하고 구현이 매우 간단합니다.
이 취약점은 AD에 의존하는 대부분의 기업에 영향을 미칠 가능성이 높습니다. Akamai가 조사한 환경의 91%에서 도메인 관리자 그룹에 속하지 않은 일반 사용자도 이 공격을 실행하는 데 필요한 권한을 보유하고 있었습니다.
Microsoft는 이 문제를 향후 수정할 계획이라고 밝혔지만, 현재로서는 패치가 제공되지 않고 있습니다. 따라서 기업은 이 공격에 대한 노출을 줄이기 위해 다른 사전 예방 조치를 취해야 합니다. Microsoft는 Akamai의 분석 내용을 검토했으며, 이 정보의 공개를 승인했습니다.
이 블로그 게시물에서는 공격에 대한 자세한 내용과 탐지 및 방어 전략을 제공합니다.
목차
서론
Windows Server 2025에서 Microsoft는 dMSA(delegated Managed Service Account)를 도입했습니다. dMSA는 AD(Active Directory)에서 gMSA(group Managed Service Accounts)의 기능을 확장한 새로운 유형의 서비스 계정입니다. dMSA의 주요 기능 중 하나는 기존의 비관리형 서비스 계정을 dMSA로 원활하게 전환할 수 있다는 점입니다.
Akamai는 AD의 dMSA 작동 방식을 분석하던 중, 예기치 못한 부분을 발견했습니다. 처음에는 이 전환 메커니즘이 깔끔하고 잘 설계된 솔루션처럼 보였지만, 내부 작동 방식에서 이상 징후가 포착되었습니다.
분석을 이어간 결과, 놀라운 권한 상승 경로가 존재함을 확인했습니다. 공격자는 dMSA를 악용해 도메인 내 어떤 주체든 장악할 수 있습니다. 공격자가 이 공격을 수행하기 위해 필요한 것은 도메인 내의 어떤 조직 단위(OU)에 대한 무해한 권한뿐입니다, 이 권한은 감지되지 않고 지나가는 경우가 많습니다.
그리고 가장 중요한 점은 이 공격은 기본 설정 그대로도 작동한다는 것입니다. 즉, 도메인에서 실제로 dMSA를 사용하지 않아도 됩니다. Windows Server 2025 도메인 컨트롤러(DC)가 하나라도 존재하는 도메인이라면, 이 기능이 활성화되어 공격이 가능합니다.
이 블로그에서는 취약점을 어떻게 발견했는지, 공격이 어떻게 이루어지는지, 그리고 이를 탐지하고 차단할 수 있는 방법에 대해 설명합니다.
dMSA란 무엇일까요?
본격적인 공격 기법을 살펴보기 전에, 먼저 dMSA가 무엇이고 어떻게 동작하는지 이해하는 것이 중요합니다.
dMSA는 일반적으로 기존 레거시 서비스 계정을 대체하기 위해 생성됩니다. 이때 원활한 전환을 위해, dMSA는 기존 계정의 권한을 마이그레이션 절차를 통해 "상속"받습니다. 이 전환 흐름은 새롭게 생성된 dMSA와, 그것이 대체하는 기존 계정을 밀접하게 연결합니다. 그리고 바로 이 흐름과 전환 과정에서 부여되는 권한이 공격자가 악용할 수 있는 취약 지점이 됩니다.
dMSA 전환 흐름
dMSA의 전환 프로세스는 새로운 Start-ADServiceAccountMigration cmdlet 호출을 통해 시작할 수 있습니다. 내부적으로는 migrateADServiceAccount라는 이름의 새로운 LDAP rootDSE 작업을 호출하며, 이 작업은 다음과 같은 인수를 받습니다.
dMSA의 DN(Distinguished Name)
대체 대상 계정의 DN
StartMigration에 해당하는 상수
dMSA의 전환 상태는 dMSA의 현재 상태를 정의하는 새로운 속성인 msDS-DelegatedMSAState 속성에 의해 결정됩니다. 현재 msDS-DelegatedMSAState 속성에 대한 공식 문서는 존재하지 않으며, 다음 표는 Akamai의 행동 분석과 실험을 기반으로 정리한 것입니다.
값 |
의미 |
0 |
알 수 없음(비활성화되었을 수 있지만 확인되지 않음) |
1 |
전환 중 |
2 |
전환 완료됨 |
3 |
독립형 dMSA(전환 없음) |
msDS-DelegatedMSAState 전환 값 및 관련 의미
이 속성과 함께 전환 과정에서는 다음과 같은 주요 속성들도 사용됩니다.
dMSA 오브젝트:
msDS-GroupMSAMembership: 이 dMSA를 사용할 수 있는 주체 목록을 포함합니다
msDS-ManagedAccountPrecededByLink: 대체된 계정의 DN(Distinguished Name)을 나타냅니다
대체된 계정 오브젝트:
msDS-SupersededManagedAccountLink: "승계하는" dMSA의 DN을 나타냅니다
msDS-SupersededServiceAccountState: msDS-DelegatedMSAState와 동일한 의미로, 원래 계정의 전환 상태를 나타냅니다
전환이 트리거되면 시스템은 다음과 같은 변경 사항을 적용합니다.
msDS-DelegatedMSAState를 1(전환 중)로 설정합니다
dMSA의 ntSecurityDescriptor를 업데이트해 대체된 계정에 다음과 같은 권한을 부여합니다.
읽기 권한
msDS-GroupMSAMembership 속성에 대한 쓰기 권한
dMSA의 msDS-ManagedAccountPrecededByLink를 대체된 계정을 참조하도록 설정합니다
대체된 계정의 msDS-SupersededManagedAccountLink를 dMSA를 참조하도록 설정합니다
대체된 계정의 msDS-SupersededServiceAccountState를 1로 설정합니다
이 시점에서 dMSA의 상태는 "전환 중"입니다. 아직 완전하게 기능을 수행하지는 않지만, 기존 서비스 계정을 여전히 사용하는 시스템이 어떤 것인지 인식하고 있는 상태입니다.
Complete-ADServiceAccountMigration 명령어가 실행되면 다음과 같은 작업이 수행됩니다.
dMSA는 대체된 계정으로부터 SPN, 위임 설정, 기타 민감한 속성과 같은 주요 구성을 상속받습니다
대체된 계정은 비활성화됩니다
msDS-DelegatedMSAState 및 msDS-SupersededServiceAccountState는 모두 2(전환 완료됨)로 설정됩니다
전환이 완료되었으며 대체된 계정에 의존하던 모든 서비스는 이제 dMSA를 통해 인증하게 됩니다.
dMSA 인증
dMSA의 생성 및 전환 프로세스를 이해했으니, 이제 인증 방식과 dMSA를 지원하기 위해 도입된 변경 사항, 그리고 이러한 변경 사항이 전환 과정을 어떻게 원활하게 만드는지를 살펴보겠습니다.
이해를 돕기 위해 SQL_SRV$ 서버에서 서비스를 실행하는 svc_sql legacy라는 서비스 계정을 예로 들어보겠습니다. 서비스가 도메인의 리소스에 접속해야 할 때마다 일반적인 인증 절차는 svc_sql 계정을 통해 수행됩니다(그림 1).
Fig. 1: Legacy service account authentication flow
전환 중 인증
이제 서비스 계정을 새로운 dMSA인 DMSA$로 전환하고 전환을 트리거합니다. 전환 기간 동안 SQL_SRV$에서 svc_sql로 인증할 때 인증 흐름에 약간의 변화가 발생합니다.
클라이언트가 svc_sql로 인증하기 위해 AS-REQ를 전송합니다.
KDC(Key Distribution Center)는 AS-REP 를 반환하는데, 여기에는 KERB-SUPERSEDED-BY-USER라는 추가 필드가 포함되어 있습니다. 이 필드에는 새 dMSA인 DMSA$의 이름과 영역이 포함되어 있습니다.
호스트가 dMSA를 지원하고(Windows Server 2025 또는 Windows 11 24H2) dMSA 인증이 활성화되어 있다면, 다음 작업이 수행됩니다.
DMSA$ 이름을 추출합니다
DMSA$에 대한 LDAP 쿼리를 실행해 다음 속성을 가져옵니다.
msDS-GroupMSAMembership
distinguishedName
objectClass
이 시점에서 서비스가 SQL_SRV$에서 svc_sql로 실행되고 있기 때문에, 해당 인증 과정은 svc_sql로부터 LDAP 수정 요청을 유도합니다. 이 요청을 통해 SQL_SRV$는 DMSA$의 비밀번호를 가져올 수 있는 허용 주체 목록에 추가됩니다(그림 2).
이러한 동작이 가능한 이유는 전환 과정에서 svc_sql 계정이 dMSA의 msDS-GroupMSAMembership 속성에 대한 쓰기 권한을 부여받았기 때문입니다. 이 권한으로 인해, 해당 호스트 머신이 계정의 인증정보에 접근할 수 있도록 승인할 수 있습니다.
Fig. 2: Kerberos authentication flow during dMSA migration
이렇게 권한이 원활하게 부여되면 전환이 완료될 무렵에는 기존에 svc_sql 을 사용하던 모든 머신이 DMSA$의 msDS-GroupMSAMembership 속성 목록에 추가되어 dMSA로 인증할 수 있게 됩니다.
전환 완료 후 인증
Complete-ADServiceAccountMigration를 통해 전환이 최종 완료되면 행동이 다시 변경됩니다.
클라이언트가 AS-REQ를 전송해 svc_sql로 인증을 시도할 때 더 이상 AS-REP를 받지 않습니다.
대신 DC는 KRB-ERROR로 응답해 svc_sql이 비활성화되었음을 알립니다.
KRB-ERROR에는 KERB-SUPERSEDED-BY-USER 필드가 포함되어 있으므로 클라이언트는 svc_sql이 전환되었음을 인식하고 자동으로 DMSA$를 사용해 인증을 재시도할 수 있습니다(그림 3).
Fig. 3: Kerberos authentication flow after the dMSA migration is completed
SQL_SRV$(및 기존에 svc_sql에 의존했던 다른 모든 머신)는 이제 자연스럽게 DMSA$를 사용하도록 전환됩니다.
예기치 않은(UnexPACted) 행동
dMSA Kerberos 인증의 흥미로운 측면 중 하나는 PAC(Privilege Attribute Certificate)입니다.
Kerberos는 인증 시 티켓 안에 PAC를 포함시키며, 이는 서비스가 클라이언트의 접근 권한 수준을 판단할 때 사용하는 구조입니다. 일반적인 TGT(Ticket Granting Ticket)에서 PAC에는 사용자의 SID와 해당 사용자가 속한 모든 그룹의 SID가 포함됩니다.
그러나 dMSA로 로그인할 경우, 예상치 못한 동작이 관찰되었습니다.
PAC에는 dMSA의 SID뿐만 아니라, 대체된 서비스 계정의 SID와 그 계정이 속한 모든 그룹의 SID까지 포함되어 있었던 것입니다.
dMSA 전환 프로세스를 악용한 권한 상승
전환이 완료되면, KDC는 dMSA에 원래(대체된) 계정의 모든 권한을 부여합니다.
설계 관점에서는 이는 타당한 접근입니다. 새로운 계정이 대체되는 계정과 동일하게 작동해야 원활한 전환이 가능하기 때문입니다. 동일한 SPN, 동일한 위임 설정, 동일한 그룹 소속을 그대로 유지해야 하죠.
하지만 보안 연구자의 시각에서는 이 동작이 즉각적으로 의심을 불러일으킵니다. 수동 재설정 없이 권한이 자동으로 복사되는 시스템을 발견하자마자, 우리는 더 깊이 조사하기 시작했습니다. 어떤 기준으로 복사할 계정을 결정하는가? 그 기준은 조작이 가능한가? 그렇다면 악용도 가능한가?
이러한 질문을 따라가던 중, 우리는 핵심적인 사실 하나를 발견했습니다. PAC 상속이라는 이 흥미로운 행동은 msDS-ManagedAccountPrecededByLink라는 단일 속성에 의해 제어되는 것으로 보입니다.
KDC는 이 속성을 기반으로 dMSA가 어느 계정을 "대체"하는지를 판단하며, dMSA가 인증을 수행할 때 PAC는 오직 이 링크 정보를 바탕으로 생성됩니다.
공격자의 시선으로 보기
공격자의 관점에서 이 현상은 어떻게 보일까요? 공격자가 이를 활용해 얼마나 깊숙이 침투할 수 있을지, 가능한 공격 시나리오 하나를 통해 살펴보겠습니다.
첫 번째 아이디어는 다음과 같습니다. dMSA를 사용해 계정 탈취의 기반을 마련합니다. 만약 어떤 사용자 계정에 대한 권한을 가지고 있다면, 그 권한을 새로운 dMSA로 "전환"해 몰래 해당 계정을 장악할 수 있을까요? 실현 가능한 접근 방식으로 보입니다. 이제 해야 할 일은 다음과 같습니다.
dMSA를 생성합니다
migrateADServiceAccount rootDSE 작업을 사용해 표적 사용자 및 dMSA 간 전환을 시작하고 완료합니다
dMSA로 인증해 표적 사용자의 모든 권한을 획득합니다
유일한 문제는, 이 방법이 작동하지 않는다는 것입니다.
Akamai가 확인한 바로는, dMSA와 대체 계정을 완전히 제어하더라도 migrateADServiceAccount 작업은 도메인 관리자만 실행할 수 있도록 제한되어 있어 전환을 수행할 수 없습니다. 그림 4는 이러한 실패 시도의 예시를 보여줍니다.
Fig. 4: A failed attempt to use a dMSA to create an account takeover primitive
다음으로, 또 다른 가능성을 살펴보았습니다. 이번에는 복잡하고, 창의적이며, 고도로 기술적인 접근이 필요합니다. 문서화되지 않은 행동을 탐색하거나, 어쩌면 KDC의 일부를 리버스 엔지니어링해야 할 수도 있습니다. 혹은 그냥 속성 두 개만 설정하면 될지도 모릅니다.
직접적인 전환은 수행할 수 없지만, dMSA 오브젝트에 다음 두 속성을 직접 설정함으로써 전환을 간단히 "시뮬레이션"할 수 있습니다.
표적 계정의 DN을 msDS-ManagedAccountPrecededByLink에 작성합니다
msDS-DelegatedMSAState의 값을 2(전환 완료됨)로 설정합니다
이때부터 dMSA로 인증할 때마다 KDC는 msDS-ManagedAccountPrecededByLink 속성에 연결된 계정의 SID를 사용해 PAC를 생성하고, 대체된 계정의 전체 권한을 효과적으로 부여합니다.
BadSuccessor 소개
이 "시뮬레이션된 전환" 기술의 흥미로운 점은 대체된 계정에 대한 권한이 전혀 필요하지 않다는 점입니다. 필요한 것은 단 하나 dMSA의 속성에 대한 쓰기 권한입니다. 어떤 dMSA라도 좋습니다.
dMSA를 특정 사용자 계정의 후속 계정으로 표시하기만 하면, KDC는 이를 정상적인 전환으로 간주하고, 해당 dMSA에게 원래 사용자 계정이 가지고 있던 모든 권한을 자동적으로 부여합니다. 정당하게 승계를 받는 것처럼 말이죠.
하지만, 이 방법은 특권을 가진 계정에는 작동하지 않겠죠? 과연 그럴까요?
실제로 Akamai가 "BadSuccessor"'라고 명명한 이 기술은 도메인 관리자를 포함한 모든 사용자에게 적용됩니다(그림 5). 즉, dMSA 오브젝트를 제어할 수 있는 누구든지 도메인 전체를 장악할 수 있게 됩니다. 이게 전부입니다. 실제 전환 과정도, 검증도, 감독도 없습니다.
Fig. 5: Full attack flow, showing all steps needed to have a BadSuccessor
dMSA 악용: 낮은 권한에서 도메인 장악까지
이쯤에서 여러분은 "우리 환경에서는 dMSA를 쓰지 않으니 상관없다"고 생각하실 수도 있습니다. 하지만 꼭 그렇지는 않습니다.
한 가지 악용 시나리오로는, 공격자가 기존 dMSA를 탈취한 뒤 이를 활용해 BadSuccessor 공격을 수행하는 경우가 있습니다. 하지만 실제로는 공격자가 훨씬 더 자주 활용할 수 있는 다른 시나리오가 있습니다. 바로 공격자가 새로운 dMSA를 직접 생성하는 경우입니다.
사용자가 AD에 오브젝트를 생성하면 해당 오브젝트의 모든 속성에 대한 완전한 권한을 갖게 됩니다. 따라서 공격자가 새로운 dMSA를 만들 수 있다면 이를 통해 도메인 전체를 손쉽게 장악할 수 있습니다.
일반적으로 New-ADServiceAccount cmdlet을 사용해 dMSA를 만들면 Managed Service Accounts 컨테이너에 저장됩니다. 이 컨테이너는 사용자가 직접 접근 권한을 가질 수도 있지만, 기본적으로 이 컨테이너에 대한 권한은 내장된 특권 AD 그룹에만 부여됩니다. 따라서 이 컨테이너에 쓰기 작업을 수행할 수 있을 가능성은 매우 낮습니다.
하지만 중요한 점은, dMSA는 Managed Service Accounts 컨테이너에만 제한되지 않는다는 것입니다. dMSA는 일반 OU에서도 생성할 수 있습니다. 그리고 어떤 사용자든 특정 OU에 대해 msDS-DelegatedManagedServiceAccount 생성 권한 또는 모든 하위 오브젝트 생성 권한을 갖고 있다면, 그 OU 내에 dMSA를 만들 수 있습니다.
dMSA 생성하기
OU 내에 오브젝트를 생성할 수 있도록 허용하는 것은 실제 환경에서 꽤 일반적인 설정입니다. 이 권한은 비교적 무해하다고 여겨지기 때문에, 해당 권한을 가진 사용자에 대한 보안 모니터링이 소홀할 수 있습니다.
dMSA를 만들려면 먼저 권한이 있는 OU를 찾아야 합니다. 예제 환경에서는 마침 "temp"라는 OU가 생성되어 있었고, 권한이 거의 없는 사용자에게도 이 OU에서 모든 하위 오브젝트를 생성할 수 있는 권한이 부여되어 있었습니다(그림 6).
Fig. 6: Example of required privileges on an OU
이 권한을 통해 New-ADServiceAccount cmdlet으로 dMSA를 만들 수 있습니다. 그림 7에서 볼 수 있듯이, 권한이 없는 사용자는 기본 MSA 컨테이너에는 dMSA를 생성할 수 없지만, path 인수를 사용하면 접근 권한이 있는 OU에 dMSA를 생성할 수 있습니다.
Fig. 7: Creating the dMSA in an allowed location using the New-ADServiceAccount PowerShell cmdlet
이제 새로 생성된, 아직 기능하지 않는 dMSA의 소유자가 되었습니다. 생성자 소유자로서 해당 오브젝트에 대한 권한을 스스로 부여할 수 있으며, 공격에 사용할 두 속성에 대한 쓰기 권한도 포함됩니다. 이 속성들은 다음과 같이 수정할 수 있습니다
msDS-ManagedAccountPrecededByLink: 이 값을 사용자 또는 컴퓨터의 DN으로 설정합니다. 도메인 컨트롤러, 도메인 관리자 그룹의 멤버, 보호된 사용자, 심지어 "위임할 수 없는 민감한 계정"으로 표시된 계정도 지정할 수 있습니다
msDS-DelegatedMSAState: 이 값을 2로 설정해 전환이 완료된 것처럼 시뮬레이션합니다(그림 8)
Fig. 8: Modifying attributes to mimic successful migration
앞서 언급했듯이 이 공격은 AD 내 모든 계정에 적용됩니다. 계정이 대체된 표적으로 사용되는 것을 방지하는 설정은 찾을 수 없었습니다.
dMSA용 TGT 획득
dMSA로 인증하는 한 가지 방법은 서비스 생성 후 dMSA 계정으로 실행되도록 설정하는 것입니다. 가능하지만 번거롭습니다. 다행히 조 디블리(Joe Dibley)의 훌륭한 pull 요청 덕분에 이제 Rubeus에서 dMSA 인증을 지원합니다(그림 9). 즉 Rubeus를 사용해 dMSA용 TGT를 요청할 수 있습니다.
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:<Machine TGT>
Fig. 9: Requesting TGT for the new dMSA using Rubeus
dMSA → 도메인 관리자
이번 예시에서는 내장된 관리자 계정을 표적으로 설정했습니다. Wireshark를 사용해 dMSA 계정으로 받은 티켓의 PAC를 분석한 결과(그림 10), 다음과 같은 항목이 포함되어 있었습니다.
dMSA의 RID(1137)
대체된 계정의 RID(500 — 관리자)
대체된 계정의 모든 그룹 멤버십(512 — 도메인 관리자, 519 — 엔터프라이즈 관리자)
Fig. 10: dMSA’s PAC that includes the Administrator’s groups’ RIDs
도메인 컨트롤러가 우리를 정상적인 상속자로 인식하기 위해 필요한 모든 정보입니다. 기억하세요. 그룹 멤버십을 변경하지 않았고, 도메인 관리자 그룹에 손대지도 않았으며, 실제 특권 계정에 대해 의심스러운LDAP 쓰기를 수행하지도 않았습니다.
속성 두 개만 바꾸면, 새로 만든 평범한 오브젝트가 승계자로 등극합니다. KDC는 혈통을 의심하지 않습니다. 링크가 존재하면 특권이 부여됩니다. 그 어떤 그룹 멤버십도 변경하지 않았고, 기존 계정을 승격시키지도 않았으며, 일반적인 권한 상승 경고도 발생하지 않았습니다.
데모: 엔드투엔드 공격 흐름
이 비디오에서 공격이 실제로 작동하는 모습을 확인하세요.
Active Directory에서 dMSA를 악용해 권한을 상승시키는 데모
추가 악용 사례 - dMSA를 악용해 인증정보 탈취
원하는 사용자의 TGT를 얻는 것만으로도 충분히 강력하지만, 거기서 멈추지 않았습니다. 사용자의 인증정보까지 손에 넣을 수 있다면 어떨까요? 다행히 이 시나리오에서도 dMSA가 유용했습니다.
dMSA용 TGT를 요청하면 KERB-DMSA-KEY-PACKAGE라는 새로운 구조가 포함됩니다. 이 구조에는 current-keys와 previous-keys라는 두 개의 필드가 있습니다. MSDN에 따르면 이 필드는 dMSA의 현재 및 이전 비밀번호와 관련된 키를 포함해야 하며, 실제로 그렇습니다. 하지만 이게 전부가 아닙니다.
새로 생성된 dMSA용 TGT를 요청할 때도 previous-keys 필드가 비어 있지 않다는 점을 발견했습니다. 생성 직후이기 때문에 "이전 비밀번호"가 존재해서는 안 됩니다. 처음에는 이 사실을 무시했지만, 이후 구조 안에서 매우 익숙한 무언가가 눈에 띄었습니다.
그림 11에서 볼 수 있듯이, 구조의 두 번째 요소는 타입 23(RC4-HMAC)의 단일 키를 포함하고 있었습니다. 이 암호화 타입은 보안 처리되지 않았기 때문에 동일한 비밀번호가 사용자 간에도 동일한 키를 생성합니다.
Fig. 11: ASN.1 decoded value of the KERB-DMSA-KEY-PACKAGE, decoded at https://pkitools.net/pages/ca/asn1.html
이 특정 키는 무엇일까요? 실험 환경에서 동일한 비밀번호를 수년간 재사용한 것이 결국 효과를 보았습니다. 우리는 그 키를 단번에 알아봤습니다. 데모 중에 표적 계정에 사용했던 비밀번호인 Aa123456과 일치하는 키였습니다.
곰곰이 생각해보세요. 다른 계정의 키가 dMSA의 previous-keys 구조에 포함되어 있었습니다.
대규모 키 탈취
도대체 무슨 일이 일어나고 있는 것일까요? 이유는 또 뭘까요?
msDS-ManagedAccountPrecededByLink는 권한 부여 목적으로 dMSA를 대체된 계정에 연결하는 것뿐 아니라 dMSA가 해당 계정의 키를 상속하도록 허용합니다. 즉, 공격을 통해 도메인 내 모든 사용자 및 컴퓨터의 키도 탈취할 수 있습니다. 그리고 이 키를 사용해 해당 계정으로 인증할 수 있게 됩니다.
아직 전체 구현을 분석한 것은 아니지만, 이 행동은 사용자 입장에서 계정 전환 중 서비스가 끊기지 않도록 하기 위한 설계로 추정됩니다.
레거시 서비스 계정으로 실행 중인 서비스가 있다고 가정해 보겠습니다. 도메인 내의 모든 계정이 이 서비스에 티켓을 요청하며, 이 티켓은 레거시 서비스 계정의 키로 암호화됩니다. 이제 레거시 계정을 dMSA로 교체하고 전환이 완료되어 서비스 계정이 dMSA로 대체되었다고 가정해 보겠습니다. 그러나 dMSA는 대체된 계정의 키에 접속할 수 없습니다.
그 결과, 클라이언트가 기존 티켓을 사용해 인증을 시도할 때 서버는 새로운 dMSA 키로 티켓을 복호화할 수 없기 때문에, 만료되지 않았더라도 발급된 모든 티켓이 사용 불가능해집니다.
이 같은 서비스 중단을 방지하기 위해 KDC는 대체된 계정의 키를 새로운 dMSA의 키 패키지 구조에 포함시켜 dMSA의 이전 인증정보처럼 처리함으로써 "이전" 티켓을 복호화할 수 있습니다.
이 점을 이해하면 또 다른 이상한 점이 설명됩니다. current-keys 필드에는 세 개의 요소가 포함되어 있으며, 각 요소는 정수(암호화 종류를 나타냄)와 옥텟 문자열(해당 키)로 이루어져 있습니다. 암호화 종류 값을 이해하려면 이 페이지를 참조하세요. 이 사례에서는 RC4-HMAC, AES256, AES128에 해당하는 키가 포함되어 있습니다. 그러나 previous-keys 필드는 조금 다릅니다. RC4-HMAC에 해당하는 단 하나의 키만 포함되어 있습니다(그림 12). 왜 previous-keys 목록에는 단 하나의 키 종류만 포함되어 있으며, 왜 하필 RC4-HMAC일까요?
Fig. 12: KERB-DMSA-KEY-PACKAGE structure, highlighting the different keys
답은 원래(대체된) 계정이 지원하는 암호화 방식에 있습니다. 서비스 티켓은 대상 서비스가 지원하는 암호화 방식 중 하나로만 암호화됩니다. Harmj0y의 우수한 블로그 게시물에 설명된 대로, msDS-SupportedEncryptionTypes 속성이 이 행동을 제어합니다. 이 속성이 정의되지 않은 경우(사용자 계정의 기본 경우), 시스템은 RC4-HMAC만 사용하도록 기본 설정됩니다. 따라서 previous-keys 목록에 RC4-HMAC 키만 하나 포함되어 있었던 것입니다.
다시 말해, KDC는 전환 이전에 발급된 서비스 티켓을 복호화하는 데 필요한 원래 계정의 키만 dMSA에 제공합니다. 이는 msDS-SupportedEncryptionTypes 속성을 검사해 확인할 수 있는 원래 주체가 지원하는 암호화 종류에 따라 결정됩니다.
Microsoft의 대응
Akamai는 2025년 4월 1일 MSRC를 통해 이 세부 정보를 Microsoft에 보고했으며, Microsoft는 보고 및 개념 증명을 검토한 후 해당 문제를 인정하고 유효성을 확인했습니다. 그러나 Microsoft는 이 취약점의 심각도를 중간으로 평가했으며 즉각적인 서비스 조치 대상은 아니라고 판단했습니다.
Microsoft 측 설명에 따르면, 해당 취약점을 성공적으로 악용하려면 공격자가 이미 dMSA 오브젝트에 대한 특정 권한을 가지고 있어야 하며, 이는 상승된 권한이 존재한다는 신호라고 봤습니다. 새로운 dMSA를 생성하는 시나리오에 대해 Microsoft는 CreateChild 권한과 관련된 리스크를 설명하는 KB5008383을 언급했습니다.
Akamai는 Microsoft의 답변을 감사하게 생각하며 심각도 평가에 대해 존중하지만 동의하지 않습니다.
이 취약점으로 인해 OU에 대한 CreateChild 권한을 가진 사용자가 도메인 내 모든 사용자를 감염시키고 DCSync 공격에 사용되는 Replicating Directory Changes 권한과 유사한 권한을 획득할 수 있는 이전에 알려지지 않은 고영향 악용 경로가 발생합니다.
또한 현재 업계 표준이나 툴이 CreateChild 접속, 특히 dMSA용 CreateChild를 중대한 문제로 표시했다는 증거를 발견하지 못했습니다. 이는 문제의 은밀성과 심각성을 강조한다고 생각합니다.
탐지 및 방어
탐지
이 공격 기법의 잠재적 악용을 탐지하려면 기업은 다음 영역에 집중해야 합니다.
dMSA 생성 감사 — 새 msDS-DelegatedManagedServiceAccount 오브젝트의 생성 로그를 기록하도록 SACL을 설정합니다(이벤트 ID 5137, 그림 13). 서비스 계정 생성 권한이 없는 계정에 특별히 주의하세요.
Fig. 13: Event example of dMSA creation
속성 변경 모니터링 — msDS-ManagedAccountPrecededByLink 속성의 변경을 기록하도록 SACL을 설정합니다(이벤트 ID 5136; 그림 14). 이 속성의 변경은 악용 시도 또는 성공의 강력한 신호입니다.
Fig. 14: Event example of dMSA link creation
dMSA 인증 추적 — dMSA용 TGT가 생성되고 KERB-DMSA-KEY-PACKAGE 구조를 포함할 경우 Domain Controller가 이벤트 ID 2946(디렉토리 서비스 로그)을 기록합니다.
Group Managed Service Account Object 필드(이 경우 dMSA이며 gMSA가 아님)에는 인증 중인 dMSA의 DN이 표시되며, Caller SID 필드는 S-1-5-7로 표시됩니다(그림 15). 비정상적인 dMSA와 관련된 빈번하거나 예상치 못한 2946 이벤트를 조사해야 합니다.
Fig. 15: Event example of dMSA authentication
권한 검토 — OU 및 컨테이너의 권한에 특별히 주의합니다. 과도하게 허용적으로 위임하면 악용의 문이 열릴 수 있습니다.
방어
Microsoft의 공식 패치가 출시되기 전까지는, dMSA 생성 권한을 제한하고 가능한 모든 위치에서 권한을 엄격히 관리하는 데 방어 노력을 집중해야 합니다.
보안 담당자는 도메인 내에서 dMSA를 생성할 수 있는 모든 주체(사용자, 그룹, 컴퓨터)를 식별하고, 이 권한을 신뢰할 수 있는 관리자에게만 부여하도록 제한해야 합니다.
이를 지원하기 위해 Akamai는 다음 기능을 수행하는 PowerShell 스크립트를 공개했습니다.
dMSA를 생성할 수 있는 비기본 주체를 모두 열거합니다
각 주체가 권한을 가진 OU를 목록으로 표시합니다
Microsoft는 엔지니어링 팀이 패치를 개발 중이라고 알려왔으며, 추가적인 기술적 세부 정보가 확보되는 대로 Akamai는 본 블로그 게시물의 방어 가이드를 업데이트할 예정입니다.
결론
이번 리서치는 Active Directory 환경에서 겉보기엔 사소하고 위험도가 낮아 보이는 권한이라도, 실제로는 도메인 전체에 큰 영향을 미칠 수 있음을 보여줍니다. 공격자는 매우 창의적입니다. 또한 최근의 기술 발전이 시사하듯, 무해해 보이는 기능도 잘못된 손에 들어가면 치명적인 결과로 이어질 수 있습니다. dMSA는 서비스 계정 관리를 현대화하기 위한 솔루션으로 도입되었지만, 그와 동시에 새로운 복잡성과 함께 예상치 못한 악용 가능성도 불러왔습니다.
기업은 dMSA를 생성하거나 기존 dMSA를 제어하는 권한을 다른 민감한 작업과 동일한 수준으로 엄격히 검토해야 합니다. 이러한 오브젝트를 관리하는 권한은 엄격히 제한해야 하며 변경 사항은 정기적으로 모니터링하고 감사해야 합니다.
이 리서치가 Windows Server 2025 전반에 걸쳐 동반된 리스크, 특히 dMSA와 관련된 리스크에 대한 이해를 높이고, 보안팀이 잘못 설정된 권한의 잠재적 영향을 더 잘 이해하고 방어하는 데 도움이 되기를 바랍니다.
