Caminos de privilegio que nadie diseñó

Con svc-respaldo en la mano, el grafo de la enumeración muestra el camino: svc-respaldo pertenece a Gestores-Copias; Gestores-Copias tiene derecho de reescritura sobre Operadores-SRV; Operadores-SRV administra el servidor de la empresa. Cada eslabón por separado parece una concesión rutinaria; leídos en cadena, son una escalera. El error de novato es saltar al primer permiso que se ve sin comprobar a dónde lleva; el criterio es recorrer la cadena completa y confirmar que termina en algo que vale.

Antes de tocar nada, se traza el camino entero de svc-respaldo hasta el servidor, para saber que el esfuerzo de abusar del permiso de reescritura desemboca en acceso real.

El derecho de reescritura de Gestores-Copias sobre Operadores-SRV no es abstracto: significa que quien esté en Gestores-Copias puede modificar la pertenencia de Operadores-SRV, es decir, meter a quien quiera. Como svc-respaldo ya está en Gestores-Copias, el salto es añadir a svc-respaldo —o a otra cuenta controlada— dentro de Operadores-SRV, y con eso hereda la administración del servidor. Es un abuso limpio de un permiso legítimo: no explota ningún fallo de software, usa el derecho tal como está concedido.

El salto correcto no es buscar un exploit para el servidor: es usar el permiso de reescritura que ya se tiene para entrar en el grupo que administra ese servidor.

Casi siempre hay varias formas de dar un salto, y no todas cuestan lo mismo en ruido ni en riesgo. Abusar de un permiso de reescritura para ajustar la pertenencia de un grupo es reversible y silencioso; tumbar un servicio del servidor para forzar una condición es ruidoso y puede dejar a la empresa sin ese servicio. El criterio del oficio —y lo que un informe premia— es elegir el camino que logra el objetivo con el menor daño y la menor huella, no el que se ve más espectacular.

Entre abusar del permiso de grupo y provocar una caída de servicio para el mismo fin, se elige el abuso del permiso: llega igual de lejos sin romper nada ni dejar a nadie sin trabajar.

Administrar el servidor no es mandar en el dominio; son dos cosas distintas, y confundirlas hace perder tiempo. Desde el servidor se abren vías nuevas hacia el controlador —una delegación mal puesta, una plantilla de certificado, una autenticación que se puede relear—, pero cada una es su propio módulo y su propio criterio. Lo que la cadena de privilegio ha logrado es una posición fuerte: administración de una máquina que confía y a la que otros se conectan. Reconocer que ese es el trampolín, y no el destino, es lo que evita cantar victoria antes de tiempo.

El paso siguiente no es declarar el dominio comprometido, es preguntar qué vías al controlador abre tener el servidor —que es justo lo que trabajan los módulos de delegaciones, certificados y relés.