Search Results for: análisis forense

(Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.)

Según lo visto en la entrada anterior, teníamos a nuestra disposición las siguientes evidencias digitales:

• Imagen forense (dd) de un GPS TomTom.
• Volcado lógico de un iPhone5.
• Volcado físico de un Samsung Galaxy S5.
• Imagen forense de un Ultrabook HP Spectre.

Una buena forma de comprobar una coartada es verificando la localización GPS, así que vamos a empezar con el análisis forense del navegador, un TomTom One. Si analizamos los artefactos forenses que podemos recuperar, vemos que nos interesan principalmente dos datos:

• Rutas programadas en el dispositivo: Queremos sobre todo la última ruta realizada, y la encontraremos en el fichero: MapSettings.cfg.
• Última conexión a GPS realizada: TomTom guarda la última conexión con la red de satélites GPS, algo que nos puede servir para corroborar la exactitud de la última ruta. Deberemos hacernos con el fichero CurrentLocation.dat.

[Read more…]

(N.d.A. Debido al revuelo que se ha montado a colación del post de hoy, nos vemos en la necesidad de aclarar que esta es una historia de ficción en la que nos hemos tomado ciertas licencias para justificar la intervención de lo que podría ser un equipo de seguridad externo (cuya colaboración en ocasiones se produce, no obstante). Todos los personajes y situaciones que aparecen en este y otros post de ficción no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.

En ningún caso se ha pretendido desmerecer la innegable labor de las FFCCSSE y el excelente trabajo que realizan día a día para proteger a los ciudadanos, tanto en el ámbito digital como en el físico. Asimismo, tampoco hemos querido poner en duda la preparación ni los medios de los expertos de seguridad de estos cuerpos, ya sea la Brigada de Investigación Tecnológica —BIT— o el Grupo de Delitos Telemáticos —GDT— de la Guardia Civil, con cuyos objetivos estamos totalmente alineados: ir a por los “malos”.)

Pocas cosas llaman tanto la atención como una buena dosis de morbo, con doble de sangre como acompañamiento y extra de drama. La noticia llevaba varios días en primera plana: Mª Adoración Puig de Parga Carral-Bryce, última descendiente de los Puig de Parga (una familia castellana poco conocida públicamente, pero poseedora de una considerable fortuna), había aparecido asesinada a cuchilladas en su chalet de La Moraleja.

Su marido, Ronald Green Hinojosa-Del Pinar, vicepresidente ejecutivo EMEA de Armand & Old, una conocida multinacional financiera, no se encontraba en casa en esos momentos (estaba al parecer en una importante reunión de trabajo), lo que ha hecho dispararse las teorías sobre el asesinato.

La que más ha calado, a bien seguro por su truculencia, es la que tiene al propio R.G. como responsable del crimen. Green es atractivo, inteligente, elegante y soberbiamente altivo, siempre con la barbilla ligeramente levantada y esa mirada de “soy mejor que tú, y lo sabes”. Maná caído del cielo para las tertulias de televisión y las redes sociales, que ya lo han apodado “El Mr. Grey español”.

[Read more…]

En la entrada de hoy quiero dar a conocer una herramienta que he probado recientemente cuyo objetivo es analizar Exploit Kits: Exploit Kit Analyzer – EKAnalyzer, que ha desarrollado Jose Ramón Palanco (fundador de Drainware) y que me parece bastante útil para la gestión de incidentes de seguridad en tiempo real.

EKAnalyzer es una herramienta que realiza las mismas peticiones HTTP registradas en una captura de tráfico (en formato pcap), para comprobar si en el momento de la ejecución se sirven artefactos maliciosos (como Exploit Kits). No es una herramienta para análisis forense, es decir, puede que un pcap en un instante determinado dé como positivo (malicioso) pero por ejemplo, una hora después, si el Exploit Kit ha sido desmantelado, dará como resultado negativo.

Para la identificación de exploits, EKAnalyzer realiza todas las peticiones varias veces, usando diferentes User-Agents en cada iteración y además realiza una copia de todos los ficheros descargados en cada análisis. Actualmente se integra con diferentes herramientas/utilidades como:

• Filemagic.
• Virustotal API.
• Yara.
• Análisis de ficheros swf.
• Clamav.

