Scenario practice questions

The port is definitely open but the response was malformed.

Why it fails: The 'open|filtered' state does not mean the port is definitely open. It indicates ambiguity. Nmap simply cannot distinguish between a dropped packet (filtered) and a port that is open but not responding to the specific probe used. The data remains inconclusive for the tester.

The port is likely closed and the firewall is silently dropping traffic.

Why it fails: If the port were closed, Nmap would likely receive an RST packet or an ICMP unreachable message, labeling it as 'closed'. The 'open|filtered' result specifically points to a lack of response, which is a common symptom of a firewall that silently discards traffic without sending any denial packets.

The port is definitely filtered and the service is unreachable.

Why it fails: Nmap only labels a port as 'filtered' if it receives an ICMP port unreachable message or if it is very sure the firewall is dropping traffic. 'Open|filtered' is reserved for when the status is genuinely unknown due to a complete lack of response from the target host's port.

Reconnaissance

Why it fails: Reconnaissance involves gathering information about the target environment to identify potential attack vectors. This stage focuses on intelligence gathering rather than direct engagement with vulnerabilities, making it distinct from the actual execution of malicious payloads that manipulate server behavior during the exploitation phase of testing.

Vulnerability Assessment

Why it fails: Vulnerability assessment focuses on identifying and classifying security weaknesses within a system, network, or application. It is primarily a scanning and discovery process that does not involve executing payloads to gain unauthorized control or performing active exploitation to verify the existence of specific technical security vulnerabilities.

Post-Exploitation

Why it fails: Post-exploitation occurs after initial access has been successfully established. It involves activities like lateral movement, privilege escalation, and data exfiltration. While the goal is to deepen control, the initial execution of a command is considered the act of exploitation itself, not the subsequent follow-up actions.

Use the SMTP VRFY command against the organization's MX host for each candidate address

Why it fails: The SMTP VRFY command asks a mail server to confirm whether a mailbox exists, but most modern mail servers disable or obfuscate VRFY responses to prevent address harvesting. Sending VRFY commands to the target's MX host also constitutes direct interaction with target infrastructure, which the scenario seeks to avoid. This method is therefore both unreliable and non-passive.

Perform a DNS MX lookup for the domain and assume any address at that domain is valid

Why it fails: An MX lookup only confirms that the domain can receive mail; it says nothing about whether a specific mailbox exists. Assuming every candidate address is valid would produce many false positives and waste effort in later phishing or credential-testing phases. This technique does not verify individual addresses, so it fails to meet the scenario's goal of validating the generated list.

Send a test message to each candidate address and monitor for bounce-backs

Why it fails: Sending test messages directly to candidate addresses delivers email to the target's mail infrastructure, which the scenario explicitly forbids. It also risks tipping off the organization and may violate rules of engagement. Bounce-back analysis is slow, noisy, and unreliable because many servers silently drop invalid recipients, so this approach is unsuitable here.

John the Ripper

Why it fails: John the Ripper is a password cracking tool, similar to Hashcat. It is used to crack hashes, not to extract them from SAM files. While it can process SAM files with the appropriate format, its primary function is cracking, not extraction. The tester would need to use an extraction tool first, then John could be used to crack the extracted hashes.

Mimikatz

Why it fails: Mimikatz is primarily used for extracting credentials from memory, such as LSASS, and for performing attacks like Pass-the-Hash and Golden Ticket. While it can dump SAM hashes with the lsadump::sam command, it is not specifically designed for offline SAM file extraction; it operates on a live system. Other tools are more focused on parsing SAM files offline.

Hashcat

Why it fails: Hashcat is a password cracking tool, not an extraction tool. It takes hashes as input and attempts to recover plaintext passwords. It cannot extract hashes from a SAM file; it requires the hashes to be already extracted. In this scenario, the tester needs to first extract the hashes from the SAM file, then could use Hashcat to crack them.

Hashcat mode 3000

Why it fails: Mode 3000 is for LM hashes, an older and weaker hash format. LM hashes are not the same as NTLM hashes and have a different structure and length. Using mode 3000 for NTLM hashes will not yield correct results because the algorithms differ. The tester must select the mode that matches the hash type to ensure successful cracking.

Hashcat mode 5500

Why it fails: Mode 5500 is for NetNTLMv1 hashes, which are challenge-response hashes used in network authentication. NTLM hashes are different; they are the raw MD4 hashes of passwords stored locally. Using mode 5500 on NTLM hashes will not work because the hash formats and algorithms are incompatible. The tester would not be able to crack the hashes correctly with this mode.

Hashcat mode 5600

