Penetration Tester Interview Questions: Web, Network and Active Directory

Penetration testing interviews reward candidates who can explain why a weakness exists, how they would prove it safely and what the client should fix, yet most question lists online only check whether you know tool names. This guide gives the questions hiring panels ask across web application, internal network and Active Directory testing, with model answers that show the depth expected from junior, mid-level and senior testers. It also covers scoping and rules of engagement questions, reporting and risk rating, the practical exercises firms use, and a scoring rubric for interviewers. Answers explain concepts and detection, not exploitation steps: panels want reasoning and judgement, and nothing here is a walkthrough. It is for candidates preparing for consultancy or in-house offensive security roles and for managers who want a fair, consistent interview. The role, routes in and certifications are covered in the Penetration Tester Career Guide, and general interview preparation in the Cyber Security Interview Preparation Guide.

Key takeaways

• Root cause beats payload. Panels score whether you can say why a finding exists (missing server-side authorisation, unsigned NTLM, a weak template) and what fixes it, not how many tools you can name.
• Authorisation is the first answer. Expect at least one question on scope, written permission and what you do when you find something outside it. A wrong answer here can end the interview.
• Active Directory is identity testing. Kerberoasting, AS-REP roasting, NTLM relay, AD CS template abuse and DCSync are all about accounts and credentials, and good answers name the service accounts and settings behind them.
• Reporting is half the job. Senior candidates are asked to rate a finding, write an executive summary and handle a client who disputes a severity.
• Honesty is marked up. "I have not done that, here is how I would approach it safely" scores better than an invented answer.

What each level is tested on

Fundamentals questions and model answers

1. Walk me through your methodology for an engagement.

Model answer: "It starts before any packets: confirm scope, written authorisation, test windows, emergency contacts and what is off limits. Then reconnaissance and enumeration, vulnerability identification, careful validation of what is actually exploitable within the agreed rules, then post-exploitation only as far as scope allows, and reporting. I keep timestamped notes of every action so the client can match my activity to their logs. For web I follow the OWASP Web Security Testing Guide structure; for broader assessments NIST SP 800-115 describes planning, executing and reporting on technical tests." Mentioning PTES or OSSTMM is fine; what matters is showing the phases and the paperwork.

2. What do you do if you find a system that looks out of scope but is clearly vulnerable?

Model answer: "Stop testing it and tell the client contact. If it is connected to in-scope systems, the risk owner can expand the scope, usually with extra time, or record it as a limitation in the report. I never test it on the assumption that permission would be given." This mirrors the NCSC's guidance that out-of-scope components affecting in-scope systems are a decision for the risk owner.

3. Name the ports you expect on an internal Windows network and why each matters.

Model answer: "88 Kerberos and 389 LDAP (636 for LDAPS) point to domain controllers; 445 SMB for file shares and remote administration; 135 RPC endpoint mapper; 3389 RDP; 5985 and 5986 WinRM; 1433 SQL Server; 53 DNS. The interesting findings are configuration: SMB without signing required, LDAP without signing or channel binding, RDP open broadly, management interfaces reachable from user VLANs." See the Network Segmentation Testing Guide.

4. What is the difference between authentication and authorisation, and why do testers care?

Model answer: "Authentication proves who you are; authorisation decides what you may do. Many serious web findings are authorisation failures where the user is correctly logged in but the server does not check they own the object they request. Broken Access Control is A01 in the OWASP Top 10:2025, so I test every function with at least two users of different roles."

5. How do you avoid causing an outage?

Model answer: "Agree in the rules of engagement what is not allowed, such as denial of service, account lockout or changes to production data. Check the password lockout policy before any password guessing and stay well below it. Throttle scans on fragile systems, avoid destructive tests on production, and tell the client contact immediately if something behaves oddly. " The Red Team Rules of Engagement Template shows the clauses panels expect you to know.

Web application questions and model answers

6. How do you test for broken access control?

Model answer: "Map every function and object identifier, then replay requests as a lower privileged user, as a different user at the same level, and unauthenticated. I look for insecure direct object references, where changing an ID returns another user's data, and for function-level gaps, where an admin endpoint works for a normal user because only the menu was hidden. The fix is a server-side check on every request, deny by default, tied to the authenticated session, not the client." See the Broken Access Control Prevention Guide.

7. Explain SQL injection and what the correct fix is.

Model answer: "User input is concatenated into a query so the database treats data as code. I confirm it with safe tests that change the query's logic or timing, not by dumping data, unless the client agreed to a limited proof. The fix is parameterised queries or safely built stored procedures, with least-privilege database accounts to reduce impact. Input filtering or a web application firewall is defence in depth, not the fix." See the SQL Injection Prevention Guide.

