Attacks
Some Techniques used to gain any form of Access, Code Execution, Privesc, Persistence or Info in General.
Unconstrained Delegation.
When a user accesses a server with unconstrained delegation enabled, the user sends their TGT to the server. The server can then impersonate the user by using their user's TGT to authenticate to other services in the network.
But first what is delegation?, Delegation is a feature in Active Directory that allows a user or a computer to impersonate another account. Microsoft had to provide a simple mechanism to support scenarios where a user authenticates to a Web Server via Kerberos and needs to update records on a back-end database server on behalf of the user. This is typically referred to as the "Kerberos double-hop issue" and requires delegation.
What's the Risk?
Once you turn on unconstrained delegation to a computer, any time an account connects to that computer for any reason, their ticket (TGT) is stored in memory so it can be used later by the computer for impersonation. Let's say you enable this option on a computer you have administrative access to and then get a Domain Admin user to access the computer over the Common Internet File System (CIFS) by accessing a shared folder. Without unconstrained delegation on, only the ticket-granting server (TGS) would be stored in memory on your compromised machine. This ticket gives access only to the CIFS service on your machine so you can't use it to move laterally. However, with unconstrained delegation enabled, when the privileged user connects to your machine, their TGT will stored in memory, which can be replayed to move laterally and compromise a domain controller.
Constrained Delegation
Constrained delegation is a way to limit exactly what a services a particular machine/account can access while impersonating other users. The 'service' specified is a service principal name that the account is allowed to access while impersonating other users. PowerView can help in locating these attributes, the filed of interest is the msds-allowedtodelegateto, but there 's also a modification to the account's userAccountControl property. Essentially, if a computer/user object has a userAccoutnControl value containing TRUSTED_TO_AUTH_FOR_DELEGATIONthen anyone who compromises that account can impersonate any user to the SPNs set in the msds-allowedtodelegateto. Benjamin Delpy (@gentlekiwi) mentioned that SeEnableDelegationPrivilege being required to actually modify there parameters.
What's the Risk?
If you are able to compromise a user account with SPNs set under msds-allowedtodelegateto can pretend to be any user they want to the target service SPN. For the HOST SPN this allows complete remote takeover. For MSSQL SPN this would allow DBA rights. A CIFS SPN would allow complete remote file access. A HTTP SPN it would likely allow for the takeover of the remote web-service, and LDAP allows for DCSync. HTTP/SQSL service accounts, even if they aren't elevated admin on the target, can possibly be abused with Rotten Potato to elevate rights to SYSTEM.
DCSync
The concept of DCSync is that it impersonates a Domain Controller to request all the hashes of the users in that domain. Yes. This means, as long as you have permissions, you do not need to run any commands on the Domain Controller and you do not have to drop any files on DC.
For this to work, it is important to have proper permissions to pull hashes from a Domain Controller. Generally limited to the Domain Admins, Enterprise Admins, Domain Controller Groups, and anyone with the Replicating Changes permissions set to Allow (i.e., Replicating Changes All/Replicating Directory Changes), DCSync will allow your user to perform this attack with the use of mimikatz.
What's the Risk?
Well if a user can impersonate a Domain Controller and request for all the domain user's passwords, that is enough risk.
Kerberoasting
For more on Kerberoasitng.
So I talked about this attack in the Credential Dumping Section, basically you have SPN services/users the attack work's because by default any domain user can request for a Ticket to these user's/services the Kerberos grant's a ticket, this ticket is later stored in memory and you can grab this ticket, save it offline and crack the hash file to gain clear-text credentials.
What's the risk?
Well it all depends on the SPNs permission, but these are usually set to access important DB or Files in the AD. This attack is also helpful to maintain Persistence, Privilege Escalate or Lateral Movement.
Silver Tickets
Silver Tickets enable an attacker to create forged service tickets (TGS Tickets). These tickets can provide access to the service that was compromised wit a Kerberoasting attack. For example, in a Kerberoast Attack, a SPN Account to the MSSQL Service was compromised. Now we can use Silver Tickets to forge TGS Tickets for the Microsoft SQL service on that host. This tactic by itself may not sound verty valueable since we already have compromised the account associated with the SPN and wouldn't need to forge tickets to act on its behalf.
What's the risk?
The attacker does not need to authenticate the account to the domain controller to obtain the forged TGS. This can be done without creating network traffic end event logs to avoid detection. The forged ticket can be created on behalf of any user account, even fictitious accounts. This allows the access of the service account to be exploited without risking detection that the account has been compromised, which may result in a password reset. The Privileged Attribute Certificate (PAC) within the TGS ticket can also be manipulated, elevating the account's access to that of a Domain Administrator. In most cases, the PAC is not validated against the domain controller when the TGS is provided.
Golden Tickets
The KRBTGT Account, every Active Directory domain controller is responsible for handling Kerberos Ticket requests, which are used to authenticate users and grant them access to computers and applications. The KRBTGT account is used to encrypt and sign all Kerberos tickets within a domain, and domain controllers use the account password to decrypt Kerberos tickets for validation. This account password never changes, and the account name is the same in every domain, so it's a well known target for attackers.
What's the risk?
Once an attacker compromises the KRBTGT account they can create forged Kerberos tickets (TGTs) which can be used to request TGS tickets for any service on any computer in the domain. But remember the hardest part to this attack is you need Administrator Access to the DC (Domain Controller), these are attacks hard to detect because they are valid TGTs.
Resources:
Unconstrained Delegation:
Constrained Delegation:
DCSync:
The Hacker's PlayBook 3
Silver Tickets:
Golden Tickets:
Last updated
