Técnicas de detección de botnets para localizar sistemas C2 modernos

Esta guía se centra exclusivamente en la capa de detección: cómo los analistas del SOC y los ingenieros de detección detectan la actividad de las redes de bots en la red, y cuáles son las limitaciones de cada técnica. Si necesitas conocer los conceptos básicos —qué es una red de bots, cómo funciona el malware subyacente y cuáles son las principales familias—, empieza por la página principal.

La detección de botnets consiste en identificar los hosts comprometidos a partir del comportamiento en red que genera su tráfico de comando y control (C2) —periodicidad de las señales, anomalías en el DNS y huellas digitales de los canales cifrados— en lugar de mediante la comparación con firmas conocidas. Dado que cada bot debe comunicarse con su controlador para ser útil, el canal de control es el lugar más fiable en el que buscar.

De las firmas al comportamiento: por qué la detección de botnets ha ido más allá de los IOC

¿Cómo se detectan las redes de bots? En la práctica, mediante el análisis del comportamiento del canal de control: periodicidad de las señales de baliza, actividad DNS anómala —como consultas del algoritmo de generación de dominios (DGA) y «fast flux»—, huellas de sesiones cifradas y comportamiento a nivel de flujo. La comparación de firmas e indicadores de compromiso (IOC) sigue teniendo su utilidad, pero solo permite detectar infraestructuras que alguien ya ha visto, notificado y catalogado.

Las listas de reputación de direcciones IP y dominios son el mínimo imprescindible. Una lista de bloqueo impide que los bots comunes reutilicen la infraestructura del mes pasado, y un sistema de detección y prevención de intrusiones (IDS/IPS) basado en firmas señala de forma fiable las cargas útiles y los protocolos de comunicación C2 para los que cuenta con definiciones. El problema es la obsolescencia: cada entrada describe una infraestructura o herramienta que un atacante puede sustituir en cuestión de minutos, por lo que una lista pierde valor desde el momento en que se publica.

La rotación es cuantificable. En su informe «Botnet Threat Update» correspondiente al periodo de enero a junio de 2026, Spamhaus observó que Sliver superó a Cobalt Strike como el marco C2 más frecuente, con un aumento del 58 % en seis meses, mientras que los servidores de comando y control de botnets que rastreó se redujeron un 30 %, hasta los 14 952. Spamhaus también observó que los dominios C&C .cn se dispararon un 771 %, mientras que los registros utilizados indebidamente en el registrador REGRU cayeron un 90 %: los operadores se trasladan en masa cuando se ven sometidos a presión. Cualquier detección basada en firmas específicas de un marco de trabajo persigue un objetivo que se mueve más rápido de lo que puede hacerlo el proceso de generación de firmas. Para ver esa rotación desde la perspectiva de un defensor, echa un vistazo a cómo funciona en la práctica la señalización de Sliver.

La detección basada en el comportamiento invierte el problema. En lugar de enumerar elementos que se sabe que son maliciosos, se establece una línea de referencia de cómo se comunican normalmente los hosts —destinos, tiempos, volúmenes, protocolos— y se detectan las desviaciones compatibles con un canal de control. La detección de anomalías en la red proporciona esa disciplina de establecimiento de referencias; las secciones siguientes la aplican a las señales que una red de bots no puede evitar generar. Un bot puede cambiar de marcos, dominios y servidores de la noche a la mañana. Lo que no puede hacer es dejar de comunicarse, dejar de resolver sus puntos de encuentro o dejar de enviar el mismo cliente a todas partes —y cada uno de esos comportamientos es observable—.

Detección de señales de comando y control

El «beaconing» es la periodicidad con la que un bot se comunica con su mando y control servidor: el implante entra en reposo, se activa, solicita tareas y vuelve a entrar en reposo. Ese ritmo es la señal más característica de una botnet en una red, y detectarla es una cuestión de sincronización, no de la carga útil. MITRE realiza un seguimiento del transporte como T1071, Protocolo de la capa de aplicación, ya que las conexiones suelen realizarse a través de HTTPS o DNS normales.

