Un directorio expuesto reveló cómo un actor explotó fallas de 2021 y credenciales SDK compartidas para tomar control de dispositivos en Ucrania y Rusia durante cinco semanas.
Entre el 17 de junio y el 22 de julio de 2026, un actor comprometió más de 14.000 cámaras Dahua distribuidas principalmente en Ucrania y Rusia. La operación, reconstruida por Hunt.io a partir de archivos filtrados del propio atacante, combinó fuerza bruta, cadenas de bypass de autenticación basadas en vulnerabilidades de 2021 y acceso directo a través del relé en la nube del fabricante. El hallazgo se produjo cuando el sistema AttackCapture de Hunt.io rastreó el servidor 154.86.119.60 el 23 de julio y descargó 2.616 archivos distribuidos en 234 subdirectorios — 407 MB en total — desde un directorio HTTP que el operador había dejado abierto sin restricciones. Ese único error expuso el motor de escaneo, las cadenas de explotación, el bot de exfiltración y un stealer para Windows alojado en el mismo servidor.
Tres rutas de acceso, una sin credenciales válidas
El motor de fuerza bruta del atacante alcanzó más de 12.300 direcciones IP únicas. Una segunda ruta explotó dos vulnerabilidades de Dahua de 2021 para plantar una cuenta de puerta trasera persistente en 1.923 cámaras — una cuenta almacenada independientemente de la contraseña de administrador que sobrevive tanto a un cambio de credenciales como, en la mayoría de los firmwares, a un restablecimiento de fábrica. La tercera ruta evitó por completo las direcciones IP y llegó a 283 cámaras únicamente mediante número de serie, a través del relé en la nube de Dahua.
Esta última vía es la que plantea el problema estructural más grave. El relé en la nube de Dahua permite que cualquier aplicación alcance una cámara detrás de NAT usando solo su número de serie, y la autenticación a ese relé se basa en credenciales SDK idénticas integradas en cada aplicación cliente de Dahua jamás enviada. Los propios registros del operador documentan el resultado de sondear este canal a escala: el 89,4 por ciento de los números de serie activos devolvieron un canal abierto sin autenticación. Nueve de cada diez cámaras resultaron accesibles para cualquiera capaz de adivinar o recolectar un número de serie.
Cómo el relé en la nube convierte un número de serie en acceso directo
El dispositivo nunca autentica a la parte que se conecta. Autentica la sesión mediante un token que la nube emitió antes de que el dispositivo fuera contactado. Obtener ese token requiere únicamente las credenciales SDK fijas compartidas por toda aplicación legítima de Dahua. La única barrera real para alcanzar cualquier cámara a través de esta ruta es conocer su número de serie — precisamente lo que el pipeline de recolección del operador existe para producir a escala. Pasar de la sesión de túnel al acceso administrativo completo todavía requiere credenciales válidas o un bypass de autenticación, pero los registros del atacante sugieren que la mayoría de las cámaras expuestas no necesitaron este paso final.
Hunt.io identificó dos problemas de atribución técnica en la documentación del operador. La herramienta vincula su técnica de puerta trasera persistente a CVE-2024-39943, pero ese CVE en realidad se refiere a una falla de inyección de comandos diferente en HTTP File Server de Rejetto. La técnica es válida, pero la referencia CVE es incorrecta. Del mismo modo, el abuso del relé no es CVE-2025-31702, que Dahua describe como una falla de escalada de privilegios autenticada más acotada. Referencias CVE incorrectas pueden enviar a los defensores a buscar el parche equivocado.
Un stealer para Windows en el mismo servidor, sin relación aparente con las cámaras
Hunt.io también encontró un binario Windows empaquetado con UPX, etiquetado como SalatStealer, alojado en el mismo servidor junto a un script PowerShell que desactiva Windows Defender de cinco maneras diferentes, incluyendo una clave de directiva de grupo diseñada para sobrevivir reinicios y actualizaciones de Defender. Los investigadores lo tratan como una capacidad separada y no relacionada que comparte infraestructura, no como parte de la campaña de cámaras propiamente dicha.
Lo que destaca en todo el conjunto de herramientas es que nada fue construido desde cero. El motor de fuerza bruta, la cadena de bypass, las herramientas de relé, el generador de códigos de recuperación: cada uno se remonta a un repositorio público diferente, acreditado — a veces con precisión — a al menos seis desarrolladores distintos. El operador ensambló, parcheó y reescribió, superponiendo comentarios en ruso sobre código en español en un componente recuperado en tres etapas separadas de la misma reescritura.
Por qué México, Brasil y Argentina quedan expuestos por el mismo patrón de dependencia
Dahua y sus líneas OEM rebrandeadas — Amcrest, Lorex, Annke, Swann, entre otras — tienen presencia significativa en América Latina, particularmente en México, Brasil y Argentina, donde se utilizan tanto en despliegues comerciales como en infraestructura crítica de vigilancia urbana. La dependencia del relé en la nube con credenciales SDK compartidas no es una vulnerabilidad específica de Ucrania o Rusia: es una característica de diseño global del backend de Dahua. Cualquier cámara de estas marcas conectada a internet en la región queda expuesta al mismo vector de acceso por número de serie que el operador explotó a escala en Europa del Este, siempre que el dispositivo tenga habilitado el modo P2P y su número de serie sea conocido o recolectable mediante escaneo.
El generador de códigos de recuperación offline es posiblemente la pieza más consecuente precisamente porque no necesita un dispositivo comprometido en absoluto. Dado un número de serie activo, deriva un código completamente offline que desbloquea el flujo de recuperación de cuenta a nivel de nube de Dahua, sin necesidad de credenciales actuales. Eliminar una cuenta de puerta trasera no afecta esto. Solo un cambio por parte de Dahua en cómo se deriva el código lo haría.
Nuestro análisis
Esta es la segunda operación de compromiso masivo de cámaras Dahua que Hunt.io rastrea hasta un directorio de operador expuesto en dos semanas. La diferencia de escala — 14.000 dispositivos frente a 58 — sugiere que el patrón de error operacional (dejar directorios HTTP abiertos) no es un caso aislado sino una práctica recurrente entre actores que operan contra este tipo de infraestructura. Lo que distingue a Operation CameraSwarm no es la sofisticación técnica — todo el toolkit es código reutilizado de repositorios públicos — sino la combinación de tres vectores de acceso paralelos que explotan tanto fallas conocidas de 2021 como una característica de diseño del relé en la nube que Dahua nunca corrigió. El hecho de que el 89,4 por ciento de los números de serie activos devolvieran un canal sin autenticación convierte el problema de seguridad en un problema de arquitectura: no se trata de parchar un CVE específico sino de rediseñar cómo el relé en la nube autentica sesiones.
Para quienes operan equipos Dahua o sus variantes OEM, la lista de mitigación es directa: verificar la presencia de una cuenta p2pwn y eliminarla, deshabilitar P2P en cualquier dispositivo donde no sea estrictamente necesario, confirmar que el firmware está parcheado contra el par de bypass de 2021, y rotar todas las credenciales que la cámara haya almacenado alguna vez, dado que el bot de exfiltración también las capturó. Ninguna de estas medidas resuelve el problema del código de recuperación. Ese queda del lado del fabricante. ¿Cuántas operaciones más de este tipo tendrán que filtrarse antes de que Dahua revise el diseño de autenticación de su relé en la nube?