Attacking Password Hashes practice questions

Using a standard copy command to move the SAM file to a network share.

Why it fails: Standard file copy commands will fail because the SAM file is locked by the Windows kernel for exclusive access. Attempting this will result in an access denied error, and if it were to succeed, the activity would be easily caught by EDR systems monitoring for file access patterns.

Executing an in-memory credential harvesting tool like Mimikatz without administrative privileges.

Why it fails: Mimikatz requires SeDebugPrivilege or local administrator rights to interact with the LSASS process or extract secrets. Without these elevated privileges, the tool cannot access the memory structures necessary to dump hashes, making this method ineffective for a tester who has not yet achieved local escalation.

Restarting the system to force it into a recovery mode.

Why it fails: Restarting a production system to enter recovery mode causes unnecessary downtime and is extremely noisy. This technique is easily detected by monitoring systems that track system availability, making it an inappropriate and unprofessional choice for a penetration test where operational continuity is a requirement for the client.

The choice of the wordlist is too small to find a match.

Why it fails: The wordlist size does not impact the raw speed of the GPU, which is measured in hashes per second. While a small list might result in zero matches, the performance metrics shown in the exhibit reflect the compute throughput, which is hindered by physical hardware limitations, not the list size.

The hash type (mode 1000) is inherently slower than others.

Why it fails: NTLM (mode 1000) is one of the fastest hash formats to crack because it lacks a salt and uses a simple MD4-based algorithm. It is significantly faster than salted or key-stretched algorithms like bcrypt or PBKDF2. Therefore, the mode is not the reason for the observed low performance.

The system memory is insufficient to load the full wordlist.

Why it fails: Hashcat streams wordlists from the disk or maintains them in cache; it does not load the entire file into VRAM at once. Insufficient system RAM would cause the application to crash or swap to disk, but it would not result in the thermal monitoring metrics observed in the exhibit.

The password length requirement for users.

Why it fails: While password length increases the entropy, it is not a property of the hash itself that impacts the speed of the cracking algorithm. An attacker can still attempt shorter passwords first; length is a policy control, not a cryptographic mechanism that inherently slows down the calculation of a single hash.

The total number of users in the target environment.

Why it fails: The number of users affects the total time to crack the entire database, but it does not change the speed of calculating a single hash. If an attacker focuses on a single target, the number of users in the domain is irrelevant to the time required to crack one specific account.

The use of a multi-core CPU for the attack.

Why it fails: Using a multi-core CPU actually decreases the time required for an attack by allowing parallel processing of password guesses. This is a benefit to the attacker, not a factor that slows down the cracking process, which is the opposite of what is required to protect the hash effectively.

Golden Ticket Attack

Why it fails: A Golden Ticket attack involves forging a TGT using a compromised KRBTGT account hash. This is an impersonation attack that provides unlimited access, whereas Kerberoasting is a technique used to recover the plain-text passwords of service accounts by targeting service tickets requested from the domain controller.

Pass-the-Hash

Why it fails: Pass-the-Hash is an authentication technique where an attacker uses an existing NTLM hash to authenticate to a remote service without knowing the plaintext password. This is a lateral movement technique, not a method for cracking an encrypted ticket or recovering a password from a hash.

AS-REP Roasting

Why it fails: AS-REP Roasting targets accounts that do not require Kerberos pre-authentication. The attacker requests a TGT for such an account and receives an encrypted response that can be cracked offline. While similar to Kerberoasting, it targets user accounts rather than service accounts associated with an SPN.

The system uses NTLM instead of Kerberos for everything.

Why it fails: While NTLM is less secure than Kerberos, the primary vulnerability to LSASS extraction is the process memory protection itself, not the network authentication protocol used. Even in a Kerberos-only environment, credentials might be stored in memory, making them susceptible to dumping if memory protection is weak.

The SAM database is stored on a network share.

Why it fails: The SAM database is a local file stored on the system disk; it is not typically stored on a network share. This is not a standard configuration, nor is it an indicator of LSASS vulnerability, as the security risks of LSASS are independent of the storage location of the SAM.

Windows Sysinternals ProcDump utility

Why it fails: ProcDump captures process memory dumps from a running system; it cannot parse an offline NTDS.dit database or SYSTEM hive to recover hashes. It is tempting because ProcDump can extract credentials from live LSASS memory, but the scenario requires offline analysis of copied files.

BloodHound GUI collector

Why it fails: BloodHound maps Active Directory relationships from collected LDAP and session data; it does not parse NTDS.dit or registry hives to recover hashes. It is tempting because BloodHound is a standard post-compromise AD tool, but its purpose is attack-path graphing, not offline credential extraction.

