Skip to content

Manual Post-Exploitation

aipostex automates recon → access → impact → own: it lands the foothold and hands you the loot — a stolen SA token, a uid=0 pod, a gateway credential — raw and un-redacted. What a real operator does next is take that access to native tooling (kubectl, curl, python) and explore by hand. That manual layer is documented here.

  • Operator Guide — per foothold: what the tool landed, the native continuation, what you find, and how to reset.

Two things worth knowing before you start:

  • Read-only vs DESTRUCTIVE. The guide's default commands are read-only and safe to run live. Anything that changes state is marked DESTRUCTIVE and requires one reset-wave.sh to clean.

  • The tool can hand you the session. If you ran an engagement (aipostex sessions start …), your dossier at ~/engagements/<name> already includes a manual/ folder — a ready-to-use kubeconfig from the stolen SA token, an env.sh of exports, and pivots.sh (the raw kubectl/curl one-liners). It's the native counterpart to the dossier's commands.sh. (From a saved findings file directly: aipostex report view <findings> --dossier-dir <dir>.)

  • By-hand with the tool console. The by-hand continuation doesn't have to leave aipostex: the operator console (request / shell) drives the same services turn-by-turn from inside the tool — authed or unauthenticated — and mines every response for loot. aipostex <module> request METHOD PATH issues a one-shot HTTP call (e.g. read an exposed Ray dashboard); aipostex <module> shell opens a REPL to chat a looted model, run a Jupyter kernel, call MCP tools, or drive an A2A agent. It's manual — you run every request; there's no auto-chaining. Kubernetes has no in-tool shell: its channel stays kubectl via the manual/ kubeconfig above. See the tool's request / shell CLI reference (docs/cli/) for the full flag set.