La puesta en marcha es muy sencilla siguiendo los pasos que se indican el fichero de instalación. Tras levantar el servicio llegamos a una interfaz Web muy sencilla (la cual le he prometido a Palanco mejorar y ponerle algo de colorines que está muy sosaina :) a la que poder subir el pcap a analizar:

Para probar un ejemplo de funcionamiento, en el laboratorio dispongo de una serie de pcaps preparados que realizan peticiones contra Exploit Kits que actualmente están activos. A continuación un ejemplo de uno de esos pcaps que como vemos contiene ciertas peticiones hacia algunos recursos de www.drainware.com:

Si subimos uno de estos pcap a EKAnalyzer lo que veremos será lo siguiente de forma secuencial:

Una vez el análisis ha concluido podemos ver los detalles del mismo para cada uno de los User-Agents. Destacar que el User-Agent que aparece en negrita es el original del pcap. Podemos ver unas capturas a continuación:

Como vemos, esta herramienta nos puede ayudar bastante agilizando algunos procesos de comprobación que normalmente se llevan a cabo en la gestión de un incidente de seguridad, reduciendo un trabajo que podría llevarnos horas a unos poco minutos. Nos ahorramos el coste de tener que abrir cada pcap, obtener las URL, mirar las cabeceras, replicar peticiones con diferentes User-Agents, analizar las respuestas, etc., que habitualmente se suele hacer de forma manual.

EKAnalyzer está bajo licencia GNU AGPL y disponible para su descarga y contribución en GitHub.

Este domingo pasado se dieron dos factores interesantes: el primero, una tarde-noche tirando a bastante aburrida y el segundo, que tenía materiales que me habían llegado el sábado. Así que decidí probar algo que había leído. Una técnica de la que había oído hablar mucho pero que no había tenido la oportunidad de probar personalmente: un “cold boot attack”.

Para aquellos que no sepan de que va, se trata de una técnica en la cual se aprovecha que la información de la memoria RAM no se borra instantáneamente, sino que se degrada poco a poco durante un breve tiempo. Ese tiempo parece ser de unos segundos, pero si se reduce la temperatura de la memoria RAM, se puede conseguir que este tiempo se incremente sustancialmente.

Una vez introducida brevemente la teoría es hora de pasar a la práctica, que es lo interesante. En este caso vamos a hacer un montaje casero, en un escenario en el que no se cuenta con demasiados recursos: un ordenador con Windows 7 y 2 GB RAM DDR3 y otro con Windows 7 y 4 GB de RAM DDR3. El primero será el sistema atacado y en el segundo se montará el modulo de RAM, que además contará con memoria extra (los otros 4GB) con la esperanza de que al cargar el sistema operativo (otro Windows 7) no se sobrescriban los datos alojados en la RAM “congelada”.

Aunque esta forma no es la más óptima, el objetivo es realizar una prueba de concepto simple y fácil de montar, ya habrá tiempo más adelante de probar en detalle.

El proceso llevado a cabo consistió en arrancar el PC con el modulo de 2 GB de RAM con sistema operativo Windows 7, en el que se abren diversos procesos: navegador firefox, imagen descargada de Google, un cliente de VoIP y otros programas. Con esto se busca dejar trazas en la RAM que puedan ser identificadas en un posterior análisis forense: se busca un punto conocido por el que poder buscar después.

Una vez hecho, botonazo y a empezar el lío. Con el PC previamente abierto, sacamos el módulo de RAM y se mete en un recipiente especializado (también conocido como tupper viejo de la cocina), se empieza a rociar la RAM para enfriarla y cuando han pasado unos segundos (a decir verdad no probé la temperatura, pero había cristales de hielo) la coges con el dedo y consigues el primer objetivo del post: dedo congelado.

Acto seguido, se conecta el modulo de RAM “congelado” y se enciende el PC. Cuando ha terminado de arrancar se lanza DumpIt la utilidad de volcado de RAM, una herramienta que crea una imagen en RAW del contenido de la memoria, que es lo que posteriormente será analizado.

Una vez hecho esto ya se puede pasar al siguiente paso, al cual me ayudó mi compañero David García (que tuvo la genial idea de utilizar foremost): análisis de la RAM. Para ello utilizamos dos herramientas clásicas: volatility y foremost. Con el primero encontramos diferentes procesos abiertos y demás, pero nada que nos pareciera una prueba concluyente. Con el segundo, foremost, encontramos esto:

Aunque como puede apreciarse, la imagen no está completa, pero se recupera gran parte y se ve claramente que es la imagen que se tenía en memoria.

No esta mal para un primer intento, ¿verdad? En otro post analizaremos soluciones a este tipo de ataques y formas de enfocar el forense, pero como resumen ya sabéis que a) no estáis a salvo solo con apagar el PC y b) debéis llevar un spray congelante si trabajáis para la NSA.

(Nota: el autor no se hace responsable de módulos de RAM rotos ni dedos congelados ;-) )

(La entrada de hoy corre a cargo de Mª José Montes)

Dentro de poco menos de tres semanas, se celebrará el primer congreso de Seguridad Informática de Córdoba, QurtubaCon.

Hasta ahora, en Córdoba, se venían celebrando dos eventos periódicos, que son Hack&Beer y HackLab. Dada la buena acogida de estos eventos y, con la ilusión de poder reunir a grandes figuras del sector de la seguridad, se gesta este congreso, organizado por la Comisión de Eventos de la Asociación Nacional de Profesionales del Hacking Ético (ANPhacket), lo forman Miguel Arroyo, Eduardo Sánchez, Enrique Palacios y una servidora, entre otros.

[Read more…]

Un flujo de datos alternativo (ADS – Alternate Data Stream) es una característica del sistema de ficheros NTFS que consiste en incluir metainformación en un fichero. Podríamos decir que son ficheros secundarios “ocultos” guardados dentro de otros ficheros. El objetivo inicial es almacenar información extra acerca del fichero principal, pero esta técnica también fue muy usada para propagar virus de forma transparente para el usuario.

Aclarar que en este artículo me voy a centrar sólo en el sistema de ficheros NTFS sobre Windows 8 en concreto. En otros sistemas de ficheros existen técnicas similares; el símil con sistemas de ficheros como ext3, ext4, JFS, HFS+, etc., serían los atributos extendidos (EAs – Extended Attributes). La limitación de los EAs es que no se puede incluir una imagen o un archivo ejecutable como sí puede almacenarse en los ADS. Pero como he comentado, en este artículo sólo nos centraremos en NTFS y los ADS.

Hay que tener en cuenta algunas consideraciones de los flujos de datos alternativos:

• Una aplicación de escritorio solo leerá el flujo principal de un archivo. Es decir, mediante el explorador de Windows sólo se abrirá el fichero que pertenezca al flujo principal. Los flujos alternativos sólo se pueden ejecutar mediante consola de comandos.
• De igual forma, con el explorador de Windows solo se verá el flujo alternativo, incluso, solo se mostrará el tamaño del fichero perteneciente al flujo principal. Si hay un vídeo de 100MB por ejemplo, éste tamaño no se verá reflejado en el tamaño del fichero.
• Los flujos de datos alternativos se pueden ver y abrir mediante la consola de comandos.

La finalidad de los flujos de datos alternativos es asociar ficheros o información que pueda ser confidencial, a ficheros de forma que queden ocultos a usuarios. Pero de la misma forma se puede usar esta técnica para alguna actividad maliciosa.

Como particularidad, mencionar que cuando descargamos un fichero de Internet, lleva asociado un flujo alternativo llamado “Zone.Identifier”, que indica la zona desde donde se ha descargado el fichero. Windows después utiliza dicho valor para abrir o ejecutar los ficheros. El significado de los valores es:

Después de la introducción, vamos a ver un ejemplo de cómo crear y ver el contenido de un flujo de datos alternativo. Para el ejemplo vamos a tomar dos ficheros:

• principal.pdf, lo trataremos como fichero del flujo principal
• img_oculta.jpg, lo trataremos como fichero del flujo alternativo

Ejecutamos dir para el contenido de la carpeta. Importante, fijaos en los tamaños de los ficheros:

Creamos ahora el flujo de datos alternativo, el comando sería el siguiente:

type img_oculta.jpg > principal.pdf:img_oculta.jpg

¿Qué ocurre si volvemos a hacer un dir? Aparentemente nada ha cambiado…

Se puede observar que el tamaño del fichero principal.pdf no ha cambiado absolutamente nada. Ejecutemos ahora el comando dir /r:

