La botnet ShadowV2 aprovecha los contenedores Docker de AWS mal configurados para operaciones de DDoS por encargo

ShadowV2 representa una nueva oleada de amenazas nativas de la nube que convierten instancias de contenedores mal configuradas en infraestructuras de ataque alquilables. La campaña se dirige a puntos finales Docker de Amazon Web Services (AWS) expuestos a la Internet pública, desplegando un conjunto de herramientas de varias etapas que combina un marco de comandos basado en Python y un troyano de acceso remoto basado en Go. Las técnicas observadas incluyen el restablecimiento rápido de HTTP/2, intentos automatizados de eludir el modo Cloudflare Under Attack y cargas útiles DDoS modulares adecuadas para operaciones DDoS-for-Hire. Este análisis disecciona la cadena de infección, la arquitectura C2, las técnicas de evasión y las mitigaciones prácticas para organizaciones que ejecutan Docker en clústeres de AWS, DigitalOcean o Kubernetes.

Botnet ShadowV2: AWS Docker mal configurado alimenta DDoS por encargo

ShadowV2 se dirige a API de Docker expuestas en Internet y a demonios de host mal configurados que se ejecutan en instancias EC2 de Amazon Web Services (AWS). Los escáneres identifican los puntos finales del motor Docker que aceptan solicitudes no autenticadas y luego ejecutan un ataque de varios pasos. Los atacantes generan un contenedor genérico de Ubuntu, instalan utilidades dentro de ese entorno de compilación efímero, capturan una imagen y, a continuación, ejecutan un contenedor activo que ejecuta un binario ELF basado en Go. Esta técnica favorece la compilación y ejecución in situ para reducir los artefactos detectables en el sistema de archivos host.

El ataque inicial aprovecha errores de configuración comunes en la nube en lugar de días cero desconocidos. Los atacantes escanean amplios rangos de IP a través de AWS y DigitalOcean, buscando APIs de Docker accesibles a través de TCP. Una vez descubierto, el módulo Python spreader ordena al demonio que extraiga o construya imágenes de contenedores y ejecute comandos privilegiados. A continuación, la carga útil basada en Go se registra en un servidor de mando y control y se une a la botnet ShadowV2 para realizar campañas DDoS de alquiler coordinadas.

Cadena de infección de Docker ShadowV2 y objetivos de AWS

La cadena de infección observada en 2025 demuestra claros pasos de orquestación adaptados a entornos en contenedores. El propagador utiliza llamadas no autenticadas a la API de Docker para ejecutar contenedores de construcción efímera y lanzar un tiempo de ejecución ligero que aloja la Go RAT. La RAT envía periódicamente mensajes de heartbeat a un dominio C2 oculto tras Cloudflare y espera nuevas coordenadas de ataque.

• Escaneo: los bots enumeran las API de Docker Engine conectadas a Internet a través de rangos de IP de AWS y DigitalOcean.
• Despliegue: se genera un contenedor de compilación genérico de Ubuntu para instalar herramientas de ejecución en el entorno de la víctima.
• Imagen: se crea una imagen del contenedor preparado y se instala como contenedor activo para ejecutar la carga útil basada en Go.
• Registro: la Go RAT establece comunicación HTTP con el C2 y obtiene tareas como el restablecimiento rápido HTTP/2 y los parámetros de inundación HTTP.
• Ataque: el nodo infectado participa en la amplificación del tráfico o en inundaciones HTTP dirigidas bajo el control del operador.

Este enfoque permite a los operadores centralizar la lógica maliciosa en contenedores efímeros y reducir las huellas forenses en los volúmenes del host. La táctica también dificulta que los propietarios de la infraestructura detecten el compromiso a través de simples comprobaciones de integridad de archivos, ya que gran parte de la actividad se produce en capas de contenedores.

Escenario	Técnica	Objetivos
Descubrimiento	Escaneado de la API de Docker a través de Internet utilizando diversos agentes de usuario	AWS, DigitalOcean, nodos Kubernetes expuestos
Despliegue	Contenedor de compilación de Ubuntu in situ e instanciación de la imagen	Motor Docker en instancias EC2
Comando	RAT basado en Go con HTTP C2	Infraestructura C2 detrás de Cloudflare