El detector «naïve» se basa en la periodicidad. Agrupa los flujos por pares de hosts, calcula los intervalos entre conexiones sucesivas y busca una distribución demasiado regular: un tiempo de inactividad fijo de 60 segundos produce tiempos entre llegadas casi idénticos, algo que ningún patrón de navegación humano genera. Una baja varianza en docenas de observaciones lo convierte en un firme candidato a baliza.

Los atacantes lo saben, y por eso todos los marcos C2 serios incorporan «jitter»: cada intervalo de espera se aleatoriza dentro de un rango configurado, lo que dispersa la distribución entre llegadas hasta que los umbrales de varianza simples dejan de activarse. La comparación ingenua de intervalos falla en este caso. Pero el «jitter» aleatoriza cada intervalo individual; no elimina la programación subyacente.

El análisis en el dominio de la frecuencia aprovecha esa debilidad. Al transformar la línea temporal de la conexión al dominio de la frecuencia —la transformada de Fourier es la herramienta habitual—, una baliza recurrente concentra la energía en un pico en su frecuencia de registro subyacente. La fluctuación ensancha el pico, pero no lo elimina. Mientras la baliza se repita, siempre habrá una frecuencia fundamental que detectar, un enfoque que se ha demostrado públicamente frente a un C2 con fluctuaciones.

‍

Los registros de flujo constituyen la base práctica de todo esto: contienen las marcas de tiempo, el recuento de bytes y las duraciones que necesita el análisis sin necesidad de capturar la carga útil. El análisis del tráfico de red aborda esta metodología en profundidad.

Conoce los modos de fallo antes de la implementación. Las balizas de baja intensidad y baja frecuencia que permanecen inactivas durante horas pueden repetirse con una periodicidad demasiado escasa como para resolverlas dentro de tu ventana de análisis. Las llamadas de retorno desencadenadas por eventos que se activan con la actividad del usuario nunca alcanzan una frecuencia estable. Además, las empresas están repletas de periodicidades legítimas —NTP, comprobaciones de actualizaciones, agentes de telemetría, sondas de monitorización—, por lo que la periodicidad por sí sola es un factor para generar una lista de candidatos, no un veredicto definitivo. Corrobora los candidatos con la rareza del destino, la consistencia del tamaño de las sesiones y las señales de DNS que se describen en la siguiente sección antes de que un analista llegue a ver una alerta.

Detección basada en el DNS: DGA y «fast flux»

Los bots tienen un problema de localización —deben encontrar a su controlador incluso después de que se hayan incautado los dominios— y las dos soluciones predominantes, los algoritmos de generación de dominios y el «fast flux», dejan huellas por todo el DNS.

Un DGA genera un gran número de dominios candidatos de forma periódica; el operador registra solo unos pocos, y cada bot va revisando la lista hasta que uno de ellos se resuelve. MITRE clasifica esta técnica como T1568.002, y su estrategia de detección DET0419 (análisis AN1178–AN1181) recoge los indicios en los que coincidieron los defensores: nombres de dominio con alta entropía de caracteres y baja similitud léxica con el lenguaje real, consultas repetidas a dominios nunca vistos y —el indicio más evidente— fallos NXDOMAIN continuados cuando un servidor recorre candidatos que nunca se han registrado.

Fast Flux aborda el modelo de desactivación desde el otro lado: el dominio permanece fijo, mientras que la infraestructura que hay detrás va rotando. El Aviso sobre flujos rápidos de «Five Eyes» de 2025 describe el «flujo simple», en el que los registros A rotan entre los servidores comprometidos, y el «flujo doble», en el que los servidores de nombres también rotan — MITRE's T1568.001 (DET0485). Sus indicadores son concretos: valores de «tiempo de vida» (TTL) tan bajos que un dominio puede cambiar de dirección IP cada 3-5 minutos, decenas o cientos de direcciones IP que se van alternando cada día y una geolocalización inconsistente en las resoluciones de un dominio. El aviso también explica por qué falla el bloqueo de direcciones IP: cada dirección se retira antes de que la lista de bloqueo pueda propagarse. El DNS también puede transportar el propio canal C2, que se rastrea como T1071.004 (DET0400).

Las señales DNS de alto rendimiento, en el orden en que la mayoría de los equipos las comprueban:

