RedTeam
5.Machine
3.Active-Directory
General
Exploitation
6.Persistence-AD
2.persistence through Tickets

General

Persistence through tickets refers to a method of maintaining access to a compromised network by using forged Kerberos tickets, such as Golden Tickets and Silver Tickets. These tickets are used to bypass normal authentication procedures and grant an attacker access to network resources without needing to know the user's password.

A Golden Ticket is a forged Kerberos Ticket Granting Ticket (TGT) that allows an attacker to impersonate any user in a Windows Active Directory environment. An attacker can create a Golden Ticket by using the Kerberos encryption key for the domain, which they can obtain through various means such as a successful pass-the-hash attack.

A Silver Ticket, on the other hand, is a forged Kerberos ticket that allows an attacker to impersonate a service account in a Windows Active Directory environment. An attacker can create a silver ticket by using the Kerberos service account name and the service's long-term key (which is known as the "service's password"), which they can obtain through various means such as dump the memory or cracking the password.

Once an attacker has successfully created a Golden Ticket or a Silver Ticket, they can use it to maintain access to the compromised network by continuously requesting new service tickets from the Ticket Granting Service (TGS) and presenting them to network resources. This allows the attacker to maintain a persistent presence on the network and continue to move laterally and perform malicious actions.

In the Kerberos authentication protocol, the Ticket Granting Ticket (TGT) is used to verify the identity of a user, while the Ticket Granting Service (TGS) is used to verify access to a specific service.

  • Golden tickets Golden Tickets are forgedĀ TGTs. What this means is we bypass steps 1 and 2 of the diagram above, where we prove to the DC who we are. Having a valid TGT of a privileged account, we can now request a TGS for almost any service we want. In order to forge a golden ticket, we need the KRBTGT account's password hash so that we can sign a TGT for any user account we want. Some interesting notes about Golden Tickets:

    • By injecting at this stage of the Kerberos process, we don't need the password hash of the account we want to impersonate since we bypass that step. TheĀ TGTĀ is only used to prove that the KDC on a DC signed it. Since it was signed by the KRBTGT hash, this verification passes and the TGT is declared valid no matter its contents.
    • Speaking of contents, the KDC will only validate the user account specified in theĀ TGTĀ if it is older than 20 minutes. This means we can put a disabled, deleted, or non-existent account in the TGT, and it will be valid as long as we ensure the timestamp is not older than 20 minutes.
    • Since the policies and rules for tickets are set in theĀ TGTĀ itself, we could overwrite the values pushed by the KDC, such as, for example, that tickets should only be valid for 10 hours. We could, for instance, ensure that our TGT is valid for 10 years, granting us persistence.
    • By default, the KRBTGT account's password never changes, meaning once we have it, unless it is manually rotated, we have persistent access by generating TGTs forever.
    • The blue team would have to rotate the KRBTGT account's password twice, since the current and previous passwords are kept valid for the account. This is to ensure that accidental rotation of the password does not impact services.
    • Rotating the KRBTGTĀ account's password is an incredibly painful process for the blue team since it will cause a significant amount of services in the environment to stop working. They think they have a valid TGT, sometimes for the next couple of hours, but that TGT is no longer valid. Not all services are smart enough to release the TGT is no longer valid (since the timestamp is still valid) and thus won't auto-request a new TGT.
    • Golden tickets would even allow you to bypass smart card authentication, since the smart card is verified by the DC before it creates theĀ TGT.
    • We can generate a golden ticket on any machine, even one that is not domain-joined (such as our own attack machine), making it harder for the blue team to detect.

    Apart from the KRBTGT account's password hash, we only need the domain name, domain SID, and user ID for the person we want to impersonate. If we are in a position where we can recover the KRBTGT account's password hash, we would already be in a position where we can recover the other pieces of the required information.

  • Silver Tickets Silver Tickets are forged TGS tickets. So now, we skip all communication (Step 1-4 in the diagram above) we would have had with the KDC on the DC and just interface with the service we want access to directly. Some interesting notes about Silver Tickets:

    • The generated TGS is signed by the machine account of the host we are targeting.

    • The main difference between Golden and Silver Tickets is the number of privileges we acquire. If we have the KRBTGT account's password hash, we can get access to everything. With a Silver Ticket, since we only have access to the password hash of the machine account of the server we are attacking, we can only impersonate users on that host itself. The Silver Ticket's scope is limited to whatever service is targeted on the specific server.

    • Since the TGS is forged, there is no associatedĀ TGT, meaning the DC was never contacted. This makes the attack incredibly dangerous since the only available logs would be on the targeted server. So while the scope is more limited, it is significantly harder for the blue team to detect.

    • Since permissions are determined through SIDs, we can again create a non-existing user for our silver ticket, as long as we ensure the ticket has the relevant SIDs that would place the user in the host's local administrators group.

    • The machine account's password is usually rotated every 30 days, which would not be good for persistence. However, we could leverage the access our TGS provides to gain access to the host's registry and alter the parameter that is responsible for the password rotation of the machine account. Thereby ensuring the machine account remains static and granting us persistence on the machine.

    • While only having access to a single host might seem like a significant downgrade, machine accounts can be used as normal AD accounts, allowing you not only administrative access to the host but also the means to continue enumerating and exploiting AD as you would with an AD user account.

More information about Kerberos ---> [[Red Team/6 - Machine/3 - Active Directory/Notes/Specific Topics/ā€¢ Kerberos]]

Commands

Golden Ticket

  • Requirements
    • NTLM hash of KRBTGT Account (Can be provided with DCsync ---> [[[1 - Persistence through Credentials]]])
    • Domain SID (Following Step)

Get SID

PS C:\Users\Administrator.ZA> Get-ADDomain

# Output
...
DomainSID : S-1-5-21-3885271727-2693558621-2658995185
...

Launch Mimikatz & Generate a Golden Tiket

PS C:\Users\Administator.ZA> mimikatz.exe

mimikatz # kerberos::golden /admin:ReallyNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:<Domain SID> /krbtgt:<NTLM hash of KRBTGT account> /endin:600 /renewmax:10080 /ptt
  • Parameters explained:
    • /adminĀ - The username we want to impersonate. This does not have to be a valid user.
    • /domainĀ - The FQDN of the domain we want to generate the ticket for.
    • /idĀ -The user RID. By default, Mimikatz uses RID 500, which is the default Administrator account RID.
    • /sidĀ -The SID of the domain we want to generate the ticket for.
    • /krbtgtĀ -The NTLM hash of the KRBTGT account.
    • /endinĀ - The ticket lifetime. By default, Mimikatz generates a ticket that is valid for 10 years. The default Kerberos policy of AD is 10 hours (600 minutes)
    • /renewmaxĀ -The maximum ticket lifetime with renewal. By default, Mimikatz generates a ticket that is valid for 10 years. The default Kerberos policy of AD is 7 days (10080 minutes)
    • /pttĀ - This flag tells Mimikatz to inject the ticket directly into the session, meaning it is ready to be used.

Verify that we have access to the domain controller

za\aaron.jones@THMWRK1 C:\Users\Administrator.ZA>dir \\thmdc.za.tryhackme.loc\c$\

Silver Ticket

mimikatz # kerberos::golden /admin:StillNotALegitAccount /domain:za.tryhackme.loc /id:500 /sid:<Domain SID> /target:<Hostname of server being targeted> /rc4:<NTLM Hash of machine account of target> /service:cifs /ptt
  • Parameters explained:
    • /adminĀ - The username we want to impersonate. This does not have to be a valid user.
    • /domainĀ - The FQDN of the domain we want to generate the ticket for.
    • /idĀ -The user RID. By default, Mimikatz uses RID 500, which is the default Administrator account RID.
    • /sidĀ -The SID of the domain we want to generate the ticket for.
    • /targetĀ - The hostname of our target server. Let's do THMSERVER1.za.tryhackme.loc, but it can be any domain-joined host.
    • /rc4Ā - The NTLM hash of the machine account of our target. Look through your DC Sync results for the NTLM hash of THMSERVER1$. The $ indicates that it is a machine account.
    • /serviceĀ - The service we are requesting in our TGS. CIFS is a safe bet, since it allows file access.
    • /pttĀ - This flag tells Mimikatz to inject the ticket directly into the session, meaning it is ready to be used.

Verify that we have access to the domain controller

za\aaron.jones@THMWRK1 C:\Users\Administrator.ZA>dir \\thmserver1.za.tryhackme.loc\c$\
1.persistence through Credentials3.persistence through Certificates