Estos artículos forman parte de un taller de respuesta ante incidente básico. Por ello, hay cosas que se podrían hacer de una forma 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: es posible descargar una máquina virtual de Remnux con todo lo necesario para el taller aquí (para VMWare) o aquí (formato .ova))
Análisis (continuación)
En el artículo anterior habíamos determinado que había “algo raro” en el equipo, y nos habíamos descargado tanto un .doc posiblemente malicioso como un ejecutable y un buzón de correo del usuario. Toca ponerse manos a la obra para ver qué pueden contener…
[Nota: Una buena práctica de seguridad es que NUNCA se comparten ficheros maliciosos sin una mínima protección. Por ello, puedes descargar ambos ficheros desde aquí, pero están comprimidos y protegidos por la contraseña “infected”. Manéjadlos con extremo cuidado, avisados estáis).
Lo primero que podemos hacer es abrir la .pst del usuario para comprobar que la vía de infección es la correcta, algo que podemos hacer fácilmente desde Windows con el Kernel Outlook PST Viewer:
Ya tenemos confirmada la vía de entrada (y no nos olvidemos de apuntar los metadatos del correo, que nos van a ser de gran utilidad en la fase de contención), por lo que ya podemos concentrarnos en los dos ficheros maliciosos. Lo primero que hacemos es calcular los hashes (suele ser recomendable calcular tanto MD5 como SHA256, el primero porque todavía está muy en uso y el segundo para evitar colisiones):
# md5sum vfggggg.exe Purchase\ Order\ 03EDG.doc b4f28747a0a9317123f0ef109c580844 vfggggg.exe f48ca1a55120e5a5ff43962ccc8db1a2 Purchase Order 03EDG.doc # sha256sum vfggggg.exe Purchase\ Order\ 03EDG.doc 1dd788c038b4d8d2d3302d7a33162322d0896c7d17888e2fa34204b66c9aee50 vfggggg.exe 18ac90e921eac40200ec2b4508d3760149d4c9e931c96b5447a711ddf7d1b3e7 Purchase Order 03EDG.doc
Y de paso, obtenemos algo de información adicional con file y exiftool:
#file Purchase\ Order\ 03EDG.doc vfggggg.exe Purchase Order 03EDG.doc: Rich Text Format data, unknown version vfggggg.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows exiftool Purchase\ Order\ 03EDG.doc vfggggg.exe ======== Purchase Order 03EDG.doc ExifTool Version Number : 9.46 File Name : Purchase Order 03EDG.doc Directory : . File Size : 221 kB File Modification Date/Time : 2018:04:03 09:52:46-04:00 File Access Date/Time : 2018:04:08 04:06:49-04:00 File Inode Change Date/Time : 2018:04:08 04:05:26-04:00 File Permissions : rw-r--r-- Error : File format error ======== vfggggg.exe ExifTool Version Number : 9.46 File Name : vfggggg.exe Directory : . File Size : 930 kB File Modification Date/Time : 2018:04:03 07:39:44-04:00 File Access Date/Time : 2018:04:08 04:13:43-04:00 File Inode Change Date/Time : 2018:04:08 04:05:26-04:00 File Permissions : rw-r--r-- File Type : Win32 EXE MIME Type : application/octet-stream Machine Type : Intel 386 or later, and compatibles Time Stamp : 2017:06:24 06:53:40-04:00 PE Type : PE32 Linker Version : 8.0 Code Size : 371712 Initialized Data Size : 580096 Uninitialized Data Size : 0 Entry Point : 0xf000a OS Version : 4.0 Image Version : 0.0 Subsystem Version : 4.0 Subsystem : Windows GUI File Version Number : 1.0.0.0 Product Version Number : 1.0.0.0 File Flags Mask : 0x003f File Flags : (none) File OS : Win32 Object File Type : Executable application File Subtype : 0 Language Code : Neutral Character Set : Unicode Comments : Company Name : File Description : File Version : 1.0.0.0 Internal Name : mndgrhsz.exe Legal Copyright : Copyright © 2018 Legal Trademarks : Original Filename : mndgrhsz.exe Product Name : Product Version : 1.0.0.0 Assembly Version : 1.0.0.0
El segundo fichero es un ejecutable con todas las de la ley, pero el primer fichero dice que es un .doc pero resulta ser un .rtf (vector habitual de varios exploits tanto antiguos como recientes).
Buscamos los hashes en VirusTotal para comprobar si el malware es o no público:
- Purchase Order 03EDG.doc (9/57 en VT), parece un documento malicioso que explota el CVE-2017-0199, una vulnerabilidad de Word
- vfggggg.exe (10/66 en VT), malware a priori no identificado.
Dado que ambos ficheros son públicos, ya tenemos libertad de ejecutarlos en una sandbox como la de Hybrid-Analysis:
- Purchase Order 03EDG.doc
- vfggggg.exe
Si nos fijamos en los comentarios de VirusTotal, tenemos un análisis adicional de VMRay, que también aporta información adicional:
https://www.vmray.com/analyses/1dd788c038b4/report/overview.html
De la información de todas las fuentes anteriores extraemos las siguientes conclusiones:
- El exploit usado parece ser el CVE-2017-0199.
- El documento realiza una conexión TLS contra el dominio a.doko[.]moe (IP 185.83.215.16).
- El malware está empaquetado con el packer Morphine v1.2.
- El malware no realiza ninguna conexión con el exterior.
- El malware al parecer tiene funciones de keylogger.
- El malware realiza una conexión TLS contra el dominio dankleo01.chickenkiller[.]com (IP 91.192.100.59)
- El malware realiza una conexión contra el dominio iptrackeronline.com
- Antes de que aparezca el fichero vfggggg.exe aparece otro ejecutable: gabkrj.jpg.exe, que lanza el explorer.exe y lo crea.
- Se crea el directorio c:\users\USUARIO\appdata\roaming\imminent, con varios ficheros de interés.
No tenemos toda la foto, pero ya hemos obtenido dos dominios de contacto de interés: a.doko[.]moe y dankleo01.chickenkiller[.]com (www.iptrackeronline.com lo descartamos porque probablemente sea una prueba de conexión del malware para comprobar que tiene conectividad a Internet, no siendo malicioso en sí mismo). El hecho de que el punto 4 se contradiga con el 6,7 viene dado a que la información viene de distintas fuentes (y posiblemente en el punto 4 el malware haya reconocido la sandbox y no se haya ejecutado correctamente).
Contención, erradicación y recuperación
En este momento el análisis básico está realizado, por lo que podemos pasar a la fase de contención y erradicación del incidente. De la fase de detección y análisis tenemos los siguientes IOC de interés:
- Correo con asunto: “Factura urgente por material de cocina”
- Correo con remitente: newmasterchef@protonmail.com
- Correo con el adjunto: “Purchase Order 03EDG.doc
- Contacto con el dominio: a.doko[.]moe
- Contacto con el dominio: dankleo01.chickenkiller[.]com
Los IOC relacionados con el correo pueden ser cruzados con los logs de la pasarela de correo, y nos indican que 124 usuarios de la Organización han recibido el correo malicioso. Los IOC relacionados con los dominios pueden ser buscados en los logs del proxy de navegación, revelando que 6 usuarios han abierto el documento. La concienciación de seguridad de los usuarios ha mejorado sensiblemente (han picado solo un 5%, un dato razonable), pero aún parece necesario reforzar las bases a algunos usuarios (posiblemente estos usuarios sean invitados a un campo de reacondic… quiero decir a otro curso de concienciación en ciberseguridad).
Las medidas a tomar para la contención son sencillas:
- Bloquear los dominios en el proxy o en el cortafuegos para impedir cualquier progresión del malware
- Avisar a los usuarios para que no abran el correo malicioso y que lo borren de sus buzones de correo (en algunos casos los administradores de sistemas podrían hasta borrarlos de los buzones desde el propio servidor de correo).
Si realizamos un análisis del TLD .moe comprobamos con asombro que no es una referencia a los Simpsons sino un término de jerga japonesa relacionado con el anime y el manga. Y para más inri, el dominio .doko.moe es un servicio hawaiano de almacenamiento gratuito de ficheros, perfecto para que un atacante deje sus payload maliciosos.
Dado que no parece probable que los dominios .moe sean críticos para el funcionamiento de la Organización, proponemos su bloqueo completo. De forma adicional, podemos crear unas reglas básicas de Snort/Suricata para su detección:
alert tcp any any -> any 80,443 (msg:"Malware Cryptostealer HTTP/HTTPS doko.moe";classtype:trojan-activity; content:"doko.moe"; sid:666666667; rev:1; ) alert udp any any -> any 53 (msg:"Malware Cryptostealer DNS doko.moe"; flow:to_server; content:"|04|doko|03|moe"; classtype:trojan-activity; sid:666666668; rev:1; )
Copiamos estas reglas en el fichero /etc/Snort/rules/rules/local.rules, y comprobamos que no tenemos errores de sintaxis verificando la configuración con:
# snort -T -i eth0 -c /etc/snort/snort.conf
Si no hay errores, reiniciamos Snort para que aplique de nuevo la configuración:
# service snort restart
Y le pasamos a Snort el .pcap que hemos capturado previamente aquí:
# snort -i eth0 -c /etc/snort/snort.conf -r /home/remnux/sandbox/labo_dfir.pcapng -l /tmp -A fast
Si todo ha ido bien, tendríamos que tener estos resultados en el fichero /tmp/alert :
04/07-04:43:45.764408 [**] [1:666666668:1] Malware Cryptostealer DNS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 192.168.25.128:59223 -> 192.168.25.2:53
04/07-04:43:45.886443 [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49168 -> 185.83.215.16:443
04/07-04:43:47.738537 [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49172 -> 185.83.215.16:443
04/07-04:43:53.321598 [**] [1:666666668:1] Malware Cryptostealer DNS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 192.168.25.128:63047 -> 192.168.25.2:53
04/07-04:43:53.411079 [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49173 -> 185.83.215.16:443
Podemos también crear una regla de YARA para detectar nuevos adjuntos maliciosos. Si editamos el RTF podemos comprobar que tiene una cadena bastante característica (la que identifica el objeto OLE malicioso que suele tener el exploit):
Una regla muy sencilla (que habría que evaluar a la hora de los falsos positivos que puede generar) podría ser esta:
rule rtf_objdata_cve_2017_0199 {
strings:
$header = "{\\rtff"
$objdata = "\\object\\objautlink\\objupdate\\objw5816\\objh6097{\\*\\objdata" nocase
condition:
$header at 0 and $objdata
}
Guardamos este fichero con el nombre “cve-2017-0199.yar” y podemos comprobar si detectamos correctamente el malware con nuestra regla con el comando:
# yara -smg cve-2017-0199.yar /home/remnux/malware/Purchase\ Order\ 03EDG.doc
Las buenas prácticas en lo referente a la erradicación en un incidente suelen ser muy simples: “Nuke it from orbit” (la teniente Ripley SIEMPRE tiene razón). A menos que se tenga totalmente claro qué tipo de malware está afectando los equipos (y realizar así una eliminación quirúrgica), la opción más segura es el formateo de los equipos y su reinstalación.
La recuperación en este caso sería sencilla: reinstalación del equipo + restauración de las copias de seguridad pertinentes.
Sin embargo, nos siguen quedando algunas preguntas por resolver… que atacaremos en el siguiente y último artículo.
