Select Two (Multi-Select) Questions

Increase the minimum password length to 50 characters.

Why it fails: While increasing complexity and length improves resilience against brute-force attacks, it does not stop password spraying, which relies on common, widely used passwords. Users will often choose simple phrases that meet length requirements but are still easily guessable, rendering this control ineffective for this specific threat vector.

Require all users to use the same password for both on-premises and cloud.

Why it fails: Enforcing the same password across environments is a security anti-pattern that increases the impact of a credential compromise. If one environment is breached, the attacker automatically gains access to both. This configuration does nothing to mitigate password spraying and significantly degrades the overall security posture.

They enable the use of rainbow tables.

Why it fails: Salted hashes explicitly prevent the use of precomputed rainbow tables. Rainbow tables rely on the consistency of hash outputs for identical inputs across the entire set. When a unique salt is introduced, the precomputed table would have to be recalculated for every possible salt, making it computationally infeasible.

They are inherently faster to crack than unsalted hashes.

Why it fails: Salted hashes are actually harder to crack than unsalted ones because they force an attacker to perform a unique attack for every single user record. There is no performance gain for the attacker; in fact, the overhead of handling the salt adds a small, albeit negligible, amount of complexity.

They are usually stored in cleartext in the configuration file.

Why it fails: Salts are not secrets and are typically stored alongside the hash in the database. While they are not 'secret', they are not stored in cleartext in a configuration file; rather, they are part of the stored credential record, allowing the system to re-compute the hash during login verification.

The age of the vulnerability in the CVE database

Why it fails: The age of a CVE does not determine its current criticality. Older vulnerabilities may still be actively exploited if patches are not applied. Prioritization should be based on current exploitability and impact, not the date of disclosure.

The number of other vulnerabilities on the same host

Why it fails: The quantity of vulnerabilities on a host does not directly indicate the criticality of a specific vulnerability. A single critical flaw is more urgent than many low-severity issues. Focusing on count can lead to misprioritization and neglect of the most dangerous findings.

The scanner's confidence level in the finding

Why it fails: While confidence level can affect whether a finding is a false positive, it is not a primary factor for criticality. Once a vulnerability is confirmed, criticality is based on severity and impact. Confidence helps validate findings but does not change the inherent risk.

Increase the maximum number of concurrent hosts scanned.

Why it fails: Raising concurrent hosts increases the volume of simultaneous traffic, which can overwhelm fragile devices and network links. This would likely increase, not decrease, disruption risk. While it speeds up the scan, it does so at the cost of stability. Therefore it is the opposite of what a tester should adjust to protect sensitive production equipment during a scan.

Disable 'Thorough tests' in the scan policy.

Why it fails: Disabling thorough tests reduces scan depth and may skip some intrusive checks, but it is not the primary control for avoiding disruption. Thorough tests primarily affect coverage, not concurrency or safety classification. Fragile devices are more likely to be affected by high concurrency or unsafe plugins. Therefore this setting is not the most direct way to reduce disruption risk.

Set the scanner to use UDP instead of TCP for all checks.

Why it fails: Switching all checks to UDP is not a supported or effective configuration and would drastically reduce accuracy. Many vulnerability checks rely on TCP-based protocols. UDP scanning is inherently unreliable and would not make the scan safer for fragile devices; it would simply produce incomplete results. This is not a recognized method for reducing disruption during a vulnerability scan.

NTLMv2 hashes can be cracked using precomputed rainbow tables.

Why it fails: Rainbow tables are ineffective against NTLMv2 because each hash incorporates a unique server challenge and client nonce, making precomputation impractical. The challenge-response mechanism ensures that the same password produces different hashes for each authentication attempt. Therefore, rainbow tables cannot be used; instead, brute-force or dictionary attacks with the specific challenge are required.

Hashcat can crack NTLMv2 hashes without specifying a wordlist or mask.

Why it fails: Hashcat requires an attack mode, such as a wordlist, mask, or combinator attack, to generate candidate passwords. It does not have a built-in default wordlist or the ability to magically crack hashes without input. The tester must provide a wordlist, rules, or mask to attempt cracking. Without specifying an attack method, Hashcat will not proceed.

NTLMv2 hashes are salted with the username, making them more resistant to cracking.

Why it fails: While the username is included in the NTLMv2 hash computation, it is not a salt in the traditional sense. The primary resistance comes from the server challenge and client nonce, which are unique per authentication. The username is known and does not add significant computational difficulty. Therefore, stating that it is salted with the username is misleading and not the main factor.

UDP ports must be scanned sequentially, preventing parallelization.

Why it fails: Nmap is fully capable of parallelizing UDP scans just as it does with TCP scans. The speed constraint is caused by the latency in waiting for responses and the handling of rate-limited ICMP errors, rather than a technical limitation on scanning multiple ports at the same time.

UDP packets are always blocked by stateful firewalls regardless of status.

Why it fails: Stateful firewalls do not block all UDP packets; they track the state of UDP streams. If a legitimate service is listening, the firewall will allow the traffic. The challenge is not that they are blocked by default, but rather the difficulty in determining the status based on responses.

The color scheme of the target's command shell.

Why it fails: The graphical user interface or terminal color settings are irrelevant to binary exploitation. Exploits function at the machine code or logic layer, interacting with memory addresses, system calls, and application APIs. Visual interface settings do not affect the underlying execution flow or the success of the exploit.

The network bandwidth available to the target.

Why it fails: While network latency can affect shell stability, it does not determine the initial success of a memory corruption exploit. Exploits succeed or fail based on logic and memory state; bandwidth only influences the speed of communication or data transfer once a connection has already been successfully established.

The number of users currently logged in.

Why it fails: The number of active users is generally unrelated to the success of a software exploit. Unless the vulnerability is specifically tied to a multi-user session state or a resource lock, the presence of other users does not change the memory corruption mechanism that triggers the exploit.

A clause allowing the tester to disable antivirus software on the mainframe during testing.

Why it fails: Disabling antivirus on a production mainframe is highly risky and unlikely to be permitted. It does not address batch processing concerns and could introduce security vulnerabilities. The RoE should focus on scheduling and communication rather than disabling protective controls.

A provision to use only automated scanning tools to minimize manual intervention.

Why it fails: Automated scanning can still disrupt batch processing if run at the wrong time, and it may not be suitable for mainframe environments. The choice of tools does not mitigate the risk of interfering with scheduled jobs. The key is to control when testing occurs and ensure rapid communication, not to restrict tool usage.

A requirement that all testing be conducted from an external IP address.

Why it fails: External testing may not be relevant or sufficient for a mainframe environment, and it does not directly address the risk of disrupting batch processing. The source of testing traffic is less important than when and how it is conducted. This requirement could even limit the effectiveness of the test if internal access is needed.

Injecting malicious DLL payloads into the Local Security Authority Subsystem Service to capture plaintext credentials in real-time.

Why it fails: Injecting unauthorized dynamic link libraries into LSASS is an active host compromise technique rather than an offline analysis method for extracted database artifacts. Operators typically dump the memory safely or use volume shadow copies rather than high-risk active injection.

Executing Kerberoasting against all user accounts to extract service tickets encrypted with legacy RC4 encryption keys.

Why it fails: Kerberoasting is a network-based attack vector used to request service tickets directly from the Active Directory domain controller. Since the operator already possesses the offline NTDS.dit database, network-based ticketing attacks are unnecessary and introduce avoidable detection risks.

Running a responder-based LLMNR/NBT-NS poisoning campaign to capture incoming network authentication challenge-response pairs.

Why it fails: LLMNR and NBT-NS poisoning captures NetNTLM challenge-response hashes from broadcast name resolution traffic, which is credential harvesting on the network rather than extraction and analysis of credentials already dumped from the domain controller. It is tempting because captured hashes can be cracked offline, but the dumped LSA secrets and NTDS.dit already contain those credentials.

A list of all vulnerabilities found during the previous year's audit.

Why it fails: While helpful for benchmarking, historical vulnerability data belongs in the pre-engagement assessment phase or the background information gathering phase. It is not a functional component of a communication plan, which focuses on real-time interaction, notification procedures, and emergency contact details during the active testing window.

The specific exploit payloads that will be used during the test.

Why it fails: The communication plan is not intended to document technical exploit methodologies. While the RoE may restrict certain payloads, the communication plan itself is focused on administrative and operational interactions between the testing team and the client, rather than the technical specifics of the exploitation phase.

The estimated total cost of the project and payment schedule.

Why it fails: Financial terms and payment schedules are part of the legal contract or the Statement of Work (SOW). They should not be included in the Rules of Engagement, which focus on the technical and operational constraints, safety procedures, and communication workflows required during the execution of the penetration test.

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.

Conducting an online brute-force attack against the domain controller

Why it fails: Online brute-force attacks are slow, noisy, and likely to trigger account lockout policies. They are not effective for cracking a large set of hashes because each attempt requires a network round-trip and authentication. Offline cracking is preferred when hashes are already obtained, as it avoids detection and lockouts.

Performing a rainbow table attack using precomputed tables for NTLM

