Shulou(Shulou.com)06/02 Report--

This article will explain in detail about the use of delegation in the kerberos system, the content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

I. Preface

The following is mainly about the use of delegation in the kerberos system. Delegation is actually a very common function in the domain environment. Compared with the previous attack methods, the use of delegation is more "passive", but it will do great harm once it is used.

II. What is delegation

In the domain, if A uses Kerberos authentication to access service B in the domain, and B uses the identity of A to request service C in the domain, this process can be understood as delegation.

Example:

User accesses the HTTP service on host S2, and the HTTP service needs to request the SQLServer database of other hosts, but S2 does not know whether User has permission to access SQLServer. In this case, HTTP service will use the identity of User to access SQLServer. Only if User has permission to access SQLServer service can the access be successful.

Delegation is mainly divided into two ways: unconstrained delegation (Unconstraineddelegation) and constraint delegation (Constrained delegation). The following describes how to implement the two methods.

1 unconstrained delegation

When unconstrained delegation is implemented in Kerberos, User will send the TGT obtained from KDC to the accessed service1 (which can be any service). After service1 gets the TGT, it can access any other services in the domain through TGT, so it is called unconstrained delegation.

Process:

1. The user can forward TGT (forwardable TGT, which we call TGT1 for convenience) by sending a KRB_AS_REQ message request.

2. KDC returns TGT1 in the KRB_AS_REP message.

3. The user then forwards the TGT (forwardedTGT, which we call TGT2) to the KDC request through TGT1.

4. Returns the forwarding TGT2 in a KRB_TGS_REP message.

5. The user uses TGT1 to request access to Service1's ST (ServiceTicket) from KDC.

6. TGS returns a ST to the user.

7. The user sends a KRB_AP_REQ request to Service1, which contains the SessionKey of TGT1 and ST, TGT2, and TGT2.

8. Service1 uses the user's TGT2 to send it to KDC through KRB_TGS_REQ, and requests a ticket that can access Service2 in the name of the user.

9. KDC returns the ticket from Service2 to Service1 in a KRB_TGS_REP message.

10. Service1 sends KRB_AP_REQ requests like Service2 in the name of the user.

11. Service2 responds to the request from Service1 in step 10.

12. Service1 responds to the user's request in step 7.

13. The TGT forwarding mechanism in this process does not limit the use of TGT2 by Service1, that is, Service1 can request any service through TGT2.

14. KDC returns the ticket requested in step 13.

15 and 16 means that Service1 accesses other Service by impersonating users.

You can see that in the first five steps, User requests two TGT from KDC (steps 2 and 4), one for accessing Service1 and one for accessing Service2, and sends both to Service1. And Service1 keeps the TGT2 in memory.

Settings for unconstrained delegation:

You can set it directly in the account properties in the Windows domain:

2 constraint delegation

Due to the insecurity of unconstrained delegation, Microsoft has released the function of constraint delegation in windows2003. Constraint delegation in Kerberos User does not send TGT directly to the service, but restricts the authentication information sent to service1 and does not allow service1 to use this TGT to access other services on behalf of User. This includes a set of Kerberos protocol extensions called S4U2Self (Service forUser to Self) and S4U2Proxy (Service forUser to Proxy).

You can see from the figure below that the whole process can actually be divided into two parts, the first is the S4U2Self process (processes 1-4), and the second is the S4U2Proxy process (processes 5-10).

Process:

1. The user sends a request to the Service1.

two。 The introduction in the official document at this time is that before the start of this process, Service1 has already obtained the TGT that the user uses to access Service1 through KRB_AS_REQ, and then simulates the user to request ST from KDC through the S4U2self extension.

3. KDC then returns to Service1 a ST for the user to authenticate the Service1 (we call it ST1), and Service1 uses this ST1 to complete the authentication process with the user.

4. Service1 authenticates with the user using the ST1 that simulates the user's application in step 3, and then responds to the user.

Note: Service1 actually gets the user's TGT and ST1 in this process, but the S4U2Self extension does not allow Service1 to request other services on behalf of the user.

5. The user initiates a request to the Service1 again, and the Service1 needs to access the Service2 as the user. Here are two points mentioned in the official document:

A.Service1 has been verified and there is a valid TGT.

B.Service1 has a forwardableST from the user to the Service1 (ST can be forwarded). Personally, I think the forwardable ST here is actually ST1.

6. On behalf of the user, Service1 requests a ST to authenticate Service2 from Service2 (we call it ST2). The user is identified in the ST1 by the cname (client name) and crealm (client realm) fields.

7. After receiving the request from Service1 in step 6, KDC verifies the digital signature of PAC (privileged attribute certificate, as described in the first article). If the authentication succeeds or the request does not have a PAC (cannot verify failure), KDC will return ST2 to Service1, but cname and crealm in this ST2 identify the user rather than Service1.

8. Service1 uses ST2 to request Service2 on behalf of the user. Service2 determines that the request is from a user who has been authenticated by KDC.

9. Service2 responds to Service1's request.

10. Service1 responds to the user's request.

In this process, the role of the S4U2Self extension is to let Service1 verify the validity of the user to KDC on behalf of the user, and get a forwardable ST1. The role of S4U2Proxy can be said to allow Service1 to retrieve ST2 through ST1 on behalf of the user, and does not allow Service1 to access other services as a user. For more details, please refer to the official documentation and the contents of RFC4120.

At the same time, note the forwardable field. If forwardable is marked as forwardable, it can be forwarded through the S4U2Proxy extension protocol. If there is no tag, it cannot be forwarded.

Https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94

Configuration of constraint delegation:

You can change the delegation method of tsvc to constraint delegation in the account properties.

Discover delegated hosts or accounts in the domain

In the domain, you can search for hosts and users with delegation turned on through the PowerView script. Unconstrained delegation is queried mainly by searching for hosts or accounts whose userAccountControl attribute contains ADS_UF_TRUSTED_FOR_DELEGATION. Constraint delegation, on the other hand, queries hosts or users that contain TRUSTED_TO_AUTH_FOR_DELEGATION by querying the userAccountControl attribute.

1 unconstrained delegation

After loading the PowerView script through Import-ModulePowerView.ps1, use the following command to query.

Query the accounts that are configured for unconstrained delegation in the domain:

Get-NetUser-Unconstrained-Domainyunying.lab

Query hosts configured with unconstrained delegation in the domain:

Get-NetComputer-Unconstrained-Domainyunying.lab

Get-DomainComputer is used in another version of PowerView

Get-DomainComputer-Unconstrained-Properties distinguishedname,useraccountcontrol-Verbose | ft-a

2 constraint delegation

Query the accounts delegated by configuration constraints in the domain:

Get-DomainUser-TrustedToAuth-Propertiesdistinguishedname,useraccountcontrol,msds-allowedtodelegateto | fl

Get-DomainUser-TrustedToAuth-Domainyunying.lab

View users with constraint delegation set

Query hosts in the domain that are delegated by configuration constraints:

Get-DomainComputer-TrustedToAuth-Domainyunying.lab IV. Utilization of unconstrained delegation

The two delegation methods are described above, and the following examples are combined with experiments to illustrate the utilization of the two delegates.

Experiment

First of all, the environment is the same as the first two articles. Suppose we have obtained an account permission or password that has been configured for delegation, and now we use these conditions to attack other accounts.

Experimental environment:

Domain: YUNYING.LAB

Domain control: WindowsServer 2008 R2 x64 (DC): user Administrator

Intra-domain host: WindowsServer 2008 R2 x64 (S2): user tsvc

Required tools:

Mimikatz

Experiment procedure:

Only the service account can have delegation function in the domain, so set the user tsvc as the service account first.

Setspn-U-Avariant/golden tsvc

Check the configuration success through setspn-l tsvc.

Then set tsvc to unconstrained delegation mode in AD users and computers

At this point, use Administrator on the domain control to access the SMB service of the host S2 where tsvc is located.

We can export the TGT content sent by Administrator through mimikatz on S2. Here, you need to open mimikatz with administrator privileges, and then use the privilege::debug command to promote permissions. If you do not promote permissions, you will report a kuhl_m_sekurlsa_acquireLSA error. Then use the sekurlsa::tickets/export command to export all the tickets in memory.

You can see that this is the TGT sent by Administrator with the name [0bot 9bec9]-2-0-60a00000-Administrator@krbtgt-YUNYING.LAB.kirbi.

Access to the domain control is denied at this time.

Pass through

Kerberos::ptt [09Shibec9]-2-0-60a00000-Administrator@krbtgt-YUNYING.LAB.kirbi

Command to import the TGT content into the current session, which is actually a Pass The Ticket attack (if you are interested, you can learn about it).

Looking at the current session through kerberos::list, you can see that the ticket has been imported into the current session.

After import, you can already access the domain-controlled shared directory. In other words, whenever a user accesses the service of tsvc, the service of tsvc will keep the visitor's TGT in memory, and all the services of the user to which the TGT belongs can be accessed through this TGT. The principle of unconstrained delegation is relatively simple, that is, the next step of access is to obtain the TGT of the administrator.

One point here is that sekurlsa::tickets is looking at all the tickets in memory, while kerberos::list is just looking at kerberos tickets in the current session. For more information on the use of mimikatz, please see https://github.com/gentilkiwi/mimikatz/wiki

Print Spooler service + unconstrained delegation to domain control permissions:

