Scenario practice questions

A penetration tester is using a vulnerability scanner on a web application and notices that many findings are false positives caused by the scanner sending oversized payloads that the application truncates or rejects. Which scanner configuration change would MOST effectively reduce false positives in this scenario?

Trap 1: Increase the scan intensity to send more payloads

Increasing scan intensity instructs the scanner to send a greater volume of payloads and adjust fuzzing depth, but it does not add any post-detection verification for the results. More aggressive payload injection often triggers more edge-case responses, which actually increases the likelihood of false positives rather than reducing them. The goal of reducing false positives requires validation logic, not simply more test cases.

Trap 2: Increase the HTTP request timeout

Raising the HTTP request timeout only extends the period the scanner waits for a server response; it does nothing to refine how responses are interpreted for vulnerability confirmation. A longer timeout helps with slow endpoints or network latency, but it cannot correct the core issue of a response being misclassified as vulnerable. In fact, an excessively long timeout may cause the scan to hang or miss real timeout-based vulnerabilities, yet it never reduces false positives.

Trap 3: Disable vulnerability detection for certain plugins

Disabling vulnerability detection for certain plugins is a blunt, overly broad action that removes entire checks from the scan engine, which also eliminates the chance of finding genuine issues tied to those plugins. While it might occasionally reduce false positives in a specific plugin, it does not address the underlying detection logic that causes false positives elsewhere, and it sacrifices real vulnerability coverage. This approach is never recommended as a curated method to improve reporting accuracy; instead, one should tune the scanner's verification settings.

A
Increase the scan intensity to send more payloads
Why it fails: Increasing scan intensity instructs the scanner to send a greater volume of payloads and adjust fuzzing depth, but it does not add any post-detection verification for the results. More aggressive payload injection often triggers more edge-case responses, which actually increases the likelihood of false positives rather than reducing them. The goal of reducing false positives requires validation logic, not simply more test cases.
B
Enable safe checks or anti-false positive mode
Enabling safe checks (or anti-false positive mode) forces the scanner to perform an additional verification pass, typically by sending a benign follow-up request or analyzing the response against a baseline, before a finding is reported as a vulnerability. This confirmatory step distinguishes real, exploitable conditions from noise, such as default error pages or generic server responses. It is the standard configuration for minimizing false positives while retaining true positive detection.
C
Increase the HTTP request timeout
Why it fails: Raising the HTTP request timeout only extends the period the scanner waits for a server response; it does nothing to refine how responses are interpreted for vulnerability confirmation. A longer timeout helps with slow endpoints or network latency, but it cannot correct the core issue of a response being misclassified as vulnerable. In fact, an excessively long timeout may cause the scan to hang or miss real timeout-based vulnerabilities, yet it never reduces false positives.
D
Disable vulnerability detection for certain plugins
Why it fails: Disabling vulnerability detection for certain plugins is a blunt, overly broad action that removes entire checks from the scan engine, which also eliminates the chance of finding genuine issues tied to those plugins. While it might occasionally reduce false positives in a specific plugin, it does not address the underlying detection logic that causes false positives elsewhere, and it sacrifices real vulnerability coverage. This approach is never recommended as a curated method to improve reporting accuracy; instead, one should tune the scanner's verification settings.

Read the full VPN explanation →

Question 2hardmultiple choice

A penetration tester is contracted to perform a grey box test of a company's internal network. The client provides a VPN account for remote access but does not disclose that the account has been used by a former employee. The tester connects and is immediately locked out. Which pre-engagement document should have addressed this scenario?

Trap 1: Emergency contact list

An emergency contact list is an operational escalation document that specifies whom to notify during an active security incident (e.g., a breach or system outage). It is not intended to store or convey authentication material. A grey box tester who discovers that supplied credentials are invalid would escalate through the project's technical coordinator, not through emergency responders. Therefore, although contact details are operationally useful, they do not contain credential values or their validity period.

Trap 2: Data handling agreement

A data handling agreement defines how collected data (e.g., scan results, screenshots, proof-of-access artifacts) must be classified, stored, transmitted, and destroyed to comply with laws or client policies. It may mention that credentials must be protected, but it does not enumerate the specific usernames, passwords, or token expiration times. In a grey box test, the actual credential details are an authorization matter, not a data protection matter. Thus, while relevant to the engagement's security controls, it is not the document that provides credential validity.

Trap 3: Statement of Work (SOW)

A Statement of Work (SOW) is a contractual document that describes the high-level scope, objectives, deliverables, timeline, and commercial terms of the engagement. It may reference that the client will provide 'test accounts' or 'valid user credentials,' but it rarely includes the actual credentials or their validity window because such secrets are not suitable for a contract appendix. The SOW also does not typically govern the day-to-day rules for how those credentials may be used. Therefore, it is incorrect to expect credential details in the SOW rather than in the rules of engagement.

