Post-exploitation and Lateral Movement practice questions

Detailed exploit steps with screenshots.

Why wrong: Detailed exploit steps are too technical for a CEO. This level of detail belongs in the technical findings section for the IT team.

A list of all CVSS scores without context.

Why wrong: Raw CVSS scores may be confusing without interpretation. The executive summary should translate technical severity into business risk.

The exact commands used during testing.

Why wrong: Commands are operational details that are irrelevant to executive-level understanding. They belong in the methodology appendix.

Two completely separate reports: one for executives and one for technical staff

Why wrong: Producing two entirely separate reports prevents the executive team from seeing the technical reproduction steps that justify the risk ratings, and denies the technical team the executive summary that contextualises business impact. This fragmentation forces each audience to cross-reference missing sections, defeating the single-source-of-truth requirement. It is tempting because separate reports allow tailored language and depth for each group, and would be correct if the client mandated strict information segregation to prevent technical details from reaching non-technical readers.

Only an executive summary, omitting technical details

Why wrong: Delivering only an executive summary omits technical details entirely, which is a severe reporting failure because the technical team cannot reproduce, validate, or remediate the vulnerabilities without specific endpoints, payloads, and evidence. Risk ratings in the executive summary would appear as unsubstantiated claims, and the client would lack the artifacts needed to perform a proper verification of the penetration test's scope and findings. Industry frameworks like PTES require both an executive and a technical section, so this option does not meet minimum reporting expectations.

Only a technical report with all details

Why wrong: Submitting only a technical report with all details fails the executive audience because system administrators and security engineers are not the sole decision-makers; leadership requires a clear, jargon-free articulation of business impact, such as regulatory exposure, potential financial loss, and impacts on reputation. A raw technical dump forces executives to interpret exploit chains and CVSS vectors themselves, which is unrealistic and can lead to misprioritized remediation budgets. Furthermore, without an executive summary, the report does not communicate the overall security posture in a way that supports board-level governance and strategic risk acceptance.

Inject shellcode into the buffer and redirect execution to it

Why wrong: Injecting raw shellcode into the buffer and overwriting the return address to point directly at that buffer fails because Data Execution Prevention (DEP/NX) marks the stack and heap as non-executable memory regions. When the CPU attempts to fetch an instruction from a non-executable page, a hardware exception (STATUS_ACCESS_VIOLATION on Windows, SIGSEGV on Linux) is raised, terminating the process. Even though the shellcode resides at a predictable address and the overflow succeeds, the processor refuses to execute it, making this technique ineffective in a DEP-enabled environment.

Use a ROP chain to call mprotect() to make the stack executable, then jump to shellcode

Why wrong: Since ASLR is disabled, the attacker can use a Ret2Libc attack to jump directly to existing library functions like system() without needing to modify memory permissions. Using mprotect() to bypass DEP via ROP chains is required only when the attacker must execute custom shellcode residing on the stack or heap. In this scenario, bypassing DEP by making memory executable adds unnecessary complexity when direct function calls are possible due to known static addresses.

Use a heap spray to place shellcode at a known address and then trigger the overflow

Why wrong: A heap spray does not address Data Execution Prevention (DEP); it is primarily a technique to defeat Address Space Layout Randomization (ASLR) by filling large portions of the heap with a NOP sled and shellcode, increasing the chance that a jump lands somewhere in the sled. Even if a predictable address is achieved, DEP still marks the heap as non-executable, so any attempt to execute the sprayed shellcode will trigger the same hardware exception as stack injection. Unless the heap is explicitly mapped with executable permissions, which modern systems do not do, heap spraying remains useless against DEP alone and is therefore the wrong choice here.

Technical findings

Why wrong: Technical findings contain detailed exploit steps, proof-of-concept code, and verbose vulnerability descriptions such as CVSS vectors and affected endpoints. This section is intended for IT security engineers who will validate and remediate the issues, not for a CISO who needs synthesized risk context. Presenting this raw technical detail to an executive would obscure the business-critical message and overwhelm an audience focused on strategic decisions.