In DerbyCon in 2018, WillSchroeder (@ Harmj0y), Lee Christensen (@ Tifkin_) and Matt Nelson (@ enigma0x3) mentioned a new way of unconstrained delegation to enhance domain control permissions (https://adsecurity.org/?p=4056) through domain-controlled PrintSpooler services and unconstrained delegated accounts. The main principle is to use specific POC through PrintSpooler services to enable domain control to initiate requests to hosts with unconstrained delegation to obtain TGT for domain control, thereby improving permissions.

Fifth, the use of constraint delegation

Constraint delegation is more complex to use than unconstrained delegation because it only specifies a specific service. The condition of this experiment is that the account of constraint delegation is configured and the password of the current account of constraint delegation (tsvc password) is known.

1 experiment

The environment here remains the same as above, and the normal domain account tsvc and domain administrator account are still used. But a new tool, kekeo, has been added, which is the same author as mimikatz.

1) confirm that the constraint delegation is set for the account tsvc.

Through the query of the tool PowerView, you can see the list of constraint delegates configured in the domain:

2) use kekeo to initiate a request to apply for TGT to the domain control.

Make a request to KDC with a known account name and plaintext password to get TGT.

Kekeo# tgt::ask / user:tsvc / domain:yunying.lab/password:admin1234! / ticket:tsvc.kirbi

/ user: current user name

/ domain: domain name

/ password: password of the current user name

/ ticket: generate the name of the ticket. The one generated in the above figure is not named according to the parameter, so it is not important. You can skip this parameter directly.

3) use kekeo to apply for TGS ticket

Kekeo#tgs::s4u / tgt:TGT_filename/user:administrator@yunying.lab / service:cifs/dc.yunying.lab

/ tgt: the tgt ticket generated by kekeo in the previous step

/ user: write the full name of the user name you want to forge (user name @ domain name)

/ service: the name of the service to which you want to forge access (service name / FQDN name of the host)

4), exit from kekeo with the exit command, and then import the generated TGS file into the Kerberos credential list using mimikatz

At this point, you can see that after the import, you have been able to successfully access the domain-controlled shared file (strictly speaking, it should be the permission of the SPN set in the unconstrained delegation). And in this process, there is no need for administrator privileges, just with the permissions of the current account, because there is no need to export the ticket from memory.

2 principle

Let's take a look at how unconstrained delegation is implemented to obtain the permissions of the set SPN through unconstrained delegation. In fact, the process of the experiment consists of three steps:

1. Request TGT

2. Request TGS

3. Import TGS into memory

It mainly looks at steps 1 and 2. In step 1, you use Kekeo to initiate an AS-REQ request to request TGT.

Kekeo# tgt::ask / user:tsvc/domain:yunying.lab / password:admin1234! / ticket:tsvc.kirbi

At this point, tsvc gets a TGT and the kekeo tool saves it as a file in kirbi format.

Step 2, use this TGT to apply for two ST files, which are divided into two parts in the process of constraint delegation implementation, namely the S4U2Self extension and the S4U2Proxy extension. In S4U2Self, Service1 instead of the user applies to KDC for a TGS to access itself, that is, one of the two generated TGS (TGS_administrator@yunying.lab@YUNYING.LAB_tsvc@YUNYING.LAB.kirbi) and a TGS is the TGS (TGS_administrator@yunying.lab@YUNYING.LAB_cifs~dc.yunying.lab@YUNYING.LAB.kirbi) used to access the SPN set in the unrestricted delegation.

We can also see that there are two TGS_REQ requests initiated here, and the KRB5-PADATA-S4U2SSELF logo can be seen in the package of the first TGS_REQ request. And cname and sname are both tsvc, which shows that this TGS is actually used to verify itself.

Looking at the second TGS_REQ request, the value of sname is cifs/dc.yunying.lab, which is the SPN added in the column "Services that can provide delegation credentials from this account" in the screenshot. And this is actually the TGS ticket applied for in the S4U2Proxy extension.

This attack on constraint delegation is a process by pretending to be a user in Service1 (tsvc) and then obtaining the TGS that allows the delegated SPN to be constrained.

VI. Defense against delegated attacks

As mentioned above, if unconstrained delegated account permissions are stolen, attackers may get a lot of TGT for other accounts, so it is best not to use unconstrained delegating in the domain.

The domain does not need to use delegated accounts, especially administrator accounts, and is set to "sensitive users cannot be delegated".

If it is a win2012 system, you can also mitigate the harm caused by delegation by setting protected user groups.

In the two ways of delegation, the experiment of unconstrained delegation can obtain all the service permissions of the target host directly through TGT, while the experiment of constraint delegation mainly obtains the TGS of SPN set in the list of constraint delegates through TGS to obtain the permissions of corresponding SPN.

On the kerberos system delegated use of what is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.