Prepárate Malware, aquí viene el Forense

Debido al auge que están teniendo los ataques por Malware, cada vez son más las empresas que pierden sus datos o se pide una recompensa por ellos. Recordaremos que, no hace mucho, grandes empresas españolas se infectaron por un Ransomware denominado WannaCry o WannaCrypt el cual comenzó a propagarse por la red interna, cifrando todos los datos de los equipos y solicitando un posterior rescate por ellos. A la hora de identificar cual ha sido el vector de entrada de la infección, es recomendable realizar un análisis forense a los equipos. Existen muchos tipos de análisis forense, por lo que en este artículo nos centraremos en CÓMO realizar el análisis sobre sistemas Windows a través de un ejemplo.

ANÁLISIS FORENSE

Antes de comenzar, vamos a mostrar cierta información que es muy importante tener en cuenta a la hora de realizar un análisis forense.

BASES GENERALES

A la hora de llevar a cabo un forense, tenemos que tener en cuenta las siguientes bases:

  1. Verificar que efectivamente se ha producido un incidente de seguridad: nos hemos descargado un programa y nos hemos infectado, hemos abierto el adjunto de un correo que nos han enviado, etc… .
  2. Recopilar la máxima información posible acerca del incidente. 
  3. Identificar todas las fuentes de datos, tanto volátiles (memoria RAM) como no volátiles.
  4. Verificar que los datos identificados son íntegros y garantizar la cadena de custodia.
  5. Elaborar un informe de seguridad en dónde se muestren los resultados del análisis llevado a cabo.

ESTADOS DEL EQUIPO INFECTADO

Dependiendo del estado en el que se encuentre el equipo a la hora de recoger evidencias, se realizarán unos u otros procedimientos. Los equipos nos los podemos encontrar en dos estados:

  1. Equipo vivo: el dispositivo no se ha apagado y mantiene procesos en ejecución e información en la memoria RAM. Hay que tener en cuenta que esta memoria es volátil y apagar el equipo provocaría la eliminación de información relevante, por lo que el primer punto obligatorio es hacer un dump de ella utilizando un Pendrive con las herramientas correspondientes las cuales no deben realizar modificaciones en el sistema. Posteriormente tiraremos del cable, ya que la opción de apagar de Windows realiza modificaciones en el sistema y procederíamos a tratalo como un equipo Post-mortem.
  2. Equipo muerto (Post-mortem): el dispositivo se ha apagado por cualquier circunstancia y no dispone de procesos en memoria RAM ya que al ser volátil se pierde al apagarlo. En este estado realizaremos la imagen del disco a un fichero o la clonación a otro disco (copia bit a bit) a través de las herramientas correspondientes.

Una vez se han obtenido las imágenes, tanto de la memoria como del disco, comienza la investigación.

 REALIZANDO EL ANÁLISIS FORENSE

Para ponernos en situación, una empresa nos comenta que uno de los equipos de un empleado ha comenzado a realizar acciones sospechosas y tiene un comportamiento extraño. Debido a esto, nos han solicitado un forense para ver que ha podido pasar, por lo que nos envían dos ficheros de imagen, uno de la memoria RAM y otro del disco, junto a sus correspondientes hashes:

CALCULANDO LOS HASHES

Antes de comenzar con el análisis, es obligatorio calcular los hashes de los ficheros recibidos con el objetivo de verificar que coinciden con los que nos han enviado. Si no coinciden significa que, o se han manipulado las imágenes o no se ha realizado el proceso correctamente y se habría roto la cadena de custodia. En este caso, a través de la herramienta md5sum, confirmamos la coincidencia de los hashes:

COMPROBANDO ZONA HORARIA

Como primer paso en el análisis que vamos a realizar, es comprobar la zona horaria que estaba configurada en el equipo con el objetivo de verificar la hora en la que se han ejecutado los procesos. Montaremos la imagen del disco con FTK Imager y accederemos a la ruta C:\Windows\System32\config\ en la que encontraremos los siguientes ficheros:

  • DEFAULT
  • SAM: proporciona información referente de todos los usuarios del sistema (fecha de creación, último login, último cambio de password, etc…).
  • SECURITY: contiene información de seguridad utilizada por el sistema y la red.
  • SOFTWARE: contiene información acerca de los programas utilizados por todos los usuarios del equipo (versión, fecha de instalación, licencia, etc…).
  • SYSTEM: proporciona información sobre los perfiles de hardware del sistema, controladores, unidades de disco, etc… .

Además de las claves de los ficheros de registro anteriores, también son interesantes estos otros ficheros:

  • User\<usuario>\Ntuser.dat
  • User\<usuario>\Local\Data\Microsoft\Windows\UsrClass.dat

Vamos a extraer todos los ficheros de registro anteriores a una carpeta, a través de Botón derecho >> Extraer para su posterior análisis :

Los ficheros exportados tendremos que abrirlos con otro programa, en este caso utilizaremos Windows Registry Reader. Abriremos el fichero SYSTEM exportado y comprobaremos el ControlSet que tiene establecido, ya que puede haber varios. El ControlSet fichero contiene información del arranque del sistema y de la configuración de los dispositivos:

Observamos que se encuentra habilitado el ControlSet01, ya que la imagen sólo dispone de ese, por lo que accederemos al directorio \ControlSet01\Control\TimeZoneInformation para comprobar la clave TimeZoneName :

Dicha clave informa sobre la zona horaria establecida, que en este caso pertenece a Pacific Standard Time. A modo de ejemplo, si los procesos tienen como hora de ejecución las 13:50 horas del país de origen, como la zona se corresponde a Pacific Standard Time GMT +7 , habría que sumar siete horas por lo que los procesos se habrían ejecutado a las 20:50 hora española.

Procedemos a abrir otro fichero exportado, en este caso el fichero SAM, para ver otros usuarios que hay creados en el sistema. Seleccionaremos la opción SAM en la columna izquierda y desplegaremos la opción Users en la derecha. Aquí comprobaremos aquellos usuarios que además de estar creados, se han utilizado, a través de la última hora de login en el sistema:

El usuario RogerMoore, como se ve en la imagen, ha iniciado sesión en el sistema a las 01:19 en GMT+7. Los otros usuarios listados no han iniciado sesión.

COMPROBANDO SOFTWARE INSTALADO

Como la mayoría de las infecciones de malware se realizan a través de adjuntos en correos electrónicos, vamos a comprobar si el usuario RogerMoore dispone de algún gestor de correo. Para ello, abriremos el fichero exportado SOFTWARE y accederemos a la opción de menú Windows Instalation y a la pestaña Installed Software :

En ese listado, que se corresponde con todos los programas instalados en el ordenador, no encontramos un cliente de correo instalado aunque también podría haber accedido a un servicio de correo web mediante un navegador. Esto podemos comprobarlo en la caché del navegador que se encuentra en el fichero de imagen del disco.

COMPROBANDO EL HISTORIAL DEL NAVEGADOR

Chrome

Volvemos al FTK Imager y accedemos a la ruta \Users\<usuario>\AppData\Local\Google\Chrome\User Data\Default en la que encontraremos el fichero History el cual procedemos a extraer :

 Este fichero tiene como formato .sqlite por lo que necesitamos de otro programa para poder abrirlo. Nosotros vamos a utilizar DB Browser for SQLite para revisar todas las direcciones del campo url con el objetivo de ver si ha accedido a algún correo web como Gmail, Hotmail, Yahoo, etc… . Investigando un poco y utilizando como filtro la palabra mail, observamos que sí ha utilizado el servicio de correo web ProtonMail :

El campo fecha con valor 13122266747104583 se encuentra en un formato específico de Chrome por lo que tendremos que hacerlo legible. Nosotros utilizaremos la página https://www.epochconverter.com/webkit que es un conversor de timestamps a fechas legibles:


Se identifica que el usuario hizo login en el servicio de correo web Protonmail sobre las 03:05 del 30 de Octubre.

COMPROBANDO CORREOS ENVIADOS

