OSCP interview questions

A SUID-root binary executes with root privileges, and if it's world-writable an attacker can replace or modify it to run arbitrary code as root — a classic local privilege-escalation path. Remove the SUID bit, correct ownership and permissions, and investigate how the misconfiguration appeared, since it may indicate compromise. Encrypting the file leaves the executable path intact, and renaming it just moves the problem without removing the escalation. Neither addresses the root cause.

Rules of engagement usually exclude DoS on production, and an unplanned crash causes real business damage and can void the engagement. Verify scope first; if a destructive proof-of-concept isn't authorized, prove the vulnerability through safer means and clearly document the likely impact. Firing the exploit for a screenshot is reckless. Running it repeatedly for 'reliability metrics' multiplies the outage. Skipping it silently hides a serious, exploitable risk from the client.

Professional engagements end with full cleanup and an artifact inventory, so you don't leave new attack surface or muddy the client's environment. Leaving shells or accounts for the client to find is negligent and dangerous — a real attacker could reuse them. Keeping a backdoor 'for next time' is unethical and likely illegal. Deleting your own activity logs destroys the audit trail the client needs to validate the test and reconstruct what you did.

The point is impact: a reused or over-privileged service credential that unlocks domain admin or critical systems is the finding that matters, so test for reuse and map the privilege and lateral-movement path. Cracking every other hash first is busywork that delays the real story. Changing the service-account password is destructive, breaks production, and tips off defenders. Emailing a live credential in plaintext is itself an exposure and bad operational security.

Discovering an active intrusion is an out-of-band emergency: the rules of engagement should define an escalation path, so invoke it immediately, preserve evidence, and avoid contaminating an active incident. Continuing to test can interfere with the real attacker or destroy the very evidence responders need. Trying to evict the attacker yourself is out of scope, risky, and may tip them off. Waiting until the final report could mean days of ongoing breach and data loss.

Prove the vulnerability without harming the client or hoarding their data: show you can read arbitrary data via the DB version, schema, or a single redacted sample, then stop. Dumping the full PII dataset creates breach-notification and data-handling liability for both parties. Dropping a table is destructive and well beyond proof-of-concept. Encrypting the database and demanding a bounty is extortion, not testing — it is a crime, not a finding.

Authorization defines the engagement, so testing outside the agreed scope is potentially illegal and breaches the rules of engagement no matter how tempting the target. Document what you saw, stop, and obtain written client approval before going further. Exploiting for 'more findings' is never a justification for unauthorized access. Quietly exploiting it if you think you won't be caught is both unethical and a crime, and self-extending the scope strips the client of informed consent.

It confirms XSS. If alert() fired at all, the browser parsed and executed your injected JavaScript in the page context — that is the vulnerability. A blank/empty popup just means the string argument you passed didn't render as expected (quote handling, encoding, or context mangling broke the message), not that the payload is being blocked. The execution sink is live; you refine the payload from here.

No. CORS is not a defense against CSRF — it actually loosens the same-origin policy so a page can read cross-origin responses it otherwise couldn't. CSRF doesn't need to read the response; it just needs the victim's browser to send an authenticated state-changing request. The real defenses are anti-CSRF tokens, the SameSite cookie attribute, and checking Origin/Referer.

Filtered. A filtered port silently drops the packet, so the scanner gets no response and must wait for a timeout — it learns nothing about whether the host even exists, and scanning is slowed dramatically. A closed port sends back a TCP RST, which confirms the host is alive and responding, handing the attacker reconnaissance value for free.

Not on its own. HTTPS prevents MITM only when certificate validation is strictly enforced and the client reaches the site over HTTPS to begin with. If a rogue CA is trusted (corporate proxy, malware-installed root), if the user clicks through cert warnings, or if SSL stripping downgrades the connection to HTTP before TLS starts, an attacker can still sit in the middle.

A disassembler like Ghidra or IDA gives you the full static map: cross-references, decompiled pseudocode, and every code path whether or not it runs. A debugger like x64dbg lets you execute the sample under control — set breakpoints, inspect registers and memory, watch decryption happen, and follow the path the code actually takes with real inputs. You read structure and intent statically, then attach the debugger to resolve what static analysis cannot: runtime-decrypted strings, dynamically resolved APIs, packed payloads, and which branch a condition takes. The two together close each other's gaps.

Process injection runs malicious code inside another process to hide and to inherit trust. Classic remote injection allocates memory in a target with VirtualAllocEx, writes a payload via WriteProcessMemory, and runs it with CreateRemoteThread. Variants include DLL injection via LoadLibrary, process hollowing that unmaps a suspended legitimate process and replaces its image, APC injection that queues code to a thread, and reflective or manual-mapped loading that avoids LoadLibrary entirely. You spot them by the telltale API sequences, RWX memory in a normally-clean process, threads with no backing file on disk, and parent-child anomalies.

Unpacking recovers the original code the packer hid. For known packers you use the matching unpacker or an emulator. For custom packers you unpack manually: run the sample in a debugger, let the stub decompress the payload into memory, find the moment it jumps to the original entry point (often by breaking on memory that becomes executable, or on the tail jump), then dump the process image from memory and rebuild the import address table with a tool like Scylla or PE-sieve. The result is a runnable or analyzable PE containing the real payload.

The WSTG is a checklist-backed methodology that walks an app through testing categories: information gathering, configuration and deployment, identity and authentication, authorization, session management, input validation (injection/XSS), error handling, cryptography, business logic, and client-side. It gives systematic coverage with stable test IDs so findings are reproducible and nothing obvious gets skipped.

