BloodHound y la ruta de ataque por identidad: de una cuenta de soporte a administrador de dominio

Una lista de cuentas con privilegios de más no resulta muy persuasiva. Un diagrama que muestra que el grupo de soporte puede restablecer la contraseña de una cuenta de servicio, que pertenece a un grupo con administrador local en un servidor donde hay cacheada la sesión de un administrador de dominio, es extremadamente persuasivo. Y es la misma información.

Eso es lo que hace BloodHound: recoge la configuración de identidad, la carga en una base de datos de grafos y responde a la pregunta que importa, cuál es la ruta más corta entre lo que un atacante probablemente tiene y lo que quiere.

Por qué el grafo gana a la lista

Los permisos de directorio se componen. Cada concesión individual le parece razonable a quien la hizo. Que soporte restablezca contraseñas es su trabajo. Que la cuenta de servicio esté en ese grupo es como funciona la aplicación. Que el administrador iniciara sesión en ese servidor fue algo puntual durante un incidente de marzo.

Ninguna revisión individual caza la combinación, porque cada concesión la revisa una persona distinta en un momento distinto. El grafo sí la caza, porque el grafo es la composición.

El resultado de una recogida no es "estas 40 cuentas tienen demasiados derechos". Es "hay 11 rutas desde el grupo de usuarios estándar hasta el nivel 0, y cortando estas 3 aristas desaparecen todas". Esa segunda frase cabe en una diapositiva de comité y produce acción.

Recogida, con cuidado

SharpHound (para Active Directory) y AzureHound (para Entra ID) leen objetos del directorio, pertenencias a grupos, ACL, enlaces de GPO, relaciones de confianza, plantillas de certificado y —la parte sensible— información de sesión de las máquinas miembro.

Dos cosas que acordar por adelantado con el cliente:

La recogida de sesiones es intrusiva. Enumerar los usuarios conectados en todos los puestos genera tráfico de red que se parece exactamente a un atacante enumerando usuarios conectados, porque es la misma técnica. Cuenta con alertas del EDR. Avisa al SOC antes de empezar, o te llevarás por delante una tarde de respuesta a incidentes de alguien. Aunque si no alertan, eso ya es un hallazgo que reportar.

Los datos recogidos son sensibles. La salida describe, en formato legible por máquina, todas las rutas para comprometer el dominio. Es el fichero más útil que un atacante podría robarte del trabajo. Cífralo, mantenlo fuera de unidades compartidas y bórralo al final con el acuerdo del cliente por escrito.

Ejecuta la recogida con una cuenta de usuario normal, no de administrador. La gracia es ver lo que ve un atacante con credenciales corrientes.

Leer las rutas

Las consultas integradas son el punto de partida: rutas más cortas a administradores de dominio, rutas desde usuarios susceptibles de Kerberoasting, principales con derechos de DCSync. Pero la consulta que merece la pena escribir es específica del cliente: marca las cuentas realmente expuestas —las de la población susceptible de phishing, las de máquinas con acceso a internet— y calcula rutas desde ahí. Un atacante empieza en un usuario phisheado, no en un nodo cualquiera.

Mira en especial:

• ForceChangePassword y GenericAll sobre usuarios. Restableces la contraseña, entras como ellos, sigues. Estas aristas suelen estar delegadas a un equipo de soporte y olvidadas.
• Plantillas de certificado. Las malas configuraciones de ADCS (la familia ESC1 a ESC8) dan con frecuencia una ruta directa de cualquier usuario autenticado a administrador de dominio, y no se ven en ningún informe de pertenencia a grupos.
• Anidamiento de grupos. Un grupo que pertenece a un grupo que pertenece a Domain Admins, tres niveles abajo, añadido para un proyecto en 2019.
• Sesiones en servidores compartidos. Cuentas de nivel 0 iniciando sesión en máquinas de nivel 1 es la arista que hace funcionar la mayoría de rutas.

En Entra ID, el mismo problema con otra ropa

AzureHound mapea asignaciones de rol, registros de aplicación, principales de servicio y concesiones de consentimiento. Los hallazgos equivalentes:

• Una aplicación con RoleManagement.ReadWrite.Directory o AppRoleAssignment.ReadWrite.All, que es administrador global con otro nombre.
• Propietarios de un principal de servicio, que pueden añadirle credenciales y convertirse en él.
• Grupos asignables a roles, con una pertenencia que nadie ha revisado desde que se creó el grupo para un canal de Teams.
• Cuentas híbridas que unen el entorno local y el cloud, lo que a menudo significa que un compromiso local es un compromiso cloud.

El grafo hace obvio el caso híbrido de una forma que dos revisiones separadas nunca lograrán.

Corta aristas, no arregles cuentas

El entregable que cambia algo es una lista corta de aristas, ordenada por en cuántas rutas aparecen. Quitar una arista bien elegida elimina a menudo decenas de rutas, y es un único cambio que un equipo puede hacer un martes.

Después vuelve a recoger y enseña el grafo otra vez. La imagen de antes y después es el artefacto de seguridad más eficaz que producimos, porque es el único donde la mejora se ve en lugar de afirmarse.

Hazlo de forma periódica, no una vez. Los directorios acumulan aristas continuamente, y un grafo que estaba limpio en marzo no lo está en septiembre. Una recogida trimestral con un diff contra la anterior convierte la higiene de identidad en algo medible, que es además, de paso, cómo evidencias la revisión de accesos que pide ISO 27001.