A
Emergency contact list
Why it fails: An emergency contact list is an operational escalation document that specifies whom to notify during an active security incident (e.g., a breach or system outage). It is not intended to store or convey authentication material. A grey box tester who discovers that supplied credentials are invalid would escalate through the project's technical coordinator, not through emergency responders. Therefore, although contact details are operationally useful, they do not contain credential values or their validity period.
B
Data handling agreement
Why it fails: A data handling agreement defines how collected data (e.g., scan results, screenshots, proof-of-access artifacts) must be classified, stored, transmitted, and destroyed to comply with laws or client policies. It may mention that credentials must be protected, but it does not enumerate the specific usernames, passwords, or token expiration times. In a grey box test, the actual credential details are an authorization matter, not a data protection matter. Thus, while relevant to the engagement's security controls, it is not the document that provides credential validity.
C
Statement of Work (SOW)
Why it fails: A Statement of Work (SOW) is a contractual document that describes the high-level scope, objectives, deliverables, timeline, and commercial terms of the engagement. It may reference that the client will provide 'test accounts' or 'valid user credentials,' but it rarely includes the actual credentials or their validity window because such secrets are not suitable for a contract appendix. The SOW also does not typically govern the day-to-day rules for how those credentials may be used. Therefore, it is incorrect to expect credential details in the SOW rather than in the rules of engagement.
D
Rules of Engagement (RoE)
The Rules of Engagement (RoE) is the authoritative document that defines the boundaries, testing windows, legal authorizations, and permissible techniques for a penetration test. In a grey box engagement, the RoE should explicitly list the provided credentials—such as usernames, passwords, API tokens, or SSO accounts—along with their validity period, or state where they will be securely delivered (e.g., an encrypted annex). This ensures the tester only uses authorized accounts and does not exceed the granted access level. Without this, the tester would have no legal proof that using those credentials was permitted.

Question 3mediummultiple choice

A penetration tester has gained a foothold on a Windows server and wants to move laterally to a domain controller. The tester has access to a service account that is a member of the 'Remote Management Users' group on the domain controller. Which of the following tools would be MOST appropriate for lateral movement in this scenario?

Trap 1: PsExec

PsExec creates a service on the remote host via the ADMIN$ share and the SVCCTL named pipe, requiring local Administrative privileges and file sharing to be enabled. The current account's group membership (notably lacking local administrators) means the connection would be denied on the target. Even though PsExec is a legitimate lateral movement technique, the environment does not meet its architectural prerequisites.

Trap 2: MS16-075 exploit

MS16-075 exploits a Windows kernel token impersonation flaw (the "Hot Potato" vector) to escalate privileges to SYSTEM on the same machine. It is a local privilege escalation exploit, not a remote service or protocol that executes commands on another server. Running it on the compromised server only affects the local security context and will not establish a session on a remote host.

Trap 3: BloodHound

BloodHound is a graph-based Active Directory reconnaissance tool that collects relationships such as group memberships, ACLs, and privileged sessions to identify attack paths. It does not have a built-in capability to execute commands on a remote machine; it simply outputs analysis results for the attacker to act on. Therefore, it is misapplied as a lateral movement execution method in this scenario.

A
PsExec
Why it fails: PsExec creates a service on the remote host via the ADMIN$ share and the SVCCTL named pipe, requiring local Administrative privileges and file sharing to be enabled. The current account's group membership (notably lacking local administrators) means the connection would be denied on the target. Even though PsExec is a legitimate lateral movement technique, the environment does not meet its architectural prerequisites.
B
MS16-075 exploit
Why it fails: MS16-075 exploits a Windows kernel token impersonation flaw (the "Hot Potato" vector) to escalate privileges to SYSTEM on the same machine. It is a local privilege escalation exploit, not a remote service or protocol that executes commands on another server. Running it on the compromised server only affects the local security context and will not establish a session on a remote host.
C
WinRM
WinRM is a Microsoft remote management protocol that listens on TCP 5985/5986 and allows authenticated users to execute PowerShell or shell commands via the WSMan service. The account's membership in the Windows Remote Management Users group explicitly grants the right to connect without needing local Administrator rights on the target. Using winrs or Invoke-Command with this account will successfully run commands, making it the correct lateral movement method.
D
BloodHound
Why it fails: BloodHound is a graph-based Active Directory reconnaissance tool that collects relationships such as group memberships, ACLs, and privileged sessions to identify attack paths. It does not have a built-in capability to execute commands on a remote machine; it simply outputs analysis results for the attacker to act on. Therefore, it is misapplied as a lateral movement execution method in this scenario.

Question 4easymultiple choice

A client requests a penetration test but only provides network diagrams and application credentials. Which type of test is being scoped?

Trap 1: Red team

Red teaming is an objective-driven, full-scope adversarial simulation that tests people, processes, and technologies, not a classification of information sharing. It can be conducted using black, grey, or white box knowledge levels, so the term is orthogonal to the scenario. The client's question is about how much network information was provided, making Red team an incorrect answer here.

Trap 2: Black box

Black box testing assumes the tester starts with zero prior knowledge of the target, relying solely on public information and active reconnaissance. Since the client explicitly supplied network diagrams and credentials, the engagement already includes internal details that a black box tester would have to discover on their own. This provision contradicts the no-knowledge premise, so Black box cannot be the correct classification.