Como se ve en la imagen, el fichero principal.pdf tiene un flujo alternativo identificado como :img_oculta.jpg. Este flujo de datos alternativo coincide en tamaño con el original img_oculta.jpg, de hecho éste se podría eliminar, pero el flujo de datos alternativo seguiría existiendo. También, como ya hemos comentado antes, el tamaño del fichero principal.pdf tampoco se ha alterado.

Para abrir el contenido del flujo de datos alternativo utilizaríamos el comando:

Nombre_de_la_aplicacion fichero.extension:alternativo.extension

En nuestro caso vamos a abrir la imagen oculta con el editor de imágenes de Windows Paint:

mspaint principal.pdf:img_oculta.jpg

En sistemas operativos antiguos como Windows XP, la ejecución de un flujo de datos alternativo se hacía mediante el comando start, pero a partir de Windows 7 esto no está permitido, por lo que se cambió a invocar directamente la aplicación para abrir el fichero.

Supongo que ya os habréis hecho la pregunta: ¿qué ocurre si añado un “.exe” como flujo alternativo? En este caso, nos encontramos con que a partir de Windows 7 no está permitido (por motivos de seguridad) ejecutar un “.exe” como flujo alternativo. Veamos un ejemplo.

Vamos a asociar a un fichero llamado principal.txt la calculadora de Windows:

type c:\Windows\System32\calc.exe > principal.txt:calc.exe

Ahora ejecutamos mediante el comando start:

start .\principal.txt:calc.exe

Y el resultado es un mensaje de error que dice “Windows no puede encontrar el archivo”. Tal y como esperábamos, no podemos ejecutar un fichero “.exe” en un flujo de datos alternativo. Pero como esperábamos, eso no es del todo cierto. Para saltarnos esta medida vamos a crear un script en Python, y mediante este script llamaremos al ejecutable. Por cambiar un poco del típico ejemplo, he decidido iniciar una instancia Google Chrome.

Creamos un fichero llamado script_py.txt con el siguiente contenido:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys, string, os			
os.system('"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"')

Ahora asociamos el fichero como flujo de datos alternativo de un fichero de texto llamado principal.txt.

type script_py.txt > principal.txt:script_py.txt

Para ejecutar el script de Python lo haremos mediante la sentencia:

C:\Python27\python.exe principal.txt:script_py.txt

Si todo ha ido bien, con esto lograremos ejecutar un fichero “.exe” a partir de un flujo alternativo. En este caso, se abrirá una nueva instancia del navegador Google Chrome.

Esta técnica era muy utilizada por atacantes para insertar malware en flujos alternativos. Aunque hemos visto que en los sistemas operativos actuales no se puede hacer directamente, sí se puede de forma indirecta, por lo que sigue siendo un aspecto a tener en cuenta para garantizar la seguridad.

Aunque no se ha visto en el artículo, existen herramientas para ver los flujos de datos alternativos en modo gráfico. Una herramienta es AlternateStreamView de Nirsoft, la cual te permite escanear carpetas en busca de ficheros alternativos.

Sin lugar a dudas, hay que tener en cuenta los flujos de datos alternativos para garantizar la seguridad de los sistemas, y no ejecutar código malicioso que permanezca oculto. Además, este tema resulta muy interesante a la hora de realizar un análisis forense para una pericial, ya que podríamos obtener información relevante que a simple vista no está accesible.

En el capítulo anterior habíamos dejado la investigación en un punto candente: teníamos pendiente un análisis forense del equipo del director de marketing, ya que todo apuntaba a que podía ser la fuente de la filtración de la información.

Hablando con María, la CIO de la Empresa, tomamos la decisión de ser extremadamente cautos a la hora de hacer una imagen forense del portátil del director de marketing, ya que la paranoia campa a sus anchas por la Empresa y no es posible fiarse de nadie.

Esperamos a que salga a una reunión en otra empresa para entrar en su oficina y abalanzarnos con nuestro bloqueador de escritura de discos para obtener una copia bit a bit (las únicas válidas ya que capturan el estado del disco tal y como está, copiando tanto ficheros borrados como espacio libre del disco duro).

[Read more…]

