Maintain state and select the next evidence-producing test
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,disprovenorinconclusive. 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 state Mandatory re-entry Hostname, address, interface, listener or route Discovery and service identification from the source position that can reach it Credential, key, hash or ticket Classify identity/material, validate compatible access, then authenticated enumeration Application role/session Revisit the same application and objects through the new authorization view Command execution or shell Verify host/identity/network, repair the session, transfer only what is needed, start local enumeration Administrator/root/SYSTEM Re-enumerate protected files, credentials, services, sessions, routes and domain context Domain identity/group/right Rebuild reachable host/service/object paths and validate the specific right Pivot or proxy Repeat 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:
- Confirmed prerequisite, direct objective transition. Test first.
- Strong observation, one cheap missing prerequisite. Validate next.
- Useful information path. Prefer when it can unlock several branches.
- Multiple unsupported assumptions or disruptive action. Defer.
- 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 ↓
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
Candidate A: writable object; consumer unknown
Candidate B: permitted operation; trigger verified
Coverage gap: unexamined serviceMeans: 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 state | Mandatory re-entry |
|---|---|
| Hostname, address, interface, listener or route | Discovery and service identification from the source position that can reach it |
| Credential, key, hash or ticket | Classify identity/material, validate compatible access, then authenticated enumeration |
| Application role/session | Revisit the same application and objects through the new authorization view |
| Command execution or shell | Verify host/identity/network, repair the session, transfer only what is needed, start local enumeration |
| Administrator/root/SYSTEM | Re-enumerate protected files, credentials, services, sessions, routes and domain context |
| Domain identity/group/right | Rebuild reachable host/service/object paths and validate the specific right |
| Pivot or proxy | Repeat 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:
- Confirmed prerequisite, direct objective transition. Test first.
- Strong observation, one cheap missing prerequisite. Validate next.
- Useful information path. Prefer when it can unlock several branches.
- Multiple unsupported assumptions or disruptive action. Defer.
- 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 →