\n```\n- Why it matters for pen testers: High impact — persistent infection of many users and possible session theft.\n- Mitigation: Server-side output encoding (HTML-encode), use Content Security Policy (CSP), validate input, and use frameworks that auto-escape templates.\n\n**Reflected XSS**\n- Description: Script comes from request (URL, form) and is immediately reflected in response.\n- Common scenario: Search page that includes the query parameter in the HTML without encoding.\n- Example payload (in URL):\n```text\nhttps://example.com/search?q=\n```\n- Mitigation: Encode user-controlled data before inserting into HTML/attributes, use HTTPOnly cookies, validate input lengths/types.\n\n**DOM-based XSS**\n- Description: Client-side JS reads attacker-controlled data (location.hash, document.write) and injects into DOM unsafely.\n- Common scenario: Single-page app that does document.write(location.hash) or sets innerHTML from URL fragment.\n- Example payload (using fragment):\n```text\nhttps://example.com/app#\n```\n- Mitigation: Avoid insecure DOM sinks (innerHTML, document.write); use safe APIs (textContent, setAttribute), sanitize with a robust client-side library, enforce CSP.\n\nAs a penetration tester I demonstrate these payloads non-destructively, report reproducible steps, impact, and prioritized remediations."}},{"@type":"Question","name":"In an Active Directory environment with mitigations like constrained delegation, AS-REP hardening, and device protection in place, explain advanced techniques attackers still use to escalate privileges and move laterally: Kerberoasting/service account attacks, pass-the-ticket, forged tickets (golden ticket concepts), Silver Tickets, and abuse of misconfigured ACLs. For each technique list prerequisites, typical tools (e.g., Rubeus), detection indicators, and defensive mitigations.","acceptedAnswer":{"@type":"Answer","text":"**Context / approach (pen-tester perspective)**\nI’d explain each technique with prerequisites, common tools I’d use, what defenders can detect, and practical mitigations I’d recommend.\n\n**Kerberoasting / service-account attacks**\n- Prereqs: Any domain user that can request service tickets to SPNs; weak service-account NTLM/RC4 or long/guessable passwords.\n- Tools: GetUserSPNs.py (Impacket), Rubeus, Kerberoast, PowerView.\n- Detection: High volume of TGS requests for many SPNs from single host/account; Event 4769/4624 anomalies; unusual Kerberos pre-auth absence.\n- Mitigations: Enforce strong/unique service account passwords, use managed service accounts (gMSA), AES-only encryption, PSOs, monitor TGS request patterns.\n\n**Pass-the-Ticket (PtT)**\n- Prereqs: Compromised host memory or LSASS dump; valid TGT/TGS in memory.\n- Tools: Mimikatz, Rubeus (ptt), mimikatz sekurlsa.\n- Detection: Reuse of tickets across multiple hosts, mismatched source IPs vs. ticket issuance, unusual ticket renewals (Event 4768/4769).\n- Mitigations: Credential protection (LSASS LSA protection, Credential Guard), LAPS, restrict admin workstations, monitor for suspicious ticket use, enforce kerberos armoring (FAST).\n\n**Forged Tickets / Golden Ticket**\n- Prereqs: NTLM hash of krbtgt or ability to write to krbtgt (high privilege).\n- Tools: Mimikatz, Rubeus.\n- Detection: Tickets with abnormal lifetimes, forged SIDs, service/auth anomalies, event 4769 with impossible lifetime; SIEM correlation of krbtgt hash changes.\n- Mitigations: Protect krbtgt (tiered admin model), regularly rotate krbtgt (double reset), monitor for krbtgt account modifications, reduce TGT lifetime, strong auditing.\n\n**Silver Ticket**\n- Prereqs: NTLM hash of a service account (not krbtgt); write access or credential theft.\n- Tools: Mimikatz, Rubeus, Kekeo.\n- Detection: Access to specific services without corresponding TGS requests to KDC, forged ticket service validation failures logged on target servers.\n- Mitigations: Use strong service-account protections (gMSA), restrict service accounts to hosts, enforce channel binding/signing, monitor SPN access.\n\n**Abuse of misconfigured ACLs (AD ACL abuse)**\n- Prereqs: Domain account with excessive ACL permissions (WriteOwner, GenericAll) on objects (user, computer, krbtgt).\n- Tools: SharpHound/BloodHound, ACLEval, ADACLScanner, PowerView.\n- Detection: Unusual ACL changes (Event 5136), unexpected delegation/permission grants, BloodHound paths showing escalation via ACLs.\n- Mitigations: Regular ACL review (BloodHound/AD ACL auditing), least-privilege, deny inheritance where needed, harden privileged groups, monitor and alert on changes to sensitive ACEs.\n\nIf I’m testing, I validate detections by simulating safe, documented attacks (nonpersistent golden/silver tickets, limited-scope kerberoast) and provide concrete remediation: tiered model, managed accounts, credential protection, Kerberos hardening (AES-only, disable RC4), aggressive logging (Event 4768/4769/4776/4624/5136) and SIEM correlation."}},{"@type":"Question","name":"You are planning a 3-week external red team engagement against a 1,500-employee SaaS company. Draft a high-level engagement outline including: timeline with milestones, in-scope and out-of-scope assets, resource assignment (roles and estimated effort), reconnaissance plan, exploitation windows, and deliverables. Explain the rationale behind major scheduling and staffing decisions.","acceptedAnswer":{"@type":"Answer","text":"**Engagement outline — 3 week external red team (1,500-employee SaaS)**\n\n**Timeline & milestones**\n- Week 0 (Pre-engagement): Rules of engagement, legal sign-off, target inventory, OOB contacts, VPN/allowlist setup (2–3 business days).\n- Week 1 (Recon & initial access): Day 1–4 passive + active recon; Day 5–7 social engineering reconnaissance and phishing cadence prep; milestone: confirmed attack surface map and prioritized targets.\n- Week 2 (Exploitation & persistence): Day 8–12 external exploitation, credential harvesting, lateral techniques simulation; Day 13–14 hold/observe persistence & data exfil simulation windows.\n- Week 3 (Cleanup, validation & reporting): Day 15–17 remediation validation, replicate key findings for proof, Day 18–19 draft report, Day 20 presentation + executive debrief.\n\n**In-scope / out-of-scope**\n- In-scope: public web apps, API endpoints, externally routable infrastructure (IP ranges), corporate email, employee-facing SSO, cloud metadata endpoints, phishing to consenting user cohort.\n- Out-of-scope: production customer data stores (direct access), critical uptime systems (payment gateways) unless explicitly allowed, physical facilities.\n\n**Resource assignment & effort**\n- Lead Red Team / Senior PT (me): 40 hours/week — planning, complex exploitation, reporting.\n- 2 Pentesters (mid): 60 hours/week combined — recon, exploit dev, phishing ops.\n- Social Engineer (part-time): 20 hours total — phishing content and simulation.\n- Ops/Coordinator (client-facing): 10 hours/week — logistics, kill-switch, legal.\nRationale: 3-week cadence requires one lead plus two hands for parallel recon/exploit; social engineer for high-skill phishing; coordinator to manage safe windows.\n\n**Reconnaissance plan**\n- Passive: OSINT (subdomains, cert transparency, employee profiles, job posts), cloud footprint, DNS/WHOIS.\n- Active: Port/service scanning (rate-limited), web app crawls, SSO/IdP behavior testing, password-spraying on known corporate username lists during allowed windows.\n- Artifact collection: legitimate-looking phishing templates, harvested metadata, misconfigured cloud buckets.\n\n**Exploitation windows & safety**\n- Timeboxed exploitation windows (Day 8–12) with client-approved blackout periods and kill-switch; no destructive tests; simulated exfil using mock files and telemetry-only transfers unless explicit permission for live exfil.\n- Night/weekend low-business-impact windows for credential brute force (if allowed) to reduce business disruption.\n\n**Deliverables**\n- Executive summary (high-level risks & remediation priorities)\n- Technical report (vuln details, PoC, exploit steps, risk rating, remediation)\n- Replayable artifacts: phishing emails, scripts, screenshots, timeline of actions\n- Walkthrough/debrief session and remediation retest plan\n\nRationale: Phased schedule concentrates recon first to minimize blind exploitation risk; parallel staffing speeds up exploit development while maintaining oversight; timeboxed exploitation + kill-switch protects availability and legal exposure."}},{"@type":"Question","name":"Architect an end-to-end reconnaissance system capable of processing and continuously monitoring 50,000 customer domains. Specify components for ingestion, passive collectors (CT logs, passive DNS), active scanning orchestration, rate-limiting and scheduling, deduplication/enrichment, storage (indexing and cold storage), alerting, retention and deletion policies, operational cost considerations, and security/privacy mitigations.","acceptedAnswer":{"@type":"Answer","text":"**High-level approach**\nDesign a scalable pipeline: Ingest customer domains → passive collectors → active scanner orchestrator → dedupe/enrich → indexed store + cold archive → alerting/retention. Focus on low-noise, legal compliance, and safe testing for a pentester.\n\n**Ingestion**\n- API/CSV/webhook input with validation, customer metadata, allowed-scope flags, and SLA tier.\n- Queue (Kafka) for backpressure.\n\n**Passive collectors**\n- CT logs ingestion via Kafka consumer (Golang), store parsed certs in Redpanda; Passive DNS via commercial feeds + internal resolver logs.\n- Normalize to a canonical event schema.\n\n**Active scanning orchestration**\n- Orchestrator (Kubernetes) schedules scanner jobs (masscan, Nmap, custom probes) in isolated pods, per-customer worker pools.\n- Respect in-scope flags; use authenticated scans when authorized.\n\n**Rate-limiting & scheduling**\n- Token-bucket per-IP and per-customer; global rate-limits; scheduler enforces quiet windows and probe diversity to avoid IDS triggers.\n- Backoff on abuse reports; retry logic.\n\n**Deduplication & enrichment**\n- Dedupe by fingerprint (domain+resource+fingerprint) in Redis Bloom + stream processors (Flink).\n- Enrich with WHOIS, ASN, GeoIP, historical CT/pDNS, vulnerability DB (CVE), and tag confidence.\n\n**Storage**\n- Hot/indexed: Elasticsearch/OpenSearch for recent 90 days (fast queries/alerts).\n- Warm: compressed Parquet on S3 for 1 year with partitioning.\n- Cold: Glacier Deep Archive beyond 1 year.\n\n**Alerting**\n- Rule engine (Sigma-like) + anomaly detection ML; alerts via Slack/email/ServiceNow; severity & reproducible PoC attachments.\n- Rate-limit alerts to customers and provide dedupe.\n\n**Retention & deletion**\n- Configurable retention per customer; auto-delete from index then expire S3 lifecycle; maintain audit logs for compliance (WORM).\n\n**Operational cost**\n- Use spot instances for workers, serverless for short tasks, tiered storage to reduce costs; monitor egress and API fees for third-party feeds.\n\n**Security & privacy**\n- Legal consent model, scope flags, opt-out; encrypt data at rest and in transit (KMS); RBAC and MFA; isolation for active scans; redact PII in exports; maintain audit trails and incident response playbook.\n\nAs a pentester I'd prioritize safe active probe design, strict scope enforcement, and high-fidelity enrichment to produce actionable findings with low false-positive noise."}},{"@type":"Question","name":"Provide decision criteria to determine when an organization should run a vulnerability assessment, when to perform a full penetration test, and when to perform both. Consider compliance drivers, business criticality, known incidents, recent configuration changes, available budget, and desired coverage and frequency in your answer.","acceptedAnswer":{"@type":"Answer","text":"**Summary recommendation (role: Penetration Tester)**\n\n**When to run a Vulnerability Assessment (VA)**\n- Compliance-driven: quarterly or monthly scanning required by standards (e.g., PCI DSS) or after patch windows.\n- Low-to-medium criticality assets where breadth and frequent coverage matter.\n- Budget-limited: automated scans provide high coverage for low cost.\n- After routine configuration changes or patch deployments to detect regressions.\n- Desired cadence: frequent (weekly–monthly).\n\n**When to perform a Full Penetration Test (PT)**\n- High business criticality: internet-facing apps, payment systems, privileged AD, or crown-jewel systems.\n- Post-incident: to validate exploitability and scope of compromise.\n- Major architecture/configuration changes (new cloud infra, microservices, SSO rollout).\n- Compliance milestones that require manual exploitation evidence or attestation.\n- Budget permitting and desired depth: annual or after major releases.\n\n**When to perform Both**\n- New high-risk systems: run immediate VA for coverage, then PT for exploitability validation.\n- After breach or high-impact change where automated discovery plus manual exploitation are needed.\n- Regulatory plus business risk: e.g., regulated payment app that’s business-critical—monthly VA + annual PT.\n\n**Prioritization matrix (quick)**\n- High criticality OR recent incident OR major change → PT (and VA)\n- Compliance-only, low risk, limited budget → VA\n- Ongoing program → frequent VA + periodic PT (risk-based frequency)\n\nRationale: VA provides wide, repeatable coverage; PT proves real-world exploitability and business impact. Use risk scoring (asset criticality × exposure × threat likelihood) to set frequencies within budget."}},{"@type":"Question","name":"List three common logging and monitoring gaps you prioritize during a penetration test (e.g., missing context, retention gaps, no alerting). For each gap provide a concrete runtime detection or logging improvement that reduces the chance of undetected exploitation.","acceptedAnswer":{"@type":"Answer","text":"**Gap 1 — Missing context (what user/process/resource caused the action)** \nI prioritize adding contextual fields to logs. Improvement: enrich authentication, web, and process logs with user-id, session-id, origin IP, user agent, process parent/command line and container/pod ID. Runtime detection: deploy EDR/OS audit rules (e.g., syscall auditing or Sysmon on Windows) that emit process lineage and command-line for suspicious binaries; SIEM correlation rule flags commands from unusual parents or mismatched user+IP.\n\n**Gap 2 — Retention and completeness gaps** \nI ensure forensic timeline viability. Improvement: extend retention for auth, DNS, proxy, and kernel-level logs to >=90 days (or per threat model) and centralize immutable storage (WORM/S3 with versioning). Runtime detection: alert when expected heartbeat logs (host/agent check-ins, DNS forwarder) stop arriving for >X minutes to detect log tampering or agent failure.\n\n**Gap 3 — No alerting or only static thresholds** \nI replace static thresholds with behavioral detections. Improvement: implement anomaly-based SIEM use-cases (e.g., UEBA) for unusual lateral movement, privilege escalation, or credential stuffing. Runtime detection: ML/behavioral alerts for rare process execution, new service installs, or sudden mass authentication failures; escalate to SOC runbook with automated containment playbooks (isolate host in EDR)."}},{"@type":"Question","name":"Explain common techniques for discovering secrets in code repositories and CI pipelines. Give three practical examples of what to search for, and list immediate remediation recommendations when a secret is found in a public or private repository.","acceptedAnswer":{"@type":"Answer","text":"**Approach / common techniques**\n\n- Automated scanning: use git-secrets, truffleHog, Gitleaks, and custom regex runners against repo history and commits (including branches, tags, reflogs).\n- CI pipeline inspection: scan CI config files (GitHub Actions, GitLab CI, Jenkinsfiles) and artifacts, environment variable configurations, and build logs for leaked values.\n- Historical analysis: search commit history and large-file storage (LFS), use git-detective to find removed secrets in past commits and force-pushes.\n\n**Three practical search examples**\n1. API keys: regex for common provider patterns (AWS AKIA[0-9A-Z]{16}, GCP service account JSON blobs).\n2. Private keys / certs: PEM headers (-----BEGIN PRIVATE KEY-----) or ssh-rsa/-----BEGIN RSA PRIVATE KEY-----.\n3. Passwords/tokens in CI: plaintext values in YAML like \"secrets:\", \"env:\", \"PASSWORD=\", \"TOKEN=\".\n\n**Immediate remediation (public vs private)**\n- Public repo: assume compromise — rotate/ revoke secrets immediately, remove secret from history (git filter-repo or BFG), invalidate tokens, notify provider, reissue credentials, purge caches & recreate affected resources.\n- Private repo: still rotate/revoke; scrub history with filter-repo, force-push coordinated with team, scan other repos/CI for reuse, enforce short-lived credentials and MFA.\n- General mitigations: add secrets to vault/secret manager, enforce pre-commit hooks and CI scanning, block commits with git hooks, enable alerting and audit logs."}},{"@type":"Question","name":"You have limited high-privilege access on a host in an environment that includes a Domain Controller. Describe a cautious, prioritized plan to obtain evidence of domain compromise (for example, NTDS.dit access, credential dumps, or AD backups) while minimizing disruption to domain services and preserving chain-of-custody for evidence. Include tools, snapshot or backup strategies, what artifacts to collect, and how to validate the integrity of your evidence.","acceptedAnswer":{"@type":"Answer","text":"Situation & goal\nI’m a penetration tester with limited high‑privilege access on a host inside an AD environment. Goal: obtain admissible evidence of domain compromise (NTDS.dit, credential dumps, AD backups) while minimizing domain disruption and preserving chain‑of‑custody.\n\nApproach framework\n1. Clarify scope & authorization (explicit client-approved rules of engagement and evidence handling).\n2. Work from least disruptive → most disruptive. Prioritize volatile capture, snapshots, then disk-level extraction.\n3. Preserve integrity & chain‑of‑custody (hashes, signing, logs, documented timeline).\n\nStep‑by‑step plan\n- Recon & confirmation\n - Enumerate services, logged on users, local admins, and if DC role present using nltest, whoami, query user, nltest, dsquery (read‑only actions).\n- Volatile evidence (minimal impact)\n - Collect process list, network connections, LSASS memory, and kerberos tickets.\n - Tools: Sysinternals (procdump for LSASS), mimikatz guarded use only with justification, Tasklist/Netstat, RBCD checks.\n - Capture: memory dump of LSASS (procdump -ma) and full RAM via DumpIt or WinPMEM.\n- Snapshot / backup strategy\n - If host is virtualized, request or create VM snapshot first (hypervisor API) — label, timestamp, operator, and take cryptographic hash of snapshot file(s).\n - If physical, create a full disk image with dd or FTK Imager over the network to a controlled forensic server.\n - Prefer read‑only mounts; avoid running DC services on snapshot clones unless necessary.\n- Disk & AD artifacts\n - From snapshot/image, extract NTDS.dit, SYSTEM and SECURITY hives, Group Policy backups, VSS stores, and Windows backup files.\n - Tools: ntdsutil (careful), esedbexport, ntdsxtract, NTDSDumpEx, and replicating with Volume Shadow Copy read via vssadmin list shadows (don’t create new shadows on DC without approval).\n- Evidence handling & chain‑of‑custody\n - Log every action with timestamps, user accounts, commands, and hashes (SHA256) of all raw artifacts.\n - Transfer artifacts over encrypted channel to a dedicated forensic workstation; sign with GPG if permitted.\n - Maintain sealed media (label, serials), and a signed custody log.\n- Validation & integrity checks\n - Compute and record cryptographic hashes immediately after capture and after every transfer.\n - Reproduce key extractions on a mounted read‑only image to confirm findings.\n - Correlate artifacts: compare NTLM hashes from NTDS.dit against extracted Kerberos tickets and Windows event logs (4624/4672) to validate accounts used.\n- Minimizing disruption & safety checks\n - Avoid AD‑write operations (no DCSync unless explicitly allowed).\n - If DCSync is approved as last resort, document permission and use BloodHound/PowerView to justify minimal query scope.\n - Schedule actions during maintenance windows if required by policy.\n\nExample artifacts to collect\n- RAM dumps (LSASS, full)\n- VM snapshot or forensic disk image\n- NTDS.dit, SYSTEM, SECURITY hives\n- VSS copies, Windows backup files, AD backups\n- Relevant event logs (Security, System, Directory Service)\n- Network captures (PCAP) around compromise timeframe\n\nReporting\n- Provide a chronological, signed forensic report with hashes, reproduction steps, and recommendations to remediate and strengthen detection controls.\n\nWhy this order\n- Volatile data is lost first; snapshots/images allow repeated offline analysis; minimizing live queries reduces risk of service disruption or alerting defenders. Maintaining strict logging and hashing ensures admissibility and integrity."}},{"@type":"Question","name":"Explain the difference between red team, blue team, and purple team interaction models during exercises. For each model, describe how knowledge sharing, timelines, and expected artifacts typically differ and when you would recommend each model.","acceptedAnswer":{"@type":"Answer","text":"**Overview (brief)** \nAs a penetration tester I use three common exercise models: red team (adversary-focused), blue team (defensive validation), and purple team (collaborative). Each differs in knowledge sharing, timelines, and deliverables.\n\n**Red Team** \n- Knowledge sharing: Minimal during the exercise; blue team usually unaware to simulate real attack. Post-exercise debrief only. \n- Timelines: Long-running, stealth-oriented (days–weeks) to allow persistence and realistic TTPs. \n- Artifacts: Executive summary, detailed attack narrative/timeline, IOCs, exploited pathways, recommendations. \n- When to use: Test detection/response maturity and real-world resilience.\n\n**Blue Team** \n- Knowledge sharing: Full transparency; focus on defensive controls, detection tuning throughout. \n- Timelines: Shorter, iterative (hours–days) for playbooks and exercises. \n- Artifacts: Detection rules, incident response runbooks, gap analyses, logs and telemetry baselines. \n- When to use: Validate controls, train SOC/processes, tune monitoring.\n\n**Purple Team** \n- Knowledge sharing: Continuous and bi-directional—red and blue operate together with shared goals. \n- Timelines: Time-boxed sessions (days) with rapid feedback loops. \n- Artifacts: Joint playbooks, tuned detections, verified mitigations, attack↔detection mapping. \n- When to use: Accelerate knowledge transfer, harden detection quickly, and operationalize lessons from pen tests.\n\nRecommendation: Use red for realistic validation, blue for defensive maturity checks, and purple when you want efficient improvement and measurable detection engineering."}},{"@type":"Question","name":"During an engagement you are asked which active reconnaissance techniques are safe to run against production systems. Explain how you determine safety for activities such as intensive port scanning, vulnerability scanners, and aggressive web crawlers. Outline the steps you take to minimize impact (profiling, rate-limits, maintenance windows), obtain approvals, and detect adverse effects while scanning.","acceptedAnswer":{"@type":"Answer","text":"**Overview — How I decide what’s “safe”**\nI treat “safe” as: will not disrupt availability, data integrity, or block legitimate users. Safety is determined by asset criticality, SLA, architecture (load‑balanced, legacy, single‑threaded), and past incidents. If an asset is high‑risk (payment systems, patient records, telemetry), I default to non‑intrusive methods or staging.\n\n**Decision steps**\n- Profile the target: OS, rate limits, web app complexity, maintenance windows, public vs. internal.\n- Choose scan type based on risk: passive/OSINT → always safe; credentialed/light fingerprinting → low impact; aggressive port sweeps, intrusive auth bypass → require extra controls.\n- Prefer credentialed and authenticated scans to reduce noisy probing.\n\n**Minimizing impact**\n- Use conservative tool settings (e.g., nmap -T2 --min-parallelism, vulnerability scanner in “safe” or non‑intrusive mode).\n- Rate‑limit and throttle: small parallelism, long timeouts, randomized delays.\n- Scan subsets incrementally (small IP ranges, specific services) and monitor before expanding.\n- Run during agreed maintenance windows or low traffic periods.\n- Test first on staging or replicas where possible.\n- Whitelist scanner IPs, use dedicated scanning VLANs, and avoid authentication lockout thresholds.\n\n**Approvals & rules of engagement**\n- Obtain written Rules of Engagement (RoE) with scope, allowed tools, time windows, emergency contacts, and a kill‑switch procedure.\n- Get sign‑off from business owners, NetOps, and security operations.\n- Document rollback/mitigation steps in advance.\n\n**Detecting adverse effects**\n- Coordinate with monitoring: watch CPU, memory, latency, error rates, and IDS/IPS alerts in real time.\n- Use canary targets and synthetic transactions to detect user impact.\n- Have a real‑time channel (phone/Slack) and immediate stop criteria; halt on rising error rates, increased latency, or service degradation.\n- Post‑scan review: correlate logs, false positives, and lessons learned; adjust parameters for follow‑ups.\n\nExample: For a production web app I’d run credentialed passive checks first, then a low‑rate crawl (1 req/sec, single thread) outside peak hours, with monitoring active and written RoE signed. If anything spikes, I stop immediately and report."}}]}
InterviewStack.io LogoInterviewStack.io

