Penetration Testing Interview Questions — Practice Quiz

A penetration test manually attempts to exploit identified weaknesses — including chaining multiple low-severity findings into a higher-impact attack path — to prove real-world business impact, while an automated vulnerability scan only identifies and reports potential vulnerabilities by signature matching, without confirming exploitability. Pentesters commonly use automated scanners as a starting point, so tooling isn't the distinguishing factor — the exploitation and validation step is.

The OWASP Top 10 is a periodically updated (roughly every 3-4 years), community-driven awareness document ranking the most critical web application security risks, based on both real-world prevalence/incidence data contributed by testing organizations and each risk's typical severity of impact. Testers and AppSec teams use it as a shared vocabulary and a baseline checklist: when scoping an engagement or reporting findings, mapping a vulnerability to 'A03: Injection' or 'A01: Broken Access Control' communicates its category instantly to anyone familiar with the list, and using it as a minimum coverage checklist ensures the highest-prevalence risk classes are never skipped.

From the foothold I would first enumerate the domain context: run queries to list domain computers and users, check which hosts the current user has local admin rights on, and look for cached credentials or Kerberos tickets in memory using a tool like Mimikatz or SharpDPAPI. I would also dump LSASS to recover any NTLM hashes or tickets that other users left on the machine. This tells me which systems are reachable and with what credentials.

With an NTLM hash recovered from LSASS, I would use Pass-the-Hash to authenticate to another host where the corresponding account has local admin rights, then execute a payload remotely via SMB/PSExec or WMI. The prerequisites are: a valid NTLM hash, network reachability to the target, and the account associated with that hash being a local administrator on the target.

To minimize noise, I would prefer reusing existing sessions or tickets rather than creating new logon events, avoid creating new services or scheduled tasks on targets, and perform actions during normal business hours so the activity blends with legitimate usage. I would also limit the number of hosts touched and use tools that do not write binaries to disk on the target.

In many Linux environments, administrators distribute the same SSH private key to multiple servers or reuse a common password for service accounts. The mechanism that makes this dangerous is that the shared key is listed in authorized_keys on every server that trusts it, so once an attacker exfiltrates that key from one compromised host, it is immediately valid for SSH login on all the others. Password reuse works similarly: credentials recovered from shell history or /proc memory on one host are accepted by the SSH daemon on every host sharing that password.

A specific lateral movement technique: the attacker locates the compromised user's private key file at ~/.ssh/id_rsa, then runs ssh -i ~/.ssh/id_rsa user@target-host to authenticate to another server that has that key in its authorized_keys. If SSH agent forwarding was used to reach the compromised host through a jump host, the attacker can instead read the SSH_AUTH_SOCK environment variable and use the forwarded agent socket to authenticate onward — without ever possessing the private key itself, because the agent performs the cryptographic signing on their behalf.

To contain this, the client should enforce unique SSH key pairs per host and per user. This breaks the lateral-movement chain because a key stolen from host A is not present in authorized_keys on host B, so ssh -i with that key against host B will be rejected. Additionally, network segmentation between server tiers prevents SSH connectivity entirely, so even a valid stolen key cannot reach its target. Disabling agent forwarding removes the SSH_AUTH_SOCK socket that an attacker would hijack on intermediate hosts, closing the agent-theft path.

True. A penetration tester may only test systems explicitly listed in the agreed-upon scope. Testing an adjacent system that was not included in the Rules of Engagement constitutes unauthorized access, even if it belongs to the same organization. The tester should flag the system to the client and request a formal scope amendment before assessing it.

Being given standard user credentials and network diagrams, but no source code access, is a gray-box engagement — the tester has partial internal knowledge, which lets them cover more ground in the time box than a pure outsider, without the full visibility a white-box (source-code-included) engagement provides. Black-box means starting from nothing but the target's public footprint.

True. A white-box penetration test, where the tester has source code and architecture access, spends far less time on blind reconnaissance than a black-box test does, so the same time budget goes almost entirely into finding and validating flaws — including logic bugs an outside attacker would struggle to spot. This is why white-box testing is preferred for thorough code-level assurance, while black-box testing is preferred to realistically simulate an external attacker.

Exploiting a bug, misconfiguration, or design flaw to gain access rights beyond what was originally granted. Vertical privilege escalation moves to a higher permission level (a regular user reaching root/SYSTEM); horizontal privilege escalation stays at the same permission level but accesses another user's equivalent resources or account (e.g. viewing another customer's data via an insecure direct object reference).

The scope defines which systems, networks, applications, and IP ranges are authorized for testing, and explicitly which are out of bounds — any target not listed in scope is off-limits regardless of discoverability.

A Kerberos Golden Ticket attack occurs during post-exploitation when an attacker who has compromised a domain controller extracts the hash of the KRBTGT account and uses it to forge a Ticket-Granting Ticket for any user in the domain, enabling persistent lateral movement across domain resources.

Broken Access Control is #1 in the OWASP Top 10:2021 (A01), up from #5 in the prior 2017 edition, based on data showing some form of broken access control present in the large majority of tested applications. Injection, which had ranked #1 in 2017, dropped to #3 in the 2021 list.

