Summary of learning some attack methods about Kerberos authentication

Kerberos authentication process

foreword

This article mainly shares some attack methods about Kerberos authentication in the domain that I have learned recently. It is based on self-understanding, and it is explained from the understanding of principles to the use of basic tools. Personal understanding and analysis are relatively long-winded. Ok, please forgive me. If there is any mistake, please make a correction.
The Kerberos authentication process is just a brief description. There are many details that are not explained below, such as PAC, S4U2SELF (delegation), S4U2PROXY (delegation), etc. For detailed interpretation, it is recommended to read related articles written by master daiker.
The main environment of this article is the Red Sun shooting range VulnStack.

• Domain controller owa win2008R2 192.168.52.138
• domain host sut1 win7 192.168.52.130

• • Host outside the domain k0uaz win7 (accessible to the domain controller) 192.168.52.162 mainly involves subjects and roles

• Domain Controller Domain controller, referred to as DC, a computer, to achieve unified management of users and computers
• Key Distribution Center The key distribution center, referred to as KDC, is installed in the domain controller by default, including AS and TGS
• Authentication Service Authentication Service, referred to as AS, is used for KDC to authenticate Client
• Ticket Grantng Service Ticket Granting Service, referred to as TGS, is used for KDC to distribute Session Key (temporary key) to Client and Server
• 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.
• Server The server may be a computer account or a service.

process and principle

The above figure involves three request return processes: Client and KDC AS, Client and KDC TGS, Client and Server. Detailed request responses are as follows

1. AS-REQ: Client initiates an authentication request to KDC (AS), and the requested credentials are the time stamp encrypted by Client's NTLM Hash and identity information, etc.
2. AS-REP: AS uses Client NTLM HASH to decrypt, and if the verification is correct, it returns a TGT ticket encrypted with KRBTGT HASH (sent to TGS in TGS-REQ and used in exchange for ST). TGT contains PAC
3. TGS-REQ: Client obtains TGT cached locally (cannot be decrypted), which can be used to exchange ST tickets for accessing corresponding services from TGS
4. TGS-REP: TGS uses KRBTGT HASH to decrypt TGT, if the result is correct, return ST (server ticket) encrypted with Server Hash (machine user HASH) of the server providing the service
5. AP_REQ: Client takes the obtained ST to the server to request resources
6. AP_REP: The Server uses its own Hash to decrypt the ST. If the decryption is correct, it takes the obtained PAC to visit the KDC to determine whether the Client has permission to access it. After decrypting the PAC, the KDC obtains the user sid and group information, and judges the authority according to the access control list (ACL). If it matches, the server returns the resource to the client

Kerberos-related security issues

Pass The Key(Hash)

Pass the Hash

Pass the Hash is applicable to both NTLM authentication and Kerberos authentication, not only outside the domain, but also within the domain. In Kerberos authentication, AS-REQ encrypts relevant information through Client Hash and sends it to AS. Therefore, if we obtain the NTLM Hash of Client, we can horizontally obtain the permissions of other hosts through Pass The Hash.

use

Here we assume that we have obtained the NTLM HASH of the domain administrator logged in on a certain domain machine

The following tools are available for PTH

1. To use Mimikatz, because you need to inject credentials into lsass, you need local administrator privileges (bypassuac) to enable Sedebug, and you can use the user credentials to access the host in the domain after injection.
2. Use wmicexec (py or exe) to go to pth, no administrator privileges required, suitable for direct remote execution of commands
3. Use cme to batch verify pth
4. etc.

Take Mimikatz as an example here, hack user (member of the local administrator group of stu1, domain user)

Do not have permission to access the domain controller shared directory

After mimikatz injects credentials mimikatz "privilege::debug" "sekurlsa::pth /user:a /domain:god.org/rc4:b4ab235f987be3621a4ebd862189fd34"

Pass the Key

mimikatz data prompt

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, and the versions that support Aes encryption are win8.1/2012r2 or win7/2008r2/8/2012 with the kb2871997 patch installed

use

get aes key

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

Since the Win7 host has not been patched, Pass The Key naturally fails. In the actual combat environment, when the PTH with rc4 encryption method is not supported, it may be in the Protected Users group. At this time, you can try Aes128, Aes256 encryption method to PTK

