Construyendo Infra de C2 con Sliver en Lab Aislado para Estudio Defensivo

Cada vez que un analista de SOC abre un ticket por un beacon sospechoso, hay una chance real de que nadie en el equipo haya visto nunca un canal de command-and-control funcionando con sus propios ojos. Los operadores de Red Team usan Sliver, Mythic y Havoc todos los dias, pero la mayoria de los defensores solo conoce esos frameworks por capturas en informes de Mandiant. Ese hueco es peligroso: no se detecta de forma confiable un comportamiento que nunca se observo. Esta guia arma un lab de Sliver aislado y sin internet cuyo unico proposito es generar telemetria realista, controlada y documentada, para que un Blue Team escriba y valide reglas de deteccion contra indicadores que produjo el mismo. Todo lo de abajo ocurre en una VLAN air-gapped y tiene cero riesgo legal, porque el lab no habla con nadie fuera de 10.50.0.0/16.

Que es un C2 y por que Sliver para un lab defensivo#

Un framework de command-and-control (C2) es el lado operador del post-exploitation: un servidor que recibe check-ins de implants (tambien llamados beacons o agents) en hosts comprometidos, mas un canal de tasking que empuja comandos de vuelta. Sliver, mantenido por BishopFox, esta escrito en Go y trae implants multiplataforma para Windows, Linux y macOS sobre mTLS, WireGuard, HTTP(S) y DNS. Para un lab defensivo le gana a las alternativas en tres ejes: a diferencia de Cobalt Strike es gratis y su codigo es auditable, asi que se puede leer exactamente que hace un implant; a diferencia de Mythic exige mucha menos infraestructura. Esa auditabilidad importa porque uno intenta mapear comportamiento a detecciones, y una caja negra no ensena nada generalizable.

Modelo de amenaza: por que los defensores deben correr el tooling ofensivo#

La ingenieria de deteccion fracasa cuando se apoya en teoria. Los fabricantes publican reglas genericas, los equipos las importan, y el primer incidente real revela que la regla disparo en un campo que el operador nunca toca, o perdio el que importaba. Correr el tooling ofensivo uno mismo cierra ese ciclo. Aprendes los named pipes por defecto de Sliver, sus patrones de process injection, las llamadas de API exactas detras de execute-assembly y la cadencia de red de un beacon mTLS. Tambien aprendes sus perillas de evasion, asi que cuando una regla deja de disparar entiendes que perilla giro el adversario. El lab no ataca a nadie; es una fabrica de telemetria cuyo output son reglas Sigma, IOCs e hipotesis de hunting en las que confias porque generaste vos mismo la verdad de terreno.

Arquitectura del lab: VLANs, pfSense y aislamiento total de egress#

La topologia es deliberadamente simple y estrictamente segmentada. Una VM Debian 12 actua como teamserver con 4 vCPU y 8 GB RAM. Vive en la VLAN de C2 10.50.10.0/24. Los objetivos viven en una VLAN de victimas separada 10.50.20.0/24. Entre ambas hay un pfSense cuyo ruleset solo permite trafico entre esas dos subredes y aplica cero NAT hacia afuera: el lab no tiene ruta a internet, por diseno. Esto importa por dos razones. Primero, un implant que no alcanza una direccion real no puede filtrar a un tercero si cometes un error. Segundo, te obliga a modelar la red como realmente se ve una empresa segmentada. Si todavia no armaste un lab base, Pentest Web desde Cero: Montando un Lab Seguro con DVWA, Juice Shop y Burp Suite es un cimiento solido para reutilizar aca.

Instalando el teamserver, paso a paso#

El camino rapido es curl https://sliver.sh/install | sudo bash, pero en un ambiente aislado nunca canalizas un script remoto a root. En cambio, bajas el binario firmado del release en una maquina conectada, lo verificas con cosign verify-blob contra la clave publicada por BishopFox, calculas su SHA-256 y lo llevas via un pendrive dedicado. En la VM Debian, ubicas el binario en /usr/local/bin/sliver-server, creas una cuenta de servicio non-root sliver y corres el server bajo systemd con una unit endurecida (NoNewPrivileges, ProtectSystem=strict, un WorkingDirectory privado). Arrancas la consola con sliver-server y generas una config de operador con new-operator --name analyst --lhost 10.50.10.5. Mantener el perfil de operador acotado a la direccion de la VLAN de C2 impide que un implant perdido alcance una interfaz de gestion que no deberia.

Generando implants y afinando perfiles#

Genera un primer implant con generate --mtls 10.50.10.5:8443 --os windows --arch amd64 --skip-symbols --save ./payloads. El flag --skip-symbols quita las tablas de simbolos de Go, reduce el binario cerca de 40% y frena el reverse engineering rapido, dejando lo suficiente para debug de tu propio lab. Si dejas este implant sin ofuscar en una VM Windows 11 21H2 con Defender real time on, tipicamente muere en unos 12 segundos. Eso no es un fracaso; es una medicion. Ya tienes una senal limpia de lo que Defender atrapa y una baseline para comparar cuando agregues evasion a proposito. Para estudiar la cadena de entrega que precede al beacon, combinalo con Initial Access Simulado: Macros, LNK e ISO en un Lab Windows 11 Aislado.

Del check-in del beacon a las reglas de deteccion#

El pago educativo empieza en el momento en que el beacon conecta. Cada comando del operador produce una huella distinta: getsystem toca duplicacion de token, execute-assembly spawnea un proceso sacrificial y carga el CLR, sideload mapea una DLL unbacked. Instrumenta los hosts victima con Sysmon usando la config de SwiftOnSecurity, envia eventos con un Elastic Agent a un cluster local y correlaciona contra reglas Sigma. En tres sprints enfocados un equipo chico puede mapear decenas de detecciones nuevas, desde los nombres de named pipe por defecto de Sliver hasta spawns de rundll32 sin command line. Todo el pipeline de convertir un IOC en una regla mantenible esta documentado en Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion, que se empareja directo con los eventos que emite este lab.

Movimiento lateral dentro de un mini Active Directory#

El movimiento lateral es donde el lab se paga solo. Levanta un mini-AD con dos domain controllers, cuatro workstations y un file server, espejando la topologia de un cliente mediano. Con el implant Sliver inicial en un host de bajo privilegio, usas Rubeus para Kerberoasting y despues pivoteas por un tunel WireGuard para llegar al domain controller sin tocarlo nunca directamente desde el teamserver. Las tecnicas en Pentest de Active Directory: Kerberoasting Paso a Paso en Lab GOAD y Pivoting con Chisel y Ligolo-ng: Redes Segmentadas en Lab de Pentest son la misma logica con herramienta distinta. Cada salto deja rastro: 4624 type 3, tickets 4769 con RC4 debil, conexiones WMI anomalas. Cada uno se convierte en material de training con una muestra known-good y una known-bad.

Endureciendo las detecciones y cerrando el ciclo#

Un lab sin ciclo de feedback es una demo. Despues de cada corrida, trata cada deteccion que escribiste como una hipotesis e intenta evadirla. Activa las features de evasion de Sliver de a una (reshaping de trafico, jitter, transports alternativos) y observa que reglas sobreviven. Las reglas que solo matchean un string por defecto son fragiles; las reglas ancladas en comportamiento (una region de memoria unbacked ejecutando, una cadena padre-hijo que nunca deberia ocurrir) sobreviven al tuning. Versiona tus reglas Sigma en git, etiqueta cada una con la tecnica ATT&CK que cubre y registra el perfil exacto de implant que genero los eventos fuente para que un companero reproduzca la senal. Esa reproducibilidad es la diferencia entre una regla en la que confias en produccion y una que esperas que funcione.

Errores comunes y OPSEC del lab#

El OPSEC del lab importa mas de lo que se asume. Aun air-gapped, snapshots de VM con implants activos ya filtraron a repos publicos cuando alguien los subio por accidente. La regla es simple: las VMs del lab viven en un datastore cifrado LUKS, los snapshots nunca salen del host, y cualquier artefacto que deba salir (regla Sigma, IOC, video demo) pasa antes por revision manual. Esto conecta con la disciplina de OPSEC para Investigadores de Seguridad: Modelo de Amenaza Personal y Higiene de Metadatos: Limpiando EXIF, PDF y Office antes de Publicar. El error clasico autoinfligido es publicar un PDF de informe cuyos metadatos entregan al adversario el username, hostname y el path del archivo en la laptop personal del investigador.

Checklist de despliegue#

Antes de declarar el lab listo, confirma cada item: pfSense fuerza reglas solo entre subredes con cero NAT saliente; el binario del teamserver fue verificado con cosign y corre bajo una unit systemd non-root endurecida; las configs de operador estan acotadas a la VLAN de C2; los objetivos Windows corren Sysmon (config SwiftOnSecurity) enviando a un cluster Elastic local; el mini-AD espeja una topologia realista; cada regla Sigma esta versionada con tag ATT&CK y perfil fuente reproducible; los snapshots viven en LUKS y nunca salen del host; y cada artefacto exportado paso por revision de metadatos. Si alguna linea queda sin marcar, la telemetria que juntas todavia no es verdad de terreno confiable.

FAQ: Es legal correr un framework de C2 en un lab?#

Si, siempre que el server de C2 y cada implant permanezcan dentro de infraestructura que posees y controlas, sin ruta a sistemas de terceros. La exposicion legal del tooling ofensivo viene de tocar maquinas que no estas autorizado a tocar. Una VLAN air-gapped con cero NAT saliente elimina esa exposicion por completo: el implant literalmente no tiene a donde ir. Manten scope escrito para el lab, etiqueta las VMs y nunca adjuntes una credencial de produccion real ni datos reales de un cliente al ambiente.

FAQ: Sliver, Mythic o Cobalt Strike para un lab defensivo?#

Para un lab defensivo de telemetria, Sliver suele ser el mejor punto de partida: gratis, open source y auditable, asi que puedes rastrear cada comportamiento hasta la fuente y generalizar tus detecciones. Mythic brilla cuando quieres modelar un ecosistema diverso de agents pero cuesta mas montaje. Cobalt Strike representa una gran parte de las intrusiones reales, asi que los equipos maduros terminan agregandolo para ampliar cobertura, pero su licenciamiento y naturaleza cerrada lo hacen una mala primera herramienta de aprendizaje. Empieza con Sliver, entiende los fundamentos, despues expande.

Conclusion#

Si defiendes una organizacion y nunca viste un Sliver beacon en una pantalla que controlas, tu deteccion es teorica. Reserva un dia entero, arma el lab con pfSense mas Debian mas dos objetivos Windows, genera un implant sin ofuscar, dejalo correr comandos por treinta minutos y abri Sysmon. Vas a salir con mas material de hunting concreto que varios cursos pagos juntos, y con cero riesgo legal porque todo pasa dentro de la VLAN 10.50.0.0/16 que no habla con nadie afuera. El punto no es volverse atacante; es hacer que tu defensa sea empirica en vez de aspiracional.