Password Attacks practice questions

Using a low-and-slow approach with long intervals between authentication attempts.

Why it fails: A low-and-slow approach is specifically designed to evade detection by staying under the threshold of security alerting systems. It does not increase the risk of detection or lockout; rather, it is a recommended strategy to minimize the footprint of the attack during the reconnaissance and exploitation phases of an assessment.

Running the attack during peak business hours when user activity is highest.

Why it fails: Running attacks during business hours can actually help mask the malicious activity within the noise of legitimate traffic. While high activity increases the volume of logs, it does not inherently increase the risk of an individual account lockout, as the lockout threshold is typically based on repeated failures for a single account.

Using a common password that is included in the organization's banned password list.

Why it fails: Using a password that is on the banned list will result in an authentication failure, but it does not inherently increase the risk of detection more than any other incorrect password. The risk of detection is driven by the volume and frequency of failed attempts, not the specific content of the password.

The organization requires all users to change their passwords every 30 days.

Why it fails: Frequent password rotation policies are generally considered a security best practice, though their efficacy is debated. This policy does not make an organization more or less vulnerable to Kerberoasting, which depends on the existence of SPNs and the ability to request service tickets, not the user's password age.

The use of legacy NTLM authentication for all domain communication.

Why it fails: Kerberoasting is a Kerberos-specific attack. If an organization relies exclusively on NTLM, Kerberoasting cannot be performed because it requires the TGS (Ticket Granting Service) exchange mechanism unique to Kerberos. Therefore, a reliance on NTLM actually precludes the possibility of this specific attack vector occurring against the domain.

Using a simple shell script to decrypt the hashes using a symmetric key.

Why it fails: Linux password hashes are created using one-way cryptographic functions. They are not encrypted with a symmetric key; therefore, they cannot be 'decrypted'. Any tool attempting to recover the password must use a guessing strategy (brute-force or dictionary) that compares hashes of guesses against the original hash.

Executing an AS-REP roasting attack against the local system.

Why it fails: AS-REP roasting is a technique specific to Kerberos and Active Directory environments. It is completely irrelevant to standard Linux local password hashes. Attempting to use this methodology on a standalone Linux machine will result in no progress and is a misunderstanding of the underlying authentication architecture.

SSO solutions inherently disable account lockout policies to improve user experience.

Why it fails: SSO solutions rarely disable lockout policies entirely. In fact, many SSO providers enforce very strict lockout policies to protect the centralized identity store. Assuming that lockout is disabled is a dangerous strategy that will likely lead to account lockouts and immediate detection of the attack activity.

SSO solutions only support multi-factor authentication, making password spraying impossible.

Why it fails: While MFA is common with SSO, it is not mandatory. Many organizations use SSO without MFA or with it only for specific applications. Password spraying is still possible, but the risk of detection remains higher due to the centralized logging of the SSO platform compared to distributed systems.

Passwords in an SSO environment are always stored in plaintext, making them easy to recover.

Why it fails: SSO providers store passwords using strong, salted, and hashed formats, just like any other secure identity provider. They are not stored in plaintext. Suggesting that they are is factually incorrect and misrepresents the security posture of modern identity management platforms used in enterprise environments.

Assigning the service account to the Domain Admins group for full access.

Why it fails: Assigning service accounts to the Domain Admins group is a catastrophic security practice. Service accounts should always follow the principle of least privilege, with only the absolute minimum permissions required to perform their specific tasks. Granting broad administrative rights turns every minor account compromise into a full domain breach.

Configuring the account to never require a password change for stability.

Why it fails: Never changing a password is a severe security risk. Over time, the probability of the password being compromised or cracked increases significantly. If a service account is compromised, the lack of rotation ensures the attacker maintains access indefinitely, which is a major security failure in any enterprise environment.

Storing service account passwords in a shared, plaintext network folder.

Why it fails: Storing passwords in plaintext is a critical vulnerability. Any user with access to the network share can trivially steal the credentials. This practice essentially hands over the service account keys to any attacker who gains even low-level access to the internal network, making it a major security failure.

Use an online password cracking service to decrypt the archive.

Why it fails: Uploading sensitive data from an engagement to an online service is a severe violation of professional ethics and client confidentiality. Furthermore, online services are unlikely to support custom, proprietary KDFs. This approach is both insecure and ineffective for the specific challenges posed by a custom encryption implementation.

Assume the archive is unbreakable and move to a different lateral movement vector.

Why it fails: Giving up is not an acceptable strategy during an engagement. Custom implementations are often poorly designed and may have weaknesses. Analyzing the implementation often reveals flaws that can be exploited, whereas stopping at the first sign of difficulty neglects potentially critical findings that could be important to the client's overall security posture.

Run a dictionary attack against the binary file without a KDF transformation.

Why it fails: If a KDF is used, the password cannot be compared directly to the binary file. The KDF transformation is a mandatory step in the authentication or decryption process. Without correctly implementing the KDF in your attack, you will never arrive at a valid key, rendering any dictionary attack completely ineffective.

Increase the delay between requests to bypass rate limiting.

Why it fails: While increasing delays helps avoid rate limiting or WAF triggers, it does not address the core issue of identifying valid usernames. You are failing to utilize the information disclosure provided by the server to refine your target list, which is the primary objective of this specific technical scenario.

Use a password list containing common patterns like Winter2023!.

Why it fails: Applying a password list is the second stage of a spray attack. This choice ignores the initial requirement to differentiate between valid and invalid usernames using the server response codes. You must refine your target list first to ensure your password attempts are hitting valid, active accounts only.

Rotate the source IP addresses for every single password attempt.

Why it fails: Rotating IP addresses is a valid evasion technique, but it does not resolve the underlying issue of targeting non-existent accounts. You are essentially spraying blindly without leveraging the server-side error differentiation, which makes your attack less efficient and more likely to be detected by account lockout monitors.

The $6$ identifier indicates the usage of the MD5 hashing algorithm.

Why it fails: The $6$ identifier in Linux shadow files corresponds to SHA-512. MD5 is represented by the $1$ identifier. Misidentifying the hash algorithm prevents the cracking tool from correctly reconstructing the password verification logic, which renders the entire effort of acquiring the hash useless for password recovery or auditing.

Cracking SHA-512 hashes is computationally easier than cracking legacy DES-based hashes.

Why it fails: SHA-512 is significantly more computationally expensive to compute than legacy DES-based hashes. The increased rounds of SHA-512 make it much harder to brute-force or perform dictionary attacks. Consequently, cracking attempts take significantly longer, often making it impractical without high-performance hardware like GPUs or specialized FPGAs.

If the second field is an asterisk (*), the user is required to change their password.

Why it fails: An asterisk (*) in the password field indicates that the account is locked or that no password has been set. It does not imply a requirement for a password change; it usually signifies that the account cannot be logged into via password authentication at all.

hashcat -a 1 -r rules/combinator.rule wordlist1.txt wordlist2.txt hashes.txt

Why it fails: Attack mode 1 represents the combinator attack, which merges words from two separate files rather than applying rule-based mutations to a single wordlist. Furthermore, combinator.rule is not a standard mutation ruleset designed for single-wordlist transformations.

hashcat -a 3 -r rules/T1048.rule mask.hcmask hashes.txt

Why it fails: Attack mode 3 relies on masks rather than wordlists, making rule files largely redundant or incompatible depending on the exact mask configuration applied. Additionally, T1048 is not a standard rule file distributed natively within the official Hashcat package.

hashcat -a 6 -r rules/leetspeak.rule wordlist.txt mask.hcmask hashes.txt

Why it fails: Attack mode 6 combines hybrid wordlist and mask operations, and while leetspeak transformations exist, they require specific rule syntax rather than arbitrary filenames that may not exist in the default rules directory.

Hashcat with mode 18200

Why it fails: Mode 18200 is for Kerberos 5 AS-REP etype 23 (RC4-HMAC). If the captured AS-REP is etype 23, this mode is correct. However, the scenario does not specify the encryption type, and in modern Windows environments, AES is often used. Without knowing the etype, assuming 18200 could fail. The most robust answer is to use a tool that automatically detects the hash type, such as John the Ripper with the krb5asrep format. Thus, this option is not the best choice here.

Aircrack-ng with the -K option

Why it fails: Aircrack-ng is a tool for cracking Wi-Fi network keys, specifically WEP and WPA/WPA2-PSK. It does not support Kerberos AS-REP hashes. The -K option is not even valid for this purpose. Using Aircrack-ng would be completely ineffective for cracking Kerberos hashes. Thus, this option is incorrect.

Hashcat with mode 7500

Why it fails: Mode 7500 is for Kerberos 5 AS-REQ Pre-Auth etype 23, which is used for pre-authentication hashes, not AS-REP responses. The scenario involves an AS-REP response because the account does not require pre-authentication. Using 7500 would be incorrect and would not crack the captured hash. Therefore, this option is wrong.

Use John the Ripper with the --format=netntlmv2 option and a rule set.

Why it fails: John the Ripper does support NetNTLMv2 via the netntlmv2 format, but the question asks for the most effective next step. Hashcat with mode 5600 is generally preferred for NetNTLMv2 due to its GPU acceleration and extensive rule support. John is a valid tool but less optimal here. This option is plausible but not the best choice given the scenario's emphasis on effectiveness.

Relay the captured NetNTLMv2 hash to another host using ntlmrelayx.

Why it fails: The scenario explicitly states SMB signing is enforced on the client, which blocks SMB relay attacks. While ntlmrelayx can relay NTLM authentication to other services, it will fail against hosts requiring SMB signing. Additionally, the goal is to recover the cleartext password, not to relay authentication. This option ignores the signing constraint and the objective.

Use Mimikatz with the sekurlsa::pth module to perform a pass-the-hash attack.

Why it fails: Pass-the-hash requires an NTLM hash (the stored NT hash), not a NetNTLMv2 challenge-response. NetNTLMv2 is a network authentication capture that cannot be used directly for pass-the-hash. Mimikatz sekurlsa::pth expects an NT hash or AES key, so it would fail here. This option confuses the captured network response with a usable credential hash.

Metasploit's psexec module with SMBPass set to the hash

Why it fails: Metasploit's psexec module can use pass-the-hash, but it requires setting both SMBUser and SMBPass, where SMBPass is the hash. However, the module often expects the hash in a specific format and may require additional configuration. It is possible, but not as straightforward as the other tools. In the context of this question, the most direct and commonly used tools are Impacket and CrackMapExec. Thus, this option is less correct than the others.

Hydra with the -p option

Why it fails: Hydra is a password cracking tool that performs online brute-force attacks. It does not support pass-the-hash authentication. The -p option is used to specify a password or a list of passwords, not a hash. Hydra cannot use NTLM hashes for authentication. Therefore, this option is incorrect.

Nmap with the smb-psexec script

Why it fails: Nmap's smb-psexec script is used for executing commands via SMB but does not support pass-the-hash authentication. It typically requires plaintext credentials or a valid session. It cannot use an NTLM hash directly. Therefore, this option is incorrect.

Pass-the-Ticket using a forged Kerberos service ticket (silver ticket) created from the NTLM hash.

Why it fails: A silver ticket is forged using the service account's NTLM hash, but it requires the target service's hash, not a user's NTLM hash. The question specifies NTLM hashes from a domain controller, likely user hashes. Creating a silver ticket requires the computer or service account hash. Thus, this option is not applicable without additional information. It confuses the requirements for ticket forgery.