Comienza un día nuevo en la oficina. Todos los sistemas están funcionando correctamente, el generador de cafeína está a toda máquina y los comerciales están fuera haciendo visitas. Es un momento perfecto para revisar algunos artículos de investigación, o hasta para invertir un poco de tiempo en un par de scripts en Python a los que les llevo dando vueltas un rato… hasta que suena el teléfono.

El jefe ha recibido una llamada de la CIO de una empresa del IBEX 35 (a partir de ahora, la empresa será Empresa, y la directiva María). Según sus palabras, se ha producido una fuga de datos. Una fuga muy grave. Al parecer, parte de lo que se ha filtrado es el plan estratégico de la empresa para los próximos cinco años. Información a la que tiene acceso un grupo muy reducido de personas, entre las que se encuentra el consejo de dirección de la empresa.

Como todavía no sabemos a lo que nos enfrentamos, cogemos tanto la mochila de respuesta ante incidentes como la de informática forense y nos dirigimos a la sede de la empresa en Madrid para una primera toma de contacto.

La Empresa se toma la seguridad muy en serio: registran ambas mochilas, toman fotografías de todos los dispositivos y nos dan una tarjeta de identidad que por la pinta seguro que es capaz de hacer más de lo que parece. Cámaras de seguridad en todos los pasillos, y un ambiente totalmente profesional hasta que subimos a la planta noble, donde nos reunimos con María. Está visiblemente nerviosa, y viendo su traje parece que lleva más de un día en pie.

Dentro de las fases de la respuesta ante incidentes estaríamos todavía de la detección (sabemos que hay algo, pero todavía no conocemos el alcance de lo que está sucediendo). María nos cuenta que alguien está obteniendo información confidencial de la empresa, tan reservada que solo puede venir de los más altos cargos de la empresa: el director general, el director de operaciones, el director financiero, el director de ventas… o ella misma.

Tras firmar varios acuerdos de confidencialidad especialmente virulentos, empezamos nuestro trabajo con la aproximación más simple: un inside job, el clásico empleado descontento que ha robado la información. Pero al parecer todos los directivos son fanáticamente leales a la empresa e incluso su personal administrativo es de la mayor confianza, por lo que a priori podemos descartar esta teoría (en realidad no la descartamos, solo la guardamos para más tarde).

El espionaje clásico también queda excluido: la información robada no es algo que se pueda obtener poniendo un micrófono o “pinchando” un teléfono. Ha sido extraída de un ordenador.

La Empresa también se toma muy en serio la seguridad informática: seguridad en profundidad en toda la arquitectura, varios niveles de cortafuegos, antivirus actualizados, sistemas parcheados hasta la obsesión, acceso remoto por VPN, detectores de intrusos, contraseñas robustas cambiadas cada mes, etc. Uno de esos sitios en los que nunca se esperaría que sucediera nada, pero en el que aquí estamos trabajando.

Lo primero que hacemos es recoger información, toda la que seamos capaces de recopilar para proceder a su análisis y entender qué ha podido suceder. La Empresa tiene todo bien organizado, por lo que podemos hacernos con un paquete de datos completo: logs del proxy, de la pasarela de correo, de los antivirus, eventos de servidores y de las estaciones de trabajo y hasta de la VPN. El problema es que todos esos logs, si tomamos el acumulado de los últimos tres meses (el mínimo con el que empezamos), suman 200Gb de información. Comprimida.

Cogemos tres meses porque estamos empezando a sospechar que una APT (Advanced Persistent Threat) puede estar detrás de esto. Vamos, que alguien puede haber entrado hasta la cocina en la Empresa y se esté comiendo hasta los yogures caducados. El disponer de un histórico de datos nos permite detectar patrones y descartar falsos positivos, haciendo más eficaz nuestro trabajo.

Lo primero que hacemos es realizar un filtro inicial de la información, quedándonos con los equipos tanto de los directivos como de su personal de administración (diez en total), lo que reduce los registros a un poco menos de 20Gb de datos descomprimidos. A través de una serie de scripts normalizamos e importamos la información a una base de datos que nos permita realizar búsquedas y aplicar otros scripts que tenemos desarrollados.

Las primeras comprobaciones son casi rutinarias, pero hay que realizarlas: visitas a dominios infectados, eventos de la consola de antivirus, múltiples envíos de correos a direcciones no conocidas… serían signos que nos permitirían detectar rápidamente el equipo comprometido, pudiendo aislar la infección lo antes posible.