Pass The Hash With Remote Desktop(Restricted Admin mode)

2014年，Microsoft发布了KB2871997补丁，它主要囊括了Windows 8.1和Windows Server 2012 R2中增强的安全保护机制。所以，以往的例如：Windows 7，Windows 8，Windows Server 2008R2和Windows Server 2012也可以更新该补丁后获得上述安全保护机制。
————————————————————————————————————————————————
Restricted Admin RDP模式的远程桌面客户端支持：
在此更新之前，RDP登录是一种交互式登录，只有在用户提供用户名和密码之后才可以访问。以这种方式登录到RDP主机时，会将用户凭据放置在RDP主机的内存中，如果主机受到威胁，它们可能会被窃取。此更新使RDP支持网络登录，其中可以传递用户现有登录令牌以进行RDP访问的身份验证。使用此登录类型可确保RDP服务器上不存储用户的凭据。从而保护凭据

通过上述解释可以理解该模式是为了保护使用RDP登录的用户凭据，通过网络验证的登录方式，RDP服务端不会保存用户的凭据

利用

win8.1以及win2012R2以上支持Restricted Admin mode模式，win8.1以及win2012R2默认开启Restricted Admin mode
条件：Client支持Restricted Admin mode模式，Server启用Restricted Admin mode模式
由于手头缺少win2012R2，因此这里使用两台Windows10来进行Pass The Hash With Remote Desktop
首先获取NTLM HASH

Use mimikatz to inject NTLM HASH (privilege::debug is required to enable debug permissions first, here are few screenshots) sekurlsa::pth /user:administrator /domain:192.168.226.137 /ntlm:9c3767903480e04c089090d27123eaf9 "/run:mstsc.exe /restrictedadmin"
/domain Specify the computer name or ip
Here do not choose to always require credentials

Credentials are correct but Restricted Admin mode is not enabled

Turn it on through the registry (0 is on, 1 is off, full administrator privileges are required), and then make an RDP connection again REG ADD "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 00000000 /f

After the remote host enables Restricted Admin mode, the RDP connection succeeds

You can see the Hash injected into the memory

Then I used the administrator account K0uaz here, so the Pass The Hash With Remote Desktop only needs the local administrator authority of the target, not necessarily the local administrator account with sid 500

However, if you just join the Remote Desktop Users and are not in the Administratros group, you will not be able to succeed, because this mechanism is for limited 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 communication security between the client and TGS)

