Remote code execution, shell access and privilege escalation are different findings. A remotely triggered command can run without an interactive shell. A shell can operate with limited privileges. A successful privilege change still needs a clear statement of which account, process and boundary changed. Verify each claim separately rather than assuming a complete chain from one successful-looking response.
This guide explains how to document an authorized assessment or training exercise. It is based on official technical references checked on October 16, 2026; it reports no personal exploitation experience, tested exploit chain or measured time savings. The proposed checks and hypothetical example are not results from your systems.
What each finding does—and does not—establish
| Finding | Question to answer |
|---|---|
| Remote code execution (RCE) | What code or command ran, where, under which conditions and identity? |
| Shell access | Which interpreter or channel accepted commands, and what limits were observed? |
| Privilege escalation | Which effective permissions increased relative to the starting context? |
| Remediation verified | Which root cause and tested path were addressed, on which deployment? |
MITRE ATT&CK distinguishes command and scripting interpreter execution from the privilege-escalation objective. These classifications describe behavior; they do not verify a vulnerability on a particular asset. The table above is an editorial reporting aid, not an ATT&CK scoring system or a mandatory attack sequence.
A legitimate remote administration session is not automatically evidence of an RCE vulnerability. An application may also execute code inside a language runtime without invoking an operating-system shell. Name the mechanism actually supported by the evidence, including authentication and other prerequisites.
Define the permitted action and stopping point
NIST’s rules-of-engagement definition describes constraints and authority established before a security test. Record the approved systems, techniques, test period, data handling, escalation contact and stop conditions. Check whether command execution, interactive access and privilege testing are each permitted. A training platform’s rules or a signed assessment scope can constrain these differently.
Choose the smallest test that answers the assessment question. If execution is already demonstrated and the owner can remediate the cause, obtaining a more capable shell may add risk without necessary evidence. Pause on service disruption, unexpected sensitive data or an unapproved system. A calculator based on repeat counts, a subjective stability score and remaining minutes cannot decide whether testing is authorized or sufficient.
Verify execution before naming it RCE
For a suspected web command-injection issue, OWASP WSTG-INPV-12 covers application input reaching OS-command execution. Command injection is one mechanism, not a synonym for every form of remote code execution. Identify the input, processing component and relevant runtime before selecting an approved validation method.
Record a baseline request, the permitted test request, time and expected benign effect. Correlate the observation with application or process logs when available. Exclude ordinary reflection, cached content, queue delays and normal file-handling behavior before attributing an effect to execution. A longer response time, an HTTP error or a new file does not alone establish arbitrary command execution.
Repeating the same effect can help investigate consistency, but three repetitions do not create a universal proof threshold. A changing backend, authentication context or request path can change the result. Record which conditions were held constant and which were unresolved. Do not keep rerunning a disruptive test merely to reach a repeat count.
A hypothetical evidence comparison
Illustrative example, not a lab result: an application response contains a fresh test marker. That alone could be reflected input. A stronger record links the request identifier and time to a process-execution event for the expected component and an agreed benign result under the service account. If those records are unavailable, describe the observed response and the attribution gap instead of filling it with a success claim.
After a patch or deployment, record the actual instance, build and route reached by the request. A load-balanced response may come from a different backend. Failure to reproduce one path does not establish that every instance is fixed, and continued unexpected behavior does not identify its cause without further evidence.
Record execution identity and boundary
The Linux process-credentials reference distinguishes real, effective, saved and filesystem IDs and group membership. Keep the identity of the process that performed the action separate from an account name printed elsewhere. A limited service account can cause serious impact without being root; assess what the observed context can actually access.
The id reference describes reporting current-process user and group information when no user argument is supplied. In a permitted Linux lab session, a proposed local observation is:
idKeep that output with the session context and timestamp. It describes the invocation being observed; it is not a complete host-security assessment or proof that an earlier request ran in the same process. Do not assume identity output from your own workstation describes the remote target.
The user-namespace documentation explains that UID 0 inside a namespace can map to an unprivileged identity outside it. Record relevant mappings and confinement when the claim concerns container versus host privileges. Do not report host root from a container prompt or username alone.
Check the channel without overstating control
For an approved command channel, document how input is submitted, where standard output and errors appear, command completion behavior, working directory and process lifetime. Use agreed harmless checks to identify truncation or state changes. A dropped connection can have several causes; it does not prove that execution failed or that the application was patched.
A TCP connection, repeated small packets or a callback can help locate activity but cannot establish shell control by themselves. The related Wireshark evidence guide explains how to correlate a stream with listener and endpoint observations, including encrypted or incomplete captures.
The Linux pseudoterminal reference explains terminal-like bidirectional input and output. A PTY can change how an application handles terminal input and signals; it does not itself grant higher privileges, create persistence or prove that a channel will recover. Test only the behavior required by the task rather than treating terminal convenience as a prerequisite for every finding.
If a session ends, preserve the available evidence and follow the agreed recovery procedure. Do not add a new account, scheduled task, startup entry or alternative access method as routine “stabilization.” Any additional access needs its own scope justification. There is no supported 90-second recovery guarantee in this guide.
Assess a specific privilege-escalation hypothesis
State the starting permissions, the proposed privileged operation and the caller-controlled input. Identify prerequisites, constraints and the smallest observation needed to resolve the question. A scanner alert, a writable-looking path or a kernel version is a lead; none alone demonstrates a privilege change. Prioritize by supported impact and evidence gaps, without assigning an invented probability.
For Linux special-mode files, the SUID and SGID review guide covers inventory scope, ownership, mount options, loader behavior and execution context. It separates a mode-bit finding from a reachable privilege boundary. Review the actual deployment rather than transferring a technique solely because a binary name matches.
If an approved test demonstrates a change, record the before-and-after identities and the specific newly permitted operation. Keep this distinct from persistence, lateral movement or access to unrelated data. Stop when the agreed evidence objective is met; a complete assessment does not require every finding to end in a root or administrator shell.
Report the chain and verify the corrective action
NIST SP 800-115, published in September 2008, covers assessment planning, evidence handling, analysis and mitigation. Use its process guidance alongside current product documentation. Keep an activity record, protect collected evidence and define retention and sharing requirements. A report should connect the demonstrated weakness to a corrective action and state untested paths.
Asset / approved scope / test time and zone:
Entry point / authentication / prerequisites:
Deployment instance / runtime / request identifier:
Baseline / permitted action / benign expected effect:
Observed effect / corroborating logs / alternative explanation:
Execution identity / namespace and confinement:
Channel capabilities / errors / limits:
Privilege hypothesis / evidence / observed change:
Impact demonstrated / paths not tested:
Temporary changes / restoration checks:
Owner / corrective action / retest result:Agree restoration of test-created objects and temporary changes with the owner, preserving the required evidence. Keep logs and monitoring intact. Retest the corrected deployment and the previously demonstrated path under the approved scope. Report a narrow result such as “the tested input no longer reaches the observed execution path”; do not declare the whole system secure from one negative check.
Common questions
Is a shell required to report RCE? No. A supported execution finding can be documented without an interactive channel. Describe its prerequisites, context, observed effect and limits.
Does a better terminal mean higher privilege? No. Terminal behavior and process privileges are separate questions. Verify the identity and resource boundary relevant to the claim.
Does a successful identity command prove the entire chain? No. It is one observation in one context. Connect it to the recorded entry point and corroborating evidence before attributing a broader result.
Choose the next step from the missing evidence
Review an existing authorized lab record and label each claim: observed, inferred or unresolved. Identify the next fact needed to resolve one uncertainty, then check whether collecting it is necessary and permitted. Preserve a useful result at its demonstrated scope instead of extending the exercise to fit a predetermined chain.