Select Two (Multi-Select) Questions

Verify the use of HTTPS

Why it fails: HTTPS verification is a transport-layer control that protects data in transit but does not reveal application-layer flaws in source code. The session's confidentiality relies on the server or proxy configuration and TLS termination, which are rarely visible in the application's code itself. Even with HTTPS enforced, injection vulnerabilities and hardcoded secrets remain fully exploitable, so this check would not satisfy the goal of identifying credential misuse or unsafe input handling.

Check for proper session timeout implementation

Why it fails: Session timeout enforcement is a session management control, not a code-level check for credential exposure or unsafe input handling. While a missing timeout can increase risk of session hijacking, it does not directly address hardcoded secrets, injection vectors, or unsafe function calls that this review intends to find. Moreover, timeout values are frequently configured in application properties or server settings, making them less discoverable and less relevant when focusing on source code patterns for injection and credential leaks.

Local administrator privileges on the target

Why it fails: Kerberoasting does not require local administrator privileges on any target host. The attack is performed entirely from an authenticated domain user context over the network, requesting service tickets via the Kerberos protocol and then cracking them offline. Local admin would be needed for other post-exploitation techniques like DCSync or credential dumping, but it is not a precondition for Kerberoasting.

Plaintext password of the service account

Why it fails: If the tester already possessed the plaintext password of the target service account, Kerberoasting would be unnecessary because the goal is to crack the password from the TGS ticket. The attack specifically exploits the fact that the ticket exposes a password-derived encryption key to offline cracking; having the password in advance defeats the purpose and is not required to perform the attack.

Gobuster

Why it fails: Gobuster is an active brute-force tool used primarily to discover hidden web directories and files by sending a high volume of HTTP requests to the target web server. While it can also enumerate DNS subdomains, every request goes directly to the target's infrastructure, generating network traffic that can be logged or detected by a WAF or IDS. Because it actively interacts with the target and does not consult third-party OSINT sources, it is unsuitable for passive reconnaissance or gathering employee/email details.

Nmap

Why it fails: Nmap is a powerful network scanning tool that actively sends crafted packets to target hosts to identify open ports, running services, and OS fingerprints. These probes generate detectable traffic on the target network and can trigger intrusion detection systems, making them a hallmark of active reconnaissance. Since passive recon requires no direct interaction with the target's systems, Nmap's active scanning methodology invalidates it for the stated task.

Nikto

Why it fails: Nikto is an active web vulnerability scanner that sends thousands of HTTP requests to a target web server to detect outdated software, dangerous files, and misconfigurations. Its aggressive scanning generates significant server-side log entries and may crash fragile applications, clearly crossing over from passive to active reconnaissance. Moreover, its primary focus is web server vulnerability detection, not extracting employee names or email addresses from OSINT sources, so it fails the task entirely.

Retain all test data indefinitely for future reference

Why it fails: Retaining all test data indefinitely violates data minimization principles and creates an unnecessary security liability if the data is ever breached. Most penetration testing contracts specify retention terms, and indefinite storage is typically not compliant with privacy regulations like GDPR or HIPAA. Furthermore, holding sensitive client data beyond the agreed period breaches trust and could expose the tester to legal action if a leak occurs.

Share findings with other clients to demonstrate expertise

Why it fails: Sharing findings with other clients is a clear violation of confidentiality agreements and NDAs because pentest reports contain sensitive details about vulnerabilities, network architecture, and business context. Even if anonymized, such data can be inferred or used to target the original client, and unauthorized disclosure may breach GDPR or HIPAA if personal data is involved. Ethical practice requires obtaining explicit, written consent before using client data for any purpose beyond the engagement.

Running Nikto with default options

Why it fails: Nikto is fundamentally a vulnerability scanner, not a directory bruteforcer; it probes for known server-side vulnerabilities, outdated software, and misconfigurations using a built-in database of signatures. Although it includes some checks for common files and paths, its scanning logic is not optimized for exhaustive, recursive path enumeration, so it will miss many hidden directories and is slower for pure content discovery. Its role is to assess security weaknesses after directories are already found, not to discover them as a primary function.

