In a compromised Active Directory environment, attackers rarely need to crack a single password. They steal authentication artifacts and replay them. This is the core logic behind Pass-the-Hash and Pass-the-Ticket: two technically distinct techniques that share the same operational goal — lateral movement through identity impersonation.
How Pass-the-Hash works
The Pass-the-Hash (PtH) technique exploits the NTLM authentication protocol. When a Windows system authenticates via NTLM, it never transmits the plaintext password — only a derived hash. If an attacker can extract that hash from the memory of the lsass.exe process, it can be injected directly into an authentication flow without ever knowing the original password.
With Mimikatz, sekurlsa::logonpasswords dumps NTLM hashes cached in LSASS. From there, sekurlsa::pth /user:admin /domain:corp.local /ntlm:<hash> /run:cmd.exe spawns a shell carrying the target user's access tokens. The attacker now reaches network shares, RPC services, and admin consoles as if they were the legitimate user — and no failed password alert is triggered.
Why NTLM remains a viable attack surface
NTLM is decades old, but it stays enabled by default in most AD environments because legacy systems, network printers, and line-of-business applications still require it. Until organisations complete a proper NTLM deprecation project, PtH remains a practical attack path regardless of password complexity policies.
Pass-the-Ticket: abusing the Kerberos protocol
Pass-the-Ticket (PtT) operates on a different layer. Kerberos authentication relies on signed tickets issued by the Key Distribution Center. A Ticket Granting Ticket (TGT) proves user identity to the KDC, while a Service Ticket (TGS) grants access to a specific resource. Steal either from memory and you can reinject it into your own session to access whatever the original user had access to.
Rubeus is the standard tool for this. Rubeus.exe dump /luid:<id> extracts active Kerberos tickets from memory. Rubeus.exe ptt /ticket:<base64_ticket> injects them into the current session. Unlike PtH, this generates no NTLM events — everything flows through Kerberos, making detection harder for tools focused solely on NTLM telemetry.
Golden Ticket and Silver Ticket: the advanced variants
PtT enables two particularly dangerous extensions. A Golden Ticket is a forged TGT crafted using the hash of the krbtgt account, which signs every Kerberos ticket in the domain. With that hash, an attacker can mint valid tickets for any user — including non-existent accounts — with arbitrary lifetimes. A Silver Ticket skips the KDC entirely, forging a TGS directly using a service account hash, which makes it even harder to detect at the domain level.
Side-by-side comparison of both techniques
Both techniques target process memory to steal authentication artifacts, but their profiles differ significantly for detection and remediation purposes. PtH depends on NTLM and generates identifiable Windows events (Event ID 4624, logon type 3). PtT stays within Kerberos and is far quieter on standard endpoints. PtH works against any NTLM-enabled service; PtT is scoped to Kerberos-integrated services, but that covers virtually everything in a standard AD setup.
How Credential Guard neutralises both attack vectors
Credential Guard isolates LSASS inside a secure execution environment using Virtualization Based Security (VBS). The protected LSASS process runs inside a hardware-level enclave that the Windows kernel itself cannot directly address. Mimikatz, which relies on injecting code into LSASS or reading its memory through kernel handles, is stopped cold: NTLM hashes and Kerberos tickets are no longer reachable from the standard ring 0 execution context.
For PtH, the impact is immediate — no memory access, no hash extraction, no replay. For PtT, Credential Guard blocks the extraction of Kerberos tickets from LSASS memory, rendering Mimikatz's sekurlsa::tickets and Rubeus.exe dump ineffective against protected sessions. Both tools encounter access denied errors where they once had free rein.
The real limits of Credential Guard
Credential Guard is a strong control, but treating it as a complete solution is a mistake that experienced defenders avoid. Several concrete limitations deserve honest consideration.
Partial account coverage
Interactive domain accounts benefit from VBS protection, but service accounts configured with unconstrained Kerberos delegation can still expose exploitable tickets. If even one domain member server lacks Credential Guard, it remains a valid target — protected workstations don't compensate for unprotected servers in the attack path.
Documented bypass scenarios
Published research demonstrates that unconstrained delegation configurations allow capturing TGTs through authentication coercion techniques like PetitPotam or PrinterBug, without ever touching LSASS. Credential Guard offers no protection here. Additionally, on systems where kernel integrity can be compromised via vulnerable drivers (BYOVD attacks), the VBS boundary itself can potentially be crossed.
Hardware and deployment constraints
Credential Guard requires UEFI Secure Boot, TPM 2.0, and Windows Pro or Enterprise editions. In the heterogeneous endpoint environments common across Morocco and sub-Saharan Africa, a meaningful portion of the fleet often doesn't meet these requirements, leaving gaps in the overall defence posture. The feature is also incompatible with certain nested virtualisation setups.
What Credential Guard doesn't replace
Even when deployed correctly, Credential Guard doesn't prevent credential theft via keyloggers, attacks against the domain controller's NTDS.dit file, or abuse of misconfigured AD permissions. It reduces the in-memory attack surface — nothing more, nothing less. A layered defence strategy remains essential.
Frequently asked questions
What is the key difference between Pass-the-Hash and Pass-the-Ticket?
PtH abuses NTLM by replaying a hash extracted from LSASS, while PtT operates on Kerberos by reinjecting stolen tickets. Both bypass the need for a plaintext password, but their underlying authentication protocols differ, which means detection strategies must also differ.
Does Credential Guard protect against Golden Tickets?
Credential Guard prevents the extraction of the krbtgt hash from LSASS on protected machines. However, if that hash is obtained through other means — such as a DCSync attack against a domain controller — the protection no longer applies. Securing the krbtgt account and monitoring AD replication events remain critical complementary controls.
Can these attacks be detected without an advanced EDR?
Partially. Windows Event IDs (4624, 4768, 4769) provide useful signals, particularly for detecting anomalous NTLM logons or unusual Kerberos ticket requests. Without SIEM correlation and behavioural baselines, though, these events are easily lost in the volume of activity generated by a busy Active Directory environment.
Do antivirus solutions detect Rubeus?
Known Rubeus signatures are detected by most antivirus products, but obfuscated or recompiled variants routinely bypass signature-based detection. This is precisely why layered defence — combining Credential Guard, Kerberos monitoring, and behavioural EDR — is more reliable than signature scanning alone.