Como es bien sabido, los ciberdelincuentes no escatiman recursos a la hora de ingeniarse nuevas estrategias y metodologías de ataque que les permitan lograr sus objetivos. La utilización de documentos maliciosos «maldocs» no es una técnica nueva, sin embargo, sigue siendo bastante popular cuando de propagar malware se trata. En esta ocasión realizaremos el análisis de un documento malicioso adjudicado al actor APT28 Fancy Bear. Este análisis tiene como propósito recopilar la mayor cantidad de información posible sobre la funcionalidad del documento malicioso.
Introducción del APT
En este artículo veremos cómo realizar la extracción de una carga útil desde un recurso externo al código plasmado en la macro del documento malicioso; detallando el procedimiento de tal manera que pueda comprenderse la estrategia de ataque implementada por el actor.
Nombre de Archivo: APT28Hospital.doc
Tipo de Archivo: Open Office XML
Número Mágico: PK
Actor: APT28 Fancy Bear
SHA256: A4A455DB9F297E2B9FE99D63C9D31E827EFB2CDA65BE445625FA64F4FCE7F797
Análisis APT
Antes de comenzar a analizar el fichero APT28Hospital.doc es importante dedicar tiempo al proceso de clasificación. Para ello pueden ser utilizadas diferentes técnicas (se puede llegar desde el punto A al punto B, a través de diferentes caminos – cada uno elige cuál es el camino más conveniente según sus propias necesidades particulares)
Iniciamos la valoración inicial.
Procedemos a ver las cadenas del fichero (revelan información muy valiosa):
Como se puede apreciar en las evidencias anteriores, las cadenas revelan información muy valiosa, como por ejemplo, posibles rutas de ficheros que componen el PK y nos permite tener un indicio de la composición del fichero.
Procedemos a validar los metadatos del fichero:
La información que obtenemos a partir de la extracción de metadatos nos puede servir para comenzar a construir la línea temporal y la clasificación del fichero malicioso, ya que evidencia datos tan importantes como el nombre de usuario que creó el fichero, la extensión del fichero, la última vez que fue modificado, el usuario que modificó por última vez el fichero, etc.
Nota: se puede observar que el apartado HLinks contiene texto codificado en Base64, también nos revela que el tipo y la extensión del fichero es .docm.
Una vez que validamos el tipo de fichero y extraemos los metadatos, podemos inferir que el fichero en cuestión puede ser descomprimido. Para analizar su contenido procedemos a descomprimir el fichero (esto puede ejecutarse con la herramienta que usted prefiera):
Como ya sabemos que existe un recurso dentro del fichero que se llama HLinks, debemos proceder a buscar en qué lugar del fichero se encuentra exactamente dicho recurso, para hacer esto podemos utilizar alguna herramienta que nos permita realizar la consulta que necesitamos (en este caso utilizaré zipgrep para buscar la cadena en cuestión):
Esta consulta nos revela el fichero en el cual se encuentra la cadena HLinks, esta cadena se encuentra en el fichero individualizado en la siguiente ruta: APT28Hospital.docm/docProps/app.xml; ahora sabemos dónde se encuentra exactamente el recurso.
Ahora debemos extraer el código de VBA que se encuentra en la macro. Para extraer el código que compone la macro existen varias técnicas (utilicen la que más les guste), optaré por eliminar la protección del fichero docm para tener acceso directamente al código de VBA en el fichero mencionado.
Para hacer esto, basta con que cambiemos la extensión al fichero malicioso. Por este motivo modificamos el nombre de dicho fichero a APT28Hospital.docm, lo que nos brindará la posibilidad de utilizar 7-zip para abrir el fichero.
Ubicamos el fichero vbaProject.bin (este es el fichero que contiene el proyecto VBA). Luego hacemos una copia del mismo fuera del contenedor, para editarlo posteriormente.
— Aquí nos tomamos una buena taza de café — .
Ahora con nuestro editor hexadecimal preferido, vamos a buscar la cadena DPB y la vamos a reemplazar por la cadena DPX.
Guardamos los cambios y reincorporamos el fichero vbaProject.bin al paquete APT28Hospital.docm para sobrescribir el original.
Ahora abrimos el fichero APT28Hospital.docm (OJO NO HABILITAR LAS MACROS) presionando la siguiente combinación de teclas: Alt+F11. Una vez aplicada la combinación de teclas aparecerá el siguiente diálogo y presionamos “si”.
Acto seguido aparecerá el siguiente error, el cual aceptaremos:
Después de aceptar el cuadro anterior, aparecerá MVBA para aplicaciones, lo que debemos hacer es presionar clic derecho sobre el objeto ThisDocument y luego ir a las propiedades del objeto. Dentro de la pestaña protección introducimos una nueva contraseña.
— Ahora podemos beber otro sorbo de café —
Ya tenemos acceso al código directamente desde la herramienta de Microsoft:
Como se puede observar, tiene una función para decodificar b64, el cual es llamada al momento de ejecutar el documento, de manera oculta para interactuar con uno de los xml y extraer el valor marcado abajo, para luego decodificarlo en b64.
Vamos bien, ahora todo es mucho más claro. ¿Recuerdan los metadatos al inicio y el valor de “HLinks”?
Ahora sabemos que la carga útil se extrae desde el recurso xml, una vez decodificada se guarda con el nombre de “user.dat” en %APPDATA% con la característica de oculto una vez escrito en el disco.
En esta otra parte del código podemos ver cómo se ejecuta la carga útil.
Podemos ver que utiliza WMI -Windows Management Instrumentation. Es una tecnología que permite la automatización de tareas y la gestión de objetos dentro del sistema operativo. Según Microsoft, WMI se implementó en Windows 95 y NT 4.0, por lo que es bastante vieja. Es popular entre los administradores de red, pero en los últimos años ha «ganado el corazón» de los desarrolladores de malware.
A modo resumen indicamos lo siguiente:
- Winmgmt es el servicio WMI dentro del proceso SVCHOST que se ejecuta bajo la cuenta «LocalSystem«.
- («Win32_ProcessStartup «, » SpawnInstance_) lo que hace es llamar a la API responsable de crear un nuevo proceso en el sistema operativo con una ventana oculta y luego pasa la ejecución de rundll32.exe como parámetro a la variable “Path” teniendo como valor %APPDATA%/user.dat.
Esta es una técnica simple y eficiente para instalar malware en la máquina de un usuario desprevenido pero se puede proteger fácilmente.
Ahora vamos a extraer el payload, esto lo podemos hacer de muchas maneras. En este caso incorporamos el contenido del recurso HLinks en un fichero para luego decodificarlo y pasarlo a su extensión correspondiente.
Ahora validamos con el comando file que todo esté en orden.
Ahora que tenemos la carga útil, comienza de nuevo el proceso pero en una situación diferente y bajo un nuevo escenario.
A menudo verá autores de malware que distribuyen su código malicioso como DLL en lugar de archivos ejecutables. Estas son algunas de las razones (entre muchas otras) por las cuales los atacantes implementan su código malicioso como DLL:
- Una DLL no se puede ejecutar haciendo doble clic, por lo que necesita un proceso de host para ejecutarse (la hace más difícil de detectar).
- Al distribuir el código malicioso como una DLL, un autor de malware puede cargar su DLL en cualquier proceso, incluido un proceso legítimo como Explorer.exe, winlogon.exe, etc. Esta técnica le da al atacante la capacidad de ocultar las acciones de un malware.
- Toda la actividad maliciosa realizada por el malware parecerá originarse en un proceso válido del host.
- Al inyectar una DLL en un proceso que ya se está ejecutando, el atacante tiene la capacidad de persistir en el sistema.
- Cuando una DLL es cargada por un proceso en su espacio de memoria, la DLL tendrá acceso a todo el espacio de la memoria del proceso, lo que le permitirá manipular la funcionalidad del proceso. Por ejemplo, un atacante puede inyectar una DLL en un proceso de navegador y robar credenciales redireccionando su función API.
- Analizar una DLL no es sencillo y puede ser complicado en comparación con el análisis de un ejecutable.
El siguiente paso es extraer la mayor cantidad de información sobre la DLL de manera estática, comenzamos por los metadatos.
Esta extracción nos arroja un dato muy revelador y bastante importante al momento de clasificar la muestra, la marca de tiempo de compilación «Time Stamp«. También nos muestra la dirección de EntryPoint que es la dirección del punto de entrada del programa (es donde el código comienza a ejecutarse).
Tenemos como fecha probable de compilación «2017/07/03 4:14:28 AM – 5:00».
La mayoría de las muestras de malware desempaquetan o descargan una DLL y luego la cargan en el espacio de memoria de otro proceso.
Nota: En la mayoría de los casos después de cargar la DLL, el dropper/loader se autoelimina. Como resultado, al realizar la investigación y el análisis del malware es posible que solo encuentre la DLL.
Pasamos a analizar la DLL, vamos a utilizar la herramienta del sistema operativo rundll32.exe. Cabe anotar que para utilizar la herramienta se debe ser muy preciso al momento de pasar los parámetros a la DLL; recuerden que una biblioteca de enlaces dinámicos es un módulo que contiene funciones (llamadas funciones exportadas o exportaciones) que pueden ser utilizadas por otro programa (como un ejecutable o DLL). Por lo cual al momento de ejecutar la DLL se debe pasar como parámetro la exportación que se quiere analizar.
En ese orden de ideas, debemos averiguar cuáles son las exportaciones que tiene incorporadas nuestra DLL maliciosa, para poder inicializar el análisis dinámico de la muestra.
¡BINGO! Tenemos la exportación load.
Recuerden que se debe pasar la ruta completa de la DLL y separada por (,) la función como se puede ver en la imagen inferior.
Recuerden tener sus recursos de monitoreo de actividades debidamente configurados y previamente activados, antes de ejecutar la DLL.
Una vez se ejecuta la DLL con la exportación como parámetro, el malware inmediatamente hace dos consultas DNS a www.google.com y mvband.net.
Procedemos a investigar el dominio a través de su whois, no nos brinda muchos detalles como se puede apreciar en la imagen inferior.
Se recibe poca información en relación al whois debido a que almacena sus datos en su propio servidor whois. Para consultar directamente un servidor whois, debemos utilizar el parámetro -h seguido del nombre del servidor, en este caso: whois -h whois.dynadot.com mvband.net tal como se puede ver en la imagen inferior.
Ahora debemos hacer la resolución de nombre de host para mvband.net, esto lo podemos hacer con varias herramientas, incluso con el comando ping y los parámetros -i 1 para evitar enviar tráfico a los atacantes (así establecemos el tiempo de vida del paquete en 1 TTL)
Nota: si los servidores DNS asociados con el nombre de host malicioso están comprometidos por los ciberdelincuentes, ellos van a poder ver la solicitud de búsqueda y la investigación quedará expuesta.
Para finalizar obtenemos la dirección IP asociada al dominio.
Conclusión
Si bien es cierto que este tipo de técnicas se están utilizando desde hace algún tiempo, siempre será muy positivo el conocer la manera de operar que utilizan actores tan sofisticados como lo es APT28; realizar este tipo de ejercicios, nos brinda la posibilidad de enriquecer nuestra capacidad de respuesta a la hora de enfrentar este tipo de amenazas.
Por ahora llegaremos hasta aquí, espero hayan disfrutado del ejercicio.
PD: Les dejo el código en las siguientes imágenes:
😉
Andrés F. Olaya – 4Sec