PTES defines seven phases: pre-engagement (scope, rules of engagement, authorization), intelligence gathering (OSINT, recon), threat modeling, vulnerability analysis, exploitation, post-exploitation (pivoting, data of value, persistence), and reporting. The structure makes engagements repeatable, defensible, and tied to business risk rather than ad-hoc hacking — pre-engagement and reporting are the phases juniors underrate.

A pentest aims for broad coverage — find as many vulnerabilities as possible in a scoped target. A red team is objective-driven adversary emulation: pick a goal (e.g., reach the crown-jewel data), emulate a specific threat actor's TTPs, stay stealthy to test detection and response, and avoid noisy scanning. Red teaming measures the blue team and the whole org, not just the asset; both need tight rules of engagement and authorization.

Start by understanding the app's threat model and where it handles untrusted input, secrets, authentication, and authorization. Use SAST to scan broadly and DAST against the running app, but treat tool output as leads, not findings — triage out false positives. Then spend human time on the high-value, context-dependent areas tools miss: authz logic, business logic, crypto usage, and trust boundaries. Trace data flow from source to sink.

Start with a full TCP port scan, then enumerate every open service in depth — banners, versions, default creds, anonymous access, and web content — before touching any exploit. Most boxes fall to thorough enumeration, not clever exploits, which is the core of the 'try harder' mindset.

The default nmap scan only covers the top 1000 ports, so a service on a high port would be missed entirely. The efficient pattern is a fast SYN scan of all 65535 ports first, then a focused version and default-script scan against only the ports found open.

Enumerate systematically: check sudo -l, SUID/SGID binaries, cron jobs, the kernel and OS version, writable files in privileged paths, capabilities, and stored credentials. Tools like LinPEAS automate the sweep, but you still verify each finding against GTFOBins or a known technique.

Map the exact service and version, search Exploit-DB or searchsploit for a matching PoC, then read the code line by line before running it — fix the target IP, port, and reverse-shell address, regenerate any shellcode, and understand what it does so it cannot backfire on you.

First identify the hash format (hashid or context), then run hashcat or John with the correct mode against a wordlist like rockyou, applying rules to mutate candidates. Use the right format flag (NTLM, sha512crypt, NetNTLMv2, etc.) so the tool hashes guesses the same way the target did.

Use the compromised host as a relay into the unreachable subnet. Set up port forwarding for a single service, or a dynamic SOCKS proxy (SSH -D or chisel) and route your tools through it with proxychains, so your attacker box can reach internal hosts via the pivot.

For SMB, enumerate shares, check for anonymous/null-session access, list users, and identify the version for known CVEs. For SNMP, try default community strings like 'public' and walk the MIB to extract usernames, running processes, installed software, and network details.

Spawn a pseudo-terminal (commonly python -c 'import pty; pty.spawn("/bin/bash")'), background it with Ctrl-Z, run stty raw -echo on your local side, foreground it, and reset TERM and the rows/columns. That gives you a full TTY with job control, tab completion, and working editors.

Identify the stack from headers and source, then brute force directories and files with gobuster or feroxbuster using a good wordlist and relevant extensions. Look for admin panels, backups, config files, and upload points, and check virtual hosts when the site responds to a hostname.

Enumerate current privileges (whoami /priv), misconfigured services (weak permissions, unquoted service paths), AlwaysInstallElevated, scheduled tasks, stored credentials, and missing patches. WinPEAS or PowerUp automates the sweep; token-privilege abuses like SeImpersonate are common high-value wins.

Individually, SQLi exposes or modifies data and can reach RCE; stored XSS hijacks sessions in victims' browsers. Chained, you can use SQLi to plant a stored XSS payload that fires in an admin's session, steal their session, and escalate to full application control.

Any authenticated domain user can request a Kerberos service ticket (TGS) for any account with an SPN. That ticket is encrypted with the service account's NTLM password hash, so you extract it and crack the password offline — no privileged access needed to start, and it's near-silent.

Passive reconnaissance gathers information without directly interacting with the target's systems — OSINT, DNS records, certificate transparency. Active reconnaissance touches the target, like port scanning or banner grabbing, which is noisier but yields more detail.

A pentest moves through pre-engagement (scope and rules of engagement), reconnaissance, scanning and enumeration, exploitation, post-exploitation, and reporting. Each phase feeds the next, and reporting is where the value is actually delivered to the client.

Pivoting turns a compromised host into a relay so you can reach internal segments your machine can't route to. You use port forwarding, a SOCKS proxy over your C2 channel (e.g. Chisel, SSH dynamic forwarding), or agent-based routing, then run tools through that tunnel to attack the next subnet.

Enumerate first: current privileges, sudo rights, SUID/SGID binaries, cron jobs, writable files in PATH, kernel version, and stored credentials. Then exploit the easiest reliable path — often a misconfigured sudo rule or a SUID GTFOBin — before reaching for a kernel exploit.

Enumerate the account's privileges and the host's misconfigurations: token privileges like SeImpersonate, unquoted service paths, weak service permissions, AlwaysInstallElevated, and stored credentials. Then abuse the most reliable one — token impersonation (Potato attacks) is a common route to SYSTEM.

A bind shell opens a listening port on the target and waits for you to connect to it. A reverse shell makes the target connect outbound to a listener you control. Reverse shells usually win because outbound traffic bypasses inbound firewall rules and NAT.

A good report serves two audiences: an executive summary that frames business risk for leadership, and detailed, reproducible findings with evidence, accurate risk ratings, and prioritized remediation for the technical team. The report — not the exploit — is the deliverable.

SQL injection lets attacker input alter a query. In-band techniques return data directly: union-based appends a UNION SELECT to pull extra columns, and error-based leaks data through database error messages. When no output is visible, attackers use blind SQLi — boolean-based infers data from true/false response differences, and time-based uses delays like SLEEP() to read data one bit at a time.