Posts Tagged ‘malware’

Volatility VS Citadel 1.3.4.5

Como analista forense y de malware siempre he sido un gran fan de Volatility, la ya archiconocida herramienta de análisis de memoria escrita en Python que sigue creciendo día a día. Por ese motivo, desde que hace algo más de un año vi el artículo de Michael Ligh en su blog sobre la extracción de las claves de cifrado de ZeuS siempre había querido probar eso mismo con otras familias de malware.

En este caso he elegido Citadel, que es una de las variantes de ZeuS que más guerra están dando desde la filtración del código fuente del mismo. En concreto la versión 1.3.4.5 que, aún no siendo la última, nos servirá de base para las siguientes versiones (Aunque se rumorea que la 1.3.5.1 podría ser la última que veamos) u otras familias.

Cuando juntamos Volatility con Yara, la potencia disponible para el procesamiento automático de malware se multiplica. En ambas cosas se basa zeusscan2, uno de los plugins resultantes del artículo comentado anteriormente. El mismo hace uso de reglas Yara sobre la memoria de una máquina infectada para detectar y acceder a las zonas de memoria susceptibles de contener la información que nos interesa extraer del binario. Para ello es necesario un exhaustivo análisis previo sobre la familia a “automatizar”, que en este caso, al tratarse de una variante de la familia ZeuS de sobra conocida y documentada, el trabajo se limitará a detectar las diferencias existentes con la misma.

De entrada sabemos que ZeuS 2.X contiene la siguiente información embebida en el binario:

  • URL de descarga inicial del fichero de configuración
  • Clave RC4 usada para descifrar el fichero de configuración
  • Información sobre la localización del binario y la configuración en la máquina infectada

Los dos primeros datos se encuentran en una zona del binario codificada mediante XOR con los bytes contenidos al comienzo de la última sección del fichero PE, mientras que la última es una zona cifrada mediante la clave RC4 con una estructura fija (En adelante nos referiremos a ello como el “objeto mágico”, para seguir la convención usada en el plugin para Volatility de ZeuS).

Nota: En el caso de ZeuS existe una segunda clave RC4 contenida en la última estructura comentada, pero dado que Citadel carece de ella, no es relevante para el objetivo del artículo.

De esta forma el flujo de extracción y procesamiento de los datos que buscamos sería algo como:

  1. Localización de la configuración embebida
  2. Decodificación de la misma mediante un XOR con los bytes situados al comienzo de la última sección del fichero PE
  3. Extracción de la URL de descarga de la configuración y la clave RC4
  4. Localización y decodificación del “objeto mágico”
  5. Extracción de los datos restantes

Ahora que sabemos la base sobre la que se asienta Citadel, podemos estudiar las diferencias para adaptar el plugin a la nueva familia. Las similitudes (a nivel de binario al menos) son más que las diferencias, así que una vez entendido lo anterior, los cambios no revisten demasiada complicación.

La principal diferencia viene marcada por el cifrado usado en los ficheros de configuración descargados, que pasa de RC4 a AES, pero para el “objeto mágico” se mantiene RC4. Dicha clave AES no está contenida en el binario como tal, sino que es calculada en tiempo de ejecución de la siguiente forma:

RC4(md5(BO_LOGIN_KEY))

La BO_LOGIN_KEY o binary key, se trata de una clave de 16 bytes en hexadecimal que sí está contenida en el binario y que además de para el cálculo de la clave AES se usa para la comunicación con su panel de control, por lo que, a la localización de la configuración embebida y el “objeto mágico”, hemos de añadir la de dicha clave “hardcodeada”.

Al flujo anterior habría que añadirle por otro lado:

  1. Localización de la BO_LOGIN_KEY
  2. Cálculo de la clave AES

Con todo esto, elegimos el siguiente código desensamblado para generar las nuevas reglas Yara que nos ayuden a localizar las variables comentadas en memoria:

8BEC                                  MOV EBP,ESP

83EC 0C                             SUB ESP,0C

8A82 00010000                  MOV AL,BYTE PTR DS:[EDX+100]