Querying theHarvester

Why it fails: theHarvester is an OSINT tool that passively gathers information from public sources—such as search engines, PGP key servers, and certificate transparency logs—to collect emails, subdomains, and hostnames. It does not send HTTP requests to the target web application to probe for directories or files; rather, it mines third-party data that may indirectly hint at hosts, but never enumerates the application's internal path structure. Therefore, it is completely unable to discover directories on the target site, making it an incorrect option.

Likelihood

Why it fails: Likelihood is not a letter in the DREAD acronym; DREAD stands for Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability. Although likelihood is a core concept in risk assessment frameworks such as CVSS or FAIR, DREAD deliberately omits it as a separate item because likelihood is instead approximated by combining Reproducibility and Exploitability. Including Likelihood would duplicate those factors and distort the final risk score.

Severity

Why it fails: Severity is the output of a DREAD assessment, not one of its constituent categories. The five DREAD factors are scored individually on a 0-to-10 scale, and those scores are averaged to assign an overall severity rating; severity therefore represents the calculated result, not an input. Confusing Severity with a component reverses the relationship and undermines the model's scoring methodology.

Impact

Why it fails: Impact is not one of the five DREAD categories; the model instead uses Affected users (how many users are touched) and Damage potential (how severe the harm is) as separate measures. In other frameworks like STRIDE or CVSS, Impact is a broad catch-all term for confidentiality, integrity, and availability loss, which conflates the scope and magnitude of harm. By splitting impact into distinct DREAD components, the model avoids that ambiguity but does not include an 'Impact' field itself.

Include a clause in the SOW that the tester is not liable for any data exposure

Why it fails: Liability disclaimers in an SOW are standard contract terms but do not serve as a scoping consideration. Proper scoping is about defining authorized targets, time windows, and attack techniques, not about insulating the tester from consequences. Without explicit authorization boundaries, even a liability clause cannot shield the tester from legal exposure.

Test all tenant data to ensure comprehensive coverage

Why it fails: In a multi-tenant environment, the tester must only access data belonging to the authorized client. Testing other tenants' data constitutes unauthorized access, violating the CFAA, GDPR, and possibly the cloud provider's terms. Comprehensive coverage should be limited to the client's own data and resources, not across tenants. The scope must explicitly define the tenant and any shared infrastructure boundaries.

Use high-level business language only

Why it fails: Technical audiences, such as system administrators and developers, expect to see the specific technical details behind a vulnerability—like affected services, port numbers, CVE identifiers, and the exact attack sequence. Using only high-level business language obscures these mechanics, making it impossible for them to validate the finding, assess its true exploitability, or begin triaging the issue. This approach treats a technical audience like an executive board, which fails to meet their need for actionable intelligence.

Focus on strategic recommendations

Why it fails: Strategic recommendations, such as improving overall security posture or embracing a zero-trust architecture, are oriented toward executive decision-makers and long-term risk management, not the immediate needs of a technical team. They lack the operational specificity required to patch a specific vulnerability, reconfigure a service, or adjust an intrusion detection rule, which leaves engineers without a clear path to action. For a technical audience, focusing on strategy instead of tactical mitigation can delay the actual remediation and create gaps between the testing findings and the actual security fixes.

Social engineering

Why it fails: Social engineering involves direct interaction with people to extract information, making it active rather than passive reconnaissance. It is tempting because it does gather intelligence about a target, but it belongs to active engagement techniques, whereas passive OSINT relies on publicly available sources without contacting the organisation.

snmpwalk

Why it fails: snmpwalk queries a live device's SNMP agent and returns its configuration data, which is direct interaction with the target and therefore active reconnaissance. It is tempting because SNMP enumeration yields rich host detail, and it would be correct during an authorised active assessment where the tester is permitted to query in-scope devices.

Nmap SYN scan

