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/Evidence & reporting/Integration & evidence
← All integration & evidence tasks

Maintain state and select the next evidence-producing test

CommandsIf → thenExplanation & examples

Needs: Explicit scope/objective and a record of observations, unknowns and available capabilities

Before interacting with a target, record

# Before interacting with a target, record
scope and explicit exclusions
objective and required evidence
starting identity/credential and whether it is local, domain or application scoped
source host, interface, route and DNS context
allowed/restricted tools and the current Metasploit target decision
case directory and note/evidence locations
cleanup or restoration obligations

Create a private case workspace using target-neutral names until the real scope is known

An interesting vulnerability is not automatically the objective. The attack is complete only when the required access or privilege is verified and the reproduction/evidence chain is retained.

# Create a private case workspace using target-neutral names until the real scope is known
mkdir -p case/{00-admin,01-scans,02-services,03-web,04-exploits,05-loot,06-sessions,07-screenshots,08-report}
touch case/00-admin/{scope.md,state.md,credentials.md,routes.md,hypotheses.md,transitions.md}

Client commands / example output

Do not put exam or private target material in a public repository.

# Baseline
HOSTS
- host/IP | role | reachable from | open services | evidence file

IDENTITIES
- local/domain identity | credential type | validated services | privilege | source

ROUTES
- source -> listener/tunnel -> pivot -> destination | DNS point | callback path

HYPOTHESES
- observation | hypothesis | prerequisite | next discriminating test | status

TRANSITIONS
- old state -> action -> new access/identity/route | decisive output | evidence

EVIDENCE COVERAGE
- objective | reproduction complete? | identity/IP proof? | screenshot? | panel/task state

Client commands / example output

Label each claim observed, inferred, possible, confirmed, disproven or inconclusive. Close a path only with a test that addressed its prerequisite; do not confuse a tool error with a disproven attack hypothesis.

# Baseline
Observe
→ Enumerate
→ Interpret
→ Hypothesize
→ Validate prerequisite
→ Exploit the confirmed primitive
→ Verify the new state
→ Re-enumerate from that state
→ Escalate, move or pivot
→ Capture evidence and cleanup

# The coverage queue prevents missed surfaces
host/source position → endpoint → confirmed application → required enumeration → state

# The hypothesis queue prevents random exploitation
observation → possible transition → prerequisite → cheapest discriminating test
→ decisive success/failure → next action
New stateMandatory re-entry
Hostname, address, interface, listener or routeDiscovery and service identification from the source position that can reach it
Credential, key, hash or ticketClassify identity/material, validate compatible access, then authenticated enumeration
Application role/sessionRevisit the same application and objects through the new authorization view
Command execution or shellVerify host/identity/network, repair the session, transfer only what is needed, start local enumeration
Administrator/root/SYSTEMRe-enumerate protected files, credentials, services, sessions, routes and domain context
Domain identity/group/rightRebuild reachable host/service/object paths and validate the specific right
Pivot or proxyRepeat discovery from the new vantage point; separately design callback and delivery routes

Create one card per distinct mechanism

Do not spend the whole assessment deepening one hypothesis while high-value coverage remains unknown. Conversely, do not keep scanning after a confirmed path only to avoid validating it.

# Create one card per distinct mechanism
Observation:
Desired state transition:
Required prerequisites:
Already confirmed:
Still unknown:
Cheapest discriminating test:
Success means:
Failure means:
Noise/change/cleanup:
Handoff if successful:
Status/evidence:
  1. Confirmed prerequisite, direct objective transition. Test first.
  2. Strong observation, one cheap missing prerequisite. Validate next.
  3. Useful information path. Prefer when it can unlock several branches.
  4. Multiple unsupported assumptions or disruptive action. Defer.
  5. Disproven prerequisite. Close until new evidence changes it.

Evidence strength overrides technique popularity. Prefer low-cost tests that split plausible explanations and create reusable information. A path that succeeds only after several unverified assumptions is not yet a high-priority path.

Verify → Every proposed action must name the uncertainty it resolves and the result that changes the decision.

If it fails → An untested assumption must remain possible/inferred, not confirmed. Record disproven contexts to avoid repeating them without new evidence. More detail ↓

If → then

  • Scanners disagree, a result is ambiguous, or a new identity changes accessible behavior → Validate uncertain results and rebuild the service queue

    Needs: A selected endpoint and a test that can resolve the decision-changing uncertainty

  • Directory relationships are too broad for manual comparison or a candidate chain needs ranking → Collect focused BloodHound data and validate an attack path

    Needs: Compatible collector/deployment, explicit scope, directory rights and separate permission/connectivity for host/session collection

  • Repeated attempts add no new evidence or several layers have been changed at once → Recover from dead ends without repeating disproven paths

    Needs: A saved last-known-working state, recorded errors and a bounded next uncertainty

  • Individual techniques are understood but the full path must be selected independently → Integrate a standalone or assumed-breach AD attack

    Needs: An assigned objective and current host/identity/route map; each next method's enabling conditions must be produced or discovered

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Maintain state and select the next evidence-producing test

