Scenario practice questions

Use nmap -sn 203.0.113.0/24 to discover which hosts in the mail subnet are alive.

Why it fails: A ping sweep sends ICMP or ARP probes directly to hosts in the subnet, making it an active technique that the target could log or alert on. It also requires knowing the correct subnet in advance, which the scenario has not established. While it would identify live hosts, it contradicts the explicit requirement to avoid sending packets to the target's servers, so it is the wrong choice here.

Run dig axfr @ns1.example.com example.com to transfer the full zone.

Why it fails: A zone transfer is an active query sent directly to the target's authoritative name server, which violates the passive-only constraint. Most servers also refuse AXFR from unauthorized clients, so the attempt would likely fail while still generating logs that reveal your interest. Even if it succeeded, the traffic would originate from your infrastructure and be attributable, which is precisely what passive reconnaissance avoids.

Perform a reverse DNS lookup against each IP in the target's announced BGP prefixes.

Why it fails: Reverse DNS queries are sent to the name servers responsible for the in-addr.arpa zones, which for the target's prefixes are typically operated by the organization or its provider. That traffic reaches infrastructure associated with the target, so it is not passive. It also returns only PTR records, which may not correspond to live mail hosts, making it both noisy and unreliable for this purpose.

Disable Windows Defender real-time protection by modifying the registry before executing the payload.

Why it fails: Modifying Defender registry keys requires elevated privileges and generates high-severity alerts in most EDR deployments, often triggering immediate response before the payload ever runs. The scenario specifies an EDR that is separate from Defender and performs behavioral monitoring, so tampering with Defender settings does not address the EDR at all. This approach increases visibility rather than reducing it.

Rename the payload executable to svchost.exe and place it in the user's temp directory.

Why it fails: Renaming a file does not change its contents, so static scanning still matches the payload bytes on disk. The behavioral layer also observes the actual behavior of the process regardless of its filename; invoking a binary named svchost.exe from a temp directory is itself a suspicious indicator that EDR products flag. This technique neither defeats static scanning nor reduces behavioral detection, making it ineffective here.

Compress the payload with UPX and deliver it as a self-extracting archive.

Why it fails: UPX is a well-known packer, and EDR and antivirus engines routinely unpack UPX-compressed binaries before scanning, so the original payload bytes are still analyzed. Self-extracting archives add another executable stage that behavioral monitoring can flag. Compression does not remove the static signature and does not change the runtime behavior that the EDR observes, so it does not address either control described in the scenario.

The user is automatically added to the root group.

Why it fails: The NOPASSWD tag only affects the authentication requirement for sudo. It does not change the user's membership in the root group. Group membership is managed through /etc/group, and being in the root group provides its own set of privileges independent of any sudo configuration directives.

The command is not logged by the system administrator.

Why it fails: NOPASSWD has no impact on logging. The sudo configuration does not affect whether actions are recorded. System administrators typically have separate logging mechanisms enabled, such as syslog or auth.log, which will still record the command execution regardless of whether a password was required for the session.

The command will run in a sandbox for security.

Why it fails: NOPASSWD does not imply any form of sandboxing or isolation. It is purely an authentication bypass mechanism. The command runs with the full privileges of the user specified in the sudoers entry, which is usually root, without any secondary security controls applied to the process execution.

Modify the /etc/shadow file directly.

Why it fails: Modifying /etc/shadow requires root privileges to begin with. Even if a cron job runs as root, the user running the script must have write permissions for the shadow file, which is rarely granted. This approach is technically impossible without already having obtained the necessary elevated permissions via another vector.

Restart the crond service to force execution.

Why it fails: Restarting system services generally requires root privileges that the attacker does not yet possess. Furthermore, simply restarting the service does not alter the underlying script's contents. The goal is to modify the logic of the scheduled task to execute arbitrary commands, not merely to trigger the existing task execution.

Change the ownership of the script using chmod.

Why it fails: The chmod command changes permissions, but it does not allow a user to change ownership unless they are already root. Even if permissions were changed, it would not automatically result in privilege escalation unless the file content was modified to perform an action that grants the user root access.

Chisel encrypts traffic only when the --tls flag is used, and otherwise sends plaintext over the wire.

Why it fails: Chisel secures the transport by default using TLS with a generated certificate, and the --tls flag controls whether the server requires a client certificate, not whether encryption is applied. Claiming plaintext by default mischaracterizes the tool's transport security and could lead to incorrect assumptions during an engagement.

The Chisel server must run on the compromised host so the client on your attacking machine can pull traffic from the internal network.

Why it fails: Running the server on the victim would require inbound connectivity to the compromised host, which the scenario says is unavailable. The client-server roles in Chisel are fixed by design: the client initiates the connection, so placing the server on the victim inverts the intended deployment and breaks the egress-only assumption.

Chisel requires a kernel TUN interface on both endpoints to carry the tunneled traffic.

Why it fails: Chisel operates at the application layer over HTTP or TLS and does not create TUN interfaces. It exposes SOCKS or fixed port forwards rather than a routed interface, so tools must be SOCKS-aware or wrapped with proxychains. Requiring TUN on both sides describes a different class of tunneling tool.

By performing a privilege escalation to modify the HKLM hive.

Why it fails: The beauty of COM Hijacking in HKCU is that it does not require administrative privileges or HKLM modification. The user has permission to write to their own HKCU hive by default. Modifying HKLM would be more difficult and more likely to be flagged by security software as a suspicious system-wide change.

By using the missing key to trigger a buffer overflow in the application.

Why it fails: COM Hijacking is a logic-based redirection attack rather than a memory corruption exploit. While a missing key might cause an error, it does not inherently provide a path to a buffer overflow. The goal here is to use the existing, legitimate functionality of the COM subsystem to load a malicious library.

By deleting the HKLM key to force the application to use HKCU.

Why it fails: The application already searches HKCU first by design; there is no need to delete the HKLM key. Furthermore, deleting keys in HKLM requires administrative privileges, which defeats the purpose of an evasion technique that is often used precisely because it can be implemented with standard user-level permissions in the HKCU hive.

Perform a cross-site scripting attack by injecting a script into the user details that are reflected back.

Why it fails: The endpoint returns JSON, which is typically not rendered as HTML. XSS requires the application to reflect user input into HTML context without proper encoding. Here, the vulnerability is unauthorized access to other users' data, not script injection. XSS would not demonstrate the IDOR impact.

Attempt to inject SQL payloads into the id parameter to extract the entire database.

Why it fails: The scenario does not indicate SQL injection; the endpoint returns JSON and likely uses an ORM. IDOR is about accessing objects without authorization, not about injecting SQL. Attempting SQL injection would be a different attack vector and may not be successful. The direct impact is unauthorized data access via ID enumeration.

Use the session cookie to perform a session fixation attack and hijack an administrator's session.

Why it fails: Session fixation requires the application to accept a session ID from the URL or a cookie set by the attacker, and then the victim to authenticate with that session. There is no indication of session fixation here. The vulnerability is that the endpoint lacks authorization checks, allowing access to any user's data by changing the ID.

Brute-force the base64-encoded cookie to discover the administrator's session identifier.

Why it fails: Brute-forcing is unnecessary because the cookie is not a random session ID; it is a predictable encoding of user ID and role. Decoding it immediately reveals the structure. Brute-force would be inefficient and unlikely to succeed without knowing the format, which is already known from the source code.

Use SQL injection on the login form to extract the administrator password hash.

Why it fails: While SQL injection is a common web attack, the scenario does not indicate a SQL injection vulnerability. The cookie is already decoded and shows a predictable structure. Attempting SQL injection would be a detour and may not be possible if input is properly sanitized. The direct path is cookie manipulation.

Perform a cross-site request forgery (CSRF) attack to change the administrator's password.

Why it fails: CSRF requires the victim to be authenticated and to visit a malicious page. Here, you are the attacker and already have a valid session cookie. CSRF would not help you escalate your own privileges because it targets another user's session. The vulnerability lies in the cookie's lack of integrity protection, not in CSRF.

Ensure the database user has FILE privileges to read data from the filesystem.

Why it fails: FILE privileges are needed for reading or writing files via SQL injection, but UNION-based extraction retrieves data from database tables, not the filesystem. The attack only requires SELECT privileges on the target tables. Requiring FILE privileges is a misconception; it is not a prerequisite for UNION attacks and would not help in extracting data from the database.

Use a time-based injection to confirm the vulnerability before attempting UNION.

Why it fails: Time-based injection is an alternative technique for blind SQL injection, but it is not required for UNION-based attacks. UNION attacks rely on visible output, so you can directly test for them by injecting a UNION SELECT and observing changes. Using time-based methods adds unnecessary complexity and may not be needed if the page reflects query results. This step is not necessary for UNION exploitation.

Encode the payload using base64 to bypass web application firewalls.

Why it fails: Base64 encoding is not a standard method for SQL injection bypass; it would alter the payload so the database does not interpret it as SQL. WAF bypass often involves obfuscation, comments, or alternate encodings, but base64 is not directly usable. This step is irrelevant to UNION-based extraction and would likely break the injection rather than help.

SafeSEH encrypts the JMP ESP instruction, making it unusable.

Why it fails: SafeSEH does not encrypt instructions. It maintains a table of valid exception handlers and checks them during exception handling. It has no effect on the JMP ESP instruction itself or its usability for return address overwrites.

You must use a POP POP RET sequence instead of JMP ESP to bypass SafeSEH.

Why it fails: POP POP RET is used to bypass SafeSEH when exploiting SEH overwrites, not return address overwrites. In a return address overwrite, you directly control EIP, so JMP ESP is appropriate. POP POP RET is irrelevant here unless you are targeting the SEH chain.

JMP ESP will not work because SafeSEH validates all addresses on the stack, including the return address.

Why it fails: SafeSEH validates exception handler addresses during exception dispatching, not the return address. The return address is used by the ret instruction, which is not checked by SafeSEH. Therefore, JMP ESP can still be effective if the module is not SafeSEH-protected.

Replay the captured token after changing only the payload `role` field to `admin`, keeping the original signature.

Why it fails: Modifying the payload invalidates the HMAC signature, so the server rejects the token. The whole point of the signature is to detect tampering with the header or payload. This option tests whether the candidate understands that JWT payloads are integrity-protected and cannot be edited without re-signing, which requires the secret.

Switch the header `alg` to `RS256` and sign the token with the server's public key as an HMAC secret.

Why it fails: The RS256-to-HS256 confusion attack requires the server to accept both algorithms and to use the public key as an HMAC secret, which is a specific misconfiguration not stated here. The scenario says the server uses a symmetric secret, so there is no public key to abuse. This technique is powerful but inapplicable without the asymmetric setup, making it a knowledgeable-sounding but wrong choice.

Change the header `alg` to `none` and remove the signature segment, then submit the token.

Why it fails: The `alg:none` attack only works if the server explicitly accepts unsigned tokens, which most modern libraries reject by default. Since the scenario says the server verifies with a symmetric secret, the library likely enforces a signing algorithm and will reject an unsigned token. This is a well-known but frequently patched misconfiguration, making it a plausible-sounding distractor rather than the most likely path.

Run a strings command on the vulnerable binary to list all characters that appear in the code.

Why it fails: strings lists printable sequences in a binary but does not indicate which bytes the program filters or mishandles at runtime. Bad characters depend on how functions like strcpy, scanf, or network parsing treat specific byte values. Static inspection cannot replace dynamic testing, where you observe actual memory contents after sending a crafted buffer.

Encode your shellcode with shikata_ga_nai and assume any remaining corruption is due to the encoder.

Why it fails: Encoding shellcode does not eliminate bad characters; the encoder's output may still contain bytes that the vulnerable function rejects. In fact, encoders often introduce null bytes or other problematic values. You must first identify bad characters empirically and then choose or customize an encoder that avoids them. Assuming the encoder is at fault without testing is guesswork.

Use a disassembler to check whether the binary contains any null bytes in its machine code.

Why it fails: Null bytes in the binary's own machine code are unrelated to which bytes your input can contain. The relevant question is how the vulnerable function processes your supplied data, not what instructions the compiler emitted. Disassembly may reveal calls to dangerous functions, but it does not enumerate runtime bad characters; dynamic testing is required.

The shellcode contains bad characters that were not filtered, causing it to be truncated.

Why it fails: Bad characters in shellcode can corrupt the payload, but if the shellcode were truncated, the JMP ESP would still execute, and the CPU would attempt to run the corrupted shellcode. The result might be a crash, but the scenario emphasizes that the JMP ESP address is accurate and offset is correct; the most likely cause is NX, not bad characters. Bad characters would typically be identified during testing.

The JMP ESP instruction address contains a null byte, which terminates the string copy.

Why it fails: A null byte in the JMP ESP address would prevent the address from being written correctly, likely causing EIP to be overwritten with a truncated value. However, the scenario states that the JMP ESP address is accurate and the offset is correct, so null bytes are not the issue. The crash is due to execution failure, not address corruption.

The offset to EIP was miscalculated, so the return address is overwritten with an incorrect value.

Why it fails: The scenario explicitly states that the offset is correct, so this cannot be the cause. If the offset were wrong, the JMP ESP address would not be placed at the return address, and EIP would not be controlled. Since the JMP ESP address is accurate, the offset must be correct. The failure is due to non-executable stack.

Remote Code Execution via file inclusion.

Why it fails: While LFI can lead to RCE, the example specifically illustrates arbitrary file reading. RCE requires the ability to execute the file contents, such as a malicious script injected via log poisoning, which is not described in this scenario. Focus on the direct manifestation of the vulnerability presented.

SQL Injection, allowing database schema enumeration.

Why it fails: SQL Injection involves manipulating database queries through input fields to extract or modify data. The provided scenario involves direct file system interaction, not database interaction. Path traversal vulnerabilities do not inherently provide access to database engines unless specific configuration files containing credentials are successfully retrieved.

Cross-Site Scripting, allowing session hijacking.

Why it fails: Cross-Site Scripting occurs when an application includes untrusted data in a web page without proper validation or escaping. This allows attackers to execute malicious scripts in the victim's browser. The described scenario involves backend file access, which is distinct from client-side execution flaws typical of XSS.

Wireshark

Why it fails: Wireshark is a packet capture and analysis tool. It can observe traffic on an interface but does not forward or proxy connections, and it certainly does not implement SOCKS. Using it on a pivot would only help with traffic analysis, not with routing your Kali tools into the segmented network.

Netcat

Why it fails: Netcat is a general-purpose networking utility for reading and writing data across TCP or UDP connections, often used for bind or reverse shells. It does not implement the SOCKS protocol, so it cannot act as a SOCKS proxy for your tools. While you can relay a single connection with netcat, it lacks the multiplexing and protocol handling needed for a functional proxy.

Nmap

Why it fails: Nmap is a port scanner and network mapping tool. Although it supports proxying its own scans through SOCKS4 proxies with the --proxies option, it cannot act as a SOCKS proxy server for other tools. The scenario requires a proxy service on the Windows pivot, which Nmap does not provide.