Dashboard-driven honeytoken/credential provisioning: manual Canarytoken creation, implant-to-honeypot, credential linking, and rotation

[Xore]

Summary

Future-work idea surfaced while #1426 (self-hosted Canarytokens) and #1427 (cross-honeypot breadcrumbs) were being implemented. Right now those two issues cover the mechanism (a self-hosted Canarytokens instance + a webhook adapter, and hand-authored breadcrumb content baked into persona files at build/deploy time). This issue is about the operator workflow layered on top: doing this live, from the dashboard, without editing persona files and redeploying every time.

What's being asked

1. Manual Canarytoken creation from the dashboard. An operator should be able to click "create honeytoken" in the dashboard UI, pick a type (AWS key, Word doc, cloned webpage, etc. -- whatever the self-hosted Canarytokens instance from Design and implement a honeytoken/breadcrumb system (Canarytokens) #1426 supports) and have it actually created, without touching the Canarytokens web UI directly. Depends directly on Design and implement a honeytoken/breadcrumb system (Canarytokens) #1426's own "investigate token-generation automation" finding (API vs. scripted UI vs. workaround) -- this issue can't be scoped precisely until that lands.
2. Implant directly into a honeypot from the dashboard. Once a token exists, let the operator pick which persona/sensor's fake filesystem it gets planted into, and have that actually happen (write the token file/artifact into the right place, live, not just at next redeploy). Needs a real "plant into persona X's fake FS" backend action, not just database bookkeeping.
3. Credential ingestion + rotation policy. Same idea for Design cross-honeypot breadcrumbs so attackers believe it's one real infrastructure #1427's item 1 (shared credentials across personas, deliberately split out to Cross-honeypot breadcrumbs: shared credentials across personas (item 1 of #1427) #1485 as its own research task) -- manual credential creation via the dashboard, plus an auto-rotation policy (rotate every N days? on-demand? never for a "stale but still valid" narrative reason?) instead of static, hand-authored values that never change.
4. Visibility: where do these things actually live, and what's inside them? The dashboard should show, for each planted token/credential: which persona/sensor it's attached to, the real file path on disk, and (for credentials at least) what the file's actual content looks like -- so an operator auditing the setup doesn't have to SSH in and grep for it.
5. Link a Canarytoken to a credential file. A "link canarytoken" option on a credential's dashboard entry, so touching/opening that specific credential file also fires the linked token's alert -- catching an attacker who exfiltrates or opens the file, not just one who tries to use the credential.

Why this matters

#1426/#1427 as currently scoped are static: breadcrumbs and tokens get planted once, at build/deploy time, by an agent editing files. This issue is about making that a live, repeatable, auditable operation instead -- the kind of thing an operator would actually want to do repeatedly as the honeypot fleet grows, without a redeploy cycle every time.

Scope note

Explicitly deferred, not to be started until:

• Design and implement a honeytoken/breadcrumb system (Canarytokens) #1426 lands and its token-generation-automation finding is known (determines whether item 1/2 here are even feasible without scripting the Canarytokens web UI).
• Cross-honeypot breadcrumbs: shared credentials across personas (item 1 of #1427) #1485 (shared credentials, split from Design cross-honeypot breadcrumbs so attackers believe it's one real infrastructure #1427) has its own design decisions made (credential provisioning/rotation mechanism, which item 3 here directly builds on).

This is a design/planning issue, not scoped for immediate implementation.

[Xore]

Implementation plan for this pass

Already shipped (PR #1508, merged, but noted there as not yet deployed): dashboard-driven token creation (6 types: PDF, MS Word, MS Excel, custom image/web-bug, Windows Folder, QR code) + a creation-history list + per-token download, all served from canarytokens_client.go/canarytokens_api.go/canarytokens_manager.go (arcane/home/honeypot-dashboard/dashboard/) behind /api/settings/canarytokens*. Currently only reachable through the Settings modal (Settings > Canarytokens pane in hp-settings.js), not a real page.

This pass: promote that into a proper first-class dashboard page instead of a Settings sub-pane, with three tabs, matching this dashboard's existing page pattern (page_X.go + ui/X.html + route in routes.go + sidebar entry in ui/partials/dashboard.html, e.g. attackers/reports):

• Tokens — table of every created token (type, memo, created-by/at, download link). Backed by the existing GET /api/settings/canarytokens list endpoint, no backend change needed.
• Create bait — the existing creation form (type picker, memo, optional snippet/upload), moved as-is onto this tab. Backed by the existing POST /api/settings/canarytokens/create.
• Reports — NEW: fired-token alert activity (who triggered which token, when, source IP), pulled from the already-flowing canarytokens-adapter → Elasticsearch pipeline (event.sensor:canarytokens in honeypot-v2-*, already classified in classify.go/elastic.go since Design and implement a honeytoken/breadcrumb system (Canarytokens) #1426). Needs one new lazy-row API endpoint following the same pattern as /api/event-rows.

Every tab renders its skeleton/table shell instantly server-side and hydrates via fetch on first activation — same convention as the rest of this dashboard (lazy row-fragments, on-demand pane loaders), all data ultimately backed by Elasticsearch, nothing new to provision.

The Settings modal's Canarytokens pane will be replaced with a link out to the new page rather than kept as a second, duplicate surface.

Explicitly out of scope for this pass (unchanged from #1508's own scoping note) — tracked here for whoever picks them up next:

• Item 2: auto-implant a created token directly into a persona's fake filesystem.
• Items 3/5: credential provisioning/rotation and linking a canarytoken to a credential file.

Both are real backend features (live file-writes into running sensor containers; a rotation scheduler) distinct enough from a read/create UI that they deserve their own scoped issue rather than being folded in here silently.

Deployment: #1508's own platform changes were never deployed live (its own PR body flagged this). Finishing this issue includes completing that outstanding deploy too — docker-compose.canarytokens.yml/VPS Traefik changes, CANARYTOKENS_API_URL/CANARY_PUBLIC_HOSTNAME env vars, and end-to-end verification (create a token from the new page, trigger it externally, confirm the alert reaches ES and shows up on the Reports tab) — not just merging code.

[Xore]

Consolidated into #1523 (AFTER RELEASE 0.1.0 epic) — closing here, tracked as a checklist item there. Reopen/re-file when this work is picked up.

[Xore]

Design for items 2/3/5 (implant, credential provisioning/rotation, linking)

Investigated the actual mechanics before building. Key finding that shapes everything below: Cowrie's honeyfs is baked into the Docker image at build time (COPY honeyfs/ in the Dockerfile), and a file's visibility to ls/cat depends on a separately-built fs.pickle index (bin/sync-fs.py merges honeyfs/'s real files into it at build time) — dropping bytes into a running container's filesystem alone would not make an attacker able to see or open them. Confirmed live via operator sign-off: build this properly rather than fake a shortcut.

The mechanism (operator-approved)

1. Bind-mount cowrie's honeyfs/ and share/cowrie/fs.pickle to host paths instead of baking them into the image (matching how cowrie.cfg/userdb.txt are already bind-mounted today). Seed the host directory from the image's current content on first deploy.
2. A new small internal-only Go service (same shape as canarytokens-adapter: dedicated container, narrow scope, WireGuard-tunnel-only API) that the dashboard calls to implant a file: writes it under the bind-mounted honeyfs/ tree, then runs bin/sync-fs.py (pure stdlib, no cowrie deps — confirmed by reading it — so this service doesn't need cowrie's own venv) against the bind-mounted fs.pickle to index the new file.
3. Restart via the existing autoheal mechanism, not new docker.sock access. This repo already has willfarrell/autoheal (in honeypot-utilities/compose.yml) restarting any container labeled autoheal=true that fails its healthcheck, talking only to docker-socket-proxy, never the raw socket. Give cowrie a HEALTHCHECK that fails while a pending-implant marker file exists (written to the already bind-mounted var/lib/cowrie — no new mount needed for this part), and clear that marker in entrypoint.sh on startup. The implant service never touches Docker at all; it just writes files and lets the existing restart machinery do its job. Real downtime: a few seconds, no rebuild/redeploy cycle, no human editing persona files in git.

Items 3/5 build on the same primitive

• Item 3 (credential provisioning/rotation): a credential is just another honeyfs artifact (e.g. rewriting bin/sync-bastion02-backup.sh's hardcoded password, per feat: shared credential breadcrumb between Cowrie and Beelzebub's bastion02 #1501's precedent) plus, for Beelzebub-style sensors, a config value (passwordRegex in ssh-2200.yaml) that the same service can rewrite and trigger a restart for via the identical autoheal mechanism. Rotation = calling implant again with new content.
• Item 5 (link a token to a credential): a dashboard-side data-model concern only (store which canarytokens_manager.go-tracked token id is associated with which credential/file path) — no new backend mechanism, just bookkeeping once items 2/3 exist.

Status

Implementing the core primitive (bind-mount conversion + implant service + autoheal wiring) now. Items 3/5's dashboard UI will follow once that primitive lands and its request/response shape is settled, so they build on the real thing instead of a guess.