Kerberos Attacks practice questions

The NTLM hash of the target service account and a valid TGS.

Why it fails: The NTLM hash of a service account is used for Silver Tickets, not Golden Tickets. A Golden Ticket requires the hash of the domain's KRBTGT account, which acts as the 'master key' for issuing and verifying tickets across the entire Active Directory domain.

The domain administrator's plaintext password and a captured TGS.

Why it fails: The administrator password is not needed for a Golden Ticket. The attack relies on the KRBTGT hash. While an administrator password provides high privileges, the KRBTGT hash provides persistent, undetectable access that persists even if the administrator password is changed or the account is disabled.

A valid TGT obtained from an authenticated user on the network.

Why it fails: Golden Tickets do not require an existing, captured TGT from a real user. Instead, the attacker constructs the ticket from scratch using the KRBTGT hash. This allows the attacker to impersonate any user, including accounts that may not even exist on the domain.

Requesting a TGT from the Domain Controller.

Why it fails: Silver Tickets are forged offline; they do not interact with the KDC at all. Requesting a TGT from the Domain Controller is part of standard Kerberos flows, but for a Silver Ticket, the attacker avoids the KDC entirely to remain undetected and minimize network logging.

Forging the service ticket using the KRBTGT hash.

Why it fails: The KRBTGT hash is used exclusively for Golden Tickets. Silver Tickets are forged using the NTLM hash of the specific service account that runs the service. Using the KRBTGT hash would be unnecessary and significantly more dangerous for the attacker, as it exposes the domain's root credential.

Disable Kerberos pre-authentication for all user accounts.

Why it fails: Disabling pre-authentication makes accounts vulnerable to AS-REP roasting, a different class of attack. This is a dangerous configuration change that severely weakens domain security and should never be used as a defensive measure.

Restrict access to the NTDS.dit file via strict file system permissions.

Why it fails: While protecting the NTDS.dit file is crucial for preventing offline credential theft (like DCsync), it does not prevent Kerberoasting. Kerberoasting relies on legitimate KDC interactions to request tickets, not the direct theft of the domain database file.

Perform an AS-REP roasting attack against users configured without pre-authentication requirements enabled.

Why it fails: AS-REP roasting specifically targets user accounts where Kerberos pre-authentication is explicitly disabled. While effective against misconfigured accounts, it does not apply universally to standard domain users who must utilize pre-authentication by default in hardened environments.

Execute a DCSync attack using replication privileges assigned to the compromised standard user account.

Why it fails: DCSync requires specialized replication rights suchas Replicate Directory Changes All, which standard low-privileged domain users do not possess. Attempting this against a Domain Controller without elevated privileges will result in an access denied error.

Launch an SMB relay attack targeting signing-disabled endpoints to capture Net-NTLMv2 hashes.

Why it fails: SMB relay attacks target network authentication protocols rather than the Kerberos infrastructure directly. They require specific network conditions and disabled SMB signing on targets, differing fundamentally from Kerberos ticket harvesting techniques.

Perform a pass-the-hash attack using the encrypted timestamp as the NTLM hash.

Why it fails: The encrypted timestamp in an AS-REQ is a Kerberos pre-authentication blob, not an NTLM hash. Pass-the-hash requires the NT hash of a user's password to authenticate via NTLM or Kerberos with RC4. The formats and cryptographic operations are entirely different, so the captured timestamp cannot be used as an NTLM hash for authentication or cracking.

Use Kerbrute with the 'userenum' mode to brute-force the password against the KDC.

Why it fails: Kerbrute's userenum mode only validates whether usernames exist by observing KDC error codes; it does not perform offline password cracking. It sends authentication attempts directly to the domain controller, which is online and subject to lockout policies. The captured AS-REQ ciphertext cannot be fed into Kerbrute for cracking, so this approach fails the scenario's requirement for offline analysis.

Replay the captured AS-REQ to the KDC to obtain a TGT, then use that TGT to request service tickets for cracking.