Why it fails: Rainbow tables for NTLM are large and less effective because NTLM hashes are unsalted but the keyspace is vast. Precomputed tables can be defeated by salting, but NTLM lacks salts. However, the storage and lookup requirements are impractical for complex passwords, and modern cracking with GPUs often outperforms rainbow tables. Thus, it is not the most effective technique here.

Using a dictionary attack with a list of common passwords only

Why it fails: A plain dictionary attack without rules is limited to the exact words in the list. Many passwords include variations like capitalized first letters or appended digits, so this approach misses a significant portion. While it is fast, it is less effective than rule-based attacks for complex passwords. It should be combined with other techniques for better results.

Running an Nmap SYN scan with a low timing template against the target's external ranges

Why it fails: An Nmap SYN scan sends TCP SYN packets to the target's IP ranges, which is active reconnaissance and violates the requirement to avoid sending packets to the target's own IP space. Even a low timing template still generates traffic that could appear in the target's logs or trigger IDS alerts. This technique is therefore unsuitable for the stated passive-only constraint.

Using a web application scanner to crawl the target's public website for hidden directories

Why it fails: A web application scanner requests pages and directories from the target's web servers, generating HTTP traffic that reaches target-owned infrastructure. This is active reconnaissance and could be detected by web application firewalls or logged in access logs. It also focuses on web content rather than the broader internet-facing system and service inventory the scenario seeks.

Performing DNS zone transfer attempts against each authoritative name server

Why it fails: A zone transfer attempt sends a DNS query directly to the target's authoritative name servers, which counts as active reconnaissance against the target's infrastructure. Even though it is a single query, it reaches target-owned systems and may be logged. It also rarely succeeds on properly configured servers, so it fails both the passive requirement and the reliability expectation.

Nmap with the smb-enum-shares script

Why it fails: Nmap's smb-enum-shares script enumerates SMB shares on a host. While it can discover shares on domain controllers, it does not provide detailed information about domain controller roles or privilege escalation vulnerabilities. It is limited to share enumeration and does not map attack paths or identify misconfigurations like delegation settings. It is not the most appropriate for this scenario.

Metasploit's auxiliary/scanner/smb/smb_version

Why it fails: This Metasploit module scans for SMB version information. While it can identify Windows versions and potentially missing patches, it does not specifically enumerate domain controllers or their privilege escalation vulnerabilities. It provides a broad scan but lacks the granularity to identify domain controller roles and misconfigurations. It is not the best choice for targeted domain controller enumeration.

Responder with LLMNR poisoning

Why it fails: Responder is used to poison LLMNR, NBT-NS, and mDNS queries to capture hashes. It is not an enumeration tool for domain controllers. It can be used to capture credentials, but it does not enumerate domain controllers or identify privilege escalation vulnerabilities. Using it in this scenario would not directly help in identifying vulnerable domain controllers.

The penetration tester's personal home address and after-hours phone number.

Why it fails: Contact information for the testing team is useful, but a tester's personal home address is not an appropriate or necessary element of the Rules of Engagement. Professional contact details such as a business phone and email suffice. Including personal information creates privacy risk and does not contribute to the legal defensibility of the engagement.

A detailed exploit payload library the testers plan to use against production systems.

Why it fails: While techniques may be discussed at a high level, providing a detailed exploit payload library is not a standard Rules of Engagement element and could expose sensitive tooling. Regulators care about authorization, scope, and boundaries, not the specific payloads. Including this adds unnecessary risk and does not strengthen the legal defensibility of the engagement.

A guarantee that no production system will experience any disruption during testing.

Why it fails: No responsible penetration test can guarantee zero disruption, especially when testing production systems. Rules of Engagement typically include risk acknowledgment and rollback procedures rather than absolute guarantees. Promising no disruption would be misleading and could expose the testing firm to liability if an unexpected outage occurred during authorized activities.

Configure the scanner to perform a SYN stealth scan on all 65,535 TCP ports for every host before authenticating.

Why it fails: A full-port SYN scan is unauthenticated and generates large amounts of traffic, increasing scan duration. It does not leverage credentials to inspect patch state or configuration, so it fails to meet the goal of reducing load while detecting missing patches. It may also trigger IDS/IPS alerts unnecessarily.

Limit the scan to a predefined list of common ports and disable all plugin families except 'Denial of Service'.

Why it fails: Restricting ports reduces coverage and disabling all but the DoS family removes patch and configuration checks entirely. This would miss missing patches and misconfigurations, directly contradicting the objective. It also unnecessarily runs intrusive DoS tests that can harm systems without providing useful vulnerability data.

Set the scanner to use a very aggressive timing template to maximize parallelism across all hosts.

