El formato de la salida es simple y puede ser analizado fácilmente por un script externo:

El análisis con grep se puede realizar cuando se usa el argumento -grepable; esto imprime los nombres de las funciones y los argumentos todo en una línea:

La tabla de identificadores únicos de módulos se imprime al final del archivo de registro:

Drltrace puede filtrar fácilmente las llamadas entre bibliotecas e imprimir solo las llamadas API realizadas desde el módulo principal (o desde el heap) de una aplicación objetivo especificando la opción -only_from_app, lo cual es muy útil en caso de aplicaciones que generan registros enormes. Para un control más granular, la opción -filter permite al usuario especificar un archivo de configuración de filtro para filtrar funciones incluidas en una lista blanca específica, o ignorar funciones en una lista negra (consulte el archivo filter.config para ver ejemplos). Drltrace también tiene varios scripts externos útiles para filtrar llamadas API para cierta biblioteca, imprimir solo llamadas API potencialmente interesantes y cadenas.

Licencia

Los módulos principales de Drltrace se distribuyen bajo BSD.

Algunos archivos necesarios para drltrace se distribuyen bajo LGPL. Consulte los archivos fuente para más detalles.

Motivación

El análisis de malware no es una tarea fácil. Los empaquetadores de software sofisticados como Themida y Armadillo, y por supuesto docenas de empaquetadores sin nombre escritos por autores de malware, junto con el cifrado de código y datos, facilitan significativamente (en algunos casos haciendo completamente imposible) la ingeniería inversa estática de dichas muestras, complicando la vida de los analistas de malware. En tal caso, el tracing de llamadas API puede reducir significativamente la cantidad de tiempo necesaria para comprender la intención maliciosa real y revelar muchos detalles técnicos sobre el código malicioso protegido.

Si bien la técnica tradicional de API-hooking se ha implementado con éxito en varias soluciones, el enfoque está bien estudiado por los autores de malware y puede ser fácilmente detectado y/o eludido. Además, estas herramientas se distribuyen como aplicaciones GUI independientes y pesadas (como productos propietarios) que a menudo no son fáciles de integrar en un flujo de trabajo de análisis de malware existente.

Si miramos el mundo de Linux, existe una herramienta maravillosa llamada ltrace. Usando un solo comando bash, podemos obtener fácilmente el rastro completo de llamadas API de un ejecutable en particular.

¿Por qué no tenemos una herramienta así (como ltrace en Linux) para Windows que además sea transparente frente a trucos anti-investigación utilizados por el malware moderno?

Resulta que existe una técnica que puede ayudarnos a tener dicha herramienta para Windows y trazar llamadas API de manera transparente al programa ejecutado. Esta técnica se llama instrumentación binaria dinámica, también conocida como DBI. DBI es una técnica para analizar el comportamiento de una aplicación binaria en tiempo de ejecución mediante la inyección de código de instrumentación.

Sin embargo, la aplicación de DBI para el análisis de malware está injustificadamente limitada a la automatización de desempaquetado y a varias pruebas de concepto para el tracing de instrucciones, bloques básicos y llamadas a funciones. Hasta donde sabemos, drltrace es la primera herramienta para tracing de llamadas API basada en DBI que se puede usar en la práctica para el análisis de malware. Proporcionamos varios ejemplos de análisis de malware en nuestra wiki donde describimos cómo drltrace permitió revelar en pocos minutos muchos detalles técnicos internos sobre muestras maliciosas sofisticadas sin siquiera iniciar IDA o un depurador.

Por qué Drltrace es increíble

• Suficientemente rápido para realizar análisis de muestras maliciosas sin ser detectado por técnicas anti-investigación basadas en tiempo.
• Soporta tanto x86 como x64 (ARM en el futuro).
• Soporta tanto Windows como Linux (macOS en el futuro).
• Soporta código automodificable.
• Soporta todos los tipos de enlace de bibliotecas (estático y dinámico).
• No detectable por enfoques anti-investigación estándar (anti-hooking, anti-debugging y anti-emulación).
• El usuario puede agregar fácilmente un nuevo prototipo de función para indicar a drltrace cómo imprimir más detalles sobre llamadas API previamente desconocidas (incluso sobre DLL no del sistema). Se utiliza un archivo de configuración externo.
• Fácil de usar y modificar para sus propios fines (sin requisitos de paquetes adicionales, sin interfaz GUI pesada).
• Código abierto, código claro y bien documentado. Puede construir y usar libremente su propia solución avanzada sobre drltrace.

Opciones de línea de comandos

Sintaxis del archivo de configuración

Drltrace admite archivos de configuración externos donde un usuario puede describir cómo drltrace debe imprimir argumentos para ciertas llamadas API.

Cada argumento de función debe separarse por |. El primer argumento es el tipo de retorno, el segundo argumento es el nombre de la función en sí y el resto son los argumentos de la función. El token __out se utiliza para marcar argumentos de salida y ___inout para marcar argumentos de entrada+salida.

Ejemplos de análisis de malware

Puede encontrar ejemplos de cómo usar drltrace para el análisis de malware complejo en nuestra página Wiki.

Visualización de registros

Para facilitar el trabajo con archivos de registro, hemos implementado un script llamado api_calls_viz.py que se puede usar para generar imágenes RGB donde cada color de píxel representa una llamada API única. Por ejemplo, la imagen a continuación representa el archivo de registro del malware WannaCry.

Las grandes áreas verdes en la imagen representan llamadas API (wcscmp/wcsicmp) que se utilizan para seleccionar archivos con extensiones interesantes (por ejemplo, docx, xls, py) para cifrarlos. Las áreas púrpura representan llamadas API (FindFirstFile/FindNextFile/CryptEncrypt) que se utilizan para enumerar y cifrar archivos y carpetas en el disco.

El script también puede generar una representación HTML de la imagen RGB generada donde se puede seleccionar cada elemento para mostrar el nombre de una llamada API.

Archivo HTML sin procesar.

Consulte el directorio de api_calls_viz para más detalles.

Cómo compilar

Puede encontrar un manual detallado en esta página Wiki.

Soporte de SO

Windows, Linux (macOS en el futuro).

Soporte de arquitecturas de CPU

x86, x64 (ARM en la lista).

Idiomas

Biblioteca estándar de C y C++ (y scripts de manejo de registros escritos en Python).

Detalles técnicos

Decidimos implementar nuestro trazador de llamadas API sobre el framework de instrumentación binaria dinámica DynamoRIO. Drltrace le pide a DynamoRIO que realice la instrumentación de la llamada LoadLibrary para poder manejar nuevas bibliotecas que el proceso objetivo esté cargando. Cuando el proceso intenta cargar una nueva biblioteca, DynamoRIO redirige el flujo de control a drltracelib.dll. A su vez, drltrace enumera las funciones exportadas en la DLL recién cargada y registra un callback especial para cada una de ellas. Por lo tanto, si el malware llama a alguna función exportada, el callback de drltrace se ejecutará antes de esta función y la herramienta podrá registrar toda la información requerida, como el nombre de la función y sus argumentos. Otro callback puede registrarse después de la función para guardar los resultados de la ejecución.

¿Por qué no Intel Pin? Decidimos usar DynamoRIO motivados por las siguientes razones:

1. El código fuente de DynamoRIO está disponible en github.com y se distribuye bajo licencia BSD, mientras que Intel Pin es un software propietario.
2. Uno de los requisitos básicos para DynamoRIO en el momento del desarrollo era la transparencia hacia el ejecutable instrumentado.
3. DynamoRIO utiliza una tecnología de instrumentación diferente basada en transformación de código, mientras que Intel PIN utiliza trampolines especiales que no son transparentes hacia el ejecutable analizado y podrían ser detectados por el malware.

Trabajo futuro

1. Si bien drltrace no es detectable por trucos anti-investigación estándar, el propio motor DBI puede ser detectado como se muestra en estos trabajos 1, 2. Hacer que DynamoRIO sea resistente a estos trucos es un camino importante para el trabajo futuro.
2. Actualmente, drltrace imprime un registro sin procesar y proporciona varios scripts para imprimir cadenas y llamadas a bibliotecas importantes. En el futuro, planeamos agregar heurísticas (probablemente aplicando reglas YARA) para poder seleccionar automáticamente el comportamiento indicativo del malware.
3. Actualmente, DynamoRIO tiene soporte beta para la arquitectura ARM; es necesario probar y portar drltrace a ARM.
4. Drltrace no admite la situación en la que el malware inyecta código en un proceso remoto. En tales casos, es posible indicarle a DynamoRIO que inyecte drltrace en todos los procesos recién creados (opción -syswide_on de drrun.exe). Sin embargo, en el futuro es necesario implementar un soporte especial en drltrace para tales situaciones.

Nuestro rastreador de problemas contiene más detalles sobre el futuro de drltrace.

Agradecimientos

Maksim Shudrak https://github.com/mxmssh

Derek Bruening https://github.com/derekbruening

Joe Testa https://github.com/jtesta