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

parseando el fichero consolidated.db

Estándar

Hola a tod@s!

Como ya conoceréis, Iphone, al igual que otros smartphones, guarda información geográfica sobre los puntos en donde ha estado “el móvil”. Entre toda esta información, también se guarda la información de los puntos de acceso WI-FI que se encuentra en “el camino”, incluyendo su MAC.

Imagen 1.- Fichero Consolidated.db

En Seguridad Apple tienen un artículo bastante interesante sobre las aplicaciones existentes en Windows, las cuales extraen esta información y las pintan en Google Maps.

En el curso de Análisis Forense de dispositivos móviles que estamos impartiendo Juan Luis García Rambla y un servidor, y en donde nos estamos peleando con una serie de dispositivos, incluyendo el Iphone, estamos analizando esta información, junto con otras muchas más.

Uno de los puntos que tenemos que tocar, es la creación de herramientas simples que consigan extraer la información necesaria en alguno de los puntos de recogida de información.

Para ello, hemos preparado algunas demos con Python. Una de ellas, es la creación de dos scripts, los cuales extraerán y pintarán en Google Maps la información del fichero Consolidated.db de un Iphone 4.

El script lo único que hace es extraer los campos latitude y longitude de las tablas CellLocation y WifiLocation.

Imagen 2.- Campos WI-FI

Para ello, hemos utilizado un Wrapper llamado PyMaps, el cual pinta el mapa añadiendo las coordenadas extraídas previamente del fichero.

Los scripts no toman ningún parámetro como entrada, y únicamente tendremos que poner en un directorio creado previamente los siguientes ficheros:

Para el script GetCoords.py, una vez lanzado, éste devolverá un fichero HTML. Una vez abierto el fichero, podremos ver algo parecido a esto:

Imagen 3.- Extracción de coordenadas

En el caso del script GetWifi.py, una vez lanzado, éste devolverá un fichero HTML. Una vez abierto el fichero, podremos ver algo parecido a esto:

Imagen 4.- Extracción de coordenadas Wi-Fi

El código de los scripts….

GetCoords.py

#Horrible Script para extraer las coordenadas del fichero Consolidated.db
#El fichero se encuentra en el directorio private/var/root/Library/Caches/locationd
#Horriblemente codeado por Silverhack
import sys, sqlite3
from PyMaps import Map, PyMap
# Creamos un mapa
NewMap = Map()
NewMap.zoom = 3
connection = sqlite3.connect("consolidated.db")
cursor=connection.cursor()
cursor.execute("SELECT Latitude,Longitude from CellLocation")
for row in cursor:
 print "La latitud es %s, y la longitud es %s" % (str(row[0]),str(row[1]))
 </p>
     # Latitud y longitud
     # Importamos de la BD consolidated a las variables
     # que posteriormente pasaremos al Script PyMaps

 latitud= str(row[0])
 longitud = str(row[1])

  # Insertamos codigo html
 pointhtml = "I see you..."

     # Anyadimos el punto al mapa
 point = (latitud, longitud, pointhtml)

 NewMap.setpoint(point)
 gmap = PyMap(key="clave", maplist=[NewMap])

 mapcode = gmap.pymapjs()
showhtml = gmap.showhtml()
print showhtml
file = open('Coordenadas.html', 'w')
file.writelines(showhtml)
# Cerramos el fichero
file.close()

GetWifi.py


#Horrible Script para extraer las coordenadas WIFI junto con su MAC del fichero Consolidated.db
#El fichero se encuentra en el directorio private/var/root/Library/Caches/locationd
#Horriblemente codeado por Silverhack
import sys, sqlite3
from PyMaps import Map, PyMap
# Creamos un mapa
NewMap = Map()
NewMap.zoom = 3
connection = sqlite3.connect("consolidated.db")
cursor=connection.cursor()
cursor.execute("SELECT MAC, Latitude, Longitude from WifiLocation")
for row in cursor:
 print "La MAC es %s, La latitud es %s, y la longitud es %s" % (str(row[0]),str(row[1]),str(row[2]))
 

     # Latitud y longitud
     # Importamos de la BD consolidated a las variables
     # que posteriormente pasaremos al Script PyMaps

 latitud= str(row[1])
 longitud = str(row[2])

  # Insertamos codigo html
 pointhtml = str(row[0])

     # Anyadimos el punto al mapa
 point = (latitud, longitud, pointhtml)

 NewMap.setpoint(point)
 gmap = PyMap(key="clave", maplist=[NewMap])

 mapcode = gmap.pymapjs()
