Practice Test #1

Incorrect. Pass-the-hash over SMB would use NTLM hashes rather than a plaintext password. In CME, PtH is typically performed by supplying hashes (e.g., --hashes or similar) instead of -p with a cleartext string. Since the command uses -p Summer123@, it is attempting standard authentication with a password, not replaying a captured hash.

Incorrect. Common protocol scanning refers to discovering open ports/services across hosts (e.g., using nmap or masscan). CrackMapExec is primarily for SMB/AD credential testing, enumeration, and post-exploitation workflows, not broad multi-protocol scanning. This command specifically targets SMB and attempts logons; it is not enumerating multiple protocols or doing port discovery.

Incorrect. Remote command execution with CME requires additional options such as -x (run a command) or -X (run PowerShell), and typically successful credentials with sufficient privileges. This command only supplies targets and credentials for authentication attempts; it does not include any execution flags or payloads, so it is not executing commands on endpoints.

Incorrect. This command runs nmap locally against <target_cidr> and then pipes nmap’s textual output into nc to port 22 on the compromised host. That does not cause the scan packets to traverse the compromised host, so it is not pivoting. It also attempts to send arbitrary text to an SSH port, which is not a meaningful “relay” for enumeration traffic.

Incorrect. This is a classic named-pipe netcat relay pattern, but as written it’s malformed (mknod syntax is wrong) and conceptually it creates a bidirectional relay for a single TCP flow, not a scalable pivot for enumerating an entire CIDR. It also mixes listening on 8000 with connecting to <target_cidr> on port 80, which doesn’t implement a general proxy for tools like nmap.

Incorrect. This attempts to chain netcat listeners/connectors and then scan 127.0.0.1:8000, but it doesn’t actually establish a pivot through the compromised host. There’s no step that places a proxy on the compromised host or forwards traffic through it. Additionally, nmap syntax is off (scanning “127.0.0.1 8000” is not a correct way to specify a port without -p).

Sidecar scanning is not a standard wireless reconnaissance or troubleshooting term in the PenTest+ context. It does not describe a recognized method for identifying whether an SSID is being broadcast on a particular RF channel. Because the problem is specifically about Wi-Fi network visibility, the tester needs a technique tied to 802.11 channel and beacon analysis. That makes this option a distractor rather than a practical troubleshooting approach.

Stealth scanning focuses on reducing the likelihood of detection during reconnaissance rather than improving the ability to find a wireless network. Even if a scan is performed quietly or passively, the core troubleshooting need is still to inspect the relevant wireless channels for beacon or probe-response traffic. The question asks for the most effective troubleshooting technique, not the least detectable one. Therefore, stealth scanning does not best address the SSID visibility problem.

Static analysis scanning is used to inspect source code, binaries, or applications without executing them. It is relevant to software security testing, not to wireless signal discovery or 802.11 management frame analysis. A missing SSID on a phone is a radio-frequency and wireless configuration issue, not a code-analysis problem. For that reason, static analysis scanning is clearly unrelated to the scenario.

URL spidering (crawling) maps a web application by following links and discovering endpoints. While it may trigger some DNS lookups initially (e.g., for new hostnames), most crawling stays within the same domain and primarily increases HTTP/HTTPS requests, not sustained high DNS volume. A major DNS spike is less consistent with spidering than with DNS tunneling behavior.

HTML scraping extracts content from web pages and APIs. Like spidering, it mainly drives HTTP/HTTPS traffic and application-layer load. DNS usage typically remains stable because the scraper repeatedly accesses the same hostnames after initial resolution. Scraping might increase bandwidth and web server logs, but it is unlikely to produce a substantial, ongoing increase in DNS traffic.

A DoS attack can increase DNS traffic if the DNS infrastructure is targeted (e.g., query floods, amplification). However, the scenario is a consumer-facing web application assessment and the observation is a DNS spike without mention of service outage. In PenTest+ context, a sustained DNS increase during an assessment more commonly indicates DNS tunneling/exfiltration than an overt DoS, which is often out of scope.

Database is not supported by the scan results. Common database ports (e.g., 1433 MSSQL, 3306 MySQL, 5432 PostgreSQL, 1521 Oracle) are not shown as open. While databases can be excellent targets, you should base your selection on observed services/ports. Here, the evidence points to SSH, RPC/NFS, and filtered SMTP—not a database service.