Use the NTLM hash to decrypt the domain's Kerberos TGTs and extract plaintext passwords.

Why it fails: NTLM hashes cannot decrypt Kerberos TGTs because TGTs are encrypted with the krbtgt account's hash, not the user's NTLM hash. Extracting plaintext passwords from tickets is not feasible without the krbtgt hash. This option misunderstands the relationship between NTLM hashes and Kerberos encryption, and it does not provide a method for lateral movement using the captured hashes.

Pass-the-Hash using RDP with the NTLM hash to authenticate to a remote desktop session.

Why it fails: RDP does not natively support pass-the-hash authentication. While tools like Restricted Admin mode can sometimes allow it, it is not a standard or reliable method. The scenario does not mention Restricted Admin mode, and typical RDP clients require plaintext credentials or a ticket. Therefore, this option is not a valid technique for leveraging NTLM hashes for lateral movement in this context.

5600

Why it fails: Mode 5600 is for NetNTLMv1 hashes, another network authentication format. Like NetNTLMv2, it is not used for local SAM hashes. NTLM hashes from the SAM are stored as a single MD4 hash of the password. Therefore, this mode is incorrect.

3000

Why it fails: Mode 3000 is for LM (LAN Manager) hashes, which are an older, weaker hash format. While LM hashes may also be present in the SAM database, the question specifies NTLM hashes. Using mode 3000 would not crack NTLM hashes. Therefore, this option is incorrect.

5500

Why it fails: Mode 5500 is for NetNTLMv2 hashes, which are used in network authentication challenges. NTLM hashes from the SAM database are different. NetNTLMv2 is a challenge-response hash captured over the network, not stored locally. Thus, this mode is not applicable.

Use John the Ripper with the krb5tgs format and a rule set.

Why it fails: John the Ripper does support krb5tgs, but the question asks for the tool and technique. Hashcat mode 13100 is more efficient for TGS-REP cracking due to GPU acceleration. John is a valid alternative but less optimal. This option is plausible but not the best choice given the scenario's emphasis on effectiveness and the specific mode available in hashcat.

Use Mimikatz with the kerberos::golden module to forge a golden ticket.

Why it fails: A golden ticket is forged using the krbtgt account's hash, not a service account's TGS ticket. The scenario involves a TGS ticket for a service account, which is used for silver ticket attacks or offline cracking. Forging a golden ticket requires domain admin-level access to the krbtgt hash. This option confuses the type of ticket and the required hash.

Use Responder to capture the service account's NetNTLMv2 hash and crack it with hashcat mode 5600.

Why it fails: Responder captures NetNTLMv2 hashes from network authentication, not Kerberos TGS tickets. The scenario already has a TGS ticket extracted from memory. Using Responder would not apply here and would require additional network interaction. This option misidentifies the type of credential material and the appropriate cracking mode.

The target system must have the Kerberos pre-authentication disabled for the user account.

Why it fails: Kerberos pre-authentication is unrelated to NTLM-based pass-the-hash attacks. While disabling it facilitates AS-REP roasting, it does not enable pass-the-hash functionality. NTLM authentication occurs independently of Kerberos mechanisms, meaning the state of pre-authentication on the domain controller has no bearing on whether an NTLM hash can be used successfully.

The victim machine must have the 'Restricted Admin' mode enabled in the RDP configuration.

Why it fails: Restricted Admin mode for RDP is a specific security feature designed to prevent credential exposure during remote sessions. While it relates to how credentials are handled, it is not a prerequisite for conducting a pass-the-hash attack, which typically utilizes tools like Mimikatz or Impacket to inject hashes into an existing session.

The target machine must be running a version of Windows older than Windows Server 2012.

Why it fails: Pass-the-hash is not limited to legacy Windows versions. While newer versions have introduced protections like Credential Guard, the fundamental vulnerability inherent to the NTLM protocol remains present across all modern versions of Windows, provided the protocol itself is not explicitly disabled within the domain or local security policy.