Why it fails: Mode 5600 is for NetNTLMv2 hashes, which involve a challenge-response mechanism. NTLM hashes are not challenge-response; they are simple MD4 hashes. Therefore, mode 5600 is incorrect for cracking NTLM hashes. Attempting to use it would result in parsing errors or failure to crack, as the hash structure does not match the mode's requirements.

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.

Golden Ticket attack using the KRBTGT hash

Why it fails: A Golden Ticket requires the KRBTGT account's NTLM hash to forge a Kerberos TGT, granting domain-wide access. While it uses an NTLM hash, it is not a Pass-the-Hash technique and requires the KRBTGT hash specifically, not a user's hash. It is used for persistence and privilege escalation, not for simple authentication with a user's hash.

Kerberoasting to request a service ticket

Why it fails: Kerberoasting targets service accounts with SPNs to obtain a service ticket encrypted with the service account's NTLM hash, which is then cracked offline. It does not allow direct authentication using an NTLM hash. This technique requires a different set of privileges and is used to escalate privileges or move laterally, not to authenticate with a stolen hash directly.

Rainbow table lookup to recover the plaintext password

Why it fails: Rainbow tables are precomputed hash chains used to crack unsalted password hashes offline. They do not enable authentication; they recover the plaintext password, which can then be used for authentication. This is a cracking method, not a direct authentication technique, and it requires significant storage and time, and is ineffective against salted hashes.

Pass-the-Ticket by injecting a forged Kerberos TGT into memory

Why it fails: Pass-the-Ticket involves stealing or forging a Kerberos ticket and injecting it into a session to authenticate. It requires a valid TGT or TGS, not an NT hash. While it can achieve lateral movement, it is a different attack path that depends on Kerberos artifacts, not the SAM hash. The scenario supplies an NT hash and asks for direct authentication, so Pass-the-Ticket is not the appropriate technique.

Kerberoasting the target service account to obtain its TGS ticket

Why it fails: Kerberoasting targets service accounts with registered SPNs by requesting a TGS ticket and cracking it offline. It does not use an NT hash from SAM and does not provide immediate authentication to a file share. This technique is used to escalate privileges or move laterally by cracking service account passwords, but it is unrelated to the extracted NT hash. The scenario already provides a credential; Kerberoasting would be an unnecessary detour.

Rainbow table lookup against the NT hash to recover the plaintext password

Why it fails: Rainbow tables map precomputed hash chains to plaintext passwords, but they only work if the hash is unsalted and the table covers the password space. NT hashes are unsalted, so rainbow tables are feasible, but they do not directly authenticate to a remote server. The scenario asks for authentication to a file share, not password recovery, so a rainbow table lookup is the wrong objective. It also requires significant storage and time, making it impractical for immediate access.

-sS

Why it fails: The -sS option initiates a TCP SYN scan, which is a port scanning technique. It sends SYN packets to target ports and analyzes responses. This directly contradicts the requirement to avoid port scanning and reduce TCP SYN noise. While it is stealthy compared to a full connect scan, it still performs port scanning and generates SYN traffic.

-sP

Why it fails: The -sP option is an older alias for -sn in some Nmap versions, but it is deprecated. In modern Nmap, -sn is the correct flag for ping scan. Using -sP may not be recognized or may behave unexpectedly, and it is not the recommended way to perform host discovery without port scanning.

-Pn

Why it fails: The -Pn option skips host discovery and treats all hosts as online, then proceeds to port scan them. This is the opposite of what is needed: it performs port scanning and assumes hosts are up, which can generate significant traffic and false positives. It does not help identify live hosts without port scanning.

Hashcat mode 5500

Why it fails: Mode 5500 is used for NetNTLMv1 hashes, which use a weaker challenge-response mechanism. NetNTLMv2 incorporates a variable client challenge and HMAC-MD5, requiring a different cracking approach. Specifying mode 5500 for a NetNTLMv2 hash will not correctly parse the input and will fail to crack the password, as the algorithms do not match.

Hashcat mode 1000

Why it fails: Mode 1000 is for NTLM hashes, which are unsalted MD4 hashes of the password. NetNTLMv2 is a challenge-response protocol that includes a server challenge and client response, making it incompatible with mode 1000. Attempting to crack a NetNTLMv2 hash with mode 1000 will result in an error or no matches because the hash structures are fundamentally different.

Hashcat mode 3000

Why it fails: Mode 3000 is for LM hashes, an outdated and weak hashing algorithm. LM hashes are not used in NetNTLMv2 authentication and have a completely different structure. Using mode 3000 on a NetNTLMv2 capture will not work because the hash format is incompatible, and the cracking process will not yield the correct password.

Install a service on a domain controller that runs as Local System and starts automatically.

Why it fails: A new service on a domain controller is a noisy, on-disk artifact. Service creation events (7045) are commonly monitored, and the binary must be present and may be scanned by antivirus or EDR. It also does not inherently survive a Domain Admin password reset, and it lacks the stealth and no-disk-footprint properties required by the scenario.

Create a new user account with Domain Admin membership and hide it from the default Users container.

Why it fails: A new Domain Admin account is a high-visibility artifact. Account creation events (4720) and privileged group changes (4728) are logged by default on domain controllers and easily caught by SIEM rules or periodic access reviews. It also does not survive a thorough review and is not stealthy, failing the requirement to avoid obvious domain-level persistence.

Add an ACL to the Domain Admins group granting Full Control to a controlled user account.

Why it fails: Modifying the Domain Admins ACL is a persistent directory change that can be detected by ACL monitoring tools or a directory-sync review. While it may survive password resets, it is not stealthy and is an on-disk directory artifact. It also requires the controlled account to remain enabled, which is a clear indicator of compromise during a security audit.

John the Ripper

Why it fails: John the Ripper is a password cracker similar to Hashcat. It does not have the capability to parse memory dumps or extract credentials from them. Its primary function is to crack password hashes from various sources. In this scenario, it would be used after extraction, not for the extraction process itself. Thus, it is not the correct choice.

Hashcat

Why it fails: Hashcat is a password cracking tool that operates on captured hashes, not a memory forensics tool. It cannot extract credentials from a memory dump. While it can crack hashes obtained from memory, it does not perform the extraction itself. Therefore, Hashcat is not the correct tool for extracting credentials directly from the memory dump.

Volatility

Why it fails: Volatility is a memory forensics framework used to analyze memory dumps for artifacts like processes, network connections, and registry keys. While it can be used to locate LSASS process memory, it does not natively extract plaintext passwords or hashes; plugins like mimikatz are often used with Volatility for that purpose. Therefore, Volatility alone is not specifically designed to extract credentials in the way described.

Rainbow table attack

Why it fails: A rainbow table attack uses precomputed tables of password hashes to crack hashes quickly. While it is an offline attack, it is specific to cracking hashed passwords, not challenge-response pairs. Challenge-response protocols often use salts or nonces, making rainbow tables ineffective. Therefore, this is not the correct description of the attack.

Credential stuffing

Why it fails: Credential stuffing involves using previously breached username/password pairs to gain unauthorized access to other systems. It does not involve offline cracking of challenge-response pairs. The scenario describes an offline attack against captured authentication traffic, which is distinct from credential stuffing. Thus, this is not the correct answer.

Pass-the-Hash

Why it fails: Pass-the-Hash is an attack that uses a captured NTLM hash to authenticate without knowing the plaintext password. It does not involve cracking challenge-response pairs offline. In this scenario, the goal is to crack the response to recover the password, not to replay a hash. Therefore, Pass-the-Hash is not applicable.

The Golden Ticket can be used to authenticate to any service in the domain without additional tickets.

Why it fails: While a Golden Ticket grants a TGT that can be used to request service tickets, it does not directly authenticate to services without obtaining service tickets first. The effectiveness here is due to the long password age, not the ticket's ability to bypass service ticket requests.

The KRBTGT account has a weak password that can be brute-forced.

Why it fails: The scenario states you extracted the KRBTGT hash, implying you already have it; brute-forcing is unnecessary. The primary reason for effectiveness is the long password age, which means the hash remains valid, not the strength of the password itself.

The Golden Ticket is automatically renewed by the domain controller, extending its validity.

Why it fails: Golden Tickets are not automatically renewed by the domain controller; they are forged with a specific lifetime. The domain controller does not extend the lifetime of a forged ticket. The persistence relies on the KRBTGT hash remaining unchanged, not on automatic renewal.

SMTP beaconing

Why it fails: SMTP beaconing uses email protocols to communicate, typically over TCP port 25 or 587. These ports are not mentioned as allowed; only DNS is permitted. SMTP would be blocked by the egress filter. Even if allowed, it would require an external mail server, which may not be reachable. This does not fit the restricted DNS-only environment.

ICMP tunneling

Why it fails: ICMP tunneling uses ICMP echo requests and replies to carry data. However, the network only allows outbound DNS queries to a specific resolver, so ICMP traffic is likely blocked. ICMP is often restricted in secure networks, and the scenario does not mention it being allowed. Therefore, this technique would not be viable here.

HTTPS beaconing

Why it fails: HTTPS beaconing requires outbound TCP port 443, which is likely blocked in this restricted network that only allows DNS. Even if HTTPS were allowed, the scenario specifies only DNS queries to an internal resolver are permitted. Thus, HTTPS would not work without additional egress rules. It does not meet the constraint of the environment.

