Aunque el primer motivo que le habrá llevado a la recopilación de evidencias sobre el incidente sea la resolución del mismo, puede que las necesite posteriormente para iniciar un proceso judicial contra sus atacantes y en tal caso deberá documentar de forma clara cómo ha sido preservada la evidencia tras la recopilación. En este proceso, como se expondrá a continuación, es imprescindible definir métodos adecuados para el almacenamiento y etiquetado de las evidencias.
Muy bien, ya tenemos la evidencia del ataque, ahora veremos que ha de continuar siendo metódico y sobre todo conservando intactas las “huellas del crimen”, debe asegurar esa evidencia a toda costa, por lo tanto ¡NI SE LE OCURRA COMENZAR EL ANÁLISIS SOBRE ESA COPIA!.
Como primer paso deberá realizar dos copias de las evidencias obtenidas, genere una suma de comprobación de la integridad de cada copia mediante el empleo de funciones hash.
tales como MD5 o SHA1. Incluya estas firmas en la etiqueta de cada copia de la evidencia sobre el propio CD o DVD, incluya también en el etiquetado la fecha y hora de creación de la copia, nombre cada copia, por ejemplo “COPIA A”, “COPIA B” para distinguirlas claramente del original. Traslade estos datos a otra etiqueta y péguela en la caja contenedora del soporte, incluso sería conveniente precintar el original para evitar su manipulación inadecuada.
Si además decide extraer los discos duros del sistema para utilizarlos como evidencia, deberá seguir el mismo procedimiento, coloque sobre ellos la etiqueta “EVIDENCIA ORIGINAL”, incluya además las correspondientes sumas hash, fecha y hora de la extracción del equipo, datos de la persona que realizó la operación, fecha, hora y lugar donde se almacenó, por ejemplo en una caja fuerte. Piense, además, que existen factores externos como cambios bruscos de temperatura o campos electromagnéticos que pueden alterar la evidencia. Toda precaución es poca, incluso si decide enviar esos discos a que sean analizados por empresas especializadas solicite que los aseguren por un importe similar a los daños causados en sus equipos.
Otro aspecto a tener en cuenta, y que está relacionado con el comentario anterior, es el proceso que se conoce como la cadena de custodia, donde se establecen las responsabilidades y controles de cada una de las personas que manipulen la evidencia. Deberá preparar un documento en el que se registren los datos personales de todos los implicados en el proceso de manipulación de las copias, desde que se tomaron hasta su almacenamiento. Sería interesante documentar:
- Dónde, cuándo y quién manejo o examinó la evidencia, incluyendo su nombre, su cargo, un número identificativo, fechas y horas, etc.
- Quién estuvo custodiando la evidencia, durante cuanto tiempo y dónde se almacenó.
- Cuando se cambie la custodia de la evidencia también deberá documentarse cuándo y como se produjo la transferencia y quién la transportó.
Todas estas medidas harán que el acceso a la evidencia sea muy restrictivo y quede claramente documentado, posibilitando detectar y pedir responsabilidades ante manipulaciones incorrectas a intentos de acceso no autorizados.
Análisis de la evidencia :
Una vez que disponemos de las evidencias digitales recopiladas y almacenadas de forma adecuada, pasemos a la fase quizás más laboriosa, el Análisis Forense propiamente dicho, cuyo objetivo es reconstruir con todos los datos disponibles la línea temporal del ataque o timeline, determinando la cadena de acontecimientos que tuvieron lugar desde el instante inmediatamente anterior al inicio del ataque, hasta el momento de su descubrimiento.
Este análisis se dará por concluido cuando conozcamos cómo se produjo el ataque, quién o quienes lo llevaron a cabo, bajo qué circunstancias se produjo, cuál era el objetivo del ataque, qué daños causaron, etc.
En el siguiente apartado se describirá este proceso de análisis empleando las herramientas propias del sistema operativo que se emplee como anfitrión y las que recopiló en su ToolKit, de esta forma se pretende dar una visión amplia del proceso que ayudará a comprender mejor el funcionamiento de las herramientas específicas para el análisis forense de sistemas que se expondrán más adelante.
Preparación para el análisis: El entorno de trabajo:
Antes de comenzar el análisis de las evidencias deberá acondicionar un entorno de trabajo adecuado al estudio que desee realizar. Si se decanta por no tocar los discos duros originales ¡muy recomendable!, y trabajar con las imágenes que recopiló como evidencias, o mejor aún con una copia de éstas, tenga en cuenta que necesitará montar esas imágenes tal cual estaban en el sistema comprometido.
Si dispone de recursos suficientes prepare dos estaciones de trabajo, en una de ellas, que contendrá al menos dos discos duros, instale un sistema operativo que actuará de anfitrión y que le servirá para realizar el estudio de las evidencias . En ese mismo ordenador y sobre un segundo disco duro, vuelque las imágenes manteniendo la estructura de particiones y del sistema de archivos tal y como estaban en el equipo atacado. En el otro equipo instale un sistema operativo configurado exactamente igual que el del equipo atacado, además mantenga nuevamente la misma estructura de particiones y ficheros en sus discos duros. La idea es utilizar este segundo ordenador como “conejillo de Indias” y realizar sobre él pruebas y verificaciones conforme vayan surgiendo hipótesis sobre el ataque.
Si no dispone de estos recursos, puede utilizar software como VMware, que le permitirá crear una plataforma de trabajo con varias máquinas virtuales (varios equipos lógicos independientes funcionando sobre un único equipo físico). También puede decantarse por una versión LIVE de sistemas operativos como Linux, que le permitirá interactuar con las imágenes montadas pero sin modificarlas. Pero si tuvo la “feliz idea” de hacer que su ToolKit en CD o DVD fuese autoarrancable, ahora es el momento de utilizarlo.
Si está muy seguro de sus posibilidades y de lo que va a hacer, puede conectar los discos duros originales del sistema atacado a una estación de trabajo independiente para intentar hacer un análisis “en caliente” del sistema, deberá tomar la precaución de montar los dispositivos en modo sólo lectura, esto se puede hacer con sistemas anfitriones UNIX/Linux, pero no con entornos Windows.
Reconstrucción de la secuencia temporal del ataque:
Supongamos que ya tenemos montadas las imágenes del sistema comprometido en nuestra estación de trabajo independiente y con un sistema operativo anfitrión de confianza. El primer paso que deberá dar es crear una línea temporal de sucesos o timeline, para ello recopile la siguiente información sobre los ficheros:
- Inodos asociados.
- Marcas de tiempo MACD (fecha y hora de modificación, acceso, creación y borrado).
- Ruta completa.
- Tamaño en bytes y tipo de fichero.
- Usuarios y grupos a quien pertenece.
- Permisos de acceso. 9 Si fue borrado o no.
Sin duda esta será la información que más tiempo le llevará recopilar, pero será el punto de partida para su análisis, podría plantearse aquí dedicar un poco de tiempo a preparar un script que automatizase el proceso de creación del timeline, empleando los comandos que le proporciona el sistema operativo y su ToolKit.
Para comenzar ordene los archivos por sus fechas MAC, esta primera comprobación, aunque simple, es muy interesante pues la mayoría de los archivos tendrán la fecha de instalación del sistema operativo, por lo que un sistema que se instaló hace meses y que fue comprometido recientemente presentará en los ficheros nuevos, inodos y fechas MAC muy distintas a las de los ficheros más antiguos.
La idea es buscar ficheros y directorios que han sido creados, modificados o borrados recientemente, o instalaciones de programas posteriores a la del sistema operativo y que además se encuentren en rutas poco comunes. Piense que la mayoría de los atacantes y sus herramientas crearán directorios y descargarán sus “aplicaciones” en lugares donde no se suele mirar, como por ejemplo en los directorios temporales.
A modo de guía céntrese primero en buscar los archivos de sistema modificados tras la instalación del sistema operativo, averigüe después la ubicación de los archivos ocultos y écheles un vistazo a ver dónde están y de qué tipo son, busque también los archivos borrados o fragmentos de éstos, pues pueden ser restos de logs y registros borrados por sus atacantes. Aquí cabe destacar nuevamente la importancia de realizar imágenes de los discos pues podremos acceder al espacio residual que hay detrás de cada archivo, (recordemos que los ficheros suelen almacenarse por bloques cuyo tamaño de clúster depende del tipo de sistema de archivos que se emplee), y leer en zonas que el sistema operativo no ve.
Piense que está buscando “una aguja en un pajar”, por lo que deberá ser metódico, vaya de lo general a lo particular, por ejemplo parta de los archivos borrados, intente recuperar su contenido, anote su fecha de borrado y cotéjela con la actividad del resto de los archivos, puede que en esos momentos se estuviesen dando los primeros pasos del ataque.
Sin perder de vista ese timestamp anterior, comience a examinar ahora con más detalle los ficheros logs y de registros que ya ojeó durante la búsqueda de indicios del ataque, intente buscar una correlación temporal entre eventos. Piense que los archivos log y de registro son generados de forma automática por el propio sistema operativo o por aplicaciones específicas, conteniendo datos sobre accesos al equipo, errores de inicialización, creación o modificación de usuarios, estado del sistema, etc. Por lo que tendremos que buscar nuevamente entradas anómalas y compararlas con la actividad de los ficheros. Edite también el archivo de contraseñas y busque la creación de usuarios y cuentas extrañas sobre la hora que considere se inició el compromiso del sistema.
Siguiendo con el ejemplo que se expuso en el apartado 3.1.1., en el fragmento del archivo /var/log/messages se detectaron dos accesos FTP, al examinar la actividad de los ficheros se descubrió que sobre esa fecha y hora se crearon varios archivos bajo el directorio /var/ftp de la máquina comprometida (directorio raíz del servicio ftp en sistemas UNIX/Linux), que además había sido borrado por el atacante. Al ser recuperado, se encontró la descarga de archivos que eran propiedad de usuario root (administradores del sistema) surgiendo la pregunta ¿qué hacía el administrador descargando archivos a esas horas?, el archivo recuperado era un conocido rootkit, se comprobó mediante el estudio del archivo de registro, que momentos después el atacante descomprimió, compiló y ejecutó sus “herramientas”, acto seguido (segundos después) se observa que un gran número de archivos de comandos del sistema operativo son modificados.
Este pequeño ejemplo es representativo de cómo ha de utilizar el timestamp para hacerse una idea más o menos certera de la cadena de eventos que se produjo.