Why it fails: Replaying the AS-REQ does not yield a crackable artifact because the KDC will issue a TGT only if the pre-authentication data is valid. Without the user's password, the operator cannot produce a valid encrypted timestamp. Even if a TGT were obtained, service tickets are encrypted with service account keys, not the user's key, so they would not help recover the user's password.

Request a TGS for the SQL service using the service account's credentials and rely on S4U2Self to obtain an administrator ticket.

Why it fails: S4U2Self requires a valid TGT for the service account and interaction with the KDC; the tester only has the NTLM hash, not a TGT. It also produces a ticket for the service account itself, not the domain administrator, unless combined with S4U2Proxy and appropriate permissions. This method contacts the KDC and does not satisfy the no-KDC-interaction requirement.

Use the service account's hash to request an AS-REP and crack the domain administrator's password for lateral movement.

Why it fails: AS-REP Roasting targets accounts with pre-authentication disabled and yields encrypted material for the target account, not the domain administrator. The service account's hash cannot be used to request another user's AS-REP. Cracking the administrator's password is not guaranteed and does not leverage the constrained delegation configuration.

Perform a DCSync attack to replicate the krbtgt hash, then forge a golden ticket for the domain administrator.

Why it fails: DCSync requires directory replication privileges that the service account typically lacks. The scenario provides only the service account's NTLM hash, not the rights needed to replicate the krbtgt secret. Forging a golden ticket also targets the entire domain rather than the specific SQL service, and it would require KDC interaction for validation in some contexts.

An AS-REP for the user, decrypted with the user's NT hash, and injected into a new logon session.

Why it fails: An AS-REP is part of the initial authentication exchange and is used to obtain a TGT. It is encrypted with the user's long-term key and contains a session key for the TGT, not service access. Injecting an AS-REP does not grant access to a specific service like the file server, and the operator already has a TGT, making this step redundant and ineffective for lateral movement.

A forged TGT with the user's SID and privileged group SIDs, signed with the KRBTGT hash.

Why it fails: Forging a TGT requires the KRBTGT account's NTLM hash, which the operator does not possess in this scenario. The operator only has a legitimate TGT for the user, not the KRBTGT secret. Without the KRBTGT hash, a forged TGT cannot be created, and attempting to do so would fail because the KDC would reject the invalid signature.

A TGS-REP for the KRBTGT service, extracted from memory and injected into a new logon session.

Why it fails: The KRBTGT service ticket is not a normal service ticket; it is used internally by the KDC. Requesting a TGS for the KRBTGT SPN is not a standard operation and does not yield a usable ticket for lateral movement. The operator needs a service ticket for the target file server, not for the KDC itself.

Rubeus.exe golden /rc4:<krbtgt_hash> /user:Administrator /domain:domain.local /sid:S-1-5-21-... /outfile:golden.kirbi /lifetime:10y

Why it fails: Rubeus does not support a /lifetime parameter with a value like 10y. The correct parameter in Rubeus for ticket lifetime is /endin, which accepts days. Specifying /lifetime:10y is invalid syntax and would not produce a ticket with a 10-year lifetime. Therefore, this command would fail or not set the desired lifetime, making it incorrect.

mimikatz "kerberos::golden /user:Administrator /domain:domain.local /sid:S-1-5-21-... /krbtgt:<hash> /ticket:golden.kirbi /endin:3650"

Why it fails: The /endin parameter in mimikatz specifies the ticket lifetime in days, not years. Setting /endin:3650 would create a ticket valid for 3650 days, which is approximately 10 years. However, the question asks for a 10-year lifetime, and using days is correct, but the parameter name is /endin, not /endin with years. This option incorrectly uses 3650 as if it were years, but it's actually days, so it would be 10 years. Wait, 3650 days is 10 years, so this is correct? But the question asks for 10 years, and 3650 days is 10 years, so this option is actually correct. However, the correct answer is B, which uses /endin:3650 as well? Let's re-evaluate: The correct parameter for lifetime in mimikatz is /endin (days). So /endin:3650 is correct for 10 years. But option A uses /endin:3650, which is correct. Option B uses /endin:3650 as well? No, option B uses /endin:3650? I need to check the options. I'll rewrite the options to avoid confusion.