Why it fails: An Nmap SYN scan sends crafted packets to target hosts and reads their replies, so it directly touches the target and is active reconnaissance. It is tempting because Nmap is a reconnaissance staple, but it would be the right tool when authorised active scanning or host discovery is required, not for OSINT gathering from third-party sources.

User credentials for all accounts

Why it fails: A penetration test report does not include a comprehensive list of user credentials, as these are highly sensitive and their distribution would expand the attack surface. While the report may reference compromised accounts as evidence of impact, actual passwords or password hashes are typically omitted or redacted. Including all accounts would pose a severe security risk and is not a professional deliverable.

Source code of the tested application

Why it fails: The deliverable is not the entire source code, but the findings derived from analysis, often with small, relevant code snippets illustrating the root cause. Supplying the full source code would expose intellectual property and is generally unnecessary for the client to understand the vulnerabilities. Clients already possess their own source code; the report only needs to show where flaws exist and how to remedy them.

Video recording of the testing process

Why it fails: Although a tester may capture screenshots, logs, or screen recordings as evidence, a full video recording is not a standard deliverable due to file size, confidentiality of tooling, and lack of added value for remediation. Text-based evidence and well-annotated findings are more practical and searchable. Clients rarely request video, and it is not part of the customary report package.

Pass-the-hash

Why it fails: Pass-the-hash is a lateral movement technique that leverages captured NTLM password hashes to authenticate to remote Windows systems without needing the plaintext password. It enables an attacker to move across a network by replaying the hash during an authentication exchange, but it does not create a lasting foothold. Because it only facilitates one-time or session-based authentication, it offers no mechanism to execute code automatically on a recurring basis, making it entirely unsuitable as a persistence technique.

Cron jobs

Why it fails: Cron jobs are a Unix/Linux job scheduler utility, not a native Windows component; Windows uses Task Scheduler instead. In a typical Windows post-exploitation scenario, cron would not exist and attempting to use it would likely fail or be ignored. Even on Linux, a cron job could be used for persistence, but in the context of this Windows-focused question, it is the wrong mechanism because it simply does not map to the platform's persistence architecture.

DNS zone transfer

Why it fails: DNS zone transfer is an active reconnaissance technique because it involves sending an AXFR query directly to the target's authoritative DNS server, requesting a full copy of the zone file. This requires interacting with the target's infrastructure and typically only succeeds if the server is misconfigured to allow transfers from any host; a properly configured server will refuse, and the request itself is recorded in the DNS server's logs.

Scanning ports with Nmap

Why it fails: Scanning ports with Nmap is inherently active as it transmits crafted packets—TCP SYN scans, UDP probes, ICMP pings—to the target host. Every probe elicits a response (or a timeout-driven inferred state) that the scanner observes, and these packets are logged by intrusion detection systems and firewalls, making the activity detectable and attributable to the attacker's source IP.

Sending phishing emails

Why it fails: Sending phishing emails is clearly active because it involves direct interaction with the target's users and systems, delivering a malicious payload or credential-harvesting link to a recipient. This creates network traffic to and from the target, triggers email gateway logging, and often requires subsequent user interaction—making it a high-risk, intrusive technique that is the antithesis of passive reconnaissance.

Social engineering

Why it fails: Social engineering is an attack vector or engagement technique, not a knowledge-based testing classification. While it can be incorporated into a penetration test engagement, it does not define the amount of prior information provided to the tester. In PenTest+ terminology, types such as black, white, and gray box refer to the tester's knowledge level, not the attack methods used.

Network penetration test

Why it fails: A network penetration test is an engagement type that focuses specifically on network infrastructure, servers, and endpoints. It describes the scope of the assessment, not the information asymmetry between the tester and the target. The knowledge-based categories (black/white/gray box) classify how much reconnaissance and internal detail the tester receives before the test, making this option incorrect.

Red team

Why it fails: Red team is an engagement type that simulates a full-scale adversarial attack, often combining technical exploits, social engineering, and physical intrusion. It is not a classification based on the level of knowledge given to the tester; rather, it defines the objective and breadth of the operation. PenTest+ distinguishes red teaming from the knowledge-based 'box' types used to categorize testing approaches.