Appendices with raw scan data

Why wrong: Appendices with raw scan data provide a repository of Nmap output, Nessus reports, and even packet captures that serve as auditable evidence. These data sets are enormous and unstructured, requiring specialized tools to interpret, making them unsuitable for an executive summary. A CISO would be lost in a sea of logs rather than gaining insight into risk posture, so this appendix is meant for compliance or technical follow-up, not executive reading.

Remediation details

Why wrong: Remediation details include step-by-step fixes, exact configuration changes, and patch versions tailored for system administrators and developers. These are action-oriented technical instructions that presume deep knowledge of the infrastructure and are not strategic in nature. The CISO requires a broader view of remediation efforts—such as timeframes, costs, and residual risk—rather than the granular technical procedures themselves.

A detailed list of all vulnerabilities with CVSS scores

Why wrong: Including a detailed vulnerability list with CVSS scores in the executive summary defeats its purpose for non-technical leadership. CVSS scores require understanding of base, temporal, and environmental metrics, which may confuse rather than clarify. This level of detail belongs in the findings section where the client's IT and security teams can map scores to specific remediation actions, not in a summary meant for decision-makers.

The exact commands and payloads used during exploitation

Why wrong: Disclosing exact commands and payloads in the executive summary is inappropriate because such operational details are unnecessary and potentially dangerous if the report is distributed beyond technical staff. Exploit code could be repurposed by malicious actors, and the content would overwhelm readers who lack hands-on security expertise. These details should be relegated to a technical appendix, keeping the executive summary focused on risk outcomes, not proof of exploitation methods.

A quantitative risk analysis including annualized loss expectancy

Why wrong: A quantitative risk analysis with annualized loss expectancy (ALE) typically belongs in a separate risk assessment deliverable, not within a penetration test's executive summary. Penetration tests identify technical vulnerabilities and exploitable conditions, but ALE requires asset valuations and loss frequency estimates that are often outside the pentest scope. The executive summary should communicate risk in business terms using the overall rating, while leaving financial modeling to a dedicated risk analysis.

The IP address and port of the target service

Why wrong: While necessary to connect, this information is typically obtained during reconnaissance. The script likely already has this or prompts for it. The critical unknown is the address to jump to after overwriting the return address.

The version of the operating system running on the target

Why wrong: While the OS version helps identify the target's defenses and potential instruction set, it does not provide the concrete memory address needed for a reliable return address overwrite. The crucial unknown is the pointer to a 'JMP ESP' or equivalent gadget, which must be resolved by examining loaded modules, ASLR settings, and binary analysis. Even with the correct OS version, you would still need to locate a stable address (e.g., in a non-ASLR DLL) to redirect execution. Thus, OS version alone is insufficient and is secondary to the exact instruction address.

The username and password for the target service

Why wrong: Buffer overflow exploits on network services typically target the service's read or parse routine before any authentication is enforced; the malicious payload itself does not require valid credentials. Supplying a username/password would not influence the overwritten stack pointer or return address, and many vulnerable services expose the attack surface anonymously. The precise memory address of a 'JMP ESP' instruction is what determines whether the shellcode gets executed, irrespective of credentials. Authentication bypass, if needed, would be a separate vulnerability—not the core uncertainty in crafting the overflow.

Kernel exploit

Why wrong: Kernel exploits are a privilege escalation strategy that relies on a specific kernel vulnerability (e.g., a CVE with a known proof-of-concept) and usually requires matching kernel version and mitigation state. In this scenario, no kernel version, patch level, or vulnerability indicator is mentioned; there is no evidence an outdated kernel is installed. The root cause is a cron job executing a group-writable script, which is directly and reliably exploitable without the risk or complexity of a kernel exploit.

Misconfigured sudo permissions