kekeo "tgt::ask /user:Administrator /domain:domain.local /krbtgt:<hash> /life:10"

Why it fails: Kekeo's tgt::ask module is used to request a TGT from the KDC, not to forge a Golden Ticket offline. It requires valid credentials or hashes to request a ticket, but it does not allow arbitrary lifetime specification like /life:10. For forging, kekeo has a different module (tgt::golden), but this command is incorrect for the purpose and does not set a 10-year lifetime.

Perform the attack during business hours to avoid detection by security monitoring tools.

Why it fails: Kerberoasting generates event ID 4769 with specific encryption types, which security monitoring tools can detect. Performing the attack during business hours might blend in with normal traffic, but it does not inherently avoid detection. In fact, unusual TGS requests for multiple SPNs could trigger alerts regardless of timing. This action does not improve cracking success.

Target service accounts that use AES encryption to ensure faster cracking.

Why it fails: AES encryption (etype 17 and 18) is more secure and significantly slower to crack than RC4-HMAC (etype 23). Requesting AES-encrypted tickets would make the cracking process much harder, not faster. Attackers typically prefer RC4-HMAC tickets because they are easier to crack, so this action would not maximize the chance of success.

Request tickets for accounts with constrained delegation to obtain higher privileges.

Why it fails: Constrained delegation allows a service to impersonate users to specific services, but it does not directly relate to Kerberoasting. Kerberoasting targets any account with an SPN to extract crackable tickets. Focusing on constrained delegation accounts does not increase the chance of cracking passwords and may complicate the attack without benefit.

Use Kekeo with 'tgt::ask /user:Administrator /domain:corp.local /krbtgt:<hash>'.

Why it fails: Kekeo's tgt::ask command is used to request a TGT from the KDC, similar to Rubeus asktgt. It does not forge a ticket; it relies on the KDC to issue one. Without valid credentials, the request would fail. Even with the KRBTGT hash, Kekeo does not support forging a TGT with arbitrary lifetime in this manner.

Use Rubeus with 'asktgt /user:Administrator /rc4:<hash> /ptt'.

Why it fails: Rubeus's asktgt command requests a TGT from the KDC using a given hash, but it does not forge a ticket. It performs an AS-REQ with the provided credentials or hash, which requires the account to be valid and may be subject to logging and restrictions. This does not create a Golden Ticket with a custom lifetime, as the KDC controls the ticket lifetime.

Use Impacket's ticketer.py with '-nthash <hash> -domain-sid <SID> -domain corp.local Administrator'.

Why it fails: Impacket's ticketer.py can create Golden Tickets, but it requires the -nthash parameter for the KRBTGT hash and the -domain-sid parameter. The command as written is missing the -domain-sid value and the correct syntax. While ticketer.py is a valid tool, the specific command lacks necessary parameters and would not execute successfully.

Hashcat mode 13100

Why it fails: Hashcat mode 13100 is used for Kerberos 5 TGS-REP etype 23, which is RC4-HMAC encryption. AES256-encrypted tickets use a different encryption type, so mode 13100 would not be able to parse or crack the extracted ticket. The operator must select the mode that corresponds to the encryption type of the ticket.

Hashcat mode 19600

Why it fails: Hashcat mode 19600 is for Kerberos 5 TGS-REP etype 17, which is AES128-CTS-HMAC-SHA1-96. The ticket in question is AES256, which is etype 18, so mode 19600 would not work. Using the wrong mode would result in errors or failed cracking attempts, wasting time and resources.

Hashcat mode 7500

Why it fails: Hashcat mode 7500 is for Kerberos 5 AS-REP etype 23, which is used in AS-REP roasting, not Kerberoasting. It targets the initial authentication exchange, not service tickets. The extracted ticket from Kerberoasting is a TGS-REP, and if it is AES256, mode 7500 is entirely inappropriate and will not yield any results.

The NTLM hash is insufficient because it cannot be used to request a Ticket Granting Ticket (TGT).

Why it fails: Requesting a TGT requires an initial authentication exchange, such as AS-REQ, which typically uses the user's password or AES keys. While an NTLM hash can be used for NTLM authentication, it does not bypass the Kerberos protocol requirements for obtaining a TGS via an SPN request.

The NTLM hash is only useful for Pass-the-Hash attacks and cannot facilitate any Kerberos interactions.

Why it fails: The NTLM hash is indeed central to Pass-the-Hash, but it is not entirely useless for Kerberos. In mixed environments, NTLM hashes can sometimes be used to facilitate downgrade attacks or service authentication, but they remain fundamentally incompatible with the specific TGS-REQ/TGS-REP flow used for Kerberoasting.

The NTLM hash must first be converted to a Kerberos AES-256 key before a TGS request can be initiated.

Why it fails: There is no direct mathematical conversion from an NTLM hash to a Kerberos AES-256 key because they utilize different cryptographic primitives. NTLM uses MD4, while Kerberos uses HMAC-SHA1 or HMAC-SHA256. Attempting to convert them will not enable the Kerberoasting process as described in standard penetration testing workflows.

A sudden spike in AS-REQ events using expired Kerberos TGTs.

Why it fails: AS-REQ events relate to initial authentication. While expired tickets can cause issues, they are not a primary indicator of Kerberoasting. The focus of Kerberoasting is on TGS-REQ events, which occur after the user has already obtained a valid TGT from the KDC.

Frequent failed logins followed by a successful Kerberos authentication.

Why it fails: Failed logins are typically associated with brute-force password attacks or credential stuffing, not Kerberoasting. Kerberoasting does not require knowledge of the account password to generate a ticket request, so it generally does not trigger account lockout mechanisms unless the attacker is also attempting other methods.

An influx of TGT-REQ packets originating from non-domain controllers.

Why it fails: TGT requests occur constantly in a Windows domain as clients authenticate to the KDC. TGT requests themselves are not inherently malicious. Kerberoasting specifically targets the TGS-REQ phase of the authentication flow, making TGT-REQ volume an unreliable metric for identifying this specific class of attack.

gMSAs prevent the KDC from issuing service tickets for the account.

Why it fails: gMSAs do not stop the KDC from issuing tickets. A client can still request a TGS for a gMSA-managed service. The protection lies in the cryptographic strength and automated rotation of the password used to encrypt that ticket, which prevents attackers from cracking it offline.

gMSAs require multi-factor authentication for every TGS-REQ performed.

Why it fails: While multi-factor authentication is a strong security control, it is not a feature of gMSA implementation. gMSAs focus on automated password management and rotation at the directory service level, not by adding interactive authentication requirements to the Kerberos TGS-REQ request/response process.

gMSAs force all Kerberos traffic to be encrypted using AES-256 only.

Why it fails: While gMSAs support AES encryption, they do not enforce it as a global policy for all Kerberos traffic. The primary defense against Kerberoasting offered by gMSAs is password complexity and rotation, which applies regardless of the underlying encryption suite used during the ticket request process.

Golden Tickets require communicating with the KDC, whereas Silver Tickets do not.

Why it fails: Neither Golden nor Silver tickets require communication with the KDC. Both are forged offline. The distinction is strictly about which secret is used to sign the ticket and what that ticket allows the attacker to do within the Windows domain environment.

Golden Tickets target the domain controller, while Silver Tickets target user workstations.

Why it fails: Both attacks can target any resource. A Golden Ticket allows the attacker to impersonate any user to any service. A Silver Ticket allows the attacker to impersonate any user to a specific service. The target machine depends on what the attacker chooses to access, not the ticket type.

Silver Tickets are more powerful because they are harder to detect than Golden Tickets.

Why it fails: Both are difficult to detect via standard logs since they bypass KDC interactions. However, Golden Tickets are significantly more powerful because they provide persistence across the entire domain, whereas Silver Tickets are limited in scope to the specific service account that was compromised.

The PAC is always encrypted with the user's password, making it easy to crack.

Why it fails: The PAC is not encrypted with the user's password. It is signed by the KDC using the KRBTGT account's key. While it contains user information, it is a protected part of the ticket structure, not a user-level credential that can be easily cracked via standard methods.

The PAC prevents the KDC from verifying the ticket's signature.

