Title: Summary of some attack methods for Kerberos authentication

Kerberos certification process

Preface

This article mainly shares some of the recently learned attack methods about Kerberos certification in the domain. It mainly focuses on self-understanding, starting from principle understanding to basic tool utilization to explain it. Personal understanding and analysis is relatively long-lasting. If you think it is too long, you can just jump and watch it. Please forgive me. If there is any error, please ask the masters to make corrections

The Kerberos authentication process is just a simple description, and there are many details below that are not explained, such as PAC, S4U2SELF (delegation), S4U2PROXY (delegation), etc. Detailed interpretation is recommended to read related articles written by Master daiker

The main environment of this article is the VulnStack, the Hongri Shooting Range

Domain Control owa win2008R2 192.168.52.138 Domain Host sut1 win7 192.168.52.130 Out-of-domain Host k0uaz win7 (accessible to domain control) 192.168.52.162 mainly involves the subject and role Domain Controller Domain Controller, referred to as DC, a computer, implements unified management of users and computers Key Distribution Center Key Distribution Center, referred to as KDC, is installed in domain control by default, including AS and TGSAuthentication Service Authentication Service Authentication Service, referred to as AS, is used for KDC authentication to Client Ticket Grantng Service Ticket Grantng Service Ticket Grantng Service Ticket Granting Service, referred to as TGS, is used for KDC to distribute Session to Client and Server Key (temporary secret key) Active Directory Active Directory, referred to as AD, is used to store information related to users, user groups, and domains. Client client refers to the user. The server side may be a computer account or a service.

Process and Principles

The above figure involves three request return processes: AS of Client and KDC, TGS of Client and KDC, Client and Server. The detailed request response is as follows

AS-REQ: Client initiates an authentication request to KDC (AS). The requested credentials are the timestamps encrypted by Client's NTLM Hash, and other identity information. AS-REP: AS uses Client NTLM HASH for decryption. If the verification is correct, it returns the TGT ticket encrypted with KRBTGT HASH (this is sent to TGS in TGS-REQ and used to exchange for ST). TGT contains PACTGS-REQ: Client obtains TGT cache locally (cannot decrypt) and can be used to exchange ST tickets to TGS to access the corresponding service TGS-REP: TGS uses KRBTGT HASH to decrypt TGT. If the result is correct, return the ST (server) encrypted by Server Hash (machine user HASH) of the server providing the service. ticket)AP_REQ: Client takes the obtained ST to the server to request the resource AP_REP: Server uses its own Hash to decrypt the ST. If the decryption is correct, use the obtained PAC to access the KDC to determine whether the Client has permission to access. After decrypting the PAC, KDC obtains the user sid and the information of the group, and judges permissions based on the access control table (ACL). If it meets, the Server returns the resource to Client

Kerberos-related security issues

Pass The Key(Hash)

Pass the Hash

Pass the Hash is suitable for NTLM authentication and also for Kerberos authentication. It can be used not only outside the domain, but also within the domain. In Kerberos authentication, AS-REQ is sent to AS through Client Hash encryption related information. Therefore, if we obtain the Client's NTLM Hash, we can obtain permissions to other hosts horizontally through Pass The Hash.

Use

Here we assume that the domain pipe NTLM HASH is obtained that is logged in to a certain domain machine.

The following tools for PTH

Using Mimikatz, since credentials are required to inject credentials into lsass, local administrator rights (bypassuac) are required to enable Sedebug. After injection, you can use this user credentials to access the host in the domain using wmicexec (both both py or exe) to pth. There is no administrator rights required. It is suitable for direct remote execution of commands using CME to batch verify pth, etc. Here, Mimikatz is used as an example, hack user (a member of the local administrator group of stu1, domain user)

No permission to access the domain control shared directory

mimikatz after injecting credentials mimikatz 'privilege:debug' 'sekurlsa:pth /user:a /domain:god.org/rc4:b4ab235f987be3621a4ebd862189fd34'

Pass the Key

mimikatz information tips

