- Регистрация
- 20.01.2011
- Сообщения
- 7,665
- Розыгрыши
- 0
- Реакции
- 135
When Active Directory was first released with Windows 2000 Server, Microsoft had to provide a simple mechanism to support scenarios where a user authenticates to a Web Server via Kerberos and needs to update records on a back-end database server on behalf of the user. This is typically referred to as the “Kerberos double-hop issue” and requires delegation in order for the Web Server to impersonate the user when modifying database records.
Graphic: Kerberos “double-hop issue”
Microsoft implemented Kerberos “unconstrained delegation” in Windows 2000 that enables this level of delegation. A Domain Admin can enable this delegation level by checking the middle box. The third box is for “constrained delegation” which requires listing of specific Kerberos services on computers to which delegation is enabled.
Graphic: Computer configured with Kerberos Unconstrained Delegation
Discovering computers with Kerberos unconstrained delegation is fairly easy using the Active Directory PowerShell module cmdlet, Get-ADComputer.
Graphic: PowerShell to find Kerberos Unconstrained Delegation
How does Kerberos Unconstrained Delegation really work?
Let’s follow the standard Kerberos communication flow.Для просмотра ссылки Войдиили ЗарегистрируйсяДля просмотра ссылки Войди или Зарегистрируйся’s a quick example describing how Kerberos works:
User logs on with username & password.
1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ).1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) & creates Ticket-Granting Ticket (TGT).
2. The TGT is encrypted, signed, & delivered to the user (AS-REP).Only the Kerberos service (KRBTGT) in the domain can open and read TGT data
3. The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket
4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).
5. The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash.
When Kerberos Unconstrained Delegation is enabled on the server hosting the service specified in the Service Principal Name referenced in the TGS-REQ (step 3), the Domain Controller the DC places a copy of the user’s TGT into the service ticket. When the user’s service ticket (TGS) is provided to the server for service access, the server opens the TGS and places the user’s TGT into LSASS for later use. The Application Server can now impersonate that user without limitation!
NOTE: In order for an application server to be configured with “Kerberos Unconstrained Delegation”, a Domain or Enterprise Admin needs to configure this setting on the computer account in the domain. This permission can be delegated to other groups, so be careful who has this right in Active Directory.
Graphic: Kerberos Unconstrained Delegation Communication Flow
As an attacker, once you have found a server with Kerberos Unconstrained Delegation, what’s next?
When the admin connects to this service, the admin’s TGS service ticket (with the TGT) is delivered to the server and placed into LSASS in case it’s needed later.
The Domain Admin’s authentication (TGT) ticket can be extracted and re-used (until the ticket lifetime expires).
No need to wait though, the ticket can be used immediately in order to get the domain KRBTGT account password hash (when a Domain Admin is compromised).In this case we use PowerShell remoting to connect to a Domain Controller as the Domain Admin.
Для просмотра ссылки Войдиили Зарегистрируйся
Graphic: Kerberos “double-hop issue”
Kerberos Unconstrained Delegation:
Microsoft implemented Kerberos “unconstrained delegation” in Windows 2000 that enables this level of delegation. A Domain Admin can enable this delegation level by checking the middle box. The third box is for “constrained delegation” which requires listing of specific Kerberos services on computers to which delegation is enabled.
Graphic: Computer configured with Kerberos Unconstrained Delegation
Discovering computers with Kerberos unconstrained delegation is fairly easy using the Active Directory PowerShell module cmdlet, Get-ADComputer.
- Unconstrained Delegation: TrustedForDelegation = True
- Constrained Delegation: TrustedToAuthForDelegation = True
Graphic: PowerShell to find Kerberos Unconstrained Delegation
How does Kerberos Unconstrained Delegation really work?
Kerberos Communication Flow:
Let’s follow the standard Kerberos communication flow.Для просмотра ссылки Войди
User logs on with username & password.
1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an authenticator in the authentication ticket (TGT) request (AS-REQ).1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) & creates Ticket-Granting Ticket (TGT).
2. The TGT is encrypted, signed, & delivered to the user (AS-REP).Only the Kerberos service (KRBTGT) in the domain can open and read TGT data
3. The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ). The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket
4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-REP).
5. The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-REQ). The service opens the TGS ticket using its NTLM password hash.
When Kerberos Unconstrained Delegation is enabled on the server hosting the service specified in the Service Principal Name referenced in the TGS-REQ (step 3), the Domain Controller the DC places a copy of the user’s TGT into the service ticket. When the user’s service ticket (TGS) is provided to the server for service access, the server opens the TGS and places the user’s TGT into LSASS for later use. The Application Server can now impersonate that user without limitation!
NOTE: In order for an application server to be configured with “Kerberos Unconstrained Delegation”, a Domain or Enterprise Admin needs to configure this setting on the computer account in the domain. This permission can be delegated to other groups, so be careful who has this right in Active Directory.
Graphic: Kerberos Unconstrained Delegation Communication Flow
Credential Theft Leveraging Unconstrained Delegation:
As an attacker, once you have found a server with Kerberos Unconstrained Delegation, what’s next?
- Compromise the server via an admin or service account.
- Social engineer a Domain Admin to connect to any service on the server with unconstrained delegation.
When the admin connects to this service, the admin’s TGS service ticket (with the TGT) is delivered to the server and placed into LSASS in case it’s needed later.
The Domain Admin’s authentication (TGT) ticket can be extracted and re-used (until the ticket lifetime expires).
No need to wait though, the ticket can be used immediately in order to get the domain KRBTGT account password hash (when a Domain Admin is compromised).In this case we use PowerShell remoting to connect to a Domain Controller as the Domain Admin.
Для просмотра ссылки Войди