Agujas, pajares e imanes: Análisis forense de malware fileless (I)

[Nota: Esta serie de posts es una narración de un análisis forense de un caso práctico totalmente ficticio (pero contada, esperamos, de forma didáctica y con gracia y salero). Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XII Jornadas STIC del CCN-CERT, o echar un ojo las slides de la presentación].

[Nota 2: Estos posts desgranan un taller de análisis forense básico. Habrá algunas cosas que se podrían hacer de manera más eficiente y elegante, pero la idea era hacerlas de forma sencilla para que fueran fáciles de entender. Y como todo buen taller práctico, se puede seguir paso a paso: el CCN-CERT está alojando en LORETO todo el material, que podéis descargar desde aquí. Tenéis tanto las evidencias en bruto (si queréis primero intentar encontrar el bicho por vuestra cuenta sin leer nada de la solución) como una guía paso a paso con todas las herramientas y evidencias necesarias en cada paso].

Un nuevo día empieza en las instalaciones del MINAF (Ministerio de la Alegría y la Felicidad), lo que para Ángela de la Guarda (CISO del MINAF) significa café, reuniones y papeleo. Al menos, el proyecto del ENF (Esquema Nacional de Felicidad) está de una vez saliendo adelante…

Pero poco dura la alegría en casa del pobre. El CAU llama porque tienen un ticket que no saben por dónde cogerlo: María Feliz (Subdirectora General de Festejos) se queja amarga (e irónicamente) de que su correo “lleva un rato haciendo cosas raras”. Magnífica descripción del problema, afirmo, piensa mientras termina el café. El CAU ha revisado su equipo y no ha encontrado nada fuera de lo normal, pero la Subdirectora insiste en que “le aparecen correos como leídos que ella no ha abierto”.

Esta afirmación despierta el sexto sentido de Ángela, y decide poner a uno sus técnicos a investigar un poco más en profundidad el asunto. Quince minutos más tarde el técnico (Salvador Bendito), llama nervioso y excitado a partes iguales: ¡tenemos un incidente! Alguien ha accedido a la cuenta de correo de la Subdirectora a través del webmail del MINAF, usando para ello unas direcciones IP no pertenecientes a ningún ISP español.

La cosa no queda ahí: a lo largo de todo el día se ha accedido desde la misma dirección IP a varias cuentas de correo de altos cargos del MINAF, con varios centenares de accesos. Un análisis de los logs del servidor de correo permite establecer esta línea temporal inicial relativa al 3 de Noviembre de 2018 (día del incidente):

• 11:35h – Primer acceso de la IP sospechosa al webmail de maria.feliz.
• 11:35h-16.00h – Accesos de la IP a diversas cuentas de correo de altos cargos.
• 16.00h – Detección del incidente.

El paciente cero resulta ser Pepe Contento (Subdirector General Adjunto de Alborozo) con un primer acceso a su cuenta de correo sobre las 11.15h, así que corresponde investigar a fondo su equipo para determinar si es la causa del incidente (se ha decidido no bloquear el acceso de los atacantes a los correos hasta que no se tenga más información de la extensión y gravedad del ataque). Ángela y Salvador sorprenden al Subdirector justo cuando estaba cerrando su despacho, y cuando es consciente de la gravedad del incidente se pone a disposición de los técnicos para todo aquello que necesiten.

La política de seguridad del MINAF es muy clara: en caso de un incidente de seguridad, el personal de ciberseguridad tiene la potestad de examinar cualquier equipo o sistema de la Organización. En este caso no hay problema alguno, ya que el Subdirector ofrece encantado su consentimiento para el examen, llegando a quedarse en el despacho mirando con fascinación a los técnicos haciendo su trabajo.

En estos casos la medida más eficiente es realizar una captura de evidencias en caliente, ya que pueden realizarse de forma rápida y de esta forma se agiliza la respuesta al incidente. El Subdirector desbloquea su equipo con su contraseña y Salvador lanza un terminal elevado con la contraseña de administrador local que le ha facilitado el CAU.

A continuación pincha una memoria USB con las herramientas que va a emplear: winpmem para realizar un volcado de la memoria RAM del equipo y CyLR para la recogida de datos de triage, siempre teniendo cuidado de que los resultados se guardan en el USB y no en el disco duro local. La operación dura menos de 5 minutos (rapidísimo si lo comparamos con las 4-6 horas que puede suponer el clonado forense de un disco duro de 1Tb).

Una vez realizada la adquisición de evidencias en caliente, toca apagar el equipo con la metodología habitual: Ángela le dice al Subdirector que mire hacia un lado mientras Salvador se acerca a la parte de atrás de la torre y, de forma súbita, tira del cable de alimentación del equipo. Nunca se sabe qué scripts se pueden ejecutar en el apagado del equipo…