Why it fails: Aggressive timing increases packet volume and concurrency, which can overwhelm network devices, cause packet loss, and actually lengthen scan times due to retransmissions. It does not improve patch or configuration detection and risks disrupting production services, making it a poor choice for reducing load and duration.

Use -O to enable OS detection.

Why it fails: OS detection (-O) sends a series of TCP and UDP probes with unusual flag combinations and payloads. These are often flagged by IPS signatures as suspicious. Enabling OS detection during a scan increases the likelihood of triggering the IPS, making it counterproductive for evasion. It should be avoided when trying to remain stealthy.

Use -A to enable aggressive scan options.

Why it fails: The -A flag enables OS detection, version detection, script scanning, and traceroute. This aggressive scanning generates a lot of traffic and uses many probes that IPS systems are designed to detect. It is the opposite of stealthy and would almost certainly trigger the IPS, leading to your IP being blocked.

Use -sV to enable version detection.

Why it fails: Version detection (-sV) sends additional probes to identify service versions, which increases the volume and variety of traffic. This can actually make the scan more conspicuous and more likely to trigger IPS signatures. It does not help evade detection; instead, it may increase the chance of being blocked by the IPS.

Increasing the number of threads to exceed the number of CPU cores

Why it fails: Setting more threads than available CPU cores leads to oversubscription and context switching, which can degrade performance. Hashcat is optimized to use available cores efficiently; exceeding them does not improve cracking speed and may even slow it down due to resource contention.

Using the --username option to ignore usernames during cracking

Why it fails: The --username option in Hashcat tells it to ignore the username field in the hash file, which is useful for parsing but does not affect the cracking efficiency. It neither expands nor reduces the candidate space, so it does not maximize efficiency in an offline attack.

Running a pure brute-force attack with all printable ASCII characters up to 12 characters

Why it fails: Pure brute-force over all printable ASCII up to 12 characters is computationally infeasible with current hardware, as the keyspace is enormous. It would take an impractical amount of time, making it an inefficient choice compared to targeted approaches like rules or masks that leverage known patterns.

Using a distributed cracking setup with multiple GPUs to increase hash rate.

Why it fails: Distributed cracking with multiple GPUs increases the overall hash rate, allowing more guesses per second. While this can speed up any attack, it does not inherently improve the chances of recovering passwords; it only reduces the time required for a given attack. The effectiveness still depends on the attack strategy, such as dictionary or rule-based methods. Without a smart approach, simply adding GPUs may not yield better results. Therefore, it is not one of the most effective techniques for maximizing recovery; it is an optimization, not a strategy.

Performing a brute-force attack with a mask that covers all possible 8-character combinations.

Why it fails: Brute-forcing all 8-character combinations is computationally intensive and often impractical, even with GPUs. While it can eventually find any password of that length, the time required is prohibitive for typical penetration test timeframes. NTLM hashes are fast to compute, but the sheer number of combinations (e.g., 95^8) is enormous. This approach is less effective than targeted dictionary or rule-based attacks, which focus on likely passwords. Therefore, it is not a recommended technique for maximizing recovery in a reasonable time.

Utilizing a precomputed rainbow table for NTLM hashes.

Why it fails: Rainbow tables can crack NTLM hashes quickly if the password is in the table, but they require massive storage and are limited to the specific character set and length covered. They are also defeated by salting, but NTLM hashes are unsalted, so they are technically feasible. However, rainbow tables are less effective than modern dictionary and rule-based attacks because they cannot adapt to new password patterns and are often outdated. For maximizing recovery in a dynamic environment, rule-based attacks are superior.

Increase the scan's maximum number of concurrent checks per host to speed up the scan.

Why it fails: Increasing concurrent checks can overwhelm fragile devices, causing them to crash or become unresponsive. This is especially risky for legacy systems and IoT devices with limited resources. The goal is to minimize disruption, so this action is counterproductive. It may also lead to false negatives if devices fail to respond.

Use a TCP SYN scan instead of a TCP connect scan to reduce the number of packets sent.

Why it fails: A TCP SYN scan is stealthier and sends fewer packets than a full connect scan, but it can still disrupt fragile devices if they cannot handle half-open connections. The primary concern is not the number of packets but the nature of the tests. SYN scans are not inherently safe for legacy systems; they can cause resource exhaustion or crashes.

Disable host discovery and scan all IP addresses in the range.

Why it fails: Disabling host discovery (e.g., using -Pn in Nmap) forces scanning of all IPs, including those that are not active. This generates unnecessary traffic and can probe devices that might be offline or fragile, increasing the risk of disruption. It does not help minimize impact on legacy systems; instead, it broadens the scan unnecessarily.