Why wrong: Misconfigured sudo permissions would require a visible sudoers rule such as a user or group allowed to run a command as root with NOPASSWD or a specific binary listed as sudo-allowed. The scenario describes only that the tester's group has write access to a script; it does not mention sudo commands, sudoers entries, or user privilege to invoke sudo on that script. Without an underlying sudo policy, there is no sudo-based escalation here; the vulnerability lies in the script's file permissions and its execution by root through cron.

Path hijacking in the cron job

Why wrong: Path hijacking would require the cron job to call a command or script using a relative path, allowing the tester to place a malicious executable earlier in the `$PATH`. In this scenario, the cron job executes a script owned by root but writable by the tester's group, so the tester can directly modify the script’s contents without needing to manipulate the path. This technique is tempting because it is a standard privilege escalation method when a cron job runs a binary or script via an unqualified name, but here the script’s writability makes direct file modification the correct vector.

A list of all tools used during the penetration test

Why wrong: A list of tools used during the penetration test provides operational detail about the testing methodology, but it does not quantify the organisation’s security posture in terms of risk exposure or remediation urgency. Non-technical stakeholders require metrics such as the number of critical vulnerabilities found or the mean time to remediate, not tool names. This option is tempting because tool lists are standard in the technical findings section of a report, where they demonstrate testing rigour to technical readers.

The total number of vulnerabilities discovered and their average CVSS score

Why wrong: Reporting only the total vulnerability count and the average CVSS score is misleading for an executive audience, because a large number of low-severity issues will pull the average down and obscure the presence of a few exploitable critical flaws. CVSS base scores are also computed in isolation, ignoring actual exploitability, attack path complexity, or the value of the affected asset. Executives need risk-prioritized metrics—such as counts of critical/high findings and exploit time—not a statistical summary that masks the urgent exposures.

A detailed step-by-step exploitation walkthrough of one critical vulnerability

Why wrong: A detailed step-by-step exploitation walkthrough of a single critical vulnerability is too technical and narrowly focused for an executive summary, which should summarize overall risk posture rather than demonstrate a specific attack chain. Such procedural detail belongs in the technical findings annex for security teams, and circulating exploit steps broadly in the executive section increases the risk of misuse or inappropriate disclosure. The summary should instead aggregate findings and highlight business impact, not narrate the penetration tester's actions.

Lateral movement

Why wrong: Lateral movement involves using compromised credentials to access other systems. The script is only checking for default passwords, not using them to move laterally. However, it could enable lateral movement if a default password is found.

Credential dumping

Why wrong: Credential dumping is the act of extracting stored authentication material, such as password hashes from SAM database or plaintext secrets from LSASS process memory. This PowerShell script does not extract any secrets from a system; it only attempts to authenticate to remote hosts using a known default Administrator password. Merely testing whether a default password works is an authentication attempt, not a credential theft technique, so it cannot be classified as credential dumping.

Privilege escalation

Why wrong: Privilege escalation involves increasing the access level of the current user or process on a single system, for example by exploiting a kernel vulnerability or abusing a service running with higher privileges. This script does not elevate privileges on any one host; it simply tests an administrative credential across multiple remote systems. If the default password works, you already have administrator-level access, so no privilege escalation step occurs. The action is better categorized as remote enumeration of an insecure configuration, not as an escalation technique.

Specify that only passive reconnaissance techniques will be used on the database server.

Why wrong: Passive reconnaissance still requires interacting with the network path to the database server, such as configuring a SPAN port or tapping a fiber link to capture traffic. This introduces a potential point of failure and can expose sensitive production data in transit, while also potentially triggering data-loss prevention or intrusion detection systems. Because the client requires zero disruption, any activity that touches the server's traffic or network segment is unacceptable.

Include a clause that the tester will not attempt to exploit any vulnerabilities on the database server.

Why wrong: This clause only prohibits exploitation, but other phases of a pentest such as port scans, version detection, and unauthenticated enumeration send crafted packets to the database server. These can cause resource exhaustion, crash vulnerable database services, or lock out service accounts due to failed authentication attempts. Since the client demands zero disruption, merely banning exploitation is insufficient; the entire server must be off-limits.

Require that all testing activities be performed during off-peak hours only.

Why wrong: Performing tests only during off-peak hours reduces the likelihood of impacting users, but it does not eliminate the risk to the database server, which may run time-sensitive batch processes, replications, or backups at night. Additionally, a malformed packet or an aggressive scan can cause an outage at any hour, and many modern databases operate globally so no true off-peak window exists. Off-peak scheduling is a mitigation, not a guarantee, so it fails the zero-disruption requirement.

Return-oriented programming (ROP) to bypass DEP

Why wrong: Return-oriented programming (ROP) is indeed used to bypass Data Execution Prevention (DEP), which is enabled in the scenario. However, with ASLR disabled, library addresses are static and predictable. This allows for a more direct exploitation method, such as Return-to-libc, which simply calls a known function at a fixed address without needing to chain multiple gadgets. ROP would be the most effective choice if ASLR were also enabled, as it provides a robust way to execute arbitrary code when library addresses are randomised.

Heap spraying to inject shellcode

Why wrong: Heap spraying does not bypass DEP; it merely allocates many blocks of memory filled with shellcode or a NOP sled to improve the odds that a redirected instruction pointer lands on attacker-controlled content. With DEP active, the heap is marked non-executable, so any jump into those sprayed regions will trigger an access violation before the shellcode runs. Additionally, since ASLR is disabled in this scenario, the heap is at a predictable address, but that predictability does nothing to counter DEP. The technique often complements exploitation, but it is not a mitigation bypass.

Stack pivoting to redirect execution to a known location

Why wrong: Stack pivoting is a technique used to shift the stack pointer (esp/rsp) to an attacker-controlled buffer, typically to support a ROP chain when the original stack is unreliable or not addressable. It does not itself bypass DEP; even after you pivot, the code you call must still reside in executable memory, and if you pivot to a non-executable heap, direct shellcode execution is still blocked. In this scenario, with ASLR off, the simpler and more direct solution is ret2libc, which calls system() at a fixed address without needing to pivot or chain gadgets. Pivoting might be necessary if the overflow is tiny or the stack is corrupted, but it is a technique for gaining stack control, not a DEP evasion.

Brute force

Why wrong: Brute force attacks involve systematically guessing the plaintext password against a remote authentication service, which is both time-consuming and likely to trigger account lockout policies or intrusion detection. Since the tester already possesses a valid NTLM hash from the workstation, attempting to brute-force the cleartext password is redundant and introduces unnecessary noise. Moreover, modern password policies and rate-limiting make brute force impractical compared to the direct use of the hash.

Rainbow tables

Why wrong: Rainbow tables are precomputed tables that map hash values back to plaintext passwords, but they are used to crack a hash offline, not to authenticate directly. They require substantial disk storage and are largely ineffective against NTLM hashes that are salted or when the password is complex; even then, the process takes time and provides no advantage over using the captured hash itself. Since the goal is to authenticate to a remote service, applying the hash directly is faster and avoids the overhead of cracking.

Keylogging

Why wrong: Keylogging involves capturing keystrokes on the current workstation, which could reveal passwords as the user types them, but it does not leverage the already-extracted NTLM hash. For immediate authentication to a remote server using existing credentials, keylogging is passive and requires waiting for the user to enter a password, which is unreliable and slow. Additionally, keyloggers may miss credentials entered via credential prompts or other input methods, making PtH far more efficient for lateral movement.

Directory brute-forcing

Why wrong: Directory brute-forcing is incorrect because it enumerates valid resource paths on a web server using GET requests (e.g., /admin, /backup) and analyzes HTTP status codes (200, 403, 404) to identify existing directories or files. The described script sends POST requests with different payloads to a single URL, which is not how path discovery works—there are no paths to brute-force. Additionally, retry with exponential backoff is an anti-rate-limiting measure for repeated login attempts, not a technique used in directory brute-forcing, where speed is prioritized.

