Penetration Testing Interview Questions & Answers

Penetration testing is an authorized security assessment in which ethical hackers simulate real-world attacks to identify, validate, and demonstrate vulnerabilities before malicious actors exploit them.

A strong answer also mentions scope, rules of engagement, written permission, and the goal of producing actionable remediation guidance — not just a list of scanner findings.

Vulnerability assessment focuses on discovering and ranking potential weaknesses, often through scanning and configuration review.

Penetration testing goes further by attempting controlled exploitation to prove real impact, chaining issues, and demonstrating business risk. VA answers “what might be wrong”; pentesting answers “what can actually be abused and how far can an attacker go.”

A common lifecycle is:

• Planning and scoping (rules of engagement, targets, constraints)
• Reconnaissance (passive and active information gathering)
• Scanning and enumeration (services, versions, attack surface)
• Vulnerability analysis
• Exploitation
• Post-exploitation (privilege escalation, lateral movement, data access)
• Reporting and remediation support

Interview tip: emphasize that reporting and debriefing are part of the engagement, not an afterthought.

Reconnaissance is the information-gathering phase before and during attacks. Passive recon uses public sources without directly touching the target; active recon interacts with systems.

Examples include WHOIS, DNS enumeration, certificate transparency, Google dorking, OSINT on employees and tech stacks, subdomain discovery, and port/service identification. Good recon often determines engagement quality more than exotic exploits.

• Black Box: little or no internal knowledge — closest to an external attacker view
• White Box: full knowledge, including architecture docs, credentials, or source code — efficient for deep coverage
• Grey Box: partial knowledge, such as a standard user account — common for realistic internal or authenticated web tests

Mention that box color affects time, cost, coverage, and the kinds of findings you can reach.

CVE (Common Vulnerabilities and Exposures) is a public identifier for a known security vulnerability. Example format: CVE-2024-12345.

In interviews, connect CVEs to exploitability: not every CVE is reachable in a given environment, and prioritization should consider exposure, asset criticality, and available exploits — not only the CVE number.

CVSS (Common Vulnerability Scoring System) provides a standardized severity score for vulnerabilities, typically 0.0–10.0.

Explain base score components at a high level (exploitability and impact) and note that business context can raise or lower real priority versus the raw CVSS number.

Exploitation is taking advantage of a vulnerability to achieve unauthorized access, code execution, data exposure, or other attacker goals within the authorized scope.

Professional pentesters document steps, minimize operational risk, avoid destructive actions unless approved, and capture evidence for the report.

Privilege escalation is moving from a lower-privileged context to higher privileges after initial access — for example, from a standard user to local admin, or from a compromised host to domain admin.

Mention common Windows and Linux themes: weak service permissions, unquoted service paths, sudo misconfigurations, kernel issues, credential dumping, and token impersonation.

Lateral movement is expanding access from one compromised system to other systems in the environment to reach higher-value targets.

Techniques can include Pass-the-Hash, remote service abuse, RDP/WinRM, SSH key reuse, and living-off-the-land binaries. Defenders look for unusual authentication patterns; attackers look for trust relationships and reusable credentials.

The OWASP Top 10 is a consensus list of the most critical web application security risks. A current high-level set includes:

• Broken Access Control
• Cryptographic Failures
• Injection
• Insecure Design
• Security Misconfiguration
• Vulnerable and Outdated Components
• Identification and Authentication Failures
• Software and Data Integrity Failures
• Security Logging and Monitoring Failures
• Server-Side Request Forgery (SSRF)

Interviewers often ask you to explain one risk with a real example and a remediation, not just recite names.

Tool choice depends on scope, but common categories include:

• Recon/scanning: Nmap, Masscan, Amass, subfinder, httpx
• Web testing: Burp Suite, OWASP ZAP, ffuf, Gobuster, sqlmap, Nuclei
• Network/exploit frameworks: Metasploit, Impacket, CrackMapExec/NetExec
• AD/internal: BloodHound, Rubeus, Mimikatz (authorized contexts), Responder
• Traffic analysis: Wireshark, tcpdump
• Custom: Python/Bash scripts for unique app logic

Strong answer: tools accelerate work; methodology and manual validation prevent false confidence.

SQL Injection occurs when untrusted input is interpreted as part of a SQL query, allowing attackers to read, modify, or destroy data, and sometimes achieve RCE via database features.

Discuss types (in-band, blind, out-of-band), detection (error-based, boolean/time-based), and fixes: parameterized queries/prepared statements, least-privilege DB accounts, input validation as defense-in-depth, and WAF only as a compensating control.

XSS lets an attacker execute script in a victim’s browser in the context of a trusted site. Main types: Stored, Reflected, and DOM-based.

Impact includes session theft, account takeover actions, phishing inside the app, and malware delivery. Mitigations: context-aware output encoding, CSP, HttpOnly/Secure cookies, and avoiding dangerous sinks in JavaScript.

Cross-Site Request Forgery tricks a victim’s browser into sending authenticated requests to a target site without the user’s intent.

