Dos SOC, dos resultados: el red team de CISA desmonta las defensas de dos infraestructuras críticas

El 25 de agosto de 2026, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) publicó un aviso de seguridad que compara dos evaluaciones ofensivas realizadas en paralelo. Los resultados muestran una brecha profunda: una de las dos organizaciones no detectó ninguna actividad maliciosa, mientras que la otra identificó y aisló los intentos iniciales, obligando al red team a operar en modo "asumir la brecha" (assume breach). Sin embargo, en ambos casos, los atacantes simulados obtuvieron acceso completo al dominio, a sistemas empresariales sensibles y a recursos en la nube. El aviso no incluye CVE ni indicadores de compromiso: se trata de un informe de evaluación, no de un boletín sobre una vulnerabilidad específica.

Dos organizaciones, sectores críticos, mismo objetivo

La CISA llevó a cabo dos evaluaciones de red team simultáneas. La primera se centró en una organización del sector de Servicios Gubernamentales e Instalaciones (Government Services and Facilities Sector, Organización A), y la segunda en una organización del sector de Sistemas de Agua y Aguas Residuales (Water and Wastewater Systems Sector, Organización B). Un red team simula las tácticas de actores de amenazas reales para evaluar las capacidades de detección, investigación y respuesta de una organización. El objetivo es obtener y mantener acceso persistente a la red corporativa y a los sistemas empresariales sensibles seleccionados por la propia organización. Estos sistemas, denominados SBS, son aplicaciones, almacenes de datos o componentes de infraestructura cuyo compromiso tendría un impacto material en las operaciones, las finanzas o los datos de los clientes.

La asistencia de la CISA está autorizada de conformidad con 6 U.S.C. §§ 652(c)(5) y 659(c)(6). El informe utiliza el marco MITRE ATT&CK for Enterprise, versión 19, para mapear las tácticas y técnicas observadas. No se han revelado las versiones exactas de los productos involucrados: el análisis se centra en configuraciones y tecnologías comunes como Active Directory, Active Directory Certificate Services (ADCS), System Center Configuration Manager (SCCM), AWS IAM y herramientas de detección y respuesta en endpoints (EDR).

Organización A: compromiso total sin ninguna alarma

En el caso de la Organización A, el red team logró un compromiso total del dominio y acceso a múltiples SBS y recursos en la nube sin que los defensores detectaran o contuvieran la actividad. El camino comenzó con el reconocimiento: se identificó una aplicación web con credenciales predeterminadas para múltiples cuentas integradas, que permitía enviar correos electrónicos desde una dirección de correo interna. Esa dirección se utilizó para campañas de phishing dirigido, lo que llevó al acceso inicial en cuatro estaciones de trabajo.

Desde las estaciones de trabajo comprometidas, el red team ejecutó un recolector BloodHound modificado, personalizado para evadir las firmas estáticas del EDR. La herramienta consultó Active Directory recopilando información sobre usuarios, equipos, grupos, listas de control de acceso, unidades organizativas y objetos de directiva de grupo (GPO). Una de las estaciones de trabajo tenía la cuota de cuentas de máquina (Machine Account Quota, MAQ) predeterminada en 10: este valor permite a usuarios no privilegiados agregar hasta 10 cuentas de equipo al dominio. En combinación con plantillas de ADCS configuradas incorrectamente según la técnica conocida como ESC1, el equipo pudo crear una cuenta de equipo y solicitar certificados para cualquier cuenta de usuario o equipo. A partir de ahí, el movimiento lateral se volvió sistemático.

Después de obtener privilegios elevados en el dominio, el plan para acceder a los SBS consistía en utilizar los datos de Active Directory para identificar usuarios y grupos vinculados a los sistemas sensibles, consultar los servidores SCCM para enumerar las relaciones usuario-dispositivo y localizar las estaciones de trabajo asignadas. El movimiento lateral desde el servidor SCCM hacia las estaciones de trabajo de los usuarios objetivo permitió buscar material de credenciales. Para el primer SBS, una base de datos, se encontraron credenciales en texto plano en la estación de trabajo de un usuario administrador. Para la segunda base de datos, la búsqueda se centró en los archivos connections.json y product-preferences.xml de una herramienta SQL Developer: descifrados, revelaron la contraseña en texto plano de la base de datos. Para el tercer SBS, un sistema de procesamiento automatizado, se obtuvieron credenciales de usuario de AWS Identity and Access Management (IAM) estáticas y de larga duración, guardadas en archivos de configuración en los directorios personales de los usuarios objetivo. La organización no había configurado caducidad ni rotación para esas credenciales.

No saltó ninguna alarma. El acceso a los SBS se extendió incluso a los escritorios virtuales, que limitan el acceso a las sesiones activas e interactivas de los usuarios y añaden controles como la segmentación de las redes de los sistemas sensibles. Ni siquiera esto detuvo al red team.

Organización B: detección temprana, pero el "assume breach" concede acceso de todos modos

