Attacking Passwords practice questions

Kerberos TGT pass-the-ticket

Why it fails: Pass-the-ticket involves extracting valid Kerberos tickets from memory, usually via mimikatz. This differs from NTLM relaying, which focuses on intercepting a challenge-response exchange to impersonate a client against a target server that does not require SMB signing or Kerberos authentication.

LLMNR poisoning

Why it fails: LLMNR poisoning is a technique used to capture hashes by responding to name resolution requests. While often a precursor to a relay attack, it is the method of acquisition, not the protocol vulnerability allowing the relaying of authentication tokens to a target server.

NetBIOS broadcast vulnerability

Why it fails: NetBIOS broadcasts are an information disclosure issue where devices announce their existence. While attackers use these to perform spoofing, they do not inherently provide the mechanism to relay NTLM authentication tokens to a target server without the underlying lack of signing.

Using MD5 hashing for rapid verification

Why it fails: MD5 is a fast cryptographic hash function, which is detrimental to security in password storage. Its speed allows attackers to perform billions of guesses per second during offline cracking attempts. Modern standards mandate slow, tunable algorithms instead of legacy fast hashes.

Enforcing a 30-day password rotation policy

Why it fails: Frequent password rotation is controversial and often leads to weaker passwords as users choose predictable patterns. While rotation has a place, it is not a defense against offline cracking of existing hashes compared to robust salting and slow hashing algorithms.

Storing passwords in plaintext with AES-256

Why it fails: Storing passwords with reversible encryption is dangerous because the compromise of the decryption key exposes all user credentials. Hashing is a one-way transformation that provides security even if the database is leaked, whereas reversible encryption is inherently insecure for passwords.

The attacker must possess the cleartext password

Why it fails: Pass-the-Hash specifically bypasses the need for the cleartext password. The attacker uses the NTLM hash directly to authenticate. Requiring the cleartext password would describe a standard login process or a brute-force attempt, not the Pass-the-Hash technique itself.

The target must have SMB signing disabled

Why it fails: SMB signing is relevant to relay attacks, not Pass-the-Hash. Pass-the-Hash involves authenticating to the target as the user directly; signing prevents relaying traffic from one machine to another, but it does not prevent the direct use of a stolen hash.

Tasklist

Why it fails: Tasklist is a built-in Windows command-line utility used solely to display a list of currently running processes on a local or remote machine. It lacks the technical capability to capture, extract, or dump process memory contents such as LSASS memory spaces.

Netstat

Why it fails: Netstat is a standard networking command-line tool utilized for displaying active network connections, routing tables, and various network interface statistics. It does not interact with operating system processes or handle memory space extraction.

Regedit

Why it fails: Regedit is the graphical registry editor interface for Microsoft Windows used to view and modify system registry keys and values. It cannot interact with running process memory or extract LSASS credential caches directly.

HKLM\SAM and HKLM\SYSTEM

Why it fails: The SAM hive does contain local password hashes, but the SYSTEM hive does not contain cached domain credentials. Cached domain logons are stored in the SECURITY hive under the Cache subkey. An attacker who exports only SAM and SYSTEM can extract local hashes but cannot recover cached domain credentials, which limits lateral movement to local accounts.

HKLM\NTDS and HKLM\SECURITY

Why it fails: HKLM\NTDS is not a valid registry hive on a workstation; the NTDS.dit database exists only on domain controllers and is stored in the file system, not the registry. The SECURITY hive does contain cached domain credentials, but the combination with a non-existent NTDS key makes this option incorrect for a Windows 10 workstation scenario.

HKLM\SYSTEM and HKLM\SOFTWARE

Why it fails: The SYSTEM hive contains hardware and driver configuration, and the SOFTWARE hive stores installed applications and system settings. Neither hive contains password hashes or cached domain credentials. While the SYSTEM hive is needed to decrypt SAM and SECURITY hives offline (because it holds the boot key), it does not itself store the credential material the attacker sought in this scenario.

Rainbow table attack

Why it fails: Rainbow tables are precomputed hash chains used to crack password hashes offline, not live authentication attempts. This scenario involves real-time SSH connections to many hosts, which requires interactive or automated login attempts, not hash lookups. Rainbow tables also do not generate network traffic to port 22; they operate on captured hash files. The observed behavior is therefore inconsistent with a rainbow table attack.

Credential stuffing attack

Why it fails: Credential stuffing uses previously breached username/password pairs, assuming users reuse credentials across services. The scenario shows a fixed username with a short, varying password list, not a large set of known compromised credential pairs. The high request rate and internal targeting also differ from typical credential stuffing, which usually hits external login portals rather than SSH on internal hosts.

Vertical brute-force attack

Why it fails: Vertical brute-force means trying many passwords against a single account. Here, the same password list is applied to multiple different hosts with the same username, not many passwords against one target account. The observed pattern is horizontal, so this description does not match the traffic. It also fails to account for the distributed nature across internal hosts, which is the defining characteristic of the activity.

SHA-256; risk of collision attacks

Why it fails: Mode 1000 is specifically defined in hashcat for NTLM hashes, not SHA-256. While SHA-256 is a common hashing algorithm, the command switch -m 1000 directly maps to NTLM, making this option technically incorrect regarding the target hash format.

bcrypt; risk of slow brute-force degradation

Why it fails: Bcrypt is represented by mode 3200 in hashcat. Mode 1000 is exclusively for NTLM. Furthermore, bcrypt is designed to be slow, making it resistant to rapid cracking, which contradicts the high speed shown in the exhibit's performance metrics.

Kerberos TGT; risk of Golden Ticket generation

Why it fails: Kerberos tickets are typically cracked using modes specific to Kerberos, such as 18200 or 13100. Mode 1000 focuses on NTLM hashes. While Kerberos cracking is a valid threat, the exhibit's command parameters explicitly identify an NTLM-based attack scenario.

Testing thousands of passwords against a single high-privileged account

Why it fails: Testing many passwords against a single account is defined as a traditional brute-force attack. This method is easily detected by account lockout policies, which lock the account after a small number of failed attempts, making it ineffective for modern secure environments.

Capturing hashes via packet sniffing and offline cracking

Why it fails: Capturing hashes is a passive reconnaissance or intercept technique. Password spraying is an active authentication attempt against a target service, not an offline process. The two techniques are distinct in their methodology and their interaction with the target's authentication infrastructure.

Injecting malicious code into the authentication form

Why it fails: Injecting code into an authentication form is a form of Cross-Site Scripting (XSS) or SQL injection. Password spraying is a legitimate, albeit malicious, use of the authentication protocol where the attacker provides credentials they expect the server to evaluate.

Dictionary attacks use compromised lists; stuffing uses random passwords

Why it fails: Dictionary attacks use lists of common words or previously identified passwords to guess credentials. Credential stuffing specifically uses lists of *valid, stolen* credentials from other breaches. The distinction lies in the origin and verified nature of the password list used by the attacker.

Dictionary attacks are faster than credential stuffing

Why it fails: Credential stuffing is often faster in practice because it leverages high-probability credentials. Dictionary attacks may take significant time to successfully guess a single password. The speed comparison is inaccurate, as both are limited by the target's authentication rate-limiting protections.

Stuffing targets the database; dictionary attacks target the login

Why it fails: Credential stuffing targets the login interface directly, not the database. It simulates a user attempting to log in. It is not an injection attack on the database itself, but rather an exploitation of the authentication service via automated front-end requests.

Acquiring the TGT; goal is to forge Golden Tickets

Why it fails: Acquiring the TGT is associated with the 'Golden Ticket' attack, which requires the KRBTGT account hash. Kerberoasting targets service accounts to obtain TGS tickets, which are encrypted with the service account's password hash, not the domain-wide KRBTGT hash.

Acquiring the NTLM hash; goal is Pass-the-Hash

Why it fails: Kerberoasting results in an encrypted Kerberos TGS blob, not a raw NTLM hash. While the final goal is gaining access, the technique specifically relies on Kerberos ticket encryption, not NTLM protocol interception or pass-the-hash methodologies.

Acquiring the PAC; goal is privilege escalation

Why it fails: The Privilege Attribute Certificate (PAC) is part of a ticket, but Kerberoasting does not aim to acquire the PAC specifically. The objective is to crack the service account's password by brute-forcing the encrypted ticket payload provided by the Key Distribution Center.

Pass-the-Hash; 0xC000006A means the hash is expired

Why it fails: Sub-status 0xC000006A means 'Bad Password'. It does not refer to hash expiration. Furthermore, Pass-the-Hash would typically succeed if the attacker possesses the correct hash, as it bypasses the password requirement entirely in the authentication handshake.

