Webcast: Análisis de Malware con Sysinternals

Estándar

Hola a tod@s!

La semana que viene, más concretamente el martes 24 de Julio a las 16:00, tendré el gusto de dar otro Webcast sobre análisis de Malware orientado principalmente a Administradores de Sistemas.

Como en el otro Webcast, se verán las capacidades de las herramientas de SysInternals así como sus novedades añadidas y funcionalidades que ayudarán a un administrador TI en la búsqueda y análisis de Malware. El guión completo más la URL de conexión lo tenéis en el siguiente párrafo.

En este Webcast se mostrará una primera aproximación sobre cómo los administradores de sistemas e investigadores de seguridad se pueden enfrentar a amenazas de tipo APT utilizando para ello las herramientas de Microsoft SysInternals.
Para esta sesión, se utilizará como demostración la reciente aparición de un Malware que ha dado mucho que hablar dentro de la comunidad de seguridad, así como en equipos de gobierno y fuerzas de seguridad del Estado: el Malware FLAME.
Con la información obtenida en esta sesión se podrá comprobar cómo los analistas de sistemas, así como administradores de seguridad, pueden utilizar estos datos para mitigar la amenaza utilizando para ello una arquitectura basada en Microsoft.

URL de conexión: https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032521432&Culture=es-ES&community=0 

Os espero por allí!

Salu2 a tod@s!!

 

Webcast sobre Flame o {ponga-amenaza-aquí} para administradores IT

Estándar

Hola a tod@s!

Después de todo lo que se ha hablado del infame FLAME, poco de momento se puede hablar más, hasta que no salgan nuevos hallazgos sobre el tema. Lo que si es un hecho es que parece que este Malware ha sido el nexo de unión entre piques de soluciones Antimalware. Por un lado tenemos el post que publicó Mikko de F-Secure, en el que explícitamente nombra la amenaza de FLAME como una especie de LAMERADA con la originalidad de un “matón de colegio”.

Kaspersky, por su parte, no ha entrado en la pelea, y sigue deleitándonos con muy buenos artículos centrados en sus investigaciones sobre la supuesta amenaza (Que es lo importante), la cual, poco a poco, se nos va desvelando.

Por la parte de Bit9, han decidido realizar un Webcast (Ya terminado), en el que hacen conciencia sobre lo vulnerables que podemos ser ante este tipo de amenazas.  Son ellos también, los que han realizado un reporte “light” sobre FLAME, explicando en líneas generales (y comerciales) en qué consiste esta amenaza de tipo APT.

Yo por mi parte no voy a entrar a valorar si la metodología de ataque es buena o mala, si el código utilizado incorpora librerías no nativas del sistema, lo que convierte al Malware en un “gordito”, o si se basa en código de “otros”. Eso se lo dejo a los verdaderos profesionales del tema. Por otro lado, y puestos a ser un poco mamoncete podríamos decir que…

Mucho lamer, malware gordito y lento, pero nadie ha sido capaz de detectarlo en 4 años jaja

Desde Microsoft han reservado dos Webcast para hablar sobre amenazas de tipo persistentes (APT) que se puedan presentar y coexistir en una arquitectura Microsoft. Y me han pedido que si podía dar estas dos sesiones y aportar mi humilde opinión.

Como no quería entrar en debates sobre este tipo de amenazas, si son peligrosas o no, me he decantado por intentar aportar una visión más “administrativa” e intentar dar respuesta a ese colectivo tan olvidado de la mano de Dios… Los sufridos Administradores de Sistemas.

Así que estos dos Webcast , vayan dedicados a estos profesionales como la copa de un pino, que en multitud de ocasiones tienen que aguantar a todo un colectivo de personas con multitud de problemas…. Aclamando que el suyo es “el más importante”…

El primer Webcast irá dirigido al análisis de un Malware a través de las herramientas de SysInternals, así como otras herramientas menos conocidas, pero igual de interesantes y útiles. Todo el desarrollo de este Webcast, se complementará con demostraciones prácticas con este Malware, así que podréis ver, cómodamente desde vuestro curro, casa, bar, playa, etc..,  cómo utilizar herramientas nativas de Spectra para realizar esta primera valoración en un análisis dinámico de Malware.

El segundo Webcast va dirigido a descubrir, haciendo uso de la arquitectura existente, y con la información anterior, si la amenaza se ha extendido a otros equipos de la organización. Para ello hablaremos de Active Directory, PowerShell y por qué no…. De BATCH!! (Lorenzo no te lo pierdas!! :P)