No hay suerte esta vez, aunque en realidad no esperábamos sacar nada en claro. Este incidente huele a algo avanzado desde el primer momento. Tenemos que pasar a la segunda fase: la detección de anomalías. Todos los sistemas (incluidos sus usuarios) siguen unos patrones de comportamiento, un conjunto de acciones y conexiones que pueden ser analizados para conformar un baseline o valor de referencia.

Ese baseline puede ser obtenido de los logs recuperados para hacer emerger todo lo raro, todo lo que no encaja: las anomalías. Es un trabajo complicado, porque la creación del baseline nunca es exacta, y abundan los falsos positivos (y además, nunca sabes si los “malos” han sido tan buenos como para esconder sus acciones tan bien como para que se hagan parte del baseline).

Al final es un trabajo minucioso, costoso y metódico que tiene que hacerse con sumo cuidado y atención al detalle para no dejarse nada. Es como buscar una aguja en un pajar, pero cuando el pajar es del tamaño de un campo de fútbol y no sabes siquiera que lo que quieres encontrar es una aguja.

Menos mal que, si llevas tiempo en el negocio, puedes tomar algunos atajos. Sabiendo cómo se comportan muchas amenazas es posible realizar una serie de modelos de ataque, conociendo qué tipo de anomalías generan en un sistema. De esta forma podemos buscar por esas miguitas de pan, esos indicios que nos permitan averiguar qué es lo que está sucediendo.

La cantidad de datos no es pequeña, así que tenemos algo de tiempo mientras nuestros programas trabajan. Un poco más de cafeína, una docena de correos y dos llamadas telefónicas más tarde, tenemos un listado de unas 30 anomalías.

Casi todas son falsos positivos, pero una de ellas salta a la vista: una petición POST a un nombre de dominio muy similar a un conocido periódico de tirada nacional (a partir de ahora www.period1co.es), tan similar que tan solo han cambiado una letra por otra casi idéntica. La petición en sí es bastante anodina, pareciendo la URL a primera vista el posteo de un comentario en una noticia.

Anomalía por partida doble. En primer lugar, ¿por qué tenemos un POST sin haber tenido antes ninguna comunicación con esa página web? Dentro de una comunicación HTTP el método POST es empleado para enviar datos a una página web, pero lo lógico es que antes hayamos descargado esa web, lo que suele conllevar un cierto trasiego de peticiones GET, que aquí a priori no existen.

En segundo lugar: ¿www.period1co.es? Lo buscamos en diversas páginas de reputación online y ninguna lo marca como malicioso, pero está claro que huele a chamusquina. Nos morimos de ganas por abrirlo en un navegador, pero no sabemos si los atacantes están vigilando los logs y los ponemos sobre aviso.

Mirando el lado positivo, tenemos ya dos hilos de los que tirar: el dominio supuestamente malicioso, y la IP origen de la petición, que resulta ser la del director de marketing de la Empresa.

Ahora podemos empezar a trabajar alrededor de estos indicios, lo que en la jerga conocemos como pivotar. Lo primero es ver más ocurrencias de ese dominio malicioso en todos los logs que tenemos recogidos, sean o no anómalos. Y el segundo paso sería analizar en detalle todo el tráfico de la IP 192.168.39.134, que parece ser a todas luces el equipo infectado.

La emoción de la caza es casi como una droga, así que mi jefe y yo miramos hipnotizados la pantalla mientras las herramientas hacen su trabajo. Diez angustiosamente largos minutos más tarde, tenemos resultados jugosos. Muy jugosos.

El equipo 192.168.39.134 ha realizado en los últimos dos meses 18 conexiones POST como la anterior a la URL www.period1co.es. Todas ellas en horario laboral, con unos tamaños bastante discretos (que hacen pensar a priori que la exfiltración de datos no se ha producido por esa vía) y a subpáginas del dominio con una estructura común (que podrían ser respondidas por un único script en el servidor y que ayudarían a que las URL variaran, haciendo más complicada su detección).

Y de forma adicional, tenemos 5 conexiones más al dominio desde dicha IP:

Durante el transcurso del análisis forense de una máquina que sospechamos que está contaminada con malware, hemos encontrado el siguiente fichero: cosa.pyc.