Habiendo realizado la adquisición inicial, se calculan en el portátil de Salvador los hashes de los dos ficheros obtenidos mediante la herramienta HashMyFiles:

MINAF-PC1.zip
MD5 a15acf19045c1f92a7b2eef46e1ed9d5
SHA1 fab756da558d6c7584574d7d73d62adf4e82bf16
SHA256 956b1366851608fe253deb3f14f7d013c24011dd940db9e2c96ffd4bb4e6c1b2

MINAF-PC1_Triage.zip
MD5 b52276522f5cbcc7f3fd5b300992e151
SHA1 454b8d3fe72ea778c78251f9662c5c565dc65414
SHA256 c7a405cedeb5b20046dee49f08dab5521d51d80b8f7334c5c4742329b465c93a

Para asegurar las evidencias, se realizan dos copias adicionales: una en el portátil de Salvador y otra en otra memoria USB nueva que Ángela ha traído para la ocasión (que se entrega junto con el equipo del Subdirector a la Inspección General de Servicios para su custodia). Se documenta todo el proceso (ver Ficha_Adquisición_Evidencias.txt contenido en el fichero Forense_MINAF_full.zip) y los técnicos vuelven a su despacho para comenzar el análisis.

[Nota 3: En la realidad todo el entorno de pruebas está virtualizado en un Proxmox en remoto al que pinchar USB es un verdadero dolor. Es por ello que la captura se ha hecho en “modo cloud”: se ha añadido al equipo un disco duro con las herramientas, se han ejecutado y se ha retirado el disco. Esto no afecta significativamente al análisis, pero es necesario indicarlo para no inducir a confusión si un analista examina las evidencias en bruto].

El primer paso es validar las evidencias recibidas con la herramienta HashMyFiles que Ángela tiene en su equipo:

Todo parece en orden, así que se puede comenzar el análisis.

Paso 1: Prefetch

Ángela tiene predilección por empezar los forenses revisando la carpeta Prefetch, con toda la razón del mundo: cada vez que se ejecuta una aplicación, Windows determina una serie de datos que necesita para arrancar y los deja precargados para acelerar futuras ejecuciones.

Esta funcionalidad está disponible desde Windows XP, aunque no existe ni en servidores ni en equipos con discos duros SSD (en los que Windows dice que son tan rápidos que no merece la pena). Y aunque su objetivo sea beneficiar la experiencia de usuario, para un analista forense son oro puro porque nos permiten determinar qué se ha ejecutado en el equipo.

Ángela hace uso de WinPrefetchView para cargar la carpeta Prefetch obtenida en el triage vía CyLR, y encuentra una buena lista de aplicaciones. Pero antes de nada, revisa la configuración horaria de la herramienta para asegurarse de que está trabajando en UTC (Coordinated Universal Time).

Un detalle muy importante siempre que realicemos un análisis forense es el tema de la gestión de las timezones: todos los países tienen una hora relativa a lo que se denomina UTC (GMT y UTC son para los mortales lo mismo). Por ejemplo, España es UTC+1 (salvo en verano que es UTC+2).

Una mala gestión de las timezones puede hacer perder mucho tiempo en un análisis forense, ya que se terminan buscando evidencias en momentos en los que no se han producido, pudiendo incluso llegar a conclusiones erróneas.

Los buenos forenses hacen dos cosas: intentan trabajar SIEMPRE en UTC+0, y sobre todo se conocen las herramientas que usan y saben en qué timezone trabajan por defecto, y si se pueden poner o no en UTC+0. Ángela es la CISO del MINAF pero se maneja con un terminal igual de bien que con un Excel, así que lo primero que hace es acceder a Options y comprobar que se muestran los tiempos en GMT (como ya hemos dicho, equivalente a UTC+0).

A continuación Ángela se pone a buscar qué se ha arrancado en el equipo antes de las 10.15h (recuerda, como estamos en UTC+1 para pasar a UTC+0 tenemos que restar una hora), prestando especial atención tanto a programas de ofimática (Word, Outlook, Excel) como a los ya conocidos LOLbins (comandos de Windows que permiten ejecutar código, en algunos casos incluso descargado de Internet).

[Tip: otra aproximación muy interesante suele ser la de ordenar por ejecuciones con el “Run Counter” y ver qué es lo que menos se ha ejecutado en el equipo].

Ángela tarda 30 segundos en encontrar algo MUY sospechoso: un combo a las 10.05h de wscript.exe + rundll32.exe, que podría ser una ejecución maliciosa.

Si nos fijamos en el panel inferior de WinPrefetchView, para cada ejecutable tenemos un listado de lo que se ha almacenado, y aquí la cosa queda bien clara:

El ejecutable wscript.exe ha lanzado el script FELICIDAD.JS… que si nos fijamos en la ruta está en “Temporary Internet Files”, lo que indica que ha sido descargado desde Internet.