Tanto en el primer Webcast como en el segundo, comentaré y referenciaré la ingente cantidad de buenos post redactados por compañeros de profesión como son Sergio de los Santos, Yago, Luis Delgado, Marc Rivero (Seifreed), el Maligno, etc…

Así que aprovecho también desde aquí para felicitarlos a todos ellos por tan buena información, así como el trabajo de redactarlo y publicarlo para todos. Sin estos artículos y sin la ayuda de alguno (Gracias Seifreed!) el trabajo de comprensión y adaptación me hubiese tomado el doble o triple de tiempo.

Webcast. Análisis de Flame con SysInternals (04 de Julio 16:00 horas)

En este Webcast daremos una primera visión de cómo administradores de sistemas e investigadores de seguridad, se pueden enfrentar a amenazas de tipo persistente (Advanced Persistent Threat), utilizando para ello las herramientas de Microsoft SysInternals.

Para la primera sesión, se utilizará como demostración la reciente aparición de un Malware que ha dado mucho que hablar dentro de la comunidad de seguridad, así como en equipos de gobierno y fuerzas de seguridad: el Malware FLAME.

Con la información obtenida en esta primera sesión, se podrá comprobar como los analistas de sistemas, así como administradores de seguridad, pueden utilizar estos datos para mitigar la amenaza utilizando para ello una arquitectura basada en Microsoft.

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032518505&Culture=es-ES&community=0

Webcast. ¿Amenazas a mí? Sácale partido a tu arquitectura (05 de Julio 16:00 horas)

A través de la información recogida y analizada en el Webcast anterior (Análisis de Flame con Sysinternals), se procederá a mitigar una posible amenaza, utilizando para ello la propia infraestructura Microsoft que posea un cliente específico. A lo largo de la sesión, se dará una visión global y ejemplos específicos como por ejemplo Active Directory o PowerShell.

https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032518510&Culture=es-ES&community=0

Para teminar este post, y haciendo alusión a la palabra LAMER, utilizada para referenciar una amenaza, termino con unas palabras que me dijo un Administrador de Sistemas: “Una amenaza, por pobre que sea, es dañina por la propia definición de la palabra amenaza. No hay que olvidar que nosotros nos debemos a nuestros usuarios”.

Os espero la semana que viene!

Salu2 a tod@s!!

Análisis de Flame parte III. La conspiración

Estándar

Hola a tod@s!

Disclaimer!!

Esta entrada sólo refleja mis pensamientos impuros, sin ninguna connotación técnica, y que sólo alimentan mi desquiciada mente. Dicho queda…

En el primer artículo, se vió cómo NO había que reproducir la muestra, si no era en un entorno totalmente “liviano” y sin ningún tipo de protección. Después, pasamos al segundo artículo, en el que se refleja la primera ejecución del bicho. Qué hace, cómo lo hace, y qué toca.

Hoy me gustaría pasar a un tema más personal, más íntimo, por lo que quedáis avisados de lo que no ha podido filtrar mi mente, y que hoy expongo aquí.

Revisando el código de uno de los módulos que generaba Flame, se encuentran partes que hacen referencia a Mutex creados por el mismo.

Imagen 1.- Referencia a Mutex en código Flame

Esto ni de lejos es nuevo, pero me ayudó bastante a la hora de poder hacerme una idea de cuántos procesos se encontraban infectados a la hora de una primera ejecución de Flame.

A estos Mutex, se le añade presumiblemente el PID del proceso que se encuentra infectado, tal y como puede verse a través de la herramienta, también de Sysinternals, WinObj.

Imagen 2.- Procesos implicados en la ejecución de Flame

En el caso de la imagen anterior, los procesos asociados son Explorer.exe, Services.exe y Winlogon.exe…. Casi nada…

Analizando dicha muestra, también me he encontrado con partes de código, que si bien no son idénticas a las encontradas en Stuxnet, poco le faltan… Este código, se aprovecha de vulnerabilidades antiguas y pequeños “trucos” que tiene el sistema operativo. Uno de ellos es la auto-ejecución en unidades extraíbles, y el otro es la posibilidad de jugar maliciosamente con enláces simbólicos en sistemas de ficheros NTFS.

Imagen 3.- Código de explotación muy parecido (por no decir igualito) al utilizado por Stuxnet

La versión bajo la que estoy haciendo las pruebas, creo que es la misma (MD5:bdc9e04388bda8527b398a8c34667e18) en la que se basan la mayoría de informes y noticias de Internet.

La versión que yo estoy utilizando, NO SE EJECUTA bajo ningún concepto si existen ciertas aplicaciones monitorizando el sistema. Ni al siguiente reinicio ni nada. Es más, ni lo intenta.