ShadowV2 cubre un nicho práctico para los delincuentes: la capacidad de convertir la computación en la nube en un recurso DDoS escalable. La dependencia de configuraciones erróneas en lugar de la explotación avanzada sugiere que una fracción significativa de los incidentes se pueden prevenir mediante el endurecimiento básico. Los operadores que ejecutan Docker en AWS deben auditar los puertos expuestos y restringir la API del motor Docker a localhost o a subredes VPC de confianza. Esta sección pone de relieve que la higiene básica de la nube a menudo impide la inscripción completa de redes de bots, una idea decisiva para los defensores.

Comando y control de la botnet ShadowV2: Python C2 y Go RAT en infraestructura de nube

La arquitectura C2 de ShadowV2 combina los modernos marcos web de Python con una protección resistente del borde de la nube. El plano de control observado utiliza un backend Python FastAPI que aprovecha Pydantic para la validación de datos y proporciona un panel de inicio de sesión orientado al operador. El alojamiento detrás de Cloudflare oculta el verdadero origen, lo que complica la atribución. El backend expone API para gestionar usuarios, configurar los tipos de ataque disponibles y orquestar qué puntos finales infectados participarán en campañas específicas.

La RAT basada en Go en contenedores Docker comprometidos se comunica a través de HTTP para sondear el C2 en busca de comandos y transmitir telemetría. La RAT puede ejecutar comandos nativos, lanzar módulos DDoS e informar de las características del sistema. El propagador Python y la RAT Go crean juntos un ecosistema modular en el que pueden integrarse nuevos vectores de ataque sin necesidad de realizar grandes cambios en el código del agente.

ShadowV2 C2 Características e interfaz de usuario

Las funciones de la API observadas incluyen la gestión de usuarios al estilo RBAC, plantillas de ataque, grupos de despliegue y listas de exclusión. La presencia de una API estructurada implica que los autores previeron una interfaz compatible con múltiples operadores o arrendatarios de pago, una característica distintiva de los servicios DDoS de alquiler. Un panel de operador alojado indica la intención de industrializar la venta y gestión de ataques, exponiendo funcionalidades normalmente asociadas con ofertas legítimas de plataforma como servicio.

• Orquestación basada en API que permite ataques programados y a petición.
• Panel de control del operador que ofrece configuración de ataques y gestión de exclusión de objetivos.
• Ingesta de telemetría de hosts infectados para comprobaciones de estado y selección de grupos.
• Ocultación de Cloudfront/CDN en dominios C2 para impedir su retirada.

La arquitectura de ShadowV2 tiene muy en cuenta la escalabilidad y la facilidad de mantenimiento. Al aprovechar FastAPI y los servicios de borde de la nube, los operadores pueden iterar rápidamente y responder a las medidas defensivas. El diseño C2 también permite la integración de nuevos módulos, como proxies SOCKS o herramientas de scraping, en consonancia con la creciente mercantilización del cibercrimen como servicio.

Componente C2	Role	Herramientas observadas
API de backend	Plano de control del operador	FastAPI, Pydantic, Cloudflare edge
Agente	Ejecución e informes	RAT basado en Go, sondeo HTTP
Esparcidor	Vector de compromiso inicial	Python spreader, abuso de la API de Docker

En la práctica, los defensores necesitan telemetría de las capas de orquestación de contenedores y registros de salida de red para detectar patrones sospechosos de sondeo y latido. Cruzar las marcas de tiempo de la actividad de la API de Docker con las operaciones de creación de contenedores suele revelar la creación no autorizada de imágenes. La detección más eficaz combina registros de flujo del proveedor de la nube, auditoría a nivel de host y herramientas que validan la exposición a la API de Docker. Esto nos lleva a una clara conclusión operativa: supervisar enérgicamente las interacciones del plano de control para romper el ciclo de vida C2.

