Active Directory Persistence
In many real-world penetration tests or red-team engagements, persistence is NOT part of the scope due to the risk of incomplete removal once the assessment is complete. Here are a few AD-specific persistence techniques
Golden Ticket
How it Works
When a user submits a request for a TGT, the KDC encrypts the TGT with a secret key known only to the KDCs in the domain. This secret key is the password hash of a domain user account called krbtgt. If we can get our hands on the ktbtgt password hash, we could create our own self-made custom TGTs, also known as golden tickets.
This provides a neat way of keeping persistence in AD, but the best advantage is the the krbtgt password is not automatically changed. The password is only changed when the domain functional level is upgraded from a pre-2008 Windows server.
Because of this, it is not uncommon to find very old ktbtgt passwords.
Creating a Golden Ticket
First, we can test an operation that we don't have privilege to perform:
C:\Tools\SysinternalsSuite>PsExec64.exe \\DC1 cmd.exe
PsExec v2.4 - Execute processes remotely
Copyright (C) 2001-2022 Mark Russinovich
Sysinternals - www.sysinternals.com
Couldn't access DC1:
Access is denied.At this stage of the engagement, the golden ticket will require us to have access to a Domain Admin's group account or to have compromised the domain controller itself to work as a persistence method.
With this level of access, we can extract the password hash of the krbtgt account using Mimikatz
Now that we have the NTLM hash of the krbtgt account along with the domain SID, we can now create our golden ticket.
Creating the golden ticket and injecting it into memory does not require any administrative privileges and can even be performed from a computer that is not joined to the domain.
First you can delete any existing Kerberos tickets using mimikatz kerberos::purge.
Now we'll use the /krbtgt option instead of /rc4 to indicate we are supplying the password hash of the krbtgt user account. Starting July 2022, Microsoft improved the authentication process, so we'll need to provide an existing account.
Mimikatz provides two sets of default values when using the golden ticket option: the user ID and the groups ID. The user ID is set to 500 by default, which is the RID of the built-in administrator for the domain. The values for the groups ID consist of the most privileged groups in Active Directory, including the Domain Admins group.
With the golden ticket injected into memory, We can now use PsExec to launch a new command prompt with the misc::cmd
We can also now verify that our user is part of the Domain Admins groups:
This is an overpass the hash style attack leveraging Kerberos authentication, so if we tried to connect PsExec to the IP address of the domain controller instead of the hostname, we would instead force the use of NTLM authentication and access would still be blocked.
Shadow Copies
A Shadow Copy or a Volume Shadow Service (VSS) is a Microsoft backup technology that allows the creation of snapshots of files or entire volumes.
To manage volume shadow copies, the Microsoft signed binary vshadow.exe is offered as part of the Windows SDK.
If we have control of a domain admin, we can abuse the vshadow utility to create a Shadow Copy that will allow us to extract the Active Directory Database NTDS.dit database file. Once we have a copy of the database, we need the SYSTEM hive and then we can extract every user credential offline on our local Kali machine.
Creating Shadow Copies
Launch an elevated command prompt and run the vshadow utility with -nw options to disable writers
Once the snapshot has been taken successfully, we should take not of the shadow copy device name.
We'll now copy the whole AD Database from the shadow copy to the C: drive root folder by specifying the shadow copy device name and adding the full ntds.dir path.
To correctly extract the content of ntds.dit we need to save the SYSTEM hive from the Windows registry by using the reg utility
Once we have extracted the two .bak files we can use impacket-secretsdump to extract the credentials from the database:
Now we have obtained the NTLM hashes and Kerberos keys for every AD user. We can now try to crack them or use them as-is in pass-the-hash attacks.
These methods leave an access trail and will require us to upload tools. An alternative is to abuse AD functionality itself to capture hashes remotely from a workstation.
To do this, we could move laterally to the domain controller and run Mimikatz to dump the password hash of every user, using the DC sync method described in the previous Module. This is a less conspicuous persistence technique that we can misuse.
Although most penetration tests wouldn't require us to be covert, we should always evaluate a given technique's stealthiness, which could be useful during future red-teaming engagements.
Last updated