SQL injection testing

Why wrong: SQL injection testing is wrong because it sends specialized SQL payloads (e.g., single quotes, UNION SELECT, OR 1=1) to observe differences in server responses, database errors, or timing, not generic password strings. The retry with exponential backoff would actually hinder SQLi testing, as a tester needs rapid, repeated requests to map how the application parses injection vectors and tune payloads in real time. Moreover, SQLi is a single-request-per-payload vulnerability check, not a credential-guessing loop, so the script's POST payloads are more consistent with authentication attacks.

Session hijacking

Why wrong: Session hijacking is incorrect because it focuses on stealing, fixing, or predicting session identifiers (e.g., session tokens, cookies) to impersonate an authenticated user, not on sending POST payloads to a login endpoint. Implementing exponential backoff in a hijacking attack is nonsensical—there is no credential to guess or lockout to avoid; instead, an attacker would capture tokens via network sniffing, cross-site scripting, or session fixation. The script's behavior of repeatedly sending different payloads via POST with retry logic clearly aligns with authentication brute-forcing or password spraying, not session-based attacks.

Kerberos Golden Ticket attack

Why wrong: 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.

SMB relay attack using the hash

Why wrong: 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.

Brute-force password cracking of the hash

Why wrong: 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.

That cloud services are often the most vulnerable and should be included for a thorough test

Why wrong: This option distracts from the actual scoping issue. While cloud assets can indeed introduce significant risk, asserting that they are 'most vulnerable' is an unverified generalization and shifts focus away from the fact that the current engagement is incomplete. The professional response is to clearly document the scale and limitations, not to argue for expanding scope with unsupported claims.

That the client can always test cloud services later in a separate engagement

Why wrong: This is wrong because it defers the issue rather than resolving it, and there's no guarantee a separate engagement will be funded or scheduled. It also fails to inform the client that the current test's conclusions will be incomplete, which could lead to a false sense of security. The tester's responsibility is to frame the current engagement's limitations now, not to assume future engagements will fill the gap.

That compliance concerns are unfounded and the test should proceed anyway

Why wrong: This is wrong because compliance constraints (e.g., data residency, regulatory restrictions) are legitimate reasons for excluding cloud assets, and ignoring them could expose the client to legal penalties. A penetration tester must operate within the agreed scope and legal boundaries; suggesting that compliance is unfounded undermines trust and may invalidate the assessment's authorization. The correct approach is to acknowledge the constraints and plan the test around them.

Brute force the password from the hash

Why wrong: While a captured NTLM hash can be subjected to offline brute-force or dictionary attacks to recover the plaintext password, this process is computationally expensive and may take a long time for complex passwords. In practice, finding the plaintext is not a prerequisite for leveraging the hash, as other attacks use the hash directly for authentication. Therefore, brute-forcing is inefficient when the hash itself is sufficient to gain access.

NTLM relay

Why wrong: NTLM relay is a network-level attack where the attacker positions themselves between a client and a server, intercepting an ongoing NTLM authentication exchange (challenge/response) and forwarding it to a target server to authenticate as the client. It requires on-path capability and a live authentication attempt, rather than using an already-captured hash. While both PtH and relay exploit NTLM hash knowledge, relay operates during the authentication flow, whereas PtH directly presents the captured hash as the credential.

Kerberoasting

Why wrong: Kerberoasting is a Kerberos-specific attack targeting TGS tickets requested for service accounts that have Service Principal Names (SPNs). The attacker extracts a TGS ticket from memory (e.g., via 'tgsrepcrack' or 'GetUserSPNs') and cracks it offline because the ticket is encrypted with the service account's NTLM hash. This attack obtains the hash within the ticket and then cracks it, making it a method to recover plaintext passwords, not a way to use a pre-captured NTLM hash for immediate authentication.

Obtain the NTLM hash of the krbtgt account.