showhtml = gmap.showhtml()
print showhtml
file = open('WiFi.html', 'w')
file.writelines(showhtml)
# Cerramos el fichero
file.close()

 Para la ejecución de los scripts, tan sólo tendremos que utilizar Python 2.6 y pysqlite.

Saludos!

Volatility Framework Installer

Estándar

Hola a tod@s!!

Hace tiempo que salió al público el estupendo trabajo de muchos investigadores que dio como resultado la herramienta Volafility Framework.

Los que me conocéis, sabéis que yo llevo dando por saco con el tema de la memoria RAM desde hace bastante tiempo. Gracias a Dios, que conforme más tiempo pasa, más información sobre este tema hay.

Yo mismo he dado algún que otro Webcast en Microsoft sobre este mismo tema, he hablado en las FIST, y en algún que otro Asegur@IT.

El Framework está escrito en su totalidad en Python. En su día, para hacer funcionar la herramienta, tanto en Windows como en Linux o MAC, tan sólo hacía falta instalar Python y vualá! Ya teníamos el Framework en funcionamiento.

Hoy día la cosa ha cambiado bastante. Existen multitud de Plugins que hacen de la herramienta una tool muy poderosa para analizar por completo la memoria RAM, pudiendo ahorrar costes en tiempo en un análisis forense corporativo o por proyecto. E incluso por diversión!!

El problema para gente que está empezando en esto, es que a día de hoy existen tantos plugins y dependencias, que instalar la herramienta desde cero, y dotarla de una funcionalidad aceptable, puede conllevar una inversión de tiempo importante.

Esto lo pensó en su día Jamie Levy (aka Gleeda), colaboradora habitual en el desarrollo de Volatility Framework, y desarrolló, entre otros impresionantes plugins, uno con la posibilidad de descargar todos los plugins de un tirón. El script para la versión 1.4 de la herramienta, e instalación bajo Linux, lo tenéis disponible aquí.

Yo he realizado mi particular script (en batch! con dos cojones!! jaja) para la total instalación de Volatility Framework, junto con todas sus dependencias. Entre las “capacidades” del Script de instalación se encuentran los siguientes puntos:

  • Descarga e instalación de Python, MinGW
  • Descarga e instalación de YARA (Gracias Hispasec!!), PYGame, PIL (Python Image Library), Distorm3
  • Descarga e instalación de Volatility Framework 1.3 (Versión estable)
  • Descarga e instalación de Plugins válidos para la versión 1.3
  • Compilación automática e instalación de diversos plugins
  • Procesado de Logs de todo lo que se descarga
  • Procesado de HASH (MD5 y SHA1) de todo lo que se descarga
  • Inclusión de rutas en PATH para dotar de máxima funcionalidad
  • Inclusión de shell de comandos con el botón derecho del ratón para facilitar el análisis (Open cmd Here)

Ahora mismo, el script es totalmente funcional para instalarlo en Windows XP/Vista/7, y, como hoy en el FTSAI nos vamos a “pelear” con la memoria y todos sus componentes, me ha parecido buena idea colgarlo por aquí.

En su día, hablando con Lympex de opensec.es, éste me pasó una versión que desarrolló para Linux, la cual todavía no he puesto en el proyecto, debido a que tiene que actualizarse. Me ha prometido que cuando la tenga funcional la colgará en el proyecto.

El proyecto está alojado en Google, y ahora sí…. No tienes excusa para seguir ampliando conocimientos en materia Forense, porque documentación hay, y facilidades también!!

http://code.google.com/p/volatility-installer/

Esta semana he empezado a realizar el mismo script en PowerShell, debido a que como batch tiene muchas restricciones, he tenido que “tirar” de herramientas de terceros, como 7zip, wget y HashMyFiles para hacerla totalmente funcional. El script es muy sencillo de utilizar y no requiere parámetros. Sólo doble clic, y a jugar….

Nota: Tanto Python, como las dependencias, junto con MinGW, se instalan de manera interactiva con el usuario. Las instalaciones son del entorno Next–>Next, menos MinGW, que necesitaremos marcar las opciones de MAKE, más el compilador. Este paso de “interacción” es necesario, ya que de manera desatendida no se compilan bien algunas bibliotecas en Python bajo Windows.

Doy por supuesto (y por invitado!) que colaboraciones y ayudas, serán muy, pero que muy bien recibidas…..

Update.- Chema, de opensec, ya me ha pasado el script de instalación y está subido al proyecto. Su script soporta la instalación de Volatility Framework en los sistemas Arch, Debian y FreeBSD!

Buen fin de semana a tod@s!!

SYSTEM, causa y efecto III de IV

Estándar

SYSTEM. causa y efecto I de IV

SYSTEM, causa y efecto II de IV

SYSTEM, causa y efecto IV de IV

Hola a tod@s!
Este post está dedicado a observar el funcionamiento de un SID en lo referente a un usuario específico.
Un SID, o identificador de seguridad, es una estructura para identificar inequívocamente a un usuario o un grupo específico.
Desde Windows NT, esta estructura se encuentra definida en la librería WINNT.H.
La estructura de un SID contiene, entre otros, los siguientes elementos:

  • Revisión del SID
  • Un identificador de autoridad que identifica la autoridad de ese SID
  • Un identificador relativo (RID), el cual identifica unívocamente un usuario o grupo, en relación a la autoridad asignada al SID

La combinación del identificador de autoridad, unido a los identificadores de las sub-autoridades, asegura que no haya dos valores SID iguales.
El formato de un SID se forma usando una cadena estandarizada, la cual hace más fácil la identificación de sus componentes. El formato de cadena de un SID es el siguiente:
S-R-I-S[VALORES]
En donde:

Imagen 1.- Relación Valores & Especificación

Aplicando los elementos anteriores, un SID válido sería el siguiente:

S-1-5-32-545

En donde la traducción de este SID sería la siguiente:

 

Imagen 2.- Valores e identificación

Si se quieren obtener los SID validados en el sistema operativo, éstos se pueden extraer de varias formas.
Una forma ágil de obtener los SID del sistema operativo, es utilizando herramientas ya creadas específicamente para este tipo de usos. Las más conocidas con GETSID, del Kit de recursos de NT, y PSGETSID, de la archiconocida SysInternals. La utilización de este tipo de herramientas no conlleva ningún tipo de problemas, y su uso es rápido e intuitivo.

 
 

Imagen 3.- Uso de PsGetSid

Otra vía de acceso a los SID validados en un sistema operativo es por el registro de Windows. Las claves asociadas que guardan información relativa a un SID de usuario son varias, pero las más usuales y prácticas son las siguientes:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
HKEY_USERS

Imagen.- SID en Registro de Windows

Otra forma rápida, fácil, y para toda la familia, es a través de Scripting. WMI y PowerShell, tienen capacidad para obtener todas las clases asociadas a un SID, y extraer la información de manera ágil. Gracias a que PowerShell tiene acceso rápido a toda la sintaxis de WMI, se puede scriptar todos los comandos de manera sencilla.

 

Imagen.- Extracción de SID a través de PowerShell

 
En el siguiente y último capítulo, veremos cómo se comporta la cuenta SYSTEM, así como el sistema operativo,  a la hora de intentar iniciar una sesión interactiva en el sistema, tal y como se suele utilizar en técnicas de elevación local de privilegios.
Saludos!!
Referencias
PSGETSID
http://technet.microsoft.com/en-us/sysinternals/bb897417
GETSID
http://download.microsoft.com/download/win2000platform/Getsid/1.0/NT5/EN-US/getsid.exe
Win32_SID Class
http://msdn.microsoft.com/en-us/library/aa394450(v=vs.85).aspx
How to Associate a Username with a Security Identifier (SID)
http://support.microsoft.com/kb/154599/en-us
How to deal with localized and renamed user and group names
http://support.microsoft.com/kb/157234/en-us