Trap 3: White box

White box testing, also known as full disclosure testing, grants the tester complete visibility into the environment, including application source code, architecture documentation, and administrative credentials. Merely providing network diagrams and standard user credentials falls far short of that complete knowledge level. Because the client only shared partial information rather than full transparency, the engagement cannot be classified as White box.

A
Red team
Why it fails: Red teaming is an objective-driven, full-scope adversarial simulation that tests people, processes, and technologies, not a classification of information sharing. It can be conducted using black, grey, or white box knowledge levels, so the term is orthogonal to the scenario. The client's question is about how much network information was provided, making Red team an incorrect answer here.
B
Black box
Why it fails: Black box testing assumes the tester starts with zero prior knowledge of the target, relying solely on public information and active reconnaissance. Since the client explicitly supplied network diagrams and credentials, the engagement already includes internal details that a black box tester would have to discover on their own. This provision contradicts the no-knowledge premise, so Black box cannot be the correct classification.
C
Grey box
Grey box testing occupies the middle ground between black and white box, giving the tester limited but realistic information such as network diagrams, IP ranges, and low-privileged credentials. This approach mirrors an insider or partially compromised external attacker and is the standard for many commercial penetration tests because it balances thoroughness with real-world conditions. The client's provision of network diagrams and credentials exactly matches this limited-information model, making Grey box the correct answer.
D
White box
Why it fails: White box testing, also known as full disclosure testing, grants the tester complete visibility into the environment, including application source code, architecture documentation, and administrative credentials. Merely providing network diagrams and standard user credentials falls far short of that complete knowledge level. Because the client only shared partial information rather than full transparency, the engagement cannot be classified as White box.

Question 5mediummultiple choice

While performing vulnerability scanning, a penetration tester runs a Nessus scan against a web server. The report shows a 'critical' finding, but after manual verification, the tester determines the service is not actually vulnerable. This scenario best describes:

Trap 1: A false negative

A false negative occurs when a scanner fails to identify a vulnerability that actually exists, meaning no alert is generated for a real security gap. In this scenario, the scanner produced an alert, so the issue is not one of omission but of incorrect reporting. Thus, this term does not describe the situation.

Trap 2: A configuration error

A configuration error might have caused the scanner to flag a non-existent issue, but it is not the classification of the alert itself. In vulnerability management terminology, an alert that is later proven invalid by manual testing is specifically called a false positive. Therefore, while a misconfiguration could be an root cause, the correct label for the incorrect alert is not 'configuration error.'

Trap 3: A true positive

A true positive indicates that the scanner correctly identified a genuine vulnerability that is verified to exist. Since manual testing contradicted the scanner's finding and proved the vulnerability is absent, this is the opposite of a true positive. Therefore, labeling this result as a true positive would be factually incorrect.

A
A false negative
Why it fails: A false negative occurs when a scanner fails to identify a vulnerability that actually exists, meaning no alert is generated for a real security gap. In this scenario, the scanner produced an alert, so the issue is not one of omission but of incorrect reporting. Thus, this term does not describe the situation.
B
A configuration error
Why it fails: A configuration error might have caused the scanner to flag a non-existent issue, but it is not the classification of the alert itself. In vulnerability management terminology, an alert that is later proven invalid by manual testing is specifically called a false positive. Therefore, while a misconfiguration could be an root cause, the correct label for the incorrect alert is not 'configuration error.'
C
A false positive
A false positive is an alert that a vulnerability scanner generates for a condition that, upon manual verification, does not actually exist. This is precisely what happened here: the scanner flagged a weakness, but penetration testing proved it was not present. Such alerts require triage to filter noise and avoid wasting remediation effort.
D
A true positive
Why it fails: A true positive indicates that the scanner correctly identified a genuine vulnerability that is verified to exist. Since manual testing contradicted the scanner's finding and proved the vulnerability is absent, this is the opposite of a true positive. Therefore, labeling this result as a true positive would be factually incorrect.

Question 6mediummultiple choice

A company wants to simulate a real-world attack scenario where the penetration tester has no prior knowledge of the environment and must act as an external threat actor. However, the tester is allowed to use social engineering to gain initial access. Which type of engagement is most appropriate?

Trap 1: Network penetration test

A network penetration test is a technical assessment of network infrastructure, targeting issues like misconfigured firewalls, unpatched servers, weak protocol settings, and improper network segmentation. Its scope and rules of engagement typically limit activities to specified IP ranges and system layers, and it usually does not involve attempting to trick employees through social engineering. While the test can reveal exploitable network vulnerabilities, it does not simulate a realistic, multidimensional attack that combines human interaction and social manipulation.

Trap 2: Wireless penetration test

A wireless penetration test is narrowly scoped to the radio-frequency environment, evaluating WPA2/WPA3 weaknesses, rogue access points, evil twin deployments, deauthentication attacks, and client misassociation. This assessment does not include social engineering, physical entry, or other organizational attack surfaces, so its results are limited to the wireless domain. It can support a red team operation but is not equivalent to a real-world scenario involving phishing or human deception.

Trap 3: Web application penetration test

A web application penetration test focuses exclusively on application-layer flaws such as SQL injection, cross-site scripting, broken authentication, and access control failures, typically aligned with the OWASP Top 10. Because the test is scoped to the web application's code, configuration, and business logic, it does not evaluate human susceptibility to phishing or the physical security of a facility. Thus, it cannot represent a real-world attack that uses social engineering as a primary entry vector.

A
Red team exercise
A red team exercise is a full-scope, objective-based simulation that mimics a real adversary's tactics, techniques, and procedures (TTPs), including social engineering, physical access, email phishing, and exploitation. Unlike a single-vector assessment, it is designed to test the organization's overall security posture — people, processes, and technology — by stealthily moving toward a defined goal, such as data exfiltration or domain compromise. Social engineering is a core component because it validates whether employee awareness and security policies can resist real-world manipulation.
B
Network penetration test
Why it fails: A network penetration test is a technical assessment of network infrastructure, targeting issues like misconfigured firewalls, unpatched servers, weak protocol settings, and improper network segmentation. Its scope and rules of engagement typically limit activities to specified IP ranges and system layers, and it usually does not involve attempting to trick employees through social engineering. While the test can reveal exploitable network vulnerabilities, it does not simulate a realistic, multidimensional attack that combines human interaction and social manipulation.
C
Wireless penetration test
Why it fails: A wireless penetration test is narrowly scoped to the radio-frequency environment, evaluating WPA2/WPA3 weaknesses, rogue access points, evil twin deployments, deauthentication attacks, and client misassociation. This assessment does not include social engineering, physical entry, or other organizational attack surfaces, so its results are limited to the wireless domain. It can support a red team operation but is not equivalent to a real-world scenario involving phishing or human deception.
D
Web application penetration test
Why it fails: A web application penetration test focuses exclusively on application-layer flaws such as SQL injection, cross-site scripting, broken authentication, and access control failures, typically aligned with the OWASP Top 10. Because the test is scoped to the web application's code, configuration, and business logic, it does not evaluate human susceptibility to phishing or the physical security of a facility. Thus, it cannot represent a real-world attack that uses social engineering as a primary entry vector.

Question 7mediummultiple choice

While performing vulnerability scanning with Nessus, a penetration tester notices that several high-severity vulnerabilities are reported for a web server, but manual verification shows the server is not vulnerable. What is the MOST likely cause of this discrepancy?

Trap 1: The scanner used unauthenticated scans, missing the actual…

Unauthenticated scans lack the necessary credentials to enumerate missing patches or configuration weaknesses, so they often report fewer findings rather than extra ones. The absence of authentication means the scanner can only see exposed services, and if a vulnerability requires a logged-in state, it will be missed—producing false negatives. This cannot explain false positives, which are erroneous positive reports.

Trap 2: The scanner configuration excluded necessary plugins for accurate…

Excluding plugins from a scanning configuration narrows the scope of security checks performed, directly reducing the chances of detecting real vulnerabilities. This exclusion causes false negatives because no test is executed for those specific weaknesses, not false positives. False positives arise from incorrect test logic or false assumptions, not from skipping checks.

Trap 3: The target server is behind a load balancer that modifies responses

A load balancer that modifies responses can route traffic to different backend servers or alter headers, but this typically affects request distribution and session persistence rather than the scanner's vulnerability matching logic. While unusual response patterns might confuse some fingerprinting, the most common source of false positives remains the scanner's version detection heuristics. Therefore, load balancing is an unlikely and less direct cause of spurious findings.

A
The scanner used unauthenticated scans, missing the actual vulnerabilities
Why it fails: Unauthenticated scans lack the necessary credentials to enumerate missing patches or configuration weaknesses, so they often report fewer findings rather than extra ones. The absence of authentication means the scanner can only see exposed services, and if a vulnerability requires a logged-in state, it will be missed—producing false negatives. This cannot explain false positives, which are erroneous positive reports.
B
The scanner configuration excluded necessary plugins for accurate testing
Why it fails: Excluding plugins from a scanning configuration narrows the scope of security checks performed, directly reducing the chances of detecting real vulnerabilities. This exclusion causes false negatives because no test is executed for those specific weaknesses, not false positives. False positives arise from incorrect test logic or false assumptions, not from skipping checks.
C
The target server is behind a load balancer that modifies responses
Why it fails: A load balancer that modifies responses can route traffic to different backend servers or alter headers, but this typically affects request distribution and session persistence rather than the scanner's vulnerability matching logic. While unusual response patterns might confuse some fingerprinting, the most common source of false positives remains the scanner's version detection heuristics. Therefore, load balancing is an unlikely and less direct cause of spurious findings.
D
The scanner is reporting false positives due to inaccurate version detection
Version-based detection is a heuristic where the scanner matches a service's banner or fingerprint against a vulnerability database; if the version string is parsed incorrectly or the banner is outdated, false positives occur. For example, a web server with a backported security patch may still display an old version number, leading the scanner to flag a vulnerability that is not actually present. This is a well-known limitation of unauthenticated scanning and a common cause of erroneous positive reports.