A la hora de realizar con éxito la primera ejecución, éste pregunta insistentemente por versiones específicas de productos de Kaspersky, tal y como se puede ver en la imagen extraída de Process Monitor.

Imagen  4.- Peticiones a productos específicos de Kaspersky

Lo curioso de esto, es que prácticamente en todas las muestras que va generando Flame, se encuentran peticiones de este tipo de producto, pero no de otras soluciones de seguridad.

Imagen 5.- Llamadas a directorios que generan productos de Kaspersky en porciones de código Flame

Si a todo lo anterior le sumamos a que parece ser que en el código de Flame ha aparecido un comentario un tanto “jocoso”, da que pensar. La noticia me ha llegado vía Full Disclosure. Yo, que no soy ruso, ni tengo ni pajolera idea del idioma local de allí… Interpreto un “Mentiroso, gracias Kaspersky”…. Que por favor me lea un Ruso y acabe con mi agonía….

Siendo no conspiranoico, puedo pensar que debido a que Kaspersky fue uno de los primeros en investigar Stuxnet, Duqu y ahora Flame, es posible que los creadores del bicho pusieran especial énfasis en productos de Kaspersky.

Otro punto a favor que le otorga la catalogación de Malware diseñado para la ciberguerra, es que todavía no se sabe muy bien si Stuxnet fue obra de la administración Bush, o por el contrario fue el Mossad… Mientras que algunos opinan que Stuxnet es obra de Bush/Obama, otros piensan de manera diferente.

Mucha gente opina que estamos asistiendo a un nuevo concepto de ciberguerra, tal y como apunta José Rosell, desde Security At Work, y que no se nos cuenta toda la información. Esto último, algo bastante lógico y normal, dentro de los cánones de la contención de masas y demás.

Que el Mossad e Irán siempre estén hostiándose… Es algo que, desgraciadamente, lo tomamos como normal hoy día…

Pero bueno… Qué carajo sabré yo, que todavía me emociono cuando veo The Goonies….

Un saludo a tod@s… Y siento la entrada de hoy!!

 

 

 

Análisis de Flame parte II. La primera ejecución

Estándar

Hola a tod@s!

En el anterior artículo hablábamos de cómo NO habíamos podido ejecutar la muestra de Flame debido a algún problema técnico. La pregunta que terminé haciéndome era que por qué otros sí habían conseguido ejecutarla y yo no. Tocaba tirar de recursos!

En toda la documentación que he leído, se comenta acerca de los diferentes cifrados que utiliza Flame. Debido a que mis nociones de ingeniería inversa y reversing de Malware son bastante pobres, opté por analizar la información que se encontraba en el momento de la ejecución de Flame. Así que recurrí a la vía forense, y realicé un volcado de memoria segundos después de la carga de Flame a través de rundll32.

Como no quería errar en el intento, provoqué un BSOD en la máquina, a través de la herramienta de SysInternals NotMyFault.

El porqué de utilizar esta herramienta, y no otra, es debido a que quería “simular”, en la medida de lo posible, un error a través de un controlador, y no realizar una petición de volcado directamente desde alguna herramienta forense. Con esta acción, lo que intento es pasar desapercibido ante controles internos monitorizados por el Malware.

Una vez extraído el volcado de memoria, utilicé la archiconocida Volatility, para extraer el contenido de la memoria del proceso RUNDLL32, y rezar para ver algún contenido que me hiciese comprender el porqué de mi error.

Analizando el espacio de memoria utilizado por RUNDLL32, se hizo la luz…..

Parece ser, que en el código de Flame se encuentra una lista de aplicaciones consideradas “peligrosas” para el Malware. Si alguna de estas aplicaciones se encuentra en ejecución en el sistema, éste automáticamente se para.

Este control, parece que se establece a través de varias órdenes. Una de ellas se puede visualizar a través de la siguiente imagen:

Imagen 1.- Código malicioso

Existen otras clases muy interesantes. Algunas de ellas son las siguientes:

  • LUA.CLAN.THREATENING_PROGRAMS
  • HEADACHE.BoostConsumer
  • GADGET.BEETLEJUICE_DATA_COLLECTOR_CONSUMER

La lista de aplicaciones es importante. Como podéis ver en la imagen siguiente, se encuentran numerosas aplicaciones conocidas por analistas y administradores de sistemas.

Imagen 2.- Algunas aplicaciones listadas por Flame

Como curiosidad, en una de las listas aparecen algunas soluciones de Antimalware. Imagino que Flame hace uso de estas rutinas para poder explotar mejor algunas de las vías de infección que utiliza.