Performing a brute-force attack on a SHA-256 encrypted archive.

Why it fails: The -m 1000 flag in Hashcat specifically targets NTLM authentication, not SHA-256 archives. SHA-256 archives would require different mode flags, such as 14100 for 7-zip. Consequently, this command would fail to produce meaningful results if applied to an archive file format as requested by the user.

Attempting a mask attack to guess passwords based on a specific pattern.

Why it fails: The -a 0 flag in Hashcat specifies a dictionary attack, which uses a list of words. A mask attack would require the -a 3 flag to define a character set and pattern. Therefore, the command does not perform a pattern-based guess, but rather iterates through the provided wordlist file.

Extracting domain user hashes from a SAM database file.

Why it fails: The command provided is for cracking already existing hashes contained within a file, not for extracting those hashes from a system database like the SAM file. Extraction requires tools like impacket-secretsdump or administrative access to the registry, which are distinct processes from the actual cracking phase performed by Hashcat.

The credentials are secure because base64 is difficult to reverse without the secret key.

Why it fails: Base64 is a public, reversible encoding scheme that requires no secret key for decoding. Anyone with access to the encoded string can transform it back into its original format effortlessly. Claiming it is secure is a dangerous misconception that leaves user credentials exposed to anyone who can intercept the traffic.

The credentials are protected from casual inspection but vulnerable to automated tools.

Why it fails: Base64 provides no protection against either casual inspection or automated tools. Because it is a standardized format, any browser, proxy, or simple script can decode it instantly. It offers no security benefits and should never be used as a mechanism for protecting sensitive data like passwords or session identifiers.

The implementation is acceptable if the connection is encrypted with TLS.

Why it fails: While TLS protects data in transit, storing credentials in a cookie in base64 format is still insecure at rest on the client machine. If the client machine is compromised or if the browser history is accessed, the credentials remain exposed. Proper security requires hashing or robust session management tokens.

The account must have a Service Principal Name (SPN) set in the domain properties.

Why it fails: Having an SPN set is the requirement for Kerberoasting, not AS-REP Roasting. AS-REP Roasting targets accounts regardless of whether they have an SPN, provided they have pre-authentication disabled. Confusing these two attacks is a common error that can lead to incorrect scoping of potential targets during an assessment.

The user must be a member of the Domain Admins or Enterprise Admins group.

Why it fails: Membership in privileged groups is not a technical requirement for AS-REP Roasting. Any account with the vulnerable setting enabled can be targeted, regardless of its permission level. While targeting administrators is more valuable, the attack's feasibility is strictly tied to the account's configuration, not its security group membership.

The account must be configured with a password that has never been rotated.

Why it fails: The age or rotation status of the password does not impact the vulnerability to AS-REP Roasting. The attack focuses on the pre-authentication setting. As long as the account exists and the pre-authentication flag is toggled, the account is vulnerable, regardless of how recently the password was updated or changed.

The vault is vulnerable to dictionary attacks due to the lack of a salt in the local file.

Why it fails: While dictionary attacks are a concern, the lack of a master password is the primary issue. The local encryption mechanism usually involves a hardcoded or derived key from system artifacts, which an attacker can find without needing to perform a dictionary attack against the database file itself.

The lack of a master password prevents the use of multi-factor authentication for the vault.

Why it fails: Multi-factor authentication is a separate mechanism from the password vault's local encryption. While not having a master password is bad, it does not strictly prevent the implementation of MFA, although it would be highly unusual to offer MFA on a system that doesn't require a master password.

The file format will be incompatible with standard password cracking software like John the Ripper.

Why it fails: Compatibility with cracking software is irrelevant if the key can be obtained through other means. In this scenario, the attacker would not need to crack the file; they would simply extract the key from the host, making the password manager's file format entirely irrelevant to the success of the theft.