Remote access maps to SSH on 22/tcp. SSH can be a target if weak passwords, exposed keys, outdated daemons, or misconfigurations exist, but it typically requires authentication and is often well-hardened. Without additional findings (version vulnerabilities, credential reuse, default creds), SSH is usually less immediately fruitful than an exposed file-sharing service like NFS.

Email maps to SMTP on 25/tcp, but Nmap reports it as filtered. Filtered indicates a firewall/ACL is blocking probes or limiting connectivity, which reduces immediate attack options. Even when open, SMTP attacks often depend on specific server misconfigurations (open relay, vulnerable MTA versions, user enumeration). In this output, SMTP is not the best initial target.

Incorrect. PTES can be used for web application tests just as well as for network or internal tests; it describes phases and deliverables, not a web-specific approach. DREAD is also not inherently web-specific. The deciding factor between DREAD and PTES is whether you need threat/risk scoring (DREAD) versus a full testing methodology (PTES).

Incorrect. Mobile application assessments may use specialized techniques (reverse engineering, device security checks, API testing), but that does not make DREAD preferable to PTES. PTES remains a general engagement framework. DREAD would only be chosen here if the goal is to score and prioritize mobile threats, not simply because the target is mobile.

Incorrect. Thick client testing involves different attack surfaces (local storage, IPC, update mechanisms, client-server protocols), but PTES still applies as the overarching process. DREAD is not a thick-client methodology; it is a threat rating model. Platform type does not determine DREAD vs PTES; the need for threat prioritization does.

Reducing file permissions is not the best prevention for XXE. /etc/passwd is typically world-readable and changing its permissions can break system functionality. More importantly, XXE is a parser configuration flaw; even if file reads are restricted, attackers may still exploit XXE for SSRF (accessing internal web services/metadata endpoints) or other data exposures. Least privilege helps limit impact but does not remove the vulnerability.

Frequent log review is a detection/monitoring control, not a preventive control. It may help identify exploitation attempts after the fact, but it does not stop the XML parser from resolving external entities and disclosing data. For exam questions asking how to best prevent the vulnerability type, choose a control that removes the root cause (unsafe XML parsing) rather than an operational process.

A WAF can sometimes detect and block obvious XXE payloads, but it is not the best prevention. XXE can be obfuscated or encoded to bypass signatures, and WAF rules vary widely. The underlying issue remains an insecure XML parser configuration. WAFs are best treated as defense-in-depth, not the primary fix for XXE.

Port mirroring (SPAN) is a wired switch feature that copies traffic from one or more ports/VLANs to a monitoring port for packet capture. It helps with visibility and troubleshooting on Ethernet networks, not with assessing RF channel usage or the ability to disrupt Wi-Fi communications. It does not directly enable wireless disruption testing and typically requires switch access/authorization.

Sidecar scanning generally refers to using an auxiliary device or sensor (a “sidecar”) to perform scanning/monitoring without impacting the primary system, or to gain an alternate vantage point. While it can be used for reconnaissance, it is not the specific technique for determining which Wi-Fi channels are in use or evaluating channel-based disruption/jamming feasibility.

ARP poisoning (ARP spoofing) is a Layer 2 man-in-the-middle technique used to redirect traffic on a local network by corrupting ARP tables. It can disrupt communications by causing misrouting, but it requires the attacker to be on the same broadcast domain and typically already associated to the network. It does not directly address wireless RF disruption and is not the best fit for “disrupt wireless communications” in the channel/interference sense.

Shoulder surfing is a physical social-engineering technique used to observe credentials or sensitive information directly from a victim’s screen/keyboard. It is not typically the first step in developing a spear-phishing campaign because it requires physical proximity, increases risk of detection, and is more aligned with onsite assessments. Phishing campaigns usually begin with passive OSINT to build pretexts and target lists.

Recon-ng is a reconnaissance framework that automates OSINT collection (domains, contacts, hosts, breaches, etc.). While useful during recon, it’s not the best “first” action when developing a spear-phishing campaign because you first need to identify targets and context. Social media OSINT often provides the initial targeting and pretext details that then feed tools like Recon-ng.

Password dumps are collections of credentials typically obtained from breaches, dark web sources, or post-exploitation. They are not a first step for creating a phishing campaign and may be out of scope unless explicitly authorized. Even when allowed, they are usually used later for credential stuffing or validation, not for initial pretext development.