Campaña UAT-10027: cómo detectar y contener el backdoor Dohdoor en entornos Windows corporativos

Gustavo Sied > Seguridad > Campaña UAT-10027: cómo detectar y contener el backdoor Dohdoor en entornos Windows corporativos

Cisco Talos describió una campaña activa contra educación y salud en EE.UU. que combina phishing, DLL sideloading y C2 sobre DNS-over-HTTPS. Qué implica para equipos de SysAdmin, SOC y DevOps, y cómo responder con foco operativo.

Bajada: Cisco Talos reportó una campaña activa atribuida al clúster UAT-10027, con foco en organizaciones de educación y salud en Estados Unidos. El actor usa una cadena de ataque por etapas para implantar Dohdoor, un backdoor que oculta su canal de mando y control detrás de DNS-over-HTTPS (DoH) y servicios cloud ampliamente permitidos. Para equipos de infraestructura y seguridad, el caso es relevante porque combina técnicas conocidas (phishing, sideloading, process hollowing) con evasión práctica de controles de red y endpoint.

Qué se sabe de la campaña y por qué importa

Según la publicación técnica de Cisco Talos del 26 de febrero de 2026, UAT-10027 mantiene actividad al menos desde diciembre de 2025 y apunta a organizaciones con alta presión operativa y baja tolerancia a indisponibilidad. El objetivo final observado es desplegar Dohdoor para mantener acceso remoto encubierto y habilitar carga de payloads adicionales en memoria.

El impacto potencial no se limita a un host comprometido: en instituciones educativas y sanitarias, una intrusión de este tipo puede afectar continuidad de servicios, integridad de datos sensibles y operaciones de TI críticas. Desde la mirada SysAdmin/DevOps, el patrón es claro: si el actor consolida persistencia, el incidente pasa rápido de “malware en endpoint” a “riesgo de movimiento lateral y degradación operativa”.

Cadena de ataque observada (de phishing a ejecución en memoria)

Talos describe una secuencia multi-etapa:

Acceso inicial probable vía phishing, que dispara un script de PowerShell.
Descarga de script batch desde infraestructura remota.
Descarga de DLL maliciosa disfrazada como archivo legítimo (por ejemplo, propsys.dll o batmeter.dll).
DLL sideloading usando binarios legítimos de Windows como Fondue.exe, mblctr.exe o ScreenClippingHost.exe.
Despliegue de Dohdoor, con C2 por DoH y descarga/ejecución reflectiva de siguiente etapa (incluyendo comportamiento compatible con Cobalt Strike en algunos casos).

La combinación no es nueva en términos de TTPs, pero sí efectiva: aprovecha herramientas y rutas válidas del sistema para reducir señales anómalas evidentes.

DoH + Cloudflare como capa de ocultamiento

Uno de los aspectos más importantes del caso es el uso de DNS-over-HTTPS para resolver dominios C2. En vez de generar consultas DNS en texto claro que un SOC detecta con controles tradicionales, Dohdoor encapsula resolución y tráfico en HTTPS hacia servicios legítimos de alta reputación. Resultado: desde muchos controles de perímetro, el flujo parece tráfico web normal.

Esto no implica que DoH sea “malicioso” por definición; sí implica que un enfoque de seguridad basado solo en reputación de destino o bloqueo de DNS clásico ya no alcanza. Para operaciones reales, hay que complementar con telemetría de proceso, correlación de comportamiento y reglas de detección centradas en cadena de ejecución.

Evasión en endpoint: API hashing, desencriptado y process hollowing

El análisis técnico difundido por Talos y retomado por medios especializados muestra que Dohdoor:

Resuelve APIs con hash-based lookups para dificultar firmas estáticas.
Recibe payload cifrado y lo desencripta con rutinas personalizadas.
Inyecta en procesos legítimos mediante process hollowing.
Intenta sortear controles EDR con técnicas de syscall unhooking en ntdll.dll.

Para equipos defensivos, la conclusión es directa: la detección más confiable no surge de un único IOC, sino de encadenar eventos (script inicial + creación de carpeta oculta + carga anómala de DLL + conexión HTTPS contextual + inyección de proceso).

Qué revisar hoy mismo en infraestructura Windows

Un plan de validación rápida (24 horas) para equipos de operaciones:

PowerShell y línea de comandos: buscar ejecuciones con curl.exe y URLs codificadas, especialmente en estaciones administrativas y servidores de salto.
Persistencia y staging: auditar creación de rutas ocultas bajo C:\ProgramData y C:\Users\Public.
Carga lateral de DLL: detectar binarios legítimos ejecutados fuera de rutas esperadas junto con DLLs sospechosas.
Telemetría de red por proceso: correlacionar procesos no navegadores con tráfico HTTPS repetitivo hacia dominios de baja confianza o TLDs inusuales.
EDR hardening: activar reglas de memoria/inyección y revisar alertas de manipulación de llamadas del sistema.
Higiene de correo: reforzar políticas anti-phishing con sandboxing de adjuntos y bloqueo de macros/scripts no firmados.

Acciones recomendadas para SysAdmin, SOC y DevOps

SysAdmin: limitar ejecución de intérpretes en hosts no administrativos (PowerShell constrained language mode donde aplique), reforzar AppLocker/WDAC y revisar permisos locales que habilitan abuso de LOLBins.

SOC: priorizar casos que combinen sideloading + beaconing HTTPS + inyección de proceso. No depender de un único feed IOC; usar detección por comportamiento y hunting iterativo.

DevOps/Plataforma: incorporar validaciones de hardening de endpoints Windows en pipelines de baseline (GPO/MDM/infra as code), y agregar pruebas de detección en ejercicios de purple team para cadenas con DoH.

Cierre

La campaña UAT-10027 no introduce una “técnica imposible”; explota, con buena ingeniería operativa, debilidades conocidas en monitoreo y respuesta. El aprendizaje para equipos técnicos es pragmático: reducir superficie de ejecución, elevar visibilidad por proceso y practicar contención rápida ante señales débiles pero correlacionadas. Quien logre esa disciplina operativa tendrá ventaja frente a amenazas que se camuflan en tráfico legítimo.

Fuentes consultadas: