Kerberoasting
Kerberoasting targets service accounts. Any domain user can request a service ticket for any service that has a Service Principal Name (SPN) set. The service ticket is encrypted with the service account's NTLM hash. You request the ticket, receive it, extract it, and crack it offline. If the service account has a weak password, you crack it without ever touching the service account directly.
The reason this is so effective in real environments is that service accounts are often created with passwords that don't expire and that were set years ago. The password complexity requirements at the time of creation might have been weaker, and nobody's rotated it since. A cracked service account password is often local admin on multiple systems because service accounts tend to be over-privileged.
GetUserSPNs.py -request -dc-ip DC_IP domain/user:password hashcat -m 13100 kerberoast_hash.txt wordlist.txt
AS-REP Roasting
AS-REP Roasting targets accounts that have pre-authentication disabled. Normally, Kerberos requires a client to prove knowledge of the account's password before issuing a TGT. When pre-authentication is disabled, the KDC will respond to any AS-REQ for that account, encrypting the TGT with the account's password hash. You collect this encrypted response and crack it offline.
Unlike Kerberoasting, you don't need a domain account to perform AS-REP Roasting. You can attack it from unauthenticated if you have a list of valid usernames — though you do need to know which accounts have pre-auth disabled, which usually requires being on the domain already or having gotten a user list some other way.
Pass-the-Hash and Pass-the-Ticket
NTLM authentication doesn't require you to know the plaintext password. The protocol uses the hash directly in the challenge-response exchange. If you've captured a hash from LSASS, a SAM dump, or an NTDS extraction, you can authenticate as that user by passing the hash without needing to crack it. This is pass-the-hash, and it works against most Windows authentication scenarios that fall back to NTLM.
Pass-the-Ticket is the Kerberos equivalent. Instead of using a hash, you use a Kerberos ticket extracted from memory. If you can extract a TGT from a privileged account's session on a compromised machine, you can inject that ticket into your own session and authenticate as that user to any service they have access to.
Golden Ticket
The krbtgt account's hash is used to sign all Kerberos TGTs in the domain. If you DCSync and extract the krbtgt hash, you can forge TGTs for any account, including non-existent ones, with any group memberships you want, and with validity periods up to 10 years. This is the Golden Ticket attack — effectively persistent and undetectable until the krbtgt password is rotated twice.
DCSync
DCSync abuses the Directory Replication Service protocol. Domain controllers replicate directory data between each other by requesting changes via the MS-DRSR protocol. Any account with the DS-Replication-Get-Changes-All permission can request replication data — which includes password hashes.
This means that from any machine on the network, with an account holding the right replication permissions, you can pull every password hash in the domain without ever touching the DC directly. The target DC thinks it's just talking to another DC for routine replication. No code execution required on the domain controller itself.
secretsdump.py -just-dc domain/user:password@DC_IP lsadump::dcsync /user:krbtgt # via mimikatz