12.1 Pass-the-Hash, Pass-the-Ticket, Pass-the-Token, and Kerberos Attacks
Key Takeaways
- PT0-003 objective 4.3 credential-reuse attacks split by material: pass-the-hash reuses an NTLM hash without cracking, pass-the-ticket reuses a Kerberos TGT or TGS, and pass-the-token reuses a stolen access, refresh, or session token.
- CME (CrackMapExec) consumes NTLM hashes or passwords to authenticate to many hosts; Responder captures NTLM challenge-response on the wire that later becomes pass-the-hash or offline-crack input.
- AS-REP roasting identifies accounts with Kerberos pre-authentication disabled; Kerberoasting identifies SPN-bearing service tickets as offline crack candidates.
- Golden and silver tickets are forged Kerberos tickets after KRBTGT or service-hash compromise — persistence findings, not a default next step after a help-desk hash.
- BloodHound on 4.3 is a priority map for which account is actually valuable to attack next, not a scanner and not a ticket cracker.
On CompTIA PenTest+ PT0-003, Domain 4 is Attacks and Exploits (35 percent of the exam). Objective 4.3 Given a scenario, perform authentication attacks is the credential chapter: testers abuse existing secrets instead of discovering a new CVE. This section covers pass-the-hash, pass-the-ticket, pass-the-token, and the Kerberos family. The next section covers password guessing, MFA fatigue, LDAP injection, and federation protocols. Exam items here are identification items. They ask which credential was reused and which attack name matches. They do not ask you to paste a dump command. Credential dumping itself is objective 4.4; 4.3 starts after the hash, ticket, or token is already in evidence.
Pass-the-hash: reuse the NTLM hash without cracking
Pass-the-hash (PtH) reuses a captured NT LAN Manager (NTLM) hash as if it were the password. Windows NTLM challenge-response can prove identity with the hash itself. The tester does not need the cleartext. If a hash for helpdesk is already in evidence — from a prior host, from an authorized dump described under 4.4, or from a Responder capture after LLMNR or NetBIOS name-service poisoning — the tester can authenticate as that user to Server Message Block (SMB), Windows Remote Management (WinRM), or Lightweight Directory Access Protocol (LDAP) services that still accept NTLM.
CME (CrackMapExec) is the 4.3 tool that consumes those hashes. You point CME at an in-scope host list and offer an NTLM hash instead of a password. A successful login is proof the hash is live. That is authentication testing, not cracking. hashcat and John the Ripper belong in the next section, where the goal is recovering cleartext from an offline hash. Exam trap: answering 'crack the hash, then log in' when the stem already gave you an NTLM hash and a file server that accepts NTLM. Pass-the-hash skips the crack.
Responder is the capture half of the same story. It poisons name resolution so a Windows client sends an NTLM challenge-response to the tester. The captured material is a hash that can later be passed or cracked. On 4.3, Responder is the answer when the stem is 'how did the tester obtain the NTLM hash on the wire.' CME is the answer when the stem is 'how did the tester use that hash against other hosts.' Neither tool is BloodHound, and neither is a vulnerability scanner.
Defenses you should recognize, not implement as a how-to: reducing NTLM where Kerberos can carry the load, requiring SMB signing, credential-guard style protections that make hashes harder to steal, and not reusing local administrator passwords across the fleet. The exam still wants the attack name: reusing the hash without cracking is pass-the-hash.
Pass-the-ticket: reuse a Kerberos TGT or TGS
Kerberos is ticket-based. The Authentication Service issues a ticket-granting ticket (TGT) after the user proves their identity. The Ticket Granting Service then issues service tickets (TGS) for specific services. Pass-the-ticket (PtT) reuses a stolen TGT or TGS. The tester places the ticket into a logon session and requests services the ticket already authorizes. No password and no NTLM hash are required.
Pass-the-ticket is not pass-the-hash. The credential type is a Kerberos ticket, not an NTLM hash. Tickets expire in hours. Hashes remain valid until the password changes. A stem that shows a captured TGT for j.smith, a service ticket for CIFS on FILE01, or 'the tester reused the existing Kerberos ticket' is pass-the-ticket. A stem that shows an NTLM hash string and SMB logons is pass-the-hash.
Pass-the-token: reuse a stolen access, refresh, or session token
Pass-the-token is the cloud, OpenID Connect (OIDC), and API cousin. The credential is an access token, refresh token, or session token — a bearer string, a cookie, or an Authorization header. If the token is still valid and the audience accepts it, the tester is that user until expiry or revocation. Typical surfaces: a browser localStorage identity token, a stolen Microsoft Graph or cloud security-token session, or a SaaS API refresh token left in an in-scope developer profile.
Exam trap: calling every stolen blob pass-the-ticket. Kerberos tickets live in Active Directory. OIDC and API tokens live in federation and cloud identity. Objective 4.3 lists both on purpose. Pass-the-token is also not credential stuffing, which reuses passwords from a breach list. Here the authentication material is already a live token.
Kerberos attacks: roast, then forge only after key compromise
CompTIA's Kerberos attacks bullet is a family. For PT0-003 you need identification and priority, not a forging tutorial.
AS-REP roasting targets accounts that do not require Kerberos pre-authentication. The Authentication Service will return an AS-REP encrypted with the user's key without the user proving they know the password first. That blob is an offline crack candidate. Identification: find users with pre-authentication disabled. Priority: those accounts, especially if they are privileged or have weak password-policy exceptions.
Kerberoasting targets service principal name (SPN) service accounts. Any authenticated domain user can request a TGS for a registered SPN. The service ticket is encrypted with the service account's password-derived key, so it is another offline crack candidate. Identification: inventory SPNs. Priority: high-privilege service accounts, old passwords, and accounts that also have path edges to Domain Admin.
BloodHound belongs here as a priority tool, not a scanner. On 3.1, BloodHound graphs Active Directory relationships. On 4.3, you use that graph to decide which account is actually valuable to attack next. A Kerberoastable sql-svc that BloodHound shows sitting on a shortest path to Domain Admin is a better next step than roasting a low-privilege printer account. BloodHound does not crack tickets and does not dump KRBTGT.
Golden tickets and silver tickets are forged Kerberos tickets after KRBTGT or service-hash compromise. A golden ticket is a forged TGT minted with the KRBTGT account's secret. A silver ticket is a forged TGS minted with a service account's secret and is limited to that service. The exam wants the concept: forging comes after the key is already compromised, it is a persistence and impersonation finding, and you report KRBTGT compromise as a forest-level incident — you do not publish a recipe. Do not treat a golden ticket as a default next step after a help-desk hash.
| Attack | Credential reused | Typical source | Not the same as |
|---|---|---|---|
| Pass-the-hash | NTLM hash, no crack required | Responder capture, prior host, authorized dump | Offline cracking with hashcat or John |
| Pass-the-ticket | Kerberos TGT or TGS | Stolen ticket from a session | Passing an NTLM hash |
| Pass-the-token | Access, refresh, or session token | Browser storage, API header, cloud STS | Kerberos pass-the-ticket |
| AS-REP roasting | AS-REP for no-preauth users | Identification of pre-auth disabled accounts | Requesting an SPN TGS |
| Kerberoasting | TGS for an SPN service account | Authenticated TGS request, then offline crack | Forging a golden ticket |
| Golden / silver ticket | Forged TGT / TGS | After KRBTGT or service-hash compromise | Roasting, which still needs a crack |
Worked matching
A tester has four artifacts from an in-scope domain: an NTLM hash for helpdesk, a TGT captured from a workstation session, an Azure access token from a browser profile, and a BloodHound path that marks sql-svc as Kerberoastable and one hop from a Domain Admin group. CME with the NTLM hash against FILE01 is pass-the-hash. Reusing the TGT is pass-the-ticket. Calling Microsoft Graph with the Azure token is pass-the-token. Requesting a TGS for sql-svc and sending that ticket to an offline cracker is Kerberoasting, chosen because BloodHound said that account is the valuable next hop. If KRBTGT were later compromised, a golden ticket would be a forged-TGT finding — still not a how-to, and still not the answer for the help-desk hash.
Keep the credential type in the front of your mind on test day. Hash without crack: pass-the-hash. Ticket reuse: pass-the-ticket. Cloud or API bearer: pass-the-token. No pre-auth: AS-REP roast. SPN service ticket: Kerberoast. Forged after KRBTGT or service-hash compromise: golden or silver. BloodHound tells you which of those accounts is worth the hours.
A tester already has an NTLM hash for the helpdesk account and authenticates to an in-scope file server without recovering the cleartext password. Which 4.3 attack is that?
During an authorized cloud review, a tester copies a still-valid Azure access token from a browser profile and calls Microsoft Graph as that user. Which 4.3 attack matches?
BloodHound shows that sql-svc is Kerberoastable and sits on a shortest path to a Domain Admin group. Which statement correctly applies 4.3 Kerberos attacks to that result?