Refer to the Exhibit 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.

Only users explicitly assigned via Microsoft Entra ID Enterprise Applications can authenticate and access the application.

Why it fails: A false value means assignment is not enforced, so any user in the tenant can authenticate to the application without explicit assignment. The option inverts the logic: assignment enforcement is exactly what 'true' provides. Requiring explicit Enterprise Application assignment is tempting because it is the hardened configuration, but it is not what this setting produces.

The application is prohibited from utilizing OAuth 2.0 authorization code flows and must rely exclusively on client credentials.

Why it fails: The setting controls assignment enforcement only; it does not restrict which OAuth 2.0 grant types an application may use. Authorization code and client credentials flows remain independently configurable. The option is tempting because both concern application access control, but the actual axis here is user assignment, not grant-type restriction.

Global administrators must manually approve every single sign-in attempt generated by standard users in the tenant.

Why it fails: 'appRoleAssignmentRequired' governs whether user assignment is enforced before authentication; it does not insert a global administrator approval step into each sign-in. The tempting misconception is that tighter control equals admin gating, but no such per-sign-in approval mechanism exists in Microsoft Entra ID enterprise application configuration.

To reduce the CPU overhead on the infected host.

Why it fails: Reducing CPU overhead is typically managed through efficient coding practices or long sleep intervals rather than randomizing the timing. While jitter affects when the code executes, its technical intent is to obfuscate traffic patterns, not to optimize performance or resource consumption on the target system.

To synchronize beaconing across multiple infected hosts.

Why it fails: Jitter is explicitly designed to desynchronize beaconing. If all hosts were synchronized to check in at the exact same moment, it would create a massive spike in traffic that is easily identified by network monitors. Synchronization is generally avoided by attackers to minimize the risk of detection.

To increase the throughput of the C2 channel.

Why it fails: Jitter has no impact on throughput or the data transmission rate. Throughput is determined by the payload size, the number of check-ins, and the available bandwidth of the network connection. Jitter only affects the timing of the connection attempts, not the volume of data transferred during those attempts.

Run a brute-force password attack against the server.

Why it fails: Brute-forcing should not be the immediate next step. Exploiting known software vulnerabilities discovered via banner grabbing is generally more effective and less noisy than credential stuffing. Relying on software flaws is a more precise approach that requires less time and minimizes the risk of account lockouts.

Immediately deploy a rootkit on the server.

Why it fails: Deploying a rootkit without initial access or a confirmed vulnerability is impossible. Rootkits require existing administrative or system-level access to install. A tester must first identify a vulnerability and successfully exploit it before considering post-exploitation persistence mechanisms like rootkits, which are highly invasive and easily detected.

Close the connection and report the server as secure.

Why it fails: The presence of a specific version number is a potential information disclosure vulnerability itself, and certainly not an indication of security. Assuming a server is secure just because it responds correctly is dangerous, as many services with known vulnerabilities appear to function normally until exploited.

The application is secure from buffer overflow attacks.

Why it fails: The output proves the opposite; it shows that an input was able to overwrite the return address, causing a crash. This is a definitive confirmation of a buffer overflow vulnerability. The application is clearly not secure, as the execution flow was successfully intercepted and manipulated by the input.

The system is protected by DEP/NX.

Why it fails: The segmentation fault is a result of the processor attempting to execute code from an invalid memory address ('AAAA'), not because of a DEP/NX violation. DEP/NX would typically cause a crash only if the payload reached the execution stage; here, the crash is due to an invalid pointer.

The payload is too large for the allocated buffer.

Why it fails: While the payload did overflow the buffer, the key insight is not the size, but the control of the instruction pointer. A smaller payload could still trigger this crash if the bytes are positioned correctly. The focus should be on the overwrite capability, not just the volume of data.

The C2 server is unreachable due to a network outage.

Why it fails: A network outage would typically result in a connection timeout, 'connection refused', or 'no route to host' error. This specific error message indicates that the TCP connection was established and the SSL handshake process actually began, but failed during the authentication phase of the TLS negotiation.

The C2 server is performing a man-in-the-middle attack.

Why it fails: While this error could occur in a man-in-the-middle scenario, the error code implies that the client is the one rejecting the certificate. If the C2 server were the one attacking, it would likely be the client's own certificate that fails or a mismatch in the expected cipher suites.

The C2 server has exhausted its connection limit.

Why it fails: Connection limits are typically enforced at the network or application layer, resulting in '503 Service Unavailable' or TCP resets. A TLS-specific alert regarding an 'unknown CA' is strictly related to the cryptographic handshake and identity verification process, not the server's available resource capacity or connection load.

Increase the timing template to -T5 to make the scan faster.

Why it fails: Increasing the timing template to -T5 focuses on speed and often causes missed packets or dropped connections due to congestion. It does not improve the accuracy of script-based directory enumeration and could lead to server-side rate limiting that blocks the scanner entirely.

Add the --script-args='http-enum.basepath=/admin' argument to the command.

Why it fails: Specifying a basepath forces the script to search only from that specific directory, which likely misses all other common locations. This narrows the scope incorrectly, as the goal is to discover unknown directories rather than verify a known one through brute-force enumeration.

Change the scan to -sS to perform a stealthy SYN scan instead of service detection.

Why it fails: An -sS scan performs port discovery but does not interact with the web server application layer. Since the goal is to identify directories, which are an application-level concern, switching to a transport-layer SYN scan will provide less information about the web application structure.

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.