En este punto Ángela ya tiene fuertes indicios de que el equipo ha sido comprometido, y además tiene algo valiosísimo: su primer IOC (Indicator of Compromise o Indicador de Compromiso), un fragmento de información que es vital para determinar si otros equipos de la Organización han sido afectados.

El IOC en palabras se podría describir como “presencia del fichero FELICIDAD.JS en un directorio de usuario”, algo que se puede fácilmente programar como un script .bat y ejecutar vía GPO/SCCM en todos los equipos de la Organización, volcando los resultados a una unidad de red compartida para su análisis.

El paso a seguir está claro: dado que el fichero malicioso parece haber sido descargado desde Internet, vamos a analizar el historial de navegación del usuario.

Paso 2: Navegación del usuario

Si revisamos con un poco más de detalle la salida de WinPrefetchView podemos observar que el navegador empleado ha sido Internet Explorer (IEXPLORE.EXE a las 10.01h), por lo que nos vamos a centrar en obtener su navegación.

El historial de navegación de un Internet Explorer moderno (el equipo es un Windows 7 correctamente actualizado) se guarda dentro del perfil de cada usuario en la carpeta:

C:\users\[username]\AppData\Local\Microsoft\Windows\WebCache

Actualmente hay herramientas como BrowsingHistoryView o MyLastSearch que pueden extraer la navegación del perfil de usuario, pero en este caso CyLR ha sido especialmente parco y nos ha facilitado únicamente el directorio Webcache, por lo que estas herramientas nos proporcionan un directorio vacío (parece que necesitan alguna estructura de ficheros para funcionar de forma correcta).

Ángela lleva unos cuantos forenses entre pecho y espalda, y sabe que siempre hay una forma de obtener resultados si conoces cómo funcionan las cosas a bajo nivel. En realidad un Internet Explorer moderno (versión 10+) guarda todos los datos de usuario en el fichero WebCacheV01.dat, que es una base de datos ESE (Extensible Storage Engine). Si tenemos un software que nos permita abrir ficheros ESE vamos a poder acceder a los datos en bruto, algo que Ángela consigue usando ESEDatabaseView:

El visor nos da acceso a bajo nivel a los datos, pero en un formato razonablemente usable. Ángela vuelve a ser cuidadosa con las timezones, y a través del menú “Options” se asegura de que la opción de “Convert Date/Time from GMT to Localtime” está desmarcada para así poder trabajar en UTC. Un vistazo rápido nos permite identificar que el historial reside en el contenedor con id=2, por lo que podemos navegar con la herramienta a esa tabla.

Una vez en el historial Ángela tiene una hipótesis muy clara: si wscript.exe se ejecutó el 3 de Noviembre a las 10:50:12h, en el historial de navegación tiene que existir una entrada sobre esa hora que nos indique a qué URL se ha accedido. Y en efecto, Ángela tiene razón:

Premio gordo. El usuario pepe.contento ha accedido a la URL:

http://sharepoint.mina.es:8000/felicidad.html

Al encontrar este dominio Ángela profiere una sarta de insultos que haría sonrojar a un estibador marsellés. Los atacantes han suplantado el Sharepoint del MINAF… por un dominio antiguo del MINAF. El Ministerio tenía anteriormente la denominación de MINA (Ministerio de la Alegría y la Felicidad), pero con el último cambio de gobierno se decidió incluir a la Felicidad como nueva competencia y por ello se produjo el cambio de nombre. Dado que nadie se molestó en renovar el dominio, los atacantes se dieron cuenta, lo registraron y emplearon vilmente para el ataque (si los usuarios se fijan habitualmente poco en los nombres de dominio, mucho menos en uno que han visto mil veces y que además reconocen como propio).

Algo bueno tiene esta pena: Ángela tiene un nuevo IOC, en este caso de los que llamamos “pata negra” ya que son fáciles de aplicar y con un alto grado de fiabilidad (no hay un motivo razonable para que un cliente visite ese enlace sin estar afectado por el ataque).

Ángela comprueba los logs de su proxy de navegación y su cortafuegos y respira aliviada. Por ahora el usuario pepe.contento parece que ha sido el único afectado. Le queda una de las dudas clásicas: ¿bloquea el dominio ahora mismo, o espera a saber más del incidente a riesgo de que los atacantes puedan causar más daño? Ángela es de la vieja escuela, y sabe que un “cierre” mal ejecutado es como tomar antibióticos dos días: corres el riesgo de no solo no matar al bicho sino de hacerlo más fuerte (avisas a los adversarios de que los has detectado y pueden tomar medidas evasivas), así que decide esperar al menos hasta terminar el análisis forense.

El contenido de los logs (y alguna sorpresa que otra) en la siguiente entrada…