1. Nombres de dominio de alta entropía, de aspecto aleatorio y sin significado léxico
2. Picos continuos de NXDOMAIN procedentes de un único host interno
3. Dominios recién registrados o desconocidos hasta ahora que reciben consultas repetidas
4. Tiempos de vida (TTL) del DNS anormalmente bajos: de unos segundos a unos pocos minutos
5. Un dominio que se resuelve en decenas o cientos de direcciones IP al día
6. Geolocalización inconsistente entre las direcciones IP resueltas de un dominio
7. Rotación de los registros del servidor de nombres (NS) junto con la rotación de los registros A
8. Registros de tráfico que muestran numerosas conexiones de corta duración a direcciones IP cambiantes

‍

El DGA y el «fast flux» generan señales DNS distintas, cada una con un «semejante benigno» diferente.

Esa segunda columna de riesgo es estructural, y el aviso lo deja claro: diferenciar el «fast flux» malicioso del comportamiento legítimo de las CDN y los equilibradores de carga «sigue siendo un reto constante». Los TTL bajos y las direcciones IP rotativas caracterizan a todas las principales CDN. El contexto es lo que las distingue: las rotaciones de las CDN se mantienen dentro de rangos de alojamiento bien conocidos, mientras que el «fast flux» recorre un gran número de hosts comprometidos que se utilizan como proxies y puntos de retransmisión. Establece primero unos valores de referencia para tus registros de resolutor; cada señal anterior es una medida de desviación, no un valor absoluto.

Detección de C2 cifrado sin descifrado

Cuando el canal C2 está cifrado — MITRE denomina esta técnica como T1573, Canal cifrado — La inspección de la carga útil no arroja ningún resultado, y el descifrado a gran escala suele ser inviable: la interceptación de TLS resulta costosa, y los implantes que fijan certificados simplemente se niegan a conectarse a través de ella. La alternativa práctica consiste en identificar al cliente sin tocar el texto sin cifrar.

La huella digital TLS genera un hash de los parámetros que un cliente proporciona durante el protocolo de establecimiento de conexión —versiones, conjuntos de cifrado, extensiones—, todos ellos visibles antes de que comience el cifrado. Un implante C2 distribuye una única pila TLS, por lo que su protocolo de establecimiento de conexión es siempre el mismo, independientemente de dónde se instale. JA3 creó la huella digital original, pero en 2023 Chromium comenzó a aleatorizar el orden de las extensiones TLS, lo que afectó a la estabilidad de JA3 en una gran parte del tráfico web y motivó el desarrollo de su sucesor, JA4, especificado por FoxIO. JA4 resiste esa aleatorización, y la suite más amplia JA4+ va más allá de TLS para identificar el propio tráfico TCP. Zeek añadió compatibilidad nativa con JA4 en enero de 2026, poniendo la técnica al alcance de cualquier equipo que utilice herramientas de monitorización de red de código abierto.

Ahora bien, hay un límite que las fuentes primarias no mencionan: ni la especificación JA4 ni el informe de Zeek cuantifican los falsos positivos, las colisiones ni la deriva. Ambos problemas son reales. Las huellas digitales colisionan: miles de aplicaciones inofensivas comparten bibliotecas TLS comunes, por lo que un hash que coincida con un implante conocido puede coincidir igualmente con una herramienta corriente construida sobre la misma pila. Las huellas digitales también se desvían: cada actualización del cliente puede modificar el protocolo de establecimiento de conexión, lo que hace que tus listas de coincidencias queden obsoletas de forma silenciosa. Trata una huella digital como una señal correlativa, nunca como un veredicto.

Este es el esquema general de la detección sensible a las técnicas de evasión. El cifrado elimina la carga útil, pero conserva el protocolo de establecimiento de conexión y la sincronización, por lo que el análisis de huellas digitales se combina con el análisis de metadatos de la sección de balizas: la duración de las sesiones, las distribuciones del tamaño de los paquetes y las proporciones de bytes siguen siendo observables en el tráfico cifrado. El argumento a favor de modelar el comportamiento C2 en lugar de descifrarlo se aplica a toda esta pila.

La detección mediante aprendizaje automático y el problema de los falsos positivos

Los resultados publicados sobre el aprendizaje automático para la detección de botnets parecen espectaculares. Un estudio de 2024 informó de una tasa de falsos positivos (FPR) del 1,53 % en el conjunto de datos IoT-23, al tiempo que identificaba el 100 % de las comunicaciones C2 basadas en paquetes y el 94 % de las basadas en flujos. Un artículo de 2025 sobre clasificadores apilados informó de una precisión en las pruebas del 97,94 % en UNSW-NB15, con una precisión del 99,99 % en su conjunto de entrenamiento. Lee la letra pequeña antes de elaborar tu presupuesto basándote en cifras como estas.

Empecemos por definir en qué consisten estos conjuntos de datos. IoT-23 es malware real malware en hardware real, pero en un laboratorio controlado, no en una red de producción. UNSW-NB15 es tráfico sintético generado por una herramienta de pruebas de IXIA. Ninguno de los dos contiene el tráfico desordenado, variable y que incumple las políticas de una empresa en funcionamiento, que es precisamente donde surgen los falsos positivos. Las medidas de precisión de los benchmarks se ajustan a las características del propio benchmark.

Ahora, las cuentas —y, para que quede claro, esta es nuestra interpretación, no una afirmación que haga ninguno de los dos artículos—. Una tasa de falsas alarmas (FPR) del 1,53 % parece insignificante hasta que la tasa de base la multiplica: con un millón de flujos al día —un volumen modesto para una empresa de tamaño medio—, el 1,53 % supone aproximadamente 15 300 falsas alarmas cada día. Ningún SOC clasifica eso. Siguiendo la misma lógica, interpretamos una precisión de entrenamiento del 99,99 % como una señal clásica de sobreajuste: el modelo ha memorizado su entorno de laboratorio, y los entornos de laboratorio no son transferibles.

Los resultados de las pruebas de referencia miden la adecuación al estándar de referencia, no el rendimiento con el tráfico real de la empresa.

Nada de esto hace que el aprendizaje automático sea inútil; lo que ocurre es que la ingeniería de precisión es el verdadero trabajo. Hay que limitar los modelos a preguntas concretas y bien definidas, correlacionar sus resultados con la periodicidad y las señales DNS mencionadas anteriormente, enriquecer los candidatos con inteligencia sobre amenazas y suprimir los servicios periódicos conocidos como benignos antes de que se active cualquier alerta. Esa disciplina de ajuste es la ingeniería de detección, y es lo que distingue a un punto de referencia de un detector. La lección es independiente del proveedor: la tasa base, y no el modelo de ningún producto, es la razón por la que todas las categorías de detección se enfrentan a falsos positivos de botnets.

Detección de redes de bots descentralizadas, sin agentes y P2P

Las redes de bots modernas se construyen cada vez más a partir de dispositivos que ningún equipo de seguridad gestiona. En la red de Cloudflare, el bombardeo DDoS de escala récord de finales de 2025 —ataques que Cloudflare relaciona con la red de bots Aisuru-Kimwolf— se remontó a una población de «principalmente televisores Android» estimada entre 1 y 4 millones de hosts. En marzo de 2026, el Departamento de Justicia de EE. UU. y sus socios internacionales desmantelaron la infraestructura detrás de cuatro botnets que habían comprometido más de tres millones de dispositivos IoT, según informó Krebs on Security. Nadie instala un agente de punto final en un televisor: en el caso de los dispositivos IoT no gestionados, la columna de telemetría de punto final está vacía por definición, y la red es el único lugar donde puede producirse la detección.

La telemetría de terminales y la de red recogen dos aspectos distintos de una botnet, y solo la de red abarca los dispositivos sin agente.

Las redes de bots con proxies residenciales agravan el problema. En 2026, el grupo de inteligencia sobre amenazas de Google (GTIG) describió la red de proxies NetNut/Popa: al menos dos millones de dispositivos registrados a través de SDK integrados en televisores inteligentes y dispositivos de streaming, con 316 grupos de amenazas distintos observados utilizando nodos de salida sospechosos de pertenecer a NetNut en una sola semana. Ese tráfico sale del espacio de direcciones habitual de los proveedores de acceso a Internet para consumidores, por lo que los algoritmos heurísticos de reputación y geolocalización lo califican como benigno, aunque las primitivas de flujo y geolocalización del aviso sobre «fast flux» siguen siendo aplicables.

Las arquitecturas peer-to-peer eliminan por completo el servidor central: no hay un único servidor C2 al que desviar el tráfico, y el análisis de flujos por sí solo no basta para la detección. En su lugar, los métodos basados en grafos modelan la topología de la comunicación; los detectores topológicos publicados obtuvieron una puntuación F1 media del 99,140 %, aunque en 2020 y en topologías de referencia. Considéralo una prueba a nivel de investigación de que el enfoque funciona, no una funcionalidad lista para su implementación.

Las operaciones de desmantelamiento cuentan la misma historia desde otra perspectiva. Europol informó de la incautación de 1.025 servidores en la Operación Endgame, que resultó eficaz precisamente porque esas operaciones contaban con un sistema C2 centralizado. Las técnicas de «fast flux», DGA y P2P existen para eludir ese modo de fallo, por lo que la localización de los dispositivos reclutados para formar parte de una red de bots no puede delegarse únicamente en las operaciones de desmantelamiento.

Correlación de la detección de botnets con MITRE ATT&CK NIST CSF

La descripción del marco garantiza que este trabajo sea auditable. Actual MITRE ATT&CK es la versión 19.1: 15 tácticas, en la que la antigua «Evasión de defensa» se ha dividido en «Sigilo» (0005) y la merma de la capacidad de defensa (0112) — y sus conceptos de «Estrategias de detección» y «Análisis» se presentaron en v18, publicada el 28 de octubre de 2025. En el NIST CSF 2.0 (CSWP 29, publicado el 26 de febrero de 2024) Por otra parte, la supervisión continua de la red en el marco de DE.CM-01 es el punto de anclaje principal, DE.CM-09 abarca la supervisión de terminales y de los sistemas informáticos, y DE.AE-02, DE.AE-03y DE.AE-07 abarcan el análisis de eventos, la correlación entre múltiples fuentes y el enriquecimiento de la información. La tabla de correspondencias que figura a continuación relaciona cada señal de esta guía con ambos marcos de referencia, así como con tu contexto más amplio detección de amenazas programa.

Cada señal de detección de botnets que aparece en esta página se corresponde con una MITRE ATT&CK concreta del marco MITRE ATT&CK y con una subcategoría «DETECT» del NIST CSF 2.0.

Enfoques modernos para la detección de botnets

Todo lo anterior converge en una única postura operativa: dar por hecho que se ha producido una intrusión, vigilar la red y modelar el comportamiento, ya que la botnet que más necesitas encontrar se ejecuta en un dispositivo que no gestionas, a través de un canal que no puedes descifrar y utilizando una infraestructura que ninguna lista de bloqueo ha detectado jamás. La detección y respuesta de red (NDR) es la capa operativa en la que estas técnicas se ejecutan de forma continua como detecciones diseñadas y correlacionadas, en lugar de búsquedas puntuales. Existe un amplio mercado de herramientas de detección de botnets que implementan partes de esta pila; evaluar ese panorama es una tarea distinta a comprender las técnicas en las que se basa.

Cómo Vectra AI la detección de botnets

Vectra AI la detección de botnets como un problema de modelización del comportamiento, en lugar de como un problema de firmas. Attack Signal Intelligence el comportamiento de los sistemas de comando y control en la red —cadencia de las señales de baliza, patrones de DNS compatibles con la generación de dominios, características de los canales cifrados— y correlaciona esos comportamientos entre los distintos hosts para distinguir un canal de control auténtico de la periodicidad habitual. Dado que el análisis se basa en la red, se aplica igualmente a los dispositivos sin agente, en los que nunca existirá telemetría de los terminales.

Conclusión

La detección de botnets se ha desplazado hacia un ámbito al que los atacantes no pueden seguir: los comportamientos que debe mostrar un bot para funcionar. Las firmas y las listas de bloqueo siguen filtrando el ruido habitual, pero las señales duraderas son la periodicidad que resiste la fluctuación, el comportamiento del DNS que resiste la rotación de dominios, las huellas digitales y la sincronización que resisten el cifrado, y la visibilidad de la red que resiste la ausencia de un agente. Desarrolla esos cuatro elementos, asóyalos con MITRE ATT&CK el NIST CSF, y ajústalos teniendo en cuenta la tasa de base.

‍