Detección de Sliver C2: cuando el sistema de balizas avanzado intenta ocultarse a plena vista

March 23, 2026
3/23/2026
Lucie Cardiet
Responsable de investigación de ciberamenazas
Detección de Sliver C2: cuando el sistema de balizas avanzado intenta ocultarse a plena vista

Es posible que los equipos de seguridad no se den cuenta en el momento en que un atacante logra entrar, pero acaban detectando el tráfico que se produce a continuación.

Un sistema comprometido comienza a establecer contacto con algo con lo que no debería comunicarse. La conexión se repite, espera y vuelve a repetirse. Esta es la función de la infraestructura de mando y control.

En un artículo anterior, expliqué cómo los atacantes utilizan Brute Ratel para mantener canales de comando ocultos dentro de entornos comprometidos. Herramientas como Brute Ratel diseñan deliberadamente su tráfico para que se camufle entre la actividad web legítima y eluda los métodos de detección tradicionales.

Otra herramienta creada con la misma filosofía es Sliver, un marco de código abierto de comando y control que introduce capas adicionales de aleatorización en el tráfico de balizas para dificultar aún más su detección.

Desde el acceso inicial hasta el mando y control

Los atacantes rara vez implementan directamente una infraestructura de comando y control. Primero necesitan un punto de entrada.

En muchas intrusiones, ese punto de entrada comienza con una vulnerabilidad en un servicio expuesto a Internet. Un ejemplo reciente es React2Shell (CVE-2025-55182), una falla crítica que afecta a los componentes de servidor de React utilizados en marcos como Next.js. La explotación de esta vulnerabilidad permite a un atacante ejecutar código en un servidor vulnerable mediante una solicitud HTTP manipulada.

Una vez que logran ejecutar el código, los atacantes actúan con rapidez para establecer la persistencia y el control remoto.

Aquí es donde entran en juego los marcos de trabajo para la fase posterior a la explotación.

En lugar de crear malware a medida, los atacantes suelen recurrir a herramientas de código abierto consolidadas que ofrecen un conjunto completo de herramientas operativas para gestionar los equipos comprometidos. Estos marcos se encargan de las partes más complejas de las operaciones de intrusión: las comunicaciones seguras, la asignación de tareas a los sistemas infectados, la transferencia de archivos y la coordinación de actividades entre múltiples equipos comprometidos.

Sliver es una de esas herramientas.

Diagrama que muestra las diferentes cargas útiles de los atacantes que utilizan React2Shell. Fuente: Wiz

Qué es Sliver y por qué lo utilizan los atacantes

Sliver se ha convertido rápidamente en uno de los marcos de código abierto para la fase posterior a la explotación más utilizados. Desarrollado originalmente para la simulación de atacantes y las operaciones de equipos rojos, el proyecto ofrece una plataforma consolidada para gestionar sistemas comprometidos y coordinar actividades de intrusión.

Captura de pantalla: Sliver en GitHub

Hay varios factores que explican su creciente aceptación:

  1. Sliver es un proyecto totalmente de código abierto y se mantiene de forma activa, lo que reduce las barreras para los atacantes en comparación con los marcos comerciales. Los operadores pueden generar fácilmente implantes personalizados, modificar perfiles de comunicación e integrar el marco en flujos de trabajo automatizados de intrusión.
  2. El marco se diseñó teniendo en cuenta la flexibilidad operativa. Sliver es compatible con múltiples sistemas operativos, protocolos de comunicación y mecanismos de transporte, lo que permite a los operadores adaptar el canal de comandos al entorno al que se dirigen. Los transportes HTTP y HTTPS son especialmente habituales, ya que se integran de forma natural en el tráfico habitual de la empresa.
  3. Sliver incorpora técnicas integradas de ofuscación del tráfico destinadas a dificultar la identificación del tráfico de comandos. El marco puede introducir variaciones temporales entre las solicitudes de baliza, alterar el tamaño y la estructura de los datos transmitidos y alternar los mecanismos de codificación que modifican la apariencia del tráfico de red.

Estas decisiones de diseño hacen que Sliver resulte atractivo para los atacantes que buscan una plataforma de comando y control eficaz sin tener que programar malware a medida. Al mismo tiempo, plantean un reto de detección más complejo para los equipos de seguridad que intentan identificar los canales de comando ocultos en el tráfico cifrado.

Por qué las señales de baliza suelen ser más fáciles de detectar

Los marcos tradicionales de mando y control suelen generar patrones de red predecibles.

Si un implante se comunica cada 60 segundos y envía aproximadamente la misma cantidad de datos cada vez, el patrón de tráfico resultante resulta fácil de identificar.

Las herramientas de seguridad pueden detectar estos patrones analizando:

  • sincronización constante entre conexiones
  • comunicaciones repetidas con el mismo destino
  • tamaños de carga útil similares en todas las solicitudes

Para evitar ser detectados, los marcos más avanzados introducen elementos aleatorios en esos patrones. Pueden variar el intervalo de tiempo entre conexiones o modificar el volumen de datos transmitidos en cada solicitud. Estas técnicas dan lugar a lo que se conoce como «señalización evasiva», en la que el patrón de comunicación sigue existiendo, pero resulta más difícil de reconocer.

Muchas herramientas modernas de post-explotación admiten estas técnicas de forma predeterminada.

Sliver lleva la idea un paso más allá.

¿Qué hace que Sliver sea más difícil de detectar?

La mayoría de los marcos de comando y control se basan en dos técnicas básicas de evasión.

El primero es la fluctuación temporal, en la que el implante ajusta aleatoriamente el retraso entre las solicitudes de baliza. En lugar de enviar una señal cada 60 segundos, podría hacerlo a los 48 segundos, luego a los 72 segundos y después a los 63 segundos.

El segundo es la fluctuación de datos, en la que el tamaño de cada solicitud varía ligeramente. Es posible que se añada una pequeña cantidad de datos aleatorios al mensaje de baliza para que el tráfico de red no parezca idéntico en cada ocasión.

Sliver introduce un enfoque más sofisticado conocido como «variación procedural de datos».

Ejemplo de fluctuación en los datos con una cantidad aleatoria de datos añadidos, que se agrupan fácilmente basándose únicamente en los volúmenes de transferencia de datos

En lugar de cambiar solo un elemento de la solicitud, Sliver modifica varios parámetros a la vez. Cada solicitud de baliza puede utilizar una ruta HTTP diferente, un método de codificación distinto y un valor aleatorio que altera la estructura de la solicitud.

Un ejemplo de Sliver en modo de espera en modo baliza HTTP con el algoritmo de agrupamiento de fluctuaciones de datos aplicado (y sin fluctuaciones de tiempo).

El marco admite múltiples codificadores, entre los que se incluyen Base64, la codificación hexadecimal, la compresión gzip e incluso codificaciones que transforman datos binarios en texto en inglés o en archivos PNG válidos. Cada método de codificación modifica la eficiencia de la compresión de los datos transmitidos, lo que da lugar a diferentes tamaños de carga útil en las distintas solicitudes.

En lugar de generar un único grupo de mensajes de baliza similares, Sliver genera múltiples patrones distintos en el tráfico de red.

En los sistemas de detección que esperan que los mensajes de baliza tengan un aspecto similar, esta variabilidad rompe el patrón.

Hay indicios de que los atacantes ya están utilizando Sliver

Sliver no es solo una herramienta para el equipo rojo.

Los investigadores en seguridad han documentado campañas en las que los atacantes han instalado implantes Sliver tras acceder a infraestructuras vulnerables.

Un ejemplo lo encontramos en un estudio de CtrlAltIntel, que descubrió una campaña dirigida contra dispositivos FortiWeb conectados a Internet. Tras aprovechar la vulnerabilidad de los sistemas expuestos, los atacantes instalaron implantes Sliver camuflados como utilidades de actualización del sistema. Los dispositivos comprometidos comenzaron a enviar señales a la infraestructura controlada por los atacantes, lo que permitió a los operadores mantener el control remoto de los servidores afectados.

La investigación reveló que había decenas de equipos comprometidos que se comunicaban con el servidor de comandos, lo que pone de manifiesto la rapidez con la que los marcos de código abierto para la fase posterior a la explotación, como Sliver, pueden pasar de ser herramientas de equipos de simulación de ataques a utilizarse en actividades de intrusión reales. Estos casos reflejan una tendencia más generalizada en las actividades de intrusión.

Los marcos de código abierto para la fase posterior a la explotación permiten a los atacantes actuar con rapidez sin necesidad de desarrollar malware personalizado. Estas herramientas ofrecen capacidades maduras de comando y control, al tiempo que se camuflan entre el tráfico legítimo de la red.

Para los defensores, esto hace que identificar el canal de comandos sea un paso fundamental para detectar una intrusión activa.

Por qué los métodos de detección tradicionales tienen dificultades

Muchas técnicas de detección de sistemas de mando y control se basan en la identificación de patrones de comunicación regulares, en los que los mensajes de baliza se envían a intervalos constantes y suelen transmitir cantidades similares de datos.

Si la mayoría de las solicitudes contienen aproximadamente el mismo número de bytes, el patrón de tráfico puede agruparse en un único clúster e identificarse como comportamiento de baliza.

La rotación del codificador de Sliver desmiente esta suposición, ya que cada método de codificación produce una tasa de compresión diferente, por lo que los mensajes de baliza resultantes se distribuyen en varios rangos de tamaño distintos, en lugar de agruparse en un único grupo dominante. Este patrón multibanda puede eludir los algoritmos que esperan que los mensajes de baliza sean similares entre sí.

En el tráfico cifrado, donde no es posible inspeccionar la carga útil, estas variaciones dificultan considerablemente la detección.

Los atacantes también suelen modificar los implantes de Sliver o distribuirlos a través de cargadores de código shell personalizados, diseñados para eludir los antivirus y los sistemas de detección de puntos finales. Estas técnicas permiten que la carga útil se ejecute íntegramente en memoria, lo que reduce las posibilidades de detección en el host. Sin embargo, una vez que el implante establece su canal de comando, la comunicación de señalización sigue generando patrones observables en la red.

Detección de astillas mediante el análisis del comportamiento

Incluso cuando las cargas útiles están cifradas y son ilegibles, el tráfico de comando y control sigue dejando patrones de comportamiento.

La Vectra AI analiza esos patrones para identificar marcos de mando y control como Sliver, incluso cuando los atacantes intentan camuflar su tráfico mediante fluctuaciones, rotación de codificadores u otras técnicas de evasión.

En lugar de basarse en firmas o en la inspección de la carga útil, la plataforma aplica modelos de aprendizaje profundo entrenados con grandes volúmenes de datos de telemetría de red reales . Estos modelos evalúan secuencias de actividad de red, como la longitud de los paquetes, los intervalos de tiempo y la dirección de la comunicación entre hosts, para detectar patrones de comportamiento compatibles con el envío de señales de baliza.

Dado que los atacantes deben mantener la comunicación con los sistemas que han comprometido, ese canal de comando sigue siendo uno de los lugares más fiables para detectar una intrusión activa.

Aunque las señales de Sliver se mezclan con el tráfico web habitual, esas señales de comportamiento siguen destacando.

Para ver cómo la Vectra AI identifica actividades de mando y control como Sliver en entornos reales, vea la demostración autoguiada.

Preguntas frecuentes