La Organización B mostró una postura defensiva muy diferente. Identificó rápidamente los intentos de compromiso inicial, puso en cuarentena los sistemas afectados y obligó al red team a pasar a un modelo de "asumir la brecha" (assume breach). En dicho modelo, los agentes de confianza de la organización (trusted agents, TA) proporcionaron acceso a un host que replicaba el nivel de acceso que el red team habría tenido si los defensores no hubieran detectado la actividad inicial.

Desde ese host, el red team elevó privilegios, se movió lateralmente hacia los SBS, los recursos en la nube y un host bastión en la DMZ OT. Aquí, los defensores volvieron a detectar la actividad y aislaron el sistema. El acceso a la red OT se demostró sin ejecución real en los sistemas OT. A pesar de la doble detección y aislamiento, el modelo "assume breach" permitió demostrar el acceso a los SBS, la nube y la DMZ OT. La resiliencia de la Organización B ralentizó al atacante, pero no eliminó el riesgo.

Las técnicas detrás del compromiso: ADCS, MAQ, SCCM y credenciales estáticas

El informe mapea las actividades con varios identificadores del marco MITRE ATT&CK v19, incluidos T1589.001 (identificación de la víctima), T1566 (phishing), T1087.002 (descubrimiento de cuentas), T1018 (descubrimiento de sistemas remotos), T1069.002 (descubrimiento de grupos de permisos), T1615 (descubrimiento de directivas de grupo), T1136.002 (creación de cuentas de dominio), T1649 (robo o falsificación de certificados), T1033 (descubrimiento del propietario del sistema), T1552 (credenciales no protegidas) y T1552.001 (credenciales en archivos).

La combinación de una cuota de cuentas de máquina (MAQ) predeterminada y plantillas ADCS vulnerables a ESC1 es particularmente peligrosa. La MAQ permite a un usuario normal crear cuentas de equipo; ESC1 permite solicitar certificados para cualquier cuenta, incluidas las recién creadas. El resultado es una ruta de escalada de privilegios difícil de detectar si el EDR no está calibrado. El recolector BloodHound modificado eludió las firmas estáticas, lo que demuestra que la protección basada únicamente en firmas conocidas no es suficiente contra herramientas ofensivas personalizadas.

Las credenciales estáticas de AWS IAM de larga duración representan otra falla grave. Sin caducidad ni rotación, una vez robadas permanecen válidas indefinidamente. Los archivos connections.json y product-preferences.xml de la herramienta SQL Developer contienen contraseñas cifradas con algoritmos débiles o reversibles: quien los encuentre puede descifrarlos y obtener acceso directo a la base de datos.

Por qué fallan los defensores: silos, ruido y nube subestimada

La comparación entre las dos organizaciones evidencia problemas recurrentes. Herramientas de detección no calibradas conducen a amenazas no detectadas. Sin líneas base definidas y filtrado de alertas, los falsos positivos y las notificaciones de rutina sobrecargan a los defensores de red, que terminan ignorando señales reales. En la Organización A, esto permitió al atacante moverse sin ser detectado durante horas o días.

Los silos organizativos y los obstáculos burocráticos impiden una respuesta eficaz a los incidentes. La comunicación fragmentada, las responsabilidades poco claras y la autoridad limitada de los defensores obstaculizan la respuesta a incidentes incluso cuando se generan alertas. En la Organización B, aunque la respuesta inicial fue rápida, la necesidad de pasar al modelo "assume breach" indica que los procesos internos podrían haber ralentizado o complicado la reacción ante un ataque real.

Los entornos en la nube suelen ser un riesgo subestimado. Faltan controles de seguridad específicos y procesos para responder a un compromiso en la nube. Las credenciales IAM estáticas y los tokens de acceso no rotados representan un vector de ataque cada vez más explotado, pero muchas organizaciones no cuentan con procedimientos para detectar y revocar estos elementos en caso de incidente.

Recomendaciones de la CISA para reducir el riesgo

El aviso enumera cuatro acciones clave. Primero, establecer y mantener continuamente una línea base y reducir el ruido de las alertas mediante ajuste fino (fine-tuning). Segundo, derribar los silos y empoderar a los defensores de red, asignando autoridad y canales de comunicación claros. Tercero, implementar políticas de acceso condicional (Conditional Access) para identidades de carga de trabajo y monitorear permisos excesivos o no utilizados. Cuarto, establecer y revisar periódicamente procedimientos completos para detectar, remediar y revocar tokens de acceso y de actualización en caso de compromiso en la nube.

Los destinatarios incluyen agencias del Poder Ejecutivo Civil Federal (Federal Civilian Executive Branch), gobiernos estatales, locales, tribales y territoriales, e infraestructuras críticas. Los roles involucrados incluyen administradores de sistemas, respondedores de incidentes, analistas defensivos de ciberseguridad, analistas de vulnerabilidades, operadores de red y responsables de sistemas de seguridad. El mensaje es claro: las configuraciones erróneas y las credenciales estáticas son la puerta de entrada preferida por los atacantes, y un SOC que no logra filtrar el ruido ni siquiera ve los ataques exitosos.