Imagen 3.- Soluciones Antimalware listadas por Flame

Qué fallaba al intentar analizar la muestra?. Fallaba en uno de los trucos más viejos utilizado por el Malware, ya que yo tenía corriendo en la máquina Wireshark para capturar paquetes, y Process Monitor (procmon.exe) para monitorizar llamadas de sistema. Todo ello arrancado y esperando a la ejecución de Flame. FAIL!

Por otra parte, si se detecta algo “extraño”, Flame tiene opciones de auto destrucción. Según los analistas, esta clase es ejecutada de forma remota, y se concentra todo en una función llamada SUICIDE, la cual parece que está destinada a parar las acciones del Malware, así como a destruir posibles evidencias futuras.

Imagen 4.- Código SUICIDE

Una vez revisada de nuevo toda la información, me dispuse a renombrar toda aplicación que tuviese en la máquina para monitorizar la muestra, y así sí…. Flame inicia el vuelo sin importarle el idioma ni el sistema operativo.

Una vez arrancado, éste comprueba si existe el directorio MSSecurityMgr, situado en el directorio Program Files\Common Files. Si no existe, crea este directorio.

Imagen 5.- Creación del directorio Shared

Una vez creado el directorio, genera una serie de ficheros, los cuales se muestran en la siguiente imagen:

Imagen 6.- Ficheros generados por Flame

Para poder ver con mayor claridad quien se encuentra tocando estos ficheros, he utilizado la herramienta de Sysinternals Process Explorer, buscando las referencias (handle) al mismo. Para este paso, también se podría haber utilizado la herramienta, también de Sysinternals, Handle.

Imagen 7.- Proceso services.exe con handle a mscrypt.dat

Una vez generado el directorio y los ficheros, se empiezan a generar consultas al árbol de registro HKLM, en concreto a la siguiente clave:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SeCEdit

Después de realizar varias consultas, carga bibliotecas específicas relacionadas con la configuración de seguridad del sistema, tales como NTMARTA.DLL y SAMLIB.DLL, y modifica las claves de registro DefaultIdentifier y LastUsedIdentifier.

Imagen 8.- Modificación de la configuración de seguridad

A los pocos minutos de la ejecución, y viendo la cantidad de información que va “depositando” el bicho, intento identificar algunos ficheros generados por Flame, utilizando para ello la herramienta de Sysinternals sigcheck. Un extracto de la salida se puede ver en la siguiente imagen:

Imagen 9.- Verificación de firma con Sigcheck

Durante todo el tiempo que se estuvo ejecutando Flame, éste generó multitud de ficheros temporales en el directorio TEMP del sistema (C:\Windows). Estos ficheros, en un principio, no se encuentran manejados por ningún proceso en particular, y sólo se utilizan en un instante determinado.

Imagen 10.- Creación de ficheros temporales utilizados por Flame

Según el documento inicial de análisis de Flame, uno de los ficheros temporales, concretamente el fichero ~HLV473.tmp, contiene una lista de los procesos que se encuentran en ejecución. En el documento, se muestran secuencias de datos que hacen alusión a un formato de compresión llamado ZLIB.

Analizando este fichero, efectivamente se encuentran este tipo de secuencia de datos, por lo que me pongo a jugar con la biblioteca ZLIB de Python.

A la hora de generar un fichero con ZLIB en python, es posible indicar el grado de compresión con un valor numérico que va desde el 0 al 9. Generando un fichero con el valor 9 (Compresión máxima), las secuencias de datos que se muestran en el nuevo fichero, coinciden con las del fichero ~HLV473.tmp.

Aplicando un sencillo script en Python (En batch no he podido! :P), es posible “ver” ciertos datos almacenados en este fichero.

Imagen 11.- Extracción de información comprimida en ZLIB

La forma de implementarlo ha sido bastante sencilla. Para extraer todas las secuencias de datos que coincidan con ZLIB y los métodos de compresión (Mínimo al Máximo) he implementado un FOR del 0 al 9 y generado 10 ficheros. Una vez realizado este paso, he extraído la secuencia inicial (Magic), y he implementado un cutre-script para poder leerlo. El cutre código, aquí:

#-------------------------------------------------------------------------------
# Name:        Flame Zlib
# Purpose:
#
# Author:      Silverhack
#
# Created:     11/06/2012
# Blog:   https://windowstips.wordpress.com
# Reference: www.crysys.hu/skywiper/skywiper.pdf
#-------------------------------------------------------------------------------
import zlib
import sys
from optparse import OptionParser
from optparse import OptionGroup

