Pase el hash para identificarlo como usuario de dominio en lugar de quedarse atascado como NT Authority \ System

0

Recientemente, descubrí que pasar los creds de administrador local y administrador de dominio a una máquina remota con Windows 7 produce el mismo resultado: obtengo acceso a esa máquina como NT Authority \ System. La única forma que encontré para recuperar los derechos de administración de dominio en la máquina remota es mediante la suplantación de tokens. ¿Seguramente hay una forma más fácil de identificarse como administrador de dominio después de pasar los creds? Usé el módulo psexec de metasploit y lo conecté a través de Admin $ share. También proporcioné el nombre de dominio y los credenciales de administrador del dominio, pero después de ejecutar "getuid" en meterpreter todavía estaba identificado como autoridad / sistema local nt.

    
pregunta Sergtal 14.09.2016 - 21:41
fuente

2 respuestas

1

La razón por la que esto te está sucediendo es por la forma en que funciona psexec. Psexec usa sus credenciales para crear un servicio en la máquina remota usando el administrador de control de servicios de dcerpc. Los servicios por defecto usarán el principal del sistema como su token de proceso. Ahora, al respecto, cómo puedo recuperar mis derechos de administrador, asumiendo que no tiene un hash, tgt o contraseña, no puede. ¿Por qué?

Las credenciales no se transfieren por diseño, solo se pasa un hash de respuesta de desafío (ntlm) de un tgs entre hosts, lo que significa que incluso si el host acepta sus credenciales, no podrá usarlas desde ese host a otros anfitriones. Si solo necesita acceso local con el usuario administrador, puede usar wmi como su método de ejecución remota (pero incluso eso es un inicio de sesión en la red que no permite el envío de credenciales a otros hosts)

    
respondido por el Jonathan Allon 07.06.2017 - 08:36
fuente
0

No creo que uno esté "identificado" por NT AUTHORITY \ SYSTEM. NT AUTHORITY y SYSTEM no son cuentas ni grupos. Las cuentas de usuario contribuyen con su SID como el SID principal al token de acceso, pero el token de acceso puede contener otros SID, la mayoría de las utilidades / herramientas reflejan el SID principal en las salidas y así, pero cuando se requiere un permiso, Windows buscará cualquier SID que tenga el permiso asociado a ese token.

El SID solo define un conjunto de permisos, no necesita definir usuarios o grupos. NT AUTHORITY \ SYSTEM se puede agregar a las cuentas para convertirse en el SID principal de esas cuentas, y se mostrará en el administrador de tareas como SISTEMA para las tareas que lo tienen como su SID principal. pero un usuario no lo es.

    
respondido por el Nalaurien 06.06.2017 - 21:12
fuente

Lea otras preguntas en las etiquetas