Continue testing until you have fully compromised the system.

Why it fails: Continuing the test after the agreed-upon hours violates the 'Testing_Time' constraint. This is a breach of the contract and the Rules of Engagement. The tester must stop all activities immediately to remain within the authorized operational window and avoid potential conflicts with the client's scheduled maintenance or monitoring.

Wait until 08:00 the next day to report the vulnerability.

Why it fails: A critical vulnerability requires immediate attention. Waiting until the next day to report it ignores the urgency of the finding and the potential risk to the client's infrastructure. The established 'Escalation' procedure should be used to report the issue as soon as possible, regardless of the testing hours.

Run a full vulnerability scan on the remaining hosts to finish early.

Why it fails: Running additional scans outside the 'Testing_Time' window is a violation of the RoE. The tester must strictly adhere to the operational windows defined in the configuration. Furthermore, running unauthorized scans after hours can disrupt system backups or batch processing that typically occur during these times.

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

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

The value represents the plaintext password in hex format.

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

The session has expired and the hash is now unusable.

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

Attempt to restart the system to reset privileges.

Why it fails: Restarting the system is counterproductive and likely to cause a loss of the current session. It does not reset privileges in a way that helps the tester; instead, it alerts administrators and potentially removes the temporary access that the tester has already achieved on the compromised host system.

Disable the privilege to ensure system stability.

Why it fails: A penetration tester's objective is to demonstrate risk, not to improve system stability or remediate vulnerabilities. Disabling the privilege would prevent further testing and would not align with the goal of identifying exploitable pathways for privilege escalation within the scope of the assigned security assessment engagement.

Install a rootkit to hide the enabled privilege.

Why it fails: Installing a rootkit is generally out of scope for most professional penetration tests and could lead to system instability or detection. The goal is to document the risk associated with the enabled SeDebugPrivilege, not to modify the system in a way that risks permanent damage or excessive noise.

TCP Connect Scan (-sT)

Why it fails: The TCP connect scan relies on the operating system's connect system call to complete the three-way handshake. Because this fully establishes a connection, it is easily logged by application servers and security appliances, making it distinct from the stealth-focused SYN scan that leaves connections incomplete at the target.

UDP Scan (-sU)

Why it fails: UDP scanning is used to identify services running on the UDP protocol, such as DNS or DHCP. The output provided shows only TCP ports (22, 80, 443), and the state 'open' for UDP is determined by different logic, such as waiting for a response that rarely occurs.

TCP ACK Scan (-sA)

Why it fails: The ACK scan is used to map out firewall rulesets rather than identifying open ports. It does not produce an 'open' state in the same manner as a SYN scan, as it is designed to determine if ports are filtered or unfiltered based on the RST packet response behavior.

To increase the speed of the port discovery phase.

Why it fails: NSE scripts do not increase the speed of port discovery. In fact, they often slow down the scan because they require additional time to interact with the service after it has been identified as open. The primary benefit of NSE is depth of information, not speed of discovery.

To bypass firewalls by using script-based obfuscation.

Why it fails: NSE scripts are not designed for firewall obfuscation. While some scripts might be used to test for specific vulnerabilities, the engine itself does not provide features to hide traffic or bypass network access controls, which is the role of other Nmap flags like decoys or timing templates.

To convert TCP scans into more reliable UDP scans.

Why it fails: The NSE is entirely unrelated to the underlying transport protocol. It cannot change a TCP scan into a UDP scan, nor does it affect the reliability of UDP scanning. It operates independently of the transport layer to provide high-level application data once a connection is successfully established.

The RHOSTS value is configured incorrectly

Why it fails: The RHOSTS value is clearly set to the target IP address. The scanner successfully connected to that IP and confirmed the vulnerability. Therefore, the connection is not the issue; the failure resides within the exploit payload's interaction with the target's specific system state during the final execution phase.

The exploit module requires an active session

Why it fails: Exploit modules like EternalBlue are designed to create the initial session, not rely on existing ones. Requiring an active session before running this module is illogical. The error message indicates a failure to trigger the vulnerability, which is a common occurrence with complex memory-corruption exploits in production environments.

The listener port is already in use by another process

Why it fails: If the listener port were in use, Metasploit would throw a specific socket binding error immediately upon starting the exploit. The output shows the listener started successfully, meaning the conflict is not with the local network configuration but with the target's response to the exploit attempt itself.

Execute the SQL injection to prove the vulnerability exists.

Why it fails: Executing an exploit that causes a database lock-up directly violates the 'Forbidden_Attacks' clause regarding DoS. Even if the intent is to prove the vulnerability, the resulting service interruption is unacceptable under the provided policy, and the tester would be liable for the resulting business impact.

Attempt the exploit on the excluded host 192.168.10.50 to see if it is vulnerable.

Why it fails: The host 192.168.10.50 is explicitly listed in the 'Exclusions' field of the policy. Any interaction with this host, regardless of the vulnerability detected, constitutes a breach of the scope, which can lead to significant legal and professional repercussions for the testing team and the firm.

Extend the testing window to allow for a safer, non-disruptive exploit.

Why it fails: Extending the testing window without explicit written approval from the client is a violation of the project constraints. The methodology and timeline must be strictly followed, and modifying them unilaterally is unprofessional. The priority should always be reporting the finding within the constraints defined in the policy.