magic = ["\x78\x01","\x78\x5e","\x78\xda","\x78\x9c"]
offset = 0

def flame(fich):
    try:
        fread = open(fich,'rb').read()
        for i in reversed(magic):
            try:
                init_offset = offset
                while 1:
                    init_offset+=fread[init_offset:].index(i)

                    if init_offset >=0:
                        try:
                            print zlib.decompress(fread[init_offset:])
                            break
                        except:
                            init_offset+=1
            except:
                pass

    except IOError:
        print "No such file or directory...."
        sys.exit()

def main():
    #set up command-line options
    parser = OptionParser(description="Flame Zlib file read | https://windowstips.wordpress.com", version="FlameZlibRead 0.1")
    StandardExtractGroup = OptionGroup(parser, "Read Section", "Read files and search common ZLIB payloads")
    StandardExtractGroup.add_option("-f","--file",default=False,help="File name to perform search", action="store_true",dest="filename")
    parser.add_option_group(StandardExtractGroup)
    #grab options
    (options, args) = parser.parse_args()
    if options.filename:
        fflame =  args[0]
        flame(fflame)

if __name__ == '__main__':
    main()

Hasta la próxima!
Referencias

http://msdn.microsoft.com/en-us/library/bb499271(v=winembedded.51).aspx

Análisis de Flame parte I. El FAIL

Estándar

Hola a tod@s!

Esta semana dedicaré una serie de entregas al análisis del Malware Flame. Espero que estas engregas sirvan para guiar al analista en su investigación, y que no cometa los mismos errores que estoy cometiendo yo!

Desde principios de este mes se conoce de la existencia de un malware que está ocupando todas las portadas de los blogs más importantes dentro del panorama de la seguridad. Personalmente, me enteré de este “elemento” leyendo una entrada en Hispasec escrita por el genial Sergio de los Santos, y que me mantuvo entretenido buena parte de un trayecto en metro.

Como me picaba la curiosidad, esa misma noche, me puse a buscar alguna muestra del Malware, y fijar algún día en la agenda para “jugar” con la misma.

Antes siquiera de “jugar”, me encuentro con otra interesantísima entrada de Luis Delgado, en la que explica básicamente el funcionamiento del bicho, así como un script en python, el cual determina una infección, en base a consultas al registro, así como a ficheros residuales que deja el propio Malware.

Ese mismo día, y desde el blog de AlienVault, Jaime Blasco nos deleita con una interesantísima entrada, hablando esta vez, de la posible “edad” del Malware. La muestra analizada por Jaime (MD5:bdc9e04388bda8527b398a8c34667e18), coincide con la que me dispongo a utilizar yo.

Días más tarde, me vuelvo a encontrar con otra noticia del mismo elemento, pero esta vez escrita por mi querido y siempre mordaz Yago. En esta entrada, habla de Flame y los certificados digitales, lanzando una primera aproximación acerca de la función principal de esa firma digital.

Una vez leída y releída toda la documentación existente sobre el Malware Flame, me he dispuesto a realizar un pequeño análisis del mismo, sólo por morbosa curiosidad, y de momento, este es el resultado.

Según el documento “oficial”, en el que se explica los entresijos de este bicho, si se desea reproducir la infección en una máquina para su análisis, se pueden realizar dos operaciones, las cuales, ofrecerían el mismo resultado.

La primera, y la más rápida, es ejecutar el fichero a través de línea de comandos, registrando el OCX a través de la herramienta rundll32.

Imagen 1.- Intentando arrancar Flame

La otra manera de arrancar la muestra, es ayudando al Malware a auto-ejecutarse en el próximo reinicio. Para llevar a cabo esta acción, se indica en el documento que Flame se carga como un proveedor de autenticación, tal y como se puede ver en la siguiente imagen:

Imagen 2.- Detalles del Malware Flame

Para realizar esta acción, en el documento se especifica la clave de registro sobre la cual hay que adjuntar la muestra, para su posterior carga.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

La máquina sobre la que me dispongo a realizar las pruebas de infección es un Windows XP Service Pack 3 en español 32 bits. El método de infección que escojo es el primero, es decir, registrando el Malware a través de línea de comandos, a través de rundll32.

Una vez ejecutado el comando, la herramienta rundll32.exe, logra arrancar el OCX. Observando el comportamiento a través de Process Monitor, me encuentro con que la primera acción que realiza el Malware, es establecer un valor aleatorio en la clave SEED de la siguiente ruta de registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG

El valor que reside en la clave SEED, es el valor que utiliza la CRYPTO API de Windows, a la hora de generar números aleatorios.

Las siguientes acciones derivan en la consulta de drivers instalados, así como consultas al directorio TEMP del Sistema.

Una vez que realiza todas estas consultas, el Malware genera un Log en el directorio Windows llamado Ef_trace.log. Un aspecto curioso de esta acción, me lo encuentro a la hora de comprobar cómo Flame cambia el Timestamp del fichero, lo que dificultaría su detección en un análisis forense, por ejemplo.

Imagen 3.- Cambio de timestamp de fichero

Acto seguido, realiza operaciones de escritura sobre el mismo, tal y como se puede comprobar en la siguiente imagen:

Imagen 4.- Escritura de fichero Ef_trace.log

A la hora de abrir este fichero, me encuentro con información cifrada, tal y como apuntan varios blogs de seguridad, que hacen mención al fichero en sí.

Imagen 5.- Datos cifrados en Ef_trace.log

El siguiente movimiento de Flame es preguntar por los proveedores de autenticación, fecha y hora del sistema, parámetros relativos al nombre de máquina y configuración de red. Y cuando ha obtenido toda la información…. SE PARA!!

Como os podréis imaginar, mi cara de FAIL era un poema. Así que empiezo a tirar de documentación, para comprobar si había errado en algún movimiento. Las siguientes 3 ejecuciones se comportan de la misma manera a lo descrito en anteriores párrafos.

Analizando cada entrada arrojada por Process Monitor, me encuentro con una que me parece sospechosa, la cual se encuentra ya documentada por anteriores analistas. Cuando se intenta inicializar Flame, éste realiza una consulta a un directorio concreto, para ver si se encuentra un fichero. En la siguiente imagen podréis comprobar cómo la consulta devuelve un resultado de NOT FOUND.

Imagen 6.- Consulta a controlador wavesetup3.drv

Como no sabía por donde tirar, elucubro la posibilidad de que pueda haber alguna incompatibilidad debida al idioma. Si el Malware está diseñado para Windows XP, puede haberla, ya que en versiones anteriores a Windows Vista, el idioma viene integrado en el Kernel.

Instalado el sistema en inglés, y ejecutando la muestra sobre éste, se comporta de la misma manera que el anterior. ¿En qué falla? ¿Qué estoy haciendo mal?

Tras una pausa (en la que me cagué en todo…), tiro de teléfono y llamo a Seifreed, buscando alguna orientación. Aprovecho para darle las gracias desde aquí, ya que en este paso fui mucho más rápido gracias a él.

Marc me comentó que él sí lo había podido lanzar sin ningún problema, y que su máquina de pruebas era un Windows XP SP2 en Spanish, lo cual me dejó totalmente sin ideas. En su ejecución, el malware había realizado conexiones y se había propagado con éxito en el equipo. Ni problema de idioma, ni Service Packs, ni hostias…..

Mañana publicaré la segunda parte de este relato, y descubriremos algunos mecanismos de seguridad que realiza Flame para poder ejecutarse en un entorno “controlado”….

Saludos a tod@s!!

Referencias

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx

www.crysys.hu/skywiper/skywiper.pdf

Información de Malware. ¿A través de DNS?

Estándar

Hola a tod@s!

Hoy día, y debido a que cada año crece más todo lo relativo a vías de infección, han proliferado muchos servicios de consulta de Malware, y todo lo relacionado con la muestra.

Servicios como VirusTotal y ThreatExpert son buenas referencias a tener en cuenta, en tanto y cuanto a un auditor, le caiga el “marrón” de analizar un “bicho”.

A la hora de analizarlo, y viendo como está el mercado, en cuanto a horas reales y cuantificables que se dedican a un proyecto, a un auditor le puede solucionar la papeleta el consultar este tipo de servicios, a día de hoy imprescindibles y para mi gusto perfectos, para que le den una visión global sobre qué dicen las principales casas de antivirus sobre el mismo.

Buscando proyectos relacionados con el análisis dinámiso de muestras de manera online, y habiéndome leído la gran entrada de HackPlayers sobre análisis de Malware, me encontré con un proyecto en OWASP bastante interesante. Consulta de Malware en base a un MD5 o SHA1. Si miramos esta última frase con ojo crítico, pensaremos, nada nuevo no?

La solución que se aloja en OWASP, la cual puede consultarse de manera ONLINE, permite que puedas realizar consultas en base a un MD5 o SHA1 de algún fichero “sospechoso”, pero en vez de consultar a una Web, las consultas las realizas a través de peticiones DNS, adjuntando al final del MD5 o SHA1 un sufijo DNS.

