La agencia estadounidense CISA dio a conocer los resultados de dos evaluaciones de red team realizadas en paralelo contra organizaciones de infraestructura crítica. Lo llamativo es que, aun aplicando un enfoque descrito como similar, los dos SOCs CISA terminaron con resultados de detección muy dispares: una organización no observó el ataque, mientras la otra lo contuvo con rapidez.
En el asesoramiento publicado el 25 de agosto de 2026 (AA26-237A), CISA presentó la historia con el título “A Tale of Two SOCs”, dejando claro que el “quién” y el “cómo” importan tanto como el “qué” se despliega en defensa.
La investigación se enmarca en organizaciones de dos sectores diferentes: Organization A (Government Services and Facilities Sector) y Organization B (Water and Wastewater Systems Sector). En ambas, el equipo de ataque logró comprometer los entornos a nivel de dominio y acceder a sistemas de negocio sensibles y a recursos en la nube.
Cómo CISA estructuró las dos simulaciones
Para comparar defensas de forma controlada, CISA ejecutó las evaluaciones simultáneamente y señaló que utilizó tradecraft (técnicas y procedimientos) similares. En ambos casos, el resultado inicial fue un acceso con expansión posterior hacia capacidades más delicadas, incluidos sistemas de negocio sensibles y recursos cloud.
La diferencia apareció cuando se trató de la respuesta defensiva: mientras una organización no detectó actividad maliciosa relevante, la otra sí identificó el compromiso temprano, lo que redujo el impacto y limitó la propagación.
Organization A: acceso completo sin alertas efectivas
En la primera evaluación, CISA describió que la Organization A sufrió un acceso inicial tras descubrir una aplicación web con credenciales predeterminadas para varias cuentas internas. Ese punto de partida permitió al red team enviar correos de phishing desde una dirección interna y aterrizar en cuatro estaciones de trabajo.
Después, el equipo escaló privilegios aprovechando dos debilidades combinadas. Por un lado, abusó de un Machine Account Quota con configuración por defecto, que permitía a cualquier usuario del dominio crear cuentas de equipo. Por otro, explotó una configuración incorrecta en Active Directory Certificate Services (AD CS) mediante una plantilla mal configurada.
CISA indicó que este patrón encaja con el abuso de plantillas de certificados que ya se había asociado recientemente a un domain-takeover (en el contexto del exploit Certighost). A partir de ahí, el red team accedió a tres sistemas SBS usando credenciales en texto claro, incluyendo archivos de configuración de bases de datos ya descifrados y claves de acceso estáticas a AWS con caducidad indefinida.
El salto a la nube y el acceso a información del equipo SOC
En el componente cloud, el atacante robó un Primary Refresh Token y luego abusó de aplicaciones en Entra ID con permisos elevados. Con esas capacidades, pudo leer el correo del equipo de seguridad y comprobar si quienes defendían eran conscientes de la actividad maliciosa.
Según CISA, en Organization A no se detectó el movimiento del red team. La agencia atribuyó el problema a que las alertas se vieron ocultas por ruido operativo: se mencionan “miles” de falsos positivos provenientes de procesos normales del negocio, y en muchos casos con severidad incluso mayor.
Además, CISA explicó que la organización contaba con múltiples SOCs y herramientas endpoint, pero sin visibilidad compartida entre ellas. En la práctica, esto puede crear silos donde cada equipo ve “su parte”, pero nadie integra la señal suficiente para confirmar un incidente.
Procedimientos y autoridad: otro cuello de botella
La falta de detección no se limitó a herramientas. CISA también señaló carencias en los procedimientos de escalado y en la autoridad para actuar. Incluso cuando hubo señales potencialmente relevantes, se descartaron como falsos positivos por no poder identificar el propietario del sistema.
Como ejemplo, CISA mencionó que una alerta vinculada a actividad del red team en un servidor de System Center Configuration Manager (SCCM) fue desestimada después de que el equipo defensor no lograra determinar quién era el responsable del sistema.
Debilidades clave que habilitaron el compromiso en A
CISA enumeró los factores principales que facilitaron que el ataque avanzara. Entre ellos, destacan:
- Machine Account Quota configurado por defecto, permitiendo que cualquier usuario del dominio agregue cuentas de equipos.
- Plantillas AD CS mal configuradas, que permitían solicitudes de certificados para cualquier usuario (en el marco de la clase de abuso descrita como ESC1).
- Credenciales en texto claro para cuentas de servicio y base de datos almacenadas en sistemas accesibles.
- Claves cloud estáticas que no caducaban, sin revocación de tokens.
- Aplicaciones con permisos excesivos en Entra ID, capaces de leer correos de usuarios a gran escala.
Organization B: contención rápida y canal C2 bloqueado
La segunda evaluación, centrada en Organization B, siguió una idea de ataque “del mismo estilo”. Sin embargo, su SOC sí detectó el payload inicial de phishing en cuanto se ejecutó.
Según CISA, el equipo defensor logró aislar las estaciones de trabajo afectadas en un rango de 2 a 20 minutos. Ese corte temprano tuvo un efecto inmediato: interrumpió las comunicaciones de command-and-control (C2) antes de que la intrusión pudiera expandirse.
Con el punto de apoyo neutralizado, CISA explicó que sus trusted agents ejecutaron un payload de red team en un host designado no privilegiado para simular el acceso que, de otro modo, el ataque habría obtenido tras evolucionar. En otras palabras, la prueba pasó a un modelo de assume-breach, donde se intenta recrear el estado posterior sin depender de la misma escalada inicial.
Problemas subyacentes presentes, pero con menos superficie
A partir de esa nueva fase, el equipo de ataque encontró los mismos problemas de base en Organization B. Se destacó, por ejemplo, la presencia de credenciales en texto claro para una cuenta de servicio de dominio dentro de un archivo de configuración relacionado con SCCM, con derechos sobre un controlador de dominio.
Con esa capacidad, el red team ejecutó una técnica de tipo DCSync para obtener el secreto asociado a krbtgt. Además, alcanzó un bastion host en la zona OT demilitarized zone, aunque el host bloqueó el acceso saliente a internet, lo que impidió establecer un canal C2. Por ello, el equipo no entró en los sistemas OT.
La brecha entre resultados: gente y procesos, no solo tecnología
En el cierre del asesoramiento, CISA atribuyó la diferencia entre ambos desenlaces a las personas y los procesos que operan las herramientas. La agencia lo resumió de forma directa: las herramientas de detección solo son tan efectivas como el personal, los procedimientos y la forma de operación que las soportan.
Este punto conecta varios elementos que aparecieron en la historia: en Organization A, el exceso de falsos positivos, la falta de visibilidad entre equipos y la limitación de escalado redujeron la probabilidad de que un incidente real se confirmara y se contuviera. En Organization B, en cambio, el SOC identificó la actividad con suficiente rapidez como para aislar equipos antes de que el ataque consolidara su control.
Qué pueden aprender los SOCs de esta “doble historia”
Más allá del caso puntual, el mensaje para equipos de seguridad es práctico. Si el objetivo es mejorar la resiliencia ante ataques similares, conviene revisar:
- Si la detección está asfixiada por falsos positivos que impiden priorizar señales reales.
- Si existen silos entre SOCs o herramientas sin mecanismos claros para compartir contexto.
- Si hay rutas de escalado definidas y autoridad para actuar cuando una alerta es plausible.
- Si la respuesta contempla el aislamiento temprano de estaciones de trabajo para cortar C2 y frenar la propagación.
Asimismo, CISA deja claro que la contención temprana no elimina la necesidad de corregir configuraciones débiles: en ambos escenarios aparecieron fallas como credenciales en texto claro, errores en AD CS, y permisos excesivos. La diferencia estuvo en cuánto daño se permitió que ocurriera antes de intervenir.
Conclusión
Los dos SOCs CISA presentados en el asesoramiento AA26-237A muestran una lección central: incluso con técnicas de ataque descritas como similares, el resultado defensivo puede cambiar drásticamente cuando intervienen factores operativos. Organization A no detectó el ataque debido al ruido y a la falta de coordinación efectiva, mientras Organization B ganó tiempo y redujo el impacto aislando rápidamente los equipos afectados y bloqueando el canal de mando y control.
Si buscas fortalecer tu programa de detección y respuesta, esta comparación invita a mirar más allá de “tener herramientas”: la clave está en cómo se operan, cómo se priorizan las alertas y cómo se toman decisiones bajo presión.
Fuente: https://thehackernews.com/2026/08/cisa-red-team-compromised-two-critical.html