In the RC4_HMAC encryption mode, we can use the same encryption process to encrypt the plaintext passwords by exhaustively enumerating the plaintext passwords, and then compare the encryption results with the ciphertexts to determine whether the blasting results are the same. It is encrypted by AES256, but here we can also use the encryption downgrade method (the method used below for Kerberoast to break through the user's support for AES encryption and return the encrypted data of type RC4_HMAC) to specify that the client's maximum supported encryption method is only RC4_HMAC, so that AS_REP The encryption method of the returned ciphertext is RC4_HMAC, so that we can crack the plaintext password,
but one problem that needs to be solved here is the problem of pre-authentication. In AS_REQ, a Timestamp encrypted with Client Hash will be generated and sent to KDC, and KDC will decrypt it. The ciphertext gets a time stamp. If the decryption is successful and the time stamp is within 5 minutes, the pre-authentication is successful. The KDC uses this method to verify the identity of the client, thereby effectively preventing brute force cracking

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

Therefore, if pre-authentication is turned off, we can perform exhaustive blasting to crack the plaintext password.

After pre-authentication is turned off, there will be no second AS_REQ, and the only AS_REQ will not carry the ciphertext of NTLM Hash encrypted Timestamp

use

Do not require Kerberos preauthenticationDomain users with attributes can be queried through LDAP.
The specific query conditions are as userAccountControl:1.2.840.113556.1.4.803:=4194304
follows, taking Rubeus as an example.Rubeus.exe asreproast /nowrap /format:hashcat

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

Rubeus asreproast principle analysis

By analyzing the traffic with Wireshark, it can be seen that the principle of this module is to query the domain users of the attribute characteristics through LADP, and then send AS_REQ request packets in batches, extract the NTLM Hash encrypted part in the returned packets, format and output the ldap query in a form suitable for Hashcat blasting:

Specifies that the supported encryption type is only RC4_HMAC

The returned ciphertext is encrypted with RC4_HMAC (so it can be used for exhaustive blasting)

golden note

features

1. Need to communicate with DC (do not need to interact with AS, need to communicate with TGS)
2. Need the hash of the krbtgt user

principle

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

condition

1. Domain name
2. Domain SID value
3. Domain KRBTGT account password HASH
4. Forged user name, which can be arbitrary (within 20 minutes of TGT service, 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 bills.
Assume that we have obtained the hash of krbtgt through the attack method of dcsync (explained and practiced below)

Condition 1: SPN scan to obtain the domain name god.org

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

Condition 3: krbtgt account Hash 58e91a5ac358d86513ab224312314061
Condition 4: Forged username administrator

Make Golden Notes

Use mimikatz kerberos::golden to forge tgt

Golden Ticket Default Group:
Domain Users SID: S-1-5-21 <DOMAINID> -513
Domain Admins SID: S-1-5-21 <DOMAINID> -512
Schema Admins SID: S-1-5-21 <DOMAINID> -518
Enterprise Admin SID: S-1-5-21 <DOMAINID> -519 (only works if forgery ticket is created in forest root domain, but add use /sids parameter for AD forest admin rights)
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: You can add /endin:xx /renewmax:xxthe validity period of the modification ticket and the maximum validity period of the renewal ticket. Mimikatz defaults to 10 years

The generated ticket can be imported to other domain machines, or you can directly use /ptt to inject tgt into the memory.
First, clear the ticket cache klist purge

Then kerberos::ptt k0u.kiribi inject into the cache ticket through mimikatz

Klist checks the ticket cache and you can see the fake tgt

At this time, a very high authority has been obtained.

After klist purge clears the ticket cache

Tips:
普通黄金票据存在局限性，适用于单域内，不适于域森林中

Pass The Ticket

In addition to the first step of Kerberos, the user NTLM Hash encryption verification on the client side is required, and the subsequent operations are verified by tickets (Tickets). Therefore, if we get a ticket or forge a ticket, we can move horizontally through the ticket, golden ticket The use of silver bills and MS14068 can be regarded as an attack method of Pass The Ticket

use

Mimikatz

Export in-memory tickets via Mimikatz

(Administrator privileges enable SeDebug) Mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

At this time, we have captured the TGT of the domain manager, we can inject the TGT of the domain manager into the cache and use the TGT to exchange the corresponding service certificate ST from TGS (no administrator privilege is required
). At this time, use god.org\hack domain When a user (Stu1 local administrator authority) accesses the Cifs shared service of the domain controller, it prompts that there is no permission and is denied. Here, the TGT of the domain controller is injected into the cache and can be accessed successfully.

Red

Rubeus, using C# to implement some function attack methods in Kekeo, etc. This tool is mainly aimed at some Kerberos attack methods. The integrated utilization tool
exports the notes in the memory
(administrator authority)Rubeus.exe dump >test.txt

The arrow points to the base64-encoded. kirbi
can directly export base64-encoded credentials through Rubeus or convert them into files. The file format can be Kerberos::ptt xxx.kirbi used with Mimikatz import bills Rubeus.exe ptt /ticket:base64 (need to process the exported base64 encoding format, delete multiple spaces, To delete newlines, you can add /nowrap parameter without newlines)

After importing, you can Rubeus.exe klist view the cached tickets by

Domain controller shared services can be accessed with a high-privilege ticket of the domain controller

/ticket:file.kirbi The form that can also be used
can call the WriteAllBytes method in the file class in the system.io namespace of the .net class library through Powershell to decode the base64 code and write it into the file [IO.File]::WriteAllBytes("Adcontrol.kirbi", [Convert]::FromBase64String("处理后的凭据Base64编码"))

import Rubeus ptt /ticket:file.kirbi

Tips:
票据文件注入内存的默认有效时间为10小时
Klist Purge清除缓存后注入的TGT也随着被清除

Kerberoasting

principle

In the TGS_REP in the kerberos authentication process, Server Hash (Ticket) and Session Key (Server Session Key) are returned, the most important of which is the ST ticket generated by encrypting the key through the NTLM Hash of the service. When the authentication encryption algorithm is RC4_HMAC (weak encryption type), we can use the same encryption process to obtain the ciphertext through the exhaustive password, and compare the obtained ciphertext with the ciphertext in the ST ticket. If they are the same, the password is correct. , Successfully blasted to obtain the plaintext of the service
credentials

(Service Principal Name)SPN

Service principal names (SPN: ServicePrincipal Names) are service instances, and Kerberos authentication uses SPNs to associate service instances with service login accounts.
The format of the SPN is:serviceclass/host:port/servicename

SPN is the unique name of a service in the domain. There are two types of SPN:

1. One is registered under the machine account (Computers) on AD. When the authority of a service is Local System or Network Service, the SPN is registered under the machine account (Computers), such as SMB or remote registry service
2. The other is registered under the domain user account (Users). When the authority of a service is a domain user, the SPN is registered under the domain user account (Users). At this time, when accessing a certain service, the service encrypted in the returned ST ticket The ticket is the ticket of the service account, that is, the credential of the account associated with the SPN and the service

   Tips:
   Setspn -Q */*Query all SPNs.
   You can set the domain user attribute servicePrincipalName as the target SPN through LDAP. You
   can quickly retrieve which domain users have the servicePrincipalName attribute through LDAP to find the blasting target (low authority is enough)

   Implementation points

   寻找有价值的SPN : 寻找基于域账户的(最好是高权限)SPN，基于主机的SPN密码复杂随机且30天自动更换一次，因此难以破解
   获得RC4_HMAC加密形式的ST票据 : 支持RC4_HMAC或启用AES认证加密但是未禁用RC4_HMAC

   利用

   首先为域用户liukaifeng01关联一个SPN

   

   老方法

   用到的工具为kerberoast
   首先通过遍历SPN(筛选有价值的SPN)，然后对获得的所有SPN发起TGS请求获取ST票据缓存到本地(Mimikatz中的kerberos::ask可实现发起单个TGS请求)，再通过Mimikatz等工具导出ST凭据，然后通过爆破脚本tgsrepcrack.py尝试爆破出明文口令

   新方法

   用到的工具为Invoke-kerberoast
   较新的方式是一步到位，(首先通过LDAP查询带有ServicePrincipalName属性的域用户)不需要发送TGS请求后通过Mimikatz导出ST凭据了，通过微软提供的类KerberosRequestorSecurityToken直接发起TGS请求，然后再返回的内容中提取加密的ST票据进行格式化，方便使用John和Hashcat来破解
   这里举例使用的工具是Rubeus，该工具同样实现了Invoke-kerberoast的功能Rubeus kerberoast(普通域用户权限即可)

   
   
   如果复制粘贴不方便，可以使用/outfile:path指定Hash参数的写入路径
   
   
   Rubeus返回的Hash参数对应的值就是hashcat官方指定的RC4_HMAC加密方式破解的格式
   
   
   kali中使用hashcat爆破hashcat -m 13100 hash.txt passwords.dict --force
   

   加密降级突破AES加密类型

   首先设置用户启用AES加密，通过AD用户和计算机管理设置liukaifeng01用户启用AES加密

   
   
   LDAP查看msDS-SupportedEncryptionTypes属性
   
   
   这时候再进行Kerberoast时，返回的票据加密类型为AES256
   
   
   Capture the packet and view TGS_REQ, you can see that the client provides the supported encryption algorithms to the server, including RC4and AESencryption
   
   
   By looking at TGS_REP, you can find that the algorithm used in the returned ST ticket is the highest supported encryption type =>AES256
   
   
   Then here is a conjecture. If we provide the highest supported encryption algorithm in TGS_REQ RC4, will the encryption method returned in TGS_REP be the same RC4?
   This method has been implemented in Rubeus and it is indeed effective.Rubeus kerberoast /tgtdeleg
   
   
   The encryption algorithms supported in the TGS_REQ request packet are onlyRC4
   
   
   liukaifeng01Although the encryption method supported by domain users is AES, what is obtained is an RC4encrypted ticket. The ticket obtained in this way can still be cracked.
   The only way to solve the encryption degradation is to completely disable it in the security policy Kerberos authentication in the group policy.RC4

   Silver notes

   features

3. Does not require interaction with domain controller (KDC)
4. Need the NTLM Hash of the target service (obtain Server Hash to fake TGT)

principle

The composition of the Ticket in the third step of authentication: Ticket=Server Hash(Server Session Key+Client info+End Time)
if we have the Server Hash, we can forge the ST, the server does not know the Server Sessoin Key before receiving the ST, so the most important thing in all these authentications is the Server Hash, with Server Hash, we can forge ST to access specified services. The Server Hash here refers to the Hash of the machine user, and the machine user is actually the System user.

condition

1. Domain name
2. SID value of the domain (SID value, note that the value after the last one is removed)
3. NTLM-Hash of the server account in the domain
4. Forged username, which can be any username.
5 , the kerberos service on the target server

Make Silver Notes

Here is still taking the domain controller owa as an example, and obtain the Hash of the machine account through mimikatz

After obtaining the hash, make a silver ticket through mimikatz (some conditions have been obtained in the practice of the above-mentioned gold ticket), and the target service is cifs.
Normally, ordinary domain users hack do not have permission to access:

Make silver notes through mimikatz and import directly

view current notes

Successfully accessed the shared directory

But this is different from the normal encryption type. The forgery of Mimikatz is the RC4 encryption type, and the normal SPN associated with the machine account is generally AES encrypted. Therefore, for the ST ticket for forging the access service CIFS, the flow of the silver ticket It is also easier to identify

Common types of fake services are as follows

Tips:
开启PAC验证可防御白银票据(Server发送PAC的数字签名给KDC校验)

Username enumeration and password brute force

three conditions

user exists

User Description Exists: error_code:eRR-PREAUTH-REQUIRED
Password Error Description:error_code:eRR-PREAUTH-FAILED

non-existent user

describe:error_code:eRR-C-PRINCIPALL-UNKNOWN

kerbrute

scenes to be used

If you are not in the domain and cannot obtain users in the domain through LDAP or SAMR protocol (if you have the user name and password in the domain, you can also obtain information through LDAP and domain controller interaction outside the domain)
. The interaction
will not have logs like LDAP brute force cracking (4625 - An account failed to log on)

main principle

After sending the constructed AE-REQ request packet, judge whether the user exists and whether the password is correct by the difference between the returned packets

Username enumeration

within the regionkerbrute_windows_amd64.exe userenum -d god.org username.txt

kerbrute_windows_amd64.exe userenum --dc 192.168.52.138 -d god.org username.txt
The IP address of the Dc needs to be specified outside the domain

password spray

Specify the password, traverse the username kerbrute_windows_amd64.exe passwordspray -d god.org username.txt Abc123!
and send the username in the first package

After the DC returns that the user name is correct, it sends the second AS-REQ, which contains the NTLM HASH of the password

pyKerbrute

The Python version of kerbrute implemented by the 3gstudent master has added two functions
◼ Increase support for the TCP protocol
◼ Increase the verification of NTLM hash

Username enumeration

The main implementation of EnumADUser.py is to send a package with As-REQ structure to modify CnameString (fix sname to krbtgt)

EnumADUser.py :   EnumADUser.py 192.168.52.138 god.org user.txt tcp

It is slightly different from the packet sent by kerbrute

password spray

First of all, pyKerbrute is divided into two modes, clearpassword and ntlmhash
classpassword: realize the encryption of plaintext into NTLM Hash and then encrypt the time stamp through the RC4-HMAC encryption algorithm, and then use the ntlmhash module to spray ntlmhash passwords
: directly through RC4-HMAC-MD5 Encryption algorithm encrypts timestamp

ADPwdSpray.py :   ADPwdSpray.py 192.168.52.138 god.org username.txt clearpassword Abc123! udp

The data packets sent by kerbrute are quite different in the supported encryption algorithms, which are not as secret as kerbrute

pyKerbrute sends a packet here, but does not send it to determine whether the user name exists, and directly requests authentication, and the encryption algorithm specifies RC4-HMAC-MD5, and kerbrute supports multiple encryption methods. After a little look at the Kerbrute code, I found the implementation method
NewWithPassword Comes from the gokrb5 library, which facilitates Kerberos-related authentication for clients and servers, and implements many encryption algorithms in the library

Detection of Kerberos pre-auth bruteforcing

Kerberos uses the Kerberos pre-auth protocol and does not generate logs (4625 - An account failed to log on)
but generates the following logs:
◼ A log is generated when the password verification is successful (4768 - A Kerberos authentication ticket (TGT) was requested)
◼ Password Generate logs when authentication fails (4771 - Kerberos pre-authentication failed)

I checked the logs on my own local domain controller and found that 4768 exists, but the user is correct and the password is wrong, and 4771 will not burst out without any prompts.

success

fail

null

solve

By consulting the information, I found the place to modify the login policy. For details, see Audit Kerberos Authentication Service

Type 4771 can be captured after modifying the audit policy:

Dcsync attack

Principle of DCSync attack

Use the Directory Replication Service Remote Protocol (DRSR) protocol to obtain sensitive information from the domain controller,
disguise the current host as a domain controller (DC), and persuade the real DC to synchronize its database with the malicious DC pretending to be the host by sending a request

Conditions of use

The DACL corresponding to the following extended permissions is required

According to 3gstudent master’s article, the following users in the group have the above permissions◼Users
in the Administrators group◼Users
in the Domain Admins group◼Users
in the Enterprise Admins group◼Computer
accounts of domain controllers

practice

The users in the Administrator group referred to here do not refer to the local Administrators on the domain machine, but the local Administrators group on the domain controller. Here
is an example of likaifeng01a user in the Administrators group at Red Sun Rangeliukaifeng01

The user is a member of the domain controller's local administrator group, but not a member of the domain administrator.
Get the member's ACL control list through Powerview's Get-DomainObjectAcl to view the above three permissions.

1. DS-Replication-Get-Changes-In-Filtered-Set
   
2. DS-Replication-Get-Changes
   
3. DS-Replication-Get-Changes-All
   

Satisfy the above three permissions, and export Hash through the dcsync function of mimikatz

You can also directly add the above three privileges to ordinary domain users through PowerView
, and then you can have the authority to execute Dcsync attacks. As a method of maintaining authority, you can first add an ordinary domain user hack , and hack direct Dcsync will fail.

Add three extended privileges to the domain user hack through PowerView with administrator privileges, Add-DomainObjectAcl -TargetIdentity "DC=god,DC=org" -PrincipalIdentity hack -Rights DCSync -Verbose
and then view the privileges owned by the user through ADfind.exe or Get-DomainObjectAcl AdFind.exe -sc getacls -sddlfilter ;;;;;god\hack -recmute

Get-ObjectAcl -Identity "dc=god,dc=org" -ResolveGUIDs | ? {$_.SecurityIdentifier -match "S-1-5-21-2952760202-1353902439-2381784089-1111"}

The screenshot is incomplete. It has been proved above that the hack user has these three permissions, and then call the dcsync module through mimikatz again to get all the Hash

Then delete the three extended privileges of the user. You can use the following command Remove-DomainObjectAcl -TargetIdentity "DC=god,DC=org" -PrincipalIdentity hack -Rights DCSync -Verbose
to delete and use the Dcsync module again, but it can no longer be obtained.

Tips
Dcsync攻击可以作为权限维持的方式=>拿到高权限后可以通过Powerview中的Add-DomainObjectAcl给普通用户添加上述三个特权,使普通用户仍然可以通过Dcsync获取所有Hash

tool address

kerbrutepyKerbruteRubeuskerberoastInvoke-Kerberoast

学习参考链接

上文学习总结自3gstudent文章，倾旋博客，unknowsec博客，car7n博客，Muxueo博客，harmj0y博客，安全客等等
当时看的有点太杂了，整理完笔记后发现很多粗看的文章都没记下来文章链接渗透技巧——通过Kerberos pre-auth进行用户枚举和口令爆破Kerberos的黄金票据详解Kerberos的白银票据详解彻底理解Windows认证 – 议题解读手把手教你入门内网渗透之二KerberosPass the Hash with Remote Desktop(Restricted Admin mode)【技术分享】Kerberoasting：一种Kerberos活动目录攻击方法域渗透——Kerberoasting高级域渗透技术之再谈Kerberoast攻击Roasting AS-REPs

关于PAC

对于PAC有疑惑的可以看下面的下四篇文章Windows内网协议学习Kerberos篇之PAC了解 Microsoft Kerberos PAC 验证PAC在Kerberos认证协议中的作用什么是 Kerberos PAC

来源：  https://forum.butian.net/share/614