La idea en sí es simple. Tener un repositorio de HASHES relacionados con ficheros maliciosos. Pero la ejecución cambia totalmente al ser consultas a través de DNS.

Desde un punto de vista “corporativo”, las consultas DNS se permitirán, casi por obligación. Como segundo punto es la información que obtenemos al realizar las consultas. Esta información va desde el supuesto tamaño de fichero que coincide con el HASH, así como información relativa al estatus de este. Si es Malware, desconocido, bueno, etc… Una de las respuestas más curiosas, es la relativa a la certeza. En la respuesta, dan un grado, en tanto por ciento, de lo cierto de que ese HASH sea Malware o no, en función del estatus, y de lo analizado.

Según el servicio, esta base de datos es mantenida con regularidad, y analizan bastantes muestras de ficheros maliciosos.

Para realizar una consulta, lo único que necesitamos es un cliente nslookup o dig.

Si lo que necesitamos es consultar si el HASH se encuentra incluido en la base de datos, se puede realizar una consulta de tipo A. La respuesta que obtendremos, en el caso de que el HASH se encuentre en la BBDD, es de 127.0.0.11.

En el caso de que se necesite extraer la información relativa al HASH, habrá que realizar la consulta, pero esta vez de tipo TXT, y añadiendo un sufijo específico, hash.sapao.net.

Imagen 1.- Consulta de HASH malicioso a través de DNS

Aunque desconocía por completo que se pudiesen realizar consultas de HASH a través de DNS, en la página del proyecto, existen enlaces a sitios y comunidades que ofrecen lo mismo. En el caso de Team Cymru’s, ofrecen el mismo servicio de consultas de HASH a través de DNS, operando de la misma manera que la anterior.

SANS, por su parte, tiene otro servicio muy similar, que, aunque no tan potente como los anteriores, tienen algo que lo hace bueno, y es que mantienen una base de datos de ficheros catalogados en WhiteList, por lo que, si se realizan consultas, se puede cotejar si un fichero es malicioso, o por el contrario se encuentra en una lista blanca.

Realizando una prueba con el MD5 un fichero, SANS me informa de que se encuentra listado en varias ocasiones. ¿Colisión? Por la pinta del tamaño, y viendo que son ficheros en texto plano, no sé, no sé…..

Imagen 2.- Consulta realizada en NIST Hash Database

Si realizamos esta consulta, pero a través de NSLOOKUP, la respuesta que obtendríamos sería la siguiente:

Imagen 3.- Consulta de HASH a través de NSLOOKUP en SANS

Curiosa forma de consultar por ficheros maliciosos no?

No sólo de la password vive el HASH!

Saludos a tod@S!

 

 

A la caza del mutante, parte IV

Estándar

Parte I

Parte II

Parte III

Parte V

Hola a tod@s!

En esta penúltima parte, vamos a realizar la búsqueda de MUTANT (MUTEX), a través de la herramienta volatility, y realizando para ello un análisis forense offline.

Para poder realizar esta búsqueda con éxito, el gran Andreas Schuster implementa un módulo para volatility, a través del cual,  y resumido en pocas palabras, realiza una búsqueda de la cadena Mut? En memoria paginada y no paginada.

Imagen 1.- Búsqueda de cadena Mut?

 El resultado es increíble, extrayendo no sólo la dirección de memoria y el nombre del Mutant, si no también información interesantísima, como por ejemplo el identificador de proceso (Client ID) que lo tiene referenciado.

Imagen 2.- Aplicación del módulo MutantScan en Volatility

En la próxima y última entrega, analizaremos la memoria offline, e intentaremos buscar evidencias, partiendo de los mismos principios que el estudio de Andreas Schuster. Lo único que vamos a cambiar esta vez, será la herramienta. En vez de utilizar Volatility Framework, se utilizará la herramienta WinDBG (Debugging Tools for Windows), y realizando las consultas de forma manual.

Saludetes!!

Referencias

Searching for Mutants

_KMUTANT Structure

Poolfind (MDSN)

A la caza del mutante, parte III

Estándar

Parte I

Parte II

Parte IV

Parte V

Esta vez, vamos a utilizar las herramientas Process Explorer y Handle, de Sysinternals, para la correcta búsqueda de Mutants (MUTEX) en el sistema.

Siempre que un objeto se crea o se abre, una referencia hacia éste, es creada. Esta referencia, llamada HANDLE, estará asociada con un proceso, a través de una tabla llamada HANDLE TABLE.

Process Explorer, permite, entre otras características, el poder visualilzar estas entradas a través de su interfaz gráfica. Para ello, tendremos que activar el panel inferior, y que sólo nos muestre la referencia.