ntlm hash is mandatory on XP/2003/Vista/2008 and before 7/2008r2/8/2012 kb2871997 (AES not available or replaceable) ; AES keys can be replaced only on 8.1/2012r2 or 7/2008r2/8/2012 with kb2871997, in this case you can avoid ntlm hash.

Pass the Key can only be used in the domain. The versions that support Aes encryption include win8.1/2012r2 or win7/2008r2/8/2012 with kb2871997 patch installed

Use

Get aes key

Then use sekurlsa:pth module mimikatz 'privilege:debug' 'sekurlsa:pth /user:administrator /domain:god.org /aes256:bf723755bc5f72a377bda41ca58fd925df7ee45df9a026ac5cd320102a3a2e33'

Since the Win7 host is not patched, the Pass The Key naturally fails. In a practical environment, when PTH does not support rc4 encryption, it may be in the Protected Users group. At this time, you can try Aes128 and Aes256 encryption to PTK

Pass The Hash With Remote Desktop(Restricted Admin mode)

In 2014, Microsoft released the KB2871997 patch, which mainly covers the enhanced security protection mechanism in Windows 8.1 and Windows Server 2012 R2. Therefore, in the past, such as Windows 7, Windows 8, Windows Server 2008R2 and Windows Server 2012, you can also update this patch to obtain the above security protection mechanism.

————————————————————————————————————————————————

Restricted Admin RDP mode Remote desktop client support:

Prior to this update, RDP login was an interactive login that was accessible only after the user provided the user name and password. When logging into an RDP host in this way, user credentials are placed in the memory of the RDP host, and if the host is threatened, they can be stolen. This update enables RDP to support network logins, where authentication for user existing login tokens can be passed for RDP access. Use this login type to ensure that the user's credentials are not stored on the RDP server. Thus protecting credentials

Through the above explanation, we can understand that this mode is to protect user credentials logged in using RDP. Through the login method of network verification, the RDP server will not save user credentials.

Use

win8.1 and win2012R2 or above support Restricted Admin mode mode, win8.1 and win2012R2 are enabled by default.

Condition: Client supports Restricted Admin mode mode, Server enables Restricted Admin mode mode

Since win2012R2 is missing on hand, two Windows 10s are used here to pass the Hash With Remote Desktop

First get NTLM HASH

Use mimikatz to inject NTLM HASH (privilege:debug first to enable debug permission, screenshots are missing here) sekurlsa:pth /user:administrator /domain:192.168.226.137 /ntlm:9c3767903480e04c089090d27123eaf9 '/run:mstsc.exe /restrictedadmin'

/domain specifies the computer name or ip

Don't choose to always require credentials here

Restricted Admin mode

Open via the registry (0 is on, 1 is off, full administrator privileges are required), and then RDP connection is done again REG ADD 'HKLM\System\CurrentControlSet\Control\Lsa' /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f

After the Restricted Admin mode is enabled on the remote host, the RDP connection is successful

You can see Hash injected into memory

Then here I used the administrator account K0uaz, so the Pass The Hash With Remote Desktop only requires the target's local administrator permissions, not necessarily a local administrator account with sid 500.

However, if you just join Remote Desktop Users and are not in the Administratros group, it will not be successful, because this mechanism is for restricted administrators

AS-REP Roasting

Principle

In AS_REP, KDC will return a Session Key encrypted by user NTLM Hash (the Sessions Key is used to ensure the security of communication between the client and TGS)

Under RC4_HMAC encryption mode, we can use the same encryption process to encrypt the plaintext password, and then compare the encryption results to determine the blasting result by evaluating whether the ciphertext is the same

Although the Session Key ciphertext of the user NTLM Hash encrypted by the user returned in the figure above is encrypted through AES256, we can also use the encryption downgrade method here (the following Kerberoast breaks through the method used to support AES encryption and return RC4_HMAC type encrypted data) to specify that the maximum encryption method supported by the client is only RC4_HMAC, so that the encryption method of the ciphertext returned in AS_REP is RC4_HMAC, so that we can crack the plaintext password.