8. What is server-side request forgery and why does it matter in the cloud?

Model answer: "SSRF is when the application can be made to send requests to a destination the attacker chooses. In cloud environments the classic impact is reaching the instance metadata service and obtaining the workload's temporary credentials, which turns a web bug into cloud access. Defences are allow-lists of destinations, blocking internal ranges, and requiring session-oriented metadata access such as IMDSv2 on AWS." See the SSRF Prevention Guide.

9. How do you assess a JSON Web Token used for sessions?

Model answer: "Decode it and check the claims: issuer, audience, expiry and whether sensitive data sits in the payload, which is only encoded, not encrypted. Then check how the server validates it: does it enforce the expected algorithm, reject unsigned tokens, check the signature with the right key, and honour expiry and revocation? Long lifetimes with no server-side revocation are a finding even when the signature handling is correct." See the JWT Security Guide.

Network and infrastructure questions and model answers

10. You plug into the internal network with no credentials. What is your approach?

Model answer: "Confirm the rules of engagement allow it, then passive listening first: broadcast and multicast traffic shows hostnames, domain names and name resolution protocols such as LLMNR and NetBIOS name service. Then careful discovery of live hosts and services within the agreed rate. Common routes to a first credential are name resolution poisoning where those protocols are enabled, relaying authentication to hosts that do not require signing, and default credentials on devices. I report the configuration that made each possible, for example LLMNR enabled or SMB signing not required." This maps to ATT&CK T1557.001 Name Resolution Poisoning and SMB Relay.

11. What is NTLM relay and what stops it?

Model answer: "The attacker sits between a client and a server and forwards the client's NTLM authentication to a different service, authenticating as the victim without knowing the password. It works where the target does not require message signing or channel binding. Fixes are requiring SMB signing, LDAP signing and channel binding, Extended Protection for Authentication on web services, disabling NTLM where possible, and removing coercion paths that force machines to authenticate (T1187 Forced Authentication)." See the NTLM Relay Guide.

12. What is pass-the-hash and why does Windows LAPS reduce its impact?

Model answer: "NTLM accepts the password hash as proof, so a stolen hash can be reused without cracking it (T1550.002). The common amplifier is the same local administrator password on every machine: one hash then opens the whole estate. Windows LAPS rotates a unique local administrator password per device and backs it up to Active Directory or Microsoft Entra ID, which breaks that lateral movement. I would report a shared local admin password as a finding with LAPS as the remediation." See the Windows LAPS Guide.

13. How do you rate a finding?

Model answer: "Likelihood and impact in the client's context, not a raw scanner score. I give a CVSS v4.0 vector where useful, saying whether it is base only or includes threat and environmental metrics, because a CVSS-B score alone overstates or understates real risk. NCSC guidance for CHECK reports uses high, medium, low and informational ratings, with CVSS allowed alongside but not as a substitute. I explain any deviation from the standard rating." See the CVSS v4 Guide.

Active Directory questions and model answers

Active Directory rounds are where identity knowledge shows. Panels expect the technique, the account or setting that makes it possible, how defenders see it, and the fix. Background on the directory itself is in Active Directory Fundamentals.

14. Explain Kerberoasting and how you would advise the client.

Model answer: "Any authenticated user can request a service ticket for an account with a service principal name. Part of that ticket is encrypted with a key derived from the service account's password, so it can be cracked offline (T1558.003). The real finding is a user-type service account with a weak, never-rotated password and often high privileges. Fixes: group managed service accounts or long random passwords, AES-only encryption types, removing unneeded SPNs and privileges, and monitoring event 4769 for unusual ticket requests, especially RC4." See the Kerberoasting and AS-REP Roasting Defence Guide.

15. What is an attack path, and how do you present one?

Model answer: "A chain of relationships, such as group membership, local admin rights, sessions and delegated permissions on objects, that leads from a low privileged account to a sensitive one. I present the shortest path with each edge explained and the one or two changes that break it, rather than listing every step. Graph tools make the path visible, but the report has to explain the misconfiguration, for example a helpdesk group with GenericAll on a privileged group." See the BloodHound and Active Directory Attack Path Guide and the Active Directory ACL and Delegation Hygiene Guide.

16. What are the common weaknesses in Active Directory Certificate Services?

Model answer: "Certificate templates that let a low privileged user enrol and supply their own subject name for a client authentication certificate, overly broad enrolment or write permissions on templates, and weak CA configuration. The impact is a certificate that authenticates as a privileged account and survives a password reset (T1649 Steal or Forge Authentication Certificates). The advice is to audit templates and permissions, require manager approval on sensitive templates, apply strong certificate mapping, and monitor certificate issuance events." See the AD CS Security Guide and How to audit AD CS certificate templates.

17. What is DCSync and what does a defender see?

Model answer: "It abuses directory replication rights to request password data from a domain controller as if the caller were another domain controller (T1003.006). It needs the replication permissions, which should be held only by domain controllers and a very small set of accounts. Defenders see directory replication requests from a host that is not a domain controller, which directory service access auditing (event 4662 with the replication rights) and network monitoring can detect. The finding I report is which non-DC principals hold those rights and how my test account reached them." See the Active Directory Domain Compromise Response Playbook.

Technique reference panels expect you to know

Where identity fits

Most internal and cloud test reports are, underneath, reports about accounts and credentials. Panels increasingly ask candidates to recognise non-human identities in their findings: service accounts with SPNs, scheduled tasks running as domain admins, credentials in scripts on file shares, API keys in web application configuration and cloud workload roles reachable through SSRF. A strong answer to "what would you prioritise in the report?" names the account, its owner if known, what it can reach and how to replace a static secret with a managed one. Testers also hold credentials themselves: the test accounts and API keys a client issues for an engagement should be time-bound, logged and removed at the end, and the report should confirm that. See the Service Account Security Guide and the guide to building a service account inventory from Active Directory.

Scenario and reporting questions

• "You have domain admin by lunchtime on day one of five. What now?" Tell the client contact, confirm whether they want you to continue looking for other paths, and use the remaining time to find independent routes and quantify impact. One path fixed is rarely the whole story.
• "You find live customer data or credentials in a file share." Stop, do not copy or exfiltrate more than the minimum needed to prove access, record the location and notify the client according to the agreed escalation route. Some findings, such as evidence of a previous compromise, need immediate escalation rather than waiting for the report.
• "The client disagrees with your critical rating." Walk through the evidence and the context assumptions; if they show a compensating control you did not know about, adjust and record why. Never change a rating just to keep the client happy.
• "Write the executive summary for this finding list." Lead with business risk and the two or three changes that remove most of it, not with technique names.
• "How do you verify a fix at retest?" Test the original condition and close variants, confirm the root cause changed rather than one instance, and record evidence with dates.

Practical exercises and how to prepare

Practise only on systems you own or on platforms built for training. Certifications such as the OSCP Certification Guide, CREST Certifications and the CompTIA PenTest+ Guide describe what each exam proves; panels still test whether you can explain your work. In the UK, government and critical national infrastructure organisations may require testers from NCSC CHECK assured companies, so expect questions about that scheme when applying to those suppliers.

For hiring managers: a scoring rubric

Use the same lab and questions for every candidate at a level, score independently before discussion, and avoid trivia about one tool's command syntax.

Framework mapping

Common failure patterns

• Reciting tools: describing which tool you would run instead of what condition you are looking for and why it matters.
• Skipping authorisation: answering a scenario without mentioning scope, permission or the client contact.
• Symptom fixes: recommending a WAF rule for SQL injection or a password change for Kerberoasting without addressing the account design.
• Severity inflation: rating every finding critical, which tells the panel you will damage client trust.
• Ignoring detection: no idea how a defender would see the activity, which matters for purple team work and for useful reports.
• Overclaiming: inventing experience. Panels often probe one answer deeply to test exactly this.

Practitioner checklist

• Be able to describe your methodology and the authorisation steps before testing.
• Explain the OWASP Top 10:2025 categories with one root cause and fix each.
• Know the Windows ports and the signing settings that stop relay attacks.
• Explain Kerberoasting, AS-REP roasting, NTLM relay, AD CS template abuse and DCSync with the fix and defender signal for each.
• Practise rating findings with context and with a CVSS v4.0 vector.
• Rewrite one finding from a sample report with evidence, root cause and remediation.
• Prepare three behavioural stories, including one mistake.
• Interviewers: use a fixed lab, fixed questions and a written rubric per level.

Standards and references

• NIST: SP 800-115 Technical Guide to Information Security Testing and Assessment
• OWASP: Web Security Testing Guide
• OWASP: Top 10:2025
• NCSC: Penetration testing
• NCSC: CHECK penetration testing
• MITRE ATT&CK: Kerberoasting
• Microsoft Learn: Windows LAPS overview
• FIRST: Common Vulnerability Scoring System v4.0

Related NHI Mgmt Group resources: Penetration Tester Career Guide · Penetration Testing Guide · Cyber Security Interview Preparation Guide · Kerberos Security Guide · IAM Engineer Interview Questions