sage-callback-bootstrap

Files (5)

• .env.example
• SKILL.md
• openai.yaml · agents/
• bootstrap_payloads.py · scripts/
• test_bootstrap_payloads.py · tests/

SKILL.md (first lines)

# Sage Callback Bootstrap

Use after `$sage-goad-reset` archives runtime databases, resets Mythic, and restarts Sage. Sage is a native Mythic
v4 chat container; do not create or wait for a Sage payload callback.

## Credentials

The helper resolves `MYTHIC_ADMIN_PASSWORD` first, then `MYTHIC_ENV_PATH`, then
`MYTHIC_ENV_PATH`; there is no checkout-name default. See `.env.example`.

## Workflow

Inspect Mythic:

```bash
.venv/bin/python skills/sage-callback-bootstrap/scripts/bootstrap_payloads.py inspect
```

Verify the Sage chat container and create a fresh Apollo payload:

```bash
.venv/bin/python skills/sage-callback-bootstrap/scripts/bootstrap_payloads.py bootstrap-reset
```

`bootstrap-reset` must report a running `sage_chat_container`, a wildcard-scoped API token owned by the current
operation's unique active bot, and an empty locked prepared channel named
`Sage GOAD Ready`, and `sage_payload_created: false`.

The standalone command keeps that prepare-chat behavior for compatibility. When the operator will create the
operation and demo chat manually, use:

```bash
.venv/bin/python skills/sage-callback-bootstrap/scripts/bootstrap_payloads.py bootstrap-reset --no-prepare-chat
```

Pair it with `readiness --no-require-prepared-channel`. This relaxes only the prepared-channel section; Sage
container, token, range, clock, BloodHound, and unique foothold requirements remain enforced.

After Apollo is launched as `NORTH\samwell.tarly` on CASTELBLACK, run:

```bash
.venv/bin/python skills/sage-callback-bootstrap/scripts/bootstrap_payloads.py post-callback-preflight
.venv/bin/python skills/sage-callback-bootstrap/scripts/bootstrap_payloads.py readiness --runtime-dbs-archived
```

Readiness delegates to the shared `sage-goad-reset` readiness contract. It is true only when the sanitized
startup identity, runtime DB archival, exact six-VM/IP state, clock check, BloodHound API/domains, BloodHound
MCP checkout and exact required tool set, Mythic chat/token, unique live foothold, and prepared channel are all
ready. `selected_sage_cb` is intentionally null.

`post-callback-preflight` is now strictly task-free. It waits for the selected live Apollo callback through
Mythic control-plane observation, synchronizes range clocks out of band, and returns explicit zero-task metadata.
It does not issue callback tasks, purge Kerberos tickets, or claim target-probed domain/identity output.
The `sage-goad-reset` orchestrator additionally proves this with observed Mythic task-count deltas before
admitting reset completion.

## Canonical Apollo Bootstrap Path

Do not re-derive Apollo bootstrap manually when these helpers cover the case.

- Fresh clean-baseline foothold with a newly built downloadable payload: `bootstrap-reset` → payload deploy skill `deploy` with the interactive Apollo
  launch path → `post-callback-preflight` → `readiness --runtime-dbs-archived`.
- Pre-staged interactive foothold with retained callback metadata: `bootstrap-reset --use-retained-callback ...` → payload deploy skill
  `launch-existing` or `launch_apollo_foothold.sh` with a settle window and unique-callback gate →
  `post-callback-preflight` → `readiness --runtime-dbs-archived`.
- Batch-logon canary foothold: use `sage-foothold-launch` only when the selected Mythic payload is genuinely
  downloadable and the operation explicitly accepts a batch-logon token.

Imported retained callback metadata can recreate a payload row with an empty server-side file path. That row binds
the staged executable's identity but cannot supply bytes to `deploy`; do not call `mythic.download_payload` for it.
It does not prove that an independently selected snapshot contains the same payload. For the qualified Trust Walker
fixture, validate the atomic snapshot/config/payload/task/executable identity in
`skills/sage-mythic-payload-deploy/SKILL.md` before launch.
Headless execution alone never changes the selected bootstrap mode. Satisfy the interactive wrapper's display
prerequisite or stop before allocation. See the authoritative decision table in
`skills/sage-mythic-payload-deploy/SKILL.md`.

For retained or purpose-range launches, do not call the foothold ready until the callback lane is unique after the
settle window. Always rediscover the active callback ID after launch; imported callback rows are historical metadata,
not tasking targets.

## Retained Foothold

Export before reset:

```bash
.venv/bin/python skills/sage-callback-bootstrap/scripts/bootstrap_payloads.py export-callback-config --callback <foothold-display-id> --output skills/sage-callback-bootstrap/merlin_callback_config.json
```

Import after reset:

```bash
.venv/bin/python skills/sage-callback-bootstrap/scripts/bootstrap_payloads.py bootstrap-reset --use-retained-callback --retained-callback-config skills/sage-callback-bootstrap/merlin_callback_config.json
```

Imported callback rows are forced inactive so they remain historical metadata and cannot be selected for
tasking. Launching the retained payload creates the active callback row used by Sage.

Then launch the retained payload and run:

```bash
.venv/bin/python skills/sage-callback-bootstrap/scripts/bootstrap_payloads.py readiness --runtime-dbs-archived --foothold-payload-type merlin
```

The baked Apollo import remains available through `--use-baked-apollo` for legacy snapshots only.

## Post-rebuild payloads and GraphQL notes

- `create-apollo` builds through the **currently running** apollo container. After a service rebuild
  (e.g., a patched agent branch installed per `skills/sage-mythic-payload-deploy/SKILL.md`), every payload it
  creates carries the patched agent version; confirm via Mythic GraphQL `payloadtype { name semver }`.
  A new build parameters instance list (`buildparameterinstances { value buildparameter { name } }`) also
  carries the build's C2 settings. Callback C2 parameters to mirror on a fresh payload can be read
  (with keys redacted) from `export-callback-config`.
- Mythic GraphQL schema differences worth knowing (v3.4.x): `filemeta` has no `sha256` field;
  `payload` has no `build_parameters`/`buildparameter` relation — use `buildparameterinstances`;
  `payloadtype` exposes the agent version as `semver` (not `agent_version`); task artifacts live in
  `task.taskartifacts { base_artifact artifact_text }` (no `artifact_details`); `response_text` is
  base64-encoded. Introspect `__type(name: "...")` before guessing fields.

From MythicAgents/sage, GPL-3.0.

More from MythicAgents/sage