Question 8hardmultiple choice

A penetration tester has compromised a Linux server and wants to move laterally to a Windows server. The Linux server has network access to the Windows server on port 445. The tester has a captured NTLM hash of a domain administrator account. Which technique is most likely to allow the tester to authenticate and execute commands on the Windows server?

Trap 1: Kerberos Golden Ticket attack

A Kerberos Golden Ticket attack requires forging a Ticket-Granting Ticket (TGT) using the KRBTGT account's hash, which is only accessible after fully compromising an Active Directory domain. This technique is used to create long-term persistence and unauthorized domain-wide access, not to authenticate to a single host with a captured user hash. To execute it, the tester would need Domain Admin privileges and access to the KRBTGT hash, making it entirely inappropriate for a simple pass-the-hash lateral movement scenario.

Trap 2: SMB relay attack using the hash

SMB relay attacks, as performed with tools like ntlmrelayx, intercept an authentication attempt and forward the challenge-response to another system, tricking it into accepting the attacker's credentials. This technique is valuable when an attacker is positioned to capture hashes in transit, but here the tester already possesses a valid NTLM hash, so relaying is unnecessary. Moreover, a relay attack requires an unsuspecting client to authenticate to the attacker's SMB server, which is not applicable when the tester directly controls the credential material.

Trap 3: Brute-force password cracking of the hash

Brute-force password cracking attempts to recover the plaintext password from the NTLM hash using offline tools like hashcat or John the Ripper, which is computationally expensive and may fail against complex passwords. While cracking could reveal reusable passwords, pass-the-hash already enables authentication without the plaintext, so the cracked password is not needed for lateral movement. The only scenario where cracking is justified is if the hash needs to be converted to a Kerberos AES key or used in a different protocol that does not support PtH, but for standard SMB access it is pointless.

A
Pass-the-hash using Impacket's psexec
Pass-the-hash (PtH) with Impacket's psexec.py allows the tester to authenticate to remote Windows hosts by providing the NTLM hash instead of the plaintext password. Since the Linux server is compromised, the tester can extract hashes from memory or local files, then use psexec to execute commands over SMB via the ADMIN$ share. This is a direct lateral movement technique that does not require cracking, and it works against any Windows target that has NTLM authentication enabled.
B
Kerberos Golden Ticket attack
Why it fails: A Kerberos Golden Ticket attack requires forging a Ticket-Granting Ticket (TGT) using the KRBTGT account's hash, which is only accessible after fully compromising an Active Directory domain. This technique is used to create long-term persistence and unauthorized domain-wide access, not to authenticate to a single host with a captured user hash. To execute it, the tester would need Domain Admin privileges and access to the KRBTGT hash, making it entirely inappropriate for a simple pass-the-hash lateral movement scenario.
C
SMB relay attack using the hash
Why it fails: SMB relay attacks, as performed with tools like ntlmrelayx, intercept an authentication attempt and forward the challenge-response to another system, tricking it into accepting the attacker's credentials. This technique is valuable when an attacker is positioned to capture hashes in transit, but here the tester already possesses a valid NTLM hash, so relaying is unnecessary. Moreover, a relay attack requires an unsuspecting client to authenticate to the attacker's SMB server, which is not applicable when the tester directly controls the credential material.
D
Brute-force password cracking of the hash
Why it fails: Brute-force password cracking attempts to recover the plaintext password from the NTLM hash using offline tools like hashcat or John the Ripper, which is computationally expensive and may fail against complex passwords. While cracking could reveal reusable passwords, pass-the-hash already enables authentication without the plaintext, so the cracked password is not needed for lateral movement. The only scenario where cracking is justified is if the hash needs to be converted to a Kerberos AES key or used in a different protocol that does not support PtH, but for standard SMB access it is pointless.

Question 9hardmultiple choice

A vulnerability scanner reports a reflected XSS vulnerability in a web application. Manual testing confirms that the application HTML-encodes all user input in the response. Which scanner misconfiguration is MOST likely causing this false positive?

Trap 1: The scanner used a POST request instead of a GET request for the…

The HTTP request method (GET vs POST) is irrelevant to whether a server-side application encodes user-controlled data in its response. Output encoding is determined by the application's templating and rendering logic, which behaves identically for either verb unless the endpoint explicitly branches on method. A reflected XSS finding depends on the payload appearing unencoded in the response body, not on how the scanner delivered the request. Since both methods result in the same server-side processing, this cannot account for a false positive.

Trap 2: The scanner's payload was reflected in a different context not…

This option describes a scenario that would be a genuine reflected XSS vulnerability, not a false positive. If the payload is reflected in a context that lacks HTML encoding, such as inside a script block or an HTML attribute, the scanner is correct to flag it. Manual testing in this scenario, however, confirmed that every reflection point applies contextually appropriate encoding, so the premise of an unencoded context is factually false. The scanner cannot independently identify which context a reflection occurs in without further probing.

