Security Assessment and Penetration Testing Questions

Covers the full spectrum of assessing and hardening systems and applications. Topics include systematic assessment methodologies such as threat modeling asset inventory scoping vulnerability identification and remediation prioritization; distinctions between vulnerability assessment and penetration testing including when to use each and what each delivers; application security testing approaches targeting common vulnerabilities and exploitation scenarios; hardening guidance for architecture configuration and access controls; severity and risk rating practices using established scoring frameworks and contextual reasoning; use of automated scanning and manual testing techniques; and how to communicate findings and remediation roadmaps to both technical teams and business stakeholders.

HardTechnical

60 practiced

Create a multi-stage adversary emulation plan mapped to MITRE ATT&CK that demonstrates data exfiltration. Include realistic initial access, persistence, privilege escalation, C2 (command-and-control) technique choices, data staging and exfiltration method, detection hypotheses, and concrete test steps that validate detection and response capabilities.

Sample Answer

**Overview / Objective**Simulate a realistic multi-stage adversary that achieves data exfiltration from a corporate Windows environment. Map each stage to MITRE ATT&CK, describe detection hypotheses, and give concrete test steps to validate detections and response.

**Stages & ATT&CK Mapping**1. Initial Access — Spearphish Attachment (T1566.001): malicious Office doc with macro.2. Execution — User Execution (T1204): macro runs PowerShell launcher.3. Persistence — Registry Run Keys (T1547.001): Create HKCU\Software\Microsoft\Windows\CurrentVersion\Run entry.4. Privilege Escalation — Exploitation for Privilege Escalation (T1068) / Token Impersonation (T1134.001): leverage known local SVC misconfig or use token steal via mimikatz.5. Discovery — File and Directory Discovery (T1083), System Network Configuration Discovery (T1016).6. C2 — Encrypted Web Service (T1071.001): HTTPS to cloud-hosted domain; fallback to DNS tunneling (T1071.004) for resilience.7. Data Staging — Data Staged (T1074): compress sensitive files to %APPDATA%\Temp\stager.zip.8. Exfiltration — Exfiltration Over C2 Channel (T1041) via HTTPS POST to attacker endpoint.

**Detection Hypotheses**- Suspicious macro execution: Office spawning PowerShell child process.- Abnormal Run key creation by Office processes.- Process injecting or reading lsass.exe or creating tokens.- Persistent outbound HTTPS to low-reputation domain with POSTs containing large encoded payloads.- DNS TXT requests at high volume / unusual size (DNS tunneling).

**Concrete Test Steps**1. Email spearphish with benign-but-instrumented macro that logs telemetry to test server; verify EDR flags Office->PowerShell parent-child and macro execution event.2. Create the Run key via scripted payload; confirm registry-write alert and endpoint monitor detection.3. Execute privilege escalation PoC in controlled VM; ensure syscall/ETW traces captured, alert on TPR/T1018 anomalies.4. Stage files into encrypted zip; run upload via HTTPS to test endpoint; monitor network logs, IDS for POST size/anomaly, and SIEM correlation.5. Activate DNS-tunnel fallback using iodine; validate DNS resolver logs, DNS anomaly alerts, and exfiltration blocking.6. Run full chain in isolated lab; measure detection latency, alert fidelity, and incident response playbook (isolate host, collect triage artifacts, block C2 domain, revoke credentials).

**Metrics & Success Criteria**- Detection coverage per ATT&CK technique (target ≥90% instrumented alerts)- Mean time to detect < 15 min; time to contain < 30 min- False positives measured and tuned during iterations

**Safety & Rules of Engagement**Run only in lab or with explicit authorization; use non-production data; notify SOC and stakeholders prior to execution.

EasyTechnical

54 practiced

List the common system hardening steps you would apply to a newly provisioned Linux server before it goes into production. Include configuration changes (e.g., SSH), service minimization, file permissions, logging/monitoring considerations, and how these steps help reduce the attack surface during an assessment.

Sample Answer

**Approach (brief)** I’d follow a least-privilege, defense-in-depth checklist: minimize services, lock down configs, harden accounts and files, enforce logging/monitoring, and apply automated drift controls.

**Configuration & access controls**- SSH: disable root login (PermitRootLogin no), use key-based auth, disable password auth (PasswordAuthentication no), restrict algorithms, enable AllowUsers/AllowGroups, change default port only as obfuscation, enable Fail2Ban/sshguard.- Configure sudo to require password, limit NOPASSWD, use role accounts and RBAC where possible.

**Service minimization**- Remove/stop/disable unnecessary packages and daemons (e.g., cups, avahi, ftp, telnet).- Use systemd masking for high-risk services.

**File permissions & accounts**- Enforce umask, secure /etc/ssh/authorized_keys, restrict /etc/sudoers (visudo), ensure /tmp, /var/tmp mounted with noexec,nosuid,nodev where feasible.- Remove default accounts, lock inactive users, enforce strong password policy and PAM controls.

**Patching & configuration management**- Enable automated security updates or scheduled patching, use CIS benchmarks, manage via Ansible/Chef for consistency.

**Logging, monitoring, and auditing**- Centralize logs (rsyslog/Fluentd -> SIEM), enable auditd with rules for privileged actions, monitor auth logs, file integrity (AIDE/OSSEC), alerting for anomalies, retain logs securely.

**Network & kernel hardening**- Configure firewall (ufw/iptables/nft) with deny-by-default, limit inbound services, rate-limit SSH, disable IPv6 if unused, enable SELinux/AppArmor, kernel tunables (sysctl) to harden networking.

**How these reduce attack surface**- Fewer services = fewer exploitable code paths. Strict SSH and account controls reduce credential/remote compromise risk. File perms and mounts limit lateral privilege escalation. Centralized logging and FIM increase detection and response speed, turning unknown compromises into observable events. Configuration management and benchmarks ensure repeatable, auditable hardening so drift and misconfigurations are minimized.

MediumTechnical

48 practiced

Explain how you would assess third-party dependencies and supply-chain risk for an application. Cover creation and use of an SBOM, static and dynamic SCA tools, version pinning, dependency update policies, and how to handle transitive dependencies or private packages in CI/CD.

Sample Answer

**Overview — goal**I’d build a repeatable, automated process to identify, assess, and remediate supply‑chain risk for all third‑party components used by an application.

**SBOM creation & use**- Generate SBOMs (CycloneDX/SPDX) at build time for each artifact (container, binary, library).- Store SBOMs in an immutable artifact repo and feed them to downstream SCA tools and vulnerability intelligence (NVD, vendor advisories, internal threat intel).- Use SBOMs for impact analysis during incidents (quickly map vulnerable components to deployed systems).

**Static vs Dynamic SCA**- Static SCA: integrate into CI to scan source and dependency manifests (npm, pom, go.mod) for known CVEs, license issues, and risky patterns before merge.- Dynamic SCA: run runtime instrumentation and eBPF/agent-based detection in staging/production to catch behavior-based supply-chain attacks (malicious network calls, unexpected file writes).- Correlate results: prioritize findings that appear in both static and dynamic scans.

**Version pinning & update policy**- Pin direct dependencies to specific patched versions; use caret/tilde with strict policies only for non-prod.- Adopt a policy: automatic patch PRs for high/critical CVEs; weekly scheduled dependency updates for minor fixes; quarterly dependency review for major upgrades.- Require PRs to include SBOM diffs and automated test gates.

**Transitive deps & private packages in CI/CD**- Fail builds on critical transitive CVEs unless approved via risk exception; maintain a transitive-dependency whitelist and mitigation backlog.- For private packages: authenticate CI to internal registries, cache vetted artifacts, and include their SBOMs in pipeline. Use ephemeral creds and rotate tokens.- Add runtime allowlists and network segmentation for third-party components to reduce blast radius.

**Metrics & governance**- Track MTTR for dependency fixes, % artifacts with SBOM, and number of blocked builds due to supply‑chain findings. Use these to drive continuous improvement.

HardTechnical

45 practiced

Leadership/ethics scenario: During a penetration test you discover a zero-day that could be weaponized and that overlaps with an active bug bounty program where disclosure rules differ. Discuss legal and ethical considerations, disclosure timelines, coordination with legal/bug-bounty teams, whether to pause testing, and how to make transparent decisions that protect the organization while respecting third-party programs.

Sample Answer

**Situation (context)** During an authorized penetration test I discovered a previously unknown remote code execution vulnerability (zero-day) in a component we use. The same component is covered by an active third‑party bug‑bounty program whose disclosure rules differ from our contract.

**Task (goal)** Protect the organization and users, avoid accidental weaponization or legal exposure, and coordinate disclosure so fixes occur promptly while respecting the bounty program and any contractual/legal constraints.

**Actions (steped approach)**

- Immediate risk control: paused any exploit development that would increase exposure, preserved logs and reproducible PoC under strict access control, and stopped automated scans that might be noisy. Principle: avoid expanding the blast radius.- Legal & leadership: notified the engagement owner, CISO and corporate counsel within 24 hours with a factual incident brief (scope, reproducible steps, risk impact). Requested legal guidance on contractual limits and nondisclosure obligations.- Triage & severity: performed impact analysis (exploitability, affected assets, exposure) and assigned CVSS-style urgency to inform timelines.- Coordinate with bug‑bounty/vendor teams: reviewed the third‑party program’s policy and vendor disclosure SLA. If the bounty’s public disclosure rules conflict with our contractual NDA or incident-handling policy, worked with counsel to request a temporary embargo or coordinated disclosure through the vendor/platform (e.g., private report with “do not disclose” until patch).- Disclosure timeline & process: proposed a staged timeline — immediate private notification to vendor/platform and legal, remediation window agreed (e.g., 30/60 days depending on severity), weekly status updates, and public disclosure only after fix or agreed deadline. Documented all communications and decisions.- Decision transparency: convened a short cross-functional meeting (security, legal, engineering, product, and program owner) to approve the plan; captured rationale, risks, and mitigation steps in a decision memo. If pausing testing or withholding PoC was required, recorded legal guidance and approvals.

**Result & learnings** This approach balanced rapid remediation with legal/ethical obligations: we limited weaponization risk, adhered to contractual NDAs, and coordinated with the bounty/vendor to produce a patch before public disclosure. Lessons: codify escalation and embargo workflows in engagement contracts, include explicit clauses about overlapping external programs, and maintain a runbook for zero‑days discovered during assessments.

**Ethical principles applied** - Do no harm: minimize exploitation and exposure - Duty to protect users and assets over public curiosity or reputation - Transparency with internal stakeholders and affected vendors, documented and legally reviewed decisions

EasyBehavioral

45 practiced

Behavioral: Tell me about a time when you discovered a high-impact vulnerability during an assessment. Use the STAR format: describe the Situation, your Task, the Actions you took to validate and communicate the issue, and the Result including remediation and any lessons learned.

Unlock Full Question Bank

Get access to hundreds of Security Assessment and Penetration Testing interview questions and detailed answers.

Join thousands of developers preparing for their dream job.