¿Alguno de nuestros lectores nos podría echar una mano para saber qué hace? ;-)

Para aquellos que os habéis enfrentado alguna vez a un análisis forense de memoria RAM, lo más seguro es que conozcáis Volatility. Esta potente herramienta desarrollada en Python permite obtener hasta la marca de café que beben los usuarios/atacantes que han hecho uso de un determinado equipo.

Como todo en la vida, se puede utilizar la mejor raqueta del mercado, pero uno no golpeará como Nadal, o se puede disponer de las mejores zapatillas de running pero uno nunca será Carl Lewis. Con Volatility pasa un poco lo mismo: no es una herramienta sencilla y tratar de encontrar un “bicho” o hallar evidencias de una intrusión no es trivial. Sí que es verdad que listar los procesos, obtener sus DLLs o incluso ver las conexiones establecidas en un momento determinado por la máquina es relativamente sencillo. Lo que ya no lo es tanto es la interpretación de la información que Volatility nos devuelve.

Es por eso que tras bucear por la estupenda wiki del proyect, e ir leyendo los diferentes posts o artículos recopilados por sus autores uno puede ir aprendiendo pequeños “trucos” sobre cómo detectar contextos anómalos y comportamientos específicos del malware. Con esta idea nace VolWrapper, una envolvente para Volatility escrita en Python que permite analizando la salida de los diferentes comandos de esta, identificar posibles anomalías presentes en la captura.

¿Cómo funciona VolWrapper? Pues simplemente redirigiendo la salida de la aplicación a la entrada de VolWrapper mediante una pipe.

root@hal9000:/home/ramado volatility  -f imagecapture.raw --profile 
   Win7SP1x86 dlllist | ./volWrapperV0.1.py

En estos momentos la envolvente soporta tan solo 3 comandos identificando situaciones anómalas para cada una de ellas: dlllist, psscan, pslist:

• Dlllist lista las librerías dll cargadas en cada uno de los procesos de la máquina. A menudo el malware pude trabajar en user space, inyectándose en un determinado proceso a través de estos métodos, por lo que durante la acción forense es recomendable revisar las diferentes librerías residentes en memoria. Este trabajo puede ser tedioso, por lo que en este punto entra en acción VolWrapper mostrando mediante una leyenda de colores información sobre las diferentes Dlls identificadas. Puede alertarnos de librerías fuera de los directorios tradicionales como system32, de capacidades de comunicación o de cifrado, incluso proporcionarnos una descripción de la funcionalidad de la dll.

  Esto no quiere decir que mágicamente no señale donde está el problema, pero sí que puede ser un soporte para cribar un montón de información que de otra manera podría suponer mucho tiempo de estudio. Ejemplo de ejecución (pinchar en la imagen para verla a tamaño completo):

  #volatility –f imagecapture.raw –profile Win7SP1x8 dlllist | ./volWrapperV0.1.py –c 
  

  

  Por ejemplo, de esta manera podemos identificar rápidamente si un proceso que aparentemente tiene una funcionalidad concreta como es notepad.exe está utilizando librerías de cifrado de datos o de comunicación, situación en un principio anómala. A su vez permite también centrarnos en todas aquellas librerías que a priori no están presentes en una instalación por defecto de un entorno Windows (listadas de color negro), centrando nuestra atención en ellas.

• Pslist permite obtener los procesos en ejecución en un momento determinado de la captura analizada. Una posible anomalía en cuanto a los resultados listados por Volatility puede ser procesos huérfanos, es decir sin PID padre aparente. Esta situación puede deberse a que un rootkit puede estar ocultando el verdadero proceso padre. VolWrapper permite identificar mediante un código de colores los procesos sospechosos.

  

• Psscan es similar al anterior, siendo un apoyo a psxview.

Resumiendo, la idea de la herramienta es ir ampliándola incorporando todas aquellas situaciones anómalas que identifiquen la presencia de algún artefacto. Por ahora tan solo soporta estos tres métodos pero irá creciendo, permitiendo a gente con menos conocimientos realizar un forense de RAM de forma más sencilla. Tenéis la herramienta en el siguiente enlace https://github.com/ramado78/volWrapper y en breve la añadiremos a la sección de herramientas “self-made” en SAW ;)