8845 FE                              MOV BYTE PTR SS:[EBP-2],AL

8A82 01010000                  MOV AL,BYTE PTR DS:[EDX+101]

8845 FD                             MOV BYTE PTR SS:[EBP-3],AL

8A82 02010000                  MOV AL,BYTE PTR DS:[EDX+102]

B9 801A1300                      MOV ECX,131A80                                                   ; BO_LOGIN_KEY

8845 FF                              MOV BYTE PTR SS:[EBP-1],AL

E8 BEF2FFFF                    CALL 0015BC16

———————————————————————————

56                                        PUSH ESI

BA 54050000                      MOV EDX,554                                                          ; Embedded configuration length

52                                        PUSH EDX

68 602A4000                       PUSH pyko.00402A60                                             ; Embedded configuration

50                                        PUSH EAX

E8 47E30100                      CALL pyko.004290C1

8B0D B4394300                 MOV ECX,DWORD PTR DS:[4339B4]

030D 943D4300                 ADD ECX,DWORD PTR DS:[433D94]

8BF2                                   MOV ESI,EDX

2BC8                                  SUB ECX,EAX

———————————————————————————

68 03010000                      PUSH 103

8D85 10FBFFFF               LEA EAX,[LOCAL.316]

50                                       PUSH EAX

8D85 FCFEFFFF              LEA EAX,[LOCAL.65]

50                                       PUSH EAX

E8 B4E20100                     CALL pyko.004290C1

B8 1C010000                     MOV EAX,11C

50                                       PUSH EAX

68 283C4300                     PUSH pyko.00433C28                                               ; Magic object

Una vez que llegamos al punto del flujo de procesamiento en el que se decodifica el “objeto mágico” nos encontramos con una estructura con un aspecto similar al siguiente:

Este objeto, al igual que pasaba con ZeuS 2.X, tiene una longitud fija en la mayoría de los casos y una estructura como la que sigue:

{‘_ZEUS_MAGIC’ : [ 0x11C, {

'struct_size' : [ 0x0, ['unsigned int']], \

‘guid’ : [ 0x4, ['array', 0x30, ['unsigned short']]], \

‘guid2′ : [ 0x7C, ['array', 0x10, ['unsigned char']]], \

‘exefile’ : [ 0x9C, ['array', 0x14, ['unsigned char']]], \

‘keyname’ : [ 0xEC, ['array', 0xA, ['unsigned char']]], \

‘value1′ : [ 0xF6, ['array', 0xA, ['unsigned char']]], \

‘value2′ : [ 0x100, ['array', 0xA, ['unsigned char']]], \

‘value3′ : [ 0x10A, ['array', 0xA, ['unsigned char']]], \

‘guid_xor_key’ : [ 0x114, ['unsigned int']], \

‘xorkey’ : [ 0x118, ['unsigned int']], \

}]}

Por lo tanto ya disponemos de todo lo que buscábamos:

Espero que este ejemplo ayude a ver un poco más claramente las posibilidades que nos ofrecen Yara y Volatility para el análisis y automatización de malware cuando trabajan en conjunto.

El plugin para la versión 1.3.4.5 lo podéis encontrar aquí. Michael Ligh lo ha integrado, además, con las versiones del plugin para ZeuS 1 y 2.X, por lo que en adelante estará disponible también en la rama principal de Volatility, aunque no activado por defecto; para su uso habrá que lanzar Volatility de la siguiente forma:

$ python vol.py –plugins=contrib/plugins/malware citadelscan1345 -f ….

En cuanto a la versión 1.3.5.1, el proceso a seguir sería similar excepto porque habría que localizar una nueva clave “hardcodeada” y tener en cuenta que el tamaño y estructura del “objeto mágico” cambia en cada muestra.

Feliz análisis!

Follow me on Twitter: @smvicente

Plugin de Ayuda en Línea MSDN para OllyDbg / Immunity Debugger

Hola a todos. En esta ocasión voy a presentar un plugin para el depurador OllyDbg / Immunity Debugger que va a facilitar la tarea de realizar la ingeniería inversa de un binario de Windows.

¿Qué es OllyDbg?

OllyDbg es un clásico depurador de binarios a bajo nivel para el sistema operativo Windows. Según muchos, es la herramienta ideal para hacer ingeniería inversa de programas de los que no disponemos del código fuente (por ejemplo, malware), y también es muy utilizado en el mundo del cracking.

Una de las características más atractivas que tiene es la posibilidad de cargar plugins. La mayoría están orientados a ayudar en el desempacado de binarios protegidos y evitar la detección del depurador por parte del código malicioso que estemos analizando, aunque los hay para muchas otras tareas.

¿Qué es Immunity Debugger?

Luego de varios años sin actualizaciones, y tras múltiples exploits publicados que no han sido corregidos por el autor, la empresa Immunity decidió comprar el código fuente para actualizarlo y mejorarlo. Así nació Immunity Debugger, que parece estar destinado a reemplazar al viejo Olly, especialmente en el terreno del exploiting que es donde se están concentrando más las nuevas características y los nuevos plugins.

¿La pega? Que los viejos plugins de OllyDbg en general ya no funcionan más. Si se dispone del código fuente se pueden actualizar e incluso hacer que funcionen en ambos. Si no, la cosa está más complicada, aunque hay una herramienta que ayuda bastante.

El plugin que presento hoy funciona correctamente en ambos programas. :)

¿Para qué sirve este plugin?

OllyDbg ya tiene sus años, y aunque se sigue usando no siempre ha envejecido con gracia. ;) Uno de sus puntos flacos es el soporte de ayuda de Windows.

Me explico. Al analizar un binario en Windows normalmente veremos código ensamblador y llamadas a funciones de la Win32 API, que es la interfase de programación de bajo nivel en Windows. Las funciones de la API son muchas y es imposible memorizarlas todas, por lo que es imprescindible poder consultar la documentación de Microsoft para saber qué hace cada una, qué parámetros llevan, etc.

Ahora bien. OllyDbg ya permitía desde sus comienzos consultar la documentación de Microsoft gracias a un archivo llamado “WIN32.HLP“, que venía con la SDK de Windows NT, y contenía la documentación más completa y detallada… de aquel entonces. Pero ya pasaron varias versiones de Windows y unos cuantos años, Microsoft dejó de dar soporte a ese manual para dar paso a la documentación online de la MSDN (Microsoft Developer Network), y lo que ocurre ahora es que al consultar la ayuda desde el Olly muchas de las cosas que buscamos no aparecen. :(

Este plugin viene a llenar ese vacío. Al instalarlo, cuando OllyDbg intente acceder a WIN32.HLP para mostrar la documentación, el plugin lo intercepta y lanza el navegador web en la página correspondiente de la documentación online. :)

¿Cómo se instala este plugin?

Es simple, hay que descargar el archivo zip, extraer el plugin (OllyMSDN.dll) y copiarlo a la carpeta de instalación del depurador.

En OllyDbg esta carpeta suele ser “C:Program FilesOllyDbg” (en castellano C:Archivos de ProgramaOllyDbg”).

En Immunity Debugger la carpeta suele ser “C:Program FilesImmunity IncImmunity Debugger” (en castellano nuevamente reemplazar “Program Files” por “Archivos de Programa”).

El siguiente paso es cargar el depurador, y desde el menú “Help” ir a la opción “Select API help file”. Allí hay que, o bien seleccionar el viejo WIN32.HLP (aunque no se vaya a usar), o al menos un archivo cualquiera que se llame exactamente igual (el contenido da lo mismo). El nombre es importante, porque es la manera en que el plugin se da cuenta de que el usuario está intentando consultar la documentación de Microsoft y no, digamos, la ayuda del propio OllyDbg.

Una vez hecho esto, ya está completa la instalación.

¿Cómo se usa este plugin?

Se usa exactamente igual que el viejo archivo WIN32.HLP. Es decir:

Para acceder a la documentación, vamos al menú “Help” y seleccionamos la opción “Open API help file”.

Para ver la ayuda de una llamada API en concreto, hacemos click derecho sobre la línea de código ensamblador y seleccionamos la opción “Help on symbolic name”.

¿Dónde consigo este plugin?

Se puede comprar por el módico precio de… nah, mentira, es completamente gratuito! :)

Se descarga siguiendo este link: OllyMSDN.zip

El archivo zip contiene el binario precompilado para Windows y el código fuente, liberado bajo la licencia GPL v2. El fuente compila bajo Visual Studio 2008, no lo he probado con otros compiladores.

Bueno, eso es todo por hoy. Que les aproveche! :)


Sígueme en Twitter: @Mario_Vilas | Linkedin: http://es.linkedin.com/in/mariovilas

El módulo de ZeuS/Spyeye para Android se hace mayor

En el último post relacionado con el módulo móvil usado por ZeuS y Spyeye para atacar el segundo factor de autenticación, se comentaba la escasa evolución que dicho tipo de muestras había tenido desde su aparición en septiembre de 2010. Pues bien, parecen habernos oído porque hoy se analizará lo que parece ser el primer paso en la evolución de una aplicación maliciosa que simplemente interceptaba y reenviaba SMS’s, hacia un bot con mayores posibilidades.

En primer lugar se puede apreciar, como se ha pasado de una innumerable lista de permisos solicitados a la hora de realizar la instalación, a una mucho más depurada con la clara intención de llamar menos la atención sobre la víctima:

Además añade nuevos permisos para realizar acciones como la instalación de aplicaciones o la lectura de la agenda del teléfono. También se ha pasado de una instalación y afectación genérica, a una específica de una determinada entidad:

La aplicación se hace pasar por un sistema de token bancario de la entidad objetivo. Esto, acompañado de las inyecciones correspondientes en el PC de la víctima, será de ayuda de cara a la ingeniería social necesaria para convencer a dicho usuario de instalarla y además, mantenerla. Y, aunque mantenga la capacidad de captura y reenvío masivo de SMS’s, puede filtrarlos definiéndolo en el fichero XML que usa a modo de configuración:

De cara a la serialización XML se hace uso de “Simple Framework” y, aparte de la nueva capacidad para leer y enviar datos de la agenda, la más interesante es que parece capaz de recibir una serie de comandos, convirtiéndolo en un bot:

En cuanto al panel de control, ha sufrido importantes mejoras y, mantiene la separación respecto de aquellos que controlan la infección del PC, posiblemente porque el módulo móvil se está “comercializando” de forma independiente:

Dentro del mismo dispone además de un builder para generar cada “apk” específica contra una determinada entidad:

Por lo tanto nos encontramos ante los primeros indicios de un desarrollo más serio, y una posible comercialización, detrás del hasta ahora “módulo bancario” de otros troyanos de escritorio; para buscar una cierta independencia a través de la incorporación de nuevas funcionalidades. Desde aquí deseamos que, el hasta ahora mal llamado “ZeuS para móviles”, no llegue a hacerse realidad y acabe convirtiéndose en eso mismo.

Follow me on Twitter: @smvicente

Análisis de malware en Android: Atacando al segundo factor de autenticación

Desde que en Septiembre de 2010 se detectara la primera muestra de ZeuS que realizaba un esquema de fraude de tipo MitMo (Man in the Mobile), se han apuntado al carro también Spyeye y últimamente Ice IX. En las dos primeras, el módulo móvil empleado para capturar las credenciales del segundo factor de autenticación basado en móvil partía de una misma base y, excepto sutiles diferencias, la evolución había sido escasa.

En el caso que nos ocupa, nos hemos hecho con una muestra para Android procedente de una inyección aparecida en la banca online de un usuario después de hacer login en ella, convenciéndolo de que instalara una aplicación de seguridad, usando para ello un mensaje como el siguiente:

#### informa: para la instalación de un programa de criptografía gratis en su teléfono, utilice la siguiente dirección http://#########.net/cripto.apk

Durante el análisis dinámico se observa cómo el mismo se instala haciéndose pasar por una solución de seguridad, y no intenta ocultarse en ningún momento:

La misma, únicamente muestra un código de activación para ser asociada presumiblemente con la cuenta de la entidad del usuario. Dicho código se trata del ID del teléfono (IMEI en GSM y el MEID o ESN para CDMA), como veremos más adelante.

La estructura del paquete APK es la siguiente:

El certificado autofirmado contiene la siguiente firma:

En el fichero XML (AndroidManifest.xml) que define los permisos necesarios por la aplicación para ejecutarse llaman la atención algunos de ellos como los siguientes:

Como se puede apreciar, requiere permiso para recibir y enviar SMS, así como consultar y modificar el estado del teléfono, entre otros.

La estructura de la aplicación Java es la siguiente:

En la clase “MainActivity” puede apreciarse el código empleado para mostrar el mensaje con el supuesto ID de activación:

La funcionalidad principal está reunida en la clase “SmsReceiver”, que es la encargada de interceptar y reenviar los SMS’s entrantes a un servidor controlado por el atacante. A continuación se muestran algunas de las variables usadas para almacenar la información capturada, así como el servidor donde se envía dicha información:

Una de las principales novedades respecto a versiones anteriores, es que la URL está codificada, aunque de una forma muy simple, de tal forma que eliminando los caracteres “q”, “-“ y “=” de la cadena, es posible obtenerla.

Como vemos, en todo este tiempo desde su primera aparición, la complejidad de este tipo de muestras apenas ha aumentado, lo que quiere decir que sigue siendo igual de efectivo y cumpliendo con el objetivo marcado por los defraudadores. Al final, si algo funciona, ¿Porqué cambiarlo?

———-

Follow me on Twitter: @smvicente

Malware Stepper

Existen muchas estrategias de análisis de malware, en este post voy a reflejar una técnica de análisis dinámico que facilita bastante las cosas, voy a llamarla stepping aunque en realidad se basa más en traces que en steps.

El stepping consiste en ejecutar todo el código del malware paso a paso, hasta identificar las llamadas “peligrosas” a la API de Windows, en principio no puede realizar ninguna actividad malévola sin llamar ninguna api, otra cosa es que llame api´s no documentadas, o utilice técnicas de subir a ring0 mediante desbordamientos de buffer, interrupciones o como sea.

El stepping tiene dos problemas:

1. La velocidad, steppear un binario es muy muy lento, para que os hagáis una idea, hacer un stepping de un malware de pocos Kbytes puede tardar varios días.

2. El segundo problema es que realice hooks, infecciones, salto a ring0 .. de manera que los datos interesantes se descifrarán desde otro proceso.

El segundo punto es una limitación de esta técnica, aunque se puede parar el stepping ante un intento de infección, hookeo etc … y continuar manualmente con análisis estático u otros steppings de otros procesos. Esto es solo una técnica y no una herramienta valida para analizar todos los malwares.

En cuanto al lenguaje a utilizar, me interesa combinar el stepping automático con análisis manual, de manera que debería desarrollarse en un lenguage de scripting para ollydebug, immunity, radare etc.

Lo más rápido que he encontrado es ollyscript, más que el ollypython y immunity python, lógicamente porque es más ligero, de hecho, curiosamente el tracing desde ollyscript, va más rápido que manualmente desde ollydebug, cuando el motor es el mismo incluso el ollyscript tiene alguna capa más.

Para acelerar el stepping realicé una comparación de eip con la dirección a partir de la cual se enlazan las librerías, fuera de librerías procedía con step into y en librerías con step over.
En el caso de encontrar un bucle, realicé una rutina llamada saltaBucles que lo detecta, breakpointea las salidas y ejecuta para pasar el bucle de la forma más rápida.

Salir de los bucles y hacer step over en las librerías aceleraba bastante el stepping, no obstante lo que voy a publicar aquí es una versión basada en trace, trace into en el módulo del malware y trace over en los demás módulos, que también es relativamente rápido, ollyscript realiza los trace y los animate de forma bastante eficiente, sobretodo los trace.

El siguiente punto a tener en cuenta, es hasta que punto dejar fluir la ejecución, que apis consideramos peligrosas.
En mi caso tenía un objetivo concreto que es obtener las urls, que algunos casos van cifradas y en otros no.

Tal como he comentado, existen otras técnicas de intercepción de api como el ring3 hooking, el ring0 SSDT patching etc …
Las api que decidí interceptar mediante stepping son las siguientes, describo muy brevemente la razón:

Para detectar api-loaders, infecciones, cambios de permisos en páginas para desempacar o descifrar código:

kernel32.OpenProcess
kernel32.CreateProcess
kernel32.CreateFileA
kernel32.CreateFileW
kernel32.CreateDirectoryA
kernel32.CreateRemoteThread
kernel32.CreateRemoteThreadEx
kernel32.DeleteFileA
kernel32.DeleteFileW
kernel32.IsDebuggerPresent
kernel32.VirtualProtect

Crear claves de registro:

ADVAPI32.RegCreateKeyExA
ADVAPI32.RegCreateKeyExW
ADVAPI32.RegSetValueEx

Conexiones y aperturas de puertos, posible control remoto, o envio de credenciales:

WS2_32.connect
WS2_32.bind
WS2_32.ntohs
WS2_32.inet_addr
WS2_32.send
WS2_32.sendto

Acceso a webs ftps, posibles envíos de credenciales:

wininet.InternetWriteFile
wininet.InternetReadFile
wininet.InternetReadFileEx
wininet.InternetOpen
wininet.InternetOpenUrl
wininet.InternetFindNextFile
wininet.InternetCrackUrl
wininet.InternetCreateUrl
wininet.InternetConnect
wininet.HttpOpenRequest
wininet.HttpQueryInfo
wininet.HttpSendRequest
wininet.HttpSendRequestEx
wininet.GopherOpenFile
wininet.FtpCommand
wininet.FtpCreateDirectory
wininet.FtpDeleteFile
wininet.FtpFindFirstFile
wininet.FtpGetCurrentDirectory
wininet.FtpGetFile
wininet.FtpOpenFile
wininet.FtpPutFile
wininet.FtpRemoveDirectory
wininet.FtpRenameFile
Winhttp.WinHttpConnect
winhttp.WinHttpCrackUrl
winhttp.WinHttpCreateUrl

Ejecución de comandos o para malwares multi multistaged:

SHELL32.ShellExecuteA
SHELL32.ShellExecuteW
SHELL32.ShellExecute

Posible convert-channel mediante las netapi:

netapi32.NetServerEnum
netapi32.WNetEnumResource
netapi32.NetShareEnum

Se podrían incluir más api interesantes como por ejemplo la cryptoapi, pero tampoco quería cargar mucho el bucle.

En cuanto al motor de traceo condicional, se basa en lo siguiente:


engine:
ticnd "eip >= 10000000"
cmp eip, 0
je theend

// Ha entrado en una api, si es una api sospechosa, se loguea y finaliza la ejecución, si no se loguea y continua el traceo

tocnd "eip < 10000000"
jmp engine

En la ventana de log de ollydebug, se puede ver las api que van siendo llamadas, softwares tipo strace/ltrace para windows hay varios, sin embargo este script puedes pararlo cuando quieras de forma manual o programada.

El stepper detecta una llamada interesante y para su ejecución para que el analista pueda continuar de forma manual.

En este caso el fichero se abre a si mismo, posiblemente en alguna parte del fichero no mapeada por el linker, se encuentran datos cifrados. Abrirse a si mismo es una operación típica en virus tipo overlay, por ejemplo un infector de ficheros elf que hice en el 2006: infR3.s

Podéis descargar el OllyScript aquí: Stepper – OllyScript for Malware Análisis

Conclusiones:

* No es la forma más rápida ni automática de analizar, es un script de ayuda al análisis manual del malware para situaciones puntuales, que ha de ser combinado con análisis manual.
* Un buen complemento es scripts de búsqueda de patrones estáticos, que espero publicar en otro post.
* Esto ejecuta el malware!!, buguroo no se hace responsable del uso inapropiado de este script, recomendamos utilizar máquina independiente o virtual.