However, one problem that needs to be solved here is the pre-authentication problem. In AS_REQ, a Timestamp with Client Hash encryption will be generated to send it to KDC. KDC obtains a timestamp by decrypting the ciphertext. If the decryption is successful and the timestamp is within 5 minutes, the pre-authentication will be successful. KDC uses this method to verify the client identity, so as to effectively prevent brute-force cracking.

As for why AS_REQ is sent twice by default, the explanation obtained from the article of harmj0y is that the client does not know the supported encryption method in advance (I think it is specific to the client not knowing the encryption method of Timestamp in pre-authentication), so I request to obtain the encryption method supported by KDC

Therefore, by turning off the pre-authentication, we can perform exhaustive blasting and cracking the plain password

After closing pre-authentication, there will be no second AS_REQ, and the only AS_REQ will not contain the NTLM Hash encryption Timestamp ciphertext

Use

You can query domain users with Do not require Kerberos preauthentication attribute through LDAP

The specific query conditions are userAccountControl:1.2.840.113556.1.4.803:=4194304

Here Rubeus is used as a sample Rubeus.exe asreproast /nowrap /format:hashcat

hashcat decrypt hashcat -m 18200 hash.txt passwords.dict --force

Rubeus asreproast principle analysis

Through Wireshark analysis of traffic, we can see that the principle of this module is to query the domain user of the attribute feature through LADP, and then send the AS_REQ request packet in batches, extract the NTLM Hash encryption part in the return packet for formatting and output suitable for Hashcat blasting.

ldap query

Specifies that the supported encryption type is RC4_HMAC only

The returned ciphertext is encrypted using RC4_HMAC (so it can be exhaustively blasted)

Gold Notes

Features

It is necessary to communicate with DC (no need to interact with AS, but need to TGS) It requires the hash of krbtgt user

Principle

During the kerberos authentication process of Windows, the Client sends its own information to the KDC, and then the KDC uses the NTLM-Hash of the Krbtgt user as the key to encrypt and generates TGT. So if you get the NTLM-Hash value of Krbtgt, can you forge any TGT? Because Krbtgt is only available on domain controllers, using gold credentials means that you have obtained permissions on domain controllers before, and gold credentials can be understood as a backdoor.

condition

1. Domain name

2. SID value of the domain

3. The domain's KRBTGT account password HASH

4. Forged username can be arbitrary (TGT's service life is within 20 minutes, and the domain controller KDC service will not verify the user account in TGT)

When we get the Hash of krbtgt, we can use it to make gold notes

Suppose we have obtained the hash of krbtgt through dcsync's attack method (explained and practice below)

Condition 1: Scan the spn to get the domain name god.org

Condition 2: whoami /all gets the domain user sid, and removes the last string of the domain SID

Condition 3: krbtgt account Hash58e91a5ac358d86513ab224312314061

Condition 4: Forge username administrator

Make gold notes

Use mimikatz kerberos:golden forged tgt

Golden Ticket Default Group:

Domain user SID: S-1-5-21 DOMAINID -513

Domain Admin SID: S-1-5-21 DOMAINID -512

Architecture Administrator SID: S-1-5-21 DOMAINID -518

Enterprise Admin SID: S-1-5-21 DOMAINID -519 (It is valid only when a forged ticket is created in the forest root domain, but add the use /sids parameter for AD forest administrator permissions)

Group Policy Creator Owner SID: S-1-5-21 DOMAINID -520

mimikatz.exe 'kerberos:golden /domain:god.org /sid:S-1-5-21-2952760202-1353902439-2381784089 /user:administrator /krbtgt:58e91a5ac358d86513ab224312314061 /ticket:k0u.kiribi' exit

tip: can add /endin:xx /renewmax:xx to modify the validity period of the bill and the maximum validity period for renewal bills. Mimikatz defaults to 10 years

The generated tickets can be imported on other domain machines, or tgt can be injected directly into memory using /ptt.

First clear the ticket cache klist purge

Then inject it into the cached bill via mimikatzkerberos:ptt k0u.kiribi

klist checks the ticket cache and can see the forged tgt