Proving Command Execution on a 24/7 Platform Without Internet Egress

The blindness is the constraint, so the proof must create an observation channel you own - and must not touch data.

• Channel. With no internet egress, use the allowlisted forward proxy if the host can reach it, or a DNS-based callback to a domain you control if the resolver is allowed out. If neither is possible, fall back to a single time-delay probe: one request with a deliberate sleep, compared against a baseline request, repeated once only to exclude jitter.
• Effect. Write a uniquely named marker file to a world-writable temporary directory and read it back through the same injection (whoami output into a file, then type). This proves code execution as the web service account with zero business impact.
• Do not. Read credential stores, create accounts, drop binaries in application directories, enumerate the shared Oracle database, or run anything that writes to a table. The shared production database is the single biggest hazard in this engagement and the injection gives you no reason to go near it.
• Evidence. Capture the exact request and payload, the callback or timing log with UTC timestamps, the marker file contents, and the identity returned by whoami. Note the load-balanced hostname so a retest can target the same node.

One clean, repeatable, harmless proof is worth more than a shell nobody can reproduce in the report.

Plan for living off the land, because nothing can be downloaded from the internet.

• First choice: native capability. Command execution as the application account is often enough to prove impact - whoami, hostname, reading an agreed non-sensitive configuration file, checking local group membership. Many findings need no uploaded binary at all.
• If a second stage is genuinely required: host it in your own infrastructure and serve it through the allowlisted proxy on 443, which is the only path the client permits; or transfer it in chunks encoded into the injection's own output/input, reassembled in a temporary directory. Keep total volume small, base64-encode, and verify the checksum after reassembly.
• Antivirus and EDR. Assume the DMZ hosts are monitored. Unusual binaries dropped by a web service account are exactly what gets alerted, so prefer built-in interpreters and document each artefact's path so cleanup is complete and verifiable.
• Record everything transferred. Name, hash, size, destination path and deletion time. The report should let the client confirm the host is back to its pre-test state.

If none of the transfer routes works inside the window, say so: the command-execution proof already demonstrates the risk, and the inability to stage tooling is a finding about egress control, not a failure of the test.

Manage the objective, not just the deliverable. The engagement's purpose is to evidence business risk within the agreed scope, time and safety constraints - a trophy is not the objective, and chasing one across a shared production database with month-end load three days away is how engagements cause incidents.

Respond in writing, the same day:

1. Restate the constraints: two days, one tester, no egress, staging shares the production database, month-end traffic begins in three days.
2. Offer a negotiated proof that is sufficient for a board conversation: confirmed command execution as the web service account, read access to a named non-sensitive file, and a single TCP connection from the DMZ host to an agreed internal host to demonstrate the pivot path exists. That chain - external input to internal reachability - is what justifies budget.
3. Explain what full domain compromise would require: additional days, a defined safe target list, an agreed change window, and a rollback plan. Offer it as a follow-on phase with its own authorisation.
4. Get any change to the objective in writing before acting, and record the refusal of anything that would breach the data-modification prohibition.

Document the attack path you did prove, with the steps the client cannot complete themselves. That is the persuasive artefact; a screenshot of a domain controller is not.