Active Directory sigue siendo, hoy, el camino más transitado hacia el control total de un dominio. No porque sea inseguro por naturaleza, sino porque años de delegaciones, permisos heredados, plantillas de certificado dejadas abiertas y cuentas de servicio olvidadas crean rutas que llevan desde cualquier usuario común hasta Domain Admin, la cuenta que tiene el control completo del dominio. Un atacante que consigue un punto de apoyo interno rara vez explota una vulnerabilidad de software: escala a través de la identidad.

El mercado ha respondido con herramientas dedicadas —PingCastle, Purple Knight y similares— que fotografían la postura de AD. Son herramientas solventes, pero viven aisladas: se ejecutan una vez, producen un informe aparte y no saben nada de la exposición externa ni de la superficie interna que el cliente ya ha mapeado en otro sitio. Para quien presta seguridad como servicio, el resultado es un silo más que gestionar.

RECON aborda el problema desde otro ángulo. El análisis de Active Directory no es un producto separado: es una capacidad adicional de la misma plataforma —y de la misma sonda— que ya ejecuta el escaneo externo e interno del cliente. Una sonda, una vista correlacionada, un único contrato.

La respuesta de RECON está pensada precisamente para superar esa conversación. No se instala ningún agente: ni en los controladores de dominio ni en los endpoints. El colector realiza una única lectura autenticada del directorio, con los solos derechos de un usuario de dominio normal, exactamente como haría una herramienta de postura: lee, nunca escribe.

La credencial de administrador, cuando hace falta, se usa una sola vez para generar una cuenta de colector dedicada de solo lectura, y luego se destruye (crypto-shredded): nunca queda en disco, en un log ni en un campo permanente. Como alternativa, la organización puede proporcionar directamente una cuenta de solo lectura, sin entregar ninguna credencial privilegiada. Todo el análisis peligroso —Tier-0, rutas de ataque, abuso de certificados, cálculo de la puntuación— sucede después, del lado del servidor, sobre los datos recogidos, sin volver a tocar el dominio en vivo. El invariante es explícito e innegociable: detectar, nunca explotar.

Para un partner esto se traduce en un dato comercial concreto: el obstáculo técnico que suele frenar la firma —"no quiero software privilegiado en mis DC"— sencillamente no aparece.

El primer nivel es un inventario de identidad: cada usuario, grupo, equipo, unidad organizativa y GPO que el directorio expone, reunidos en una lista filtrable. En una organización de tamaño medio se trata fácilmente de más de mil objetos. Lo que los hace legibles son los marcadores: los objetos privilegiados y los de Tier-0 aparecen resaltados. Tier-0 es el conjunto de las cuentas y los sistemas más potentes del dominio —los Domain Admins, los controladores de dominio y todo lo que puede controlarlos—; quien se apodera de Tier-0 se apodera de hecho de todo el dominio, y por eso es el primer perímetro a defender. Junto a los objetos aparecen las marcas de riesgo —un adminCount=1 fuera de lugar (el rastro de que una cuenta es, o fue, privilegiada), un último inicio de sesión demasiado antiguo, un grupo sensible más expuesto de lo debido.

Y todo esto se condensa en un único número: una nota de postura del dominio, de la A a la F (de 100 hacia abajo). El equipo de seguridad puede abrirla y ver los hallazgos ponderados detrás del número; la dirección puede leerla sin mediación técnica. Es la diferencia entre entregar al cliente un muro de hallazgos y entregarle una frase: esto es lo expuesto que está tu dominio, y esto es lo que hay que arreglar primero.

Un ejemplo ayuda a entender la forma del resultado. No es raro que un único elemento —una cuenta de equipo, una cuenta de servicio, un grupo mal delegado— resulte ser el punto de paso de una docena de rutas distintas, cada una con una puntuación de confianza y un esfuerzo estimado. En un caso así la consola no se limita a decir "tienes un problema": señala qué único nodo proteger para apagar el mayor número de rutas de una sola vez. Y cada hallazgo lleva consigo su propia remediación: para una ACL peligrosa sobre un objeto de controlador de dominio, por ejemplo, la instrucción precisa es eliminar los derechos Write/AllExtendedRights/AddKeyCredentialLink en manos de principals que no son Tier-0.

El mismo principio se aplica a los Certificate Services, la PKI interna, entre las vías más abusadas hacia Domain Admin: RECON lee plantillas y autoridades de certificación y clasifica las configuraciones incorrectas conocidas de la infraestructura de clave pública. "ESC" viene de Escalation: es la sigla con la que la comunidad de seguridad cataloga las técnicas de abuso de AD CS, una familia numerada de ESC1 a ESC16 en la que cada entrada describe una forma distinta en que una PKI mal configurada concede a un usuario común privilegios que no debería tener. ESC1, por ejemplo, es el caso en que una plantilla de certificado deja que quien lo solicita indique por sí mismo la identidad que se escribe en el certificado y permite su uso para la autenticación: en la práctica, cualquier usuario común puede hacerse emitir un certificado que lo hace pasar por una cuenta mucho más potente.

RECON clasifica cada una de estas entradas con una honestidad poco común —confirmado, candidato o detect-only. Un ESC1 confirmado significa que un usuario sin privilegios ya puede obtener ese certificado; un candidato permanece marcado como tal hasta que el abuso queda probado. El cliente nunca lee un "crítico" inflado que nadie ha demostrado —y esta honestidad, contraintuitivamente, es uno de los argumentos de venta más sólidos que se pueden aportar.

Para el partner no es "otra herramienta que vender": es una capacidad más sobre una infraestructura ya instalada, que abre un servicio recurrente, acorta la venta y hace el valor medible en cada escaneo.

Los siguientes pasos son concretos: un recorrido guiado del análisis sobre el propio dominio del cliente; el despliegue de la sonda en una sola red para ver en una única pasada el escaneo interno, OT/ICS y Active Directory; y la revisión de las rutas vivas hacia Domain Admin, con el chokepoint a romper señalado en primer lugar.

Más información: [email protected] · orizon.one/services/recon