Account lockout; 0xC000006A means account is disabled

Why it fails: Account lockout is usually indicated by sub-status 0xC000006A if the account has already exceeded thresholds. However, 0xC000006A strictly denotes a 'bad password' error. If the account were disabled, the sub-status would typically be 0xC0000072 or similar.

Kerberoasting; 0xC000006A means SPN not found

Why it fails: Kerberoasting does not generate Event ID 4625 logs on the target system for the account being roasted, as it is a request for a service ticket from the Domain Controller. 0xC000006A is specifically a local authentication error for bad passwords.

Salting increases the length of the hash, causing buffer overflows

Why it fails: Salting does not cause buffer overflows. Modern hash storage uses fixed-length fields or dynamic storage that handles the extra data. The security benefit comes from the uniqueness added by the salt, not from any memory corruption vulnerability.

Salts make the total hash space too large to compute

Why it fails: The salt does not make the hash space larger; it makes the mapping between plaintext and hash unique to each account. The primary defense is that the attacker cannot use the same precomputed table across multiple users or systems.

Salts slow down the hashing algorithm significantly

Why it fails: Salting adds negligible time to the hashing process. The performance hit comes from using slow, compute-intensive algorithms like bcrypt or Argon2, not from the addition of a few bytes of salt data to the input string before the hashing function executes.

It uses hardware-specific instructions to prevent GPU cracking

Why it fails: PBKDF2 is not inherently tied to hardware-specific instructions; it is a software-based algorithm. While it is slower than raw SHA-256, it does not prevent GPU cracking via specific instructions; it simply increases the cost of each attempt by requiring thousands of iterations.

It encrypts the hash so it cannot be decrypted

Why it fails: Hashing is a one-way process, not encryption. You cannot 'decrypt' a hash regardless of whether it is PBKDF2 or MD5. PBKDF2 provides strength by increasing the difficulty of the brute-force search space, not by hiding the hash behind an encryption layer.

It requires a secret key that is stored on a HSM

Why it fails: PBKDF2 does not require a secret key stored on an HSM. It uses the password and a salt as input. While HSMs can be used to protect master keys, PBKDF2's strength is derived purely from the iteration-based key stretching process.

It exploits weak encryption in SMB signing

Why it fails: Responder exploits name resolution protocols like LLMNR, not SMB signing. SMB signing is a defense mechanism that would prevent the relaying of the captured hash, but Responder's core objective is the poisoning of name resolution to force the client to reveal its hash.

It intercepts plaintext passwords via ARP spoofing

Why it fails: While Responder uses ARP spoofing to facilitate its presence, it does not typically capture plaintext passwords. It intercepts authentication challenges, which contain hashed material. Plaintext passwords are rarely transmitted over modern network protocols unless the application itself is insecure and unencrypted.

It performs Man-in-the-Middle on encrypted Kerberos tickets

Why it fails: Responder is designed to target NTLM-based authentication via broadcast name resolution. Kerberos is a much more robust protocol that relies on a trusted Key Distribution Center. Responder cannot easily intercept or modify Kerberos traffic in the same way it handles LLMNR/NBT-NS.

Mandating password changes every 90 days

Why it fails: Frequent rotation often causes users to choose simple, predictable passwords. Modern guidelines from NIST suggest that rotation should only occur upon evidence of compromise, as forced rotation significantly reduces the actual security of the passwords chosen by users over time.

Requiring a combination of uppercase and special characters

Why it fails: While complexity requirements are better than nothing, they are often insufficient on their own. Users tend to pick predictable patterns like 'Password123!'. A banned list is much more effective because it identifies and blocks these predictable choices specifically.

Storing all passwords in a secure password manager

Why it fails: Password managers are great for user security, but they do not help in enforcing a corporate password policy. A central authority must enforce the complexity and 'banned' status at the point of entry (e.g., Active Directory) to ensure compliance across the organization.

It cracks the SAM database file offline

Why it fails: This command operates on memory, not the SAM database file. The SAM database is stored on disk and is only accessible with system privileges. The command specifically targets the LSASS process memory to retrieve credentials currently held by the Windows authentication subsystem.

It resets the local Administrator password

Why it fails: This command does not modify credentials; it only reads them. Resetting the Administrator password requires different commands (e.g., 'token::elevate' followed by password change utilities). Its primary utility is credential harvesting, not credential modification or administrative password resets.

It clears the event logs to hide the attack

Why it fails: Clearing logs is done using commands like 'event::clear'. Extracting credentials from memory is purely a harvesting operation. While attackers may clear logs afterwards, 'sekurlsa::logonpasswords' has no inherent log-clearing functionality; its purpose is solely to steal identity information.

Mode 3000, which is designated for legacy LAN Manager hashes.

Why it fails: LAN Manager is an obsolete and cryptographically weak authentication protocol that has been disabled by default since Windows Vista and Windows Server 2008. While occasionally found in extremely legacy environments, NTDS.dit databases store modern NTLM hashes rather than original LM hashes.

Mode 5600, which targets NetNTLMv2 network authentication captures.

Why it fails: NetNTLMv2 hashes are captured over the network during authentication exchanges, such as through Responder or SMB relay attacks. They differ fundamentally in structure from the static password database hashes extracted directly from the NTDS.dit file.

Mode 13100, which is utilized for Kerberos 5 TGS-REP etype 23 tickets.

Why it fails: Kerberos ticket hashes are targeted during Kerberoasting attacks where service tickets are requested from the domain controller. These hashes require an entirely different parsing mode and structure than the static account hashes stored natively within NTDS.dit.

AS-REP Roasting targeting user accounts with Kerberos pre-authentication disabled.

Why it fails: AS-REP Roasting targets user accounts lacking Kerberos pre-authentication, returning a ticket encrypted with the user's key; service accounts are non-user objects whose passwords are cracked from Kerberoasting service tickets. It tempts because both are offline Kerberos cracking techniques against domain accounts.

NTLM relaying against local SMB signing configurations.

Why it fails: NTLM relaying captures authentication traffic to impersonate a host; it does not extract a stored hash for offline cracking, and SMB signing configuration is unrelated to recovering cleartext from a service account. It tempts because relaying also targets service accounts, but the stem specifies offline cracking of a recovered hash.

Pass-the-Hash utilizing harvested NTLM password hashes from memory.

Why it fails: Pass-the-Hash reuses an NTLM hash for authentication without ever recovering cleartext, so it cannot explain a cracked plaintext password. It is tempting because it targets service accounts and non-user objects, and would be correct had the attacker authenticated with the hash rather than cracking it offline.

Enabling Extended Protection for Authentication on the domain controller

Why it fails: Extended Protection for Authentication (EPA) binds authentication to the TLS channel or SPN and is effective for HTTP-based services like Exchange and LDAP over TLS. It does not apply to native SMB file server sessions, so enabling EPA on a domain controller would not prevent the relayed NTLM authentication to the file server in this scenario.

Disabling NetBIOS over TCP/IP on all workstations

Why it fails: Disabling NetBIOS over TCP/IP reduces legacy name resolution and some broadcast-based poisoning opportunities, but it does not stop NTLM relay over SMB, which operates on TCP port 445. The relayed authentication in this scenario flows directly to the file server over SMB, so removing NetBIOS does not invalidate the relayed challenge/response or prevent the session from being established.

Requiring Kerberos authentication for all domain logons

Why it fails: Kerberos is preferred for domain authentication, but NTLM remains enabled by default and can be used for SMB access to file servers even in a Kerberos-capable domain. Simply requiring Kerberos for logons does not prevent a client from falling back to NTLM for SMB, and the relayed NTLM authentication would still succeed unless signing or another NTLM-specific control is enforced.

Brute-force attack

Why it fails: A brute-force attack systematically tries many passwords against a single account until successful. The log shows many usernames but only one password attempt per user, which is the opposite pattern. Brute-force would generate a high volume of failed attempts for one account, likely triggering lockout.

Credential stuffing

Why it fails: Credential stuffing relies on previously breached username/password pairs from other sites. The scenario describes using a list of common usernames, not known compromised credentials, and only one password per username. This does not align with credential stuffing, which would typically show varied passwords from a breach corpus.

Rainbow table attack

Why it fails: Rainbow tables are used offline against captured password hashes, not for online authentication attempts. They require possession of the hash and significant precomputation. The scenario involves live logon attempts against a domain controller, which is an online attack, so rainbow tables are not applicable here.