Why wrong: Kerberoasting specifically targets service accounts (accounts with SPNs) by requesting TGS tickets encrypted with the service account's password hash, not the krbtgt account. The krbtgt hash is only obtainable via domain compromise techniques like DCSync or NTDS.dit extraction, and it is used for Golden Ticket attacks, not Kerberoasting. These are entirely separate attack paths with different prerequisites and goals.

Obtain a list of all domain users.

Why wrong: Kerberoasting does not enumerate the full user directory; it sends TGS requests only for known SPN-linked accounts and receives only the corresponding service tickets. The attack requires a pre-existing list of SPNs, typically gathered via LDAP queries, but never outputs a user list. Comprehensive user enumeration requires dedicated directory queries or tools like PowerView, making this option incorrect.

Obtain a Kerberos ticket that can be used to impersonate a domain admin.

Why wrong: Kerberoasting yields TGS tickets that are encrypted with the target service account's password-derived key, not a privileged account's hash, and these tickets can only access that specific service. They cannot be used to impersonate a domain admin across the domain because impersonation via Silver or Golden tickets requires the service account's or krbtgt account's hash, which this technique does not obtain. The response was not accepting.

Include a requirement that the client disables NAC during the testing window.

Why wrong: Disabling NAC globally for the entire testing window removes the access control boundary for every endpoint, not just the tester's device. This would leave the client's network open to unauthorized or non-compliant devices during the test, significantly increasing risk and potentially violating compliance requirements. A proper rule of engagement should grant the tester access through a narrow, controlled exception such as a MAC whitelist, not by disabling the security control entirely, which is an unreasonable and disproportionate request.

State that the tester will not connect to the internal network and will only test externally.

Why wrong: Stating that the tester will only perform external testing directly contradicts the client's explicit request for an internal network assessment, so the engagement would fail to meet its core objective. Without internal connectivity, the tester cannot evaluate internal segmentation, host hardening, or how NAC would react to an unauthorized device from inside the network. The rule of engagement should define how the tester is granted authorized internal access, not avoid the internal network altogether, as that would render the test out of scope.

Specify that the tester will bypass NAC as part of the test objectives.

Why wrong: Specifying that the tester will bypass NAC as a test objective conflates the practical need for authorized access with the testing goal of assessing NAC security. A bypass attempt might be a legitimate separate objective, but it should be explicitly agreed upon in the scope and rules of engagement, not used as the method to gain initial network access. Furthermore, attempting to bypass NAC on an unapproved basis could cause network disruptions or legal issues, whereas a pre-authorized whitelist provides a clean, controlled way for the tester to connect before any bypass testing begins.

Technical Findings

Why wrong: Technical Findings contains in-depth technical details, which may be too granular for a CISO who needs a strategic view.

Appendix - Vulnerability Details

Why wrong: The Appendix includes raw data and is supplementary; it is not the primary section for executive communication.

Methodology

Why wrong: Methodology describes the testing process, not the results or business risk, and is not the focus for a CISO.

Lateral movement via PsExec.

Why wrong: PsExec lateral movement typically involves creating and starting a service on the remote host, often by copying a binary to the ADMIN$ share and executing it via the Service Control Manager. While Invoke-Command can be used for lateral movement, the described script only calls Set-Service to change configuration; it does not upload, create, or start a new service, so it is not executing code via PsExec.

Credential dumping.

Why wrong: Credential dumping techniques (e.g., Invoke-Mimikatz, accessing LSASS, or the SAM database) are completely absent from this script. Set-Service only interacts with the Service Control Manager; it does not read memory, access the registry hive, or invoke any credential-API calls. Therefore, the script's purpose is not credential theft.

Data exfiltration.

Why wrong: Data exfiltration requires moving data off the target (e.g., HTTP POST, SCP, DNS tunneling, or email). The script's use of Invoke-Command and Set-Service only alters service attributes; it does not read files, compress data, or initiate network transfers. Without any outbound connection or data-handling cmdlet, exfiltration is not supported.