El usuario analyst ya dispone de una shell en lab-linux, y CORP.LOCAL\svcuser ya inicia sesión en LAB-WIN01. Ninguno de estos puntos de acceso inicial implica privilegios administrativos. La cuestión a evaluar es si un error de configuración local permite a cualquiera de las cuentas superar el límite de privilegios local para alcanzar root o SYSTEM, y si es posible demostrar dicho riesgo sin ejecutar un exploit. Un comando permitido en sudoers, una ruta de servicio con permisos de escritura o una credencial almacenada pueden constituir evidencia suficiente cuando coinciden la cuenta, la configuración y los requisitos previos necesarios.
Todo el trabajo de este curso se realiza dentro de los entornos de laboratorio fijos y sin conexión (offline) basados en Ubuntu 22.04 y Windows Server 2022, los cuales son de nuestra propiedad o para cuya evaluación contamos con autorización explícita. El método genera hallazgos fundamentados y defendibles, no payloads, cadenas de explotación ni pasos de evasión. En Ubuntu, una solicitud de sudo y su resultado pueden dejar evidencia de autorización en /var/log/auth.log y en el registro del sistema (journal), mientras que la actividad de privilegios en Windows debe vincularse al registro de seguridad (Security log) correspondiente o a evidencias relacionadas con el servicio.
El laboratorio fijo permite visualizar el límite de privilegios y las ubicaciones donde se almacena la evidencia asociada:
Este diagrama muestra por qué la enumeración comienza en el host. La configuración relevante y la evidencia de su uso suelen encontrarse en lados opuestos de un mismo límite de privilegios; por tanto, para confirmar un hallazgo se requieren ambos elementos, no solo una configuración sospechosa aislada.
Dado que la existencia de un límite visible no implica necesariamente una ruta que lo atraviese, cada fase de enumeración genera cuatro resultados interconectados. Una lista de hipótesis es un conjunto jerarquizado de posibles clases de vectores de ataque, como comandos de Linux delegados, tareas programadas, configuraciones débiles de servicios de Windows o credenciales expuestas a cuentas no administrativas. Una hipótesis no constituye un hallazgo por sí misma; solo se convierte en tal cuando la configuración del host cumple con los requisitos previos del vector.
Por ejemplo, el hecho de que un usuario analyst vea un ejecutable con permisos elevados no demuestra que exista una escalada de privilegios. Es necesario determinar quién es el propietario del archivo, si el usuario analyst puede influir en él, qué componente con privilegios lo ejecuta y si el contexto de ejecución alcanza realmente al usuario root. En Windows, el equivalente no consiste simplemente en detectar un servicio; se requiere conocer la cuenta de servicio, la ruta del binario, el control de acceso y los permisos asignados a CORP.LOCAL\svcuser.
Esa misma evidencia permite responder a las dudas de un defensor. En Ubuntu, la actividad de sudo (tanto aceptada como rechazada) permite identificar la cuenta que invoca el comando, el usuario de destino, el directorio de trabajo y el comando en sí; por su parte, los archivos de política como /etc/sudoers y /etc/sudoers.d/ explican la razón por la que se permitió la acción. Un defensor puede comparar dichos registros con la regla de delegación prevista y generar alertas ante comandos privilegiados inusuales o cambios inesperados en los archivos de política.
Los resultados de la evaluación permiten distinguir entre una ruta plausible y una condición de escalada de privilegios que debe ser reportada: