Paso 5: Análisis de malware
En la entrada anterior Ángela había encontrado la persistencia del malware, así que procede analizarlo para ver su contenido. Salvador (a pesar de su espesa barba digna de un administrador de HP-UX de principios de siglo) está más contento que un niño con zapatos nuevos, así que se lanza a por el malware como un fox-terrier hambriento.
Lo primero de todo es comprobar si nos estamos enfrentando a un malware conocido. Para ello Salvador copia el código en base64 a un fichero de texto, calcula su hash con HashMyFiles y lo sube a VirusTotal sin obtener resultados. Interesante…
El segundo paso sería subir el fichero a VirusTotal, pero Salvador ha estado atento a lo explicado por sus profesores del curso de análisis de malware: algunos atacantes vigilan de forma constante VirusTotal para comprobar si su malware ha sido subido a la plataforma, usándola como un sistema de alerta temprana.
En algunos casos son hasta capaces de poner un código distintivo de cada organización a la que atacan para, cuando descubren que está en VirusTotal, descargarlo y saber exactamente qué cliente los ha detectado (y suele ser MUY mala idea que los malos sepan que les vas pisando los talones…).
Lo que sí que puede hacer es subirlo a MARIA, la solución multiantivirus que el CCN-CERT pone a disposición de todas las AA.PP. (y que obviamente es privada). En este caso el resultado es más bien decepcionante:
Vamos a tener que darle “amor” al bicho, piensa Salvador. Lo primero de todo va a ser decodificar ese código en base64. Para ello hace uso de b64.exe, una utilidad básica que nos convierte el código anterior en un Powershell algo más comprensible. Después de formatearlo un poco para hacerlo más legible, el resultado es el siguiente:
El código viene a decir más o menos: “mira a ver si estás en 32 o 64bits, coge este otro código en base64 que está comprimido, cárgalo en memoria y ejecútalo”. Salvador sabe que podría cargar ese base64 en su Linux y magrearlo con Python, pero también sabe Powershell suficiente como para obligar al bicho a que trabaje para él.
Unas pequeñas modificaciones al código hacen que vuelque la salida del código en base64 a un fichero ¿Y cuál es el resultado de un buen trabajo? Más trabajo, ya que la salida resulta ser OTRO Powershell:
En este caso el Powershell se le escapa a Salvador, pero sí que reconoce otro código en base64 que con toda probabilidad sea el payload malicioso final. Una nueva decodificación nos da como resultado un fichero que ya está en binario, por lo que es muy posible que éste sea el shellcode final que se ejecuta en la memoria.
Es momento de sacar un conejo de la chistera: scdbg.exe, un emulador que permite lanzar un shellcode y trazar las llamadas a la API de Windows que realiza. Y vaya si nos da resultados:
Todo el código que Salvador ha analizado se reduce más o menos a “de la forma más sigilosa posible, conéctate a esa IP y ejecuta en memoria lo que te descargues”. Salvador no puede evitar en cierta medida alabar la técnica de los atacantes: el malware real de los atacantes está escondido en esa IP, y pueden cambiarlo a voluntad siempre que quieran (al coste de una petición HTTPS cada vez que se arranca el equipo, eso sí).
Solo por curiosidad, Salvador vuelve a subir este último fichero a MARIA a ver qué pasa:
Los atacantes lo saben, y Salvador ahora lo ve muy claro: la triple capa de ofuscación en Powershell les funciona a los atacantes MUY bien.
Pero lo más importante que ha sacado Salvador de su análisis es otro IOC “pata negra”: el servidor C2 (Command & Control) de los atacantes. Esta dirección IP puede buscarse tanto en los logs del cortafuegos como en los del proxy para comprobar si tenemos más equipos comprometidos en la Organización.
Paso 6: Análisis de memoria RAM
Mientras Salvador apalea el malware, Ángela se centra en el análisis del volcado de la memoria RAM recuperada del usuario. Una de las ventajas del análisis de memoria es que TODO está en la memoria (conexiones, procesos, ficheros abiertos…), siendo además el lugar en el que menos trucos pueden usar los atacantes para esconderse.
En el análisis de memoria RAM los forenses están divididos entre Volatility y Rekall cual Madrid/Barca, Coca-Cola/Pepsi o concebollismo/sincebollismo, pero Ángela es del Volatility Team. El primer comando que ejecuta es netscan para mostrar las conexiones de red del equipo (lo bueno del análisis de memoria es que no solo están las conexiones actuales del equipo sino que se pueden encontrar algunas conexiones pasadas).
La IP 2.16.65.18 corresponde a Akamai… pero la IP 101.132.122.231 parece un ISP de China, algo MUY sospechoso. Ángela se guarda esa IP (por ahora un potencial IOC), y continua lanzando el comando pstree para obtener un árbol de los procesos del sistema.
A los ojos entrenados de Ángela este resultado es como decir “ha sido el mayordomo, en el salón de fumar y con el candelabro”. Los puntos de la izquierda indican quién es el padre de cada proceso, por lo que según esa imagen ha pasado lo siguiente:
- Explorer.exe (el explorador de Windows, el proceso base que gestiona la sesión de usuario) lanza Outlook.exe (el cliente de correo).
- Outlook.exe lanza iexplore.exe (el navegador Internet Explorer), lo que induce a pensar que el usuario ha recibido un correo con un enlace y ha pinchado sobre el mismo.
- Iexplore.exe ha lanzado wscript.exe (algo que ya sabíamos) ejecutando el JavaScript contenido en felicidad.js.
- Wscript.exe ha lanzado rundll32.exe (posiblemente el código malicioso final).
- Rundll32.exe ha lanzado cmd.exe (o el código malicioso final o alguna herramienta de apoyo para los atacantes).
Habiendo localizado el posible código malicioso, Ángela ahora quiere saber si los atacantes han conseguido de alguna forma elevar privilegios (porque ahora mismo tendrían que estar como usuarios pelados ya que han entrado a través del usuario pepe.contento). Para ello puede hacer uso del comando privs, que nos devuelve todos los privilegios que tienen los procesos en ejecución:
Ángela busca por el PID 1100 (el del proceso rundll32.exe), y blasfema en arameo al encontrar que posee el privilegio “SeDebugPrivilege” (que permite al poseedor hacer un debug del resto de procesos del sistema, algo que puede ser usado para inyectar código en su memoria).
¿Cómo han conseguido los atacantes elevar privilegios en el equipo, si la política de parches de seguridad es más rígida que una institutriz inglesa de 1920? (y ella lo sabe perfectamente porque fue ella la que la implantó).
La respuesta la tiene el propio CAU: al parecer algún alto cargo se quejó de que el HappiNator 32.1 no sincronizaba correctamente con la YupiNube en una cuenta de usuario normal, así que sin decirle nada a Seguridad de la Información, les dieron a todos privilegios de administrador local. El facepalm y las ganas de matar de Ángela podrían constituir un meme si alguien hubiera capturado ese momento…
Ángela toma nota del hallazgo y continua con el análisis de la memoria. Otra táctica que suele dar muy buenos resultados es hacer uso del comando malfind (que como su nombre indica encuentra malware en el equipo a base de buscar código inyectado en otros procesos). Suele dar una buena cantidad de falsos positivos pero en este caso queremos saber si el PID 1100 (rundll32.exe) aparece entre los resultados. Afirmativo:
Malfind nos vuelca el resultado del código inyectado en una carpeta, por lo que podemos coger ese trozo de memoria y subirlo a MARIA (podríamos subirlo a VirusTotal porque al ser un trozo de memoria las posibilidades de que los atacantes lo estén monitorizando son prácticamente nulas, pero no vamos a correr riesgos). MARIA parece tener bastante claro a lo que nos estamos enfrentando:
Al parecer tenemos en memoria una preciosa sesión de Meterpreter, herramienta exótica que casi ningún atacante suele emplear para entrar en sistemas ajenos (sarcasmo OFF). Sabiendo que puede ser un Meterpreter, Ángela sabe cómo confirmarlo a través del comando strings de Volatility.
El comando strings necesita de la ejecución previa del comando strings.exe (ajeno a Volatility), que lo que hace es extraer las cadenas de texto de un fichero binario (como un volcado de memoria). Con este resultado Volatility es capaz de cruzar esas cadenas de texto y asociarlas a procesos, lo que nos viene de perlas a la hora de un análisis forense.
El proceso lleva su tiempo (10-15min en un ordenador moderno), pero tiene su recompensa. Ángela sabe que una sesión de Meterpreter hace uso de stdapi, por lo que puede hacer una búsqueda rápida y tener una confirmación del malware:
Si recordamos que el PID del rundll32.exe era 1100, tenemos suficientes pruebas como para condenar al equipo a un formateo sumario por compromiso total.
Ángela se pone en la piel del atacante: tengo una sesión de Meterpreter en el equipo, y además no necesito elevar privilegios porque ya soy administrador local ¿Qué haría? Obtener credenciales. Y si recordamos lo que vimos en la revisión de los logs, teníamos nada más y nada menos que una sesión iniciada de administrador de dominio. Un sudor frío recorre la espalda pensando en lo que podría hacer un atacante con acceso total al MINAF…
La búsqueda en las cadenas de texto del temido Mimikatz no ofrece resultados. Conociendo los comandos más habituales de Meterpreter, Ángela busca unas cadenas alternativas como “kiwi” (la nueva forma de llamar a Mimikatz) o “incognito” (el módulo de impersonación), encontrando un hit en el último:
No es una evidencia 100% fiable de que se ha ejecutado incognito, pero es lo mejor que se puede conseguir. Ángela sospecha que los atacantes han seguido este camino:
- A través de la ejecución del enlace malicioso han logrado una sesión de Meterpreter en el sistema.
- Los atacantes han comprobado que la cuenta en la que han aterrizado tiene privilegios de administrador, por lo que han lanzado Mimikatz y robado las credenciales del administrador de dominio.
- Teniendo esas credenciales han usado el módulo incognito de Meterpreter para iniciar una sesión con privilegios de administrador de dominio.
Si damos un paso atrás al incidente y pensamos en cómo hemos detectado el incidente (el acceso a varias cuentas de correo de altos cargos a través del webmail) y el plazo de tiempo que han tenido los atacantes (unas pocas horas), la teoría más probable es que los atacantes se hayan hecho con los hashes de las contraseñas de dichos usuarios (ya sea a través de un ataque de DCSync o robando directamente el fichero NTDIS.dit de un controlador de dominio).
Con los hashes en la mano, un ataque vía Rainbow Tables o con Hashcat debería de proporcionarles a los atacantes las contraseñas en un plazo razonable de tiempo dependiendo de la fortaleza de las contraseñas (que Ángela sabe que no son 123456, pero que se podrían mejorar) y del hardware disponible (que si en AWS tienen semejantes bicharracos de 16 GPU no debería de ser un problema).
Otra opción sería ver si los atacantes han comprometido el servidor de correo Exchange, pero la cree menos factible ya que los atacantes llevan menos de 6h en el sistema (y además accedieron a la cuenta de pepe.contento nada más obtener sus credenciales vía Mimikatz).
De esta fase del análisis Ángela se queda con una foto más o menos borrosa (como suelen ser buena parte de estos análisis, nunca se tienen todos los datos) de lo sucedido y con un posible IOC: la IP 101.132.122.231, que puede volver a cruzarse con los logs tanto del cortafuegos como del proxy de navegación.
Le queda únicamente comprobar la vía de entrada del malware y ver si es capaz de capturar el malware original, algo que veremos en la siguiente entrada…