Classic defenses: anti-CSRF tokens synchronized with the session, SameSite cookies, re-authentication for sensitive actions, and avoiding state-changing GET requests.

Server-Side Request Forgery forces a server-side component to make HTTP (or other protocol) requests to attacker-chosen destinations.

Impact can include cloud metadata credential theft, internal port scanning, and access to admin panels not exposed externally. Defenses: allowlists, block internal IP ranges/metadata IPs, disable unnecessary URL fetch features, and network segmentation.

Insecure Direct Object Reference is an access-control failure where changing an object identifier (user id, invoice id, file name) grants unauthorized access to another user’s data.

Test by swapping IDs across accounts and roles. Fix with server-side authorization checks on every object access, unpredictable identifiers as a weak secondary control, and consistent deny-by-default access logic.

RCE allows an attacker to execute arbitrary commands or code on a target system remotely. It is among the highest-impact findings because it often leads to full host compromise.

Causes include unsafe deserialization, command injection, template injection, unpatched services, and file upload flaws. Always describe containment, evidence, and business impact in interviews.

Command injection occurs when application input is passed to a system shell or command interpreter without proper separation, enabling OS command execution.

Contrast with code injection and SQLi. Mitigations: avoid shells, use safe APIs with argument arrays, strict allowlists, least privilege, and input validation that never relies on blacklists alone.

Authentication verifies identity (who you are). Authorization decides what an authenticated identity is allowed to do (what you can access).

Many critical bugs are authorization failures after successful login — IDOR, privilege escalation, and broken function-level access control. Interviewers love candidates who test both.

Kerberos is the primary authentication protocol in Active Directory. Clients obtain tickets from a Key Distribution Center (KDC) to prove identity to services without sending passwords to every host.

Key terms: AS-REQ/AS-REP, TGT, TGS, SPN, and the KRBTGT account. Many modern AD attacks abuse ticket material or weak service account passwords.

NTLM is a legacy Windows authentication protocol still encountered in many environments for compatibility.

It is relevant to Pass-the-Hash, NTLM relay, and coerced authentication attacks. Hardening includes reducing NTLM usage, SMB signing, LDAP signing/channel binding, and monitoring NTLM authentications.

Pass-the-Hash authenticates with an NTLM password hash instead of the plaintext password, often after credential dumping from memory or disk.

It enables lateral movement when the same local admin hash is reused. Defenses: LAPS/unique local admin passwords, Credential Guard, privileged access workstations, and detecting unusual lateral auth patterns.

A Golden Ticket is a forged Kerberos TGT created with the KRBTGT account hash, granting long-lived, highly privileged domain access that can bypass normal authentication controls.

It requires deep compromise (KRBTGT secret). Recovery involves KRBTGT password resets (twice, carefully planned), hunting persistence, and rebuilding trust in the domain’s ticket-issuing path.

Kerberoasting requests service tickets for accounts with SPNs and offline-cracks them to recover service account passwords.

It thrives on weak service account passwords and over-privileged service accounts. Defenses: long random passwords or gMSA, least privilege, and detecting unusual TGS requests.

When name resolution fails, Windows hosts may broadcast LLMNR/NBT-NS queries. An attacker on the network can respond and capture or relay authentication material (often with tools like Responder).

Mitigations: disable LLMNR/NBT-NS where possible, enforce SMB signing, use strong name resolution, and monitor for poisoner activity.

CSP is an HTTP response header (and meta) mechanism that tells browsers which sources of script, style, image, and other content are allowed.

A well-designed CSP reduces XSS impact. Weak CSPs with unsafe-inline or overly broad wildcards provide limited value. Mention report-only mode for safe rollout.

Cross-Origin Resource Sharing is a browser mechanism controlling which origins may read responses from another origin using credentialed or non-credentialed requests.

Misconfigured CORS (for example, reflecting arbitrary Origin with Access-Control-Allow-Credentials: true) can enable cross-site data theft. CORS is not an authentication substitute.

Clickjacking (UI redressing) overlays or frames a target page so users click hidden actions.

Defenses include frame-busting historically, and modern protections like CSP frame-ancestors and X-Frame-Options.

XML External Entity injection abuses XML parsers that resolve external entities, potentially disclosing local files, causing SSRF-like requests, or enabling denial of service.

Fix by disabling external entity resolution and DTDs in XML parsers, and preferring safer data formats when possible.

JSON Web Tokens can be abused via algorithm confusion (alg:none or RS256/HS256 key confusion), weak signing secrets, accepting unsigned tokens, insecure kid injection, and long-lived tokens without revocation.

Hardening: explicit algorithm allowlists, strong keys, short expiry, audience/issuer validation, and secure storage on the client.

TCP is connection-oriented and reliable (handshake, sequencing, retransmission). UDP is connectionless and lower-overhead, used where speed or simplicity matters (DNS, many real-time services).

For pentesting: TCP port states and service banners matter for enumeration; UDP scanning is noisier and less reliable, so methodology and timing matter.

ARP spoofing poisons local ARP caches so traffic is redirected through an attacker host, enabling man-in-the-middle on a LAN segment.

Related controls: dynamic ARP inspection, port security, 802.1X, and encrypted protocols that reduce sniffing value.

VLAN hopping attempts to break VLAN segmentation, historically via switch spoofing or double tagging, to reach traffic in other VLANs.

Modern hardened switch configs greatly reduce classic techniques, but misconfigured trunks and weak segmentation still appear in assessments.

SMB enumeration discovers shares, users, groups, policies, and permissions over ports 445/139 to identify attack paths.

Useful intel includes readable shares with credentials, writable shares for payload drops, and domain information that feeds BloodHound-style graphing.

Pivoting uses a compromised host as a foothold to reach networks not directly accessible from the tester’s machine — via SOCKS proxies, SSH tunnels, VPN-like tunnels, or native routing techniques.

Discuss scope boundaries: pivots must stay inside authorized ranges and be documented carefully.

Review public access blocks, bucket policies, ACLs, encryption (SSE-S3/SSE-KMS), logging, versioning, and whether sensitive prefixes are exposed via misconfigured policies or static website hosting.

Also check for overly broad IAM principals and cross-account access. Public list/get on sensitive data is a classic critical finding.

Cloud instances expose a metadata service (for example, AWS IMDS) that can provide temporary credentials and instance identity data.

If an app is vulnerable to SSRF or an attacker gains code execution on the instance, they may query metadata to steal roles. IMDSv2 hop-limit controls and blocking instance metadata from app layers are key defenses.

Common issues: containers run as root, privileged containers, exposed Docker sockets, weak image supply chain, secrets in images/env vars, and breakout risks from kernel sharing.

Recommend least privilege, read-only filesystems where possible, image scanning, and not mounting docker.sock into untrusted containers.

Identity and Access Management misconfiguration means users, roles, or policies grant excessive permissions — for example, wildcards on sensitive actions, privilege escalation paths through iam:PassRole, or public principals.

Cloud pentests often focus on identity graph abuse more than classic network exploits.

Broken Object Level Authorization (OWASP API1) is unauthorized access to API objects by manipulating object IDs — essentially IDOR for APIs.

Test with two users: authenticate as user A, request user B’s resources by ID. Fix with authorization checks on every object reference, every time.

• API keys (simple, often overexposed in clients)
• HTTP Basic (rarely appropriate alone for public APIs)
• JWT bearer tokens
• OAuth 2.0 / OIDC
• mTLS for service-to-service

Discuss token storage, rotation, scope limitation, and replay risks.

GraphQL risks include introspection exposure in production, overly deep nested queries (DoS), batching abuse, injection via resolvers, and broken authorization at field/object level.

Controls: disable or protect introspection, query depth/cost limits, strong authZ in resolvers, and least-privilege data access.

API fuzzing sends unexpected, malformed, or boundary inputs to endpoints to discover crashes, validation gaps, injection points, and logic bugs.

Combine schema-aware testing (OpenAPI/GraphQL) with auth-context switching. Fuzzing finds anomalies; manual analysis proves impact.

A professional report typically includes: engagement overview and scope, methodology, executive summary, technical findings with evidence, risk ratings, reproduction steps, impact, remediation, and appendices (tools, timelines, raw data as appropriate).

Write for two audiences: executives need business risk; engineers need fix guidance.

High-level scope, overall security posture narrative, the most important risks in business language, potential impact scenarios, and prioritized recommendations.

Avoid dumping CVEs without context. Executives should understand what matters this quarter.

A PoC is reproducible evidence that a vulnerability is real — screenshots, requests/responses, short scripts, or redacted data access proofs.

Good PoCs are minimal, safe, and clear enough that a developer can reproduce and verify the fix.

Combine severity (CVSS or similar), exploitability, asset criticality, exposure (internet-facing vs internal), and business impact.

A medium CVSS on a public payment API may outrank a high CVSS on an isolated lab host. Mention compensating controls and attacker prerequisites honestly.

Give a 60–90 second structured pitch: background → security focus area (web/AD/cloud) → hands-on proof (labs, CTFs, projects, internships) → what role you want and why this company.

Avoid reciting your entire resume. End with enthusiasm for authorized offensive work and clear reporting.

Connect curiosity about how systems fail with a professional ethic: helping organizations fix issues before criminals abuse them.

Mention enjoyment of methodology, puzzle-solving, and communicating risk. Avoid sounding like you only want to “hack things” without client outcomes.

List role-aligned credentials honestly (for example CEEH, KLSFP, CKCC, eJPT, OSCP, PNPT) and immediately pair each with practical proof — labs, write-ups, or engagements.

If still preparing, say what you are studying and what you can already demonstrate.

Describe architecture (hypervisor, vulnerable targets, AD lab, Kali/attacker host, logging if any), what attacks you practice, and what you documented.

Interviewers listen for intentional design and learning outcomes, not just “I installed Kali.”