Movimiento Lateral
Última actualización
Última actualización
En pocas palabras, el movimiento lateral es el grupo de técnicas utilizadas por los atacantes para moverse por una red. Una vez que un atacante ha obtenido acceso a la primera máquina de una red, moverse es esencial por muchas razones, incluidas las siguientes: - Alcanzar nuestros objetivos como atacantes - Eludir las restricciones de red vigentes - Establecer puntos de entrada adicionales a la red - Crear confusión y evitar la detección.
Si bien muchas cadenas de ciberataques hacen referencia al movimiento lateral como un paso adicional en un proceso lineal, en realidad es parte de un ciclo. Durante este ciclo, utilizamos todas las credenciales disponibles para realizar movimientos laterales, lo que nos da acceso a nuevas máquinas donde elevamos privilegios y extraemos credenciales si es posible. Con las nuevas credenciales, el ciclo comienza de nuevo.
Habitualmente repetiremos este ciclo varias veces antes de alcanzar nuestro objetivo final en la red. Si nuestro primer punto de apoyo es una máquina con muy poco acceso a otros recursos de la red, es posible que necesitemos movernos lateralmente a otros hosts que tengan más privilegios en la red.
Supongamos que estamos realizando una interacción con el equipo rojo donde nuestro objetivo final es llegar a un repositorio de código interno, donde obtuvimos nuestro primer compromiso en la red objetivo mediante el uso de una campaña de phishing. Normalmente las campañas de phishing son más efectivas contra usuarios no técnicos, por lo que nuestro primer acceso podría ser a través de una máquina del departamento de Marketing.
Las estaciones de trabajo de marketing normalmente estarán limitadas mediante políticas de firewall para acceder a cualquier servicio crítico en la red, incluidos protocolos administrativos, puertos de bases de datos, servicios de monitoreo o cualquier otro que no sea necesario para su trabajo diario, incluidos los repositorios de códigos.
Para llegar a hosts y servicios sensibles, debemos pasar a otros hosts y desde allí pasar a nuestro objetivo final. Para ello, podríamos intentar elevar los privilegios en la estación de trabajo de Marketing y extraer los hashes de contraseñas de los usuarios locales. Si encontramos un administrador local, la misma cuenta puede estar presente en otros hosts. Después de hacer un reconocimiento, encontramos una estación de trabajo con el nombre DEV-001-PC. Usamos el hash de contraseña del administrador local para acceder a DEV-001-PC y confirmar que es propiedad de uno de los desarrolladores de la empresa. Desde allí, está disponible el acceso a nuestro repositorio de códigos de destino.
Tenga en cuenta que, si bien es posible que sea necesario utilizar el movimiento lateral para eludir las restricciones del firewall, también es útil para evadir la detección. En nuestro ejemplo, incluso si la estación de trabajo de Marketing tuviera acceso directo al repositorio de código, probablemente sería conveniente conectarse a través de la PC del desarrollador. Este comportamiento sería menos sospechoso desde el punto de vista de un analista del equipo azul que verifica los registros de auditoría de inicio de sesión.
Hay varias formas en que un atacante puede moverse lateralmente. La forma más sencilla sería utilizar protocolos administrativos estándar como WinRM, RDP , VNC o SSH para conectarse a otras máquinas de la red. Este enfoque se puede utilizar para emular en cierta medida los comportamientos de los usuarios habituales, siempre y cuando se mantenga cierta coherencia al planificar dónde conectarse y qué cuenta. Si bien un usuario de TI que se conecta al servidor web a través de RDP puede ser habitual y pasar desapercibido, se debe tener cuidado de no intentar conexiones sospechosas (por ejemplo, ¿por qué el usuario administrador local se conecta al DEV-001-PC desde el departamento de marketing?). ¿PC?) .
Hoy en día, los atacantes también tienen otros métodos para moverse lateralmente, lo que hace que sea algo más difícil para el equipo azul detectar lo que está sucediendo de manera efectiva . Si bien ninguna técnica debe considerarse infalible, al menos podemos intentar permanecer lo más silenciosos posible. En las siguientes tareas, veremos algunas de las técnicas de movimiento lateral más comunes disponibles.
Mientras realizamos la mayoría de las técnicas de movimiento lateral introducidas en la sala, utilizaremos principalmente credenciales de administrador. Si bien se podría esperar que todas las cuentas de administrador sirvieran para el mismo propósito, se debe hacer una distinción entre dos tipos de administradores:
Las cuentas locales forman parte del grupo de administradores locales.
Las cuentas de dominio forman parte del grupo de administradores locales.
Las diferencias que nos interesan son las restricciones impuestas por el Control de cuentas de usuario ( UAC ) sobre los administradores locales (excepto la cuenta de administrador predeterminada). De forma predeterminada, los administradores locales no podrán conectarse de forma remota a una máquina y realizar tareas administrativas a menos que utilicen una sesión interactiva a través de RDP . Windows negará cualquier tarea administrativa solicitada a través de RPC, SMB o WinRM, ya que dichos administradores iniciarán sesión con un token de integridad medio filtrado, lo que impedirá que la cuenta realice acciones privilegiadas. La única cuenta local que obtendrá privilegios completos es la cuenta de Administrador predeterminada.
Las cuentas de dominio con privilegios de administración local no estarán sujetas al mismo tratamiento y iniciarán sesión con privilegios administrativos completos.
Esta característica de seguridad se puede desactivar si lo desea y, a veces, no encontrará diferencias entre las cuentas locales y de dominio en el grupo del administrador. Aún así, es esencial tener en cuenta que si algunas de las técnicas de movimiento lateral fallan, podría deberse al uso de un administrador local no predeterminado donde se aplica UAC . Puede leer más detalles sobre esta característica de seguridad
Puertos: 445/TCP ( SMB )
Membresías de grupo requeridas: administradores
La forma en que funciona psexec es la siguiente:
Conéctese al recurso compartido Admin$ y cargue un binario de servicio. Psexec usa psexesvc.exe como nombre.
Conéctese al administrador de control de servicios para crear y ejecutar un servicio llamado PSEXESVC y asociar el binario del servicio con C:\Windows\psexesvc.exe.
Cree algunas canalizaciones con nombre para manejar stdin/stdout/stderr.
Para ejecutar psexec, solo necesitamos proporcionar las credenciales de administrador requeridas para el host remoto y el comando que queremos ejecutar ( psexec64.exeestá disponible C:\toolsen THMJMP2 para su conveniencia):
Puertos: 5985/TCP (WinRM HTTP ) o 5986/TCP (WinRM HTTPS)
Membresías de grupo requeridas: usuarios de administración remota
La administración remota de Windows (WinRM) es un protocolo basado en web que se utiliza para enviar comandos de Powershell a hosts de Windows de forma remota. La mayoría de las instalaciones de Windows Server tendrán WinRM habilitado de forma predeterminada, lo que lo convierte en un vector de ataque atractivo.
Para conectarnos a una sesión remota de Powershell desde la línea de comando, podemos usar el siguiente comando:
Podemos lograr lo mismo desde Powershell, pero para pasar credenciales diferentes, necesitaremos crear un objeto PSCredential:
Una vez que tengamos nuestro objeto PSCredential, podemos crear una sesión interactiva usando el cmdlet Enter-PSSession:
Powershell también incluye el cmdlet Invoke-Command, que ejecuta ScriptBlocks de forma remota a través de WinRM. Las credenciales también deben pasarse a través de un objeto PSCredential:
Puertos:
135/TCP, 49152-65535/TCP (DCE/RPC)
445/TCP (RPC sobre canalizaciones con nombre SMB )
139/TCP (RPC sobre canalizaciones con nombre SMB )
Membresías de grupo requeridas: administradores
Los servicios de Windows también se pueden aprovechar para ejecutar comandos arbitrarios, ya que ejecutan un comando cuando se inician. Si bien un ejecutable de servicio es técnicamente diferente de una aplicación normal, si configuramos un servicio de Windows para ejecutar cualquier aplicación, aún así la ejecutará y luego fallará.
Podemos crear un servicio en un host remoto con sc.exe, una herramienta estándar disponible en Windows. Al usar sc, intentará conectarse al programa de servicio remoto Service Control Manager (SVCCTL) a través de RPC de varias maneras:
Se realizará un intento de conexión utilizando DCE/RPC. El cliente primero se conectará al Endpoint Mapper (EPM) en el puerto 135, que sirve como catálogo de puntos finales RPC disponibles y solicita información sobre el programa de servicio SVCCTL. Luego, el EPM responderá con la IP y el puerto para conectarse a SVCCTL, que suele ser un puerto dinámico en el rango de 49152-65535.
Si la última conexión falla, sc intentará llegar a SVCCTL a través de canalizaciones con nombre SMB , ya sea en el puerto 445 (SMB) o 139 (SMB sobre NetBIOS).
Podemos crear e iniciar un servicio llamado "THMservice" usando los siguientes comandos:
El comando "net user" se ejecutará cuando se inicie el servicio, creando un nuevo usuario local en el sistema. Dado que el sistema operativo está a cargo de iniciar el servicio, no podrá ver el resultado del comando.
Para detener y eliminar el servicio, podemos ejecutar los siguientes comandos:
Otra característica de Windows que podemos utilizar son las Tareas programadas. Puede crear y ejecutar uno de forma remota con schtasks, disponible en cualquier instalación de Windows. Para crear una tarea llamada THMtask1, podemos usar los siguientes comandos:
Configuramos el tipo de programación (/sc) en UNA VEZ, lo que significa que la tarea debe ejecutarse solo una vez en la fecha y hora especificadas. Dado que ejecutaremos la tarea manualmente, la fecha de inicio (/sd) y la hora de inicio (/st) no importarán mucho de todos modos.
Dado que el sistema ejecutará la tarea programada, la salida del comando no estará disponible para nosotros, lo que lo convierte en un ataque ciego.
Finalmente, para eliminar la tarea programada, podemos usar el siguiente comando y limpiar después de nosotros mismos:
También podemos realizar muchas de las técnicas analizadas en la tarea anterior de forma diferente utilizando el Instrumental de administración de Windows ( WMI ). WMI es la implementación de Windows de Web-Based Enterprise Management (WBEM), un estándar empresarial para acceder a información de administración a través de dispositivos.
En términos más simples, WMI permite a los administradores realizar tareas de administración estándar de las que los atacantes pueden abusar para realizar movimientos laterales de varias maneras, que discutiremos.
Antes de poder conectarnos a WMI usando comandos de Powershell, necesitamos crear un objeto PSCredential con nuestro usuario y contraseña. Este objeto se almacenará en la variable $credential y se utilizará en todas las técnicas de esta tarea:
Luego procedemos a establecer una sesión WMI utilizando cualquiera de los siguientes protocolos:
DCOM: Se utilizará RPC sobre IP para conectarse a WMI . Este protocolo utiliza el puerto 135/TCP y los puertos 49152-65535/TCP, tal como se explica al usar sc.exe.
Wsman: WinRM se utilizará para conectarse a WMI . Este protocolo utiliza los puertos 5985/TCP (WinRM HTTP ) o 5986/TCP (WinRM HTTPS).
Para establecer una sesión WMI desde Powershell, podemos usar los siguientes comandos y almacenar la sesión en la variable $Session, que usaremos en toda la sala sobre las diferentes técnicas:
El New-CimSessionOptioncmdlet se utiliza para configurar las opciones de conexión para la sesión WMI , incluido el protocolo de conexión. Luego, las opciones y credenciales se pasan alNew-CimSession cmdlet para establecer una sesión en un host remoto.
Puertos:
135/TCP, 49152-65535/TCP (DCERPC)
5985/TCP (WinRM HTTP ) o 5986/TCP (WinRM HTTPS)
Membresías de grupo requeridas: administradores
Podemos generar de forma remota un proceso desde Powershell aprovechando el Instrumental de administración de Windows ( WMI ), enviando una solicitud WMI a la clase Win32_Process para generar el proceso en la sesión que creamos antes:
Tenga en cuenta que WMI no le permitirá ver el resultado de ningún comando, pero sí creará el proceso requerido de forma silenciosa.
En sistemas heredados, se puede hacer lo mismo usando wmic desde el símbolo del sistema:
Puertos:
135/TCP, 49152-65535/TCP (DCERPC)
5985/TCP (WinRM HTTP ) o 5986/TCP (WinRM HTTPS)
Membresías de grupo requeridas: administradores
Podemos crear servicios con WMI a través de Powershell. Para crear un servicio llamado THMService2, podemos usar el siguiente comando:
Y luego, podemos controlar el servicio e iniciarlo con los siguientes comandos:
Finalmente, podemos detener y eliminar el servicio con los siguientes comandos:
Puertos:
135/TCP, 49152-65535/TCP (DCERPC)
5985/TCP (WinRM HTTP ) o 5986/TCP (WinRM HTTPS)
Membresías de grupo requeridas: administradores
Podemos crear y ejecutar tareas programadas utilizando algunos cmdlets disponibles en las instalaciones predeterminadas de Windows:
Para eliminar la tarea programada después de haber sido utilizada, podemos usar el siguiente comando:
Puertos:
135/TCP, 49152-65535/TCP (DCERPC)
5985/TCP (WinRM HTTP ) o 5986/TCP (WinRM HTTPS)
Membresías de grupo requeridas: administradores
MSI es un formato de archivo utilizado para los instaladores. Si podemos copiar un paquete MSI al sistema de destino, podemos usar WMI para intentar instalarlo por nosotros. El archivo se puede copiar de cualquier forma disponible para el atacante. Una vez que el archivo MSI esté en el sistema de destino, podemos intentar instalarlo invocando la clase Win32_Product a través de WMI :
Podemos lograr lo mismo usando wmic en sistemas heredados:
Por material de autenticación alternativo, nos referimos a cualquier dato que pueda usarse para acceder a una cuenta de Windows sin conocer realmente la contraseña del usuario. Esto es posible gracias a cómo funcionan algunos protocolos de autenticación utilizados por las redes de Windows. En esta tarea, veremos un par de alternativas disponibles para iniciar sesión como usuario cuando cualquiera de los siguientes protocolos de autenticación está disponible en la red:
Autenticación NTLM
Autenticación Kerberos
Nota: Durante esta tarea, se supone que está familiarizado con los métodos y herramientas para extraer credenciales de un host. Mimikatz se utilizará como herramienta elegida para la extracción de credenciales en toda la sala.
Antes de profundizar en las técnicas reales de movimiento lateral, echemos un vistazo a cómo funciona la autenticación NTLM :
El cliente envía una solicitud de autenticación al servidor al que desea acceder.
El servidor genera un número aleatorio y lo envía como desafío al cliente.
El cliente combina su hash de contraseña NTLM con el desafío (y otros datos conocidos) para generar una respuesta al desafío y la envía de regreso al servidor para su verificación.
El servidor envía tanto el desafío como la respuesta al controlador de dominio para su verificación.
El controlador de dominio utiliza el desafío para recalcular la respuesta y la compara con la respuesta inicial enviada por el cliente. Si ambos coinciden, el cliente queda autenticado; de lo contrario, se deniega el acceso. El resultado de la autenticación se envía de vuelta al servidor.
El servidor envía el resultado de la autenticación al cliente.
Nota: El proceso descrito se aplica cuando se utiliza una cuenta de dominio. Si se utiliza una cuenta local, el servidor puede verificar la respuesta al desafío sin necesidad de interacción con el controlador de dominio, ya que tiene el hash de contraseña almacenado localmente en su SAM.
Como resultado de extraer credenciales de un host donde hemos obtenido privilegios administrativos (mediante el uso de mimikatz o herramientas similares), es posible que obtengamos contraseñas de texto sin cifrar o hashes que se pueden descifrar fácilmente. Sin embargo, si no tenemos la suerte suficiente, terminaremos con hashes de contraseñas NTLM no descifrados .
Aunque pueda parecer que realmente no podemos usar esos hash, se puede responder al desafío NTLM enviado durante la autenticación simplemente conociendo el hash de la contraseña. Esto significa que podemos autenticarnos sin necesidad de conocer la contraseña en texto plano. En lugar de tener que descifrar hashes NTLM, si el dominio de Windows está configurado para utilizar la autenticación NTLM, podemos Pass-the-Hash (PtH) y autenticarnos correctamente.
Para extraer hashes NTLM , podemos usar mimikatz para leer el SAM local o extraer hashes directamente de la memoria LSASS.
Extracción de hashes NTLM del SAM local:
Este método sólo le permitirá obtener hashes de usuarios locales en la máquina. Los hashes de ningún usuario del dominio estarán disponibles.
THMJMP2: Powershell
Extracción de hashes NTLM de la memoria LSASS:
Este método le permitirá extraer cualquier hash NTLM para usuarios locales y cualquier usuario de dominio que haya iniciado sesión recientemente en la máquina.
THMJMP2: Powershell
Luego podemos usar los hashes extraídos para realizar un ataque PtH attack usando mimikatz para inyectar un token de acceso para el usuario víctima en un shell inverso (o cualquier otro comando que desee) de la siguiente manera:
Tenga en cuenta que solíamos token::revertrestablecer nuestros privilegios de token originales, ya que intentar pasar el hash con un token elevado no funcionará.
Esto sería el equivalente a usar runas /netonlypero con un hash en lugar de una contraseña y generará un nuevo shell inverso desde donde podemos ejecutar cualquier comando como usuario víctima.
Para recibir el shell inverso, debemos ejecutar un detector inverso en nuestro AttackBox:
Curiosamente, si ejecuta el comando whoami en este shell, aún le mostrará el usuario original que estaba usando antes de realizar PtH, pero cualquier comando que se ejecute desde aquí en realidad usará las credenciales que inyectamos usando PtH.
Pasando el hash usando Linux :
Si tiene acceso a una máquina Linux (como su AttackBox), varias herramientas tienen soporte integrado para realizar PtH utilizando diferentes protocolos. Dependiendo de los servicios que estén disponibles para usted, puede hacer lo siguiente:
Conéctese a RDP usando PtH:
Conéctese a través de psexec usando PtH:
Nota: Sólo la versión Linux de psexec admite PtH.
Conéctese a WinRM usando PtH:
Echemos un vistazo rápido a cómo funciona la autenticación Kerberos en redes Windows:
El usuario envía su nombre de usuario y una marca de tiempo cifrada mediante una clave derivada de su contraseña al Key Distribution Center (KDC) , un servicio normalmente instalado en el controlador de dominio encargado de crear tickets Kerberos en la red.
El KDC creará y devolverá un Ticket Granting Ticket ( TGT ) , que permitirá al usuario solicitar boletos para acceder a servicios específicos sin pasar sus credenciales a los servicios mismos. Junto con el TGT , se le proporciona al usuario una clave de sesión , que necesitará para generar las solicitudes siguientes.
Observe que el TGT está cifrado utilizando el hash de contraseña de la cuenta krbtgt , por lo que el usuario no puede acceder a su contenido. Es importante saber que el TGT cifrado incluye una copia de la clave de sesión como parte de su contenido, y el KDC no necesita almacenar la clave de sesión, ya que puede recuperar una copia descifrando el TGT si es necesario.
Cuando los usuarios quieran conectarse a un servicio en la red como un recurso compartido, un sitio web o una base de datos, usarán su TGT para solicitar al KDC un Ticket Granting Ticket (TGS) . Los TGS son boletos que permiten conectarse únicamente al servicio específico para el cual fueron creados. Para solicitar un TGS, el usuario enviará su nombre de usuario y una marca de tiempo encriptada usando la Clave de Sesión, junto con el TGT y un Service Principal Name (SPN), que indica el nombre del servicio y servidor al que pretendemos acceder.
Como resultado, el KDC nos enviará un TGS y una clave de sesión de servicio , que necesitaremos para autenticarnos en el servicio al que queremos acceder. El TGS se cifra mediante el Hash del propietario del servicio . El propietario del servicio es el usuario o la cuenta de máquina bajo la cual se ejecuta el servicio. El TGS contiene una copia de la Clave de sesión del servicio en su contenido cifrado para que el Propietario del servicio pueda acceder a ella descifrando el TGS.
Luego, el TGS se puede enviar al servicio deseado para autenticar y establecer una conexión. El servicio utilizará el hash de contraseña de su cuenta configurada para descifrar el TGS y validar la clave de sesión del servicio.
A veces será posible extraer tickets de Kerberos y claves de sesión de la memoria LSASS usando mimikatz. El proceso normalmente requiere que tengamos privilegios de SISTEMA en la máquina atacada y se puede realizar de la siguiente manera:
Observe que si solo tuviéramos acceso a un ticket pero no a su clave de sesión correspondiente, no podríamos usar ese ticket; por lo tanto, ambos son necesarios.
Si bien mimikatz puede extraer cualquier TGT o TGS disponible de la memoria del proceso LSASS, la mayoría de las veces nos interesarán los TGT, ya que pueden usarse para solicitar acceso a cualquier servicio al que el usuario tenga permiso. Al mismo tiempo, los TGS sólo sirven para un servicio específico. Para extraer los TGT será necesario que tengamos credenciales de administrador, y la extracción de los TGS se puede realizar con una cuenta con pocos privilegios (solo los asignados a esa cuenta).
Una vez que hayamos extraído el ticket deseado, podemos inyectar los tickets en la sesión actual con el siguiente comando:
Inyectar tickets en nuestra propia sesión no requiere privilegios de administrador. Después de esto, los tickets estarán disponibles para cualquier herramienta que utilicemos para el movimiento lateral. Para verificar si los tickets fueron inyectados correctamente, puedes usar el comando klist:
THMJMP2: Powershell
Este tipo de ataque es similar al PtH pero se aplica a redes Kerberos .
Cuando un usuario solicita un TGT , envía una marca de tiempo cifrada con una clave de cifrado derivada de su contraseña. El algoritmo utilizado para derivar esta clave puede ser DES (deshabilitado de forma predeterminada en las versiones actuales de Windows), RC4, AES128 o AES256, según la versión de Windows instalada y la configuración de Kerberos. Si tenemos alguna de esas claves, podemos pedirle al KDC un TGT sin requerir la contraseña real, de ahí el nombre Pass-the-key (PtK) .
Podemos obtener las claves de cifrado Kerberos de la memoria usando mimikatz con los siguientes comandos:
Dependiendo de las claves disponibles, podemos ejecutar los siguientes comandos en mimikatz para obtener un shell inverso mediante Pass-the-Key ( nc64ya está disponible en THMJMP2 para su comodidad):
Si tenemos el hash RC4:
Si tenemos el hash AES128:
Si tenemos el hash AES256:
Tenga en cuenta que cuando utilice RC4, la clave será igual al hash NTLM de un usuario. Esto significa que si pudiéramos extraer el hash NTLM, podemos usarlo para solicitar un TGT siempre que RC4 sea uno de los protocolos habilitados. Esta variante en particular suele conocerse como Overpass-the-Hash (OPtH) .
Para recibir el shell inverso, debemos ejecutar un detector inverso en nuestro AttackBox:
Al igual que con PtH, cualquier comando ejecutado desde este shell utilizará las credenciales inyectadas mediante mimikatz.
En determinadas circunstancias, un atacante puede aprovechar las acciones realizadas por los usuarios para obtener más acceso a las máquinas de la red. Si bien hay muchas maneras en que esto puede suceder, veremos algunas de las más comunes.
Es bastante común encontrar recursos compartidos de red que usuarios legítimos utilizan para realizar tareas del día a día cuando revisan entornos corporativos. Si por algún motivo se puede escribir en esos recursos compartidos, un atacante puede colocar archivos específicos para obligar a los usuarios a ejecutar cualquier carga útil arbitraria y obtener acceso a sus máquinas.
Un escenario común consiste en encontrar un acceso directo a un script o archivo ejecutable alojado en un recurso compartido de red.
La razón detrás de esto es que el administrador puede mantener un ejecutable en un recurso compartido de red y los usuarios pueden ejecutarlo sin copiar o instalar la aplicación en la máquina de cada usuario. Si nosotros, como atacantes, tenemos permisos de escritura sobre dichos scripts o ejecutables, podemos hacerles una puerta trasera para obligar a los usuarios a ejecutar cualquier carga útil que queramos.
Aunque el script o ejecutable está alojado en un servidor, cuando un usuario abre el acceso directo en su estación de trabajo, el ejecutable se copiará del servidor a su %temp%carpeta y se ejecutará en la estación de trabajo. Por lo tanto, cualquier carga útil se ejecutará en el contexto de la estación de trabajo del usuario final (y la cuenta de usuario que inició sesión).
Como ejemplo, si el recurso compartido es un script VBS, podemos colocar una copia de nc64.exe en el mismo recurso compartido e inyectar el siguiente código en el script compartido:
Esto copiará nc64.exe del recurso compartido al %tmp%directorio de la estación de trabajo del usuario y enviará un shell inverso al atacante cada vez que un usuario abra el script VBS compartido.
Si el archivo compartido es un binario de Windows, digamos putty.exe, puede descargarlo desde el recurso compartido y usar msfvenom para inyectarle una puerta trasera. El binario seguirá funcionando como de costumbre pero ejecutará una carga útil adicional de forma silenciosa. Para crear un putty.exe con puerta trasera, podemos usar el siguiente comando:
El puttyX.exe resultante ejecutará una carga útil de meterpreter inversa_tcp sin que el usuario se dé cuenta. Una vez que se ha generado el archivo, podemos reemplazar el ejecutable en el recurso compartido de Windows y esperar cualquier conexión usando el módulo exploit/multi/handler de Metasploit .
Cuando un administrador utiliza Escritorio remoto para conectarse a una máquina y cierra el cliente RDP en lugar de cerrar sesión, su sesión permanecerá abierta en el servidor indefinidamente. Si tiene privilegios de SISTEMA en Windows Server 2016 y versiones anteriores, puede asumir cualquier sesión RDP existente sin necesidad de contraseña.
Si tenemos acceso a nivel de administrador, podemos obtener SISTEMA mediante cualquier método de nuestra preferencia. Por ahora, usaremos psexec para hacerlo. Primero, ejecutemos cmd.exe como administrador:
Desde allí, ejecute PsExec64.exe(disponible en C:\tools\):
Para enumerar las sesiones existentes en un servidor, puede utilizar el siguiente comando:
Según el resultado del comando anterior, si actualmente estuviéramos conectados a través de RDP usando el usuario administrador, nuestro NOMBRE DE SESIÓN seríardp-tcp#6 . También podemos ver que un usuario llamado luke ha dejado una sesión abierta con id 3. El usuario ha dejado abierta cualquier sesión con estado Disco y no se está utilizando en este momento. Si bien usted también puede hacerse cargo de las sesiones activas, el usuario legítimo se verá obligado a abandonar su sesión cuando lo haga, lo que podría ser notado por él.
Para conectarnos a una sesión, usaremos tscon.exe y especificaremos el ID de sesión que asumiremos, así como nuestro NOMBRE DE SESIÓN actual. Siguiendo el ejemplo anterior, para tomar el control de la sesión de Luke si estuviéramos conectados como usuario administrador, usaríamos el siguiente comando:
En términos simples, el comando establece que la sesión gráfica 3propiedad de Luke debe estar conectada con la sesión RDPrdp-tcp#6 , propiedad del usuario administrador.
Como resultado, reanudaremos la sesión RDP de Luke y nos conectaremos a ella inmediatamente.
Nota: Windows Server 2019 no le permitirá conectarse a la sesión de otro usuario sin conocer su contraseña.
Psexec ha sido el método preferido cuando se necesita ejecutar procesos de forma remota durante años. Permite a un usuario administrador ejecutar comandos de forma remota en cualquier PC a la que tenga acceso. Psexec es una de las muchas herramientas de Sysinternals y se puede descargar .