Wireshark

Why it fails: Wireshark is a network protocol analyzer that captures and dissects frames and packets traversing a network interface, focusing on headers, payloads, and protocol state at Layers 2-7. It never loads or executes the target binary, and it cannot inspect CPU registers, memory addresses, or disassembled instruction streams. For a compiled executable, its only marginal use would be observing the binary's outbound network traffic during a dynamic run, which is not a substitute for code-level analysis.

Nmap

Why it fails: Nmap is a network discovery and security auditing utility that sends crafted IP packets to identify live hosts, open TCP/UDP ports, OS fingerprints, and service versions. It treats the compiled binary as an opaque file, because it is neither a file parser nor a disassembler; it simply probes network endpoints. Thus Nmap can determine whether the binary acts as a network service, but it reveals nothing about vulnerable code paths, memory corruption, or the binary's logic.

Burp Suite

Why it fails: Burp Suite is an integrated platform for web application security testing, including intercepting proxies, repeaters, and scanners that manipulate HTTP/S requests between a browser and a backend server. It operates on TLS-terminated web traffic and parses JavaScript, not native machine code, and it has no support for loading portable executables or ELF files. Any vulnerability it finds (such as SQL injection or cross-site scripting) is a web-layer flaw, completely orthogonal to buffer overflows inside a compiled binary.

Pass-the-hash

Why it fails: Pass-the-hash is a lateral movement technique that uses captured NTLM password hashes to authenticate to remote systems on the network, not a local privilege escalation method. It does not elevate privileges on the current compromised host; it simply reuses an already-valid credential (the hash) to access other machines. Since the attacker already has valid credentials, the technique does not turn a standard user into SYSTEM or bypass local access controls.

Kerberoasting

Why it fails: Kerberoasting attacks target Active Directory service accounts by requesting TGS tickets for SPN-linked accounts and cracking them offline to reconstruct plaintext passwords. This is a credential access technique designed to compromise domain service accounts, and it requires network access to a domain controller; it does not elevate privileges on the local host. It enables lateral movement or domain escalation, but it is not a method to go from a low-integrity local user to SYSTEM on the current machine.

SUID/SGID binary exploitation

Why it fails: SUID/SGID binary exploitation is a Linux/Unix privilege escalation technique where a binary with setuid/setgid bits runs with the file owner's or group's privileges, allowing an attacker to spawn a shell as root or another user. This mechanism does not exist on Windows; Windows uses access tokens, service permissions, and other ACL-based controls. Therefore, in a Windows-targeted penetration test, this option is invalid and indicates a misunderstanding of platform-specific privilege escalation.

Adding a registry Run key

Why it fails: The Windows Registry is a hierarchical database that stores low-level settings for the operating system and applications. A Run key in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run instructs Windows to launch a specified program at user logon. Because the compromised target is a Linux host, there is no Registry hive or Run key mechanism, making this option invalid and platform-inappropriate for persistence.

Creating a scheduled task using schtasks

Why it fails: The schtasks utility is a Windows command-line tool used to schedule tasks via the Task Scheduler component. It requires the Windows Task Scheduler service and sees no equivalent on a Linux system, which uses cron or systemd timers instead. Running schtasks against a compromised Linux target would fail because the binary and underlying scheduling infrastructure do not exist.

Remote code execution

Why it fails: While XXE can sometimes be escalated to remote code execution if the XML parser supports PHP or other wrappers and auxiliary functionality like file upload exists, it is not a direct or guaranteed outcome of the vulnerability. RCE requires chaining XXE with additional bugs such as insecure deserialization or write permissions to the web root. In a standard XXE scenario, the impact is limited to file disclosure or SSRF, not arbitrary command execution.

Cross-Site Scripting (XSS)