Evasión de la botnet ShadowV2 y Cloudflare UAM: Intentos de evasión automatizados y restablecimiento rápido de HTTP/2

ShadowV2 demuestra diversas técnicas de evasión que tienen como objetivo eludir las defensas web como el Modo Bajo Ataque (UAM) de Cloudflare. Un método notable aprovecha la automatización de ChromeDP para resolver los desafíos de JavaScript presentados por Cloudflare, obteniendo cookies de autorización para reutilizarlas en solicitudes posteriores. La campaña también implementa ataques HTTP/2 Rapid Reset para explotar la semántica del protocolo en lugar de inundaciones puramente volumétricas, que pueden ser más eficaces contra ciertas pilas de servidores y mitigaciones.

Sin embargo, la heurística anti-automatización de Cloudflare y la evolución del desafío están diseñadas para detectar el tráfico de navegador sin cabeza. El intento de automatización presenta ventajas y desventajas: aunque a veces puede producir una cookie de autorización, el enfoque es frágil y detectable. El uso de ChromeDP por parte de ShadowV2 junto con técnicas de restablecimiento rápido subraya un intento estratégico de combinar ataques sigilosos y de baja huella con ráfagas de tráfico de gran volumen cuando surgen oportunidades.

Tácticas de evasión de ShadowV2 y respuestas de CDN

Las CDN en la nube como Cloudflare y Akamai desempeñan una doble función. Enmascaran los orígenes del backend C2, complicando los desmantelamientos, y actúan como defensores de primera línea para objetivos potenciales. Los intentos de ShadowV2 de resolver los desafíos a través de ChromeDP ponen de relieve la carrera armamentística entre la automatización sin cabeza y los mecanismos de desafío. Las medidas de mitigación de Akamai y Cloudflare suelen implicar la limitación de la velocidad, el endurecimiento de los desafíos y la puntuación de la reputación de IP, lo que obliga a los atacantes a confiar en la infraestructura pirateada en lugar de en el sondeo de los extremos.

• La automatización intenta resolver los retos de JavaScript utilizando herramientas de navegador sin cabeza.
• Ataques a nivel de protocolo como HTTP/2 Rapid Reset para eludir algunas heurísticas de limitación de velocidad.
• Uso de Cloudflare para ocultar los servidores C2 y complicar la identificación del origen.
• Recurrir a inundaciones HTTP volumétricas cuando los métodos sigilosos no surtan efecto.

Desde la perspectiva de un defensor, el análisis de la coherencia del protocolo TLS, los comportamientos de flujo HTTP/2 y los patrones de emisión de cookies pueden revelar soluciones de desafío automatizadas. Cuando se combinan con los registros de Akamai o Cloudflare, estas señales permiten a los equipos de seguridad bloquear o limitar las sesiones sospechosas antes de que se intensifiquen. La idea aquí es que la detección eficaz aprovecha tanto la telemetría de la capa de aplicación como los análisis proporcionados por la CDN para detectar intentos de elusión de la UAM.

Evasión	Técnica ShadowV2	Mitigación
Bypass UAM	Automatización de ChromeDP para obtener la cookie de autorización	Heurística de los retos de comportamiento y huellas dactilares de los dispositivos
Abuso de protocolo	Inundaciones por reinicio rápido HTTP/2	Gestión de flujos HTTP/2 y límites por conexión
Ocultación C2	Cloudflare fronting para dominios C2	Correlación de registros Edge y notificación de abusos

La mezcla de sigilo y volumen de ShadowV2 lo hace adaptable. La implicación defensiva es clara: las configuraciones de CDN y los cortafuegos de aplicaciones web deben configurarse con heurística en capas e intercambio automatizado de información para detectar actividades sofisticadas de DDoS por encargo. Observar la interacción de la emisión de retos, los patrones de uso de cookies y el comportamiento atípico de HTTP/2 es esencial para desbaratar estas campañas a gran escala.

La botnet ShadowV2 como DDoS de alquiler: Mercado de API, riesgos de Kubernetes y desconfiguraciones de la nube

Se ha observado que ShadowV2 ofrece API orientadas al operador que gestionan las cuentas de usuario, asignan privilegios de ataque y especifican qué grupos de sistemas infectados ejecutarán las órdenes. Este modelo comercializado se asemeja a las plataformas SaaS legítimas, pero da servicio a la demanda ilegal de campañas DDoS. El enfoque basado en API permite a los operadores solicitar mediante programación ataques contra objetivos específicos y excluir otros, lo que demuestra un nivel de control operativo normalmente visto en operaciones maduras de ciberdelincuencia como servicio.

Los errores de configuración van más allá de los demonios Docker aislados. Los clústeres de Kubernetes, los droplets de DigitalOcean e incluso los ejecutores de contenedores autoalojados pueden configurarse incorrectamente para exponer planos de control. Para organizaciones como la hipotética empresa de alojamiento "Atlas Web Services", un único nodo mal configurado permitió la propagación a un clúster que luego fue aprovechado por ShadowV2 para una campaña volumétrica coordinada. El incidente subraya cómo los pequeños fallos en el control de acceso pueden convertirse en riesgos para toda la plataforma.

Características del mercado de ShadowV2 y superficie de ataque nativa de la nube

La interfaz del operador admite la selección del tipo de ataque, la programación y los modelos de compra en línea con la economía de DDoS-for-Hire. Esto revela un canal de ventas bien pensado en el que los atacantes monetizan el acceso a los grupos de botnets. El modelo basado en plataformas reduce la fricción para los compradores y permite a los desarrolladores actualizar los módulos de ataque de forma centralizada. El resultado es una cadena de suministro dinámica en la que las desconfiguraciones de la nube sirven como materia prima para los mercados ilícitos.

• Los puntos finales de la API para la gestión de usuarios y ataques permiten la orquestación programática de campañas.
• Los errores de configuración de Kubernetes (servidor API expuesto, kubelets no autenticados) amplían la superficie de ataque.
• Los errores de configuración del proveedor de la nube en AWS y DigitalOcean provocan una rápida propagación lateral.
• Las interfaces tipo servicio bajan el listón para los clientes criminales que buscan ofertas DDoS-for-Hire.

Entre las medidas prácticas para reducir el riesgo se incluyen la aplicación de privilegios mínimos en las API de contenedores, la habilitación de TLS mutuo y el acceso basado en funciones en Kubernetes, y la garantía de que los sockets de demonio de Docker no están vinculados a interfaces públicas. La corrección de Atlas Web Services tras el incidente incluyó ACL a nivel de red, endurecimiento del host y un cambio a servicios de contenedores gestionados con un aislamiento por defecto más estricto. Las lecciones aprendidas demuestran que la disciplina operativa y las plantillas estandarizadas reducen drásticamente la exposición.

Características del mercado	Riesgo	Control recomendado
Orquestación de API	Ataques automatizados a gran escala	Auditoría y limitación del acceso a la API; detección de anomalías
Exposición de la API de contenedores	Punto de apoyo inicial a través de Docker Engine	Vincular la API de Docker a localhost; utilizar proxy de socket
Configuración errónea de Kubernetes	Movimiento lateral del racimo	RBAC, políticas de red y planos de control privados

El auge de las plataformas de DDoS de alquiler como ShadowV2 aprovecha la mercantilización de la computación en la nube y la postura de seguridad desigual entre los proveedores. Proteger los activos nativos de la nube requiere automatización, validación continua de la configuración y un modelado de amenazas que incluya tanto las dependencias de los servicios como la economía de los mercados ilícitos. La idea: cerrar los vectores de ataque fáciles obliga a los adversarios a dedicar más esfuerzo, lo que aumenta su coste operativo y reduce la incidencia del crecimiento oportunista de las redes de bots.

Nuestra opinión: La botnet ShadowV2 y los riesgos de AWS Docker en el futuro