Passive reconnaissance techniques gather information without sending any traffic to the target's own systems: searching WHOIS records, reviewing employee LinkedIn profiles and job postings for tech-stack clues, and searching public GitHub repositories for leaked credentials all qualify. Running an Nmap scan or fuzzing a login form both send traffic directly to the target and count as active reconnaissance instead, since either can be logged or trigger an IDS alert.

False. Metasploit is an extensible framework, not just a library of pre-built CVE exploits — it exposes Ruby APIs for writing a custom exploit module against a vulnerability a tester or researcher discovered themselves, whether or not it has a CVE assigned. Researchers routinely build proof-of-concept exploits as Metasploit modules before or independent of public disclosure.

Line 2 — building the SQL string by directly concatenating untrusted input, instead of using a parameterized query, lets an attacker close the quote and inject their own SQL

A penetration test proceeds in a fixed order: pre-engagement scoping and authorization first, then reconnaissance, then scanning and enumeration to map live hosts and services, then exploitation of discovered vulnerabilities, then post-exploitation to escalate privileges and assess real business impact, and finally reporting the findings and remediation guidance. Authorization has to come before any testing — that's the line between a pentest and unauthorized hacking.

Key elements of a penetration testing RoE include: (1) Scope — target IP ranges, domains, applications, and excluded systems; (2) Authorization — written permission (often a Get-Out-of-Jail letter) and emergency contacts; (3) Testing window — allowed dates/times for active testing; (4) Methodologies & techniques permitted — e.g., whether social engineering, DoS, or physical entry are allowed; (5) Communication plan — escalation paths, reporting frequency, and points of contact on both sides; (6) Legal & compliance constraints — applicable laws, data-handling requirements, and non-disclosure terms; (7) Success criteria & deliverables — what the final report must contain and in what format.

Correct statements: black-box provides no prior knowledge, white-box provides source code/diagrams/credentials, gray-box provides partial information like network maps or low-privilege accounts, and white-box can surface insecure code patterns that black-box misses. The claim that black-box is 'always more thorough' is false — black-box better simulates an external attacker, but white-box's internal visibility typically yields broader and deeper findings.

This technique is called Kerberoasting. The TGS ticket is encrypted using the target service account's password hash (commonly RC4-HMAC, which derives from the account's NTLM hash). Because the ticket can be captured by any authenticated domain user and the encryption key is derived solely from the service account's password, an attacker can perform an offline dictionary or brute-force attack against the captured ticket to recover the plaintext password without any further interaction with the KDC or the target service.

Injection (A03), Security Misconfiguration (A05), and Server-Side Request Forgery (A10) are official OWASP Top 10:2021 categories. Cross-Site Request Forgery was dropped from the 2021 list — OWASP cited a low measured incidence rate and that most modern frameworks now ship CSRF protection by default. Buffer Overflow has never been an OWASP Top 10 category; it's a memory-safety issue more associated with native-code security.

Black-box testing gives the tester no internal knowledge — they start from only the target's public-facing footprint, which most realistically simulates what an actual external attacker sees. The cost is that a meaningful share of the time budget goes into blind reconnaissance and enumeration rather than deep vulnerability analysis, so in a fixed time window it typically achieves shallower coverage and can miss logic flaws buried deep in the application. White-box testing hands over source code and architecture up front, so almost the entire time budget goes into finding and validating flaws, achieving far broader and deeper coverage in the same window — at the cost of not testing what an attacker with zero information would actually be able to discover, and it can't validate the effectiveness of external-facing defenses like WAFs the way a black-box test would. Choose black-box when the goal is testing detection/response and the external attack surface realistically; choose white-box (or gray-box as a middle ground) when the goal is maximum code-level assurance under a fixed timeline.

The Penetration Testing Execution Standard (PTES) defines seven core phases executed in sequence: Pre-engagement Interactions, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post-Exploitation, and Reporting. The blank phase consumes the intelligence gathered in the previous phase and models adversary capabilities against the target's business logic, trust relationships, and data flows to identify realistic attack scenarios before any vulnerability scanning or exploitation begins.

The PTES phases in order are: Pre-engagement Interactions → Intelligence Gathering → Threat Modeling → Vulnerability Analysis → Exploitation → Post-Exploitation → Reporting. Each phase feeds the next — you cannot model threats before gathering intelligence, and you cannot exploit before analyzing vulnerabilities — so the pipeline is strictly sequential.

During the PTES Post-Exploitation phase, a tester who has compromised a host on one network segment configures that host to route traffic to a second, otherwise-inaccessible internal subnet, allowing further attacks against hosts the tester cannot reach directly from the original vantage point. This technique of using a compromised system as a network relay is commonly referred to as pivoting, a concept distinct from lateral movement, which describes the act of moving between accounts or hosts within the same reachable network tier.

The correct order is: Define scope and objectives → Draft the Rules of Engagement → Conduct legal/compliance review → Obtain written authorization (signature) → Begin active testing. Scope definition must precede the RoE draft because the rules are built around what is in scope; legal review must precede signature so liabilities are validated; and active testing may only start after the signed authorization is in hand.

Line 2 — /opt/backup.sh is world-writable (rwxrwxrwx) even though root's crontab executes it every 5 minutes, so a low-privileged user can overwrite it with attacker-controlled commands that cron then runs as root