Exploit Development Questions

Covers the theory and practice of developing, adapting, and deploying exploits against software and systems. Candidates should demonstrate understanding of common exploitation classes such as memory corruption, logic flaws, and injection vulnerabilities, and how to build exploitation chains that combine multiple weaknesses to achieve an objective. Topics include reverse engineering binaries to identify exploitable behavior, analyzing patches to find bypasses, adapting public proof of concept exploits to specific target environments, writing custom exploit code, debugging and instrumentation techniques, and using exploitation frameworks responsibly. Interviews may also probe knowledge of mitigations and how to defeat or bypass them, safe testing practices in controlled environments, and ethical and legal considerations when developing or using exploits.

MediumTechnical

41 practiced

You receive a patch diff for an open-source component that removed a single call to a validation function. Outline the systematic approach you would use to analyze that patch to determine whether it introduced a regression that could be exploited, including automated and manual steps.

HardTechnical

42 practiced

You need to bypass Control Flow Guard (CFG) on Windows 10 to reuse existing functions for a ROP-like attack. Explain CFG's enforcement model and one practical technique an exploit developer might use to work around CFG when no direct call targets are permitted.

Sample Answer

**CFG enforcement model (concise)**

- Control Flow Guard (CFG) is a Microsoft CFI mechanism that maintains a per-module set of valid indirect-call targets (a bitmap or table generated at compile/link time). - At runtime, indirect CALL/JMPs instrumented by the compiler are checked: the target address must be listed as a CFG-allowed target for that module. If not, the runtime blocks execution (crash/terminate). - CFG is coarse-grained compared with full CFI: it allows only pre-marked functions and does not validate call-site semantics or stack state.

**High-level bypass concept (non-actionable overview)**

- When no direct call targets are permitted, attackers have used the idea of *leveraging legitimately registered call targets* rather than forging new ones. That means finding existing functions or thunks that the CFG bitmap already marks as valid and chaining them to achieve desired effects—effectively building a ROP-like chain from CFG-approved building blocks. - Practical examples at a conceptual level: - Reuse exported thunks, import-table stubs, or callback vectors that are already in the CFG allowlist as trampolines to reach other code paths. - Abuse application-registered callbacks or plugin APIs whose function pointers are validated by CFG but can be indirectly influenced to execute useful functionality. - Target JIT or dynamically generated code paths that the process legitimately marks as callable (e.g., via proper registration) to introduce desired behavior.

**Why this matters and defensive recommendations**

- These tactics exploit the gap between “allowed target” granularity and semantic control-flow integrity. Defenders should: - Enable compiler/linker options that harden CFG and use latest MSVC/OS updates. - Use stricter CFI solutions that validate call-site expectations, not just target lists. - Monitor abnormal use of callbacks, thunk registrations, and unusual chains of legitimate API calls. - Employ layered controls: DEP/ASLR, code-signing, endpoint behavior analytics, and least-privilege execution to reduce impact.

This explanation frames the attacker model and defensive mitigations without providing exploit development steps.

EasyTechnical

42 practiced

List and briefly explain common binary exploitation mitigations (NX/DEP, ASLR, stack canaries, PIE, RELRO, CFI). For each mitigation describe what it prevents and one practical technique an exploit developer might use to bypass or work around it during a penetration test.

Sample Answer

**Situation:** As a penetration tester I must know common binary mitigations, what they stop, and realistic bypass techniques.

**NX / DEP (Non‑Executable / Data Execution Prevention)**- What it prevents: Stops execution of code from data pages (stack/heap).- Bypass technique: Return‑oriented programming (ROP) chains that reuse existing executable code gadgets; or JIT spraying against JIT engines.

**ASLR (Address Space Layout Randomization)**- What it prevents: Randomizes base addresses of libs, stack, heap to prevent reliable code/gadget addresses.- Bypass technique: Information disclosure (leak pointers via format string, info leak in protocol) to defeat entropy; use partial pointer overwrites when low entropy.

**Stack canaries**- What it prevents: Detects and aborts simple stack buffer overflows by checking a known value before return.- Bypass technique: Memory disclosure to read canary value, or use non‑stack memory corruption (heap overflow, format string) or return‑oriented techniques that avoid smashing canary.

**PIE (Position Independent Executable)**- What it prevents: Randomizes the main executable’s base like ASLR.- Bypass technique: Same as ASLR — leak an executable pointer or abuse relative relocations; use brute force only where feasible.

**RELRO (Partial/Full)**- What it prevents: Protects GOT/PLT from overwrite (Partial) and makes libc relocations read‑only (Full).- Bypass technique: If Partial RELRO, overwrite GOT entries (easier). If Full, use ROP to call existing libc functions or find writable relocations, or use GOT info leaks before RELRO applied.

**CFI (Control Flow Integrity)**- What it prevents: Blocks illegal control transfers by validating targets against a CFG.- Bypass technique: Find legitimate call targets (catalog available trampolines/gadgets) or exploit logic flaws to call allowed functions with controlled arguments; or corrupt-only non‑protected metadata (e.g., data-only attacks).

Notes: In real engagements combine techniques (info leak + ROP) and always document proof‑of‑concepts and remediation recommendations.

MediumTechnical

36 practiced

Design an exploitation approach that chains a blind SQL injection (no returned data but you can observe time delays) to achieve remote code execution on the backend web server. List the stages, how you would extract data, and how you would turn that data into an RCE vector while minimizing detection.

Sample Answer

Situation and goalI’m a penetration tester tasked to chain a blind time-based SQL injection to achieve RCE on a backend web server during an authorized engagement. My aim is to describe a staged, low-noise approach while emphasizing detection avoidance and safe testing controls.

High-level stages1. Recon & stability checks- Confirm reproducible time-based injection points, parameter locations, and underlying DB type by observing consistent timing differentials.- Establish low-frequency probing cadence and obtain explicit scope authorization.

2. Reliable bitwise exfiltration- Use boolean/bitwise timing queries to extract small pieces of sensitive data (schema names, table names, column names, hashes) one bit at a time.- Prioritize high-value targets (admin credentials, config file paths) and limit queries to short windows to reduce noise.

3. Localize write primitives- Determine if DB user has file write or command-execution functions available (e.g., procedures or unsafe UDFs) via non-destructive checks.- If write primitives unavailable, enumerate reachable application file paths and upload vectors instead.

4. Build RCE vector safely- Prefer server-side file write to drop a small, minimal webshell in a non-obvious location or modify a template for command execution—but only with explicit permission.- If direct write not possible, pivot: extract credentials/config to access other services (SFTP, admin panels) to deploy payloads.

5. Post-exploitation hygiene & detection minimization- Use low-bandwidth exfiltration, randomize timing, and clean artifacts after testing.- Maintain logs of every action for the report and coordinate with defenders for live validation.

Extraction techniques (conceptual)- Time-based binary extraction (read single bits to reconstruct strings).- Chunked extraction (request fixed-length substrings to speed retrieval).- Prioritize hashes/configs over full data dumps to reduce queries.

Turning extracted data into RCE (conceptual)- If DB file-write allowed: drop a tiny command endpoint (webshell) into an application-writable directory.- If credentials obtained: authenticate to admin interfaces or services to upload legitimate functionality.- If stored procedures/UDFs available: use them to execute commands only after risk assessment.

Mitigations & ethical controls- Work within scope; avoid destructive commands.- Use throttling, jitter, and sampling to avoid IDS/IPS trigger.- Provide remediation: parameterized queries, least-privilege DB users, disable file-writing functions, monitoring of slow-query patterns.

Why this approach- Stepwise, conservative extraction reduces noise and risk.- Prioritizes high-impact artifacts and safe escalation paths.- Balances effectiveness with ethics and detection minimization, producing actionable remediation for the client.

MediumTechnical

38 practiced

Describe how you would adapt a community Metasploit or public PoC exploit to a Windows target that has DEP enabled but no ASLR. What changes are required to the exploit payload, and which techniques would you use to evade DEP on that system?

Sample Answer

**Approach summary**I would convert the community Metasploit/public PoC so the exploit no longer relies on executable stack/heap and instead uses a DEP bypass based on ROP. Because ASLR is disabled, module base addresses are predictable which simplifies gadget selection.

**Concrete steps**- Recon: confirm DEP is enabled and ASLR disabled (Process Explorer, !nxinfo / EMET info, dumpmodules). Identify non-ASLR, non-randomized modules (e.g., application EXE or old DLLs).- Payload changes: - Replace raw shellcode that expects NX-disabled memory with a payload that will be executed after a ROP chain flips memory permissions (e.g., meterpreter/staged or stageless — either works; stageless reduces reliance on network after exec). - Ensure payload is position-independent and encoded/evaded as needed.- DEP bypass technique: - Build a ROP chain using gadgets from non-ASLR modules to call VirtualProtect (or VirtualAlloc) to mark the memory region containing the payload as RWX or RX. - Typical ROP sequence: set up arguments (lpAddress, dwSize, flNewProtect = PAGE_EXECUTE_READWRITE, lpflOldProtect) via pop/pop/ret gadgets, then call VirtualProtect; then jump to the now-executable payload. - Use fixed addresses for gadgets because ASLR is off.- Integration with Metasploit: - Use msfvenom to generate raw/pure shellcode (no stack-exec assumptions) and append it after ROP chain in the exploit buffer. - Adapt exploit's EIP overwrite offsets to place ROP chain reliably; update module offsets/addresses to target binary build/version.- Hardening/evade details: - Use reliable gadgets (avoid fragile sequences), add NOP sleds/aligners, and encode payload to bypass simple signature checks. - Test iteratively in a controlled VM, verify DEP bypass with debugger (WinDbg/Immunity) and adjust for different OS/service pack versions.

**Why this works**DEP prevents direct execution of injected data; ROP uses existing executable code (gadgets) to call system APIs that change memory protections. With ASLR off, gadget addresses are stable, making ROP practical and reliable for this target.

Unlock Full Question Bank

Get access to hundreds of Exploit Development interview questions and detailed answers.

Join thousands of developers preparing for their dream job.