Penetration Testing Lifecycle and Execution Questions

Comprehensive knowledge and practical skills for planning and executing time boxed security testing engagements such as penetration tests and red team exercises from initiation through reporting and closure. Candidates should be able to describe pre engagement scoping and rules of engagement, developing a testing strategy and priorities aligned to business risk, resource and timeline planning, reconnaissance and information gathering techniques, scanning and service discovery, vulnerability validation and targeted exploitation where appropriate, post exploitation activities including persistence and lateral movement considerations, evidence collection and chain of custody practices, impact assessment and risk rating, writing clear and actionable findings and prioritized remediation recommendations, communicating progress and risks to technical and non technical stakeholders, handling changes in scope and legal and ethical constraints, and conducting remediation verification and retesting. Candidates should also be able to explain how methodologies, tooling, and trade offs differ for infrastructure testing versus web application testing versus cloud and application programming interface security and physical security assessments, and how to capture lessons learned and metrics to improve future engagements.

HardTechnical

65 practiced

You collect potentially sensitive evidence during an engagement that spans multiple legal jurisdictions. Design a chain-of-custody and evidence handling process that respects cross-border data protection laws, preserves forensic integrity, documents custody and access, and covers encryption, access controls, legal sign-off points, and the process if law enforcement requests the data. Include considerations for client confidentiality and vendor handling.

Sample Answer

**Situation & Objectives**I would establish a defensible, auditable chain-of-custody (CoC) that preserves forensic integrity, complies with cross-border data protection (e.g., GDPR, CLOUD Act implications), protects client confidentiality, and defines responses to law enforcement requests.

**Process Overview**1. Evidence identification & minimization- Collect only authorized scope; document legal jurisdiction of data source.- If cross-border transfer unnecessary, keep data in-origin and perform analysis there.

2. Forensic acquisition- Use approved tools (e.g., FTK Imager, dd) with write-blockers; record UTC timestamps, operator, purpose.- Compute multiple hashes (SHA-256, SHA-1) immediately and record.

3. Immediate protection- Store raw images in encrypted containers (AES-256-GCM). Keys held in enterprise KMS with split knowledge (at least 2 admins) and HSM-backed wrapping.- Label media with tamper-evident seals and unique CoC IDs.

4. Access controls & logging- Enforce least privilege via RBAC and MFA; require Just-In-Time elevation for analysis.- All access recorded to immutable audit logs (SIEM + WORM storage) recording actor, time, action, and hash verification.

5. Documentation & sign-offs- Maintain a CoC ledger (signed digital entries) recording handoffs, transfers, and hash re-verification at each step.- Legal/compliance sign-off required before any cross-border transfer; capture written client consent and DPIA if required.

6. Cross-border & legal compliance- Map data flows to jurisdictions; if transfer is required, use standard contractual clauses or adequacy mechanisms.- Consult client counsel and our legal team; if host-country law prohibits transfer, perform in-country analysis or use neutral third-party lab.

7. Law enforcement requests- Route all requests to legal team; require subpoena/MLAT before disclosure.- Preserve evidence under legal hold; do not disclose content until cleared. If compelled, log scope of disclosure, provide only requested subset, and attempt to notify client unless prohibited.

8. Vendor & third-party handling- Onboard vendors under POA, NDA, security addenda, and maintain SOC2/ISO27001 evidence.- Vendors must follow same CoC practices, use segregated, encrypted storage, and accept audits.

**Verification & Preservation**- Periodic hash revalidation; maintain immutable backups with geographic isolation per client direction.- End-of-engagement report includes CoC ledger, raw hashes, tool versions, and legal approvals.

**Why this works**- Minimizes legal risk by mapping jurisdictions and requiring legal sign-offs.- Preserves integrity via hashing, tamper-evidence, and immutable logs.- Protects confidentiality through encryption, KMS policies, and vendor contracts.

MediumTechnical

64 practiced

You performed an exploit and collected a memory dump and several extracted binaries. Describe a secure evidence handling procedure that includes hashing algorithms to use, metadata collection (who, when, how), secure transfer and storage options, integrity verification steps, chain-of-custody records you would maintain, and how you would prepare artifacts for inclusion in a technical report while preserving confidentiality.

Sample Answer

**Overview / Goal**Provide forensically-sound handling so evidence remains authentic, confidential, and admissible while enabling technical analysis and reporting.

**Initial collection**- Record who, when, where, tool/version, target IP/hostname, acquisition method, commands used, and justification (e.g., authorized exploit X under test plan). Timestamp with UTC and capture operator ID.- Photograph any physical console/VM state if applicable.

**Hashing & verification**- Compute strong hashes immediately after capture: SHA-256 and SHA-512 (store both). Optionally compute BLAKE2b for speed. Record tool/version (e.g., sha256sum vX).- Record: file path, byte-size, hashes, creation/modification times, and collection timestamp.

**Secure transfer & storage**- Transfer only over encrypted channels (SFTP with server cert pinning, scp with key auth, or use an encrypted container). For highest assurance, use an air-gapped portable with full-disk encryption (LUKS/BitLocker) or hardware-encrypted drive.- Store originals on write-once media or in an immutable object store (WORM) with access logging. Maintain least privilege and MFA for retrieval.

**Integrity verification steps**- On every access or transfer, recompute hashes and compare to recorded values. Log verification event (who, when, purpose).- Use signed manifests: signer (tester) signs the manifest with a private key (RSA/ECDSA) and store public key fingerprint in chain-of-custody.

**Chain-of-custody**- Maintain a signed, chronological C-o-C log entries: item ID, hashes, custody change (who/from→to), timestamps, reason, transfer method, and verification results. Retain original acquisition notes and authorization documents.

**Preparing artifacts for reports**- Never embed full sensitive binaries in public reports. Provide: - Redacted/sanitized snippets or indicators of compromise (hex offsets, function names). - Hashes and manifest for reproducibility. - Secure download links with time-limited, authenticated access for authorized stakeholders; require NDA if needed.- When including samples for internal triage, package in an encrypted archive (AES-256) and share keys out-of-band.

**Best practices / Auditability**- Use immutable logging (SIEM or append-only ledger), timestamping (NTP-synced), and store signatures and manifests alongside evidence.- Retain originals until retest/closure and legal hold expiry. Provide clear destruction procedures documented and signed when authorized.

MediumTechnical

79 practiced

Draft an executive summary (2-3 sentences) for a critical finding where a web service exposes customer PII, and then list the minimal technical reproduction steps a developer would need to triage the issue. Emphasize clarity for non-technical stakeholders and actionable detail for developers while minimizing exposure of sensitive data in the report.

Sample Answer

**Executive summary (2–3 sentences)** The web service’s API endpoint /api/customers returns unredacted customer personally identifiable information (PII) — including full names, email addresses, and account numbers — to authenticated users without appropriate authorization checks, posing a high risk of data exposure. Immediate mitigation: restrict the endpoint to least-privilege roles and apply server-side filtering/redaction; rotate affected credentials and audit access logs.

**Minimal technical reproduction steps (for developers)**

1. Preconditions - Use a test account with normal user privileges (do not use real customer data). - Test in a staging environment or isolate requests to prevent exposing live PII.

2. Discover endpoint - Enumerate API endpoints (e.g., from swagger/openapi or traffic capture).

3. Reproduce request - Send authenticated request with normal user token:

bash

# Replace {BASE_URL} and {USER_TOKEN} with test values
curl -s -H "Authorization: Bearer {USER_TOKEN}" \
  -H "Accept: application/json" \
  "{BASE_URL}/api/customers?limit=1"

4. Observe response - Verify response JSON contains fields: full_name, email, account_number (use placeholders when documenting). - Example check (developer): assert response contains "account_number" key.

5. Verify access control bypass - Repeat with a lower-privilege role or revoked token; confirm data remains accessible.

6. Collect evidence safely - Redact or hash any real values before saving logs:

bash

# simple hash example for logs
echo "sensitive-value" | sha256sum

7. Recommended quick triage - Reproduce, then add server-side filtering to remove/obfuscate PII fields and enforce role checks; capture minimal logs and escalate to incident response.

EasyTechnical

90 practiced

Compare passive and active reconnaissance techniques used in the reconnaissance phase of a penetration test. For each category explain specific examples (e.g., DNS enumeration, certificate transparency logs, WHOIS, GitHub code search for passive; port scanning, banner grabbing, and service fingerprinting for active), the trade-offs in stealth, coverage, and time, and the legal or detection risks associated with active techniques.

HardTechnical

72 practiced

Design a safe testing strategy to evaluate multi-factor authentication (MFA) resilience for an application. Include how you would test fallback mechanisms (SMS, email recovery, backup codes), SSO/OAuth flows, recovery workflows, and social-engineering vectors. Explain how to validate weaknesses without exposing real user accounts or violating privacy, and what test accounts or consent processes you would require.

Sample Answer

**Approach summary**I’d build a scoped, non-destructive test plan that exercises MFA paths (primary MFA, fallbacks, SSO/OAuth, recovery) in isolated environments and with instrumented test accounts in production only when absolutely allowed and monitored.

**Test environments & accounts**- Prefer dedicated test/staging tenant mirroring production config (SMS providers, OAuth clients).- Production: create labeled test accounts (admin and user roles) with consent in writing, feature flags, and opt-in phone/email addresses controlled by the test team (simulated SMS via provider sandbox or virtual numbers, dedicated email inboxes).- Obtain written rules of engagement: allowed targets, time windows, escalation contacts, data retention and deletion, and legal sign-off.

**MFA primary + fallback tests**- Backup codes: attempt reuse, brute-force resilience (rate limits), token format validation, and invalidation on use.- SMS/email recovery: test interception scenarios using provider sandbox, simulate delivery delays, code reuse, and code predictability; verify one-time-use and expiry enforcement.- Recovery workflows: perform account recovery flows end-to-end (support ticket, identity proofing) to find privilege escalation or bypasses; validate audit trails.

**SSO / OAuth flows**- Test token exchange, redirect URI validation, state parameter enforcement, PKCE for public clients, refresh token rotation, and session fixation. Attempt token replay and misuse of OAuth client credentials in a controlled lab.

**Social-engineering vectors**- Conduct controlled phishing/smishing during engagement with pre-approved templates and targets (test accounts or consenting staff). Use double opt-in and observer witnesses for live calls. Evaluate fallback acceptance of social proofs (security questions, knowledge-based) and staff escalation behavior.

**Safety, privacy & validation**- Never use real user accounts or PII. Use synthetic or consenting test users. Log all actions centrally; notify ops and monitoring to avoid false incidents. After tests, produce reproducible PoC steps and remediation suggestions. Provide metrics: time-to-bypass, rate-limit gaps, recovery success rate, and residual risks.

**Deliverables**- Executive summary, technical findings with PoCs, risk ratings, remediation roadmap, and retest plan.

Unlock Full Question Bank

Get access to hundreds of Penetration Testing Lifecycle and Execution interview questions and detailed answers.

Join thousands of developers preparing for their dream job.