Trap 3: The scanner used a payload with special characters that were…

Truncation would prevent the full payload from appearing in the HTTP response, so the scanner's verification step—matching its exact payload string in the response—would fail, producing a false negative rather than a false positive. For a false positive, the scanner needs to see a reflected copy of its complete payload, unencoded. Truncation also typically removes special characters that are essential for XSS payload execution, so the reflected snippet would be inert and would not trigger the scanner's signature. Thus this is the opposite of a plausible cause for a false report.

A
The scanner used a POST request instead of a GET request for the payload
Why it fails: The HTTP request method (GET vs POST) is irrelevant to whether a server-side application encodes user-controlled data in its response. Output encoding is determined by the application's templating and rendering logic, which behaves identically for either verb unless the endpoint explicitly branches on method. A reflected XSS finding depends on the payload appearing unencoded in the response body, not on how the scanner delivered the request. Since both methods result in the same server-side processing, this cannot account for a false positive.
B
The scanner's payload was reflected in a different context not subject to HTML encoding
Why it fails: This option describes a scenario that would be a genuine reflected XSS vulnerability, not a false positive. If the payload is reflected in a context that lacks HTML encoding, such as inside a script block or an HTML attribute, the scanner is correct to flag it. Manual testing in this scenario, however, confirmed that every reflection point applies contextually appropriate encoding, so the premise of an unencoded context is factually false. The scanner cannot independently identify which context a reflection occurs in without further probing.
C
The scanner used a payload with special characters that were truncated by the server
Why it fails: Truncation would prevent the full payload from appearing in the HTTP response, so the scanner's verification step—matching its exact payload string in the response—would fail, producing a false negative rather than a false positive. For a false positive, the scanner needs to see a reflected copy of its complete payload, unencoded. Truncation also typically removes special characters that are essential for XSS payload execution, so the reflected snippet would be inert and would not trigger the scanner's signature. Thus this is the opposite of a plausible cause for a false report.
D
The scanner's payload triggered a server error that echoed back the input without encoding
When a scanner payload triggers an unhandled exception, the application's error handler may render a stack trace or generic error page that echoes back the offending input without applying the output encoding used by normal templates. The scanner observes its payload reflected verbatim in the response and flags it as XSS, but the vulnerability exists only in the error-handling path, which may not be reachable or exploitable under normal conditions. This is a well-known source of false positives because error pages often bypass security headers and encoding filters. Manual testing shows the normal pages encode all output, so this anomalous reflection is the likely explanation for the scanner's report.

Question 10easymultiple choice

A penetration tester is performing a client-side attack against a user. The tester sends an email with a malicious attachment that, when opened, executes a macro that downloads a payload. Which type of attack is this?

Trap 1: Vishing

Vishing is incorrect because it relies on voice communication, typically through phone calls or VoIP, to deceive the target into revealing sensitive information or performing an action. It does not use email or attachments, and the attack vector is auditory, not file-based. While vishing can be a client-side attack, the scenario's explicit mention of a malicious attachment eliminates voice as the delivery mechanism.

Trap 2: Smishing

Smishing is incorrect because it uses SMS or text messages as the attack vector, often with a link or a prompt to reply, rather than email with an attachment. The term 'smishing' is a portmanteau of 'SMS' and 'phishing,' and it exploits the trust people place in text messages. The scenario's email-based delivery with an attachment distinguishes it from smishing, which typically directs victims to a malicious website via a texted URL.

Trap 3: Watering hole

A watering hole attack is incorrect because it does not involve sending a direct message to the target. Instead, the attacker compromises a website that the target is known to visit, planting malware that infects the user's system when they browse the site. This method relies on the target to initiate the visit, whereas the scenario states a direct client-side attack, suggesting a proactive delivery like email.

A
Spear phishing
Spear phishing is the correct choice because the scenario describes a client-side attack that targets a specific user through email with a malicious attachment. Unlike generic phishing, spear phishing leverages reconnaissance—such as the victim's name, role, or interests—to craft a highly convincing message, increasing the likelihood of the user opening the attachment. This direct, personalized email vector aligns perfectly with the definition of spear phishing.
B
Vishing
Why it fails: Vishing is incorrect because it relies on voice communication, typically through phone calls or VoIP, to deceive the target into revealing sensitive information or performing an action. It does not use email or attachments, and the attack vector is auditory, not file-based. While vishing can be a client-side attack, the scenario's explicit mention of a malicious attachment eliminates voice as the delivery mechanism.
C
Smishing
Why it fails: Smishing is incorrect because it uses SMS or text messages as the attack vector, often with a link or a prompt to reply, rather than email with an attachment. The term 'smishing' is a portmanteau of 'SMS' and 'phishing,' and it exploits the trust people place in text messages. The scenario's email-based delivery with an attachment distinguishes it from smishing, which typically directs victims to a malicious website via a texted URL.
D
Watering hole
Why it fails: A watering hole attack is incorrect because it does not involve sending a direct message to the target. Instead, the attacker compromises a website that the target is known to visit, planting malware that infects the user's system when they browse the site. This method relies on the target to initiate the visit, whereas the scenario states a direct client-side attack, suggesting a proactive delivery like email.

