caso practico de informe experto de´ analisis forense digital´
Post on 19-Jul-2022
30 Views
Preview:
TRANSCRIPT
UNIVERSITAT POLITECNICA DE CATALUNYA
PROJECTE FINAL DE CARRERA
Caso practico de informe experto deanalisis forense digital
Autora:Helena TARIBO GOMEZ
Tutor:Abraham PASAMAR
DEPARTAMENT DE TELEMATICA
7 de julio de 2016
”The Truth Is Out There”
The X-Files
iii
Agradecimientos
Me gustarıa agradecer al Josep, Abraham y Oriol la oportunidad de realizar esteproyecto y de introducirme en el sector.
Un especial agradecimiento a Juanvi por todo lo que me ha ensenado, por su pa-ciencia y por los buenos consejos.
Gracias a Javi por haber sido tan buen companero durante todos estos meses depracticas, por lo bien que lo he pasado mientras nos formabamos.
Gracias a todo el equipo de INCIDE por lo que he aprendido con ellos y por el buenambiente que hay en la oficina.
Gracias a mis amigos por hacer que el estudio sea siempre mas ameno.
Gracias a mi familia y a mi pareja por todo el apoyo que siempre me han dado ypor la confianza que han depositado en mı.
v
Contents
1 Introduccion 11.1 Formacion en la UPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Formacion en INCIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Estructura del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Fases de un analisis forense 52.1 Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Documentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Preparacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Incidencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Respuesta a una incidencia . . . . . . . . . . . . . . . . . . . . . . . . . 102.6 Analisis forense digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6.1 Adquirir y autenticar . . . . . . . . . . . . . . . . . . . . . . . . . 112.6.2 Examinar y recolectar . . . . . . . . . . . . . . . . . . . . . . . . 112.6.3 Analisis de los datos . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Presentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Descripcion del caso practico a analizar 15
4 Funcionamiento de un disco duro 194.1 Geometrıa de un disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Particiones DOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3 Particiones Apple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4 NTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.4.1 MFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Funcionamiento del correo electronico 37
6 Herramientas usadas para el analisis 496.1 Adquisicion y aseguramiento . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Montaje del disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.3 Tratamiento de la informacion . . . . . . . . . . . . . . . . . . . . . . . . 516.4 Busqueda ciega de palabras clave y analisis heurıstico . . . . . . . . . 526.5 The Sleuth Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.6 Recuperacion de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.7 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
vii
7 Proceso de investigacion 577.1 Documentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577.2 Preparacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.3 Incidencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.4 Respuesta a la incidencia . . . . . . . . . . . . . . . . . . . . . . . . . . 597.5 Analisis forense digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.5.1 Adquirir y autenticar . . . . . . . . . . . . . . . . . . . . . . . . . 597.5.2 Examinar y recolectar . . . . . . . . . . . . . . . . . . . . . . . . 607.5.3 Analisis de los datos . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.6 Presentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8 Conclusiones 69
Bibliografıa 73
Informe pericial 751 Cuestiones previas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
1.1 Consideraciones previas . . . . . . . . . . . . . . . . . . . . . . 771.2 Solicitud de opinion . . . . . . . . . . . . . . . . . . . . . . . . . 771.3 Fuentes de informacion . . . . . . . . . . . . . . . . . . . . . . . 771.4 Adquisicion de datos y cadena de custodia . . . . . . . . . . . . 78
2 Dictamen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1 (a) Extraer todos los fichero que, en su denominacion, con-
tengan el nombre PALABRA A o PALABRA B . . . . . . . . . . . 802.2 (b) Extraer todos los correos electronicos enviados o recibidos
entre DIRECCION 1 y DIRECCION 2 . . . . . . . . . . . . . . . 832.3 (c) Verificar que los correos electronicos extraıdos son ıntegros . 852.4 (d) Extraer todos los ficheros eliminados entre FECHA INICIAL
y FECHA FINAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 873 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914 Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.1 Aseguramiento de las fuentes de informacion . . . . . . . . . . . 934.2 Ficheros con las palabras PALABRA A y/o PALABRA B en el
nombre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.3 Correos electronicos entre DIRECCION 1 y DIRECCION 2 . . . 954.4 Ficheros eliminados entre FECHA INICIAL y FECHA FINAL . . 954.5 Identificacion de los equipos . . . . . . . . . . . . . . . . . . . . 954.6 Procedimiento para analisis de correo electronico . . . . . . . . 97
viii
1 Introduccion
La proliferacion en el uso de los dispositivos electronicos como ordenadores y telefonos
moviles nos permiten estar conectados en todo momento y con todo el mundo. Las
actividades cotidianas implican, cada vez mas, el uso de Internet: realizar la compra,
comunicarnos con los amigos, realizar consultas medicas, etc. Si bien facilita nuestras
vidas tambien es una herramienta que debe usarse con responsabilidad y precaucion.
En Internet nos podemos encontrar con estafas de todo tipo, muchas de ellas basadas
en el principio de impersonar a terceros de confianza, como la famosa estafa de los
emails que simulaban ser de Correos. Los metodos cambian pero los delitos siguen
siendo parecidos. No solo con las estafas, antes, cuando un empleado decidıa robar
informacion confidencial de la empresa realizaba fotocopias del material deseado y se
lo llevaba; ahora, se puede enviar los documentos por correo electronico o copiarlos
a un dispositivo USB. Es por este motivo que cada vez se realizan mas juicios en
los que intervienen elementos tecnologicos de ultima tecnologıa y, para ello, se debe
conocer el funcionamiento de todos los elementos que implican estos dispositivos.
El objetivo de este proyecto es dar a conocer el proceso realizado durante una
investigacion digital. Es importante conocer todo el proceso y llevarlo a cabo correcta-
mente para que el informe resultante sea valido, ya sea a nivel judicial o interno para
una empresa. El proyecto cubre la investigacion digital desde el primer momento, es
decir, cuando se avisa de una posible incidencia, hasta el final, cuando se presenta
el informe de resultados al cliente. Antes de llegar al punto de redaccion de este
proyecto, se ha estudiado el proceso a seguir en una investigacion, no solo a nivel
teorico y academico sino a nivel practico, es decir, se ha realizado una investigacion
real en la empresa INCIDE (INCIDE Digital Data, S.L.). [9]
Estas practicas se han divido en dos etapas: una primera etapa de formacion en
la UPC para aprender conceptos basicos; y una segunda etapa de formacion en una
1
empresa para seguir aprendiendo mientras se realizan investigaciones reales.
1.1 Formacion en la UPC
La experiencia empieza con dos meses de formacion en la UPC bajo la tutela de Juan
Vera y Josep Pegueroles, del Information Security Group [3] del departamento de
telematica de la Universitat Politecnica de Catalunya. Durante esos dıas trabajamos
conceptos basicos que nos ayudaron a familiarizarnos con una investigacion digital.
Empezando por la instalacion de sistemas operativos Windows y Linux repasamos y
aprendimos a configurar un equipo con distintos sistemas operativos. No solo para
ser capaces de realizar una instalacion por nosotros mismos, sino con la finalidad de
conocer las distintas opciones que existen y en que lugar se almacenan los ficheros
de registro para poder consultarlos cuando se analiza un ordenador durante una in-
vestigacion. Ademas de la configuracion de un equipo, utilizamos herramientas para
la creacion y recuperacion de particiones de disco. Aprendimos a realizar copias bi-
narias y a optimizar la velocidad de la copia en funcion de la configuracion del equipo
y tambien distintos comandos para calcular un hash y a recuperar datos eliminados.
Tambien nos familiarizamos con el entorno Linux, empezando con comandos Bash
y avanzando a scripts tanto en Bash como en Python porque la automatizacion de
procesos es una pieza fundamental de las investigaciones forenses. Finalmente, re-
producimos casos que habıan sido realizados por el Information Security Group con
anterioridad a modo de practica.
1.2 Formacion en INCIDE
Finalizada la formacion en UPC, empezaron las practicas en INCIDE. Dejar el ambito
academico para pasar al ambito profesional supone enfrentarnos a casos reales que
no han sido disenados expresamente para los alumnos sino que son situaciones en
las que no se puede mirar la guıa de soluciones para llegar al final del caso y en
los que no existe una unica solucion. INCIDE es una empresa especializada en el
tratamiento e investigacion de la informacion digital. Esta encabezada por Abraham
2
Pasamar (CEO/CTO), que cuenta con mas de 12 anos de experiencia en el campo de
la seguridad de la informacion. La diversidad de casos realizados en INCIDE permite
tocar varios aspectos del mundo de la seguridad digital, como servicios forenses,
monitorizacion, e-crime, etc. El caso presentado en este proyecto es el primer caso
real que investigue durante las practicas realizadas en INCIDE.
1.3 Estructura del trabajo
Con el objetivo de entender y explicar ordenadamente el proceso de una investi-
gacion digital, en el capıtulo Fases de un analisis forense (apartado 2, pag. 5), se
hara un breve repaso de las fases llevadas a cabo en una investigacion. A contin-
uacion, en Descripcion del caso practico a analizar (apartado 3, pag. 15), se hara
una introduccion al caso practico realizado. Para poder realizar una buena investi-
gacion, en Funcionamiento de un disco duro (apartado 4, pag. 19) y Funcionamiento
del correo electronico (apartado 5, pag. 37) se desarrollara la teorıa necesaria que
se aplica en el desarrollo del caso. Seguidamente, en Herramientas usadas para el
analisis (apartado 6, pag. 49), se expondran las herramientas usadas para realizar
este analisis, porque son esenciales para optimizar el tiempo requerido y cumplir los
objetivos en los plazos previstos. Para finalizar, en Proceso de investigacion (apartado
7, pag. 57), se aplican todos los conocimientos adquiridos a un caso real encargado a
INCIDE. Se incluyen las notas de la investigacion y el informe de resultados. Se trata
de un caso de fuga de informacion en una empresa por parte de cierto trabajador.
1.4 Objetivos
Los objetivos de este proyecto son los de:
• Entender y dar a conocer el procedimiento que debe seguir un analista o perito
digital para llevar a cabo investigaciones digitales.
• Realizar una investigacion de un caso real en una empresa (INCIDE). Los obje-
tivos del caso presentado son los siguientes:
3
– Extraer todos los fichero que, en su denominacion, contengan el nombre
PALABRA A o PALABRA B.
– Extraer todos los correos electronicos enviados o recibidos entre DIRECCION 1
y DIRECCION 2.
– Verificar que los correos electronicos extraıdos son ıntegros.
– Extraer todos los ficheros eliminados entre FECHA INICIAL y FECHA FINAL.
4
2 Fases de un analisis forense
En este capıtulo se hara una explicacion breve de las distintas fases por las que pasa
una investigacion forense digital, desde el momento en el que el investigador es re-
querido hasta el momento en el que este entrega el informe de resultados. No hay
un modelo estandar que dicte todos los pasos a seguir sino que a lo largo de mas
de 20 anos se han ido proponiendo diversos modelos. Todos ellos remarcan la im-
portancia de preservar las pruebas y mantener la cadena de custodia. Los casos con
los que se puede enfrentar un investigador son de tipologıa muy distinta y no todos
las etapas se pueden aplicar en cada investigacion. Ası pues, los pasos descritos
a continuacion son unas directrices y no una normativa. En concreto, se ha elegido
el modelo propuesto por Michael Donovan Kohn en 2012 [5] como referencia porque
incluye la fase de preparacion que, aunque no implica directamente al investigador, se
ha considerado relevante que las personas esten mınimamente preparadas por si se
produce algun percance. Segun el tipo de incidente, la preparacion podrıa ser crucial
para una investigacion, tanto para la empresa como para el investigador.
5
Figure 2.1: Fases por las que pasa un analisis forense digital.
2.1 Definiciones
Antes de explicar las fases, es conveniente conocer algunos conceptos basicos del
analisis digital forense como son digital forensics, digital evidence y cadena de custo-
dia.
Digital Forensics
El analisis forense digital o digital forensics, es una ciencia que utiliza metodos cientıficos
probados y basados en un fundamento legal solido para preservar, recoger, validar,
identificar, analizar, interpretar y presentar la informacion que proviene de dispositivos
digitales. El objetivo de un analisis forense es el de aportar informacion valida en un
proceso legal para validar o refutar hipotesis ante los tribunales de justicia.
En 2012 se publico la ISO/IEC 27037:2012 — Information technology — Secu-
rity techniques — Guidelines for identification, collection, acquisition, and preserva-
tion of digital evidence [2] en el que se establecen unas directrices basicas para el
tratamiento de potenciales pruebas digitales. En Europa estos principios se agruparon
6
en las denominadas buenas practicas, good practice en ingles, en el que el Consejo
de Europa establece los principios basicos para el manejo de evidencias digitales. Los
principios basicos recogidos en el documento son la integridad, auditabilidad, soporte
de expertos, formacion adecuada y legalidad.
• Integridad: ninguna accion puede cambiar los medios de prueba.
• Auditabilidad: todo el proceso debe estar documentado y a disposicion de ter-
ceras partes que puedan repetirlo.
• Expertos: presencia de especialistas en las intervenciones.
• Formacion adecuada: los especialistas en recogida de evidencias deben tener
una formacion adecuada.
• Legalidad: todo el proceso debe ajustarse a la legislacion.
Los principios recogidos por las buenas practicas deben aplicarse en todas las
investigaciones, adaptandose a las circunstancias particulares de cada caso. En
caso de que no existan procedimientos establecidos para una tecnologıa concreta
a analizar, el perito debe definir y anotar el procedimiento, justificando cada paso y
el objetivo al que pretende llegar al llevar a cabo dicha practica, de forma que se
cualquier otro investigador sea capaz de repetir el mismo procedimientos y obtener
los mismos resultados.
Digital Evidence
Segun el Departamento de Justicia de los Estados Unidos de America [7], digital
evidence son datos e informacion de valor para una investigacion guardada, recibida
o enviada mediante un dispositivo electronico. Esta prueba es adquirida cuando los
datos o el dispositivo electronico se incauta y asegurada para ser examinado.
Cadena de custodia
La cadena de custodia es el procedimiento que controla los indicios relacionados con
un delito, desde su localizacion, descubrimiento o aportacion hasta que ha sido
7
analizado y valorado y la autoridad competente ordene su conclusion. El objetivo
de la cadena de custodia es el de no alterar o sustituir las potenciales pruebas de
un delito. Una prueba que ha sido hallada sin haber sido establecida la cadena de
custodia del medio que la albergaba no tiene validez en un tribunal pues no se puede
asegurar que estos datos no han sido modificados. De la misma forma que en una
escena de un asesinato se debe tener especial cuidado de no tocar nada hasta que
se hayan extraıdo las huellas dactilares, en el campo del analisis forense digital no se
puede acceder a los datos hasta que el dispositivo que alberga los datos no ha sido
asegurado. La cadena de custodia debe establecerse, siempre que sea posible, en
presencia de un fedatario publico y este debe quedarse una copia en custodia para
garantizar el derecho a la defensa de la otra parte.
Es fundamental que los analistas presenten los medios de prueba cumpliendo estas
caracterısticas:
• Admisibles: deben cumplir con todas las garantıas legales.
• Autenticas: vinculadas directamente con los datos disponibles en una investi-
gacion
• Completas: deben proporcionar informacion suficiente y objetiva.
• Confiables: se deben mantener la integridad de los datos en los que se apoyan
las conclusiones.
• Verosımiles: presentadas de forma clara y razonada.
• Proporcionales: adecuado a los fines perseguidos.
2.2 Documentacion
La documentacion es una fase o procedimiento que debe seguirse durante toda la
investigacion. Consiste en anotar todas las acciones realizadas y tambien los resul-
tados obtenidos. Llevar un registro detallado es util para la redaccion del informe
de resultados y para que otro investigador pueda seguir nuestro trabajo. Tambien
sirve para demostrar que se han seguido los principios de integridad y auditibilidad
8
recogidos en las buenas practicas forenses, es decir, no alterar el material original
bajo investigacion y documentar las acciones realizadas para que terceras personas
puedan llegar a las mismos resultados. Asimismo, todas las notas registradas son
de utilidad para el propio investigador, para ser consciente de las acciones realizadas
antes de, por ejemplo, ir a juicio a ratificar el informe pericial. Cuanto mas detalladas
sean las notas, mas facil sera la redaccion del informe.
2.3 Preparacion
La fase de preparacion, aunque podrıa no considerarse parte de un analisis forense
digital, es importante porque es el primer paso a seguir en el momento observar una
incidencia. El objetivo de la fase de preparacion es el de tener una serie de normas o
polıticas de empresa que se deberıan seguir en caso de detectar un posible incidente.
Estas normas sirven para maximizar la conservacion de pruebas a la vez que se
minimiza el coste de la investigacion para la empresa afectada. Por ejemplo, en caso
de recibir un posible ataque a un servidor, el departamento de seguridad y el de
produccion podrıan tener ideas distintas sobre como reaccionar. El departamento de
seguridad desearıa saber que y como ha sucedido para corregir las vulnerabilidades;
mientras que lo importante para el departamento de produccion serıa volver a tener
el servidor en funcionamiento lo antes posible. Con unas buenas instrucciones se
deberıa impedir que se perdiesen pruebas potenciales debidas a la mala actuacion
por parte de los empleados, como podrıa ser apagar todos los servidores de golpe.
2.4 Incidencia
Figure 2.2: Fases de incidencia.
El primer paso de esta fase es detectar la incidencia, ya sea de manera automatica
o manual. Una incidencia es una accion llevada a cabo con el objetivo de compro-
9
meter la confidencialidad, disponibilidad e integridad de la informacion. Una vez de-
tectada, esta necesita ser evaluada para ser confirmada o desmentida. En caso de
confirmar la incidencia, se debe notificar a los investigadores y a las autoridades per-
tinentes para empezar la siguiente fase, la de respuesta a la incidencia. En caso de
desmentirla se trata de un falso positivo. Siguiendo con el ejemplo anterior, sobre un
intento de acceso no autorizado al servidor de una empresa, dicho acceso generarıa
una notificacion al encargado de sistemas. Esta persona es la que deberıa compro-
bar si se trata de un acceso controlado, como podrıa ser un acceso por parte de un
empleado que se conecta en remoto o un empleado que ha introducido de forma in-
correcta el usuario o contrasena; o, por contra, si se trata realmente de un intento de
acceso malintencionado, ya sea dirigido especıficamente a dicho servidor o por parte
de escaneos masivos en busca de vulnerabilidades.
2.5 Respuesta a una incidencia
La fase de respuesta empieza con la llegada de los investigadores, que tienen que ser
capaces de analizar la situacion y definir una estrategia a seguir. Deben establecer y
mantener la cadena de custodia, preservar las pruebas potenciales y llevar un registro
de todos las acciones que realicen. Es importante aclarar las cuestiones que puedan
ser relevantes para la investigacion antes de llevar a cabo cualquier accion. Cues-
tiones como con que frecuencia se realizan copias de seguridad, que usuarios tienen
acceso a un determinado dispositivo o si el correo electronico se almacena en local
o en remoto pueden ser vitales para una investigacion. Se hara una clonacion de los
dispositivos in situ o en presencia de agentes judiciales segun el tipo de investigacion.
Esta copia tiene que ir acompanada de su correspondiente hash, para asegurar la
cadena de custodia de todos los datos. Un hash de un fichero es un calculo que
da como resultado una combinacion de numeros y letras. Tiene la peculiaridad de
que cualquier cambio en la informacion, por pequeno que sea, altera totalmente el
resultado del hash.
10
2.6 Analisis forense digital
Esta es la fase en la que el investigador tiene que analizar todos los dispositivos que
forman parte de las denominadas fuentes de informacion para dar respuesta a los
objetivos de la investigacion. Los objetivos suelen responder a que ha ocurrido y quien
es el responsable o autor de los hechos ocurridos y que han llevado a la investigacion.
Se puede dividir en distintas etapas, que se explican a continuacion.
Figure 2.3: Fases de analisis forense digital.
2.6.1 Adquirir y autenticar
El primer paso consiste en tomar posesion de los dispositivos a analizar. Siguiendo
las buenas practicas forenses, lo primero que se debe hacer es realizar una copia
bit-a-bit del contenido de los dispositivos a analizar, ya sea un ordenador, un telefono
movil, un buzon de correo o el contenido de una pagina web. Al realizar la copia
nos aseguramos de disponer de todo el contenido y dejamos el dispositivo original
intacto. El dispositivo original (o una segunda copia) debe quedarse bajo custodia
para garantizar el derecho a la defensa por cualquier otra parte que quiera ejercer este
derecho. A cada copia se le calcula el correspondiente hash, que es una operacion
matematica que da como resultado una secuencia de numeros y letras. Si se realiza
una modificacion del contenido del dispositivo, por pequena que sea, el valor del hash
variara sustancialmente. El hash calculado tambien quedara guardado bajo custodia.
Generalmente se usa el calculo del hash MD5 o SHA256.
2.6.2 Examinar y recolectar
Es en este momento en el que se empiezan a tratar todos los datos reunidos. En esta
etapa el investigador debe tener claro cual es su objetivo para, a partir de la copia
11
realizada, sacar todos los datos que puedan ser relevantes para la investigacion. Esto
puede incluir la recuperacion masiva de ficheros, la extraccion de lineas temporales
del sistema de ficheros, la extraccion de las cadenas del disco duro, el parseo del
contenido del dispositivo o la extraccion de todos los correos de un buzon de correo
electronico. Aunque las circunstancias de cada caso son distintas, estas acciones
suelen estar automatizadas para facilitar el trabajo del investigador y evitar errores
humanos.
2.6.3 Analisis de los datos
Una vez se han extraıdo los datos del dispositivo llega el momento de analizarlos. Es
recomendable separar los datos que nos pueden interesar de los que no son impor-
tantes para la investigacion porque, en general, se trabaja con grandes cantidades
de datos y nos interesa ahorrar tiempo y recursos. Una vez identificados los datos
relevantes (por contener potenciales pruebas), estos deben ser catalogados y orga-
nizados para realizar un analisis detallado de todos ellos. El investigador no debe
olvidarse de llevar un registro de acciones y resultados. Ademas, si se dispone de un
registro de incidentes previos, se pueden comparar los indicios obtenidos con inves-
tigaciones anteriores como metodo de soporte a la investigacion. Durante el proceso
de analisis, el investigador debe formular una hipotesis y tratar de probarla o de refu-
tarla con evidencias o por falta de ellas. Si las pruebas desmienten la hipotesis inicial,
debe formularse otra hipotesis hasta que los datos obtenidos la respalden o hasta que
no haya indicios que sugieran lo contrario.
Una vez mas, en funcion del tipo de investigacion se tendra mas o menos infor-
macion para analizar. Por ejemplo, si el objetivo del analisis es encontrar un trafico
sospechoso detectado en cierto ordenador, se analizaran los registros o logs del sis-
tema en busca de rastros que indiquen una conexion externa o indicios que apunten
hacia la anomalıa y, por otra parte, tambien se pueden intentar reproducir las mis-
mas condiciones que llevaron a ese trafico con el fin de detectar su procedencia.
Otro ejemplo puede ser una investigacion enfocada a buscar determinados correos
electronicos y probar su autenticidad. En este caso el investigador se centrara en
analizar los gestores de correo electronico del dispositivo y el contenido residual de
12
las consultas a Internet con el fin de encontrar dichos correos electronicos.
2.7 Presentacion
Finalmente, se tiene que presentar por escrito un documento de resultados. Este
documento debe incluir los procedimientos seguidos desde el establecimiento de la
cadena de custodia hasta las conclusiones a las que se ha llegado y un analisis que
interprete los resultados obtenidos. Tanto si forma parte de un proceso judicial como si
se trata de una investigacion interna de una empresa, el informe debe contener expli-
caciones dirigidas a personas sin conocimientos tecnicos, como un juez o el directivo
de una empresa. Es decir, un buen informe no puede incluir solamente un serie de
logs, sino que estos deben presentarse acompanados de una interpretacion para que
tenga sentido para personas sin altos conocimientos tecnicos. Sin embargo, tampoco
es correcto un informe que carezca del contenido que respalda las conclusiones a las
que ha llegado el investigador. Finalmente, si el informe es pericial, el perito tendra
que ir a ratificar el informe ante el juez.
Cada caso es distinto al anterior; por esta razon, las fases que se acaban de explicar
en Fases de un analisis forense (apartado 2, pag. 5) pueden no ser aplicables en
todas las investigaciones pero sı que son una guıa que se debe tener en mente.
A modo de resumen se destaca el aseguramiento de las fuentes de informacion y
el mantenimiento de la cadena de custodia ası como la importancia de escribir unas
detalladas notas durante todo el caso. La investigacion debe llevarse a cabo siguiendo
las buenas practicas forenses y el informe debe incluir un analisis de los resultados y
explicaciones sin un elevado contenido tecnico.
13
Figure 2.4: Detalle de la portada de un informe pericial realizado por INCIDE.
14
3 Descripcion del caso practico a
analizar
A continuacion se explicaran las etapas que, de forma general, se aplican en INCIDE
en la gestion de cualquier caso de prueba electronica. Estas etapas son el resultado
de anos de experiencia, que han permitido aplicar una metodologıa que se ajusta a
las buenas practicas forenses descritas en el apartado Fases de un analisis forense
(apartado 2, pag. 5) y que resultan en la emision de un dictamen con los resultados
de toda la investigacion. Antes de entrar en detalle, se introducira el caso realizado en
INCIDE ası como los conceptos que han permitido una buena resolucion del mismo.
La primera toma de contacto con un caso siempre es a traves de la persona que
contrata a INCIDE, ya sea personalmente o a traves de un abogado. A partir de uno
o varios encuentros con el cliente, se realiza un estudio preliminar para comprender
sus necesidades, definir los objetivos de la investigacion e identificar los elementos
relevantes para la investigacion, como por ejemplo un ordenador, un telefono movil
o la informacion publicada en cierta pagina web. A continuacion, se suele concertar
cita con el notario para asegurar todos los elementos bajo analisis y, ası, establecer la
cadena de custodia. El notario custodiara una de las copias realizadas para garantizar
el derecho a la defensa por cualquier parte involucrada en el proceso judicial. En el
caso de los contenidos de una pagina web, se suelen realizar capturas de pantalla del
contenido bajo investigacion.
En el caso que se explica en este proyecto, se analizaron cinco ordenadores. Para
anonimizar el caso no se utilizaran nombres propios, fechas concretas ni lugares. De
esta forma, se protege la intimidad de todas las personas y empresas que formaron
parte de la investigacion y, ademas, se cumple con el contrato de privacidad firmado
con INCIDE antes de empezar a realizar las practicas en esta empresa.
15
En este caso, el Cliente contacto a traves de su abogado y ambos estuvieron pre-
sentes en la reunion realizada con INCIDE para realizar el estudio preliminar. El
Cliente explico a INCIDE que habıa sido denunciado por su Empresa por irregula-
ridades detectadas en las cuentas de la empresa. En concreto, por alteracion de los
precios en las facturas con un proveedor con el que el se encargaba de gestionar los
pedidos. La Empresa aporto cinco ordenadores que habıan sido asignados al Cliente
durante su periodo laboral en la Empresa y con los que el realizaba su labor en la
empresa. Toda esta informacion ya habıa sido recogida en las diligencias previas
numero XXX del juzgado de instruccion numero 1 de XXX, proceso que acababa de
ser abierto y que estaba en manos del juez de instruccion. El cliente solicito los servi-
cios de INCIDE para que realizase un analisis cuyos objetivos finales eran los mismos
que habıan sido autorizados para llevar a cabo por la Policıa con el fin de que su abo-
gado tuviera el maximo de informacion posible para encarar la defensa del Cliente.
La adquisicion fue llevada a cabo en una notarıa de Barcelona, realizando dos copias
de cada disco, una para el analisis de la Policıa y la otra copia para el analisis de IN-
CIDE, que actuaba como mandatario verbal del Cliente. Los discos duros originales
quedaron depositados en sede notarial.
Los objetivos que dictamino el juez de instruccion para el analisis de los discos son
los siguientes:
• Extraer todos los fichero que, en su denominacion, contengan el nombre
PALABRA A o PALABRA B.
• Extraer todos los correos electronicos enviados o recibidos entre DIRECCION 1
y DIRECCION 2.
• Verificar que los correos electronicos extraıdos son ıntegros.
• Extraer todos los ficheros eliminados entre FECHA INICIAL y FECHA FINAL.
Para alcanzar los objetivos de este caso, en el siguiente capıtulo (Funcionamiento
de un disco duro (apartado 4, pag. 19)) se explicara el funcionamiento de un disco
duro, haciendo especial hincapie en el sistema de ficheros NTFS utilizado por Win-
dows. En el capıtulo Funcionamiento del correo electronico (apartado 5, pag. 37) se
16
explicara el funcionamiento de un correo electronico, que es esencial para la resolu-
cion del caso. En el capıtulo Herramientas usadas para el analisis (apartado 6, pag.
49) se repasan las herramientas usadas en el caso.
17
4 Funcionamiento de un disco duro
Esta seccion explica el funcionamiento de los discos duros, como son y como se
almacena y recupera la informacion. Se centra en el sistema de ficheros NTFS, que
es el que utilizan los sistemas operativos Windows.
4.1 Geometrıa de un disco
Un disco duro esta formado por varias capas circulares o discos uno encima del otro
y que giran a la vez. Cada disco tiene dos caras que estan recubiertas de un medio
magnetico y, para cada cara, hay un cabezal magnetico que es el encargado de leer
los bits. Un disco se puede dividir en pistas, cilindros y sectores. Las caras se dividen
en pistas concentricas, el conjunto de pistas que ocupan la misma posicion en todas
las caras se denomina cilindro y, un sector, que tiene un tamano de 512 bytes, es la
unidad de division de una pista. En la siguiente imagen se puede ver un dibujo de la
estructura de un disco duro.
19
Figure 4.1: Esquema de un disco duro.
Los discos duros se conectan al ordenador mediante el controlador ATA (Advanced
Technology Attachment) o las evoluciones del controlador, como Parallel ATA y Serial
ATA. SATA es una interfaz que conecta el adaptador de bus del host con los disposi-
tivos de almacenamiento como los discos duros. Tambien existen discos duros que se
conectan mediante USB o Serial Attached SCSI (SAS). Los discos mas comunes son
los de 3.5 pulgadas para ordenadores de sobremesa y 2.5 pulgadas para ordenadores
portatiles.
Las ventajas principales que ofrece SATA respecto a sus predecesores son la del
aumento de velocidad de transmision (mayor ratio de senal) y mayor eficiencia (cola
input output opcional), reduccion del coste y del tamano del cable que paso de utilizar
40-80 conductores a utilizar solo 7.
En un disco duro convencional los bits de informacion se escriben uno a contin-
uacion de otro, de forma secuencial, llenando clusters de datos. En cambio, en los
dispositivos de almacenamiento de datos flash, como los USB o los discos SSD, los
datos se guardan en bloques no consecutivos porque las memorias flash tienen un
numero limitado de ciclos de borrado/reescritura y de esta forma se reparte el uso de
la memoria. El tipo de dispositivo debe tenerse en cuenta cuando se recuperan datos,
20
porque en caso de un disco convencional se pueden seguir los bloques e ir recu-
perando datos pero en un dispositivo SSD los ficheros pueden quedar fragmentados
en bloques muy dispares.
A continuacion se hara un resumen de los tipos de particion mas usados.
4.2 Particiones DOS
Microsoft denomina Master Boot Record (MBR) a los discos que utilizan las par-
ticiones DOS. Tambien existen los discos GUID Partition Table (GPT) que se uti-
lizan con Extensible Firmaware Interface (EFI). A partir de Windows 2000, Microsoft
tambien distingue entre discos basicos, que son discos con MBR o GPT en los que
las particiones del disco son independientes y stand-alone; y discos dinamicos, que
son aquellos discos de tipo MBR o GPT en los que las distintas particiones se pueden
entrelazar para formar particiones de mayor tamano. La informacion expuesta a con-
tinuacion se refiere a discos MBR basicos, aunque por brevedad se utilizara el termino
particion DOS sin hacer mas distinciones. Las particiones de tipos DOS se utilizan
en distintos sistemas operativos, como por ejemplo Microsoft Windows y Linux. Las
particiones DOS contienen una MBR en el primer sector, que es de 512 bytes y puede
tener hasta 4 particiones. Cada particion es una entrada en la tabla, y estas, a su vez,
contienen campos con informacion sobre donde empieza y acaba cada particion ası
como el tipo de particion y un flag que indica si la particion es bootable o no.
La limitacion de las 4 particiones se puede solucionar mediante las particiones ex-
tendidas. Es decir, la tabla de particiones almacenada en una MBR puede llegar
hasta 4, para crear una particion extendida se crearan hasta 3 particiones primarias
no extendidas y una particion primaria extendida.
4.3 Particiones Apple
Apple no tiene un numero limitado de particiones y las data structures se almacenan
en sectores consecutivos del disco. Las particiones Apple se describen en el mapa de
particiones situado al inicio del disco. El firmware que contiene el codigo procesa la
21
estructura; por ese motivo, el mapa de particiones no lleva codigo de arranque como
las tablas de particiones DOS. En cada entrada del mapa de particiones se describe
el sector inicial de la particion, el tamano, el tipo y el nombre del volumen. Apple crea
particiones para guardar los drivers del hardware; por esta razon, el disco principal
de un sistema Apple esta formado por diversas particiones con drivers. Un fichero de
imagen de disco Apple es muy similar a un fichero de tipo zip en Windows o tar en
Unix.
Para poder identificar las particiones, se tiene que leer la estructura de datos del
segundo sector. La herramienta mmls del programa The Sleuth Kit nos mostrara las
particiones, sin embargo, la herramienta fdisk de Linux no mostrara los contenidos
de la particion del mapa. El programa The Sleuth Kit se explicara en el apartado
Herramientas usadas para el analisis (apartado 6, pag. 49)
4.4 NTFS
A continuacion, se hara una explicacion del sistema de ficheros NTFS. Es importante
conocerlo porque es el utilizado por Windows, el sistema operativo mas extendido.
NTFS, New Technologies File System, es el sistema de ficheros disenado y utilizado
por Windows desde el ano 1993. Fue concebido para ser escalable y para utilizarse
en sistemas con discos duros de mayor capacidad, 400 MB en aquella epoca. La
escabilidad viene dada por la estructura de datos interna que se adapta mientras que
el envoltorio general se mantiene constante. Con envoltorio general nos referimos, por
ejemplo, a que cada byte de datos del sistema se asigna a un fichero. Este concepto
es muy importante porque lo diferencia de otros sistemas de ficheros. En NTFS todos
los bytes de datos forman parte de ficheros, incluyendo los datos administrativos del
file system y que pueden estar asignados (allocated) en cualquier sitio del disco. Los
unicos datos que tienen un emplazamiento predeterminado son el sector de arranque
(boot sector ) y el codigo de arranque, que se encuentran en los primeros sectores del
volumen. Por este motivo la tabla maestra de ficheros (MFT) es tan importante para
el sistema de ficheros NTFS.
22
4.4.1 MFT
La master file table contiene informacion sobre todos los ficheros y directorios del sis-
tema. Cada fichero y directorio tiene, por lo menos, una entrada en la tabla, incluyendo
la propia MFT.
Las entradas de la MFT ocupan 1 KB, los primeros 42 bytes estan destinados a 12
campos con informacion como la signatura, en la que hay la palabra ’FILE’ escrita en
ASCII en una entrada estandar; un campo que indica el numero de secuencia, otro
que indica el tamano allocated de la entrada MFT, etc. Los bytes restantes se usan
para almacenar atributos, que son pequenas estructuras de datos usadas para un fin
concreto, como el nombre del fichero, el contenido del fichero, etc. y que pueden ser
residentes (su valor se encuentra en la MFT) o no residentes (en la MFT se indica
en que lugar de la zona de datos se encuentra su valor). Las primeras entradas
de la tabla estan reservadas para registros que contienen informacion general del
sistema de ficheros que no suele estar asociada a un fichero de usuario especıfico
y se denominan file system metadata files. Las entradas reservadas que no se usan
estan marcadas como allocated pero solo contienen informacion generica. Todos los
ficheros de metadatos del sistema de ficheros se encuentran en el directorio raız,
aunque no suelen estar visible para los usuarios. Los nombres de los ficheros de
metadatos del sistema de fichero empiezan con el sımbolo $ y mayuscula como se
podra ver en la siguiente tabla. Una caracterıstica a destacar de estos ficheros es que,
al igual que el resto de ficheros del file system, tienen marcas de tiempo, que son de
utilidad para el investigador para saber la fecha en la que fueron creados, por lo tanto
indican la fecha en la que el sistema de ficheros fue creado.
23
Figure 4.2: Master file table
Cada entrada se direcciona de forma secuencial usando 48 bits. La direccion
maxima de la MFT va creciendo a medida que se anaden entradas. Las entradas
de la MFT disponen de un numero de secuencia de 16 bits que se incrementa cuando
la entrada pasa a estar allocated/reallocated. La entrada de la MFT y el numero de
secuencia se combinan para crear una direccion de referencia de fichero de 64 bits. El
sistema de ficheros NTFS utiliza este direccionamiento para referirse a las entradas
de la MTF porque ası le es mas facil determinar si se encuentra en un estado de
corrupcion. Esto puede ser util para recuperar ficheros borrados: si tenemos datos
unallocated con un numero de referencia podemos determinar si la entrada de la MFT
ha sido reasignada desde que se uso para los datos que tenemos.
Ficheros de metadatos del sistema de ficheros
Como se acaba de comentar, existen los file system metadata files en los que se al-
macenan los datos administrativos del sistema de ficheros. A continuacion se muestra
una tabla que resume los file system metadata files. Para ser mas exactos, estas son
24
las entradas halladas en la MFT de un Windows 7 aunque se encuentran en todos los
sistemas de ficheros NTFS.
Entrada Nombre Descripcion
0 $MFT La entrada de la propia MFT.
1 $MFTMirr Copia de seguridad de las primeras
entradas de la MFT y que se encuen-
tra en medio del sistema de ficheros.
2 $LogFile Contiene el journal que registra las
transacciones de metadatos.
3 $Volume Contiene informacion del volumen,
como la version.
4 $AttrDef Contiene informacion de los atributos,
como nombre y tamano.
5 . Contiene el directorio raız del sistema
de ficheros.
6 $Bitmap Contiene el estado de asignacion
(allocated/unallocated) de todos los
clusters del sistema.
25
7 $Boot Contiene el sector y codigo de boot
del sistema de ficheros.
8 $BadClus Contiene los clusters con sectores
danados.
9 $Secure Contiene informacion sobre la se-
guridad y control de acceso de los
ficheros (Windows 2000 y Windows
XP).
10 $Upcase Contiene los caracteres Unicode en
mayuscula.
11 $Extend Un directorio que contiene ficheros
para extensiones opcionales.
• $MFT: es la entrada de la tabla. En ella se indica la disposicion en el disco
de la tabla entera. En el sector de arranque se indica donde se encuentra el
inicio de la tabla. El atributo $DATA de la entrada $MFT contiene los clusters
utilizados por la MFT. Como cualquier otra entrada tambien dispone del atributo
$BITMAP, que como se vera mas adelante en esta seccion, controla el estado
de asignacion de las entradas de la MFT. El fichero $MFT se crea ocupando el
26
mınimo espacio posible y va creciendo a medida que se van creando ficheros.
• $MFTMirr: esta entrada tiene un atributo $DATA no residente que contiene una
copia de seguridad de, por lo menos, las cuatro primeras entradas de la MFT
en medio del file system. En caso de existir algun problema para determinar el
layout de la MFT, se tendrıa que buscar el sector ubicado en la mitad del file
system para leer los datos de esta entrada.
• $LogFile: contiene informacion utilizada por el sistema de ficheros para una
rapida recuperacion del sistema. El tamano del log depende del tamano del
volumen y puede llegar a los 4 MB. Con el comando chkdsk se puede modificar
el tamano del log.
• $Volume: contiene la etiqueta e informacion de la version del volumen. Tiene
dos atributos que solo usa este fichero: $VOLUME NAME, que tiene el nombre
del volumen en Unicode; y $VOLUME INFORMATION, que contiene la version
del NTFS y dirty status.
• $AttrDef: el atributo $DATA de este fichero define los nombres y tipos de identifi-
cadores para cada tipo de atributo. Este fichero permite a cada file system tener
atributos unicos para sus ficheros y tambien permite redefinir identificadores
estandar de los atributos.
• Directorio raız (.): es el directorio raız del sistema de ficheros.
• $Bitmap: este fichero contiene informacion sobre el estado de asignacion de
cada uno de los clusters del sistema. En el atributo $DATA hay un bit reservado
a cada cluster del file system de forma ordenada, lo que significa que el primer
bit (bit 0) es para el cluster 0, el bit 1 es para el cluster 1, etc. Si el bit esta a 1
significa que el cluster esta allocated.
• $Boot: esta entrada contiene el sector de boot del sistema. El atributo $DATA se
encuentra siempre en el primer sector del file system porque se necesita para
arrancar el sistema. Es el unico fichero de metadatos del file system que tiene
una ubicacion estatica. La signatura del sector de arranque es la misma que
para los sistemas de ficheros FAT, 0xAA55. El sector de boot aporta informacion
27
basica del tamano de los clusters, el numero de sectores en el file system y el
cluster en el que empieza la MFT. En el atributo $DATA tambien se guarda el boot
code, imprescindible para que el file system sea bootable y ubica los ficheros
necesarios para cargar el sistema operativo. En algun sector del volumen (ultimo
sector o mitad del volumen en funcion de la version de Windows) se encuentra
una copia de seguridad del sector de arranque.
• $BadClus: NTFS lleva un registro de los clusters danados del sistema. Para ello,
cuando un cluster se reporta como danado, se anade al atributo $DATA llamado
$Bad (sparse file).
• $Secure: este fichero utiliza el parametro Security ID del atributo $STANDARD
INFORMATION de cada fichero como ındice para encontrar el descriptor ade-
cuado. Este Security ID son diferentes de los Windows Security Identifiers (SID)
asignados a los usuarios en Windows.
• $Upcase: para convertir un caracter Unicode en minuscula al mismo caracter
Unicode en mayuscula.
• $Extend: se utiliza para extensiones opcionales como quotas, reparse point data
y identificadores de objeto.
Para consultar informacion de estos ficheros se puede usar la herramienta $istat de
The Sleuth Kit junto con el numero de entrada, como por ejemplo si queremos que
nos muestre informacion sobre el fichero de metadatos $MTF ejecutaremos istat -f
ntfs nom img.dd 0
Atributos
Un atributo es una estructura de datos que guarda un tipo de datos especıfico. Hay
varios tipos de atributo y cada uno tiene una estructura interna distinta. Los atributos
se componen de dos partes: la cabecera y el contenido. La cabecera es igual para to-
dos los atributos pero el contenido es distinto para cada atributo, por lo que el tamano
tambien varıa para cada atributo. Como hemos dicho anteriormente, las entradas de
28
la MFT destinan la mayor parte de sus bytes a almacenar los atributos del fichero/di-
rectorio que representan. En caso de que el contenido del atributo ocupe mas de unos
700 bytes, la cabecera del atributo indica el lugar en el que se almacena en contenido
de dicho atributo. La cabecera identifica el tipo de atributo, su nombre y su tamano.
Tambien tiene flags que identifican si el valor esta comprimido o cifrado. Una entrada
de la MFT puede tener multiples atributos del mismo tipo y para diferenciarlos se usa
un identificador unico para cada atributo. El contenido de un atributo, como se acaba
de comentar, puede tener cualquier tamano y formato, por lo que puede haber atribu-
tos que ocupen hasta gigabytes y que, por lo tanto, no se pueden alojar en la entrada
de la MFT. Para solucionar este problema, el sistema de ficheros NFTS tiene dos sitios
en los que se puede alojar el contenido de un atributo: en la misma entrada de la MFT
(resident) o en un cluster externo en el file system (non-resident). En la cabecera del
atributo se indica si es residente o no. En caso de no serlo, en la cabecera se indica el
cluster en el que se encuentra el contenido junto con el numero de clusters que ocupa.
Figure 4.3: Entrada de la MFT
Los atributos se distinguen gracias a un numero que identifica el tipo de atribu-
to, ademas, se les da un nombre que se escribe en mayusculas y empieza por $.
Con la unica excepcion de las entradas non-base, todas las entradas allocated de
la MFT tienen los atributos $FILE NAME y $STANDARD INFORMATION. El atrib-
uto $FILE NAME contiene informacion del nombre del fichero, tamano y tiempos.
El atributo $STANDARD INFORMATION, que existe en todos los ficheros y directo-
rios, contiene informacion sobre tiempo de creacion, acceso, etc, sobre permisos y
de seguridad. Ambos atributos son residentes (se encuentran en la entrada de la
MFT). Todos los ficheros tienen el atributo $DATA, en el que hay el contenido del
29
fichero. Si el fichero ocupa mas de unos 700 bytes, se aloja fuera de la entrada
(non-resident). Si el fichero tiene mas de un atributo de tipo $DATA, se denomina
alternate data stream (ADS) a estos atributos adicionales que, ademas, tienen que
tener un nombre de atributo (que no es lo mismo que el nombre del tipo de atributo).
Cada directorio tiene un atributo de tipo $INDEX ROOT que contiene informacion so-
bre los subdirectorios y ficheros que contiene. Si se trata de un directorio grande, los
atributos $INDEX ALLOCATION y $BITMAP tambien se usan para almacenar infor-
macion. Los directorio tambien pueden tener el atributo $DATA, en el que se guarda
el contenido que una aplicacion o usuario desee. Los atributos $INDEX ROOT y $IN-
DEX ALLOCATION suelen tener el nombre $I30. Hay ficheros que tienen mas atribu-
tos de los que caben en una sola entrada de la MFT, por lo que ocupan mas entradas.
En la entrada ’base’, se encuentra el atributo $ATTRIBUTE LIST, en el que se indica
todos los atributos del ficheros y la entrada en la que se encuentran, solo la entrada
base tiene los atributos $FILE NAME y $STANDARD INFORMATION. Hay flags que
indican si un atributo esta comprimido o cifrado. Solo se comprime o cifra el atributo
no residente $DATA. La cabecera no se cifra.
NTFS usa ındices (index data structure), que son colecciones de atributos que se
guardan en un orden determinado. Los directorios, por ejemplo, usan ındices para
ordenar los atributos $FILE NAME.
Los ındices ordenan los atributos en lo que se denominan B-tree. Un arbol es un
grupo de estructuras de datos (nodos) que se enlazan entre sı de forma que hay
un nodo raız que se ramifica creando padres e hijos. Los arboles son utiles porque
permiten ordenar y encontrar los datos de forma facil. El inconveniente esta en la
forma de crear el arbol. Como tiene que estar siempre ordenado, anadir o borrar
un solo fichero puede cambiar completamente el arbol para poder cumplir con las
condiciones de numero de nodos permitidos por rama, cosa que puede dar proble-
mas en una investigacion porque con el movimiento podemos pensar que un fichero
esta eliminado pero simplemente ha cambiado de nodo para balancear. Los arboles
tienen entradas de ındice. Estos ındices se almacenan en la MFT en los atributos
$INDEX ROOT o $INDEX ALLOCATION en funcion del numero de nodos. Se utiliza
el atributo $BITMAP para encontrar un entrada de ındice disponible para un nuevo
nodo. Si no encuentra ningun indice disponible, se anade espacio. A cada ındice se le
30
da un nombre, y a los atributos $INDEX ROOT, $INDEX ALLOCATION y $BITMAP se
les asigna ese mismo nombre en sus cabeceras. En la entrada de un ındice tambien
existe un flag que indica si tienen nodos hijos.
Al formatear un equipo, la MFT nueva tendra muy pocas entradas por lo que las
entradas pertenecientes a la MFT de antes del formateo aun tendrıan que existir en
espacio unallocated. Se pueden buscar estas entradas para tratar de recuperar los
atributos originales y, ası, recuperar el contenido anterior al formateo. La herramienta
blkls de The Sleuth Kit (Herramientas usadas para el analisis (apartado 6, pag. 49)
nos muestra informacion sobre las unidades de datos del sistema de ficheros. Por
defecto extrae las unidades de datos unallocated. A partir de esta informacion se
puede usar la herramienta sigfind para buscar ’4649c45’ que significa ’FILE’ en hexa-
decimal y nos servira para encontrar las entradas de la MFT que, como hemos visto
antes, empiezan por la signatura. El resultado de este proceso nos dara los sectores
en los que se encuentran signaturas (FILE) y con la herramienta dd examinamos el
contenido de los sectores.
A continuacion se enumeran algunos de los tipos de atributos que pueden contener
las entradas de la MFT.
Identificador Nombre Descripcion
16 $STANDARD INFORMATION Informacion general, como por
ejemplo fechas de modificacion
y acceso, propietario y flags.
32 $ATTRIBUTE LIST Indica donde se pueden encon-
trar los atributos.
48 $FILE NAME Nombre del fichero (en Unicode)
y fechas de modificacion y ac-
ceso.
31
64 $OBJECT ID Identificador unico de 16 bytes
para el fichero/directorio.
80 $SECURITY DESCRIPTOR Control de acceso y
propiedades de seguridad
de un fichero.
96 $VOLUME NAME Nombre del volumen.
112 $VOLUME INFORMATION Version del file system y flags.
128 $DATA Contenido del fichero.
144 $SINDEX ROOT Nodo raız para un arbol ındice.
160 $INDEX ALLOCATION Utilizado para la implemetacion
de directorios y otros ındices.
176 $BITMAP Un bitmap para el fichero $MFT
y para los ındices.
32
• $STANDARD INFORMATION: Este atributo existe para todos los ficheros y di-
rectorios del sistema de ficheros y contiene los metadatos mas importantes. En
este atributo se guardan las marcas de tiempo, informacion de propietario y de
seguridad. No hay informacion indispensable para guardar los ficheros, pero
muchas caracterısticas del nivel de aplicacion de Microsoft dependen de este
atributo. Cuando el usuario selecciona las propiedades del fichero en Windows,
los tiempos que se visualizan son los de creacion, modificacion y acceso. El
tiempo de modificacion de la MFT guardado en este atributo no se muestra en
las propiedades. Ademas, a partir de Windows Vista[12], la fecha de ultimo ac-
ceso no se actualiza al acceder a un fichero para ahorrar recursos al sistema. En
este atributo existe un flag que indica si el fichero es solo de lectura, si el fichero
esta comprimido o si esta cifrado. Tambien hay un identificador de seguridad que
usa de ındice el fichero $Secure y se usa para determinar que normas de control
se aplican a este fichero. Si se esta usando el journal, hay el update sequence
number (USN) para el ultimo registro creado en este fichero. En concreto, las
fechas que se almacenan en este atributo son las siguientes:
– mtime: modification time, se guarda la fecha y hora en la que el fichero fue
modificado por ultima vez.
– atime: access time, se guarda la fecha y hora en la que el fichero fue acce-
dido por ultima vez. A partir de Windows vista, esta fecha, por defecto, no
se actualiza por temas de rendimiento del equipo.
– ctime: creation time, este campo, aunque se llame de creacion, registra la
fecha y hora de ultima modificacion en la entrada de la MFT correspondien-
te al fichero o directorio.
– btime: birth time, se guarda la fecha y hora en la que el fichero fue creado
en el sistema de ficheros, es decir, el momento en el que el fichero aparecio
en el volumen. Si el fichero fue creado en otro volumen (otro ordenador
por ejemplo), la fecha de nacimiento (btime) sera posterior a la fecha de
modificacion (mtime).
33
• $ATTRIBUTE LIST: este atributo se utiliza cuando un fichero o directorio nece-
sita mas de una entrada en la MFT para guardar todos sus atributos. Aunque
los atributos pueden ser no residentes, las cabeceras de todos los atributos se
almacenan en la propia entrada de la MFT y este atributo contiene una lista
de todos los atributos del fichero (menos el mismo). Cada entrada de la lista
contiene el tipo de atributo y la direccion de la entrada en la que se encuentra.
• $FILE NAME: en este atributo se encuentra el nombre del archivo y la direccion
del directorio padre. Windows no suele actualizar la informacion temporal de
este atributo, por lo que las fechas reflejadas en el atributo $STANDARD INFORMATION
y las fechas de este atributo pueden no coincidir. En general actualiza las fechas
de este atributo solo en caso de crear, renombrar o mover el fichero. En este
atributo tambien se almacena informacion de los mismos flags que se almace-
nan en $STANDARD INFORMATION con informacion sobre si la entrada es un
directorio, read only, etc,
• $OBJECT ID: este atributo contiene un identificador unico para los ficheros. Este
ID es utilizado por el Distributed Link Tracking Service y se utiliza, por ejemplo,
para los accesos directos a ficheros. No todos los ficheros disponen de este
atributo.
• $SECURITY DESCRIPTOR: este atributo almacena la informacion de seguridad
de un fichero. Sin embargo, en nuevas versiones de NTFS, Microsoft ha cam-
biado lo localizacion de esta informacion en un fichero denominado $SECURE.
Una de las ventajas que conlleva el fichero $SECURE es la agrupacion de per-
misos, varios ficheros con el mismo nivel de seguridad no necesitan almacenar
esta informacion en ficheros individuales para cada uno.
• $VOLUME NAME: este atributo solo existe en el fichero $Volume. Como su
nombre indica, almacena el nombre del volumen.
• $VOLUME INFORMATION: este atributo tambien es utilizado solo por el fichero
$Volume. Contiene informacion de la version del sistema de ficheros y un campo
para volume flags.
34
• $DATA: como su nombre indica, en este atributo se almacenan los datos y no
tiene un tamano preestablecido. Puede haber mas de un atributo $DATA en
una misma entrada de la MFT. Por ejemplo, se puede anadir informacion de
resumen a un fichero haciendo click con el boton derecho. Esta accion crea
un segundo atributo $DATA a la entrada. Los directorios tambien pueden tener
este atributo. Estos atributos adicionales, o alternate data streams ADS, no se
muestran cuando se lista el contenido de un directorio, por lo que pueden servir
para esconder informacion.
• $SINDEX ROOT: todos los directorios tienen ındices con informacion sobre los
ficheros y subdirectorios que alojan. Si el directorio aloja pocos ficheros, la infor-
macion se almacena en este atributo. Cuando el directorio alberga mas ficheros,
se almacenan en el atributo $INDEX ALLOCATION. Estos ındices forman un
B-tree.
• $INDEX ALLOCATION: como se acaba de mencionar, almacena informacion del
arbol que empieza en el atributo $INDEX ROOT.
• $BITMAP: este atributo tambien forma parte de la estructura de indexacion.
Mantiene un registro de que partes del ındice que estan allocated y cuales estan
libres para ser reutilizadas. Tambien para $MFT.
En el Instituto SANS (SysAdmin Audit, Networking and Security Institute) han ela-
borado un resumen de lo que significa la actualizacion de las fechas en los atributos
$STANDARD INFORMATION y $FILE NAME.[4]
35
Figure 4.4: Cambio en los metadatos de un fichero. Fuente: SANS.
36
5 Funcionamiento del correo
electronico
Un correo electronico es un servicio que permite a los usuarios enviar y recibir men-
sajes mediante sistemas de comunicacion electronica. Un correo electronico es sus-
ceptible de ser alterado o manipulado con facilidad mediante programas de edicion de
imagen como Photoshop o con un editor de textos como el Bloc de notas de Windows
sin que su contenido parezca alterado. Por esta razon, la presentacion de un correo
electronico debe hacerse en formato digital y con determinadas garantıas como la
custodia del medio que los alberga, ya sea el buzon de correo electronico en el que
se encuentra o el correo web (webmail) en el que esta contenido el mensaje. El estu-
dio de la ’adveracion de correos’ consiste en un analisis de las fuentes de informacion
disponibles en cada caso (cabeceras de correo, propiedades del buzon de correo, re-
gistros del servidor, etc.) para determinar si los correos conservan su integridad o si,
por el contrario, se observan incoherencias en los datos existentes en dichas fuentes
de informacion que puedan indicar que esos correos electronicos han podido sufrir
alguna manipulacion.
Los buzones de correo de los distintos gestores de correo que existen en el mer-
cado (Microsoft Outlook, Lotus Notes, Thunderbird, Evolution, etc.) contienen una
serie de metainformacion introducida por el gestor de correo que permite su correcto
funcionamiento. Esta informacion es incorporada de forma transparente por el pro-
grama gestor de correo y no puede ser manipulada directamente por el usuario, por lo
que el analisis de sus valores permite deducir, a partir de su estudio detallado, las ac-
ciones realizadas por cada mensaje, incluyendo la presencia o ausencia de posibles
modificaciones a las que el correo haya podido ser sometido tras ser enviado/recibido.
En el caso de que el servicio de correo electronico sea proporcionado directamente
37
mediante el explorador web (Firefox, Chrome, etc), el gestor de correo no es un pro-
grama independiente usado para tal fin sino que se utiliza un correo web o webmail,
que es un cliente de correo electronico que provee una interfaz web por la que se
accede al correo electronico, como por ejemplo Gmail, el cliente de correo de Google.
En el caso de disponer de un gestor de correo, la adveracion del correo se realizara
a partir del correo almacenado en el gestor. En caso de no disponer de uno, la infor-
macion que debe ser asegurada de un correo electronico enviado o recibido a traves
de webmail, consiste en el contenido completo del correo bajo investigacion, es decir,
el cuerpo del correo en el que esta el contenido del mismo, los ficheros adjuntos y la
cabecera completa.
La cabecera de un correo electronico esta formada por una serie de datos identi-
ficativos del mensaje, tanto del del cuerpo del correo como de los ficheros adjuntos.
En realidad, un correo electronico es el conjunto de las cabeceras, cuerpo y datos ad-
juntos, pero debido a que no aportan demasiada informacion al usuario y que, dada
su extension y complejidad tecnica, suponen mas bien una molestia para el mismo, la
mayorıa de los programas y sistemas de correo electronico no muestran los datos de
la cabecera por defecto. Sin embargo, permiten diferentes opciones para poder visu-
alizar la cabecera completa. Existen dos tipos de cabecera en un correo electronico:
la cabecera simple y la cabecera tecnica.
• La cabecera simple esta formada por los campos que se muestran al abrir el
correo e incluso en la previsualizacion del mismo, que se encuentra en la lista
de correos de la bandeja de entrada, salida, etc. Estos campos suelen mostrarse
en el idioma en el que esta configurado el gestor o cliente de correo.
– De:
– Para:
– Asunto:
– Fecha:
• La cabecera tecnica es la que aporta mas informacion al investigador por la
cantidad de campos que contiene y le permite establecer una trazabilidad del
correos en Internet. Por ejemplo, permite determinar por que sitios paso el men-
saje antes de ser recibido y la hora exacta en la que este fue recibido. Esta
38
cabecera no se muestra por defecto en los gestores de correo ni desde un
cliente web pero se pueden ver a traves de simples opciones como ”Muestra
el original” disponible para cada correo en Gmail. A diferencia de los campos de
la cabecera simple, estos siempre se muestran en ingles, que es el idioma de
estandarizacion y todos acaban con dos puntos (:). Algunos de los campos de
la cabecera tecnica son los siguientes:
– Delivered-To:
– Received:
– Return-Path:
– In-Reply-To:
– Message-ID:
Figure 5.1: Opcion para poder visualizar el correo electronico en su totalidad.
Este aseguramiento debe realizarse en el formato original, es decir, en formato di-
gital puesto que se trata de un correo electronico, almacenandolo en un dispositivo
adecuado tal como una memoria USB u otro dispositivo de almacenamiento de datos
externo. De forma complementaria, un juez puede enviar un requerimiento judicial
al proveedor de servicio de Internet (ISP por sus siglas en ingles) para obtener los
39
registros de actividad asociados a esta cuenta de correo. El analisis de estos logs
permitira estudiar la coherencia de los datos aportados respecto a aspectos tan re-
levantes como fecha y hora de acceso a la cuenta de correo o envıo y recepcion de
mensajes, entre otros.
Para poder analizar una cabecera se debe conocer el funcionamiento de un correo
electronico, desde que un usuario lo envıa hasta que llega a su destinatario. Los
correos electronico se envıan vıa SMTP (Simple Mail Transfer Protocol), que en cas-
tellano se puede traducir por protocolo simple de transferencia de correo. A contin-
uacion se resumen los pasos que sigue un correo electronico desde su origen hasta
su destino:
1. El programa de correo del emisor entrega el mensaje al servidor de correo que
tenga establecido.
2. El servidor de correo del usuario entrega el mensaje al servidor de correo de
destino.
3. El servidor de correo de destino almacena el correo en el buzon del usuario.
4. El destinatario recibe el mensaje de su servidor de correo.
La siguiente imagen ejemplifica el proceso que se acaba de describir.
40
Figure 5.2: Transmision de un correo electronico a traves de diversos servidores de correo en Internet.
En cada paso del proceso de envıo del correo, se generan ciertos campos que se
van anadiendo a la cabecera tecnica final que recibe el destinatario del mensaje. A
continuacion se explica de forma breve el proceso en el que se generan los campos
de la cabecera.
• Cuando el emisor escribe un correo electronico tiene que rellenar, de forma obli-
gatoria, el campo del receptor con la direccion de correo a quien vaya dirigido el
mensaje. De forma opcional el emisor rellena el asunto, el cuerpo del correo y
anade ficheros adjuntos, aunque serıa posible enviar un correo completamente
vacıo, solo con el destinatario.
• El cliente de correo que este utilizando el emisor, antepone una cabecera a dicho
mensaje. A continuacion, cuando el emisor decide enviar el correo, el cliente de
correo lo envıa al servidor de correo que tenga asociado, como por ejemplo a de
su proveedor de servicios de Internet.
• El servidor de correo anade, al principio, una cabecera Received y lo pasa al
siguiente servidor de correo que corresponda.
– Este proceso puede repetirse varias veces porque el correo puede pasar
por varios servidores de correo intermedios de Internet antes de llegar a su
destino
– Normalmente, un servidor de correo intermedio solo anade cabeceras Re-
ceived, pero ocasionalmente tambien puede insertar otras como las que
introducen los antivirus, antispam, etc.
– Notese que cada servidor inserta su propia cabecera al principio de las
cabeceras, y por tanto antes que las demas.
– En dicha cabecera se incluye la hora local del servidor que recibe el correo,
siendo posible determinar el tiempo que tarda un mensaje en llegar a su
destino.
• Cuando llega al ultimo servidor, este, ademas del campo Received puede es-
cribir otras cabeceras. Finalmente deposita el mensaje en el buzon del usuario.
41
A continuacion se puede ver un ejemplo, extraıdo de Wikipedia [13], de un correo
enviado vıa SMTP. En este ejemplo el correo electronico se envıa desde la direccion
bob@example.org a dos destinatarios, a alice@example.com y a theboss@example.com.
En el ejemplo se identifica el usuario con una C de cliente y el servidor, con una S.
La transmision empieza con el servidor indicando el nombre del dominio en el que se
encuentra (smtp.example.com). El usuario empieza la conversacion con un ”HELO”.
Finalmente, la conversacion acaba con un ”Bye” por parte del servidor.
42
S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:<bob@example.org>
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: RCPT TO:<theboss@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <bob@example.org>
C: To: "Alice Example" <alice@example.com>
C: Cc: theboss@example.com
C: Date: Tue, 15 January 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 4 header fields and 5 lines
in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
Los gestores de correo pueden anadir campos adicionales a la cabecera tecnica.
Este es el caso del gestor de correo Microsoft Outlook, que anade informacion muy
relevante para el investigador sobre el envıo de cada correo, en concreto, uno de
los campos que anade es el denominado x-originating-ip: en el que se indica la
direccion IP desde la que se envio el correo electronico. Disponer de la direccion IP de
43
origen no solo es util para localizar el lugar desde el que se envio el correo electronico
sino que ademas, aporta informacion sobre el proveedor de Internet utilizado. En
caso de considerarse necesario, se puede solicitar, mediante requerimiento judicial al
proveedor de servicio de Internet al que pertenece la direccion IP, los datos personales
e informacion de la utilizacion del servicio del usuario asociado a esta direccion IP.
A continuacion se realizara el analisis de un correo electronico a modo de ejemplo.
La cabecera de este correo ha sido modificada para anonimizar los correos reales
analizados, por lo que podrıa haber alguna pequena incoherencia debida a la modifi-
cacion realizada para este proyecto. En esta investigacion no se detecto ninguna mod-
ificacion de los correos electronicos extraıdos que habıan sido enviados o recibidos
entre DIRECCION 1 y DIRECCION 2.
En este ejemplo podemos ver un correo que fue enviado desde el gestor de correo
Microsoft Outlook. Se han substituido valores de algunos campos por tres puntos (...)
porque estos valores no aportan informacion relevante para la demostracion y ası no
se revelan datos confidenciales y se facilita la lectura.
44
Delivered-To:direccion1@empresa1.com
Received:by
10.194.33.39with
SMTPid
o7csp492541wji;
Tue,15
Nov
201107:19:07
-0700
(PDT)
X-Received:by
10.202.242.137with
SMTPid
q131mr17697382oih.137.1464704347461;
Tue,15
Nov
201107:19:07
-0700
(PDT)
Return-Path:<direccion2@empresa2.com>
Received:from
EUR01-HE1-obe.outbound.protection.outlook.com
(mail-he1eur01on0065.outbound.protection.outlook.com.
[104.47.0.65])
by
mx.google.com
withESMTPS
idz194si24044937oia.58.2011.11.15.07.19.06
for
<direccion1@empresa1.com>
Tue,15
Nov
201107:19:07
-0700
(PDT)
Received-SPF:pass
(google.com:domain
ofdireccion2@empresa2.com
designates
104.47.0.65as
permittedsender)
client-ip=104.47.0.65;
Authentication-Results:...
DKIM-Signature:...
Received:from
AM2PR07MB0865.eurprd07.prod.outlook.com
(10.161.71.151)by
AM2PR07MB0867.eurprd07.prod.outlook.com
(10.161.71.153)with
MicrosoftSMTP
Server(TLS)
id
15.1.501.7;
Tue,15
Nov
2011
14:19:04
+0000
from
AM2PR07MB0865.eurprd07.prod.outlook.com([10.161.71.151])
by
AM2PR07MB0865.eurprd07.prod.outlook.com
([10.161.71.151])with
mapiid
15.01.0506.013;Tue,
15Nov
201114:19:04
+0000
45
From:
"direccion2@empresa2.com"
<direccion2@empresa2.com>
To:
"direccion1@empresa1.com"
<direccion1@empresa1.com>
Subject:Material
Thread-Topic:Material
Thread-Index:AdG7RyTeAc80vwCdQg+45mjHWVKTUw==
Date:
Tue,
15
Nov2011
14:19:04+0000
Message-ID:<AM2PR07MB0865B8A0143AED17493EEF30865.euasdsd07.prod.outlook.com>
Accept-Language:es-ES,
en-US
Content-Language:es-ES
X-MS-Has-Attach:yes
X-MS-TNEF-Correlator:
authentication-results:...
x-originating-ip:[212.145.159.148]
x-ms-office365-filtering-correlation-id:
8bf04447-0847-45ac-915f-08d3895e852d
x-microsoft-exchange-diagnostics:...
x-microsoft-antispam:UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM2PR07MB0867;
x-microsoft-antispam-prvs:...
x-exchange-antispam-report-test:...
x-exchange-antispam-report-cfa-test:...
x-forefront-prvs:...
x-forefront-antispam-report:...
46
spamdiagnosticoutput:...
spamdiagnosticmetadata:NSPM
Content-Type:multipart/related;
boundary="_004_AM2PR07MB0865B8A0143AED17493EEF3CF0460AM2PR07MB0865eurp_";
type="multipart/alternative"
MIME-Version:1.0
X-OriginatorOrg:empresa2.com
X-MS-Exchange-CrossTenant-originalarrivaltime:
15Nov
201114:19:04.2565
(UTC)
X-MS-Exchange-CrossTenant-fromentityheader:
Hosted
X-MS-Exchange-CrossTenant-id:1c6d7ece-5a37-467d-ae24-57ffa0901acd
X-MS-Exchange-Transport-CrossTenantHeadersStamped:
AM2PR07MB0867
--_004_AM2PR07MB0865B8A0143AED17493EEF3CF0460AM2PR07MB0865eurp_
Content-Type:multipart/alternative;
boundary="_000_AM2PR07MB0865B8A0143AED17493EEF3CF0460AM2PR07MB0865eurp_"
--_000_AM2PR07MB0865B8A0143AED17493EEF3CF0460AM2PR07MB0865eurp_
Content-Type:text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding:quoted-printable
Hola,
"SIGUE
EL
CUERPO
DELCORREO"
47
Para analizar la cabecera tecnica de un correo electronico nos centramos en dos
elementos: los valores de los distintos campos Received y las fechas y horas que van
apareciendo a lo largo de la cabecera del correo electronico. Los campos Received
aportan informacion para trazar el recorrido del correo electronico desde que fue en-
viado hasta que fue recibido. Cada vez que el correo pasa por un servidor, anade un
campo Received a la cabecera. La lectura de una cabecera se realiza de abajo hacia
arriba, siendo el campo Received de mas abajo el que ofrece informacion del emisor
y, el campo Received de mas arriba, el que ofrece informacion sobre el buzon de en-
trega del receptor. En este caso concreto, el correo ha sido enviado desde el gestor
de correo Microsoft Outlook, hecho que se observa por los datos que se pueden leer
en la cabecera sobre Microsoft. Que el correo haya sido enviado desde Microsoft Out-
look es una buena noticia para el investigador porque este gestor de correo anade el
campo x-originating-ip en la cabecera del correo. El valor de este campo es el dato
mas relevante para la trazabilidad del origen de un correo electronico puesto que se
trata de la direccion IP de origen del correo. Por motivos de privacidad del usuario,
la mayorıa de gestores y clientes de correo electronico no anaden este campo de
informacion a la cabecera, sin embargo, Microsoft Outlook sı que lo hace.
Los campos con informacion temporal del correo son la principal fuente de infor-
macion para determinar la veracidad del correo. En este caso observamos que la
diferencia de tiempo entre el primer y el ultimo Received es de 3 segundos,siendo
14:19:04 +0000 la hora que se muestra en el primer (emisor) Received y 07:19:07
-0700 (PDT) la hora que se muestra en el ultimo (recepcion) Received, que equiva-
le a 14:19:07 +0000. Se observa una diferencia de dos decimas de segundo entre
los campos X-MS-Exchange-CrossTenant-originalarrivaltime y el primer Received, es
una diferencia temporal muy pequena que puede ser atribuida a tiempo de carga del
correo electronico. Ademas, se encuentra en procesos del emisor, por lo que no se
considera una alteracion que deba ser analizada en mas profundidad.
48
6 Herramientas usadas para el
analisis
Aunque es cierto que cada caso es distinto y se necesitan personas que analicen e
interpreten los datos hallados durante una investigacion, es conveniente tener pro-
cesos automatizados. No solo porque de esta forma el investigador ahorra tiempo,
sino porque ası se evitan errores humanos. En este capıtulo se hara un resumen de
las herramientas usadas para el caso que nos ocupa. Esto incluye herramientas de
software libre y los realizados para este caso.
6.1 Adquisicion y aseguramiento
Tal y como se ha comentado en el apartadoFases de un analisis forense (apartado 2,
pag. 5), lo primero que se debe realizar antes de empezar con el proceso de inves-
tigacion es una copia binaria o forense de los dispositivos y que, ademas, se deben
presentar acompanados del hash correspondiente para que cualquier otra persona
pueda contrastar los resultados obtenidos.
• Copia: las herramientas mas comunes son dd y dcfldd. La diferencia entre
ambas es que la segunda realiza el calculo del hash a la vez que realiza la
copia.
• Hash: El hash de una informacion (un texto, un fichero, etc.) es un calculo
matematico cuyo resultado es una combinacion de numeros y letras. Cualquier
cambio en la informacion, por pequeno que sea, altera totalmente su hash.
Ademas, es practicamente imposible encontrar otra informacion que tenga el
mismo hash que la original. Por esta razon el hash es un instrumento muy
49
valioso en el aseguramiento de prueba electronica. Existen distintos tipos de
hash, siendo los mas conocidos SHA-1 y MD5. Si durante la adquisicion de
datos se deja constancia del hash de la informacion, mas adelante cualquiera
que tenga acceso a la informacion puede volver a calcularle el hash, y si este no
ha variado se podra asegurar que la informacion de que se dispone es exacta-
mente la misma que se obtuvo durante la adquisicion de datos.
sudo dd if=/dev/sdg conv=sync,noerror,notrunc 2>/media/caso/img.dd.log |
tee nom_img.dd | md5sum > /media/caso/img.dd.md5"
• Clonadora: Se trata de un equipo que realiza la copia y el calculo del hash. Se
coloca el disco o discos vacıos destinatarios de la copia, el disco original se
conecta a la clonadora y, gracias a la pantalla se selecciona la opcion de realizar
la copia y calcular el hash, que se almacena en el disco receptor en un fichero
separado. En la pantalla de la clonadora se indica el tiempo que queda para
terminar y, al finalizar, muestra el resultado del hash por pantalla. Se realizan
fotografıas del proceso para anadirlas al informe porque dan soporte a la cadena
de custodia.
Figure 6.1: Clonacion de un disco y calculo del hash con la clonadora.
50
6.2 Montaje del disco
Para poder acceder al sistema de ficheros sin modificar ni un solo bit de informacion,
se montan los discos sin necesidad de arrancar el sistema operativo y en formato solo
lectura.
• fdisk, parted o mmls: son programas que sirven para visualizar y manipular las
tablas de particion de un disco. Para las investigaciones se utiliza para deter-
minar el numero de particiones del disco, el file system utilizado y el offset en
el que empieza el sistema de ficheros y, ası, poder montarlo para acceder a la
estructura de directorios y ficheros.
• mount: monta un sistema de ficheros al destino que se le indique. Es importante
para un investigador usar la opcion de solo lectura para no comprometer los
datos a analizar. De esta forma se accede al sistema de ficheros sin necesidad
de arrancar el equipo y, por lo tanto, no se modifican los registros del sistema.
6.3 Tratamiento de la informacion
• strings: es una herramienta que imprime cadenas de caracteres del fichero
que se le indique, ya sea un fichero o una imagen de disco. Puede imprimir
caracteres en mas de una codificacion, como por ejemplo ASCII o Unicode.
• grep: es una herramienta que busca un patron concreto dentro de un fichero
y muestra por pantalla la lınea del fichero en la que este patron aparece. En-
tre las opciones que ofrece la herramienta existe la de ignorar mayusculas y
minusculas, mostrar ciertas lıneas antes y despues de la coincidencia e inver-
tir la coincidencia, es decir, mostrar las lıneas en las que el patron buscado no
aparece.
• find: es una herramienta que busca ficheros en el arbol de directorios del sis-
tema por el nombre que se le pasa, una de las opciones mas interesantes es la
de ignorar mayusculas y minusculas.
51
• tree: es una herramienta que lista los directorios y su contenido en forma de
arbol, es decir, manteniendo la jerarquıa de directorios y subdirectorios exis-
tente. Una de las opciones mas interesantes que ofrece la herramienta es la de
mostrar ficheros ocultos, que no se muestran por defecto. Tambien se le puede
indicar el nivel de ’profundidad’ que se quiere mostrar, es decir, el numero de
subdirectorios que mostrara por pantalla esta herramienta.
• RegRipper: es una herramienta forense que sirve para extraer datos en un
equipo que utilize el sistema operativo Windows. Es una herramienta muy ex-
tensa, formada por diversos paquetes que extraen informacion muy diversa so-
bre el ordenador, como por ejemplo los usuarios del equipo con la ultima fecha
de escritura en disco, informacion sobre las impresoras o sobre los dispositivos
externos que han sido conectados al ordenador en cuestion.
• exiftool: es una herramienta que se utiliza para leer los metadatos de un
fichero.
6.4 Busqueda ciega de palabras clave y analisis
heurıstico
El analisis heurıstico persigue acceder a los contenidos de los documentos electronicos
con la seguridad de que no contienen informacion personal, al tiempo que reduce
aun mas el numero de documentos a analizar manualmente, lo que repercute directa-
mente en la simplificacion de la investigacion. Para esta deteccion de informacion per-
sonal suelen utilizarse diversas variantes de lo que se llama analisis heurıstico, que
tiene como base asignar, de manera ciega y automatizada, una puntuacion a cada
documento electronico, basandose en ciertos criterios que pueden variar en cada
caso, y descartar aquellos sospechosos de contener informacion personal en base a
esta puntuacion. Esta tecnica se utiliza de forma ruinaria en las investigaciones de
informatica forense, y se considera un estandar de facto, aunque su implementacion
exacta puede variar dependiendo de los criterios utilizados por cada perito para la
puntuacion. Aunque no se haya utilizado el analisis heurıstico en esta investigacion,
52
se ha considerado importante explicarla porque remarca la importancia de no analizar
los ficheros de caracter privado de los usuarios.
6.5 The Sleuth Kit
The Sleuth Kit esta formado por una coleccion de programas o comandos de codigo
abierto que sirven para analizar imagenes de discos duros. En el capıtulo anterior ya
se han introducido algunas de estas herramientas y continuacion se detallan:
Figure 6.2: The Sleuth Kit.
• tsk gettimes: esta herramienta extrae los metadatos de los sistemas de ficheros
de una imagen de disco. El resultado se puede usar para crear una timeline con
la herramienta mactime.
• mactime: esta herramienta crea una timeline de los ficheros a partir del resultado
obtenido con la herramienta tsk gettimes.
• fls: esta herramienta genera una lista de todos los ficheros y directorios de file
system. Tambien puede incluir directorios o ficheros borrados. Indica el nodo al
que pertenece el fichero/directorio.
• mmls: como se ha comentado antes, este comando lista la tabla de particiones,
el sector en el que empieza cada particion, el tamano y el tipo de particion.
• istat: esta herramienta muestra por pantalla informacion sobre el nodo selec-
cionado. Por ejemplo tamano, si el fichero/directorio esta borrado, los tiempos
53
de acceso y modificacion, etc. En los sistemas de ficheros NTFS muestra los
atributos de la MFT del fichero/directorio correspondiente.
• ils: esta herramienta lista la informacion de los nodos. Por defecto solo muestra
aquellos nodos correspondientes a ficheros eliminados.
• blkls: esta herramienta muestra los bloques de datos del file system. Por de-
fecto muestra solo los bloques no asignados pero tambien puede mostrar de-
talles de los que sı que estan allocated.
Mediante tsk gettimes y mactime se extraen timelines del dispositivo analizado, que
nos puede dar bastante informacion sobre la actividad del equipo si se saben inter-
pretar los datos correctamente, es decir, se conoce el significado de la mtime, atime,
ctime y btime en los distintos sistemas operativos que nos podemos encontrar durante
una investigacion.
6.6 Recuperacion de datos
A veces, en una investigacion, se requiere recuperar datos eliminados ya sea como
requerimiento expreso del cliente o para tener mas informacion acerca de la actividad
llevada a cabo en el dispositivo. Otras veces, nos encontramos con particiones de
disco danadas y para acceder a los datos se tiene que recuperar antes la particion
del disco. En este apartado se explican dos herramientas distintas: TestDisk, Pho-
toRec. Ambas herramientas son open source y tienen la misma finalidad pero utilizan
metodos distintos.
Figure 6.3: TestDisk y PhotoRec.
• TestDisk: esta herramienta fue disenada para recuperar particiones. Actual-
mente, ademas de recuperar particiones borradas, TestDisk tambien puede re-
cuperar el sector de boot de la copia de seguridad de los sistemas de ficheros
54
FAT y NTFS y recuperar ficheros eliminados de los sistemas FAT, exFAT, NTFS y
ext2. Tambien puede copiar ficheros de particiones FAT, exFAT, NTFS y ext2/ext3/
ext4 eliminadas. TestDisk a veces dispone de nombres de ficheros que no puede
recuperar. En este caso sirve para listar ficheros eliminados.
• PhotoRec: esta herramienta fue disenada para recuperar ficheros eliminados.
Se puede utilizar en discos duros, CDs, USB, tarjetas SD y camaras digitales.
PhotoRec ignora el sistema de ficheros y se centra en los datos subyacentes,
por lo que puede recuperar ficheros aunque el sistema de ficheros este danado
o haya sido formateado. Puede recuperar ficheros de, por lo menos, FAT, NTFS,
exFAT, ext2/ext3/ext4 y HFS+. Tambien recupera fotos y vıdeos de varias camaras
digitales. Para recuperar ficheros, busca cabeceras de mas de 480 tipos de
ficheros. Si los datos no estan fragmentados, puede recuperar el fichero entero.
Los resultados de recuperacion de ficheros que se obtienen suelen ser de mu-
chos ficheros sin algunos de sus metadatos, como el nombre del ficheros o las
marcas temporales.
6.7 Scripts
En funcion de la naturaleza del caso, puede ser aconsejable la creacion de scripts
especıficos para automatizar ciertos procesos igual que hacen las herramientas des-
critas en el apartado anterior. La automatizacion de tareas permite:
• Minimizar errores humanos.
• Reutilizar herramientas durante el caso y en investigaciones futuras.
• Y en la misma linea que el punto anterior, optimizar el tiempo para que el investi-
gador se pueda centrar en analizar los datos y ası evitar perder tiempo en llevar
a cabo tareas que no aportan valor dado que son automatizables.
• Si en el transcurso de una investigacion se analiza el contenido del sistema de
ficheros, no se suele arrancar el sistema operativo, sino que se monta el sistema
de ficheros en modo lectura para poder ver los directorios y ficheros. Los discos
55
pueden tener varias particiones y, para montar el disco, se debe calcular el offset
de cada particion. Para facilitar el trabajo, se creo una herramienta que monta
las distintas particiones de un disco.
• Uno de los objetivos que perseguıa el informe era el de extraer todos los correos
electronicos enviados y recibidos entre dos direcciones concretas. Por diversos
factores que fueron apareciendo durante la investigacion, se opto por buscar
los correos electronicos en el fichero de strings generado. Como se ha visto
en la explicacion de los discos duros, la informacion puede ser parcialmente
eliminada, cosa que dificulta la extraccion de correos eliminados. Ası pues, se
opto por extraer correos totales y parciales. En el anexo se puede consultar el
script creado para esta investigacion.
• Otro de los objetivos del informe era el de encontrar todos los ficheros con ciertas
palabras en su nombre. Como no se revisarıan uno a uno todos los ficheros de
los discos, porque, recordemos, se debe mantener el derecho a la intimidad de
los usuarios, se creo un simple script que revisaba los nombres de todos los
ficheros de los discos.
56
7 Proceso de investigacion
En este apartado se representan las fases llevadas a cabo en una investigacion real
realizada en INCIDE. Con la finalidad de escribir este proyecto sin desvelar infor-
macion real de ninguna de las partes involucradas en el proceso judicial, se utilizan
palabras genericas como Cliente y Empresa, empezando en mayuscula para remar-
car que no es una empresa ni un cliente cualquiera sino la empresa y el cliente en los
que se centra el caso; y FECHA y PALABRA, escritas en mayuscula para remarcar
que se tratarıa de fechas y palabras concretas pero que no se han escrito para hacer
el informe de resultados anonimo. Tambien se emplean ’XX’ para ocultar resultados
numericos y otra informacion confidencial de la investigacion.
7.1 Documentacion
La fase de documentacion empieza recopilando la informacion proporcionada por el
Cliente sobre el caso y termina con el informe de resultados. Cuando el Cliente con-
tacto con INCIDE, la Empresa ya habıa denunciado al Cliente, por este motivo, parte
de la informacion recopilada ha sido extraıda de las diligencias previas numero XXX
del juzgado numero 1 de XXX. Esta informacion se resume a continuacion:
• La Empresa despide a Cliente, por sospechar de irregularidades en las cuentas.
• La Empresa denuncia a Cliente por supuestas operaciones de venta de material
en un periodo en el que el denunciado desempenaba sus tareas en la Empresa.
• Concretamente por la compraventa de material a un proveedor en concreto por
un precio que no se correspondıa con la facturacion entre ambas empresas.
57
El Cliente contrata a INCIDE para realizar el mismo analisis que la Policıa y, de esta
forma, que su abogado pueda construir una buena defensa en base a los resultados
que puede encontrar la Policıa. Los objetivos del analisis son los siguientes:
• Extraer todos los fichero que, en su denominacion, contengan el nombre
PALABRA A o PALABRA B.
• Extraer todos los correos electronicos enviados o recibidos entre DIRECCION 1
y DIRECCION 2.
• Verificar que los correos electronicos extraıdos son ıntegros.
• Extraer todos los ficheros eliminados entre FECHA INICIAL y FECHA FINAL.
Ademas de la informacion previa sobre el caso, todos los procedimientos que se
realicen y los resultados que se extraigan forman parte de la fase de documentacion.
En este caso, tanto el apartado anterior Descripcion del caso practico a analizar
(apartado 3, pag. 15), este mismo apartado, como el informe pericial que se puede
consultar en Informe pericial (apartado 8, pag. 76), forman parte de la documentacion
del caso. Tambien posibles notas intermedias que no se acaban incluyendo en el in-
forme ya sea por tener poca relevancia para el resultado de la investigacion o por ser
detalles demasiado tecnicos.
7.2 Preparacion
La empresa no disponıa de ningun protocolo para evitar que los empleados sustra-
jeran informacion confidencial. Los equipos usados por los empleados podıan tener
los sistemas operativos Windows o Ubuntu instalados. Los ordenadores que utiliza-
ban Windows tenıan todos el gestor de correo Microsoft Outlook instalados pero no
era obligatorio usarlo para acceder al correo corporativo. Los ordenadores que utiliza-
ban Ubuntu no disponıan de un gestor de correos instalado de serie para que los em-
pleados lo utilizaran. Tampoco habıa habilitado medidas para que los empleados no
pudieran conectar dispositivos externos a sus equipos ni medidas de monitorizacion
de las acciones de los empleados.
58
7.3 Incidencia
La incidencia por la cual se ha realizado la investigacion es la alteracion de los precios
de compraventa entre Cliente (denunciado) y un proveedor. Fue detectada por la
Empresa (denunciantes). Se desconoce como y cuando lo descubrieron. La pericial
ha sido encargada para poder demostrar los hechos que confirmar la incidencia.
7.4 Respuesta a la incidencia
En esta investigacion no hubo respuesta a la incidencia. Para INCIDE el caso empezo
cuando el Cliente ya habıa sido despedido y el proceso judicial contra el ya se encon-
traba en el juzgado de instruccion. El analisis realizado se ha efectuado sobre las
copias de los equipos proporcionados por la Empresa por su relacion con el Cliente.
7.5 Analisis forense digital
7.5.1 Adquirir y autenticar
Tal y como se ha comentado en la primera etapa de analisis digital (Adquirir y aut-
enticar (apartado 2.6.1, pag. 11)), el primer paso consiste en tomar posesion de los
dispositivos a analizar. En este caso la empresa aporto cinco equipos de sobremesa
con un disco duro cada uno. Se desmontaron los equipos para extraer los discos duros
y, mediante la clonadora se realizaron dos copias de cada disco, una para cada parte.
Los discos duros originales fueron depositados ante notario junto con una memoria
USB que contenıa fotografıas realizadas durante el proceso de clonacion de los dis-
cos, incluyendo las fotografıas realizadas de la pantalla de la clonadora al finalizar la
copia, en la que se puede ver el resultado del calculo del hash. Los discos duros
que reciben las copias son de tamano ligeramente superior a los originales porque la
clonadora crea un fichero con los hash SHA256 y MD5 calculados que sirven para
posibles comprobaciones sobre si se han alterado los datos del disco.
59
7.5.2 Examinar y recolectar
Una vez se tienen los dispositivos para analizar, se realiza una pequena descripcion
del dispositivo para tener mas datos de contexto que ayuden en la investigacion. El
tamano del disco, el numero de particiones, sistema operativo y sistema de ficheros
ası como los usuarios del equipo y fechas relevantes como la de instalacion y de ultimo
uso por parte de todos los usuarios forman parte de la caracterizacion del equipo.
Esta informacion se suele anadir como anexo al informe. La herramienta mmls de The
Sleuth Kit extrae informacion sobre el disco: el numero y tipo de particiones, donde
empiezan y cuanto ocupan. Para el equipo de Windows, la herramienta Regripper
extrae informacion sobre la fecha de instalacion, la version del sistema operativo y los
usuarios con las fechas de creacion y de ultima conexion.
Como se ha visto en el apartado Documentacion (apartado 7.1, pag. 57), se han
establecido unos objetivos concretos a cumplir, por lo que antes de empezar a analizar
los datos, se evalua que informacion puede ser relevante y como se puede extraer. En
este caso, se necesitan ficheros con un nombre particular, ciertos correos electronicos
y recuperar ficheros entre dos fechas. Por este motivo, se realizan las siguientes
acciones:
• Listado de todos los archivos del sistema de ficheros con la herramienta find.
• Listado de todos los archivos y directorios del equipo, actuales y borrados re-
cientemente, con la herramienta fls de The Sleuth Kit.
• Busqueda de gestores de correo electronico y/o webmail (cliente de correo
electronico al que se accede desde el navegador de Internet).
• Extraccion de las cadenas del disco con la herramienta strings.
• Extraccion de la timeline o lınea temporal de los equipos con las herramientas
tsk gettimes y mactime de The Sleuth Kit.
• Carving: recuperar el maximo de ficheros y directorios eliminados con las herra-
mientas TestDisk y PhotoRec.
• Extraccion de un listado de todos los ficheros contenidos en la papelera de reci-
claje.
60
La mayorıa de estas acciones estan automatizadas de forma que se generan ficheros
en los que se van almacenando los resultados encontrados para poder ser analizados.
7.5.3 Analisis de los datos
En esta fase se empiezan a analizar los datos extraıdos en la fase anterior con el
fin de poder cumplir los objetivos marcados para la realizacion del informe pericial.
En este caso las hipotesis que se tienen que probar o desmentir son los objetivos
establecidos en el proceso judicial y que se detallan en los siguientes subapartados.
Todas las anotaciones realizadas forman parte de la fase de documentacion y se
encaminan a la redaccion del informe de resultados.
Extraer todos los fichero que, en su denominacion, contengan el nombre
PALABRA A o PALABRA B
Uno de los objetivos era el de extraer todos los ficheros con ciertas palabras en el
nombre. Logicamente, no se mirarıan los directorios uno a uno hasta haber repasado
el nombre de todos los ficheros. No solo por la gran cantidad de tiempo que se nece-
sitarıa sino tambien porque vulnerarıa el derecho a la intimidad de los usuarios del
equipo. Se utilizo la lista de ficheros allocated del disco (extraıda en el subapartado
anterior) para realizar una busqueda ciega mediante palabras clave, siendo las pa-
labras claves las dos indicadas por el Cliente que debıan figurar en el nombre del
fichero.
Para determinar si hay ficheros eliminados que se conservan en el disco y que con-
tienen las palabras PALABRA A o PALABRA B en el nombre, se realizo una busqueda
en el listado de ficheros extraıdo con la herramienta fls de The Sleuth Kit. Igual que
en el caso anterior, la palabras se buscan ignorando las mayusculas y minusculas. A
continuacion se muestra como, a partir de los ficheros extraıdos en el apartado ante-
rior (Examinar y recolectar (apartado 7.5.2, pag. 60)), se realiza una busqueda ciega
y se escriben los resultados en un nuevo ficheros.
61
echo "PALABRA_A" >> ficheros_AB.txt
grep -Ei "PALABRA_A" ficheros_disco.txt >> ficheros_AB.txt
echo "PALABRA_B" >> ficheros_AB.txt
grep -Ei "PALABRA_B" ficheros_disco.txt >> ficheros_AB.txt
Se comprueban y comparan los resultados de los dos procedimientos. Los ficheros
no eliminados son los mismos en ambas listas. En el listado fls AB.txt se encuen-
tran ficheros marcados como eliminados. Se buscan estos ficheros en los resultados
del procedimiento de recuperacion de ficheros eliminados pero no se han encontrado
todos los ficheros. Esto puede pasar porque el inodo en el que se almacenan los
metadatos de nombre apunte a un lugar en el que ya hay otro fichero y, este, tambien
tiene otro inodo con los metadatos correctos que lo apunta. Ademas, Photorec no per-
mite recuperar el nombre del fichero, por lo que es posible que alguno de los ficheros
recuperados sean los que se buscan pero dado que solo se tiene el nombre no se
puede asegurar y no entra en los objetivos de este caso, puesto que se solicitaba por
nombres de fichero sin entrar en su contenido. Dado que se han encontrado ficheros
eliminados que contenıan las palabras en el nombre, se realiza una busqueda por es-
tas mismas palabras en todos los ficheros recuperados por si se ha recuperado algun
fichero que contenga las palabras PALABRA A y/o PALABRA B en su nombre y que
la herramienta fls no haya podido extraer. No se han encontrado mas ficheros pero
se han extraıdo aquellos ficheros localizados a partir de la lista de ficheros eliminados.
Extraer todos los correos electronicos enviados o recibidos entre
DIRECCION 1 y DIRECCION 2
El Cliente solicito extraer todos los correos electronicos enviados y recibidos entre dos
direcciones de correo electronico concretas. Como se ha comentado en el apartado
Descripcion del caso practico a analizar (apartado 3, pag. 15) y en el subapartado
Documentacion (apartado 7.1, pag. 57), la Empresa quiere aportar pruebas que
demuestren como se llevaban a cabo las irregularidades entre Cliente y el provee-
dor. Para ellos, el juez decreto que se podıa acceder al correo laboral del Cliente
(DIRECCION 1) y extraer toda la correspondencia que tenga relacion con la com-
62
praventa de material con dicho proveedor (DIRECCION 2). Dada la importancia de
los correos electronicos por contener potencial informacion sobre el asunto que atane
al caso, los correos electronicos extraıdos tiene que ser analizados para verificarse su
autenticidad tal y como se vera en el siguiente subapartado.
No se especifico como se accedıa al correo electronico corporativo, pero sı que se
informo a este perito de que los equipos con el sistema operativo Windows tenıan el
gestor de correo Microsoft Outlook instalado. Por este motivo, como se ha visto en
el apartado anterior, se realizo una busqueda de gestores de correo electronico y de
uso de webmail. No se encontraron indicios en los ficheros temporales de Internet
que apuntaran que se hubiese utilizado el correo electronico desde el navegador de
Internet. Por lo que respecta al uso de gestores de correo, se encontro Microsoft
Outlook en el equipo que utilizaba el sistema operativo Windows XP y el gestor de
correo Evolution en los equipos que utilizaban el sistema operativo Ubuntu.
Todos los buzones encontrados estaban asociados a una unica direccion de correo
electronico, el correo corporativo del Cliente (DIRECCION 1) por lo que las busquedas
realizadas son de la direccion de correo electronico DIRECCION 2 con la herramienta
grep. A continuacion se resumen los resultados:
• Disco 01: La unica coincidencia de la palabra DIRECCION 2 fue en la agenda de
contactos, no se encontraron correos enviados o recibidos entre DIRECCION 1
y DIRECCION 2.
• Disco 02: La unica coincidencia de la palabra DIRECCION 2 fue en la agenda de
contactos, no se encontraron correos enviados o recibidos entre DIRECCION 1
y DIRECCION 2.
• Disco 03: No se ha encontrado ninguna coincidencia de la palabra DIRECCION 2.
• Disco 04: Se encontraron coincidencias en la agenda de contactos, en la ban-
deja de entrada y en la bandeja de correos eliminados. Para recuperar estos
correos se ha usado la herramienta undbx, que extrae correos de las bases de
datos de Outlook. Ademas, con la opcion de recuperacion no solo extrae los
correos, sino que tambien recupera posibles correos borrados y los presenta en
carpetas separadas para distinguir su origen.
63
• Disco 05: Se encontraron coincidencias en la agenda de contactos y en las ban-
dejas de entrada y de salida. Sin embargo, el comportamiento de Evolution no
fue el esperado y los correos no se podıan abrir y aislar de forma individual. Para
poder analizar el contenido de los correos, el investigador creo una herramienta
que separa los correos a partir de su cabecera.
Notese que realizar la extraccion de correos electronicos a partir del resultado de
busquedas ciegas por palabra clave, protege los usuarios de que su correspondencia
sea leıda mas alla de los estrictamente necesario para la investigacion. Aunque se
trate de una direccion de correo corporativo, solo han sido analizados aquellos correos
que cumplıan las condiciones establecidas por un juez, protegiendo, ası, el derecho a
la intimidad de los usuarios.
El hecho de que en el disco 01 y en el disco 02 se encontrase la direccion de correo
electronico DIRECCION 2 en la agenda de contactos, puede indicar que en algun
momento se han intercambiado correos electronicos con esta direccion aunque no se
haya encontrado ningun correo presente en el sistema de ficheros en el momento de
realizar la extraccion. Por este motivo se aprovecho el script creado para separar los
correos del disco 05 para buscar correos electronicos eliminados en las cadenas del
disco, ya que el usuario podrıa haber eliminado dichos correos pero podrıan seguir en
espacio no reasignado del disco. A continuacion se resumen los resultados:
• Disco 01: Se encontraron correos enviados y/o recibidos entre DIRECCION 1 y
DIRECCION 2.
• Disco 02: Se encontraron correos enviados y/o recibidos entre DIRECCION 1 y
DIRECCION 2.
• Disco 03: No se ha encontrado ninguna coincidencia de la palabra DIRECCION 2.
• Disco 04: Se encontraron correos enviados y/o recibidos entre DIRECCION 1 y
DIRECCION 2.
• Disco 05: Se encontraron correos enviados y/o recibidos entre DIRECCION 1 y
DIRECCION 2.
64
Estos correos electronicos han sido extraıdos de las cadenas del disco, es decir,
se han extraıdo todos los caracteres imprimibles del disco y se han realizado las
busquedas sobre estos ficheros. Si comparamos los resultados de los dos proce-
dimientos podemos ver que en el disco 01 y en el disco 02 no se encontraron correos
en el sistema de ficheros, por lo que podemos deducir que los correos encontrados a
partir de los strings son correos eliminados. Se han podido recuperar correos porque
los datos (ficheros o directorios) que elimina un usuario no se eliminan del disco duro
de forma inmediata sino que el sistema los ”marca” como eliminados. Sin embargo,
los datos permanecen en el disco hasta que el espacio que ocupan se sobreescribe
con datos nuevos. Dado que no todos los ficheros ocupan igual, puede que algunos
correos hayan quedado parcialmente sobreescritos y que solo se haya podido recu-
perar aquella parte del correo electronico que aun no habıa sido sobreescrita.
Verificar que los correos electronicos extraıdos son ıntegros
Se han analizado todos los correos electronicos que han sido recuperados de forma
completa y no se han detectado alteraciones tal y como se ha explicado en Fun-
cionamiento del correo electronico (apartado 5, pag. 37). Se puede afirmar que
todos los correos son ıntegros. Aquellos correos electronicos que no han podido
ser recuperados en su totalidad se han dividido en dos: correos con cabeceras to-
tales y contenido parcial y correos con cabecera parcial y contenido total o parcial.
Los correos de los que se dispone una cabecera tecnica completa han podido ser
adverados aunque no puedan ser visualizados en su totalidad. Aunque no se haya
encontrado ningun correo modificado, los correos de los que no se dispone de una
cabecera completa no pueden ser adverados y, por lo tanto, no se puede afirmar que
no hayan sufrido ninguna modificacion.
Extraer todos los ficheros eliminados entre FECHA INICIAL y FECHA FINAL
El Cliente solicita recuperar los ficheros eliminados entre FECHA INICIAL y FECHA
FINAL. Para extraer los correos se han utilizado las herramientas TestDisk y PhotoRec.
Sin embargo, estos resultados se tienen que filtrar para que se ajusten a las fechas
indicadas. Para ello, se diferencia entre el disco 04 (Windows XP) de los discos 01,
65
02, 03 y 05 (Ubuntu).
Windows, como se ha comentado en NTFS (apartado 4.4, pag. 22), utiliza el sis-
tema de ficheros NTFS. Este sistema de ficheros no registra datos del momento en el
que se elimina un fichero. Esto ocurre porque a un usuario no le interesa la fecha de
eliminacion de un fichero que esta borrando, ya que, precisamente, lo esta eliminando
y simplemente quiere que desaparezca. Por lo tanto, NTFS se ahorra este proceso.
Sin embargo, aunque los metadatos de un fichero o directorio eliminado no incluyan
fecha y hora del momento en el que este fue borrado, sı que es posible encontrar
rastros indirectos de cuando sucedio este evento. Cuando se elimina un fichero o
un subdirectorio, se produce un cambio en el directorio en el que esta contenido el
elemento y este cambio se registra en los metadatos del directorio, en concreto, en
el atributo $STANDARD INFORMATION de la entrada de la MFT correspondiente a
este directorio. El mismo campo tambien se actualiza si se anade un fichero en el
directorio, si se renombra el directorio o si mueve el directorio, es decir, hay varias ac-
ciones que implican modificar el campo de ultima modificacion de la MFT del atributo
$STANDARD INFORMATION. Por lo tanto, no se puede saber en que momento fue
eliminado un fichero ni un directorio o subdirectorio.
Aunque, como acabamos de ver, no hay ningun campo que registre el momento de
borrado de un fichero o directorio, se puede establecer una ventana temporal en la
que un directorio podrıa haber sido eliminado. Esto es, entre el momento de ultima
modificacion del directorio que se encuentra eliminado en el momento de realizar el
analisis y el momento de ultima modificacion de su directorio padre. Es importante
entender que esta fecha solo afecta al directorio y no a su contenido. Cada directorio
dispone de un ındice de su contenido, ya sean ficheros o subdirectorios. Este ındice
va aumentando a medida que el directorio aloja mas elementos. El tamano del ındice
no disminuye aunque se elimine el contenido. Por esta razon, no se puede saber el
contenido que alojaba un directorio en el momento de ser eliminado. Es decir, no
podemos saber la fecha en la que fue eliminado un fichero.
No obstante, en esta investigacion no se necesita una fecha exacta de eliminacion
sino que se establece un rango de fechas. Ası, todos aquellos ficheros que hayan sido
accedidos, creados o modificados en una fecha posterior a FECHA INICIAL de un
directorio que se ha eliminado entre las fechas deseadas se puede afirmar que sı que
66
han sido eliminados en el periodo temporal entre FECHA INICIAL y FECHA FINAL
porque se tienen constancia de que existıan pasada FECHA INICIAL. El siguiente
esquema ejemplifica esta explicacion.
Figure 7.1: Esquema de representacion del borrado de ficheros.
Se han examinado los metadatos de los directorios eliminados para encontrar to-
dos aquellos que cumplen los requisitos indicados. Ademas, tal y como se acaba de
explicar, se han comprobado los registros temporales de todos los ficheros y subdi-
rectorios contenidos en estos directorios para elaborar un listado de todos los ficheros
eliminados entre FECHA INICIAL y FECHA FINAL del disco 04.
El sistema de ficheros NTFS sı que registra cuando un fichero ha sido enviado a
la papelera de reciclaje. Se ha elaborado un listado con los ficheros enviados a la
papelera entre FECHA INICIAL y FECHA FINAL aunque el hecho de que un fichero
se encuentre en la papelera de reciclaje no puede considerarse como borrado sı que
denota intencion de querer eliminarlo.
Los cuatro equipos Linux venıan con el sistema de ficheros EXT4. Este sistema de
ficheros registra cuatro marcas temporales en sus inodos. Estas son fecha de cambio
del inodo (ctime), fecha de acceso (atime), fecha de modificacion (mtime) y fecha de
eliminacion (dtime). Gracias al registro al campo deletion time (dtime) se puede saber
la fecha en la que un fichero fue eliminado. Se han analizado los metadatos de todos
67
los ficheros recuperados mediante la herramienta TestDisk para separar los ficheros
eliminados entre FECHA INICIAL y FECHA FINAL.
Ademas, los usuarios del sistema operativo Ubuntu (y Linux en general), se carac-
terizan por utilizar entornos menos graficos que en Windows, es decir, utilizan mas la
consola del sistema y no tanto las ventanas caracterısticas de Windows. Los coman-
dos ejecutados desde la terminal se almacenan en el fichero bash history que, por
defecto, viene limitado a XXX instrucciones almacenadas. Se ha analizado el historial
de comandos realizados y se han encontrado varias ejecuciones del comando rm de
remove en ingles, y que se utiliza para eliminar ficheros y directorios. Algunos de los
ficheros eliminados por lınea de comandos no han sido recuperados, por lo que se
ha querido ubicar en el tiempo la ejecucion de los comandos de borrado. Para ello,
se han analizado los comandos de antes y despues del borrado para establecer un
marco temporal en el que se han eliminado los ficheros. Es decir, si el comando an-
terior y posterior al de borrado de un fichero era de creacion de otros ficheros, se han
buscado los nuevos ficheros y se han analizado sus metadatos para saber la fecha
de creacion y, ası, establecer el momento en el que fue borrado el fichero. No se ha
podido establecer la fecha y hora de borrado de todos los ficheros.
7.6 Presentacion
Por ultimo, todas las notas recopiladas a lo largo de las fases anteriores, se presentan
en un informe de resultados. En este caso, el informe pericial del caso se puede
consultar en el anexo Informe pericial (apartado 8, pag. 76). En el informe pericial
no se incluyen los comandos realizados para obtener los resultados pero sı que se
explica el procedimiento seguido para llegar a los resultados y las conclusiones que
se desprenden de estos. Todo este proyecto se puede considerar que forma parte
de la fase de presentacion de la investigacion llevada a cabo con motivo del proyecto
final de carrera.
68
8 Conclusiones
Este trabajo ha tenido un enfoque teorico en su primera parte y practico en la segunda.
En la explicacion teorica del proyecto, hemos visto las distintas etapas por las que
pasa una investigacion forense digital: documentacion, preparacion, incidencia, res-
puesta a la incidencia, analisis forense digital y presentacion. Aunque cada investi-
gacion tiene sus particularidades, todas se pueden adaptar a las fases explicadas:
se empieza por la documentacion del caso, con los antecedentes que han llevado al
cliente a solicitar una investigacion y que sirven para tener contexto con el que tra-
bajar. La fase de documentacion sigue viva durante todo el caso, porque el perito
o analista forense anota todo el procedimiento seguido y los resultados conseguidos
con el fin de presentar un informe detallado de todos los hechos. Antes de llegar
a presentar nuestro informe, que se corresponde a la ultima fase, tambien se han
explicado las etapas de preparacion, incidencia y respuesta a la incidencia y, eviden-
temente, analisis forense digital en la que el investigador trabaja para confirmar la
hipotesis realizada sobre los hechos que mueven el caso. Dividir la investigacion en
distintas fases ayuda a entender mejor el proceso en su conjunto sin perder de vista
el objetivo final de la investigacion. Tambien es de utilidad a la hora de elaborar el
informe de forma logica y organizada.
A lo largo de todas las fases de la investigacion, es de especial importancia y de
obligado cumplimiento seguir las buenas practicas forenses, en las que se establecen
los principios basicos de:
• Integridad
• Auditabilidad
• Expertos
69
• Formacion adecuada
• Legalidad
Con tal de garantizar estos principios, se debe establecer la cadena de custodia para
asegurar que los datos no han sido modificados en ningun momento de la investi-
gacion y, ası, poder presentar, de forma clara y detallada, las pruebas en un proceso
legal.
En la parte practica del proyecto, hemos visto como tanto las fases mencionadas
anteriormente como los principios de buenas practicas forenses y la cadena de custo-
dia se pueden apreciar en la investigacion llevada a cabo por INCIDE. La investigacion
descrita en este proyecto no ha sido una excepcion. En este caso se han seguido to-
das las fases salvo la de respuesta a la incidencia, porque no hubo una incidencia
a tratar en el momento. Se establecio la cadena de custodia por parte del perito
ante notario en el momento de realizar la adquisicion de datos, hecho que asegura
la integridad y auditabilidad de los datos analizados, que han sido recogidos por un
especialista en presencia de un fedatario publico. Como se ha podido comprobar a
lo largo del proyecto, todas las acciones han seguido procedimientos legales y han
quedado perfectamente documentadas para quien desee consultarlas.
Los objetivos marcados para la investigacion eran los siguientes:
• Extraer todos los fichero que, en su denominacion, contengan el nombre PALA-
BRA A o PALABRA B.
• Extraer todos los correos electronicos enviados o recibidos entre DIRECCION 1
y DIRECCION 2.
• Verificar que los correos electronicos extraıdos son ıntegros.
• Extraer todos los ficheros eliminados entre FECHA INICIAL y FECHA FINAL.
Para cumplir estos objetivos se han seguido varios procedimientos forenses adap-
tados a cada objetivo en particular. Como se puede ver en el anexo Conclusiones
(apartado 3, pag. 91), se ha respondido satisfactoriamente cada uno de los objetivos
planteados. Los puntos que conllevaron un mayor desempeno por parte del investi-
gador fueron la verificacion de la integridad de los correos electronicos y la extraccion
de ficheros eliminados entre dos fechas concretas.
70
Puesto que los correos electronicos son facilmente manipulables, se debe tener
especial cuidado en la comprobacion de la concordancia y coherencia de los distintos
datos que aparecen en las cabeceras de los correos. En el caso de la extraccion
de ficheros eliminados entre dos fechas, la tarea puede llegar a no ser concluyente
debido a las caracterısticas de cada sistema de ficheros. En concreto, hemos visto
que NTFS, el sistema de ficheros utilizado en Windows, no registra la fecha y hora
de borrado de los ficheros, por lo que solo se puede asegurar una ventana de tiempo
para la eliminacion de un fichero. Todos estos factores contribuyen en gran medida al
exito de una investigacion digital.
71
Bibliography
[1] Brian Carrier. File system forensic analysis, 2005.
[2] International Organization for Standardization. Iso/iec 27037:2012, 2012. URL
https://www.iso.org/obp/ui/#iso:std:iso-iec:27037:ed-1:v1:en.
[3] Information Security Group. URL http://futur.upc.edu/ISG.
[4] SANS Institute. Windows time rules, 2012. URL https://uk.sans.org/posters/
windows_artifact_analysis.pdf.
[5] Michael Donovan Kohn. Integrated digital forensic process model, 2012.
[6] The Sleuth Kit. Help documents. URL http://wiki.sleuthkit.org/index.php?
title=Help_Documents.
[7] U.S. Department of Justice Office of Justice Programs. Electronic crime scene
investigation: A guide for first responders, 2001. URL https://www.ncjrs.gov/
pdffiles1/nij/219941.pdf.
[8] RegRipper. URL https://code.google.com/archive/p/regripper/.
[9] INCIDE Digital Data S.L. URL http://www.incide.es.
[10] Microsoft Enterprise Platforms Support: Windows Server Core Team. Ntfs file
attributes, 2010. URL https://blogs.technet.microsoft.com/askcore/2010/
08/25/ntfs-file-attributes/.
[11] TestDisk and PhotoRec. URL http://www.cgsecurity.org/.
[12] Forensics Wiki. Mac times. URL http://www.forensicswiki.org/wiki/MAC_
times#NTFS.
73
[13] Wikipedia. Simple mail transfer protocol. URL https://en.wikipedia.org/wiki/
Simple_Mail_Transfer_Protocol.
74
75
Informe pericial
76
Informe pericial con relacion al procedimiento de
diligencias previas XXX
1 Cuestiones previas
1.1 Consideraciones previas
La siguiente informacion ha sido facilitada por el Cliente. Ha sido extraıda de las
diligencias previas XXX del juzgado numero 1 de XXX:
• La Empresa despide a Cliente, por sospechar de irregularidades en las cuentas.
• La Empresa denuncia a Cliente por supuestas operaciones de venta de material
en un periodo en el que el denunciado desempenaba sus tareas en la Empresa.
• Concretamente por la venta de material a un cliente en concreto por un precio
que no se correspondıa con la facturacion entre ambas empresas.
1.2 Solicitud de opinion
Por todo lo expuesto en el apartado anterior, Cliente ha solicitado mi opinion sobre los
siguientes extremos:
• Extraer todos los fichero que, en su denominacion, contengan el nombre PALA-
BRA A o PALABRA B.
• Extraer todos los correos electronicos enviados o recibidos entre DIRECCION 1
y DIRECCION 2.
• Verificar que los correos electronicos extraıdos son ıntegros.
• Extraer todos los ficheros eliminados entre FECHA INICIAL y FECHA FINAL.
1.3 Fuentes de informacion
La informacion recogida en este informe deriva del analisis de los datos contenidos
en los siguientes sistemas y/o soportes informaticos:
77
• Disco WD2500AAJS 250GB identificado como Disco 01
• Disco Seagate Barracuda 250GB identificado como Disco 02
• Disco Seagate Barracuda 250GB identificado como Disco 03
• Disco SAMSUNG HD103SJ identificado como Disco 04
• Disco Seagate Barracuda 250GB identificado como Disco 05
1.4 Adquisicion de datos y cadena de custodia
Este apartado recoge las circunstancias en que se obtuvieron las diferentes fuentes
de informacion para su analisis.
En Barcelona, el representante legal de la Empresa proporciono cinco (5) orde-
nadores de sobremesa que contenıan los discos mencionados en el apartado ante-
rior (Fuentes de informacion (apartado 1.3, pag. 77)) con el fin de que el notario D.
Notario, en fecha XXX, diese fe del proceso de copia realizado.
Una vez allı, se procedio a la identificacion y extraccion de los discos duros de los
ordenadores entregados para realizar dos copias de cada disco duro, quedando los
originales en deposito notarial y entregandose una de las dos copias de cada disco
a INCIDE y la otra al representante legal de la Empresa. Junto con los equipos se
deposito un dispositivo de memoria externa USB que contenıa fotografıas realizadas
del proceso de identificacion, extraccion y clonacion de los discos junto con el calculo
de la funcion criptografica hash de cada disco.
Todo el proceso se llevo a cabo en la citada fecha en las dependencias notariales
de la Notarıa de D. Notario de Barcelona, quedando reflejada en el protocolo notarial
numero XXX. Para ver mas detalles, vease el anexo de detalle de aseguramiento de
pruebas Aseguramiento de las fuentes de informacion (apartado 4.1, pag. 93).
A continuacion se reflejan los hash de los correspondientes discos duros.
MD5 (Disco_01.dd): c2cb76d72c5c2662d78e28c4e36ec6bb
MD5 (Disco_02.dd): a1d078a880dde94789fa4w4ba28d44c5
MD5 (Disco_03.dd): a4b69h1b11d4f5574096d569ccb20da3
MD5 (Disco_04.dd): pxj47sbf61jhd73bn6ouyasdkgh5411a
78
MD5 (Disco_05.dd): gsorb69sb12doo750bawn34g211dijsl
79
2 Dictamen
2.1 (a) Extraer todos los fichero que, en su denominacion,
contengan el nombre PALABRA A o PALABRA B
El Cliente requiere extraer todos los ficheros de los discos duros que, en su nombre,
contengan las palabra PALABRA A y/o PALABRA B. Para ello, se han utilizado tres
procedimientos diferentes:
• Realizar una busqueda directamente en el sistema de ficheros actual.
• Extraer un listado de ficheros y directorios del disco actuales y borrados recien-
temente y, en este arbol de directorios y ficheros, realizar una busqueda por
nombre de fichero.
• Realizar una busqueda en los directorios con la herramienta de recuperacion de
ficheros TestDisk.
Estos procedimientos se detallan a continuacion.
Realizar una busqueda directamente en el sistema de ficheros actual
El procedimiento mas eficaz para encontrar ficheros que aun se encuentran en el
sistema de ficheros es extraer un listado de todos los ficheros existentes y realizar
una busqueda en ese listado. Ambos procedimientos estan automatizados, por lo que
se evitan errores humanos. Ademas, dado la busqueda se realiza por palabra clave,
no se analizan todos los ficheros uno a uno y, de esta forma, se protege la privacidad
del usuario. Para maximizar resultados, se ignoran las mayusculas y minusculas ası
como las tildes.
Resultados
• Disco 01: No se han encontrado ficheros.
• Disco 02: No se han encontrado ficheros.
• Disco 03: No se han encontrado ficheros.
80
• Disco 04: Se han encontrado tres ficheros no borrados. El contenido de estos
archivos es recuperable.
• Disco 05: No se han encontrado ficheros.
Una vez confirmada la presencia de ficheros relevantes, se accede al equipo para
obtener estos ficheros. Para poder ver el contenido de los discos duros sin alterar el
contenido de estos, se monta el sistema de ficheros en modo solo lectura. Notese
que al montar el sistema de ficheros no se esta encendiendo el ordenador, por lo
que los registros que hacen relacion a encendidos/apagados y logueos no se modi-
fican. El hecho de montar el disco en con la opcion de solo lectura se imposibilita la
modificacion de ficheros del disco.
Extraer un listado de ficheros y directorios del disco actuales y borrados
recientemente y, en este arbol de directorios y ficheros, realizar una busqueda
por nombre de fichero
Se ha extraıdo un listado de ficheros y directorios a partir de la copia de cada disco. Al
realizarse sobre todo el disco y no de la unidad montada, pueden aparecer ficheros y
directorios eliminados en la lista. A partir de los listados se ha realizado una busqueda
por las palabras clave PALABRA A y PALABRA B. Igual que en procedimiento ante-
rior, se ignoran mayusculas, minusculas y tildes para maximizar los resultados.
Resultados
• Disco 01: No se han encontrado ficheros.
• Disco 02: No se han encontrado ficheros.
• Disco 03: No se han encontrado ficheros.
• Disco 04: Se han encontrado tres ficheros no borrados. El contenido de estos
ficheros es recuperable.
• Disco 05: No se han encontrado ficheros.
Los ficheros coinciden con la busqueda realizada con el metodo anterior.
81
Realizar una busqueda en los directorios con la herramienta de recuperacion
de ficheros TestDisk
Para recuperar ficheros borrados se ha utilizado la herramienta TestDisk, que permite
recuperar ficheros eliminados conservando el nombre de fichero. Esta herramienta
tiene ciertas limitaciones. En el caso de los equipos Linux (01, 02, 03, y 05), que
utilizan el sistema de ficheros EXT4, no puede recuperar los ficheros, pero si que
permite visualizar ficheros que han sido eliminados.
Resultados
• Disco 01: Se han localizado 2 ficheros pero no se han podido recuperar.
• Disco 02: No se ha detectado ningun fichero.
• Disco 03: Se han localizado 4 ficheros pero no se han podido recuperar.
• Disco 04: Se han detectado 7 ficheros eliminados y se han recuperado con
TestDisk.
• Disco 05: Se han localizado 1 fichero pero no se ha podido recuperar.
En el proceso de recuperacion de ficheros mediante la herramienta TestDisk se han
detectado varios ficheros que, en su nombre, contenıan las palabras PALABRA A y/o
PALABRA B. Desafortunadamente, debido al tipo de sistema de ficheros que utilizan
los discos Linux, no se han podido recuperar los ficheros detectados.
Se realizo una segunda busqueda utilizando la herramienta PhotoRec. PhotoRec
es una herramienta que permite recuperar ficheros eliminados y que admite ciertos
filtros, es decir, permite seleccionar el tipo de fichero que se quiere recuperar (doc,
png, xls jpg, ppt, etc.). El inconveniente que presenta Photorec es que los ficheros
carecen de metadatos, como el nombre del fichero. Se realizaron busquedas con las
misma extensiones que los ficheros detectados con PhotoRec. Como resultado se
han obtenido gran cantidad de ficheros sin nombre y con las extensiones deseadas.
Dada la gran cantidad de resultados es imposible asociar los ficheros detectados con
los resultados.
82
2.2 (b) Extraer todos los correos electronicos enviados o
recibidos entre DIRECCION 1 y DIRECCION 2
Se pide extraer todos los correos electronicos recibidos o enviados entre las direc-
ciones de correo electronico DIRECCION 1 y DIRECCION 2. Para ello, se han seguido
tres procedimientos distintos.
• Busqueda en el sistema de ficheros.
• Busqueda a partir de la imagen del disco.
Busqueda en el sistema de ficheros
Se ha realizado una busqueda de correos electronicos en los directorios de los dis-
cos. En concreto se han buscado directorios de gestores de correo electronico como
Outlook, Thunderbird, etc. y tambien se han buscado en los ficheros temporales de
Internet. Se ha encontrado el gestor de correo Evolution en 4 de los discos y el gestor
de correo Microdoft Outlook en el disco restante. No se han encontrado indicios de
correos electronicos en el historial de navegacion de Internet de ninguno de los discos.
• Disco 01: Se han encontrado dos directorios del gestor de correo Evolution,
un directorio con el nombre Evolution y otro con el nombre Evolution-definitivo.
Las coincidencias resultado de la busqueda por la palabra clave DIRECCION 2
fueron en el directorio Evolution-definitivo pero se trataba de la base de datos de
la agenda de direcciones de correo. No se ha encontrado correspondencia entre
DIRECCION 1 y DIRECCION 2 aunque el hecho de que se haya encontrado
la DIRECCION 2 en la agenda puede significar que sı se han intercambiado
correos electronicos en algun momento pero que han sido eliminados.
• Disco 02: Se han encontrado resultados de la busqueda de DIRECCION 2 en
el directorio del gestor de correos Evolution. Se ha realizado una busqueda con
la palabra clave DIRECCION 2 dentro de este directorio y la unica coinciden-
cia ha sido la direccion DIRECCION 2 en la base de datos de la agenda de
correos, igual que en el disco 01. No se ha encontrado correspondencia entre
DIRECCION 1 y DIRECCION 2.
83
• Disco 03: El procedimiento seguido y los resultados obtenidos han sido los mis-
mos que en el disco 02. No se ha encontrado ninguna coincidencia con la pala-
bra clave DIRECCION 2.
• Disco 04: Se han encontrado resultados de la busqueda de DIRECCION 2 en
el directorio del gestor de correos Microsoft Outlook. En concreto, se han en-
contrado coincidencias en las bases de datos de la bandeja de entrada y en la
bandeja de correos eliminados y tambien en la agenda de contactos. Para re-
cuperar estos correos se ha usado la herramienta undbx, que extrae correos de
las bases de datos de Outlook. Ademas, con la opcion de recuperacion no solo
extrae los correos, sino que tambien recupera posibles correos borrados y los
presenta en carpetas separadas para distinguirlos.
• Disco 05: Se han encontrado resultados de la busqueda de DIRECCION 2 en
el directorio del gestor de correos Evolution. Se ha realizado una busqueda con
la palabra clave DIRECCION 2 dentro de este directorio y se han encontrado
coincidencias en varios ficheros. Por alguna razon que este perito desconoce,
las bases de datos no mostraban los datos de cada correo de forma individual,
por lo que se han tenido que filtrar los correos a partir de la base de datos
completa. Para garantizar el derecho a la intimidad de los usuarios, esta criba se
ha realizado de forma automatica mediante busquedas ciegas con las palabras
clave DIRECCION 1 y DIRECCION 2.
Resultados
• Disco 01: No se han encontrado correos entre DIRECCION 1 y DIRECCION 2.
• Disco 02: No se han encontrado correos entre DIRECCION 1 y DIRECCION 2.
• Disco 03: No se han encontrado correos entre DIRECCION 1 y DIRECCION 2.
• Disco 04: Se han encontrado correos entre DIRECCION 1 y DIRECCION 2.
• Disco 05: Se han encontrado correos entre DIRECCION 1 y DIRECCION 2.
84
Busqueda a partir de la imagen del disco
Se han extraıdo las cadenas del disco, es decir, todos los caracteres imprimibles del
disco. A partir del fichero resultante se han realizado dos busquedas independientes
por las palabras clave DIRECCION 1 y DIRECCION 2 para confirmar la presencia de
estas direcciones en el disco. Una vez asegurada la presencia de las direcciones,
se ha filtrado toda la informacion del fichero de cadenas dando como resultado los
correos electronicos enviados o recibidos entre las dos direcciones de correo. Dado
que se ha realizado sobre el fichero de cadenas, hay correos que no se han podido
recuperar en su totalidad.
Este procedimiento se ha usado con todos los discos y con el hemos encontrado
tanto correos que se encuentran en el sistema de ficheros existentes como correos
que han sido eliminados.
Resultados
• Disco 01: Se han encontrado correos entre DIRECCION 1 y DIRECCION 2.
• Disco 02: Se han encontrado correos entre DIRECCION 1 y DIRECCION 2.
• Disco 03: No se han encontrado correos entre DIRECCION 1 y DIRECCION 2.
• Disco 04: Se han encontrado correos entre DIRECCION 1 y DIRECCION 2.
• Disco 05: Se han encontrado correos entre DIRECCION 1 y DIRECCION 2.
2.3 (c) Verificar que los correos electronicos extraıdos son
ıntegros
Una vez extraıdos, los correos electronicos tienen que ser analizados para probar su
integridad, es decir, para comprobar que no han sido alterados. Un correo electronico
presentado en papel es susceptible de ser manipulado con facilidad con un editor
de textos como Bloc de notas o con un editor de imagenes como Photoshop antes
de imprimirse y presentarse (de forma invalida segun la opinion de este perito). Un
correo electronico presentado en formato digital tambien puede haber sido alterado
85
con facilidad sin que se note en el contenido. Es por este motivo que es importante la
adveracion de los correos electronicos. Un correo electronico esta compuesto por la
cabecera tecnica, en la que hay informacion imprescindible para que el correo llegue
a su destinatario ası como de todos los saltos realizados a traves de servidores en-
tre su origen y su destino; la cabecera simple, en la que hay informacion sobre las
direcciones de correo del emisor y del receptor, el asunto del correo y la fecha entre
otros; el cuerpo del correo, en el que hay el texto enviado por el emisor; y los posibles
documentos adjuntos al correo. Para mas informacion se puede consultar el anexo
Procedimiento para analisis de correo electronico (apartado 4.6, pag. 97).
Los correos electronicos extraıdos han sido albergados por los gestores de correo
electronico Evolution y Microsoft Outlook. Se ha analizado la informacion de las
cabeceras de todos los correos electronicos extraıdos en su totalidad. Todos los datos
analizados son coherentes. Se puede afirmar, por tanto, que todos los correos son
ıntegros y no existen alteraciones. Estos correos electronicos se pueden encontrar
en el anexo Correos electronicos entre DIRECCION 1 y DIRECCION 2 (apartado 4.3,
pag. 95). Los correos electronicos parciales han sido analizados en la medida de
lo posible. Se han dividido en dos casos: los correos cuyas cabeceras se han recu-
perado en su totalidad y que tienen un cuerpo de correo y adjuntos parciales, y los
correos cuyas cabeceras no se han podido recuperar en su totalidad y que tienen un
cuerpo y adjuntos totales o parciales. Los correos electronicos de los que se dispone
de una cabecera total, han sido analizados. Se puede afirmar que todos ellos son
ıntegros. Aquellos correos de los que no se dispone de cabeceras totales no han po-
dido ser adverados, no se dispone de informacion suficiente como para afirmar que
no han sido modificados, aunque tampoco se puede afirmar lo contrario.
Destacan aquellos correos que han sido enviados desde DIRECCION 2 a traves
del gestor de correo Microsoft Outlook por incluir, en su cabecera tecnica, la direccion
IP de origen del correo que permite determinar el origen de la transmision del correo
electronico.
86
2.4 (d) Extraer todos los ficheros eliminados entre
FECHA INICIAL y FECHA FINAL
El Cliente requiere recuperar los ficheros eliminados entre dos fechas determinadas.
Para extraer ficheros eliminados se utilizan herramientas forenses que recuperan
ficheros eliminados que aun no han sido sobrescritos. Es conveniente empezar desta-
cando que los discos 01, 02, 03 y 05 utilizan el sistema operativo Ubuntu 10.04.3,
mientras que el disco 04 utiliza el sistema operativo Windows XP tal y como se detalla
en el anexo Identificacion de los equipos (apartado 4.5, pag. 95).
El sistema operativo Ubuntu, basado en Linux, tiene un campo de metadatos de
los ficheros en el que se registra la fecha de borrado. Sin embargo, la recuperacion
de ficheros no es una tarea facil porque los metadatos asociados a un fichero no
siempre se recuperan junto a este. Se ha utilizado la herramienta TestDisk porque
permite recuperar ficheros enteros, contenido y metadatos asociados. Por contra, no
es capaz de recuperar tantos ficheros como otras herramientas. Dado que se han
detectado ficheros eliminados que no han podido ser recuperados con TestDisk, se
ha decidido utilizar tambien PhotoRec. Esta herramienta es capaz de recuperar el
contenido de muchos ficheros pero aunque estos no llevan los metadatos asociados,
por lo que se tiene el contenido de ficheros sin toda la metainformacion disponible,
como el nombre, propietario del fichero o referencias temporales. Con los equipos
que operan con Linux, sı que se puede determinar la fecha en que un fichero fue
eliminado porque existe el campo dtime, en el que se actualiza la fecha y hora en el
momento de ser eliminado. Se ha utilizado una herramienta de carving para recuperar
ficheros eliminados. Analizando los metadatos de los ficheros recuperados se han
encontrado ficheros eliminados que cumplen el requisito de haber sido eliminados
entre FECHA INICIAL y FECHA FINAL.
Los usuarios del sistema operativo Ubuntu y Linux en general, se caracterizan por
utilizar entornos menos graficos que en Windows, es decir, utilizan mas la consola
del sistema y no tanto las ventanas caracterısticas de Windows. Se ha examinado
el historial de comandos (acciones) realizadas desde consola y se han encontrado
varias ejecuciones del comando rm de remove en ingles, y que se utiliza para eliminar
ficheros y directorios. El historial de comandos es limitado y solo se muestra infor-
87
macion temporal del ultimo comando ejecutado. Examinando los sistemas de ficheros
para buscar rastros de las ejecuciones realizadas se ha podido establecer un listado
de ficheros fueron eliminados dentro del rango temporal.
Resultados
• Disco 01: XX ficheros eliminados entre FECHA INICIAL y FECHA FINAL.
• Disco 02: Se han identificado ficheros eliminados pero no se han podido recu-
perar, por lo que no se puede comprobar la fecha de eliminacion de estos.
• Disco 03: XX ficheros eliminados entre FECHA INICIAL y FECHA FINAL.
• Disco 05: XX ficheros eliminados entre FECHA INICIAL y FECHA FINAL.
NTFS, el sistema de ficheros utilizado por Windows, no registra datos del momento
en el que se borra un fichero dentro de los metadatos del fichero. Esto ocurre porque
a un usuario no le interesa la fecha de eliminacion de un fichero que esta borrando,
lo que el quiere es que el fichero desaparezca y, por lo tanto, NTFS se ahorra este
proceso. Sin embargo, aunque los metadatos de un fichero o directorio eliminado no
incluyan cuando fue borrado, sı que es posible encontrar rastros indirectos de cuando
sucedio este evento. Cuando un fichero o directorio se renombra, se mueve o se
elimina, el directorio en el que esta contenido detecta el cambio y marca la fecha y
hora en la que se produce.
Cada directorio guarda un ındice de los ficheros que contiene. Y este ındice va au-
mentando a medida que el directorio aloja mas ficheros o subdirectorios. El tamano
del ındice no disminuye aunque se elimine contenido del directorio. Por lo tanto,
aunque se detecte un directorio eliminado con un ındice de cierto tamano, no se
puede asegurar el contenido que se encontraba en el directorio en el momento de
ser eliminado, sino el contenido maximo que ha llegado a tener el directorio. Lo que
significa que si en el sistema de ficheros del equipo de Windows nos encontramos con
un directorio que actualmente esta borrado y cuya fecha de ultima modificacion es de
un dıa determinado, no podemos asegurar que el directorio fuese borrado aquel dıa
en concreto, es mas, hasta ese momento lo que sı que se puede asegurar es que el
directorio no estaba eliminado. Podemos decir que el directorio fue eliminado entre
88
la fecha de su ultima modificacion y la fecha de ultima modificacion del directorio que
lo contiene, porque al borrarse el primero (hijo), se registra una modificacion en el
segundo (padre). El sistema de ficheros NTFS sı que registra cuando un fichero ha
sido enviado a la papelera de reciclaje.
Para realizar el analisis de ficheros borrados entre FECHA INICIAL y FECHA FINAL
del disco 04 se han seguido dos pasos:
1. Establecer ventanas temporales mediante la fecha de ultima modificacion de los
directorios y subdirectorios.
2. Filtrar los ficheros contenidos en los directorios por sus fechas de acceso.
De forma complementaria, se ha elaborado un listado de los ficheros enviados a la
papelera de reciclaje entre FECHA INICIAL y FECHA FINAL. Estos procedimientos
se detallan a continuacion.
Establecer ventanas temporales mediante la fecha de ultima modificacion de
los directorios y subdirectorios
Como se acaba de explicar, el sistema de ficheros NTFS no registra la fecha y hora
de eliminacion de los directorios ni de los ficheros, por lo que es imposible asegurar
la fecha en la un fichero o directorio fue eliminado. Examinando los metadatos de
los directorios se ha elaborado un listado de los directorio que han sido eliminados
con certeza dentro del periodo establecido, entre FECHA INICIAL y FECHA FINAL.
Por la estructura en la que se diseno el sistema de ficheros NTFS, los ficheros y
subdirectorios alojados en un directorio se van anadiendo en nodos. Los nodos per-
manecen aunque se elimine el fichero o subdirectorio y no se registra la fecha de eli-
minacion del fichero o subdirectorio. Los directorios eliminados entre FECHA INICIAL
y FECHA FINAL tienen un cierto numero de nodos que indican el numero maximo
de ficheros y subdirectorios que han llegado a alojar en algun momento, pero no se
puede asegurar o desmentir la presencia de todos estos ficheros y subdirectorios en
el momento de eliminar los ficheros.
89
Filtrar los ficheros contenidos en los directorios por sus fechas de acceso
Para determinar que ficheros fueron eliminados en la ventana temporal requerida se
extrajo la lınea temporal (o timeline) de la actividad de cada equipo. Como se acaba de
explicar, salvo en ocasiones muy puntuales, como es el uso de la papelera de reciclaje,
resulta imposible determinar con absoluta certeza la fecha exacta del borrado de un
fichero. No obstante, se puede asegurar que ciertos ficheros han sido eliminados
dentro de la ventana temporal que va desde FECHA INICIAL hasta FECHA FINAL.
Se han buscado en la timeline los ficheros contenidos dentro de los directorios
eliminados entre FECHA INICIAL hasta FECHA FINAL. Se puede afirmar que todos
aquellos ficheros cuya fecha de acceso sea posterior a FECHA INICIAL han sido eli-
minados dentro del periodo indicado.
En concreto, se han localizado XX ficheros y XX directorios. El listado completo se
puede consultar en el anexo Ficheros eliminados entre FECHA INICIAL y FECHA FINAL
(apartado 4.4, pag. 95).
Analisis de los historiales de la papelera de reciclaje
Como se ha explicado anteriormente en este mismo apartado, las marcas temporales
de los ficheros eliminados a traves de la papelera de reciclaje sı que se actualizan, en
concreto se modifican en el momento en que un fichero es enviado a la papelera, tanto
en Linux como en Windows. No solo se registra el momento en el que el fichero fue
enviado a la papelera de reciclaje sino que los metadatos conservan el directorio en
el que se encontraba el fichero antes de ser enviado a la papelera. No ha sido posible
analizar los metadatos asociados a los ficheros de la papelera del disco 02 por la
irregularidad detectada en la copia proporcionada, pero se confirma la existencia de
ficheros en la papelera de reciclaje. Los ficheros que en el momento del analisis se
han encontrado en la papelera se pueden ver en el anexo Ficheros eliminados entre
FECHA INICIAL y FECHA FINAL (apartado 4.4, pag. 95) aunque, insistimos, estos
ficheros no pueden considerarse como eliminados.
90
3 Conclusiones
De todo lo expuesto anteriormente se puede concluir que:
• Se han encontrado un total de XX ficheros que, en su nombre, contienen
las palabras PALABRA A y/o PALABRA B.
• En concreto:
– Se han encontrado XX ficheros con solo la palabra PALABRA A en su nom-
bre.
– Se han encontrado XX ficheros con solo la palabra PALABRA B en su nom-
bre.
– Se han encontrado XX ficheros con la palabra PALABRA A y la palabra
PALABRA B en su nombre.
• Se han extraıdo un total de XX correos electronicos enviados o recibidos
entre DIRECCION 1 y DIRECCION 2.
• En concreto:
– Se han extraıdo XX correos electronicos completos. Todos ellos son ver-
aces.
– Se han extraıdo XX correos electronicos con cabeceras completas y con-
tenidos parciales. Todos ellos son veraces.
– Se han extraıdo XX correos electronicos con cabeceras parciales. No se
puede afirmar ni desmentir su veracidad.
• Se han recuperado XX ficheros eliminados entre FECHA INICIAL y FECHA FINAL.
• De los ficheros recuperados, hay un total de XX ficheros de los que no se ha
podido recuperar el nombre ni la ruta en la que se encontraban antes de ser
eliminados.
• Aunque no pueden considerarse como eliminados, se han encontrado XX ficheros
que fueron enviados a la papelera de reciclaje entre FECHA INICIAL y FECHA FINAL.
91
• Los resultados del disco 02 podrıan ampliarse si se demuestra que la copia
realizada en dependencias notariales tuvo algun error y se procede a realizar
una nueva copia forense.
Y esto es todo cuanto tengo que decir a mi buen saber y entender.
92
4 Anexos
En los siguientes apartados se incluirıan los anexos del informe en los que se mues-
tra informacion mas tecnica de la investigacion y el detalle de los resultados. Esta
informacion se incluye en los anexos y no en el cuerpo del informe para facilitarse la
lectura del mismo.
4.1 Aseguramiento de las fuentes de informacion
Este apartado recoge el proceso de identificacion, extraccion y copia de los discos.
Para que este proyecto de fin de carrera no revele datos reales del caso, solo se
incluyen dos fotografıas.
Figure 1: Clonacion de un disco mediante la clonadora.
93
Figure 2: Sobre sellado que asegura la cadena de custodia.
4.2 Ficheros con las palabras PALABRA A y/o PALABRA B en el
nombre
En este anexo se incluirıa un listado de todos los ficheros encontrados cuyos nombre
contengan la palabra A o la palabra B separados por el disco en el que se han encon-
trado y clasificados por formato (doc, xls, lnk, etc). De ser necesario, se entregarıan
los ficheros en un dispositivo de almacenamiento externo como un USB o un CD.
94
4.3 Correos electronicos entre DIRECCION 1 y DIRECCION 2
En este anexo se reproducirıan los correos electronicos enviados y recibidos entre
DIRECCION 1 y DIRECCION 2 separados por disco de procedencia y ordenados por
fecha. En el caso de haber una gran cantidad de correos electronicos, que es lo que
paso en esta investigacion, se opto por reproducir en este anexo solo los correos
electronicos que el Cliente considero relevantes. El total de correos electronicos
fueron entregados en un dispositivo de almacenamiento externo USB.
4.4 Ficheros eliminados entre FECHA INICIAL y FECHA FINAL
En este anexo se incluirıa un listado de todos los ficheros y directorios que pueden
asegurarse que fueron borrados entre FECHA INICIAL y FECHA FINAL separados
por disco de procedencia y ordenados cronologicamente. De ser necesario, se entre-
garıan los ficheros en un dispositivo de almacenamiento externo como un USB o un
CD. Como subapartado del mismo anexo, se incluirıa tambien un listado de todos los
ficheros que se encontraban en la papelera de reciclaje en el momento de realizar la
investigacion y que cumplen los requerimientos temporales.
4.5 Identificacion de los equipos
A continuacion se detallan las caracterısticas principales de cada equipo:
• Disco-01
– Nombre del equipo: XXX-09
– Sistema operativo: Ubuntu 10.04.3 LTS
– Fecha de instalacion: 10 de septiembre de 2010 a las 14:05:57 (UTC +2)
– Fecha ultimo apagado: 14 de febrero de 2012 a las 18:38 (UTC)
– Usuarios: XXX
– Fecha ultimo login del usuario: 14 de febrero de 2012 a las 18:37 (UTC)
• Disco-02
– Nombre del equipo: XXX-04
95
– Sistema operativo: Ubuntu 10.04.3 LTS
– Fecha de instalacion: 25 de septiembre de 2010 a las 08:34:41 (UTC +2)
– Fecha ultimo apagado: 14 de febrero de 2012 a las 19:41 (UTC)
– Usuarios: XXX
– Fecha ultimo login del usuario: 14 de febrero de 2012 a las 18:24 (UTC)
• Disco-03
– Nombre del equipo: XXX-06
– Sistema operativo: Ubuntu 10.04.3 LTS
– Fecha de instalacion: 24 de septiembre de 2010 a las 15:36:09 (UTC +2)
– Fecha ultimo apagado: 14 de febrero de 2012 a las 19:22 (UTC)
– Usuarios: XXX
– Fecha ultimo login del usuario: 14 de febrero de 2012 a las 18:21 (UTC)
• Disco-04
– Nombre del equipo: DESKTOP
– Sistema operativo: Windows XP SP2
– Fecha de instalacion: 3 de junio de 2011 a las 14:05:57 (UTC)
– Fecha ultimo apagado: 14 de febrero de 2012 a las 16:16:26 (UTC)
– Usuarios: Administrador
– Fecha ultimo login del usuario: 8 de febrero de 2012 a las 07:36:43 (UTC)
• Disco-05
– Nombre del equipo: XXX-05
– Sistema operativo: Ubuntu 10.04.3 LTS
– Fecha de instalacion: 10 de diciembre de 2010 a las 08:31:22 (UTC +1)
– Fecha ultimo apagado: 14 de febrero de 2012 a las 16:49 (UTC)
– Usuarios: XXX
– Fecha ultimo login del usuario: 14 de febrero de 2012 a las 16:47 (UTC)
96
4.6 Procedimiento para analisis de correo electronico
Un correo electronico es un servicio que permite a los usuarios enviar y recibir men-
sajes mediante sistemas de comunicacion electronica. Un correo electronico es sus-
ceptible de ser alterado o manipulado. La presentacion de un correo como prueba
debe hacerse en formato digital y con determinadas garantıas como la custodia del
medio que los alberga, ya sea el buzon de correo electronico en el que se encuentra
o el correo web (webmail) en el que esta contenido el correo electronico. El estudio
de la adveracion de correos consiste en un analisis de las fuentes de informacion
disponibles en cada caso (cabeceras de correo, propiedades del buzon de correo,
registros del servidor o logs, etc.) para determinar si los correos conservan su integri-
dad o si, por el contrario, se observan incoherencias en los datos existentes en dichas
fuentes de informacion que puedan indicar que esos correos electronicos han podido
sufrir alguna manipulacion.
En los casos en los que sea posible, es especialmente relevante disponer de buzon
de correo en el que originalmente residen los correos electronicos objeto del trabajo
de adveracion, ya que los buzones de correo de los distintos gestores de correo que
existen en el mercado (Microsoft Outlook, Lotus Notes, Thunderbird, Evolution, etc.)
contienen una serie de metainformacion introducida por el gestor de correo que per-
mite su correcto funcionamiento. Esta informacion es incorporada de forma transpar-
ente por el programa gestor de correo y no puede ser manipulada directamente por
el usuario, por lo que el analisis de sus valores permite deducir, a partir de su estudio
detallado, las acciones realizadas por cada mensaje, incluyendo la presencia o ausen-
cia de posibles modificaciones a las que el correo haya podido ser sometido tras ser
enviado/recibido.
En el caso de que el servicio de correo electronico sea proporcionado directamente
mediante el explorador de Internet (Firefox, Chrome, etc.), el gestor de correo no es
un programa independiente usado para tal fin sino que se utiliza un correo web o
webmail, que es un cliente de correo electronico que provee una interfaz web por
la que se accede al correo electronico. Los mas populares son Gmail, Hotmail o
Yahoo. Cuando el correo electronico que se desea analizar provenga de webmail, la
fuente de informacion objeto de analisis que requiere ser asegurada es el contenido
97
completo de dicho correo electronico, es decir, el cuerpo del correo en el que esta el
contenido del mismo, los ficheros adjuntos y la cabecera completa. La cabecera de
un correo electronico, esta formada por una serie de datos identificativos del mensaje,
del cuerpo y de los datos adjuntos al mensaje de correo electronico. En realidad un
correo electronico es el conjunto de las cabeceras, cuerpo y datos adjuntos, pero
debido a que no aportan demasiada informacion al usuario y que, dada su extension
y complejidad tecnica, suponen mas bien una molestia para el mismo, la mayorıa de
los programas y sistemas de correo electronico no muestran, por defecto, los datos
de la cabecera. Sin embargo, la gran mayorıa de estos presentan diferentes opciones
para poder visualizarlas.
La cabecera simple esta formada por los campos que se muestran al abrir el correo
electronico. Estos campos suelen mostrarse en el idioma en el que se ha configurado
el gestor o el cliente de correo. Los campos mas importantes de la cabecera simple
son los siguientes:
• De:
• Para:
• Asunto:
• Fecha:
La cabecera tecnica contiene informacion muy valiosa desde el punto de vista
tecnico que ayudan al investigador o perito forense a establecer una trazabilidad del
correo en Internet, pudiendo determinar, en algunas de las ocasiones, desde que di-
reccion IP se envio el mensaje 1 (entre otras cosas). En la cabecera tecnica, todos los
campos estan escritos en ingles, empiezan con mayuscula y acaben en dos puntos
(:). Algunos de los campos que se muestran en la cabecera tecnica son los siguientes:
• Delivered-To:
• Received:
• Return-Path:1La mayorıa de clientes de correo web, como Gmail, no proporcionan la direccion IP desde la que se
ha enviado el correo para ofrecer privacidad al usuario.
98
• In-Reply-To:
• Message-ID:
El aseguramiento debe realizarse en el formato original, es decir, en formato digital
puesto que se trata de un correo electronico, almacenandolo en un dispositivo ade-
cuado tal como una memoria USB (o pendrive) u otro dispositivo de almacenamiento
de datos. En este caso tambien deben ser asegurados los registros de actividad
asociados a esa cuenta de correo (los logs), que proporciona el servidor de correo
electronico del proveedor del servicio (Internet Service Provider o ISP), cuyo analisis
permitira estudiar la coherencia de los datos aportados respecto a aspectos tan rel-
evantes como fecha y hora de acceso a la cuenta de correo, envıo y recepcion de
mensajes, entre otros. Una vez aseguradas dichas fuentes, se inicia la cadena de
custodia que permitira garantizar la veracidad de las conclusiones alcanzadas tras el
analisis que se pretenda realizar.
Un correo electronico dispone de diversos campos con informacion, algunos de
ellos estan estandarizados y otros los anade el programa que gestiona el correo
electronico. A continuacion se puede ver un ejemplo de cabecera de correo electronico,
para una lectura mas comoda se han eliminado y reducido campos que no tienen valor
para la adveracion del correo. 2
2Los valores que aparecen en el siguiente ejemplo han sido inventados a modo de ejemplo.
99
Delivered-To: direccion1@empresa1.com
Received: by 10.194.33.39 with SMTP id o7cspi;
Tue, 15 Nov 2011 07:19:07 -0700 (PDT)
X-Received: by 10.202.242.137 with SMTP id q131m;
Tue, 15 Nov 2011 07:19:07 -0700 (PDT)
Return-Path: <direccion2@empresa2.com>
Received: from EUR01-HE1-obe.outbound.protection.outlook.com
(mail-he1eur01on0065.outbound.protection.outlook.com. [104.47.0.65])
by mx.google.com with ESMTPS id z194 for <direccion1@empresa1.com>
Tue, 15 Nov 2011 07:19:07 -0700 (PDT)
Received-SPF: pass (google.com: domain of direccion2@empresa2.com designates
104.47.0.65 as permitted sender) client-ip=104.47.0.65;
Received: from AM2PR07MB0865.eurprd07.prod.outlook.com (10.161.71.151) by
AM2PR07MB0867.eurprd07.prod.outlook.com (10.161.71.153) with Microsoft SMTP
Server (TLS) id 15.1.501.7; Tue, 15 Nov 2011 14:19:04 +0000
from AM2PR07MB0865.eurprd07.prod.outlook.com ([10.161.71.151]) by
AM2PR07MB0865.eurprd07.prod.outlook.com ([10.161.71.151]) with mapi id
15.01.0506.013; Tue, 15 Nov 2011 14:19:04 +0000
From: "direccion2@empresa2.com" <direccion2@empresa2.com>
To: "direccion1@empresa1.com" <direccion1@empresa1.com>
Subject: Material
Thread-Topic: Material
Date: Tue, 15 Nov 2011 14:19:04 +0000
Message-ID: <AM2PR07MB0865B8865.euasdsd07.prod.outlook.com>
x-originating-ip: [212.145.159.148]
Content-Type: multipart/related;
boundary="_004_AM2PR07MB0865B8A0143AE65eurp_";
type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2011 14:19:04.2565(UTC)
Content-Type: multipart/alternative;
Content-Type: text/plain; charset="iso-8859-1"
Este es el cuerpo del correo electronico.
100
A continuacion se explican los campos mas destacados para la trazabilidad y au-
tenticidad del correo:
• Received: en las cabeceras de un correo electronico este campo suele aparecer
varias veces. Cada vez que el correo electronico pasa por un servidor se le
anade un campo Received. Ası, este campo adquiere un valor distinto para cada
uno de los servidores por los que haya pasado un correo electronico, empezando
por el mas cercano al origen de la comunicacion y hasta el de su destino. El
valor de este campo es el de la direccion IP que tengan los sucesivos servidores
intervinientes. En este campo se muestra la fecha y hora en la que el correo ha
pasado por cada servidor.
• x-originating-ip: de la cabecera anadida por el gestor de correo Microsoft Out-
look. El valor de este campo es la direccion IP desde la que se ha enviado el
correo electronico.
Por tanto, es imprescindible disponer de la informacion de estos campos cuando
se realiza cualquier tipo de consideracion acerca de un correo electronico y mas aun
cuando sea necesario realizar un analisis para, entre otras valoraciones, poder pro-
nunciarse acerca de la localizacion desde la que el correo fue enviado o sobre la posi-
bilidad que la integridad del correo haya podido ser comprometida. La unica forma de
poder disponer de esta informacion y realizar dichas consideraciones es preservando
el correo electronico en formato digital, lo cual se consigue mediante el proceso de
aseguramiento del mismo como fuente de informacion que es, tal y como se ha co-
mentado en el presente apartado.
101
top related