Informática Forense - Adquisición de Evidencias Digitales en Vivo PDF

Informática Forense Adquisición de evidencias digitales en vivo 1 Adquisición de evidencias en vivo Adquisición de evidencias en vivo 2 Análisis en vivo ▪ La obtención de evidencias forenses digitales de dispositivos encendidos (en vivo o...

Informática Forense Adquisición de evidencias digitales en vivo 1 Adquisición de evidencias en vivo Adquisición de evidencias en vivo 2 Análisis en vivo ▪ La obtención de evidencias forenses digitales de dispositivos encendidos (en vivo o en caliente) comprende el conjunto de acciones a llevar a cabo en aquellos dispositivos que se encuentran en funcionamiento en el momento de su intervención por el equipo forense. Adquisición de evidencias en vivo 3 Análisis en vivo ▪ Ventajas de este escenario con respecto al escenario de obtención de evidencias de dispositivos apagados: ▪ Posibilidad de obtención de información de carácter volátil (es decir, no persistente), la cual desaparece con el apagado o el reinicio del dispositivo. ▪ Pequeño impacto en la operatividad del sistema (p.e. no existe tiempo de caída del sistema, esta característica es de especial importancia a la hora de extraer información de sistemas críticos) durante el proceso de obtención de evidencias digitales. Adquisición de evidencias en vivo 4 Análisis en vivo ▪ La recopilación de datos se realiza con el dispositivo encendido, y su sistema operativo, servicios y herramientas en ejecución. ▪ El investigador estará logueado en el sistema (bien usando la consola local, el GUI o usando un software de acceso remoto). ▪ La obtención de evidencias se llevará a cabo usando los recursos disponibles en el propio sistema objeto de la investigación. ▪ Si fuera preciso recurrir a herramientas software específicas, es preciso que el investigador las lleve compiladas estáticamente en un pendrive USB, en un medio óptico o ejecutarlas de manera remota. Así se reduce el impacto potencial sobre los datos que han de ser adquiridos y se evitan inconvenientes debidos a posibles presencias de rootkits o troyanos en el sistema. Adquisición de evidencias en vivo 5 Análisis en vivo ▪ En muchas ocasiones un análisis en caliente resulta imprescindible para conocer el estado en el que se encuentra el sistema cuando el perito llega al lugar de los hechos. Pero hay que tener en cuenta que las propias acciones llevadas a cabo por el investigador contaminarán el escenario (p.e. al ejecutar herramientas desde la consola del sistema), por lo que se deben documentar de manera pertinente como apoyo para la posterior fase de análisis de las evidencias. ▪ Se debe intentar minimizar al máximo la alteración o impacto en el sistema, con vistas a su análisis posterior, pudiendo entonces emplearse la metodología utilizada con los dispositivos apagados. ▪ Una vez adquirida la información volátil, si fuera posible y el caso lo precisa, se apaga el sistema, preferiblemente de forma no ordenada, es decir, interrumpiendo la alimentación eléctrica. Adquisición de evidencias en vivo 6 Análisis en vivo ▪ La recopilación de datos altamente volátiles será equivalente a una “fotografía” (snapshot) del instante en el cual se produjo la recopilación de evidencias, pudiendo variar los resultados de manera notoria dependiendo del instante en el cual se realice la captura (mejor evidencia). ▪ Estos datos serán de especial importancia cuando el objeto de la investigación es determinar la presencia de actividad potencialmente maliciosa en el sistema, pero también pueden permitir recopilar credenciales que habiliten el acceso a potenciales fuentes de evidencias (p.e. perfiles del usuario en redes sociales, correo electrónico web, almacenamiento en la nube, volúmenes cifrados,…). Adquisición de evidencias en vivo 7 Análisis en vivo ▪ Para intentar asegurar la validez forense de estas evidencias, dejando claro que toda adquisición de un sistema en funcionamiento conlleva el uso de técnicas intrusivas, se deberían seguir las siguientes recomendaciones: ▪ El perito encargado de la adquisición de evidencias debe documentar perfectamente todos los procesos efectuados. ▪ Estas técnicas no permiten su reproducibilidad. ▪ Las fuentes de evidencia son dinámicas (el contenido de la memoria, los archivos temporales, el registro del sistema operativo, etc.). ▪ La validez de los resultados obtenidos, a partir de una snapshot, ante un tribunal dependería en gran parte de la correcta justificación en el informe pericial. Adquisición de evidencias en vivo 8 Análisis en vivo ▪ El informe pericial debe detallar la metodología seguida para la adquisición efectuada en los sistemas en funcionamiento, así como si se ha minimizado al máximo dicho efecto intrusivo utilizando dispositivos hardware adecuados, o vía software, activando comandos perfectamente conocidos (p.e. scripts validados para los procesos de obtención de la organización), caso del acceso a los datos de la evidencia a través de un entorno remoto. ▪ En estos casos, el cálculo del valor del hash es dinámico. ▪ Según el instante temporal en que se efectúe el cálculo del resumen, se obtendrá un resultado diferente. ▪ Es una buena práctica generar el hash de la evidencia digital generada, pues permite identificar de forma única la evidencia, garantizando así la posibilidad de contrastar la integridad de cualquier copia que se realice de la evidencia digital adquirida con posterioridad. Adquisición de evidencias en vivo 9 Análisis en vivo ▪ El perito responsable de la obtención de evidencias debe: ▪ Prestar especial atención ante la posible presencia en el dispositivo de medidas antiforenses (p.e. esteganografía, discos con cifrado full-disk), y/o en las investigaciones donde el dispositivo a investigar pudiera existir una infección por malware. ▪ Utilizar su propio kit de herramientas del sistema (versión portable, preferiblemente) para soslayar una posible contaminación de la adquisición de evidencias si se hiciese uso de las propias herramientas instaladas en el sistema operativo del dispositivo a analizar en el caso de que se encontrase comprometido por algún tipo de malware. Adquisición de evidencias en vivo 10 Análisis en vivo de dispositivos móviles ▪ La obtención de evidencias en vivo de dispositivos móviles se ve afectada por la característica de estos dispositivos de poder interactuar con redes inalámbricas (Wifi, Bluetooth) y/o de telefonía móvil (GSM, 3G, 4G, 5G). Por ello, los dispositivos móviles se deben proteger o aislar electromagnéticamente de manera adecuada (p.e. bolsa de Faraday, jaula de Faraday) con el objetivo de: ▪ Garantizar que durante su manipulación no puedan conectarse utilizando sus interfaces de red a las citadas redes. ▪ Evitar una manipulación accidental por parte del equipo de obtención de evidencias o maliciosa en remoto por parte del propietario del dispositivo pueda dañar o destruir la información almacenada en el dispositivo. Adquisición de evidencias en vivo 11 Análisis en vivo de dispositivos móviles ▪ Una buena praxis de obtención de evidencias de dispositivos móviles encendidos consiste en seguir las siguientes recomendaciones: ▪ Realizar un proceso de copia o clonado de las partes accesibles de la tarjeta SIM original, empleando para ello un lector de tarjetas con su software específico, e introducir esta tarjeta clon en el dispositivo móvil. ▪ La tarjeta clon carece de las claves de acceso a la red de telefonía móvil de la tarjeta SIM original. Esto impide que el dispositivo móvil se conecte a dicha red, evitando así tener que procesar las evidencias en el interior de una jaula de Faraday (elevado coste y tecnológicamente complejo de construir) o entorno de similares características. ▪ Con la tarjeta clon insertada se realizará una copia a bajo nivel (conocida también como extracción física) de los datos en la memoria o memorias internas del dispositivo móvil. Adquisición de evidencias en vivo 12 Análisis en vivo de dispositivos móviles ▪ No obstante, existen casos en los cuales las herramientas hardware/software específicas para forense de dispositivos móviles no soportan la copia física del modelo concreto objeto de la investigación. Alternativas: ▪ Algunos dispositivos permiten realizar una extracción lógica (copia de los datos activos desde el sistema de archivos del dispositivo móvil). ▪ La extracción lógica no permite obtener la misma información que la extracción física, no pudiendo por ejemplo realizar una reconstrucción (carving) de información perdida o eliminada (accidental o intencionadamente) o acceder al espacio no utilizado de la memoria del dispositivo. ▪ Proceder como en el caso de los sistemas apagados. Es decir, extraer la información directamente de la memoria del dispositivo utilizando para ello dispositivos hardware, para, posteriormente, emplear un software de análisis de datos capaz de interpretar el volcado realizado. Adquisición de evidencias en vivo 13 Análisis en vivo de dispositivos móviles ▪ Además, en aquellos escenarios en los cuales no se pueda proceder a una extracción física o lógica de la información (p.e. al no encontrarse activa la opción ADB en un dispositivo móvil con sistema operativo Android), existen dos alternativas: ▪ Reflejar en el informe pericial la información visualizada en la pantalla del dispositivo móvil. ▪ En este caso, es altamente recomendable grabar en soporte audiovisual todo el proceso de obtención de evidencias para adjuntarlo como prueba pericial. ▪ Extraer la información del dispositivo empleando técnicas de manipulación de su hardware (p.e. JTAG, chip-off). Adquisición de evidencias en vivo 14 Análisis en vivo de dispositivos móviles ▪ Una vez finalizado la adquisición de evidencias del dispositivo móvil, el perito no debe introducir ni la batería ni la tarjeta SIM original en el dispositivo con la finalidad de impedir la alteración del archivo de localización (LOCI, LOCation Information) de la SIM, unido a la modificación del listado de llamadas almacenadas. ▪ Una vez realizado el volcado de la información de las diferentes memorias (p.e. NAND, microSD) se debe obtener su valor resumen para garantizar la integridad de los datos extraídos. Adquisición de evidencias en vivo 15 Volcado y análisis de la memoria Adquisición de evidencias en vivo 16 Volcado y análisis de la memoria ▪ El volcado de memoria (core dump o memory dump) es un registro no estructurado del contenido de la memoria en un momento concreto. ▪ El volcado de memoria es uno de los aspectos más importantes y críticos de la fase de adquisición de evidencias en vivo ya que su contenido puede resultar decisivo en una investigación forense pues se pueden hallar evidencias significativas como: ▪ Conexiones establecidas. ▪ Procesos en ejecución. ▪ Contraseñas (web, correo, volúmenes cifrados) en texto claro. ▪ Líneas de comando tecleadas por los usuarios. ▪ Imágenes completas de los ejecutables. ▪ Rastros de procesos antiguos ejecutados por los usuarios. ▪… Adquisición de evidencias en vivo 17 Volcado y análisis de la memoria ▪ Realizar un correcto volcado de memoria puede suponer la diferencia entre la resolución de la investigación o no. Debido a ello, se debe ser muy cuidadoso durante el proceso. ▪ Una vez obtenida la imagen correspondiente al volcado de memoria física es necesario obtener un resumen hash de esta, que se reflejará en la documentación de la cadena de custodia para asegurar que dicha imagen no sea modificada a posteriori y garantizar la integridad de evidencia. Adquisición de evidencias en vivo 18 Volcado y análisis de la memoria ▪ A la hora de obtener la memoria se deben tener en cuenta el sistema operativo sobre el que se va a realizar la adquisición y dos tipos de memoria: ▪ La memoria física corresponde a la memoria real del sistema. ▪ La memoria virtual corresponde normalmente al fichero de paginación pagefile.sys (Windows) o una partición swap. ▪ La memoria virtual permite optimizar el uso de la memoria RAM ya que el sistema operativo envía ahí, de manera temporal, la información que no es necesaria en ese momento para los procesos en ejecución y posteriormente la recupera en el caso de alguno la solicite. Adquisición de evidencias en vivo 19 Volcado y análisis de la memoria ▪ El manejo de los dispositivos en los sistemas Unix está gobernado por unos ficheros virtuales especiales, los ficheros de dispositivo. ▪ El fichero de dispositivo que gestiona la memoria es /dev/mem. Los métodos para volcar la memoria lo utilizan. ▪ Una de las formas más conocida para el volcado de la memoria es el comando memdump. ▪ En algunos sistemas ejecutar este comando conlleva a un fallo total de nuestro sistema → kernel panic → reinicio del sistema. ▪ Es por ello por lo que, en un entorno de una investigación forense (y menos aún en un sistema en producción), no se debe hacer esto. Adquisición de evidencias en vivo 20 Volcado y análisis de la memoria ▪ Otra posibilidad para exportar el contenido de /dev/mem es utilizar el comando dd (herramienta de copia bit a bit): dd if=/dev/mem of=volcado.mem ▪ Lo más frecuente es que esté activa una restricción del kernel que limita la cantidad de datos que se leen del fichero se dispositivo de la memoria. ▪ Si lo está, el fichero generado por dd tendrá un tamaño esto nos devuelve un fichero de un tamaño inferior (habitualmente 1Mb) al total de RAM disponible en el sistema. ▪ La mejor opción es utilizar alguna herramienta de adquisición de la memoria volátil específica para tal fin. Adquisición de evidencias en vivo 21 LiME (Linux Memory Extractor) ▪ LiME es una herramienta desarrollada por 504ensics Labs, de código abierto, que permite la adquisición de la memoria volátil de sistemas Linux y dispositivos basados en Linux, y que trabaja a nivel de kernel. ▪ Repositorio: https://github.com/504ensicsLabs/LiME ▪ Doc: https://github.com/504ensicsLabs/LiME/tree/master/doc ▪ Como la herramienta está pensada para su uso forense, minimiza su interacción entre los procesos del espacio del usuario y del kernel durante la adquisición. Adquisición de evidencias en vivo 22 LiME (Linux Memory Extractor) ▪ LiME es un módulo de kernel cargable (LKM, Loadable Kernel Module) que facilita la adquisición de memoria de dispositivos basados en Linux, incluido Android. ▪ Garantiza capturas de memoria más sólidas desde el punto de vista forense en comparación con otras herramientas, lo que lo convierte en un activo crucial para el análisis de memoria. ▪ Permite la adquisición del volcado en distintos formatos: ▪ raw: todos los datos en la RAM se leen de manera continua y se concatenan al archivo de salida. ▪ padded: lee la RAM y rellena la RAM que no es del sistema con ceros. ▪ lime: crea una imagen específica de LiME de la RAM con encabezados de tamaño fijo que contienen información sobre el espacio de direcciones. ▪ Permite el envío del volcado por red. Adquisición de evidencias en vivo 23 LiME (Linux Memory Extractor) ▪ Para usarlo, lo habitual es es clonar (o descargar) la herramienta e instalar, si no lo están ya, los paquetes que precisa LiME (make, build-essential y linux-headers). Una vez instalados, procedemos a compilarla. # Clonar LiME git clone https://github.com/504ensicsLabs/LiME.git # Instalación de los paquetes requeridos # Para instalar linux-headers necesitamos conocer la versión de kernel usada uname -r sudo apt-get install make build-essential linux-headers #Compilar y generar el módulo cd LiME/src make Adquisición de evidencias en vivo 24 LiME (Linux Memory Extractor) ▪ Si todo ha ido bien, se ha generado un fichero (kernel object) con nombre lime-versiondelkernel-generic.ko. ▪ Es necesario compilar la herramienta usando la misma versión del kernel que la del sistema que se quiere volcar la memoria. ▪ Para realizar una adquisición de la memoria local: sudo insmod lime-version-generic.ko "path=./volcado.mem format=raw" Adquisición de evidencias en vivo 25 LiME (Linux Memory Extractor) ▪ También se puede hacer una adquisición de la memoria de manera remota. La adquisición remota se realiza en dos fases, la ejecución de LiME en la máquina objeto de la extracción y la ejecución de nc o de ncat en la máquina forense. ▪ En la máquina objeto, de la que se va a volcar la memoria: ▪ Debemos saber su IP (usando, por ejemplo, el comando ifconfig). ▪ Arrancamos LiME poniéndolo a la escucha: sudo insmod lime-version-generic.ko "path=tcp:4444 format=lime" Adquisición de evidencias en vivo 26 LiME (Linux Memory Extractor) ▪ En la máquina forense, la que va a adquirir el volcado, tenemos dos opciones para realizarlo, siendo muy similares. ▪ Usando el comando nc (paquete netcat). ▪ Usando el comando ncat (paquete nmap). ▪ Será necesario instalar el paquete correspondiente en cada caso, si no lo estuviera ya. # Adquisición usando el comando nc (netcat) nc ip_maquina_objeto 4444 > volcado.mem # Adquisición usando el comando ncat (nmap) ncat ip_maquina_objeto 4444 > volcado.mem Adquisición de evidencias en vivo 27 LiME (Linux Memory Extractor) ▪ Una alternativa que se puede usar es LiMEaide: ▪ Aplicación Python diseñada para volcar de forma remota o local la RAM de un cliente Linux y crear un perfil de Volatility para su posterior análisis. ▪ Repositorio: https://github.com/kd8bny/LiMEaide ▪ Por último, una vez finalizado el volcado no hay que olvidarse de descargar el módulo del kernel de LiME. # Listar los módulos del kernel sudo lsmod # Descargar el módulo del kernel LiME sudo rmmod lime Adquisición de evidencias en vivo 28 Volatility ▪ Volatility (https://volatilityfoundation.org) es un framework con un conjunto de herramientas desarrolladas en Python, con licencia GNU, que nos permitirá analizar un volcado de memoria desde una perspectiva forense. ▪ Permite extraer de fichero de volcado los datos volátiles que estaban en memoria RAM. ▪ Volatility funciona en cualquier sistema que ejecute Python. ▪ Versiones: ▪ Volatility → Python 2.6 → https://github.com/volatilityfoundation/volatility ▪ Volatility 3 → Python 3.x → https://github.com/volatilityfoundation/volatility3 Adquisición de evidencias en vivo 29 Volatility ▪ Volatility puede extraer de la imagen de volcado de la memoria la suficiente información relevante para obtener evidencias. Entre otras: ▪ Tipo de sistema, fecha y hora. ▪ Procesos que se estaban ejecutando. ▪ Puertos abiertos. ▪ Puertos conectados. ▪ DLLs cargadas por proceso. ▪ Ficheros cargados por procesos. ▪ Claves del registro utilizadas en los procesos. ▪ Módulos del kernel. ▪ Mapa físico de offsets a direcciones virtuales. ▪ Direccionamiento de memoria por proceso. ▪ Extracción de ejecutables. Adquisición de evidencias en vivo 30 Volatility ▪ Ventajas de Volatility: ▪ Marco único y coherente para analizar volcados de memoria RAM de 32 y 64 bits de Windows, Linux, macOS y sistemas Android. ▪ Open Source GPLv2. ▪ API ampliable y scriptable que le permite ampliarse y seguir innovando. ▪ Incluye funcionalidades basadas en características sin precedentes basadas en ingeniería inversa e investigación especializada. ▪ Tiene una cobertura completa de tipos de formatos. ▪ Algoritmos rápidos y eficientes que permiten analizar los volcados de memoria RAM de grandes sistemas sin consumo innecesario de memoria o sobrecarga. ▪ Comunidad seria y de gran alcance de profesionales e investigadores que trabajan en los campos de análisis forense, respuesta a incidentes y malware. ▪ Enfoque forense/respuesta a incidentes/malware. Adquisición de evidencias en vivo 31 Volatility ▪ Inconvenientes de Volatility: ▪ No realiza volcados. ▪ No tiene línea de comandos propia. ▪ Tiene una fuerte dependencia desde donde se realice el volcado. ▪ Antes de comenzar con el análisis es necesario crear (u obtener) un perfil específico para el sistema operativo que se va a analizar, ya que nos podemos encontrar con cientos de distribuciones y variedades de versiones de kernel. ▪ Repositorios con perfiles antiguos para diferentes versiones de Linux. ▪ https://github.com/volatilityfoundation/profiles ▪ https://github.com/KDPryor/LinuxVolProfiles Adquisición de evidencias en vivo 32 Volatility ▪ Para instalar Volatility basta con clonar (o copiar) la versión de la herramienta que se adecúe a la versión de Python que se tenga instalada. ▪ En los ejemplos de este tema se ha usado Volatility 2.6. ▪ La sintaxis puede variar de Volatility 2 a Volatility 3 (comparación entre ambos). # Volatility para Python 2.6 git clone https://github.com/volatilityfoundation/volatility.git # Volatility para Python 3.x git clone https://github.com/volatilityfoundation/volatility3.git # Establecer los enlaces simbólicos, variable de entorno PATH,... # Probar que funciona python vol.py --info # Ver información de una imagen de volcado de memoria python vol.py imageinfo –f volcado.mem Adquisición de evidencias en vivo 33 Volatility ▪ Para analizar el volcado, será necesario crear un perfil dwarf del sistema del cuál hemos hecho el volcado (1). ▪ DWARF es un formato de datos de depuración ampliamente utilizado y estandarizado. ▪ Un formato de datos de depuración es un medio de almacenar información sobre un programa informático compilado para su uso por depuradores de alto nivel.. ▪ Necesitamos saber la versión de sistema operativo y arquitectura de la máquina objeto. ▪ Podemos crear el perfil bien en la máquina objeto, bien en una máquina forense con la misma arquitectura y versión de sistema operativo. Adquisición de evidencias en vivo 34 Volatility ▪ Para analizar el volcado, será necesario crear un perfil dwarf del sistema del cuál hemos hecho el volcado (2). ▪ Instalar dwarfdump, que permite crear el fichero de cabecera con la estructura para esa plataforma y arquitectura (https://www.prevanders.net/dwarf.html). ▪ Ir a ruta volatility/tools/linux y compilar Module.c con make, nos generará un fichero denominado module.dwarf. ▪ Crear un zip con nombre nombreDistro-versiónKernel_profile.zip que contenga: ▪ volatility/tools/Linux/module.dwarf ▪ /boot/System.map-versiónKernel ▪ Copiar el zip creado a la ruta volatility/plugins/overlays/linux de la máquina forense. Adquisición de evidencias en vivo 35 Volatility # Instalar dwarfdump apt -y install dwarfdump # Crear el perfil # Compilar cd volatility/tools/linux make # Crear el zip export kernel=$(uname -r) export distro=$(lsb_release -i -s) zip -j "${distro}_${kernel}_profile.zip" module.dwarf "/boot/System.map-${kernel}" # Copiar mv XXXX_X.X.X-X-XXX_profile.zip ~/volatility/plugins/overlays/linux/ # Verificar python vol.py --info | grep profile Adquisición de evidencias en vivo 36 Volatility ▪ Analizando el volcado de memoria. ▪ La forma básica de ejecutar Volatility es: python vol.py -f --profile= comando|plugin ▪ Comandos. ▪ Operaciones base en el framework. ▪ https://github.com/volatilityfoundation/volatility/wiki/Command-Reference ▪ Plugins. ▪ Creados adhoc para cada sistema operativo. ▪ https://github.com/volatilityfoundation/volatility/wiki/Linux#using-the-plugins ▪ Para ver los disponibles (p.e. para linux): python vol.py --info | grep –i linux Adquisición de evidencias en vivo 37 Volatility # Muestra las interfaces activas python vol.py linux_ifconfig -f volcado.mem --profile=UbuntuXXXXX # Muestra la tabla ARP python vol.py linux_arp -f volcado.mem --profile=UbuntuXXXXX # Recuperar el historial bash de la memoria del proceso bash python vol.py linux_bash -f volcado.mem --profile=UbuntuXXXXX # Muestra los sockets abiertos python vol.py linux_netstat -f volcado.mem --profile=UbuntuXXXXX # Muestra los dispositivos fs montados python vol.py linux_mount -f volcado.mem --profile=UbuntuXXXXX # Muestra los módulos del kernel cargados python vol.py linux_lsmod -f volcado.mem --profile=UbuntuXXXXX Adquisición de evidencias en vivo 38