Search Results for: análisis forense

DEFCON 2018 DFIR CTF – Reto forense (Intro + Nivel 1)

4 de enero de 2019 Por
(N.d.E.: nos damos un respiro con los artículos sobre la Comunidad de Ciberinteligencia rusa, el GRU (volverán pronto), para adentrarnos en el reto forense que nos introduce Antonio Sanz.)

Comentaban unos alumnos del curso de análisis forense hace unas cuantas semanas la dificultad de conseguir experiencia en forense y respuesta ante incidentes, no sin parte de razón. En muchas ocasiones yo comparo, salvando las obvias distancias, el trabajo de DFIR (Digital Forensics and Incident Response) con el de un bombero: gran parte del tiempo de relajación mezclado con una pequeña parte de tiempo de intensidad y stress máximos.

Aquí estamos, sin embargo, no siendo del todo exactos: ¿qué hacen los bomberos cuando no se deslizan por el tubo y salen corriendo a salvar gente? La respuesta es muy sencilla: ENTRENAN.

En el mundo DFIR el entrenamiento es fundamental, ya que en muy pocos trabajos se está el 100% del tiempo “en harina” (hay que tener en cuenta que estar en un incidente a máxima capacidad de trabajo durante un periodo largo de tiempo cuesta, y mucho). El entrenamiento, además, permite detectar carencias y áreas de mejora, así como afianzar conceptos y aprender nuevas formas de hacer las cosas. [Read more…]

Análisis de Samouri: una botnet de noobs, para noobs

9 de marzo de 2018 Por

Hace unos días encontramos un malware Linux con elementos bastante conocidos hasta la fecha, sobretodo importados de Gafgyt. Sin embargo, ciertas modificaciones hicieron que le dedicáramos el tiempo de analizarlo.

En un primer momento, el malware lleva a cabo funciones de reconocimiento del entorno, obteniendo la IP pública del sistema o el Endianness, donde por defecto tomará little endian (recordemos que arquitecturas como ARM, PowerPC o MIPS pueden trabajar con ambos órdenes.) [Read more…]

Análisis del Timeline de una evidencia con Plaso

5 de julio de 2017 Por

Plaso, evolución de la herramienta conocida como log2timeline, es una herramienta desarrollada en Python que permite extraer la línea temporal de todos los eventos ocurridos en un sistema. Admite como como datos de entrada ficheros, discos virtuales, dispositivo de almacenamiento , algún punto de montaje o un volcado de imagen de disco. Como nota aclaratoria aunque la nueva herramienta pasa a denominarse plaso, para ejecutarla se hará a través de “log2timeline.py” lo cual puede llegar a causar confusión.

Plaso nos ofrece un conjunto de herramientas, que de forma resumida son:

  • log2timeline: extraer el time line de todos los eventos.
  • psort: procesamiento de los datos extraídos.
  • pinfo: muestra los datos del fichero de almacenamiento plaso.
  • image_export: exporta ficheros de una imagen.

Log2timeline se encarga de analizar los datos recibidos como parámetro de entrada generando un fichero de salida con formato “plaso”, el cual contendrá toda la información de los datos analizados. Dicho fichero de almacenamiento plaso contendrá información como:

  • Cuando se ejecutó la herramienta.
  • Metadatos de los ficheros analizados de los datos de entrada.
  • La información parseada.
  • Número de eventos extraídos de los datos de entrada.

Para las pruebas realizadas he optado por usar una imagen de prueba en formato EnCase (parte1 y parte2), accesible para cualquiera que quiera realizar las pruebas.

[Read more…]

Análisis tráfico de red dispositivos móviles

29 de noviembre de 2016 Por

En un post anterior se explicó como capturar tráfico de red en una red local utilizando para ello una Raspberry Pi 3.

A continuación vamos a ver cómo podemos analizar el tráfico que hemos capturado en formato pcap.

La primera opción por la que me decanto es la herramienta Capanalysis. Esta herramienta nos permite ver de una forma gráfica las peticiones realizadas, filtrar por tipo de tráfico (HTTP, DNS, ARP, …), filtrar por IP, país, etc. Por tanto, permite acceder a toda esta información de una forma sencilla y visual.

En primer lugar, instalamos la aplicación de Capanalysis. En mi caso he optado por instalarlo en una máquina virtual de la distribución Caine, la cual está orientada a realizar análisis forenses y está basada en Ubuntu 14.04.
[Read more…]

Cómo preparar un testbed para tu set de herramientas forenses

20 de noviembre de 2015 Por

Es habitual que cada profesional tenga sus preferencias en cuanto a herramientas y modo de trabajar. En general, estas preferencias vienen determinadas por nuestra experiencia y formación; y con el paso del tiempo, la colección de scripts y programas que usamos crece exponencialmente.

Una manera interesante de mantener todo este material recopilado organizado y clasificado es configurar un testbed o laboratorio de pruebas. Esta práctica es seguida habitualmente por profesionales de respuesta a incidentes y peritos, con el objetivo de probar la fiabilidad de las herramientas que usan.  Sin embargo, yo aconsejo realizarlo también a otros profesionales debido a las ventajas que ofrece:

  • Dispones de un entorno de referencia para probar herramientas y técnicas forenses.
  • Puedes probar programas y comandos, y evaluar cuales son más apropiadas para diferentes entornos y situaciones (por ejemplo: por tiempo de ejecución, trazas dejadas en el sistema operativo o fiabilidad en los resultados).
  • A pesar de llevar bastante tiempo, una vez configurado y documentado, el entorno es fácilmente reproducible.

A continuación se explican brevemente los pasos a seguir.

[Read more…]

LINE. Android e iOS. Análisis técnico de la mensajería instantánea.

10 de febrero de 2015 Por

En la actualidad, el uso de smartphones y tablets se ha convertido en una parte fundamental de nuestras vidas. El rápido crecimiento de las aplicaciones de mensajería instantánea ha hecho que servicios como llamadas telefónicas o SMS queden desplazados por los mensajes enviados desde aplicaciones en terminales móviles. Es por esto que este tipo de mensajes puedan tener cabida en un tribunal como prueba ante un delito.

En este post comentaré lo que fue mi Trabajo Fin de Grado en la Universidad de Alcalá el cual fue dirigido por el IUICP (Instituto Universitario de Investigación en Ciencias Policiales) y por lo tanto, imaginaréis que quienes lo usarán serán las FFCCSSEE en caso de que sea necesario para llevar algún tipo de investigación forense donde sea preciso recuperar conversaciones mantenida desde LINE.

¿Por qué LINE y no otro? Para chatear con una persona usando LINE no es necesario que ninguna de las partes tenga el teléfono móvil de la otra, únicamente dando el ID de usuario ya puedes mantener una conversación. El anonimato que esto ofrece, junto con las conversaciones secretas (sus mensajes se autodestruyen “permanentemente”), abre un campo muy amplio que dejo a vuestra imaginación.

Aunque no puedo dar mucha información sobre aspectos técnicos de la investigación (una pena ya que todo esto es propiedad del IUICP), sí puedo comentar el proceso que realicé, que puede dar una orientación a otras personas interesadas en este tipo de investigaciones.

Lo primero que analicé fue el protocolo usado por LINE para envío y recepción de mensajes. Debajo se puede ver una imagen con el esquema del protocolo de mensajes.

Resumiendo:

1. Un Emisor escribe un mensaje y lo envía.

2. Los Servidores de LINE lo reciben y le asignan un identificador único de mensaje (server_id) y una fecha de recepción (created_time).

3. Los servidores envían a Emisor server_id y created_time.

4. Los servidores envían a Receptor el mensaje, server_id y created_time.

En un segundo bloque, separado por Android o iOS, llevé a cabo el análisis de:

1. El sistema de archivos que utiliza LINE. En este apartado, se analiza el directorio de instalación, dónde se encuentran las bases de datos, dónde se almacenan los ficheros multimedia enviados/recibidos así como las fotos de perfil de los contactos…

2. Análisis de las bases de datos (donde se almacenan los mensajes).

  • Análisis relacional: Relación entre tablas usando sus registros.
  • Análisis de los registros: Saber qué almacena cada columna de cada tabla de la base de datos.

3. Análisis forense.

  • Ficheros de configuración: Obtención de más información, como el nombre de usuario y la foto de perfil.
  • Bases de datos: Se analiza cómo es la estructura de los mensajes una vez almacenados mediante un editor hexadecimal.

Por último, en un tercer bloque describo las aplicaciones desarrolladas a partir de las que se demuestra que es posible recuperar conversaciones desde una base de datos de LINE:

  • Lector de mensajes: Obtiene las mensajes de la base de datos y los maqueta en una interfaz HTML.
  • Recuperación de mensajes eliminados: Mediante técnicas de data-carving en busca de datos como server_id, quedando al descubierto que sí es posible recuperar mensajes eliminados de la base de datos, tanto de conversaciones normales como secretas.

Comparto a continuación la presentación que utilicé en las II Jornadas de Seguridad y Ciberdefensa de la Universidad de Alcalá, que contiene algunos detalles más del funcionamiento de LINE de los indicados arriba. Seguiré con el proyecto que llevan a cabo las Fuerzas y Cuerpos de Seguridad del Estado, analizando otras aplicaciones de mensajería instantánea y publicando en Security Art Work los avances que haga.

Peritos informáticos forenses: Legislación, verdades y mentiras

9 de septiembre de 2014 Por

Los delitos informáticos están de moda (y lo que les queda). Fraudes, robo de datos personales y bancarios, amenazas, pornografía infantil, blanqueo de capitales… la lista es larga, y solo limitada por la imaginación, la naturaleza humana y la legislación vigente.

Entre el aumento de los delitos, la mejora de la legislación (que hasta hace relativamente pocos años no equiparaba delitos informáticos con sus equivalentes físicos) y el excelente trabajo de las FCSE, cada día llegan a los juzgados más casos relacionados con las TIC.

Y dado que los jueces no son omniscientes, en ocasiones es necesario que recurran a terceras personas. Según la RAE, un perito se define como “persona que, poseyendo determinados conocimientos científicos, artísticos, técnicos o prácticos, informa, bajo juramento, al juzgador sobre puntos litigiosos en cuanto se relacionan con su especial saber o experiencia”.

[Read more…]

Herramienta forense Log2Pcap

3 de mayo de 2013 Por

A principios de septiembre tenía que escribir un artículo para presentarlo como propuesta para la certificación GOLD GCIA de GIAC (SANS). Este documento tenía que estar relacionado con el tráfico de red y la detección de intrusos, orientado al análisis forense.

Del conjunto de distintas ideas que tenía en mente, pensé en las veces que me había encontrado con un registro (log) de un servidor Web, en el que se requería emplear expresiones regulares usando listas blancas y negras de patrones que identificasen de entre todas las entradas del registro cuáles podían identificar un incidente de seguridad.

Adicionalmente a las listas negras y blancas, tenemos una serie de herramientas de detección de intrusos a nivel de sistema, donde dado un registro de un servidor es capaz de detectar alertas a partir de unas reglas previamente creadas. Un ejemplo de estas herramientas fue expuesto con anterioridad por José Luis Chica donde se empleó la herramienta OSSEC.

Teniendo en cuenta estos motores de reglas, uno de los entornos con mayor número de reglas son las herramientas de detección de intrusos a nivel de red, como por ejemplo Snort. El principal problema de las herramientas de detección de intrusos a nivel de red es que los datos de entrada requieren justamente eso: tráfico de red, pero el técnico dispone del registro del servidor y no del tráfico de red que lo generó.

Por tanto, para poder usar estos motores de reglas es necesario ser capaz de leer ese registro de entrada y a partir de éste, generar el tráfico de red oportuno, de forma que dicho tráfico de red pueda ser inyectado en una herramienta de detección de intrusos a nivel de red. Con esta idea programé una pequeña herramienta (prueba de concepto), la cual es capaz de leer el fichero de registro de un ISS, Apache, Nginx o IBM Web Seal y guardar en un fichero PCAP el tráfico de red que generó dicho registro.

Para entenderlo mejor vamos a ver un ejemplo de uso de la herramienta, donde se dispone de un registro de un servidor web Apache donde una IP atacante (y ficticia) ha realizado una auditoría Web con la herramienta Nikto:

Por ello vamos a proceder a usar la herramienta Log2Pcap para que recree el tráfico de red correspondiente al registro del servidor. Lo primero es indicar donde está el fichero del registro, que se trata de un servidor Apache, la IP y puerto del servidor Web que ha sido auditado:

Como resultado tenemos un fichero llamado “result.pcap” que ocupa 168 K. Dicho fichero ya puede ser leído por todas las herramientas de red que tengan la capacidad de leer el fichero PCAP, como por ejemplo Tcpdump o Tcpflow:

De la misma forma que puede ser inyectado en este tipo de herramientas, también puede ser inyectado en un Snort para que emplee el motor de reglas en búsqueda de posibles ataques:

Dando como resultado las siguientes alertas:

El código fuente de la herramienta lo podéis encontrar aquí mientras que la documentación la tenéis explicada aquí. Siento que el inglés no sea el mejor pero el documento fue escrito hace aproximadamente cinco meses.

Respecto a la evolución de la herramienta, la segunda versión está casi terminada. La herramienta ha sido prácticamente reescrita desde cero y se han añadido funcionalidades como poder inyectar el tráfico a un interfaz de red sin ser necesaria la creación del fichero PCAP, API orientada a objetos e integración con Plaso.

En lo concerniente a las limitaciones la más importante es obvia: se depende totalmente de la integridad y de la información almacenada en dicho registro. Durante el desarrollo de la herramienta caí en la cuenta que prácticamente la mayoría de servidores web no registran por defecto las variables enviadas por POST. Por lo tanto, aunque la herramienta está preparada para leer registros con parámetros POST, si el servidor no está configurado adecuadamente se está perdiendo mucha información. La segunda limitación viene dada al intentar establecer una línea de tiempo, puesto que en ningún momento la herramienta relaciona la alerta de Snort con la entrada del registro que generó la alerta.

Otro punto importante a entender es que la herramienta no pretende sustituir a las expresiones regulares, a los motores de detección de intrusos a nivel de host o cualquier otro método usado previamente. El objetivo de la herramienta es ofrecer otra opción más que pueda proporcionar más información al técnico que gestione el incidente.

Para evitar confusión quiero comentar que existe otra herramienta perteneciente al motor de Samba que usa el mismo nombre. La cual hace justamente lo que su nombre indica: coge un fichero samba y genera un fichero PCAP. He de reconocer que nunca he usado dicha herramienta y que no conocía la existencia de la misma. Ambas tienen propósitos totalmente distintos, protocolos distintos y nada en común. He mantenido el nombre Log2Pcap porque es la metodología de nombre empleado para este tipo de herramienta. Posiblemente en la segunda versión, y dada las nuevas funcionalidades, le cambiaré el nombre a LogWeb2Net.

Para finalizar agradecería que los lectores me enviasen el fichero log de cualquier otro servidor Web no soportado hasta la fecha, lógicamente anonimizado antes del envío. Con un par de líneas donde se traten diferentes métodos como GET y POST sería suficiente.

Análisis de estadísticas de red como herramienta de detección de incidentes

26 de abril de 2013 Por

Las estadísticas de red, o network flows, son datos recopilados del tráfico de una red que básicamente suele consistir en registros de cada una de las conexiones. Pueden ser IP origen y destino, protocolo, número de paquetes enviados/recibidos, tiempo de conexión, etc. Esta información se almacena en base de datos para sacar estadísticas, muy útiles para los administradores de red, y también como vamos a explicar hoy, para la gestión de incidentes.

Usualmente estos datos pueden exportarse directamente de la electrónica de red, en formato sFlow o NetFlow, este último formato propietario de Cisco. Algunas aplicaciones usuales para manejar estos datos suelen ser SiLK o Argus.

¿Qué ventajas tiene un gestor de estadísticas de red?

  • Recopila información sobre el tráfico, sin tener que capturar ni esnifar.
  • No importa si el tráfico va cifrado.
  • Es fácil de implementar.
  • Actúa como histórico para usarlo de consulta.
  • Es un excelente complemento para un IDS o IPS.

Con esta información, es posible detectar incidentes que se hayan producido si sabemos qué buscar y cómo buscarlo. Por poner un ejemplo, se podría hacer un timeline bastante preciso de una intrusión o verificar después de la contención de una infección que ésta ha sido efectiva. Veamos algunas técnicas para buscar posibles incidentes:

  • Filtrado: Se pueden acotar los datos a una IP concreta que previamente hemos detectado como sospechosa. De este modo se puede tener un registro detallado de su actividad, y deducir si sus acciones han sido maliciosas. También podría filtrarse por una franja horaria o un puerto concreto que sabemos opera algún malware determinado.
  • Tráfico normal vs tráfico anómalo: identificando cual es el tráfico normal en una red, se puede identificar de forma sutil el tráfico anómalo y potencialmente malicioso a toda actividad que se salga del patrón habitual. Tráfico entrante hacia un puerto no identificado puede traducirse a un posible backdoor en un servidor. Así también sería posible detectar algún indicio de ataque dirigido.
  • “Dirty Values”: En análisis forense es habitual disponer una lista de valores predefinida a buscar. Como aquí no se tiene el contenido del tráfico, los patrones a buscar serían, por ejemplo, listados de direcciones IP maliciosas, como las disponibles en abuse.ch o Shadowserver.
  • Patrones de actividad: los incidentes de seguridad suelen identificarse por un comportamiento muy concreto. Conociendo el patrón que siguen, se puede detectar. Si la tarea se automatiza y se parametriza de acuerdo al entorno de la organización, se tendría una poderosa herramienta de detección de incidentes.

Con las técnicas descritas, a modo de ejemplo vamos a enumerar varios casos de incidentes y sus comportamientos habituales:

Botnets / Malware:

  • Incremento de peticiones DNS, mucho más de lo usual, o más que los demás hosts. Típico para el malware que usa fast-flux.
  • Tráfico SMTP, RPC, SMB o IRC inusual.
  • Tráfico de 1 origen y N destinos.

Escaneos

  • Tráfico de 1 origen y N destinos y excesivos paquetes SYN sin contestar.

DDOS

  • Tráfico de N orígenes y 1 destino y excesivos paquetes SYN sin contestar.

Fuga de datos / Servidor comprometido

  • Mucho tráfico saliente hacia una única IP.
  • Tráfico en horario poco habitual.

Más información:

Forense en discos SSD

5 de noviembre de 2012 Por

Estaba haciendo el otro día mis pinitos con django, cuando por una negligencia, borré una aplicación que ya tenía terminada. La web no era compleja, tenía pocas líneas de código y creía que la podría volver a tener en menos de un día, pero sin embargo, vi la ocasión como una oportunidad para aprender a hacer una recuperación de datos en un disco SSD.

La configuración del disco de este equipo es la siguiente: particionado GPT con varias particiones formateadas con ext4 (nada de LVM). Mi experiencia previa en este tipo de casos siempre ha sido utilizar las herramientas más conocidas en entornos GNU/Linux: sleuthkit, autopsy, testdisk y photorec (éstas dos últimas suelen venir en el mismo paquete), dd, grep…

Volviendo al caso, nada más darme cuenta de lo que había hecho intenté mantener la calma y seguir lo que suele ser mi procedimiento estándar: montar la partición en la que estaba el proyecto como sólo lectura y crear una imagen de la partición con la herramienta ‘dd‘, de manera que las nuevas interacciones con el disco no sobreescriban ningún dato.

Creada la imagen, mi primera opción fue testdisk, un software de análisis forense y recuperación de datos que me ha dado muy buenos resultados en el pasado. No obstante, en esta ocasión me decía que la partición estaba corrupta, por lo que no podía recuperar el contenido del disco. A día de hoy, desconozco si fue por un error mío en las múltiples opciones que ofrece testdisk, o si bien por el contrario esta herramienta no se lleva bien con discos SSD o con particiones GPT.

Tras un primer intento fallido, probé suerte con sleuthkit y autopsy. En esta ocasión, todo iba como la seda. Tras establecer los parámetros iniciales del caso, empecé a “jugar” con las opciones de autopsy:

No obstante, parecía que el procedimiento iba para rato, ya que la imagen de disco tenía cierto tamaño y estaba almacenada en un disco duro externo USB. Como no me apetecía estar delante del PC sin hacer nada un viernes de madrugada, cancelé los procesos de sleuthkit y me puse a utilizar photorec.

Con photorec la cosa cambió: en cuestión de segundos, estaba recuperando multitud de ficheros, algunos de ellos borrados hacía meses. Como iba para rato, pero había podido comprobar que estaba haciendo su tarea, decidí dejar el proceso ejecutándose y continuar la mañana siguiente. Cual fue mi sorpresa al día siguiente al ver que photorec había encontrado unos cuantos miles de ficheros de tipo texto (extensiones txt, java (en este equipo nunca he programado en Java), html, py…).

Dado el gran número de ficheros, nada mejor que un poco de grep y unas cuantas expresiones regulares para encontrar el directorio y los ficheros que me interesaban. Al ser código en python, empleé sentencias que serían únicas de python, como import, nombres de variables que recordaba, tags html…

Al cabo de unas cuentas horas, pese a que parecía que había recuperado casi la totalidad del proyecto y que si faltaba algo podría recodificarlo, había una cosa extraña: el número de ficheros que tenía ahora del proyecto era más del triple del número de ficheros que tenía originalmente. Tras ojear los ficheros para poder cambiarles el nombre por el original (photorec tiene una pega: cambia el nombre del fichero por caracteres alfanuméricos, e incluso hay veces que no detecta correctamente la extensión del fichero), vi que muchos ficheros se correspondían con el mismo y que muchos otros no estaban completos.

Descarté en seguida que se tratara de copias de seguridad: no había considerado que fuese necesario crear una copia de seguridad para un proyecto como éste. Además, ¿qué sería de la vida sin pequeñas emociones? (N.d.E.: niños, no hagáis caso a este insensato)

Mirando los ficheros detenidamente, pude ver como los ficheros se correspondían a versiones viejas de los mismos, como si cuando hubiese hecho un cambio y lo hubiese guardado en disco, se creara un nuevo fichero y se borrase el viejo, almacenándose cada uno en secciones diferentes del disco. También había unos cuantos ficheros parciales, en los que se veían funciones del código pero no todas las que coexistían en el mismo fichero.

Tras indagar un poco, pude discernir entre “versiones”, realizar varias pruebas en la aplicación y ver que líneas tenía que añadir, borrar o modificar para tener la aplicación tal y como la tenía antes. No obstante, se me planteaban nuevas cuestiones. ¿Guarda eclipse varias versiones del mismo fichero? ¿Es cosa del Sistema Operativo? ¿Es por utilizar un disco SSD?

Como muchos lectores ya se habrán imaginado, el causante de este comportamiento es la forma en la que el disco SSD almacena los datos. Sin embargo, me gustaría dejar los detalles técnicos para una próxima entrega, más técnica y menos teórica que la actual.

Nos vemos en la próxima!