This chapter covers two critical identity-based attack patterns: Pass-the-Hash (PtH) and Kerberoasting. These attacks exploit weaknesses in Windows authentication protocols and are frequently tested on the CS0-003 exam, appearing in approximately 10-15% of questions in Domain 1.0 (Security Operations). Understanding these attacks is essential for detecting and mitigating credential theft and lateral movement in Active Directory environments. You will learn the underlying mechanisms, detection techniques, and defensive measures.
Jump to a section
Imagine a secure office building where employees use key cards to enter. Each card has a unique ID and a stored hash of the employee's PIN. When an employee swipes in, the door reader hashes the entered PIN and compares it to the stored hash. If they match, the door unlocks. Now, a malicious insider steals a co-worker's key card but doesn't know the PIN. However, they discover that the door reader doesn't require the PIN again after the first successful swipe—it just caches the hash. The attacker clones the hash from the card and uses it directly to access the building, bypassing the PIN entirely. This mirrors Pass-the-Hash: the attacker captures the NTLM hash from a compromised system and reuses it to authenticate to other systems without knowing the plaintext password. The hash is the key card; the PIN is the password. The reader's trust in the cached hash is the vulnerability. Similarly, Kerberoasting is like convincing the security desk to give you a copy of all employee key card hashes by asking for a service report, then cracking the PINs offline.
What is Pass-the-Hash?
Pass-the-Hash (PtH) is a technique where an attacker captures a user's NTLM password hash (not the plaintext password) and uses it to authenticate to remote systems or services. This attack works because NTLM authentication uses the hash as the secret—knowing the hash is sufficient to prove identity. PtH is particularly dangerous in Windows domains where users reuse credentials across multiple systems.
How NTLM Authentication Works
NTLM uses a challenge-response mechanism. When a client wants to authenticate to a server: 1. The client sends a request to the server. 2. The server responds with a random 8-byte challenge (nonce). 3. The client encrypts the challenge with the user's NTLM hash (derived from the password) using DES (for LM) or MD4 (for NTLMv1/v2). 4. The server verifies the response by performing the same computation and comparing.
The key point: the hash is the secret. If an attacker has the hash, they can compute the correct response to any challenge without knowing the password.
Pass-the-Hash Attack Steps
Hash Extraction: The attacker gains administrative access to a system (e.g., via phishing, exploit) and extracts hashes from memory (LSASS process) or the SAM database. Tools: Mimikatz, Meterpreter, Windows Credential Editor.
Hash Reuse: Using tools like Mimikatz, the attacker injects the hash into a new logon session. Mimikatz uses the sekurlsa::pth module to create a token with the stolen hash.
Authentication: The attacker uses the token to authenticate to other systems (e.g., via PsExec, SMB, WMI) as the stolen user.
Key Components and Defaults
NTLM Hash: 32-character hexadecimal string. For NTLMv1, the hash is MD4 of the password. For NTLMv2, it includes a timestamp and other data.
LSASS (Local Security Authority Subsystem Service): Stores user credentials in memory after logon. On Windows 8.1/Server 2012 R2 and later, LSASS runs as a Protected Process Light (PPL) to resist dumping.
Mimikatz: The most common tool for PtH. Command: sekurlsa::pth /user:DOMAIN\User /domain:DOMAIN /ntlm:HASH.
Windows Credential Guard: Virtualization-based security that isolates LSASS secrets, preventing extraction even with admin rights.
Detection of Pass-the-Hash
Event ID 4624 (Logon): Look for logon type 3 (network) with unusual source IPs or multiple logons from different systems using the same account.
Event ID 4672 (Special Logon): Assigning of sensitive privileges (SeTcbPrivilege) during logon.
Event ID 4648 (Logon with Explicit Credentials): Indicates use of cached credentials.
Anomalous NTLM traffic: Multiple authentication attempts from a single host to many targets.
Mitigation
Enable Credential Guard: Prevents hash extraction from LSASS.
Use Kerberos: Kerberos uses tickets, not hashes, and is resistant to PtH if properly configured.
Limit Local Admin Privileges: Reduce the number of accounts that can extract hashes.
Network Segmentation: Limit lateral movement paths.
Monitor for Mimikatz: Use AV/EDR to detect Mimikatz binaries or behavior.
What is Kerberoasting?
Kerberoasting is a post-exploitation attack that targets service accounts in Active Directory. The attacker requests a Kerberos service ticket (TGS) for a service running under a user account, then extracts the ticket and cracks the service account password offline.
How Kerberos Authentication Works
User authenticates to the Key Distribution Center (KDC) and receives a Ticket Granting Ticket (TGT).
To access a service, the user requests a Service Ticket (TGS) from the KDC.
The TGS is encrypted with the service account's NTLM hash. The user never sees the hash; they receive the encrypted ticket.
The user presents the TGS to the service, which decrypts it with its own hash.
Kerberoasting Attack Steps
Request TGS: The attacker (who already has a TGT) requests a TGS for any service principal name (SPN) in the domain. Tools: GetUserSPNs (Impacket), Rubeus, Mimikatz.
Extract Ticket: The TGS is returned to the attacker in the Kerberos reply. The ticket is encrypted with the service account's NTLM hash.
Offline Cracking: The attacker saves the ticket and cracks the service account password using tools like Hashcat or John the Ripper. The hash format is $krb5tgs$23$*user$realm$spn*$ciphertext.
Use Credentials: Once cracked, the attacker can use the service account password to access resources.
Key Components and Defaults
Service Principal Name (SPN): Unique identifier for a service instance. Examples: HTTP/webserver.domain.com, MSSQLSvc/sqlserver.domain.com:1433.
Service Account: A user account under which a service runs. Often has elevated privileges.
TGS Encryption: RC4-HMAC (type 23) by default, which is crackable offline. AES encryption (type 18) is stronger but less common.
Hashcat Mode: 13100 for TGS-REP (Kerberoasting).
Detection of Kerberoasting
Event ID 4769 (Kerberos Service Ticket Requested): Look for multiple TGS requests for different services from a single user, especially if the user does not normally access those services.
Event ID 4776 (Credential Validation): Service account logon failures if cracking attempts are online.
Anomalous SPN queries: Use of tools like GetUserSPNs generates distinct LDAP queries.
Mitigation
Use Strong Passwords: Service account passwords should be long (25+ characters) and complex.
Managed Service Accounts (MSAs): Group Managed Service Accounts (gMSAs) have automatic password rotation and are not subject to Kerberoasting.
Disable RC4 Encryption: Configure Kerberos to use AES encryption only. This makes cracking significantly harder.
Monitor Service Account Logons: Alert on service account usage from non-service hosts.
Limit SPNs: Only assign SPNs to accounts that need them.
Comparison of PtH and Kerberoasting
Privilege Requirement: PtH requires administrative access to extract hashes; Kerberoasting requires only a valid domain user account.
Offline vs Online: Kerberoasting is offline cracking; PtH uses the hash directly online.
Target: PtH targets any user hash; Kerberoasting targets service accounts.
Persistence: PtH is ephemeral (hash can be rotated); Kerberoasting reveals plaintext password, allowing long-term access.
Exam Tips
The CS0-003 exam often asks which attack uses offline cracking (Kerberoasting) vs online hash reuse (PtH).
Know the default encryption type for Kerberos tickets (RC4-HMAC) and why it's weak.
Understand that Credential Guard blocks PtH but not Kerberoasting.
Be able to identify the correct event IDs for detection.
Hash Extraction from LSASS
The attacker gains administrative privileges on a compromised host and uses Mimikatz to dump hashes from the LSASS process. Mimikatz runs `sekurlsa::logonpasswords` to extract NTLM hashes of all logged-on users. On systems without Credential Guard, this works even if the attacker is not the user whose hash is stolen. The extracted hashes are 32-character hex strings. The attacker saves these for later use. This step requires SeDebugPrivilege or local admin rights. Defenders can detect this via Event ID 4688 (process creation) for Mimikatz.exe or by monitoring for suspicious access to LSASS (Event ID 4656).
Injecting Hash into Logon Session
Using Mimikatz's `sekurlsa::pth` command, the attacker creates a new logon session using the stolen hash. The command syntax is `sekurlsa::pth /user:DOMAIN\User /domain:DOMAIN /ntlm:HASH`. This launches a new process (e.g., cmd.exe) under the user's identity without knowing the password. The hash is used to generate NTLM responses for any challenge. The new process inherits the user's token, which includes group memberships and privileges. This step is not logged as a traditional logon event because it reuses existing cached credentials. However, Event ID 4624 with logon type 9 (NewCredentials) may appear.
Authenticating to Remote Systems
From the new command prompt, the attacker uses tools like PsExec, WMIC, or schtasks to authenticate to remote systems. For example, `psexec \\target -s cmd.exe` uses NTLM authentication. The attacker's machine sends the NTLM challenge-response using the injected hash. The target system verifies the response and grants access. This appears as a network logon (type 3) on the target, logged as Event ID 4624. Multiple such logons from the attacker's IP to many targets are a strong indicator of PtH. The attacker can now move laterally.
Requesting TGS for Service Account
In Kerberoasting, the attacker first obtains a TGT by authenticating as any domain user. Then they enumerate service principal names (SPNs) using LDAP queries, often with tools like `setspn -T domain -Q */*` or Impacket's `GetUserSPNs.py`. The attacker requests a TGS for each SPN by calling the Kerberos TGS-REQ. The KDC checks if the user has access (no special rights needed for most services) and returns a TGS encrypted with the service account's NTLM hash. This request is logged as Event ID 4769 on the domain controller.
Extracting and Cracking TGS
The attacker saves the TGS reply, which contains the encrypted ticket. Using tools like Rubeus or Mimikatz, they extract the ticket in hash format. The hash is saved to a file. The attacker then uses Hashcat with mode 13100 to crack the password offline. For RC4-encrypted tickets (type 23), cracking speed can be billions of hashes per second with GPUs. Once cracked, the attacker has the plaintext password of the service account. They can now log in as that account, potentially gaining elevated privileges if the service account is a domain admin or has delegated rights.
Enterprise Scenario 1: Healthcare Organization with Legacy Systems
A large hospital network uses Windows Server 2008 R2 domain controllers and Windows 7 workstations for legacy medical devices. Credential Guard is not supported. An attacker phishes an administrative assistant and gains a foothold. Using Mimikatz, they extract the hash of a domain admin who recently logged on to the assistant's machine. The attacker then uses PtH to access the domain controller, dumping all hashes. They move laterally to the SQL server hosting patient records. The attack goes undetected because the security team only monitors for malware, not for hash reuse. Mitigation: Upgrade to Windows 10/Server 2016+ to enable Credential Guard, implement Just Enough Administration (JEA), and monitor Event ID 4624 for unusual network logons.
Enterprise Scenario 2: Financial Firm with Service Account Overprivilege
A financial firm runs critical applications under domain user accounts with SPNs. One service account is a member of the Domain Admins group for legacy reasons. An attacker with a low-privilege domain account uses GetUserSPNs.py to enumerate SPNs. They request TGS tickets for all service accounts, including the privileged one. They crack the password offline (it is 'P@ssw0rd123') and then use that account to log into the domain controller and exfiltrate sensitive data. Detection failed because the security team did not monitor Event ID 4769 for unusual service ticket requests. Mitigation: Use Group Managed Service Accounts (gMSAs) for automatic password rotation, disable RC4 encryption in Kerberos policy, and ensure service accounts are not domain admins.
Scenario 3: Cloud Hybrid Environment with Azure AD Connect
A company syncs on-premises Active Directory to Azure AD using Azure AD Connect. The on-premises AD uses a service account 'AAD_Sync' with an SPN for the sync service. An attacker performs Kerberoasting on this account, cracks the password, and gains access to the on-premises AD. They then modify attributes to bypass cloud MFA. The attacker uses PtH to move laterally to the Azure AD Connect server, extracting the hash of the sync account and using it to authenticate to Azure AD. Mitigation: Use a strong, randomly generated password for the sync account, enable Azure AD Password Protection, and monitor for anomalous Azure AD logins.
Common Misconfigurations
Weak Service Account Passwords: Often set to 'Password1' or similar. Policy should enforce 25+ character random passwords.
Overprivileged Service Accounts: Many service accounts are granted more rights than needed. Use least privilege.
Lack of Monitoring: Organizations fail to enable advanced audit policies for Kerberos and NTLM events.
No Credential Guard: Many enterprises delay Windows upgrades, leaving systems vulnerable to PtH.
CS0-003 Exam Focus: Domain 1.0 Security Operations (Objective 1.2)
The exam tests your ability to analyze indicators of compromise (IoCs) for identity-based attacks. You must know the differences between Pass-the-Hash and Kerberoasting, including the tools, detection events, and mitigation strategies.
Common Wrong Answers
'Pass-the-Hash requires the plaintext password.' Wrong: PtH uses the hash, not the password. The attacker never needs the plaintext.
'Kerberoasting requires administrative privileges.' Wrong: Any authenticated domain user can request TGS tickets. No special privileges needed.
'Credential Guard prevents Kerberoasting.' Wrong: Credential Guard protects hashes in LSASS, but Kerberoasting does not require hash extraction; it uses Kerberos protocol messages.
'Event ID 4625 (failed logon) is the primary indicator of PtH.' Wrong: Successful logons (Event ID 4624) are more common because the attacker uses valid hashes.
Specific Numbers and Values
NTLM hash length: 32 hex characters (128 bits).
Kerberos ticket encryption types: RC4-HMAC (type 23) is default; AES128 (type 17) and AES256 (type 18) are stronger.
Hashcat mode for Kerberoasting: 13100 (TGS-REP).
Mimikatz command for PtH: sekurlsa::pth /user:User /domain:Domain /ntlm:hash.
Event ID for Kerberos TGS request: 4769.
Event ID for NTLM logon: 4624 (type 3).
Edge Cases
PtH with Kerberos: PtH primarily works with NTLM. For Kerberos, the attacker would need the TGT, which is also stored in LSASS. Mimikatz can export TGTs for pass-the-ticket attacks.
Kerberoasting with AES: If the domain is configured to use AES only, the attacker can still request tickets, but cracking AES keys is computationally harder. However, if the service account password is weak, it can still be cracked.
Service accounts without SPNs: Kerberoasting only works for accounts with SPNs. Accounts without SPNs cannot be targeted.
How to Eliminate Wrong Answers
If the scenario mentions 'offline cracking' of a service ticket, it's Kerberoasting.
If the scenario mentions 'reusing a hash to authenticate without knowing the password', it's PtH.
If the question asks for mitigation, 'Enable Credential Guard' applies to PtH, not Kerberoasting.
If the question mentions 'weak encryption algorithm', think RC4-HMAC (type 23) for Kerberoasting.
Exam Tips
Memorize the event IDs: 4624 (logon), 4769 (TGS request), 4672 (special logon).
Know that Kerberoasting is a post-exploitation attack; the attacker already has a foothold.
Understand that managed service accounts (MSAs) are immune to Kerberoasting because their passwords are automatically rotated and not known to users.
Pass-the-Hash (PtH) reuses NTLM hashes to authenticate without knowing the password.
Kerberoasting cracks service account passwords offline from Kerberos TGS tickets.
PtH requires admin privileges; Kerberoasting only needs a domain user account.
Event ID 4624 (logon type 3) indicates NTLM network logon; Event ID 4769 indicates TGS request.
Credential Guard mitigates PtH but not Kerberoasting.
Kerberoasting targets accounts with SPNs; Group Managed Service Accounts (gMSAs) are immune.
Default Kerberos encryption is RC4-HMAC (type 23), which is crackable offline.
Mimikatz's `sekurlsa::pth` is the classic PtH tool; Rubeus and Impacket are used for Kerberoasting.
Strong service account passwords (25+ characters) and AES encryption reduce Kerberoasting risk.
Monitoring for multiple TGS requests from a single user is key to detecting Kerberoasting.
These come up on the exam all the time. Here's how to tell them apart.
Pass-the-Hash
Uses NTLM hashes extracted from LSASS or SAM
Requires administrative privileges on the source system
Online attack: hash is used directly to authenticate
Mitigated by Credential Guard
Targets any user account with cached credentials
Kerberoasting
Uses Kerberos TGS tickets encrypted with service account hash
Requires only a valid domain user account (no admin)
Offline attack: ticket is cracked after extraction
Not mitigated by Credential Guard
Targets service accounts with SPNs
Mistake
Pass-the-Hash requires the attacker to know the plaintext password.
Correct
PtH uses the NTLM hash directly; the password is never needed. The hash is the secret in NTLM authentication.
Mistake
Kerberoasting requires administrative privileges on the domain.
Correct
Any authenticated domain user can request TGS tickets for any SPN. No admin rights needed.
Mistake
Credential Guard prevents both PtH and Kerberoasting.
Correct
Credential Guard prevents hash extraction from LSASS (stopping PtH) but does not prevent Kerberoasting, which uses Kerberos protocol messages.
Mistake
Kerberoasting only works with RC4 encryption.
Correct
Kerberoasting works with any encryption type, but RC4 (type 23) is easiest to crack. AES-encrypted tickets can also be cracked offline if the password is weak.
Mistake
PtH attacks are only possible from a compromised workstation.
Correct
PtH can be performed from any system where the attacker has admin rights and can extract hashes, including servers and domain controllers.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Pass-the-Hash (PtH) uses NTLM hashes to authenticate via NTLM protocol. Pass-the-Ticket (PtT) uses Kerberos TGTs or service tickets. PtH works for NTLM-based authentication; PtT works for Kerberos. Both involve reusing stolen credentials without knowing the password. On the exam, know that Mimikatz can perform both: `sekurlsa::pth` for PtH and `kerberos::ptt` for PtT.
Yes, Event ID 4769 (Kerberos Service Ticket Requested) is logged on the domain controller. Multiple TGS requests for different services from a single user in a short time is suspicious. Also, Event ID 4776 (Credential Validation) may appear if the attacker attempts to use the cracked password. However, the actual cracking is offline and not logged.
RC4-HMAC (type 23) is weak because it uses a 128-bit key derived from the NTLM hash, which is itself derived from the password. The hash can be cracked offline using GPU-accelerated tools like Hashcat. AES encryption (type 18) uses a stronger key derivation function and is more resistant to cracking. On the exam, remember that disabling RC4 forces the use of AES, making Kerberoasting harder.
A gMSA is a Windows service account whose password is automatically managed by the domain controller. The password is complex, rotated regularly, and not known to any user. Since no user knows the password, even if an attacker obtains a TGS ticket, they cannot crack the password because it is a random 240-character string. gMSAs also do not require SPN registration manually, but they do have SPNs. However, the password strength makes cracking infeasible.
Credential Guard uses virtualization-based security (VBS) to isolate the LSASS process. The secrets (hashes, TGTs) are stored in a protected container that even a process running as SYSTEM cannot access. Mimikatz cannot dump hashes from LSASS when Credential Guard is enabled. However, it does not prevent Kerberoasting because the TGS ticket is obtained via the Kerberos protocol, not from LSASS memory.
Service account passwords should be at least 25 characters long, randomly generated, and include a mix of uppercase, lowercase, digits, and special characters. Use a password manager to generate and store them. Avoid using the same password across multiple accounts. Enable AES encryption in Kerberos policy and disable RC4. Consider using gMSAs where possible.
PtH exploits NTLM authentication. If an environment disables NTLM and uses only Kerberos, PtH becomes ineffective because the attacker cannot use NTLM hashes. However, Kerberos has its own attack: Pass-the-Ticket. Also, many environments still have NTLM enabled for compatibility. The exam may test that disabling NTLM mitigates PtH.
You've just covered Identity-Based Attack Patterns: Pass-the-Hash, Kerberoasting — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?