Use a DNS TXT record to store commands, and have the compromised host poll a public DNS server directly on UDP 53, bypassing the internal resolver.

Why it fails: The network only permits outbound DNS to an internal resolver, not directly to public DNS servers. Attempting to bypass the internal resolver would likely be blocked by egress firewall rules. Additionally, using TXT records for command polling does not provide interactive shell access and lacks the robustness of a full tunneling protocol. This approach would fail due to network restrictions.

Use a reverse TCP Meterpreter payload over port 443 with TLS, and rely on the firewall's deep packet inspection to allow it as HTTPS.

Why it fails: The scenario states that only outbound DNS (UDP 53) to an internal resolver is permitted. A reverse TCP connection on port 443 would be blocked by the firewall because it is not DNS traffic. Even if TLS is used, the firewall rules explicitly restrict outbound traffic to DNS only. This option violates the network constraint and would fail to establish a channel.

Use an ICMP tunnel such as ptunnel to encapsulate shell traffic in echo requests, and configure a registry run key for persistence.

Why it fails: While ICMP tunneling can bypass some filters, the scenario explicitly states that only outbound DNS (UDP 53) is allowed. ICMP is a different protocol and would be blocked by the firewall. Therefore, an ICMP tunnel would not work in this environment. The registry run key for persistence is plausible, but the primary channel is invalid.

A world-readable configuration file that contains database credentials.

Why it fails: A world-readable configuration file with database credentials may provide access to the database, but it does not directly escalate privileges on the local system. You might be able to pivot to other systems or extract sensitive data, but it does not grant root access on the current host. This is an information disclosure issue, not a direct privilege escalation vector. It is less likely to lead to local privilege escalation.

A world-writable file in /etc/ that is not used by any service or cron job.

Why it fails: A world-writable file in /etc/ that is not used by any service or cron job may seem dangerous, but if nothing reads or executes it, modifying it has no effect. It does not lead to privilege escalation because no privileged process consumes it. It could be a security misconfiguration, but without a mechanism to trigger its use, it is not an escalation vector. This is a distraction.

A directory with permissions 755 owned by root, containing a script that is executed by root.

Why it fails: A directory with permissions 755 owned by root means that only root can write to it. Even if it contains a script executed by root, you cannot modify the script or create new files in the directory. Therefore, you cannot influence its execution. This scenario does not provide a means to escalate privileges because you lack write access to the directory or the script.

Monitor the domain controller's event logs for lockout events (e.g., Event ID 4740) to detect when the lockout threshold is being approached and adjust your attack accordingly.

Why it fails: Monitoring lockout events is a detection technique for defenders, not a best practice for attackers. While an attacker might check for lockouts indirectly, actively monitoring event logs requires access that a typical external attacker does not have. Moreover, it does not prevent lockouts; it only observes them. The goal is to avoid lockouts proactively through pacing and password selection.

Attempt all passwords in your list against a single account before moving to the next account to quickly identify which account has a weak password.

Why it fails: Trying multiple passwords against a single account is a brute-force attack, not spraying. This will quickly lock out the account if the lockout threshold is low. Password spraying aims to avoid lockouts by distributing attempts across accounts. Therefore, this practice is counterproductive and risky in an Active Directory environment with lockout policies.

Use a single password for all accounts and attempt it simultaneously across all accounts using multiple threads to maximize speed.

Why it fails: Using multiple threads to attempt the same password across all accounts simultaneously can trigger lockouts if the lockout threshold is low or if the attempts are counted per account. While spraying often uses one password at a time, doing so concurrently without delays can still cause lockouts due to rapid failed attempts. Proper spraying requires careful timing, not just parallelization.

The SMB credentials provided are incorrect

Why it fails: If the credentials were incorrect, the error message would typically be 'Access Denied' or 'Authentication Failed'. A 'Connection reset by peer' implies the connection was successfully established but then terminated, which points towards a security control or network device actively killing the session rather than a simple authentication rejection.

The listener port is blocked by the target firewall

Why it fails: If the listener port were blocked on the host, the exploit might hang or time out while trying to establish the reverse shell, but it wouldn't necessarily reset the SMB connection during the authentication phase. The reset occurs during the initial SMB handshake, suggesting the target's SMB service is the culprit.

The payload architecture does not match the target

Why it fails: A payload mismatch would cause the exploit to succeed in uploading but fail when attempting to execute the binary. The error here occurs during the initial phase where the exploit tries to gain access via SMB, meaning the payload has not yet been executed on the target's operating system.