Un actor de amenazas llevó a cabo un ataque masivo cámaras IP contra dispositivos Dahua, comprometiendo más de 14.000 cámaras en Ucrania y Rusia, según un reporte de Hunt.io. La actividad se desarrolló entre el 17 de junio y el 22 de julio y combinó exploración de red, intentos de acceso por fuerza bruta y una puerta trasera persistente mediante mecanismos asociados a RPC.
El incidente no solo apunta a un uso directo de credenciales expuestas, sino también a una cadena de técnicas más amplia: infraestructura preparada con antelación, explotación de fallos de autenticación y, en algunos casos, uso de relés en la nube para alcanzar cámaras situadas detrás de NAT. Aunque el análisis describe con detalle cómo funcionó la intrusión, el reporte no determina con certeza la motivación final ni el objetivo de los atacantes.
Cómo se ejecutó el ataque masivo contra cámaras Dahua
La campaña, denominada Operation CameraSwarm, arrancó con un barrido global de rangos de ISP vinculados a Rusia, además de incluir rangos de México y Vietnam. Con el paso del tiempo, el foco se desplazó principalmente a netblocks de telecomunicaciones rusas y del ámbito CIS.
Una vez detectados objetivos potenciales, Hunt.io indica que el actor consiguió acceso a sus propios servidores asociados a la operación. Allí encontró un conjunto de datos compuesto por 2.616 archivos distribuidos en 234 subdirectorios, con un volumen cercano a 407 MB. Importante: esos contenidos residían en un directorio HTTP abierto al que los atacantes “se expusieron” sin protección adecuada.
Fuerza bruta y alcance del compromiso
Del análisis de la información recuperada se concluye que la campaña resultó en la compromisión de más de 14.530 dispositivos durante los 35 días de actividad. Para intentar el acceso, el actor utilizó un motor de fuerza bruta que apuntó a 12.324 direcciones únicas.
Este enfoque sugiere que no se trató únicamente de encontrar cámaras “al azar”, sino de insistir en objetivos concretos hasta lograr acceso. En escenarios de cámaras IP, la superficie de ataque suele ampliarse cuando existe reutilización de credenciales, configuraciones débiles o servicios accesibles desde Internet sin una segmentación adecuada.
Cuenta persistente por RPC: lo que permitía volver a entrar
Uno de los hallazgos más relevantes del reporte es la instalación de una cuenta de puerta trasera persistente en una parte de las cámaras comprometidas. Según Hunt.io, la cuenta se desplegó en 1.923 cámaras mediante Remote Procedure Call (RPC).
La credencial usada sigue el patrón p2pwn / p2password (usuario y contraseña). Lo especialmente preocupante es su capacidad de persistir incluso cuando el administrador intenta “limpiar” el equipo: el reporte indica que la cuenta se almacena de forma independiente de la contraseña del usuario administrador, de modo que sobrevive al cambio de contraseña. Además, en la mayoría de los firmwares, también continúa tras un restablecimiento de fábrica, según el análisis reportado por Hunt.io.
En términos prácticos, esto complica la respuesta operativa. No basta con modificar contraseñas si el mecanismo malicioso es capaz de reaparecer o mantenerse tras procedimientos estándar.
Bypass de autenticación encadenando vulnerabilidades
Para conseguir acceso más allá de credenciales válidas, el actor empleó un marco de fuerza bruta basado en un proyecto disponible públicamente en Python con soporte para asyncio. Sin embargo, el reporte también describe una pieza clave: un binario compilado en Go diseñado para evadir la autenticación.
Ese binario, de acuerdo con Hunt.io, encadena tres vulnerabilidades. Entre ellas se mencionan los bypass asociados a CVE-2021-33044 y CVE-2021-33045, además del uso de CVE-2024-39943 para implementar la cuenta de puerta trasera.
Qué hacen los bypass reportados
El análisis detalla que, para CVE-2021-33044, existe un comportamiento de “confianza incondicional” en cómo el cliente se identifica como controlador NetKeyboard. En ese caso, cuando clientType es NetKeyboard, el campo de contraseña no se evalúa. Por su parte, CVE-2021-33045 se apoya en que el firmware tomaría la dirección origen declarada desde el body de la solicitud en lugar de depender de la conexión TCP real.
El efecto conjunto de estos bypass permite devolver una sesión de administrador completa de forma no autenticada. Después, el binario deja caer la cuenta con credenciales p2pwn / p2ppassword (según se describe en el reporte) usando RPC, cerrando el ciclo para garantizar acceso posterior.
Uso de relé en la nube para cámaras detrás de NAT
No siempre los atacantes tenían un camino directo a las cámaras. En algunos casos, el actor habría abusado del cloud relay del ecosistema para alcanzar dispositivos ubicados detrás de NAT (traducción de direcciones de red).
Según Hunt.io, en esos escenarios los atacantes podían operar con solo el número de serie de la cámara. Esto reduce el requisito de exposición del servicio a Internet: incluso si la cámara no es accesible de manera directa desde el exterior, el abuso de mecanismos de intermediación puede facilitar la conexión.
Infraestructura preparada con tiempo y código reutilizado
El reporte también señala que el actor montó la infraestructura usada al menos un año antes de ejecutar la campaña. Además, el material recuperado de los servidores sugiere que el “toolkit” no era exclusivamente de autoría propia.
Hunt.io afirma que el paquete incluía tanto código propio como código modificado de al menos cuatro otros desarrolladores. A partir de elementos como un diseño de recuperación basado en código transferible y una canalización de exportación con formato empresarial, la evaluación del reporte indica una conclusión con confianza moderada: el toolkit habría sido pensado para dar acceso a un tercero.
En cualquier caso, el reporte aclara que esta situación es más limitada que una operación comercial plenamente confirmada, ya que la evidencia disponible no respalda una lectura más amplia.
Qué significa esto para usuarios y administradores
Más allá de las cifras, el caso muestra un patrón: en cámaras IP el ataque no termina en el acceso inicial. La capacidad de colocar una puerta trasera que resiste cambios de contraseña y, en muchos firmwares, también resta de fábrica, eleva el impacto y obliga a revisar el enfoque de respuesta.
Si administras entornos con cámaras Dahua u otros proveedores, conviene tomar el incidente como referencia para evaluar tres frentes: exposición de servicios (evitar accesos innecesarios desde Internet), actualización y validación de firmware, y revisión de cuentas o mecanismos persistentes que puedan sobrevivir a cambios manuales.
También resulta importante segmentar la red de IoT y aplicar controles que reduzcan el valor de la fuerza bruta, como límites de intentos, reglas de firewall y supervisión de conexiones anómalas.
Motivación desconocida, pero el impacto es claro
Por ahora, el reporte no establece la motivación última del operador ni el uso previsto de las cámaras comprometidas. Dicho de otro modo: sabemos cómo atacaron y qué dejaron instalado, pero no se puede afirmar con certeza el objetivo final, ya sea vigilancia, acceso persistente o preparación para acciones posteriores.
Lo relevante para la seguridad es que el ataque masivo cámaras IP descrito combina técnicas que se refuerzan entre sí: reconocimiento, fuerza bruta, bypass de autenticación y una puerta trasera persistente por RPC. Ese “combo” aumenta la probabilidad de éxito y complica la recuperación.
Conclusión
El caso de Operation CameraSwarm evidencia que las cámaras IP pueden convertirse en un objetivo priorizado, especialmente cuando existen fallos explotables y credenciales o cuentas que persisten en el tiempo. Con un alcance de más de 14.530 dispositivos comprometidos, fuerza bruta contra direcciones únicas y una cuenta persistente p2pwn/p2ppassword desplegada vía RPC, el reporte subraya la necesidad de una respuesta que vaya más allá de “cambiar la contraseña”.
Si gestionas infraestructuras con cámaras, usa este incidente para reforzar la postura de seguridad: actualiza firmwares, reduce exposición, segmenta redes y verifica que no existan accesos o cuentas maliciosas que sobrevivan a procedimientos rutinarios.
Fuente: https://www.securityweek.com/threat-actor-hacks-14000-ip-cameras-in-ukraine-and-russia/
