PCI VLAN Proof Without Touching Data
You land on a DMZ web server (dmz-web01) as a low-privilege service account, app_svc, after exploiting a deserialization flaw. The host is dual-homed: 172.16.5.10/24 (DMZ) and 10.20.30.15/24 (internal). Egress from the DMZ is restricted to TCP 443 to an authenticated HTTP proxy; no direct internet. You have no C2 framework, only built-in tools (curl, ssh, PowerShell not present). The internal network has three VLANs: 10.20.30.0/24 (app), 10.20.40.0/24 (PCI), and 10.20.50.0/24 (management). A config file on dmz-web01 contains credentials for svc_deploy, which is reused on 12 app servers. The client wants proof you can reach one PCI server, pci-db01 (10.20.40.22), and read a non-sensitive table, without modifying data. All actions must be documented for the QSA; the PCI VLAN has IDS.
1. Design a pivot that uses only built-in tools and complies with egress restrictions.
Read the worked answer
Do not try to reach the internet; the only egress is the authenticated proxy, and building a tunnel through it adds noise. Use dmz-web01 as a jump host over SSH if sshd is reachable from your attack host. From your workstation: ssh -N -L 15432:pci-db01:5432 app_svc@dmz-web01. This keeps traffic on the DMZ-to-internal path and does not use the proxy. If SSH is not available, check for curl and use it only against an internal HTTP service; do not attempt to install tools. For the app VLAN, the svc_deploy credentials are reused, but do not spray them. Test one app server with a single SSH login and confirm the credential, then use that host as a second hop if needed. Keep the tunnel bound to localhost. Log the exact command, process ID, and start/stop time. A single SSH session from dmz-web01 to pci-db01 is far less noisy than scanning.
2. How do you prove access to pci-db01 and read a non-sensitive table without changing data, and what do you log?
Read the worked answer
Use the tunnel to connect to pci-db01 as svc_deploy, but start a read-only transaction: SET TRANSACTION READ ONLY; SELECT current_user, inet_server_addr(); SELECT count(*) FROM public.currency;. Choose a reference table the client confirms is non-sensitive. Do not run pg_dump, COPY, or any INSERT/UPDATE/DELETE. Capture the psql transcript with timestamps, the tunnel command, the source IP as seen by the database, and the exact query. Hash the output and store it with the evidence. If the client wants proof of data read, select one row from a non-sensitive table and redact any PII. Log the start and end time, the session user, and the fact that the transaction was read-only. Clean up by closing the SSH tunnel and the database session; verify no temporary files remain. This gives the QSA a defensible record without touching cardholder data.
3. What goes in the report and what do you redact?
Read the worked answer
Report the scope and timeline, the initial foothold, the dual-homed host, the pivot command, the credential-reuse finding on 12 app servers, the PCI VLAN reachability, and the exact read-only query with evidence. Include a network diagram, source and destination IPs, and the control gap: a DMZ host with an internal interface and reused service credentials. Redact passwords, hashes, session tokens, and any cardholder or personal data; replace them with a canary or table name. Do not include the full /etc/shadow or database rows. Provide reproducible steps in an appendix, but keep the exploit payload out of the executive summary. State what you did not do: no writes, no persistence, and no lateral movement beyond the single proof host. Recommend segmentation, unique service accounts, and egress filtering. The report should let the client fix the path without handing an attacker a copy-paste playbook.