Hola a todos he creado este artículo a raíz de uno de los ejercicios que he puesto a mis alumnos de la asignatura de Gestión de Respuesta Frente a Incidentes de Seguridad dentro del Certificado de Profesionalidad de Castilla La-Mancha, en la resolución de este caso forense pretendo mostrar cómo llevar a cabo un ejercicio forense para descubrir qué ha sucedido durante un incidente. En el siguiente artículo se podrá ver cómo se tratan las evidencias y qué herramientas usamos para descubrir lo sucedido y, con ello, realizar un informe del caso.
Autor: David Bernal
Twitter: @db3rn4l.
Linkedin: https://www.linkedin.com/in/davidbernal89/
Antecedentes:
La empresa Renter nos ha contratado para realizar un ejercicio forense en el que, según dice la empresa, creen que el ordenador de Raúl ha sido vulnerado.
Raúl ha notado que su equipo ha emitido algunas ventanas azules que se cierran rápidamente y ralentización del equipo mientras está trabajando.
El sujeto afectado es un empleado administrativo que se encarga de gestionar los préstamos de las furgonetas de la empresa, por lo que no tiene conocimientos informáticos, más allá de los básicos para realizar su trabajo.
Renter es una empresa (ficticia) que se dedica a prestar furgonetas en alquiler.
Evidencias:
Como evidencias disponemos de un triage completo realizado mediante la herramienta Windows Live Response de Brimor Labs que se puede descargar del siguiente enlace https://www.brimorlabs.com/tools/.
Windows Live Respones (en adelante WLR) es una herramienta gratuita GNU desarrollada por Brian Moran que permite la recolección de la memoria volátil (memoria RAM), la realización de un triage mediante el cual se obtienen números registros volátiles importantes y una imagen del disco duro del equipo afectado.
En el caso en el que nos encontramos, disponemos de un triage completo, compuesto por las imágenes forenses (memoria e imagen del disco) y los datos volátiles obtenidos en vivo, tal y como se puede observar en las imágenes inferiores.
Directorio ForensicImages:
Directorio LiveResponseData:
Análisis de evidencias. Triage:
Comenzamos revisando el archivo system_info.txt dentro de la carpeta BasicInfo.
En este archivo obtendremos datos importantes tales como el sistema operativo, nombre del equipo, direccionamiento IP y la zona horaria del sistema, dato muy importante que nos ayudará a establecer una línea temporal con los eventos ocurridos dentro del sistema.
System Info:
El siguiente paso que damos es echar un vistazo dentro de los procesos del sistema, para ello abrimos el archivo PsList.txt.
En la tabla de procesos que se puede ver en el archivo observamos un proceso powershell, algo bastante sospechoso ya que Raúl no tiene conocimientos suficientes como para realizar trabajos con esta herramienta.
Desgraciadamente el archivo PsList.txt no nos muestra el proceso padre de cada proceso para saber de dónde puede provenir la ejecución de este proceso powershell.
PsList.txt:
Ya disponemos de un hilo de donde tirar, por lo que deberíamos echar un vistazo a todo lo relacionado con powershell y más concretamente con el proceso con PID 360, pero vamos a dejarlo aparcado un poco y, para que no se nos escape nada, vamos a continuar mirando más archivos obtenidos en el triage.
Otra cosa muy importante que revisar son siempre las conexiones de red de los equipos, el triage de WLR, ofrece varios archivos con registros de las conexiones de red que existen en el momento de la realización del triage.
Durante este ejercicio nos vamos a centrar en el archivo cports.html dentro de la carpeta NetworkInfo, que es un archivo realizado en HTML (visible desde un navegador web) mediante el cual se pueden apreciar las conexiones de red que realiza un equipo.
Si nos fijamos detenidamente se puede observar que, desde la IP de la máquina de Raúl, se realiza una conexión a la IP 151.12.4.11 mediante el proceso powershell al puerto 3601. Esta dirección IP no se corresponde a ninguna dirección IP de la empresa Renter, por lo que se está realizando contra un host de Internet… También es sospechoso el puerto ya que no se corresponde a ningún puerto conocido por ningún servicio al que acceda la empresa.
Adicionalmente podemos observar una conexión FTP a la misma dirección IP, lo que nos puede indicar que alguien ha estado transfiriendo archivos entre la máquina afectada y esa máquina desconocida.
cports.html:
Continuando con la revisión de los archivos del triage, esta vez miramos en el archivo LastActivityView.html dentro de la carpeta BasicInfo.
Este archivo refleja las últimas ejecuciones realizadas en el sistema, observamos las ejecuciones de powershell, PID (360) que tenemos apuntado y posteriormente revisaremos cuando analicemos la memoria volátil en profundidad y la ejecución del ftp nativo de Windows. Nos llama mucho la atención que un usuario básico de Windows, que hace labores administrativas, haga uso de la herramienta nativa de ftp de Windows (normalmente se utilizan aplicaciones del tipo WinSCP para realizar transferencias de archivos FTP), por lo que nos lo apuntamos.
También podemos comprobar que se ha realizado la ejecución del programa WINWORD.EXE (aplicación Word de office) y se ha abierto el archivo factura.doc, a estos registros no les vamos a hacer demasiado caso por el momento, ya que el PC es usado por una persona que suele realizar su trabajo diario con herramientas de office y maneja la facturación de sus clientes.
Análisis de evidencias. Eventos del sistema:
Llegados a este punto del análisis, nos vamos a dirigir a la imagen del disco duro del PC implicado para extraer los eventos del sistema.
Dentro de la Carpeta ForensicImages > DiskImage encontramos una serie de archivos con extensión *.drive.E0n, éstos son fragmentos de una imagen de disco duro realizada durante el triage con WLR, tal y como se puede ver en la imagen inferior.
Para poder montar la imagen de disco utilizamos la herramienta FTK Imager de AccessData que se puede descargar de forma gratuita del siguiente enlace https://accessdata.com/product-download/ftk-imager-version-4-5 tras registrarse.
Desde dentro de la herramienta elegiremos como origen Image File y seleccionaremos el primer E01 para montar el disco al completo.
Una vez montado, nos aparecerá el árbol completo de directorios del sistema como se puede ver en la siguiente imagen:
Accederemos a la ruta C:\Windows\System32\Winevt\Logs y extraeremos los eventos del sistema System.evtx y Microsoft-Windows-PowerShell%4Operational.evtx
Para poder visualizar los eventos del sistema tenemos varias herramientas, podemos tirar del propio visor de eventos de Windows, utilizar Full Event Log View de Nirsoft https://www.nirsoft.net/utils/full_event_log_view.html o mi preferido, Even Log Explorer https://eventlogxp.com/download.php
Event Log Explorer (en adelante ELE) es un programa de pago, pero que mediante registro te permite hacer uso de la solución durante un periodo de 30 días y una vez acabados puedes solicitar la ampliación de la licencia.
Para poder cargar los eventos en ELE, simplemente nos dirigimos a File > Open Log File > Standard y seleccionamos el archivo de eventos que queramos visualizar.
En este caso vamos a empezar por Microsoft-Windows-PowerShell%4Operational.evtx ya que en este archivo se guardan todas las ejecuciones realizadas a través de Powershell y nos interesa comprobar si se puede ver alguna ejecución de Powershell que demuestre las incidencias sobre las que se queja Raúl.
Lo primero que hacemos siempre que se trabaja con Event Log Explorer es ajustar la hora a UTC para no equivocarnos y a partir de ahí mentalmente se suman las horas para ajustar el tiempo a la hora que tenía el sistema, en este caso era UTC + 1 (Madrid) pero en horario de verano, es decir, 2 horas más.
Para ajustar el tiempo, nos dirigiremos a View > Time Correction
Y aplicamos en UTC
A continuación, nos dirigimos a las 11:17 (15:17 UTC + 2) ya que el fichero LastActivityView.html mostraba una ejecución de Powershell a las 13:16 (UTC + 2) y se puede observar una ejecución de Powershell -e junto a un string de caracteres ilegible.
Observando que el string acaba en == se puede intuir que se trata de un string de texto codificado en Base64, por lo que nos dirigimos a la página web base64decode.org y lo pegamos aquí para descifrarlo.
Si miramos detenidamente el string resultante se puede apreciar que se crea un objeto de red en el que se establece un socket de conexión System.Net.Sockets.TCPClient("151.12.4.11",3601) hacia la dirección IP 151.12.4.11 al puerto 3601 (justamente la dirección IP que aparecía en el archivo cports.html) otorgando una Shell en Powershell de la máquina de Raúl, es decir, una Shell Reversa con la que el atacante ha obtenido el control de la máquina de Raúl.
También hemos revisado los eventos de seguridad del sistema de Raúl alojados en el archivo Security.evtx en el que no hemos visto conexiones entrantes hacia la máquina de Raúl, ni sesiones abiertas remotamente, ni creación de usuarios extraños dentro del sistema, lo que nos confirma que ha sido la máquina de Raúl la que se ha debido de conectar a la máquina del atacante ofreciéndole una Shell de Powershell.
Análisis de evidencias. Memoria:
Para analizar el volcado de memoria de la máquina de Raúl vamos a utilizar la herramienta Volatility concretamente la versión Stand Alone executable que se puede descargar aquí http://downloads.volatilityfoundation.org/releases/2.6/volatility_2.6_win64_standalone.zip
Volatility es una herramienta forense de análisis de memoria desarrollada en Python, lo que permite que pueda ser utilizada en cualquier plataforma que tenga Python instalado.
En este caso forense, vamos a usar la versión Stand Alone porque no necesitamos añadir plugins adicionales y no es necesario instalar Python para usarla.
Lo primero que se debe hacer para comenzar a analizar un volcado de memoria con Volatility es hallar el perfil del sistema operativo instalado, para ello Volatility cuenta con el comando “imageinfo”.
La sintaxis del comando sería la siguiente:
volatility.exe -f RAUL-PC_20220607_152508_mem.dmp imageinfo.
*Nota: La opción -f RAUL-PC_20220607_152508_mem.dmp, sirve para indicar la ruta del volcado de memoria.
El resultado nos arroja cuatro posibles perfiles, en este caso nos vamos a quedar con el perfil Win10x64_10586
Una vez obtenido el perfil vamos a continuar analizando la memoria en busca de los procesos en ejecución, si recordamos al principio del caso forense teníamos un proceso de Powershell con PID 360, el cual no sabemos cuál era su origen, es decir, su proceso padre. Para obtener un árbol de procesos en donde aparezcan los procesos clasificados utilizaremos el comando pstree y la salida del comando la vamos a mandar a un fichero que nos facilite su lectura.
La sintaxis del comando sería la siguiente: volatility.exe -f RAUL-PC_20220607_152508_mem.dmp --profile=Win10x64_10586 pstree > pstree.txt
Una vez obtenida la salida de pstree podemos observar que el proceso powershell.exe PID:360 es hijo del proceso WINDWORD.EXE con PID 3304.
La interpretación de lo anterior es que el usuario hizo uso de la aplicación WORD para abrir un archivo y a continuación se ejecutó el proceso powershell.exe, algo muy sospechoso.
A continuación, echamos un vistazo a las conexiones de red. Mirar las conexiones de red dentro de la memoria tiene la ventaja de que pueden quedar registros de conexiones que han sido cerradas y que no aparecen en los archivos de los triages.
Para ello ejecutamos el comando netscan y lo mandamos a fichero de la siguiente forma:
volatility.exe -f RAUL-PC_20220607_152508_mem.dmp --profile=Win10x64_10586 netscan > netscan.txt
De los registros que obtenemos podemos apreciar la conexión powershell contra la IP 151.12.4.11 al puerto 3601 y adicionalmente otra conexión a la IP 151.12.4.11 al puerto 21 la cual puede estar relacionada a la ejecución del ftp.exe nativo de Windows que vimos en el archivo LastActivityView.html
Tras haber analizado las conexiones y visto el árbol de
procesos, vamos a pasar a analizar proceso por proceso. Para ello haremos uso
del comando memdump que nos va a permitir volcar el área de memoria usada por
un proceso y a partir de ese volcado extraeremos datos utilizando strings en
Windows.
Para obtener el comando strings en Windows deberemos
descargarlo del siguiente enlace: https://docs.microsoft.com/en-us/sysinternals/downloads/strings
Vamos a comenzar con el proceso WINWORD ya que nos interesa
saber cuál es el archivo que que ha podido generar esa ejecución de Powershell.
Para obtener el minidump del proceso 3304 ejecutamos el siguiente comando:
volatility.exe
-f RAUL-PC_20220607_152508_mem.dmp --profile=Win10x64_10586 memdum -p 3304 -D
.\dir
Una vez obtenido el minidump, haremos uso de Strings y filtraremos por “doc” para poder ver qué documentos se encontraba manejando el Word en ese momento.
Después de realizar el comando strings64.exe 3304.dmp | find “doc” obtenemos registros de que el archivo que estaba abierto por el proceso es factura.doc que se encontraba en la ruta C:\Users\Raul\Desktop\factura.docx como se puede apreciar en la siguiente imagen.
El siguiente proceso que vamos a analizar es el proceso 360 correspondiente a Powershell, para ello volcamos el área de memoria del proceso:
volatility.exe -f RAUL-PC_20220607_152508_mem.dmp --profile=Win10x64_10586 memdum -p 360 -D .\dir
Una vez obtenido el minidump vamos a tirar de Strings para intentar obtener información. Primero filtramos por “doc” y podemos observar que la persona que controlaba el proceso powershell comprimió la carpeta docs de Raúl en un fichero llamado exfil.zip, por lo que pudo haber robado información.
En el siguiente paso filtramos por “ftp” ya que si el atacante quiso robar información seguro que pudo haber utilizado el protocolo ftp tal y como vimos en el archivo LastActivityView.html y… bingo!, tal y como podemos ver en la imagen inferior el atacante ha extraído la información a través del protocolo FTP, además podemos ver cómo se conecta a la IP 151.12.4.11 la misma que vimos cuando extrajimos las conexiones de la memoria mediante el comando netscan con el usuario kali y la contraseña kali.
Análisis de evidencias. Registros de Ficheros:
Únicamente nos queda descubrir cómo ha podido llegar ese archivo malicioso al PC de Raúl, por lo que volvemos al FTK imager y extraemos la MFT ($MFT) de la raíz del sistema de ficheros.
La MFT o Master File Table, es una tabla que guarda los registros de todos los ficheros que están o han estado en el sistema junto con sus timestamps, es decir, las fechas de acceso, creación, modificación y cambios en los metadatos de los archivos.
Para poder leer la mft, primero debemos parsearla, es decir traducirla a un idioma que podamos interpretar, para ello vamos a hacer uso de la herramienta mftdump la cual es capaz de producir un archivo CSV con los registros de la MFT.
Para descargar la herramienta se hacía desde la web http://malware-hunters.net/freetools/, pero actualmente se encuentra caída por lo que podemos acceder mediante archive.org y descárgalo del siguiente enlace https://web.archive.org/web/20170223081622/http://malware-hunters.net/wp-content/downloads/MFTDump_V.1.3.0.zip
La sintaxis es muy básica simplemente con mftdump.exe $MFT -o resultado.csv obtendremos la tabla MFT lista para analizarla con nuestra aplicación de hoja de cálculo preferida.
En este caso yo he utilizado Excel y tras pasar los registros a columnas separados por tabulador, ordenarlos de más antiguos a más nuevos y filtrar por “factura” hemos encontrado un registro .lnk en los recents que justamente se encuentra debajo de bastantes registros de Thunderbird, lo que hace pensar que el cliente de correo electrónico ha podido tener algo que ver en la aparición de este archivo.
Decididos a analizar el correo electrónico de Raúl mediante FTK imager nos dirigimos a la ruta C:\Users\Raul\AppData\Roaming\Thunderbird\Profiles y nos exportamos su perfil de correo electrónico para poder analizarlo.
El correo electrónico procedente del cliente Thunderbird lo analizamos con la herramienta Mbox Viewer Free https://www.mboxviewer.com/. Esta es una herramienta cuya licencia tiene un coste, pero que permite un periodo de prueba de aproximadamente unos 15 días.
Abrimos la herramienta y cargamos la carpeta exportada con
el perfil tal y como se puede ver a continuación.
Y vualá, ahí tenemos el correo electrónico de Raúl.
Si nos fijamos detenidamente Raúl suele recibir correos de la empresa cliente aliven.es, pero… en su buzón de entrada hay un correo desde el dominio a1iven.es, lo que parece claramente una suplantación de identidad.
Si abrimos el correo podemos
observar que tiene como adjunto el archivo factura.doc.
Tras comprobar el correo nos dirigimos con FTK imager a la ruta C:\Users\Raul\Desktop\factura.doc y extraemos el archivo.
Una vez obtenido el archivo podemos analizarlo de varias formas. Una de ellas es subirlo a virustotal y obtendremos un análisis del archivo, tal y como podemos ver en la imagen inferior:
O con mucho cuidado y en un entorno controlado, podemos proceder a abrirlo y comprobar que el fichero tiene una macro en su interior con el comando que vimos en los eventos de powershell.
Fin.