A través de la caché del navegador, no podemos ver si se ha realizado el envío o la recepción de algún correo electrónico, pero podemos consultar el fichero de imagen de la memoria RAM en la que seguramente sigan esos correos. Las búsquedas sobre ficheros de imagen de memoria RAM las haremos con la herramienta volatility, aunque hay muchas otras. Lo primero que necesitamos saber es el sistema operativo al que pertenece este dump de memoria, pues dependiendo de cual sea, se utilizará un perfil de volatility u otro. Esta información la obtendremos con el parámetro imageinfo que, como se muestra en la siguiente imagen, nos indica que el sistema operativo es un Windows 10 32 bits (Win10x86_14393) :
 

Ahora añadiremos a la ejecución de volatility el parámetro –profile=”Win10x86_14393″ para aplicar el perfil correspondiente y el parámetro pstree para mostrar todos los procesos existentes en la memoria en forma de árbol. Los campos mostrados son los siguientes :

  • Name: nombre del proceso ejecutado.
  • Pid: número de proceso asociado al ejecutar el programa.
  • PPid: número de proceso del proceso padre que lo ha ejecutado.
  • Thds: número de veces que se ha ejecutado.
  • Time: fecha en la que se ha ejecutado.

La salida del comando es la siguiente:

Tendremos que ir revisando todos los procesos que aparecen e ir comprobando sus PPids para verificar que el proceso padre es el que tiene que invocar al servicio y no otro. Después de mucho y mucho revisar, nos fijamos en seis servicios de chrome que se encontraban abiertos (seguramente las pestañas del navegador) que vamos a analizar. Observamos que cada uno tiene su propio Pid y todos excepto el primero tienen el mismo PPid 5704 que se corresponde con el Pid del primer proceso de chrome, que es el padre de los demás (seguramente el propio navegador) :

Ya que averiguamos anteriormente que el usuario estuvo utilizando un servicio de correo web, vamos a analizar cada uno de estos procesos para ver que encontramos. Para extraer un proceso de la imagen de la memoria RAM, utilizaremos volatility con los parámetros memdump -p <número_de_proceso> –dump-dir=”<directorio_salida>” :

 Si accedemos al directorio de salida indicado en el parámetro –dump-dir , observamos el fichero del dump del proceso, en este caso el proceso con PID 4992 :

Utilizaremos el comando strings para buscar cadenas dentro de este fichero .dmp . Como ejemplo, vamos a proceder a buscar la cadena To: que aparece en los correos electrónicos :

Parece ser que tenemos coincidencias. Otra forma de hacer esto es volcar todo el contenido a un fichero .txt y realizar las búsquedas en él. De esta otra forma, hemos encontrado el contenido del correo que le han enviado a nuestro usuario :

 Ya tenemos evidencia de que la infección se ha llevado a cabo a través de un correo electrónico.

COMPROBANDO EJECUCIONES DE PROGRAMAS

Comprobaremos ahora que es lo que se ha ejecutado en el sistema. Todos los programas que se han ido ejecutando en ese ordenador, se almacenan en la carpeta Prefetch que se encuentra en la ruta C:\Windows\Prefetch dentro de la imagen del disco. Para poder exportarla, tendremos que ir a la imagen del disco en FTK Image :

Exportamos la carpeta Prefetch de la imagen del disco y comprobamos, en el directorio de destino, todos los procesos que tenemos:

Para un mayor análisis, utilizaremos la herramienta WinPrefetchView que nos detallará cada uno de estos procesos con la hora de creación, hora de modificación, tamaño del fichero, ruta del proceso, número de ejecuciones, etc… . Por defecto este programa se abrirá configurado para leer la carpeta de nuestro ordenador C:\Windows\Prefetch :

Antes de nada, tendremos que indicarle la ruta en la que se encuentra la carpeta Prefetch que acabamos de exportar. Una vez cargada, se muestran todas las ejecuciones que hemos extraído de la imagen del disco. Ordenaremos por la hora de modificación y nos iremos fijando en cada uno de ellos para detectar ejecuciones sospechosas:

En este caso, después de mucho analizar, nos encontramos con una secuencia de ejecución de programas un tanto sospechosa :

Cada uno de estos procesos, se detalla a continuación:

  • powershell.exe: es una interfaz de consola, más poderosa que DOS, creada para la automatización de tareas administrativas a los usuarios.
  • net.exe: es un proceso del sistema de windows capaz de manipular otros programas, conectarse a internet y registrar entradas. Su denominación es utilizado muy a menudo por el malware para intentar pasar desapercibido. Debe localizarse en C:\Windows\System32 o en su defecto, puede ser un proceso malicioso.
  • tasklist.exe: este proceso muestra todos los servicios, servicios corriendo bajo procesos, servicios corriendo bajo una cuenta de usuario, aplicaciones, etc… que están corriendo en el sistema, detallando el PID (Process ID) de cada uno de ellos.
  • whoami.exe: muestra información del usuario que se encuentra autenticado, como por ejemplo el grupo al que pertenece y los privilegios que dispone. Utilizado sin parámetros muestra el dominio y el nombre de usuario. Es utilizado en intrusiones sobre sistemas para verificar el usuario con el que nos encontramos y sus privilegios.
  • mshta.exe: este proceso, por defecto en Windows, es el encargado de ejecutar ficheros con extensión hta, que es la abreviación de HTML Aplication. Estos ficheros están formados por etiquetas HTML y algún lenguaje de Script (VBScript o Javascript), que pueda ser ejecutado por Internet Explorer, y son muy utilizados como medio de infección a través de correos web. A continuación mostramos un ejemplo:

COMPROBANDO LA CACHE DE WINDOWS

Al igual que con pasos anteriores, accederemos a la imagen del disco a través del FTK Imager y exportaremos el fichero WebCahceV01.dat unicado en C:\Windows\Webcache a un directorio:

 Para abrir este otro fichero de caché utilizaremos el programa IECacheView . Nada más abrirlo y habiendo ordenado los procesos por fecha, nos encontramos con la ejecución de un fichero de extensión .hta , conneryhaters[1].hta , el cual hace una petición a la dirección URL http://128.199.170.85/conneryhaters.hta a las 03:24 , hora que coincide con la ejecución del proceso MSHTA.EXE que hemos visto en el directorio Prefetch del punto anterior:

Comprobamos que la ruta en la que se encuentra el fichero C:\Users\RogerMoore\AppData\Local\Microsoft\Windows\INetCache\Low\IE\DT34KEU7\conneryhaters[1].hta es una ruta perteneciente al usuario:

Si accedemos a esa ruta, identificamos el fichero ejecutado del cual podemos ver su contenido, formado por etiquetas HTML y lenguajes de script como comentamos anteriormente. En este caso se crea un objeto ActiveX que ejecutará powershell.exe cuyo contenido se encuentra en Base64:
 

 Ya que Base64 es un sistema de codificación, es posible decodificarlo para ver su contenido, en el que nos encontramos una llamada a la misma dirección URL de antes pero dirigida al fichero index.asp en el puerto 8080 de ese servidor:

Para conocer un poco más de información sobre este fichero .hta, nos dirigimos al directorio de Windows C:\Windows\System32\winevt\Logs en el que se recogen todos los eventos generados por el sistema y los analizamos. Entre ellos, encontramos los eventos de Powershell relacionados:

 Ahora, procedemos a extraerlos y a hacer doble click sobre ellos para que el gestor de eventos de Windows los abra, pudiendo observar la información detallada que nos muestra:

Tal y como sospechábamos, se produjo la ejecución del fichero conneryhaters[1].hta a través del cual se produjo la ejecución de Powershell. Cómo último paso, comprobaremos si ha creado persistencia en el sistema en las rutas :

Parece ser que la ejecución de este script ha generado un nuevo valor en la clave Run para asignar persistencia cada vez que se arranque el ordenador.

Esperamos que os haya gustado.

Don’t give up. Great things take time“.

Deja un comentario

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