Why it fails: The PAC is actually what the KDC uses to include authorization data in the ticket. It does not prevent signature verification; rather, it is part of the data that the KDC signs. The vulnerability arises when an attacker forges the entire ticket and signs it themselves.

The PAC is required for TGT requests, making it a primary target for sniffers.

Why it fails: The PAC is included in the TGS response, not the initial TGT request. While it is a target for manipulation, it is not simply 'sniffed' from the wire as it is encrypted within the ticket. The risk is specifically in the forgery and subsequent modification of the authorization data.

The TGT's ability to be renewed indefinitely.

Why it fails: Renewable TGTs are a standard Kerberos feature but are not the focus of constrained delegation. Constrained delegation is specifically about the KDC allowing a service to request tickets for other services on behalf of a user, which is a different configuration-based mechanism.

The PAC validation performed by the Domain Controller.

Why it fails: PAC validation is a security check, not a feature meant for delegation. While constrained delegation relies on the KDC's trust, the delegation mechanism itself is driven by specific extensions (S4U) designed to allow cross-service impersonation, not the PAC validation process itself.

The ability to use RC4 encryption for TGS requests.

Why it fails: Encryption types are independent of the delegation mechanism. While attackers prefer RC4, it is not the feature that enables constrained delegation. The delegation configuration is stored as an attribute on the Active Directory computer or service account object, which dictates the allowed service paths.

It forces the use of NTLM for all authentication requests.

Why it fails: Unconstrained delegation has nothing to do with NTLM. It is a Kerberos-specific feature where a service is trusted to impersonate a user to any resource. The risk is specifically that the service receives and caches the user's TGT, making it accessible to any attacker.

It requires the domain controller to store plaintext passwords for all users.

Why it fails: The domain controller never stores plaintext passwords. It stores hashes. Unconstrained delegation is a configuration attribute on a computer or user object in AD, and it does not impact how the domain controller stores or handles user credentials or password data.

It prevents the KDC from enforcing password expiration policies.

Why it fails: Delegation settings are entirely separate from password expiration policies. An account with unconstrained delegation enabled is still subject to the same domain-wide password policies as any other account. The risk is strictly limited to the handling of TGTs during the authentication process.

To prevent the domain controller from logging failed authentication attempts.

Why it fails: Kerberos Armoring is a security feature that strengthens the protocol; it does not disable logging. In fact, strengthening the tunnel makes the environment safer, and legitimate security auditing should remain fully functional after implementing FAST.

To force all service accounts to use AES-256 encryption for tickets.

Why it fails: Kerberos Armoring (FAST) protects authentication exchanges by wrapping pre-authentication and AS/TGS traffic in a hardened tunnel, not by mandating AES-256 for service accounts. It is tempting because encryption is involved, but FAST addresses protocol downgrade and offline-cracking attacks.

To bypass the need for a TGT during service authentication.

Why it fails: A TGT is fundamental to the Kerberos protocol. No security feature, including FAST, eliminates the need for TGTs. FAST only changes how the initial TGT request is secured during transit, not the underlying logic of the Kerberos ticket system.

It targets service accounts that are configured with SPNs.

Why it fails: AS-REP Roasting exploits accounts with Kerberos pre-authentication disabled, requesting an AS-REP and cracking the encrypted portion offline; SPNs are irrelevant, since SPN-bearing service accounts are the target of Kerberoasting instead. It is tempting because both attacks abuse Kerberos ticket requests and yield crackable hashes, but the enabling condition differs.

It relies on the interception of a TGS request to obtain encrypted credentials.

Why it fails: AS-REP Roasting targets the AS-REQ/AS-REP exchange (initial authentication), not the TGS-REQ/TGS-REP exchange. The vulnerability is the lack of pre-authentication, which allows the attacker to obtain an encrypted blob that can be cracked offline without needing any initial credentials.

It is a technique for escalating privileges using the KRBTGT account.

Why it fails: AS-REP Roasting is used to obtain the password of a specific user account, not to escalate privileges via the KRBTGT account. Golden Ticket attacks are the technique that uses the KRBTGT account to forge administrative TGTs for domain-wide access.