Select password, NT hash, key-to-ticket or ticket authentication

Needs: Credential type accepted by the chosen protocol/client, correct identity/domain, naming/time and destination authorization

Pass-the-Hash

# Pass-the-Hash
NT HASH -> NTLM CHALLENGE/RESPONSE -> TARGET SERVICE

# Mimikatz network-credential context
sekurlsa::pth /user:USER /domain:DOMAIN /ntlm:NT_HASH /run:powershell.exe

PtH requires an NTLM-capable service, a valid account context and the service-specific right. SMB share access may work without administrative execution; PsExec/WMIExec/SMBExec usually need administrative rights. Remote UAC commonly filters non-built-in local administrators. Domain accounts in the target Administrators group traditionally receive a full remote token, but newer Administrator Protection policy can change that result—trust the observed target token and method-specific authorization.

Rubeus TGT request

REM Rubeus TGT request
Rubeus.exe asktgt /user:USER /domain:DOMAIN /rc4:NT_HASH /dc:DC_HOST /ptt
klist

REM AES alternative
Rubeus.exe asktgt /user:USER /domain:DOMAIN /aes256:AES256_KEY /dc:DC_HOST /ptt

REM Trigger a Kerberos service request with the hostname, then inspect
dir \\TARGET_HOST\C$
klist

REM Windows
Rubeus.exe ptt /ticket:ticket.kirbi
klist

In a Mimikatz sekurlsa::pth process, whoami can still show the original local process token while network authentication uses the supplied identity. Validate the ticket's client and the remote result rather than treating local whoami as the network identity.

Pass-the-Ticket

# Pass-the-Ticket
kerberos::ptt ticket.kirbi

Linux

# Linux
export KRB5CCNAME="$PWD/ticket.ccache"
klist
impacket-wmiexec -k -no-pass -dc-ip DC_IP -target-ip TARGET_IP 'DOMAIN/USER@TARGET_HOST'

A TGS must name the selected service/hostname. A TGT can request a suitable TGS only while valid and when the KDC is reachable. Ticket import is not lateral movement until the destination accepts it and produces the intended authorized effect.

Verify → Verify exact material type, represented network identity and successful destination action.

If it fails → Wrong ticket service, RC4 policy, time skew, IP-only SPN naming or local/domain mismatch can invalidate one variant while another remains viable. More detail ↓

If → then

A destination grants administrative-share write and service-control rights → Execute through uploaded service creation using PsExec
Needs: SMB/SCM reachability, writable required share, effective service-creation/start rights and an accepted password/hash or supported Kerberos context
A destination exposes WMI/DCOM and the identity has useful namespace/process rights → Execute through WMI or native CIM over DCOM
Needs: RPC endpoint mapper plus negotiated dynamic ports; effective WMI/DCOM rights; the selected output path may additionally need SMB
A WinRM listener and a candidate endpoint-authorized account → Use WinRM, WinRS or PowerShell remoting
Needs: Reachable HTTP(S) listener, accepted authentication and endpoint/session configuration permissions; hash/ticket support depends on client/context
A valid ticket/cache or a long-term key that can request a TGT → Inventory, convert and import tickets in the correct logon context
Needs: Matching client/realm/service, valid lifetime, compatible format and available KDC/service routes; ticket import affects a specific context

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Select password, NT hash, key-to-ticket or ticket authentication

USE WHEN: A password, actual NT hash, AES/NT long-term key or ticket is available
STARTING ACCESS: Identified authentication material, destination service reachability and a candidate authorized identity
RESULT: A compatible authenticated service operation using the available material

Recognize the clue

Return to the credential source and inspect format, identity and ticket service scope before selecting a remote protocol.

klist
getent hosts TARGET_HOST
date -u

SYNTHETIC EXAMPLE OUTPUT

Available cache: cifs/TARGET_HOST@REALM
No TGT present
Target hostname: resolves through selected route

Means: The cache permits investigating a matching CIFS action, not arbitrary WinRM or a new TGS without a TGT/KDC route.

Confirm: Match NTLM versus Kerberos support, account/domain, key/encryption policy, name/time and destination rights.

After validation: The selected client/service accepts the exact material and action: use that method.
Ruled out in this context: Only a challenge response is available for a direct NT-hash client: reject the type mismatch.
Still inconclusive: An unlabelled hash or unknown ticket lifetime requires classification first.

Troubleshooting: Wrong ticket service, RC4 policy, time skew, IP-only SPN naming or local/domain mismatch can invalidate one variant while another remains viable.

Pass-the-Hash

PtH requires an NTLM-capable service, a valid account context and the service-specific right. SMB share access may work without administrative execution; PsExec/WMIExec/SMBExec usually need administrative rights. Remote UAC commonly filters non-built-in local administrators. Domain accounts in the target Administrators group traditionally receive a full remote token, but newer Administrator Protection policy can change that result—trust the observed target token and method-specific authorization.

Overpass-the-Hash / key-to-ticket

Mimikatz network-credential context:

Rubeus TGT request:

AES alternative:

Trigger a Kerberos service request with the hostname, then inspect:

In a Mimikatz sekurlsa::pth process, whoami can still show the original local process token while network authentication uses the supplied identity. Validate the ticket's client and the remote result rather than treating local whoami as the network identity.

Pass-the-Ticket

Windows:

Linux:

A TGS must name the selected service/hostname. A TGT can request a suitable TGS only while valid and when the KDC is reachable. Ticket import is not lateral movement until the destination accepts it and produces the intended authorized effect.

Why it works

Pass-the-Hash uses NTLM key material; Overpass-the-Hash/key-to-ticket requests Kerberos credentials; Pass-the-Ticket uses an existing ticket. They do not grant the same services without their own rights and scope.

Worked example · hypothetical

Observation: an NT hash works for NTLM SMB but an RC4 TGT request fails. Test: inspect domain encryption policy and available key types. Illustrative output: RC4 is disabled. Interpretation: use an allowed existing service route or a supported AES/key/password transition.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