Responder network poisoning tool

Why it fails: Responder poisons LLMNR, NBT-NS and mDNS to capture live authentication traffic; it never reads NTDS.dit or SYSTEM hive files. It is tempting because Responder harvests NetNTLM hashes during engagements, but that requires network interaction, not offline database parsing.

Hashcat mode 13100 is for Kerberos 5 AS-REP, not TGS-REP.

Why it fails: Hashcat mode 13100 is specifically for Kerberos 5 TGS-REP etype 23. Mode 18200 is for AS-REP etype 23. The tester used the correct mode, so this is not the reason for failure. The issue likely lies with the hash file format, such as missing salt or incorrect capture.

The hash is actually a Kerberos 5 AS-REP hash, not a TGS-REP hash.

Why it fails: If the hash were an AS-REP hash, it would require a different mode (18200 for AS-REP etype 23). However, the scenario states it is a TGS-REP hash, so this is not the issue. The tester correctly identified the hash type, so the failure is likely due to another reason such as missing salt or incorrect format.

The service account password is longer than 14 characters, making it uncrackable.

Why it fails: While longer passwords are more difficult to crack, they are not inherently uncrackable. The failure could be due to many factors, but password length alone is not a definitive reason. Moreover, the scenario does not specify the password length, and the use of a large wordlist suggests that the tester expects to crack it. The more likely issue is a missing salt or incorrect hash format.

Use a hybrid attack combining wordlist and mask

Why it fails: Hybrid attacks combine wordlists with masks (e.g., appending digits) and can be useful, but they are not as broadly effective as rule-based or pure mask attacks when targeting NTLM hashes. They may miss common patterns if the mask does not align with user behavior. While effective, they are not among the top two strategies for maximizing cracking success in this scenario.

Use a rainbow table attack with precomputed NTLM hashes

Why it fails: Rainbow tables are less effective for NTLM hashes because they are unsalted and can be defeated by salting or using large password spaces. Additionally, rainbow tables for NTLM are enormous and require significant storage. Modern GPU cracking with wordlists and rules is generally faster and more flexible, making rainbow tables impractical for most penetration tests.

Use a distributed cracking setup with multiple GPUs

Why it fails: Distributed cracking increases speed but does not inherently improve success rate; it only accelerates the process. Without effective candidate generation strategies like rules or masks, simply adding GPUs will not crack more hashes if the password space is not adequately covered. Thus, it is not a strategy to increase success but rather to reduce time.

--force

Why it fails: The --force option bypasses Hashcat's safety checks, such as ignoring warnings about temperature or missing OpenCL devices. It does not affect the attack mode or rules. It is not essential for a rule-based dictionary attack and could potentially cause issues if used unnecessarily. Therefore, it is not one of the correct choices.

-m 1000

Why it fails: The -m 1000 option sets the hash type to NTLM. While this is necessary for cracking NTLM hashes, it is not specific to a rule-based dictionary attack. It is a required parameter for any NTLM cracking session, but the question asks for options essential to the rule-based aspect. Thus, it is not one of the two correct choices, though it would be used in the full command.

--increment

Why it fails: The --increment option enables incremental mask attack mode, which is used for brute-force attacks with masks. It is not used in a dictionary attack. This option would be irrelevant here because the tester wants to use a wordlist with rules, not a brute-force mask. Including it would not contribute to the rule-based dictionary attack.

The tester must have domain administrator privileges to perform the attack.

Why it fails: Pass-the-Hash can be performed with any user account's hash, not just domain administrators. The success depends on the privileges of the account whose hash is used. If a local administrator hash is extracted, it can be used to access other machines where that same local administrator account exists. Domain administrator privileges are not required to initiate the attack; they would only elevate the impact. Therefore, this condition is not necessary.

The target workstations must be running Windows Server 2008 or later.

Why it fails: Pass-the-Hash works on a wide range of Windows versions, including older ones like Windows XP and Server 2003, as long as NTLM authentication is enabled. The operating system version is not a limiting factor for the attack itself. While newer versions may have additional mitigations like Credential Guard, the basic technique remains viable. The scenario does not specify a version restriction, so this condition is not necessary.

The tester must first crack the NT hash to recover the plaintext password.

Why it fails: Pass-the-Hash does not require cracking the hash; the hash itself is used as the credential. Cracking is only needed if the tester wants to obtain the plaintext for other purposes, such as password reuse on different systems that require plaintext. In this scenario, the goal is to authenticate directly using the hash. Therefore, cracking is not a prerequisite and would unnecessarily delay the attack.

Password policies are easily bypassed by users sharing credentials.

Why it fails: While credential sharing is a risk, it is unrelated to the cryptographic strength of the password storage mechanism. Even if users shared complex passwords, they would remain vulnerable if the underlying hashing algorithm was outdated, such as MD5, which can be computed in microseconds by modern cracking tools.

Passwords are always transmitted in plain text over the network.

Why it fails: Passwords should not be transmitted in plain text if secure protocols like HTTPS are used. This statement is a false premise; assuming all traffic is insecure ignores modern transport security standards, which are independent of how passwords are stored in the back-end database after they are hashed.

The password policy is only effective for local accounts.

Why it fails: Password policies can be enforced for both local and domain accounts through Group Policy or identity management systems. The assertion that policies are ineffective for non-local accounts is incorrect and does not justify prioritizing the evaluation of hashing algorithms over the assessment of organizational security policies.

NTLM requires a connection to a Domain Controller for every login.

Why it fails: NTLM is designed to work in disconnected or local environments and does not require a Domain Controller for every authentication request. It uses the local SAM database or cached credentials, which is actually a security risk in itself because it keeps credentials stored on the local host.

The protocol uses hard-coded encryption keys for every session.

Why it fails: NTLM uses a session-based challenge-response mechanism, not hard-coded keys. The weakness lies in the protocol's design and the lack of salt in the hash, rather than the use of static encryption keys for the entire session. The primary issue is the hash vulnerability to offline cracking.

Use the hashes to perform a Pass-the-Hash attack on every server.

Why it fails: Pass-the-Hash is an authentication technique, not a cracking technique. It is useful for lateral movement but does not reveal the plaintext password. If the goal specifically asks for the password recovery, Pass-the-Hash fails to satisfy the requirement as it only grants access without revealing the credentials.

Submit the hashes to an online cloud-based cracking service.

Why it fails: Submitting sensitive organizational credentials to a third-party cloud service is a severe violation of professional ethics and data privacy rules. A penetration tester must maintain control over client data and should never expose credentials to external, untrusted environments during the engagement process.

Reverse the MD4 algorithm to recover the original string.

Why it fails: Hashing is a one-way cryptographic function, and it is mathematically impossible to 'reverse' the algorithm to recover the original input. Any attempt to reverse the MD4 function mathematically will result in failure, as the process is designed to be irreversible, unlike standard encryption or encoding.

The hash is a salt-based hash requiring a rainbow table.

Why it fails: NTLM hashes do not use a salt; they are deterministic based on the user's password. Rainbow tables are generally not required because the lack of a salt allows the attacker to use brute force or dictionary attacks directly on the hash without needing precomputed data structures.

The value represents the plaintext password in hex format.

Why it fails: The value is a hashed representation, not the plaintext password. While NTLM is weak, it is still a one-way cryptographic hash. It cannot be converted directly back to plaintext without an offline dictionary or brute-force attack, which is a computationally intensive process compared to simple decoding.

The session has expired and the hash is now unusable.

Why it fails: NTLM hashes are derived from the user's password and stored in memory by the LSASS process. They do not expire like Kerberos tickets. As long as the user's password has not been changed, the hash remains valid and can be used for authentication at any time.

Cached credentials only store the user's username.

Why it fails: If cached credentials only contained usernames, they would be useless for authentication. They actually contain sensitive information, including a hashed version of the user's password, which is specifically designed to enable offline authentication, making them a high-value target for attackers who have obtained local administrative rights.

They allow offline authentication, but are stored in plain text.

Why it fails: Windows does not store cached credentials in plain text. They are stored as encrypted hashes within the registry. The vulnerability lies in the fact that these hashes can be extracted and then subjected to offline cracking attempts, not that they are readily available as plain text strings.

They are automatically wiped upon every system reboot.

Why it fails: Cached credentials are persistent and remain in the registry even after a system reboot. If they were wiped on reboot, they would be ineffective for their intended purpose of allowing domain logins during network outages, making them a reliable target for attackers seeking long-term access to a system.

GPUs have larger cache sizes for storing wordlists.

Why it fails: GPU cache sizes are generally smaller than those found on modern CPUs. The performance gain comes from the massive number of arithmetic logic units (ALUs) available for parallel computation, not from memory storage capacity. The wordlist is usually stored in system RAM or on disk, not on the GPU.

GPUs have a faster instruction set for MD4 algorithms.

Why it fails: The instruction set of a GPU is not specifically optimized for MD4; the speed advantage is due to the sheer number of execution units available. The architecture allows for 'SIMD' (Single Instruction, Multiple Data) processing, where one instruction can be applied to thousands of passwords concurrently, creating massive throughput.