Senior Penetration Tester Interview Preparation Guide - FAANG Standards

Penetration Tester
Senior
7 rounds
Updated 6/25/2026

This guide is based on general FAANG interview practices and may not reflect specific company procedures.

Senior Penetration Tester interviews at FAANG companies typically consist of 7 comprehensive rounds spanning 4-6 weeks. The process progresses strategically from initial screening through technical depth, hands-on penetration testing assessment, advanced red team scenario evaluation, security architecture understanding, behavioral leadership assessment, and final hiring manager alignment. Each round evaluates distinct competency dimensions: core security knowledge and methodology, practical exploitation and tool proficiency, strategic red team thinking, defensive security understanding, leadership and communication capabilities, and organizational fit. This structure ensures candidates possess both deep technical expertise and the maturity required for senior-level responsibility.

Interview Rounds

1

Recruiter Screening

2

Technical Phone Screen - Core Security Concepts

3

Technical Assessment - Hands-On Penetration Testing Challenge

4

Red Team Scenario and Strategic Assessment

5

Security Architecture and Defense Assessment

6

Behavioral and Leadership Interview

7

Hiring Manager Round

Frequently Asked Penetration Tester Interview Questions

Web Application Penetration Testing and Dynamic Application Security TestingEasyTechnical
56 practiced
Describe stored, reflected, and DOM-based XSS vulnerabilities. For each type, provide an example scenario where it commonly occurs, a simple payload that demonstrates the issue in a browser context, and a mitigation approach developers should implement.
Exploitation and Post ExploitationHardTechnical
22 practiced
In an Active Directory environment with mitigations like constrained delegation, AS-REP hardening, and device protection in place, explain advanced techniques attackers still use to escalate privileges and move laterally: Kerberoasting/service account attacks, pass-the-ticket, forged tickets (golden ticket concepts), Silver Tickets, and abuse of misconfigured ACLs. For each technique list prerequisites, typical tools (e.g., Rubeus), detection indicators, and defensive mitigations.
Red Team Engagement Planning and DesignMediumSystem Design
66 practiced
You are planning a 3-week external red team engagement against a 1,500-employee SaaS company. Draft a high-level engagement outline including: timeline with milestones, in-scope and out-of-scope assets, resource assignment (roles and estimated effort), reconnaissance plan, exploitation windows, and deliverables. Explain the rationale behind major scheduling and staffing decisions.
Reconnaissance and Information GatheringHardSystem Design
131 practiced
Architect an end-to-end reconnaissance system capable of processing and continuously monitoring 50,000 customer domains. Specify components for ingestion, passive collectors (CT logs, passive DNS), active scanning orchestration, rate-limiting and scheduling, deduplication/enrichment, storage (indexing and cold storage), alerting, retention and deletion policies, operational cost considerations, and security/privacy mitigations.
Vulnerability Assessment and Penetration Testing MethodologiesEasyTechnical
57 practiced
Provide decision criteria to determine when an organization should run a vulnerability assessment, when to perform a full penetration test, and when to perform both. Consider compliance drivers, business criticality, known incidents, recent configuration changes, available budget, and desired coverage and frequency in your answer.
OWASP Top Ten and CWE Top Twenty FiveEasyTechnical
40 practiced
List three common logging and monitoring gaps you prioritize during a penetration test (e.g., missing context, retention gaps, no alerting). For each gap provide a concrete runtime detection or logging improvement that reduces the chance of undetected exploitation.
Vulnerability Identification and RemediationEasyTechnical
67 practiced
Explain common techniques for discovering secrets in code repositories and CI pipelines. Give three practical examples of what to search for, and list immediate remediation recommendations when a secret is found in a public or private repository.
Exploitation and Post ExploitationHardTechnical
31 practiced
You have limited high-privilege access on a host in an environment that includes a Domain Controller. Describe a cautious, prioritized plan to obtain evidence of domain compromise (for example, NTDS.dit access, credential dumps, or AD backups) while minimizing disruption to domain services and preserving chain-of-custody for evidence. Include tools, snapshot or backup strategies, what artifacts to collect, and how to validate the integrity of your evidence.
Red Team Engagement Planning and DesignEasyTechnical
77 practiced
Explain the difference between red team, blue team, and purple team interaction models during exercises. For each model, describe how knowledge sharing, timelines, and expected artifacts typically differ and when you would recommend each model.
Reconnaissance and Information GatheringEasyTechnical
130 practiced
During an engagement you are asked which active reconnaissance techniques are safe to run against production systems. Explain how you determine safety for activities such as intensive port scanning, vulnerability scanners, and aggressive web crawlers. Outline the steps you take to minimize impact (profiling, rate-limits, maintenance windows), obtain approvals, and detect adverse effects while scanning.
Additional Information

Want to create your own tailored preparation guide using our deep research?

Get Started for Free

Interview-Ready Courses

Visual-first, interactive, structured learning paths

Browse Penetration Tester jobs

AI-enriched listings across hundreds of company career pages

Explore Jobs
Penetration Tester Interview Questions & Prep Guide | InterviewStack.io