Análisis de malware hacía Remcos RAT

En el post anterior hablaba acerca del uso, ventajas, potencial y un breve análisis de un RAT hecho en Python, siendo este Pupy. En aquel post se demostraron muchas de las funciones más útiles de ese RAT, desde simples capturas de pantalla, el uso de lazagne para la obtención de passwords, hasta inyección de código en archivos .DLL para conseguir elevación de privilegios sobre el equipo cliente.

Ahora este tratará sobre Remcos RAT, este estando hecho en C++, pero por hoy haremos a un lado las demostraciones sobre el uso de esta herramienta de administración remota y analizaremos más a detalle como es que este troyano funciona, esto mediante el uso de diferentes herramientas para inspeccionar esta muestra de malware, entre lo que podemos encontrar a lo largo de un análisis hacia una muestra de malware determinada, está el host y puerto hacia el que conecta, el protocolo y transporte que utiliza (TCP/SSL), las rutinas/subrutinas de operaciones que lleva a cabo, identificación del uso API´s sospechosas, identificar niveles de entropía, «Packers o Compressers», etc.

¿Que se utilizará para esta demostración?

  • Software de Virtualización (Vmware Workstation)
  • Máquina virtual Windows.
  • Máquina virtual de REMnux (version 6.0 en este caso)
  • Configurar el adaptador de Red en modo NAT para ambas.

Algo que me gusta inspeccionar son los Troyanos, aquellos muy perjudiciales y peligrosos, ese tipo de malware que le/nos permite tomar control remoto de equipo infectado con el, y hacer mucho con ellos. Esta demostración tratará de Remcos RAT (Más adelante hablaré sobre otros RAT’s). Para esta ocasión utilicé la versión gratuita de Remcos, puedes descargarla en el siguiente enlace:

https://www.rekings.com/shop/remcos-rat/

Algo  que si agregaré sobre el uso del RAT es la forma en la qué se configuró el troyano, pues servirá de apoyo para entender mejor la información que obtendremos más adelante.  Luego de haber descargado iniciado la versión gratuita de Remcos, utilicé la siguiente configuración:

  • 127.0.0.1 (localhost) se configuró así por que el troyano iba a ser ejecutado sobre la misma máquina, así como el puerto TCP 6525 sería a donde se establecería la conexión, es importante hacer clic en «Add» para establecer la configuración.

Hecho lo anterior, pasamos a la pestaña «Installation» para solo hacer un «check» en la única opción disponible, al hacerlo se habilitarán las opciones por default, sin embargo no podemos hacer uso de las demas puesto a que solo están disponibles en la versión PRO. En la configuración podemos ver que se esta especificando que el troyano residirá en el famoso directorio «Appdata«.

En la parte «Stealth» no cambiaremos nada, lo dejaremos tal cual. Las funciones de esta pestaña sirven para hacer que nuestro troyano opere de forma furtiva, disponible en versión PRO nada más.

Las pestañas «Keylogger y Surveillance» las omitiremos debido a que no haremos cambios en esa configuración ya establecida, por lo qué pasaremos a «Build«, lo único que cambiaremos será el empaquetamiento a MPRESS.

¿Porqué MPRESS?

Es un packer que hace a las librerías y programas más pequeños, funciona para ejecutables  de tipo PE32, de .NET y PE32+, además de que reduce el tiempo de ejecución de los binarios, incluyendo si se corren desde un dispositivo de almacenamiento extraíble, además de que protege los binarios de técnicas anti-debugging, por herramientas no convencionales.

Hecho esto solo hacemos clic en «Build«, al hacerlo, a un costado aparecerá el log de este proceso:

Ahora solo falta guardar el troyano y ejecutarlo.

¿Porqué hay que ejecutarlo?

En el post anterior había mencionado las 2 metodologías para el estudio/análisis de malware; el análisis estático y el análisis dinámico. El primero tiene lugar cuando se lleva a cabo un proceso de reversing hacía una muestra en específico, este tiene el objetivo de examinar el código de cierta pieza de malware. El segundo ocurre cuando una muestra de malware se pone en función en un ambiente monitoreado, controlado y aislado de la red funcional, para evitar la infección, en donde se observa el comportamiento que este software tiene en el equipo, a este análisis también se le conoce como «Behavioral Analysis».
Por ello, vamos estudiar el «comportamiento» que tiene este software una vez que llega a ser ejecutado, al hacerlo, notaremos en el panel de Remcos que se agregó un nuevo cliente, en donde vemos también detalles del host:

Viendo lo anterior entonces ya es un hecho que se estableció una conexión y el malware hizo su trabajo, ahora, vamos a recurrir a 2 herramientas.

  • Windows Process Monitor
  • Windows Process Explorer

La primera es una herramienta de monitoreo de eventos en Windows, que muestra en tiempo real todo lo que ocurre en dicho sistema operativo, como lo es la actividad en el registro (Registry), actividad detallada de los procesos, puesto a que 2 utilidades del Sysinternals (Filemon y Regmon) qué trabajan en conjunto con el software consiguen una compresión mayor de los eventos en el S.O y sus propiedades, por lo que nos servirá como una herramienta útil en la caza del malware, al iniciarse se mostrará una ventana así, en donde se muestra la siguiente configuración por default:

El malware, buscaremos su proceso en el “Process Monitor”, por ello, habrá que hacer unos cambios en ella, solamente en lugar de hacer el “Fetching” de los eventos por su arquitectura como se hace por default, seleccionémoslo por el nombre de los procesos (Process name), puesto a que ya hubo una previa ejecución del malware, este tendrá un proceso corriendo (Aunque existe malware que lo oculta, como la versión PRO de Remcos), para esto existen otras técnicas. Luego de seleccionar la condición de búsqueda por procesos, en el siguiente campo, se enumeran los procesos activos en tiempo real en el S.O, dentro seleccionaremos el del troyano «remcos.exe», ya seleccionado hacemos clic en “Add” para que el proceso se añada a la tabla del filtro monitoreo, por ultimo hacemos clic en “Apply” y “Ok” para aplicar la configuración.

Al hacerlo, se mostrará el panel de monitoreo con la configuración establecida, el cual consiste de múltiples tablas, las cuales describen detalles acerca del evento, como lo es la hora, nombre del proceso, ID del proceso (PID), Operación realizada, dirección (Path), etc. En la imagen de abajo notaremos que se llevaron a cabo operaciones de modificación y escritura en el disco duro, en la partición C, siendo estas «CreateFile, WireteFile y RegSetValue«. Las 3 primeras acciones consisten en crear un directorio nombrado «/remcos/» y un file con el mismo nombre pero con extensión. En el cuarto evento vemos que la operación «RegSetValue» toma acción con la función «Run» sobre remcos, esta es utilizada como método de persistencia, también vemos que hace uso de «CreateFile» y «WriteFile» para crear el archivo llamado install.bat en el directorio «/Temp/«.

