Hace unos días participé junto con un compañero en un ejercicio de Red Teaming. Yo estoy iniciandome en esta clase de ejercicios (espero obtener antes de que acabe el año el ceritificado de Red Team Operator), pero mi compañero es un experto que lleva años trabajando en esto y ha participado como ponente en muchas conferencias de ciberseguridad.
La propuesta era sencilla: el cliente nos daba las credenciales de la cuenta de microsoft de uno de sus empleados con menos privilegios, y nosotros teníamos que ver hasta donde podíamos llegar con esa información sin que nos descubrieran.
Los empleados del cliente se conectaban mediante la solución VDI de Microsoft, Azure Virtual Desktop, por lo que pudimos conectarnos mediante Remote Desktop.
Una vez conectados, lo primero era buscar la forma de escalar privilegios y convertirnos en administrador local. Después, comprobaríamos posibles fallos de configuración que pudiera tener el Active Directory de la empresa del cliente, e intentaríamos buscar la forma de llegar al Domain Admin para poder tener acceso completo a toda la red. Fue un proceso realmente divertido e interesante, pero en este post quiero centrarme en la escalada de privilegios local.
La vulnerabilidad
Tras enumerar y analizar el sistema, encontramos un programa que se estaba ejecutando en un directorio en el que teníamos acceso de escritura. Además, había dos motivos por lo que nos fijamos en este programa: estaba ejecutandose como administrador, y en modo de inicio «Automático».
Por tanto, podríamos cambiar el exe por uno malicioso que tenga un payload con una reverse shell, y la próxima vez que se reiniciase el sistema, el payload se ejecutaría y tendríamos acceso como administrador.
Primera opción: msfvenom
Cuando piensas en modificar un ejecutable para añadirle una reverse shell, lo primero que te viene a la mente es utilizar la herramienta de metasploit, msfvenom.
Esta herramienta puede ser muy útil para CTFs o entornos sin antivirus, pero en la vida real, la firma que deja msfvenom al modificar un ejecutable está más que registrada por todos los antivirus. Por tanto, no es una opción para nosotros.
Segunda opción: Code Caves
Pensando en un método más realista de poder realizar el cambiazo, me acordé del post que escribí hace un tiempo sobre las Code Caves. El ejecutable cumplía todas las condiciones: archivo de 32 bits, sin protección DEP ni ASLR.
Así que empecé a buscar una cueva de código en el ejecutable lo suficientemente grande como para poder inyectar mi payload (mira el post del link si quieres saber más sobre el proceso).
Pero me llevé una amarga sorpresa al descubrir que no había ningún espacio lo suficientemente grande como para inyectar el código de la reverse shell. Dado que el principal objetivo era no ser detectado por el antivirus, no podía añadir espacio adicional al programa manualmente (tal y como hice en el post de Code Caves I), y la opción de las Code Caves quedó totalmente descartada.
Tercera opción: Código en C
Al final lo más sencillo es lo que suele funcionar. Así que simplemente empleé el lenguaje de programación C para hacer un script que crease un archivo .exe que ejecutase dos comandos: crear un nuevo usuario, hacer a ese usuario administrador.
Lo compilé en linux con el siguiente comando:
i686-w64-mingw32-gcc -o script.exe script.c
Y… de nuevo, el antivirus de Windows lo detectó…
¿Cuál podría ser el problema? ¿Qué diferencia había entre mi programa y otro cualquiera legítimo?
La respuesta me la dio mi companero. El problema es que compilé el ejecutable con Linux. Y eso levanta algunas alarmas.
Así que me descargué Visual Studio y compilé el programa en Windows, y esta vez finalmente funcionó. Pude ejecutar el archivo, y obtuve acceso como administrador en el sistema.
Este ejercicio me ha enseñado que no hay que sobrepensar los problemas y normalmente la solución más sencilla es la buena. Espero que te haya gustado el post y mi experiencia te haya sido útil.
Lethani.