Question 11easymultiple choice

A penetration tester is hired to assess the security of a company's internal network. The client provides the tester with full network diagrams, credentials, and source code. Which type of penetration test is being performed?

Trap 1: Grey box

Grey box testing grants the tester partial knowledge, such as a valid low-privileged domain account or limited network diagrams, to emulate an authenticated internal threat. Because the engagement involves only piecemeal information rather than complete architectural and code-level details, it does not satisfy a scenario where the tester is granted full system knowledge. The correct answer must reflect total visibility, not a middle ground.

Trap 2: Black box

Black box testing provides no prior knowledge of the target, forcing the tester to perform reconnaissance and behave like an unprivileged external attacker. While this approach validates external perimeter controls, it cannot be selected when the engagement explicitly provides the tester with full credentials, source code, and infrastructure documentation. Lack of insider knowledge runs directly contrary to the premise that the tester has complete access.

Trap 3: Red team

Red teaming is a goal-based security exercise that emulates adversarial tactics, techniques, and procedures across multiple layers, not a knowledge-level classification like black, grey, or white box. A red team can operate with black, grey, or white knowledge depending on the rules of engagement, so selecting it as a testing type would mismatch the question's focus on the amount of information provided. The premise asks for a testing methodology defined by knowledge, not an operational exercise format.

A
Grey box
Why it fails: Grey box testing grants the tester partial knowledge, such as a valid low-privileged domain account or limited network diagrams, to emulate an authenticated internal threat. Because the engagement involves only piecemeal information rather than complete architectural and code-level details, it does not satisfy a scenario where the tester is granted full system knowledge. The correct answer must reflect total visibility, not a middle ground.
B
Black box
Why it fails: Black box testing provides no prior knowledge of the target, forcing the tester to perform reconnaissance and behave like an unprivileged external attacker. While this approach validates external perimeter controls, it cannot be selected when the engagement explicitly provides the tester with full credentials, source code, and infrastructure documentation. Lack of insider knowledge runs directly contrary to the premise that the tester has complete access.
C
Red team
Why it fails: Red teaming is a goal-based security exercise that emulates adversarial tactics, techniques, and procedures across multiple layers, not a knowledge-level classification like black, grey, or white box. A red team can operate with black, grey, or white knowledge depending on the rules of engagement, so selecting it as a testing type would mismatch the question's focus on the amount of information provided. The premise asks for a testing methodology defined by knowledge, not an operational exercise format.
D
White box
White box testing, also called clear box or open box testing, gives the tester full knowledge of the target environment, including source code, architecture diagrams, configuration files, and administrative credentials. This comprehensive visibility allows the pentester to perform detailed code review, identify programming flaws, and validate configuration hardening with maximum efficiency. When the engagement premise states the tester is provided complete system details, white box is the only correct classification.

Question 12easymultiple choice

A penetration tester is planning a social engineering campaign against a corporation. The goal is to trick the CEO into revealing sensitive information. Which type of attack should the tester use?

Trap 1: Vishing

Vishing (voice phishing) uses phone calls or VoIP with caller-ID spoofing to trick a user into disclosing credentials, MFA codes, or sensitive data. While a vishing campaign can absolutely be aimed at a CEO, the term describes the medium and tactic, not the executive-level target. In contrast, 'whaling' specifically denotes attacks directed at senior executives, so vishing is too broad and imprecise for this scenario.

Trap 2: Spear phishing

Spear phishing is a targeted phishing attack that is tailored to a specific individual using OSINT-gathered details like job role, projects, or personal interests. It is accurate to say a CEO could be spear-phished, but the term does not indicate that the victim is a senior executive; any employee can be a spear-phishing target. Whaling is the specialized subset for C-suite and high-value executives, so spear phishing lacks the precise semantic focus the question asks for.

Trap 3: Pharming

Pharming is a non-social-engineering attack that redirects victims' traffic by poisoning DNS caches, altering hosts files, or compromising a router so that a legitimate domain resolves to a malicious server. The victim is manipulated indirectly through infrastructure, not through persuasive communication, and the attacker often does not even know who the victim is. Because the campaign specifically targets a named CEO, pharming does not fit the targeting logic and is not a social engineering technique in the same category as whaling.

A
Vishing
Why it fails: Vishing (voice phishing) uses phone calls or VoIP with caller-ID spoofing to trick a user into disclosing credentials, MFA codes, or sensitive data. While a vishing campaign can absolutely be aimed at a CEO, the term describes the medium and tactic, not the executive-level target. In contrast, 'whaling' specifically denotes attacks directed at senior executives, so vishing is too broad and imprecise for this scenario.
B
Spear phishing
Why it fails: Spear phishing is a targeted phishing attack that is tailored to a specific individual using OSINT-gathered details like job role, projects, or personal interests. It is accurate to say a CEO could be spear-phished, but the term does not indicate that the victim is a senior executive; any employee can be a spear-phishing target. Whaling is the specialized subset for C-suite and high-value executives, so spear phishing lacks the precise semantic focus the question asks for.
C
Pharming
Why it fails: Pharming is a non-social-engineering attack that redirects victims' traffic by poisoning DNS caches, altering hosts files, or compromising a router so that a legitimate domain resolves to a malicious server. The victim is manipulated indirectly through infrastructure, not through persuasive communication, and the attacker often does not even know who the victim is. Because the campaign specifically targets a named CEO, pharming does not fit the targeting logic and is not a social engineering technique in the same category as whaling.
D
Whaling
Whaling is the established term for a spear-phishing attack aimed at high-level executives such as a CEO, CFO, or other senior officers. The attacker crafts pretexts like legal subpoenas, urgent board communications, or financial transaction requests that exploit the executive's authority, busy schedule, and access to critical systems or funds. In a pen-test scenario targeting a CEO, whaling is the correct label because it names both the technique and the specific victim class.

Open the full VLAN trunking answer →

Question 13hardmultiple choice

A medium-sized e-commerce company, CyberMart, has contracted your penetration testing firm to assess their security posture. The company operates from three physical locations: headquarters, a data center, and a remote warehouse. They have a flat internal network but separate VLANs for production, development, and guest Wi-Fi. CyberMart's CISO insists that the test must be conducted without causing any disruption to the production environment, especially the payment processing system. The test should simulate an external attacker targeting the public-facing web servers and an internal attacker who has gained initial access to the guest network. The CISO also requests that all testing be done during off-peak hours to minimize impact. You are preparing the rules of engagement. Which of the following is the most appropriate action to include in the ROE to satisfy the client's requirements while maintaining a realistic test scenario?

Trap 1: Include all VLANs but with explicit permission to conduct…

Authorizing denial-of-service tests on all VLANs, even during off-peak hours, still risks production outages and cascading failures that could affect payment processing. The CISO explicitly requested avoiding degradation, not merely scheduling it for low-traffic windows, and off-hours operations often have fewer staff available to respond to incidents. Furthermore, including the production payment VLAN violates the requirement to protect that critical segment. A proper rules of engagement should exclude critical systems entirely and require a kill switch, not just time-based restrictions.

Trap 2: Focus exclusively on the external web servers and exclude internal…

Excluding internal network testing entirely prevents the assessment from validating the internal attacker scenario, which is specifically part of the test objectives. External web server testing alone cannot discover issues like VLAN hopping, weak internal lateral movement controls, or excessive trust relationships between internal systems. The CISO's concern about disruption does not justify omitting an entire attack surface; instead, controlled testing with safeguards should be used to mitigate risk.

Trap 3: Restrict testing to only the guest network and external IPs,…

Limiting testing to the guest network and external IPs ignores the production VLANs where the most sensitive data and critical business processes reside. This fails to validate internal segmentation between guest and corporate networks, as well as between different production tiers, leaving the actual internal attacker path untested. While it minimizes disruption, it also makes the penetration test largely irrelevant to the company's risk profile, as the guest network is typically already isolated and external testing is only one small component.

A
Include all VLANs but with explicit permission to conduct denial-of-service tests only during off-peak hours.
Why it fails: Authorizing denial-of-service tests on all VLANs, even during off-peak hours, still risks production outages and cascading failures that could affect payment processing. The CISO explicitly requested avoiding degradation, not merely scheduling it for low-traffic windows, and off-hours operations often have fewer staff available to respond to incidents. Furthermore, including the production payment VLAN violates the requirement to protect that critical segment. A proper rules of engagement should exclude critical systems entirely and require a kill switch, not just time-based restrictions.
B
Allow testing on all VLANs except the production VLAN containing payment processing, with a rule to immediately stop if any degradation is observed.
This scope correctly balances comprehensive internal testing with business continuity: it includes all network segments to simulate both external and internal attackers, but excludes the payment processing VLAN to protect cardholder data and PCI DSS-scoped systems. The immediate-stop rule serves as a safety kill switch, ensuring any sign of degradation halts testing before impact. This covers internal segmentation testing across VLANs, which is essential for a medium e-commerce company, while respecting the CISO's risk tolerance.
C
Focus exclusively on the external web servers and exclude internal network testing due to the risk of disruption.
Why it fails: Excluding internal network testing entirely prevents the assessment from validating the internal attacker scenario, which is specifically part of the test objectives. External web server testing alone cannot discover issues like VLAN hopping, weak internal lateral movement controls, or excessive trust relationships between internal systems. The CISO's concern about disruption does not justify omitting an entire attack surface; instead, controlled testing with safeguards should be used to mitigate risk.
D
Restrict testing to only the guest network and external IPs, excluding all production VLANs.
Why it fails: Limiting testing to the guest network and external IPs ignores the production VLANs where the most sensitive data and critical business processes reside. This fails to validate internal segmentation between guest and corporate networks, as well as between different production tiers, leaving the actual internal attacker path untested. While it minimizes disruption, it also makes the penetration test largely irrelevant to the company's risk profile, as the guest network is typically already isolated and external testing is only one small component.