GPUs can bypass the salt requirement during the attack.

Why it fails: A GPU cannot bypass the requirement of a salt. If a hash is salted, the attacker must still compute the hash including the salt. The performance advantage of the GPU is entirely independent of whether a salt is present; it remains a high-throughput device regardless of the hash format.

Monitoring for high CPU usage on all workstations.

Why it fails: High CPU usage on a workstation is a generic indicator that can be caused by many benign software processes. It is not an effective way to detect offline cracking because the cracking itself usually happens on the attacker's own external machine, not on the victim's production workstation.

Scanning for the use of the Hashcat tool on the network.

Why it fails: Attackers can rename tools or use custom scripts that perform the same functions as Hashcat. Relying on simple file-name detection is easily bypassed by renaming the binary, making it an ineffective strategy for detecting professional attackers who are aware of basic signature-based security controls.

Monitoring for network traffic to known cracking websites.

Why it fails: Professional attackers do not use websites to perform their cracking operations; they use locally installed, high-performance hardware or cloud-based instances they control. Monitoring web traffic will not identify the exfiltration of credentials or the subsequent offline cracking, as these activities do not require communication with public websites.

Attempt a brute-force attack on the Kerberos TGT.

Why it fails: Brute-forcing a TGT requires obtaining the ticket first and the attack is unrelated to the failure to crack an NTLM hash. If the NTLM hash cannot be cracked, it suggests the password is strong; attacking a different protocol is not a direct substitute for the current failure.

Use a social engineering attack to reset the password.

Why it fails: Resetting a password via social engineering is a high-risk and slow activity that might alert the user or the security team. It is not an 'alternative strategy' to using the hash already in possession; it is a completely different, lower-efficiency attack vector that should only be used if others fail.

Re-run the cracking attack with a longer wordlist.

Why it fails: If a robust wordlist failed, merely using a longer one is unlikely to succeed. The goal of the penetration test is to gain access, and PtH is a proven, reliable method that leverages the existing data, whereas repeating a failed cracking attempt is unlikely to yield a quick result.

Hashcat mode 1000 represents standard NTLM password hashes extracted from the Windows SAM database or NTDS.dit.

Why it fails: Mode 1000 processes local NTLM password hashes, which consist only of the username, RID, LM hash, and NT hash. It lacks the server challenge and client nonce present in network captures, making it incompatible with NetNTLMv2 responses.

Hashcat mode 3000 handles LANMAN hashes, which are legacy Windows password hashes stored for backwards compatibility on older systems.

Why it fails: Mode 3000 cracks LANMAN hashes, the legacy DES-based format from pre-NT systems, which differs structurally from NTLMv2's HMAC-MD5 challenge-response captured over the network. Mode 3000 is correct when recovering passwords from old SAM databases containing LM hashes, not from LLMNR/NBT-NS poisoning captures.

Hashcat mode 13100 is utilized for Kerberos 5 TGS-REP etype 23 hashes gathered through service ticket requests.

Why it fails: Mode 13100 targets Kerberos 5 TGS-REP etype 23 tickets, a different hash structure from the NTLMv2 challenge-response pairs captured via LLMNR/NBT-NS poisoning, so it cannot verify those captures. Mode 13100 is correct when cracking service tickets obtained through Kerberoasting, not network poisoning.

Mode 1000, which targets local Windows SAM NT hashes extracted from a compromised registry hive export.

Why it fails: Mode 1000 cracks NT hashes from a SAM or registry export, which lack the server challenge needed to verify a captured network response. It is tempting because NT hashes are the fastest GPU target and the correct choice when you have extracted hashes locally rather than sniffed authentication traffic.

Mode 5500, which is designed exclusively for cracking legacy NTLMv1 network authentication challenge-response pairs.

Why it fails: Mode 5500 targets NTLMv1 challenge-response, whose weaker DES-based cryptography differs from the HMAC-MD5 construction in NTLMv2. It is tempting because NTLMv1 is genuinely crackable with mode 5500, and would be the correct choice when captured traffic uses legacy NTLMv1 rather than NTLMv2.

Mode 3000, which processes LanMan hashes historically found on very old Windows NT and 95 operating systems.

Why it fails: Mode 3000 processes LanMan hashes, which are unsalted DES-derived values stored locally, not network challenge-response pairs. It is tempting because LanMan cracking is genuinely performed with mode 3000, and would be the correct choice when recovering passwords from legacy LM hashes in an old SAM database.