ShadowV2 es un recordatorio de que la comodidad de la nube a menudo viene acompañada de una deuda de seguridad. La campaña convierte puntos finales de orquestación de contenedores y Docker mal configurados en Amazon Web Services y otros proveedores en un tejido de ataque alquilable. El uso de herramientas C2 basadas en Python y una Go RAT, combinadas con servicios de borde como Cloudflare para enmascarar la infraestructura, indica una creciente profesionalización en las operaciones DDoS-as-a-service. Las organizaciones deben tratar los planos de control de contenedores expuestos como vulnerabilidades críticas.

Entre las medidas concretas que se recomiendan figuran asegurarse de que no se pueda acceder a las API de Docker Engine desde la Internet pública, implantar controles de mínimos privilegios para los tiempos de ejecución de contenedores y habilitar la telemetría de host y de red para detectar comportamientos sospechosos de compilación y sondeo. Las ofertas de Kubernetes gestionado y las plantillas de orquestación reforzadas reducen el margen de error humano. Además, la integración de la telemetría CDN y WAF (de Cloudflare, Akamai y proveedores similares) en los procesos de respuesta a incidentes mejora la capacidad de detectar y desacelerar los ataques en una fase temprana.

• Audite las reglas del cortafuegos de la nube para garantizar que las API de Docker y los kubelets son privados.
• Implemente la exploración continua de la configuración y la detección de desviaciones para las plantillas de contenedores.
• Correlacione los registros de borde CDN con la telemetría de host para identificar el sondeo C2 y desafiar el abuso.
• Eduque a los equipos de plataforma sobre los valores predeterminados seguros al aprovisionar recursos de AWS, DigitalOcean o Kubernetes.

Los controles recomendados abarcan desde cambios en la infraestructura hasta prácticas operativas. El uso de infraestructura como código automatizada con puertas de acceso a políticas reforzadas evita la exposición accidental. Los registros preparados para el análisis forense, los registros de contenedores inmutables y la evitación del montaje de sockets Docker en el host para servicios de terceros reducen el radio de impacto de un ataque. La combinación de medidas preventivas y de detección es el único camino realista para reducir el impacto empresarial de la inscripción en redes de bots.

Control	Por qué ayuda	Acción rápida
Enlaces privados de la API de Docker	Bloquea el control remoto no autenticado	Reconfigure el demonio para que escuche en localhost o en un socket seguro
Orquestación gestionada	Reduce el riesgo de errores de configuración	Migración a Kubernetes gestionado con valores predeterminados reforzados
Correlación logarítmica de aristas	Detecta la actividad temprana de C2	Reenvío de registros de Cloudflare/Akamai a SIEM

Para leer más sobre los riesgos adyacentes y las tácticas defensivas, consulta los recursos que cubren los impactos de IoT, las herramientas de ciberseguridad basadas en IA y la higiene del malware. Temas como la forma en que el Internet de las cosas altera la superficie de ataque o cómo la IA informa la detección de amenazas son directamente relevantes para comprender el ecosistema en el que opera ShadowV2. Se pueden encontrar ejemplos y revisiones técnicas en sesiones informativas específicas y ejercicios de incidentes para mejorar la preparación.

• DualMedia sobre IoT y ciberseguridad: Impacto de IoT en la ciberseguridad
• Revisión técnica de la IA en ciberseguridad: Avances de la IA en ciberseguridad
• Recursos prácticos para wargames: Juego de ciberseguridad en Irlanda
• Contexto de compromiso del dispositivo inteligente: ¿Controlan los hackers los dispositivos inteligentes?
• Fundamentos y eliminación del malware: Qué es el malware y cómo eliminarlo
• Noticias y orientaciones continuas sobre la seguridad del IoT: Noticias sobre seguridad IoT

La evolución de ShadowV2 demuestra que los defensores deben seguir el ritmo de la industrialización de las herramientas delictivas. Dar prioridad a la higiene de las API de los contenedores, integrar los conocimientos de las CDN y tratar la desconfiguración de la nube como una vulnerabilidad crítica son las acciones inmediatas que reducen materialmente el riesgo. La idea final: aumentar el coste operativo para los adversarios mediante un control coherente y automatizado reduce el mercado de servicios DDoS de alquiler y mejora la resistencia colectiva.