Lo que hace este archivo .bat consiste básicamente en hacer un PING al Sistema que lo ejecutó para poder comprobar conexión, en el caso de que se responda, ejecuta «remcos.exe» desde el directorio «/Appdata/» para despues removerse así mismo.  la creación de archivos .bat es utilizada comúnmente por el malware para establecer cierta automatización de procesos, como parte de la adición de persistencia. (La info de la imagen siguiente fue obtenida mediante el submit a una plataforma online de análisis»:

Si exploramos más abajo en el resumen de eventos por ProcMon, nos encontraremos con una rutina de conexión, la cual se repite cada cierto tiempo, lo que hace esta rutina simplemente consiste en comenzar un proceso en donde se ve involucrado un «thread» (hilo) que sostiene la conexión TCP, por eso vemos ahí a las operaciones «TCP Recieve», «Thread Create», «TCP Send» y «Thread Exit», en la columna «Path» vemos que hay una conexión en donde se indica el nombre del Host, y el puerto que este host tiene abierto para esta conexión, seguido del otro puerto (6525) en el otro host, en este caso es el mismo por que el RAT se configuró para que operara así, al final en la columna «Result» vemos el banner «SUCCESS» de que el evento esta siendo llevado a cabo con éxito (La conexión existe y es estable):

Ya sabemos que es lo que ha ocurrido en cuanto a creación/modificación de archivos en el sistema, así como tambien los eventos relacionados al networking en el equipo infectado, desde como se origina, hasta el como se mantiene en función. Pasemos a utilizar Process Explorer, esta herramienta es un software de gestión de procesos y eventos, está unos niveles arriba del Task Manager, no será de utilidad ya que nos proporciona gran variedad de atributos e información más a detalle de los procesos que toman lugar en el Sistema. este software puede conseguirse gratuitamente desde el sitio web de Microsoft. Al abrir Process Explorer veremos los procesos que existen en el S.O, ahí es donde encontraremos a «remcos.exe«, con otro PID, esto es parte de la funcionalidad de la persistencia y migraciones, veamos las propiedades de este:

Al hacerlo, se abrirá una ventana con varias pestañas para que exploremos los detalles de este proceso, vemos que en la pestaña «TCP/IP» podemos ver información acerca de una conexión por este protocolo, en donde hay 2 direcciones, una remota y otra local, cada una con sus respectivos puertos funcionales en donde está operando esta conectividad, podrás notar que en el equipo cambio el puerto, esto es gracias a las funcionalidades de persistencia y migración, ambas direcciones son las mismas, ya que el troyano fue configurado de esa forma.

Si pasamos a la pestaña «Environment«, podremos ver las variables de las que hace uso el malware, así como su valor de éstas, entre las más distinguidas está «APPDATA» que contiene como valor el directorio donde reside «remcos.exe», «LOCALAPPDATA» Y «LOGONSERVER» que se refieren al directorio en AppData y al servidor donde loggearse, en éste caso, «OSCAR-PC»:

Hasta este punto hemos visto parte de los resultados del «Behavioral Analysis» desde el propio equipo, en donde vimos los eventos que se han involucrado desde la ejecución del Troyano en el Equipo, y detalles acerca de estos (Operaciones, archivos, modificaciones, conexiones, puertos, hosts, protocolos, Variables de entorno, etc).  

Ahora pasemos a hacerlo de una forma más… artesanal digamos. Aquí es en donde entra el análisis estático, a diferencia del análisis dinámico, este toma lugar cuando se examina o inspecciona el malware sin tener que correrlo o ejecutar la muestra, también conocido en inglés como «Code Analysis» es la metodología utilizada para estudiar el código de cierta muestra de malware y entender que es lo que hace.

Para esto usaremos la distro de REMnux. Para los que no saben qué es, REMnux es una distribución de Linux que está diseñada exclusivamente para llevar a cabo tareas de reversing y análisis de malware, previamente había comentado sobre ella, es todo un «Toolkit» bastante eficiente que sirve de apoyo para analistas de malware, investigadores forenses e incluso crackers, una característica bastante funcional que tiene es que todas las ejecuciones que ocurren en REMnux, se mantienen sobre un entorno de Sandboxing, lo cual hace que el laboratorio de análisis sea aun más seguro y confiable.

El despliegue de herramientas es bastante rápido en REMnux, solo es cuestión de invocarlos y usar la sintaxis correcta para ello, lo que haremos ahora será inspeccionar el binario o muestra de malware con la ayuda de algunas herramientas ya incluidas en la distro.

Utilizaremos para la primera aproximación a «Pescan«, esta es una herramienta que hace un rápido análisis estático hacia archivos PE, en este caso el troyano. La sintaxis es muy simple: pescan [Archivo PE]. Al ejecutar el comando, se mostró la información siguiente; en donde podemos ver que el nivel de entropía es alto, lo que apunta a que posiblemente el binario haya pasado por un Compresser o Packer, también podemos ver que el stub del DOS  parece ser sospechoso, esto se debe a que la cabecera DOS contiene anomalías en el código, por último vemos que el banner «MPRESS1» tiene etiquetas de nombre sospechoso:

Está inspección fue más que breve, pasemos a hacerlo de una forma algo más extensa, entre las herramientas que hay en REMnux, nos encontramos con «ExeScan«, estando escrita en Python, ExeScan nos permite analizar de forma estática archivos PE y encontrar anomalías y características sospechosas. Al igual que «Pescan» la sintaxis de ExeScan es muy simple: exescan.py [-opciones] [Archivo PE]. En este caso se uso el parámetro «-a» que significa «Advanced Scan«. Al ejecutarlo se obtuvo la siguiente información:

  • Hashes: De tipo MD, SHA- 1 y SHA-256, en cuanto a malware, estos son proporcionados para que sirvan de identificadores hacía muestras únicas a las que se realiza inspección alguna.
  • Tipo de archivo: Ejecutable.
  • Compilador o Packer: No identificado (por ahora).
  • Dirección del punto de entrada: 0x0001127e
  • Secciones: Este apartado se refiere a las secciones con niveles anormales o elevados de entropía, en donde vemos el texto «MPRESS» apuntado hacia una dirección virtual, teniendo un valor de entropía de 7.987 lo que nos  indica que el PE posiblemente haya tenido un proceso de «Packing«, como lo comentamos.
  • Anomalies Check: Aquí es en donde se afirma que basándose en los resultados anteriores con respecto a la entropía es posible que el archivo venga «empaquetado». Consulta la imagen

Mas abajo en los resultados encontré información relevante a indicios sospechosos y anomalías encontradas en el binario, como lo son API’s utilizadas por el troyano, estás API’s son categorizadas como sospechosas debido a que comúnmente son utilizadas por otras variantes de malware. En la sección «Import Table» nos encontramos con 3 «Internet Addresses«. Haciendo uso de 3 API’s en especifico:

  • GetProcAddress: Ésta es comúnmente utilizada por variantes de malware para poder enmascarar o cunrir ciertas funciones comprometedoras, como la obtención/migración de procesos.
  • RegCloseKey: Esta API trabaja con el registro de Windows, hay variantes de malware que recurren a ella para poder hacer modificaciones en el «Registry«
  • send: Es utilizada para transferir información, requiere también la API «recv«

Después tenemos otra sección nombrada «Entire Executable» a:

  • GetModuleHandle: Esta API es usada normalmente para que buscar un buen lugar para llevar a cabo la inyección de código arbitrario, o para poder encontrar algún módulo y modificarlo.
  • GetProcAddress: Tiene la misma finalidad que la descripción anterior
  • InternetOpen: Esta es utilizada para abrir sesiones HTTP o HTTPS.
  • RegCloseKey: Tiene la misma finalidad antes descrita.
  • URLDownloadFile: El malware hace uso de ella para poder descargar archivos de Internet o de algún hosts, comúnmente para infestar con más malware el equipo.

Nota: Como herramienta extra también podemos utilizar a «peframe» para hacer análisis estático a archivos .EXE
Su sintaxis es la siguiente: peframe [–opciones] [Archivo PE], en este caso se especificó que los resultados se arrojaran en formato JSON. En donde se pudo ver información similar ala que obtuvimos antes, como lo son los 3 Tipos de HASHES, el número de secciones de entropía anormal encontrada, etc:

Hasta este punto ya sabemos cuales son las API’s maliciosas de las que esta muestra de malware dispone y que trabajo hacen para el. Entre las diferentes herramientas que hay para examinar malware de forma estática está «pedump«, esta al igual que las otras permiten inspeccionar archivos PE de forma estática, siendo tan eficaz como «ExeScan«, nos arroja resultados de una forma igual de «legible«, pero sin embargo resulta más eficaz para determinar qué software de empaquetamiento fue usado en algún archivo PE.

Hemos visto detalles sobre el «Packing» del binario, sin embargo las herramientas que hemos usado hasta ahora no han definido cual fue el software o Compresser qué se utilizó. Pedump viene incluido en REMnux también, su sintaxis es igual a las demás: pedump [Archivo PE]. 

Entre la información más destacada que nos arrojó se encuentra la tabla IMPORTS. La columna MODULE_NAME contiene los módulos que son el lugar nativo de las API´s o funciones, también vemos que nos encontramos a varías de las que habíamos visto antes en las otras inspecciones estáticas con «ExeScan» y  «Pedump«. Al final vemos al Packer que fue utilizado para la compresión del Binario, , aquí podemos ver que efectivamente se trata de MPRESS, version 2.12

Hasta ahora, hemos dado una inspección más a fondo que en el post anterior en cuando a ambas metodologías de análisis, hemos visto el comportamiento que toma este software al momento de ser ejecutado sobre algún equipo Windows, viendo las modificaciones que hace, hacia donde conecta, como lo hace, que esta involucrado en esa acción, que es lo que crea/destruye/sobrescribe, donde se aloja, etc.

En al análisis estático inspeccionamos el Binario mediante el apoyo de ciertas herramientas que nos muestran un volcado de información relevante a anomalías e indicios sospechosos encontrados en la inspección a lo largo del código, a lo que nos llevó a encontrar API´s maliciosas utilizadas por el malware analizado, ¿cuales son?, ¿para que sirven? y como es que también pueden encontrarse en otras variantes de malware, así como también vimos los Hashes únicos proporcionados para esa muestra de malware, sean MD5, SHa-1 o SHA-256.

Algo que resulta crítico es la determinar si existen niveles anormales o muy altos de entropía en el binario, ya que esta puede funcionar como indicador para saber si el binario o el archivo PE pasó por proceso de protección o «Packing», el cual hicimos al momento de configurar el troyano, así como también lo encontramos al momento de analizar de forma estática este archivo PE con una de las herramientas ya incluidas en REMnux.

La ultima inspección estática que haremos será más interactiva, para ello vamos a recurrir a Bokken, este se invoca solamente ejecutando el comando «bokken». Al hacerlo, en la terminal comenzará el checking de las dependencias necesarias para que «Bokken» funcione, al terminar eso  aparecerá la siguiente ventana, en donde configuraremos a «Bokken» para que funcione con el backend de Radare. Radare es un Framework que permite realizar análisis estático hacia archivos PE, hecho eso, buscaremos el binario muestra y pondremos a trabajar a «Bokken»:

Al iniciarlo aparecerá un panel de trabajo algo complejo, desde el podemos inspeccionar a mayor escala la muestra de malware proporcionada, de las  pestañas que hay en el lado izquierdo, seleccionamos la que tiene el nombre «Imports«, en donde veremos la misma información que estaba en la tabla arrojada por «pedump«, en donde vemos el grupo al que pertenecen y la función correspondiente a ellos. También podemos encontrar esta información en el panel principal, seleccionando la pestaña «File Info», dentro en la sección «Imports» veremos el listado de estas, identificando su función y nombre, en este caso ya sabemos que se tratan de las API’s maliciosas a las que el malware recurre para poder conseguir su propósito. 

Una ultima cosa antes de terminar, existen servicios o plataformas online que sirven de apoyo para usuarios que no confian en la procedencia de algún binario, hasta para analistas, investigadores forenses e «incident response teams», estas plataformas son Sandboxes que son conformadas por varias máquinas virtuales que operan en servicios de hosting como servidores que cuentan con una compleja configuración para mantenerse en operación.

Entre las plataformas de «Scanning/Analysis» online preferidas por mi, se encuentra «Hybrid-Analyisis«, por Hybrid se refiere a que puede hacer ambos análisis una vez comenzado el proceso, nos puede arrojar información que se obtiene mediante una aproximación con metodología dinámica tanto como nos puede arrojar información que se obtiene solo mediante un análisis estático.

NOTA: Para poder descargar muestras de la plataforma y hacer uso de ella para analizar muestras, tendrás que registrarte y crear un usuario. Es proceso es muy simple.

Yo ya tenía una cuenta en Hybrid-Analysis, hice el Submit (carga) de la muestra de malware y esperé los resultados, entre la BASTA INFORMACIÓN QUE OBTUVE, los detalles que más me llamaron la atención fueron los siguientes:

  • Como # 1 y por qué es necesario ponerlo, son los detalles del archivo PE, en donde  una vez mas nos encontramos con los 3 HASHES, y de nuevo identificamos a MPRESS como el Packer usado:

  • También podemos ver que se hace referencia de nuevo a «MPRESS» como indicador de uso de software anti-debugging para evitar reversing hacia el malware. Indicando también que existe un nivel inusual de entropía, mostrándonos de nuevo el valor de 7.987

  • Así como también podemos encontrar un apartado dedicado a las secciones de entropía encontradas, que como ya sabemos son 3: MPRESS1, MPRESS2 y .rsrc, cada una con sus correspondientes direcciones virtuales y con sus respectivos valores de entropía y HASHES.

  • Por último, está un apartado nombrado como «Network Related«, el cual contiene detalles acerca de todo lo que tenga que ver con redes y networking en lo que el malware haya estado involucrado. Aquí podemos ver el proceso que se  llevo en el comienzo una vez que el malware es ejecutado, en donde hace un ping hacia la dirección IP establecida durante la creación del troyano y ejecuta el archivo «install.bat» y después lo remueve.

Con esto, podemos darnos cuenta de la eficacia que tienen estas plataformas para analizar malware, en donde pudimos ver información idéntica a la que fuimos obteniendo a lo largo de esta demostración. Un ultimo detalle, si el equipo que esta infectado por el troyano es reiniciado ocurre una rutina de conexión, esto se debe a la funcionalidad de persistencia que trae consigo el malware.

En la imagen de abajo se demuestra el evento encontrado por el Process Explorer, así como sus propiedades, donde «TCP Reconnect» es el evento y vemos que hay un nuevo porto estableciendo conexión con el puerto 6525, que es el de la plataforma de trabajo:

Si aplicamos un filtro de exclusividad solo para remcos.exe, podemos ver la subrutina de reconexión entre host infectado y administrador (Ambos son los mismos). También vemos que hay un cambio de numero de proceso y de puertos, sin embargo, todas las operaciones de reconexión son exitosas:

Como lo había mencionado en el post anterior, se viene una serie de demás escritos con demostraciones de este tópico y similares, dando pie a adentrarnos más a fondo en el área del reversing, modding y análisis de malware. Temas, ejercicios/demostraciones de este tipo, similares y mas complejas se ven durante nuestro curso de hacking ofensivo COISP Nivel 2 «BlackHat».

Ya sea que quieras registrarte aquí en el blog o hacerlo desde la publicación en Facebook, comenta sobre que tipo de malware te gustaría saber más o ver una demostración sobre su inspección, o si lo prefieres, a que malware en específico te gustaría que le hiciésemos un análisis para adentrarnos en las entrañas de este y saber el  como es que opera, que es lo que contiene, como lo hace y que le permite hacerlo.

Todo el contenido de este escrito fue hecho con fines educativos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *