Pass-the-Hash (PtH) is a credential-abuse technique in which an attacker uses stolen password-derived authentication material instead of knowing a user’s plaintext password. The risk is greatest when a privileged credential can be reused across multiple computers. This guide focuses on how defenders can understand the authentication protocols, interpret Windows logon telemetry, reduce exposure, and investigate suspected lateral movement.

NTLMv1, NTLMv2, and Kerberos are not interchangeable

NTLM is a family of Windows challenge-response authentication protocols. NTLMv1 is a legacy option with weaker protections and should be disabled wherever application compatibility permits. NTLMv2 improves the challenge-response protocol, but it does not make a stolen password-derived secret harmless: if an attacker obtains usable credential material, NTLM-based authentication can still be abused. Moving to NTLMv2 is not a substitute for protecting credentials or restricting where accounts can log on.

Kerberos is the preferred protocol for domain authentication in Active Directory environments. It uses tickets issued by the domain’s Key Distribution Center to authenticate users to services. A stolen Kerberos ticket is associated with Pass-the-Ticket, a different technique from PtH. A captured NTLM hash is not itself a Kerberos ticket, although misconfiguration, legacy dependencies, and protocol fallback can leave NTLM authentication available in an otherwise Kerberos-based network.

Windows logon types: useful context, not verdicts

Windows Security event 4624 records a successful logon session on the computer that accepted the logon. Its Logon Type field describes the kind of session—not whether it is malicious. Common types include:

• Type 2, Interactive: a local sign-in at the computer.
• Type 3, Network: access to a computer over the network, such as a service or file-share connection.
• Type 9, NewCredentials: a local session uses different credentials for outbound network connections.
• Type 10, RemoteInteractive: an interactive remote session, commonly associated with Remote Desktop.
• Type 11, CachedInteractive: an interactive sign-in validated with cached domain credentials.

Investigators should correlate the logon type with the authentication package, account, source device and address, destination host, time, and the account’s normal work pattern. A single Type 3 or Type 9 event is not proof of PtH; legitimate applications and administration workflows can produce these events.

Detection: correlate identity and endpoint telemetry

Useful Windows Security events include 4624 for successful logons, 4625 for failed logons, 4648 when a process attempts to use explicit credentials, and 4776 for NTLM credential validation. Domain controllers also record Kerberos ticket activity in events such as 4768 and 4769. Event availability depends on audit policy and system role, so verify collection and retention before relying on these signals.

Look for combinations that do not fit the environment’s baseline: privileged accounts authenticating to unusual workstations, one account appearing across many endpoints in a short period, unexpected NTLM use where Kerberos is normally expected, or a network logon followed by privileged activity on a host that the account rarely accesses. Enrich these observations with endpoint process and network telemetry, account privilege changes, and the identity’s recent authentication history.

EDR and identity-threat-detection products can help connect activity that would otherwise be split across endpoint and domain-controller logs. For example, Microsoft Defender for Endpoint provides endpoint telemetry, Microsoft Defender for Identity analyzes identity signals, and a SIEM can correlate retained events across systems. These tools improve visibility; none should be treated as a replacement for correctly configured auditing, a known-good baseline, and analyst validation.

Where credential material lives—and how to protect it

There is not one universal “folder” containing all credentials. Windows authentication material is managed by operating-system security components and can exist in protected memory or other credential mechanisms depending on the logon and application. For defenders, the safer approach is to reduce access to sensitive processes and secrets rather than searching for, copying, or circulating credential stores.

• Enable and validate Credential Guard on supported devices to isolate protected secrets using virtualization-based security.
• Enable Local Security Authority protection where supported and monitor for changes to credential-protection settings.
• Use Windows LAPS or an equivalent managed solution so local administrator passwords are unique and rotated, not reused across endpoints.
• Separate administrative accounts from everyday user accounts and restrict where privileged identities are permitted to sign in.

Prevention and response priorities

Audit NTLM usage before restricting it, identify legacy dependencies, and then reduce or disable NTLM where the business can support it. Prefer Kerberos for domain services, remove unnecessary local administrator rights, apply least privilege, and use phishing-resistant multifactor authentication for administrative access where available. SMB signing and LDAP signing or channel binding strengthen related network authentication paths, but do not by themselves prevent PtH.

If you suspect credential reuse, isolate affected endpoints according to your incident plan, preserve endpoint and domain-controller logs, identify every host where the account authenticated, and rotate credentials from a trusted device after containment. Review privileged sessions and persistence indicators before returning systems to service. Avoid resetting credentials from a potentially compromised endpoint, where new secrets could be exposed again.

Sources

• Microsoft Learn: NTLM overview
• Microsoft Learn: Kerberos authentication overview
• Microsoft Learn: Security event 4624 and logon sessions
• Microsoft Learn: Credential Guard overview

Logon types and event IDs provide investigation context, not standalone indicators of compromise. Validate detections against your Windows versions, audit policy, and normal administrative activity.