Imagen 1.- Mostrar handle en Process Explorer

Una vez que el panel inferior se encuentra activo, es fácil encontrar las referencias a los MUTANT (MUTEX), tal y como se muestra en la siguiente figura:

Imagen 2.- Mutant visualizado con Process Explorer

Si se necesita automatizar el proceso en forma de línea de comandos, la herramienta Handle, de Sysinternals, permitirá extraer todas las referencias, incluyendo las del directorio \BaseNamedObjcts. Para ello, habrá que pasarle el parámetro –a, para que incluya todos los handle. Si se desea que pregunte por el Security Descriptor, incluiremos también el parámetro –u.

Imagen 3.- Mutant descubierto a través de Handle

En el próximo post, realizaremos esta tarea, utilizando para ello volatility framework, en un análisis offline.

Saludetes!

 

A la caza del Mutante. Parte II

Estándar

Parte I

Parte III

Parte IV

Parte V

La forma más sencilla de buscar mutantes (MUTEX) en nuestro sistema y en tiempo real, es utilizando las herramientas de SysInternals. Para ello, la primera herramienta que utilizaremos será WinOBJ, la cual nos permitirá visualizar, de forma jerárquica, el manejador de objetos (Object Manager) de Windows. Cada recurso de Windows, se encontrará catalogado en un espacio de nombres. Un recurso puede ser la memoria RAM, una entrada de registro o un directorio, por ejemplo.

Cada objeto administrado por el Object Manager tendrá una estructura determinada. Bajo esta estructura, se encontrará un nombre que identifique al objeto en sí (Object Name) y un Security Descriptor, el cual aportará información sobre los derechos de acceso del objeto.

Los MUTANT (MUTEX),  entre otros objetos, se encuentran catalogados en el directorio (Object Directory) \BaseNamedObjects. Dentro de este directorio, podremos realizar consultas gráficas para encontrar fácilmente Mutex maliciosos.

Imagen 1.- Acceso a objetos MUTANT a través de WinObj

A través de esta utilidad, se pueden realizar consultas al Security Descriptor, para conocer qué derechos de acceso y dueño, tiene este objeto.

Imagen 2.- Permisos de Objeto MUTANT

En la próxima entrega nos centraremos en la búsqueda de estos objetos a través de otras herramientas de Sysinternals como Process Explorer o bajo línea de comandos con Handle.

Referencias

Object Manager (PDF)

Object Manager (PPT)

Object Manager (Wikipedia)

A la caza del Mutante. Parte I

Estándar

Parte II

Parte III

Parte IV

Parte V

Un mutante, es como Windows llama de forma común a un Mutex. Un mutex ayuda a la hora de acceder a los recursos del sistema, o como mecanismo que ayude a que sólo una instancia de la aplicación se encuentre corriendo en el sistema.

Las aplicaciones pueden crear mutantes con un nombre específico o con un nombre en particular. Si una segunda instancia de la aplicación es ejecutada en el sistema, ésta intentará crear un mutex sin éxito, lo cual obligaría a la aplicación a terminar.

A menudo este tipo de técnicas son utilizadas por malware de diverso tipo para prevenir múltiples infecciones de una misma cepa. Y a menudo también nos podemos encontrar con aplicaciones que crean Mutex con la finalidad de proteger al sistema operativo. Entre los diferentes mecanismos de protección que puedan ofrecer, uno de ellos es la creación de Mutex a priori utilizados por Malware. Con esto intentan prevenir que algún tipo de virus pueda ejecutarse bajo esta técnica.

Utilizar la búsqueda de Mutex maliciosos como única técnica de detección de Malware es algo muy pobre, debido a que es muy fácil modificar este parámetro. Una prueba de ello lo tenemos en el configurador del archiconocido Poison Ivy.

Imagen 1.- Nombre de Mutex generado automáticamente por Poison Ivy

Es por ello que, unido a mi morbosa curiosidad, y dado el incremento de este tipo de técnicas en la programación de Malware, que dedicaremos 5 entradas sobre las técnicas y herramientas existentes para buscar con éxito mutantes (MUTEX) creados por aplicaciones.  Para ello, iremos realizando las operaciones desde lo más fácil, a lo más difícil, siempre desde mi punto de vista. La búsqueda de Mutex las realizaremos desde el punto de vista de:

  • Herramientas de Sysinternals (Análisis en Vivo)
  • Volatility Framework (Análisis Offline)
  • WinDBG (Debugging Tools de Windows) (Análisis Offline)

Nos vemos en la segunda parte!!