Attack path

Modela el parque como un grafo. Los nodos son usuarios, equipos, grupos, cuentas de servicio, roles, plantillas de certificado y objetos. Las aristas son las relaciones entre ellos: la pertenencia, el permiso para restablecer una contraseña, el permiso para modificar un grupo, una sesión activa en una máquina, el derecho a asumir un rol. Un attack path es un recorrido dirigido desde un nodo que controlas hasta un nodo que quieres, y encontrarlo es una consulta sobre el grafo, no un exploit.

La técnica es poco vistosa a propósito. Casi todas las aristas son una configuración legítima creada por algún motivo, y ninguna arista suelta es un hallazgo. El hallazgo es el camino, y por eso las herramientas que enumeran y grafican las relaciones del directorio cambiaron tanto las pruebas internas.

Los parques se auditan objeto a objeto y se atacan camino a camino. Una revisión de permisos que examina cada grupo por separado aprobará los cinco pasos de una ruta hasta administrador de dominio, porque cada paso, por sí solo, es defendible. La composición no es de nadie.

Las aristas que más aparecen en los caminos que dibujamos son corrientes: un grupo de soporte con permiso para restablecer contraseñas de cuentas que además pertenecen a un grupo privilegiado, una cuenta de servicio con derechos de administrador local sobre un montón de máquinas, un grupo anidado dentro de otro cuatro niveles más abajo, una plantilla de certificado que permite a un usuario corriente pedir un certificado en nombre de otro, o la sesión de un administrador abierta en un puesto de trabajo, que se convierte en credential dumping y movimiento lateral. En cloud la misma forma aparece como un rol al que se le permite asumir otro, que es un camino de ataque en cloud.

El arreglo también es estructural: corta la arista, no el nodo. Quitar una sola relación rompe muchas veces decenas de caminos a la vez, y ese es el análisis que merece la pena pagar.

Nuestros informes internos abren con el camino, dibujado como una secuencia con la evidencia de cada paso, y las vulnerabilidades sueltas aparecen debajo como sus componentes. Después identificamos el conjunto más pequeño de aristas cuya retirada rompe el mayor número de caminos, que es una priorización que una lista de hallazgos no sabe expresar. Esto es lo que un producto no te puede decir, porque sabe enumerar las aristas y no sabe recorrerlas. Esto forma parte de cómo se informa un proyecto interno como una ruta y no como una lista.