USE WHEN
Several hosts, identities, routes or competing hypotheses need coordination
STARTING ACCESS
An assigned objective, scope and accumulated host/identity/route evidence
RESULT
A ranked, reproducible next-test decision with separate coverage and hypothesis queues

Recognize the clue

Inspect the current private host/identity/route notes and compare each proposed action with a named unresolved question.

For each candidate record:
HOST | IDENTITY | ROUTE | OBSERVED CAPABILITY | MISSING CONDITION | NEXT DISCRIMINATING TEST
SYNTHETIC EXAMPLE OUTPUT
Candidate A: writable object; consumer unknown
Candidate B: permitted operation; trigger verified
Coverage gap: unexamined service

Means: The ledger distinguishes an unvalidated hypothesis from an enabled candidate and a missing coverage question.

Confirm: Verify the next test resolves a stated uncertainty and its expected outcomes change the decision.

After validation
A candidate has the necessary evidence and a discriminating test: prioritize it by gain/cost/impact.
Ruled out in this context
The action repeats an unchanged disproven context: reject it as the next test.
Still inconclusive
Missing source/identity/route records require state reconstruction first.

Troubleshooting: An untested assumption must remain possible/inferred, not confirmed. Record disproven contexts to avoid repeating them without new evidence.

Additional prerequisite checks

HOST | IDENTITY | CREDENTIAL TYPE | ROUTE | OBSERVATION | HYPOTHESIS | MISSING PREREQUISITE | NEXT TEST

Before interacting with a target, record:

An interesting vulnerability is not automatically the objective. The attack is complete only when the required access or privilege is verified and the reproduction/evidence chain is retained.

Create a private case workspace using target-neutral names until the real scope is known:

Do not put exam or private target material in a public repository.

Keep target-specific values in a private case/lab record, not this public repository.

Label each claim observed, inferred, possible, confirmed, disproven or inconclusive. Close a path only with a test that addressed its prerequisite; do not confuse a tool error with a disproven attack hypothesis.

The sequence is a loop, not a one-time checklist. A state change routes work back to the relevant earlier stage:

New stateMandatory re-entry
Hostname, address, interface, listener or routeDiscovery and service identification from the source position that can reach it
Credential, key, hash or ticketClassify identity/material, validate compatible access, then authenticated enumeration
Application role/sessionRevisit the same application and objects through the new authorization view
Command execution or shellVerify host/identity/network, repair the session, transfer only what is needed, start local enumeration
Administrator/root/SYSTEMRe-enumerate protected files, credentials, services, sessions, routes and domain context
Domain identity/group/rightRebuild reachable host/service/object paths and validate the specific right
Pivot or proxyRepeat discovery from the new vantage point; separately design callback and delivery routes
Keep two queues

The coverage queue prevents missed surfaces:

The hypothesis queue prevents random exploitation:

Do not spend the whole assessment deepening one hypothesis while high-value coverage remains unknown. Conversely, do not keep scanning after a confirmed path only to avoid validating it.

Create one card per distinct mechanism:

Rank without false numerical precision:

  1. Confirmed prerequisite, direct objective transition. Test first.
  2. Strong observation, one cheap missing prerequisite. Validate next.
  3. Useful information path. Prefer when it can unlock several branches.
  4. Multiple unsupported assumptions or disruptive action. Defer.
  5. Disproven prerequisite. Close until new evidence changes it.

Evidence strength overrides technique popularity. Prefer low-cost tests that split plausible explanations and create reusable information. A path that succeeds only after several unverified assumptions is not yet a high-priority path.

Why it works

A route, credential or privilege change modifies the attack state. Coverage tests discover available behavior; hypothesis tests discriminate a proposed weakness. Mixing them hides missing prerequisites.

Worked example · hypothetical

Observation: three candidates exist but only one has a verified trigger. Test: compare required access, missing conditions, likely gain and reversibility. Illustrative output: the trigger-backed candidate is selected. Interpretation: the choice follows evidence rather than tool familiarity.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗
HomeProjectsToolsNotes
Interactive toolsOSCP notes ↗Extended OSCP workspace ↗Attack-path visualizer ↗

© 2026 Armaan. Built with curiosity.

GitHub ↗GMT+8