Why it fails: Cross-Site Scripting (XSS) is a client-side vulnerability where attacker-controlled data is rendered in a user's browser, executing JavaScript in the victim's session. In contrast, XXE occurs entirely on the server during XML parsing, allowing the attacker to read files or make server-side requests. While an XXE file read could theoretically be reflected in a page and later lead to stored XSS, that would be a secondary, indirect consequence, not the core mechanism or direct classification of the XXE attack.

SQL injection

Why it fails: SQL injection (SQLi) abuses a lack of parameterization in SQL queries by injecting SQL syntax into user input, targeting the database layer directly. XXE, on the other hand, exploits an insecure <!ENTITY> declaration in an XML parser to influence file resolution and HTTP requests, not query structure. They are orthogonal vulnerability classes; identifying XXE does not imply SQLi, and fixing SQLi would not affect XXE.

Command injection

Why it fails: Command injection is incorrect because it relies on injecting OS-level commands into application functions that execute system shells, often via parameters like exec(), system(), or pipeline operators. In contrast, XXE targets the XML parser's entity expansion and does not involve shell execution—it deals with file reads or URL fetches, not arbitrary command running. Therefore, while both are critical, they are distinct vulnerability classes with different root causes and exploitation techniques.

SQL injection

Why it fails: SQL injection is not the answer because it operates by manipulating SQL queries through specially crafted input that is concatenated into database statements, such as OR 1=1 to bypass authentication or UNION to extract data. XXE, on the other hand, exploits the XML parsing process by defining external entities that the parser resolves, which has nothing to do with database query syntax. The attack vectors and payload structures are entirely different, and XXE does not interact with SQL engines directly.

XSS

Why it fails: XSS (Cross-Site Scripting) is wrong because it injects malicious client-side scripts (typically JavaScript) into web pages that execute in a victim's browser. XXE, however, is a server-side vulnerability where the XML parser itself processes external entities, leading to file disclosure or SSRF—it never delivers scripts to end users. The impact of XSS is against client sessions and browser data, whereas XXE has no client-side execution and instead affects the server's filesystem or internal network.

Execute SQL injection

Why it fails: XXE is a server-side XML parsing vulnerability that abuses the parser's handling of external entities, whereas SQL injection exploits unsanitized input concatenated into SQL queries. An XXE payload operates at the XML layer and cannot directly alter or inject SQL statements because it never manipulates query syntax or database commands. Even if an attacker reads a database configuration file or credentials, that does not constitute executing SQL injection—it simply enables a separate attack later.

Bypass authentication

Why it fails: Although XXE might indirectly assist with authentication bypass by leaking password hashes or session tokens via file reads or SSRF, it does not directly circumvent authentication mechanisms such as login forms, session validation, or access control checks. Bypassing authentication requires a separate vulnerability like SQL injection in a login query, session fixation, or an IDOR flaw—none of which are intrinsic to XML parser misconfiguration. The scope of XXE is limited to what external entities allow: file disclosure, resource exhaustion, and server-side requests, not alteration of authentication logic.

Conduct testing during off-peak hours

Why it fails: Scheduling testing during off-peak hours reduces the chance of user-visible disruption, but it does nothing to isolate the test from production identity systems. Every authentication attempt still traverses the production Active Directory or IdP, consuming authentication capacity and generating logs that can trip anomaly detection; any misstep—such as an accidental password reset or policy change—would still affect real production accounts and could cause a targeted denial of service.

Perform password spraying against all users

Why it fails: Performing password spraying against all users is an attack technique, not a scoping or isolation method, and it is explicitly dangerous in a production environment. Spraying common passwords across the entire user population will rapidly approach or exceed account lockout thresholds, effectively causing an authentication denial of service; it also risks revealing valid credentials for real users, which violates the principle of least privilege and typical rules of engagement.

Disable MFA for test accounts

Why it fails: Disabling MFA for test accounts is misguided because it changes the security posture you are supposed to be validating and creates a false sense of success. MFA is a critical control, and turning it off on any account—even a test account—weakens the overall identity infrastructure if the test accounts share the same domain or policy; it also prevents the test from accurately reflecting real-world authentication behavior, potentially missing MFA bypass flaws that should have been identified.