Yvvvzu 1579025421

Instituto Tecnológico y de Estudios Superiores de Monterrey
Campus Monterrey
Atizapán de Zaragoza , Estado de México a 4 de Septiembre de 2006.
Lic. Arturo Azuara Flores:

Director de Asesoría Legal del Sistema
Por medio de la presente hago constar que soy autor y titular de la obra titulada
"Metodología para la recolección de datos volátiles aplicados a un proceso de
investigación forense", en los sucesivo LA OBRA, en virtud de lo cual autorizo a
el Instituto Tecnológico y de Estudios Superiores de Monterrey (EL INSTITUTO)
para que efectúe la divulgación, publicación, comunicación pública, distribución y
reproducción, así como la digitalización de la misma, con fines académicos o
propios al objeto de EL INSTITUTO.
El Instituto se compromete a respetar en todo momento mi autoría y a otorgarme
el crédito correspondiente en todas las actividades mencionadas anteriormente
de la obra.
De la misma manera, desligo de toda responsabilidad a EL INSTITUTO por
cualquier violación a los derechos de autor y propiedad intelectual que cometa el
suscrito frente a terceros.
Rosa Alicia Torres García

AUTORA
Metodología para la Recolección de Datos Volátiles Aplicados a
un Proceso de Investigación Forense-Edición Única
Title Metodología para la Recolección de Datos Volátiles

Aplicados a un Proceso de Investigación Forense-Edición
Única
Authors Rosa Alicia Torres García
Affiliation ITESM-Campus Estado de México
Issue Date 2006-04-01
Item type Tesis
Rights Open Access
Downloaded 19-Jan-2017 10:39:19
Link to item http://hdl.handle.net/11285/567549

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY
CAMPUS ESTADO DE MÉXICO
METODOLOGÍA PARA LA RECOLECCIÓN DE DATOS

VOLÁTILES APLICADOS A UN PROCESO DE
INVESTIGACIÓN FORENSE
TESIS QUE PARA OPTAR EL GRADO DE

MAESTRO EN CIENCIAS COMPUTACIONALES
PRESENTA
ROSA ALICIA TORRES GARCÍA
Asesor: Dr. ROBERTO GÓMEZ CÁRDENAS
Comité de tesis: Dr. JOSÉ DE JESÚS VÁZQUEZ GÓMEZ

Dr. EDUARDO GARCÍA GARCÍA
Dr. ROBERTO GÓMEZ CÁRDENAS
Jurado: Dr. JOSÉ DE JESÚS VÁZQUEZ GÓMEZ Presidente

Dr. EDUARDO GARCÍA GARCÍA Secretario
Dr. ROBERTO GÓMEZ CÁRDENAS Vocal
Atizapán de Zaragoza, Edo. Méx., Abril de 2006.

2
CONTENIDO
RESUMEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
LISTA DE FIGURAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
LISTA DE TABLAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. LA INVESTIGACIÓN FORENSE EN CÓMPUTO. . . . . . . . . . . . . . . . . . . . . . 9
1.1 Respuesta a Incidentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.1 Procedimientos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.1.1 Respuesta inicial del administrador del sistema. . . . . . . . . . . . . . . . 12
1.1.1.2 Protegiendo la integridad de la evidencia. . . . . . . . . . . . . . . . . . . . . 12
1.1.1.3 Procedimientos de shut-down. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.1.4 Cadena de custodia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Metodología en una Respuesta a Incidentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Investigación Forense en cómputo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.1 Pasos del proceso forense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.1.1 Paso 1: Identificar y recolectar evidencia . . . . . . . . . . . . . . . . . . . . . 19
1.3.1.2 Paso 2: Preservar la evidencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.1.3 Paso 3: Analizar la evidencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.1.4 Paso 4: Presentar la evidencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 Estándares internacionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5 México y los delitos informáticos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2. RECOLECCIÓN DE EVIDENCIA Y VOLATILIDAD DE LOS DATOS. . . . 24
2.1 Recolección de evidencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1 Donde y como archivar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.2 Herramientas útiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3
2.2 Volatilidad de los datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3 Problemática de la recolección de datos en una investigación forense. . . . . . . . 31
2.4 Propuestas de solución. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3. HERRAMIENTAS PARA LA RECOLECCIÓN DE INFORMACIÓN DE
DATOS VOLÁTILES Y MEMORIA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1. SO WindowsNT y 2000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.1. Herramientas (toolkit) de captura con utilerías del SO para Windows. . 36
3.1.1.1. MS-DOS y comandos del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.1.2. Windows Resource Kit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1.1.3. Herramientas para Windows no propietarias: PsTools. . . . . . . . . . . 39
3.1.1.4. Herramientas varias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.1.5. Volcado de memoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.2. Herramientas forenses para Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.2.1. Software comercial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.2.2. Hardware forense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2. SO Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.1. Herramientas de captura con utilerías del SO Linux. . . . . . . . . . . . . . . . 48
3.2.1.1. Comandos del Sistema Operativo Linux. . . . . . . . . . . . . . . . . . . . . 49
3.2.1.2. Volcado de memoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2.2. Herramientas forenses para Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.2.1. TCT Coroner´s Toolkit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.2.2. Memdump. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.2.3. Sleuth Kit y Autopsy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.2.4. Live CD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.2.2.5. Herramientas varias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.3. Análisis comparativo de herramientas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4. METODOLOGÍA PARA LA RECOLECCIÓN DE INFORMACIÓN
Y CASOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.1 Estableciendo una metodología “general” para aplicar en cada caso. . . . . . . . . . 77
4.2 Aplicando el procedimiento de recolección: CASO 1 Windows local . . . . . . . . 81
4.3 Aplicando el procedimiento de recolección: CASO 2 Windows por red. . . . . . . 96
4.4 Aplicando el procedimiento de recolección: CASO 3 Linux local. . . . . . . . . . . 114
4.5 Aplicando el procedimiento de recolección: CASO 4 Linux por red. . . . . . . . . . 126
4
4.6 Aplicando el procedimiento de recolección: CASO 5 Grave Robber Linux. . . . 137

5. RECUPERACIÓN DE INFORMACIÓN EN MEMORIA RAM A
TRAVÉS DE PROCEDIMIENTOS FÍSICOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.1 Introducción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.2 Defectos físicos en los dispositivos de memoria. . . . . . . . . . . . . . . . . . . . . . . . . 144
5.3 Recuperación de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
5.4 Ejemplos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
5.4.1 Ejemplo 1: Retención de datos en base a la temperatura . . . . . . . . . . . . . 148
5.4.2 Ejemplo 2: Recuperación de datos en base al stress generado en los
transistores de una celda SRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.4.3 Ejemplo 3: Recuperación de datos en base al stress del óxido dieléctrico
del capacitor en una celda DRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.4.4 Ejemplo 4: Recuperación de datos utilizando técnicas “Burn in” e “Iddq”
en SRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.4.5 Ejemplo 5: Recuperación de datos en base a la alteración del estado
preferente de encendido en una celda DRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.4.6 Ejemplo 6: Recuperación de datos en Smart Cards en base a análisis
de parámetros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.4.7 Ejemplo 7: Recuperación de datos en smartcards utilizando un método
invasivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
5.4.8 Ejemplo 8: Lectura óptica de una SRAM CMOS. . . . . . . . . . . . . . . . . . . 155
5.4.9 Ejemplo 9: Prueba electromagnética en smartcards. . . . . . . . . . . . . . . . . . 156
CONCLUSIONES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
REFERENCIAS BIBLIOGRÁFICAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
ANEXO A. ARTICULO 211 bis CODIGO PENAL FEDERAL. . . . . . . . . . . . . . . . 166
ANEXO B. MICROPRUEBAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
ANEXO C. GLOSARIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
5
RESUMEN
En un incidente de seguridad, donde se ha realizado una intrusión no permitida a un equipo de

cómputo y se requiere buscar la causa y/o al culpable para que se haga justicia sobre los daños
que fueron hechos, se utilizan los conocimientos y experiencia de los investigadores forenses en
cómputo.
Uno de los primeros pasos que realiza el forense en una investigación, es congelar la escena del
crimen con el fin de adquirir la información que pueda llevarlo a encontrar las claves necesarias
para identificar las causas del incidente. En los crímenes digitales la captura de información se
convierte en un paso importante durante la investigación, ya que si no se siguen los pasos
adecuados es fácil perder la información volátil del sistema.
Cuando un investigador llega a la escena del crimen puede encontrar el sistema “vivo” (corriendo
sus procesos en forma “normal”) o el sistema “muerto” (apagado). En el caso de un sistema vivo,
es difícil congelar la escena del crimen, ya que la evidencia es sensitiva al tiempo y además de
frágil, puede ser fácilmente alterada, dañada o destruida, además al realizar la captura de
información volátil y de memoria es fácil cometer errores que traigan consecuencias graves ya
que si se desconecta el equipo antes de capturarla, se puede destruir la poca evidencia existente.
En el caso de encontrar el sistema muerto, podemos decir que la información volátil se ha
perdido. Es por eso que la captura de información volátil de un equipo de cómputo se vuelve un
problema en el proceso de recolección de información en una investigación forense. Otro
problema que se presenta a la hora de recolectar información es el conjunto de herramientas que
se utilizará para obtener la información. El investigador forense tiene que saber el uso de las
6
herramientas que están a su alcance, ya que el orden en que se pueden o deben usar depende de
los efectos que tienen.
Para afrontar este problema en este trabajo de investigación se propone una metodología de
recolección de datos volátiles y de memoria con el fin de asistir al investigador en el proceso de
captura, la metodología consiste en siete pasos que se realizarán en base a la volatilidad de la
información de un sistema de cómputo. Para comprobar su utilidad la metodología se aplicará a
cinco casos con dos sistemas operativos diferentes, donde se accederá en forma local y remota y
se utilizará un conjunto de herramientas en base al análisis de las utilerías existentes para las
versiones de los sistemas operativos planteados en esta investigación.
Dentro del alcance de este trabajo no se plantea una metodología para la recuperación de
información sobre un sistema muerto, ya que lleva un proceso y herramientas muy diferentes a un
sistema vivo, para este caso se exponen varios ejemplos realizados por Universidades dedicadas a
semiconductores y seguridad que muestran que todavía es posible obtener algo de información de
la memoria RAM aunque el equipo esté desconectado de energía.
El presente trabajo se encuentra organizado de la siguiente forma: en el primer capítulo se

introduce al lector a la investigación forense, sus pasos y la respuesta a incidentes; en el segundo
capítulo se plantea la problemática de recolección de información con respecto a la volatilidad de
los datos; en el tercer capítulo se muestran las herramientas útiles para crear el conjunto de
herramientas que permitirán al investigador realizar la recolección de datos volátiles; en el cuarto
capítulo se plantea la metodología a seguir para la recolección de información volátil,
aplicándose a cinco casos con diferentes sistemas operativos; finalmente en el quinto capítulo se
muestran ejemplos de recuperación de información utilizando métodos físicos. Al final del
documento se exponen las conclusiones del trabajo de investigación
7
LISTA DE FIGURAS
FIGURA 3.1 Autopsy inicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

FIGURA 3.2 Autopsy nuevo caso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
FIGURA 4.1 Casos a considerar para la presente investigación. . . . . . . . . . . . . . . . . . 76
FIGURA 4.2 Caso 1: Aplicación de la metodología con Windows en forma local. . . . 81
FIGURA 4.3 cmd.exe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
FIGURA 4.4 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
FIGURA 4.5 Caso 2: Aplicación de la metodología con Windows en forma remota. . . 96
FIGURA 4.6 Diagrama de conexión: Caso 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
FIGURA 4.7 Caso 3: Aplicación de metodología en Linux con acceso local. . . . . . . . 114
FIGURA 4.8 Caso 4: Aplicación de la metodología a través de la red con Linux. . . . . 126
FIGURA 4.9 Diagrama de conexión: Caso 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
FIGURA 4.10 Pantallas de “Ethereal”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
FIGURA 4.11 Caso 5: Herramienta forense “Grave robber”. . . . . . . . . . . . . . . . . . . . . 137
FIGURA 5.1 Recuperación de datos en un sistema “muerto”. . . . . . . . . . . . . . . . . . . . . 142
FIGURA 5.2 Transistor MOSFET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
FIGURA 5.3 Celda SRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
FIGURA 5.4 Mapa construido usando la corriente de eddy. . . . . . . . . . . . . . . . . . . . . . 157
8
LISTA DE TABLAS
TABLA 1.1 Metodología de un Respuesta a Incidentes . . . . . . . . . . . . . . . . . . . . . . . 15

TABLA 2.1 Fuentes del sistemas de datos su volatilidad y utilidad. . . . . . . . . . . . . . 29
TABLA 3.1 Comandos de sistema operativo Windows. . . . . . . . . . . . . . . . . . . . . . . . 36
TABLA 3.2 Herramientas de “Windows Resource Kit” libres. . . . . . . . . . . . . . . . . . 37
TABLA 3.3 Herramientas de “Windows Resource Kit” con costo. . . . . . . . . . . . . . . 38
TABLA 3.4 Suite “PsTools”. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
TABLA 3.5 Herramientas varias Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
TABLA 3.6 Software comercial para Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
TABLA 3.7 Hardware forense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
TABLA 3.8 Comandos del sistema operativo Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . 49
TABLA 3.9 Archivos y programas del sistema operativo Linux. . . . . . . . . . . . . . . . . 51
TABLA 3.10 Archivos y directorios de “Grave Robber”. . . . . . . . . . . . . . . . . . . . . . . . 59
TABLA 3.11 Herramientas de seguridad y Forensia para Linux. . . . . . . . . . . . . . . . . . 69
TABLA 3.12 Herramientas varias Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
TABLA 4.1 Pasos y acciones realizadas: Caso 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
TABLA 4.2 Documentando: Caso 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
TABLA 4.6 Documentando: Caso 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
9
CAPITULO 1
LA INVESTIGACIÓN FORENSE EN
CÓMPUTO
10
1. LA INVESTIGACIÓN FORENSE EN CÓMPUTO.
Las computadoras se han convertido en una parte esencial en nuestro trabajo, esto genera el
riesgo de tener violaciones no autorizadas a nuestro sistema (incidentes de seguridad) por el mal
manejo que podamos tener sobre éste. Los delitos informáticos se han vuelto cada día más
importantes debido a la utilización de los servicios que ofrece la red Internet, algunos crímenes
convencionales, especialmente los concernientes a comercio y finanzas, se hacen más
sofisticados tecnológicamente.
Para protegerse contra las amenazas constantes de hackers, crackers y código malicioso, las
organizaciones hacen uso de firewalls, software antivirus y sistemas de detección de intrusos.
Pero a pesar de estas medidas de defensa, computadoras y redes conectadas a Internet, aún siguen
siendo sujetas a ataques frecuentes.
Como resultado de estos hechos desafortunados, organizaciones y gobiernos alrededor del mundo
deben estar preparados para responder ante un incidente de seguridad [1].
11
1.1 RESPUESTA A INCIDENTES
En un incidente donde una brecha de seguridad se ha abierto o un acto criminal involucra a una
computadora, la respuesta inicial es muy importante, las primeras acciones tomadas durante la
atención al incidente puede hacer que se puedan encontrar las pruebas necesarias para detectar la
falla y/o al culpable del acto criminal.
En una respuesta a incidentes el equipo de emergencia hace la verificación del incidente,

recolecta evidencia, analiza la situación, reacciona ante un desastre y reporta acciones, el
investigador forense va un poco mas allá, recolecta y preserva evidencia de la intrusión, busca
pistas, analiza la situación, reporta hallazgos y determina propósitos y motivos.
En un incidente de seguridad es esencial que los pasos que se tomen aseguren la protección de los
datos en el medio de almacenamiento ya que estos datos son invaluables para determinar el nivel
de la brecha de seguridad y la localización de evidencia potencial acerca del acto criminal. El
éxito de la recuperación de datos y el enjuiciamiento dependerá de las acciones del individuo que
inicialmente descubrió el incidente computacional. En la mayoría de las situaciones, el equipo de
emergencia es solo el administrador del sistema. La mayoría de los administradores empiezan a
tomar acciones cuando ocurre un incidente sin darse cuenta del costo que éstas pueden implicar
sobre la evidencia. Es por esto que el proceso de Respuesta a Incidentes tendrá un impacto
significante en el análisis forense posterior.
Las organizaciones necesitan desarrollar un equipo especializado que tenga la capacidad de

responder a incidentes de seguridad, esto incluye personal con habilidades técnicas necesarias
que conozcan los procedimientos y políticas de seguridad.
Mientras la respuesta a incidentes varía dependiendo de las circunstancias, los objetivos

principales en todos los casos según Douglas Schweitzer [21] son:
• Recuperarse rápida y eficientemente del incidente de seguridad.

• Minimizar el impacto causado por la pérdida de datos o robo de información.
• Responder sistemáticamente siguiendo los procedimientos para evitar la recurrencia.
12
Las organizaciones deben desarrollar e implementar un plan de seguridad, llevarlo a cabo y

retroalimentarlo. Deben estar preparadas para actuar rápida y eficientemente para minimizar el
impacto de estos incidentes y establecer los procedimientos que se llevarán a cabo en una
respuesta a incidentes en forma clara y precisa [7].
1.1.1 PROCEDIMIENTOS
No existe un manual que indique paso a paso lo que debemos hacer ante cada uno de los
escenarios en incidentes de seguridad, por lo que podemos ayudarnos con los procedimientos que
algunas dependencias ya han establecido para tomar las medidas precautorias ante un incidente
como la guía de respuesta inicial del Laboratorio de Cómputo Forense del Departamento de
Energía de los E.U. [5] que expone los siguientes cuatro puntos:
1.1.1.1 Respuesta inicial del administrador del sistema
El rol del administrador del sistema es vital para asegurar todos los aspectos de la red, seguridad
y mantenimiento. Desde el punto de vista del forense la situación ideal es aislar el equipo de
cómputo, pero existen casos donde el equipo es un servidor en producción donde la pérdida de
evidencia es inminente.
1.1.1.2 Protegiendo la integridad de la evidencia
Es de gran importancia tener cuidado en preservar la evidencia en su estado original, el simple

hecho de abrir un archivo puede alterar la evidencia, esto en sentido legal puede ser inadmisible
como evidencia. La evidencia incluye también medios de almacenamiento, notas y bitácoras
escritas a mano y documentos del área donde la computadora ha sido involucrada.
1.1.1.3 Procedimientos shut-down
Una de las primeras acciones que se realizan puede estar entre: respaldar evidencia, encontrar
pistas, apagar o dejar arriba el sistema. Cualquier cosa que se haga o no se haga cambiará el
estado del sistema.
13
Cuando se da de baja limpiamente el sistema, se modifica la información del disco y la memoria,

esta es la opción menos viable cuando se desea obtener evidencia. Al apagar el sistema se pierde
información de todos los procesos en ejecución y memoria.
Otra opción es aislar el equipo bajo análisis de la red de trabajo, es decir desconectar de la red y
conectar el otro extremo a un concentrador que no esta conectado a ninguna otra parte, haciendo
suponer a la máquina que sigue conectada a la red y limitando la cantidad de cambios en el
sistema, esto porque la mayoría de los sistemas escriben mensajes de error en los archivos de
bitácora si no se encuentra la red.
Una de las decisiones más difíciles al tratar con un sistema sospechoso es la forma de apagar el
equipo sin corromper la integridad de los archivos. En muchos casos el tipo de sistema operativo
será la clave para tomar la decisión. En algunos sistemas jalar del cordón de poder es un método
para apagar el sistema, pero en otros casos esto puede causar la pérdida de archivos importantes,
o procesos e información en memoria o que el disco duro se dañe. En el caso de los equipos con
Windows se recomienda desconectar el equipo, en el caso de los equipos con Unix se puede
utilizar el comando halt, en sistemas MAC se puede realizar un shutdown especial o quitar el
cordón de corriente.
1.1.1.4 Cadena de custodia
El investigador debe asegurar y administrar eficientemente la evidencia. Una vez que la evidencia
ha sido obtenida se debe tener cuidado de mantener una custodia sobre ésta, en caso de no tenerla
se puede causar un daño grave en la investigación. Por lo que es importante realizar notas de
quién, qué y cuándo se hizo la transferencia de evidencia y mantenerla en un lugar seguro. El
análisis se debe realizar sobre copias en vez de la evidencia original y utilizar firmas digitales
para proveer integridad al contenido original [3].
14
1.2 METODOLOGÍA EN UNA RESPUESTA A INCIDENTES
Los criminales emplean la tecnología como depósito para ocultar evidencia incriminatoria o
materiales de contrabando. Los oficiales de policía deben tener conocimiento y equipo
actualizado para investigar eficientemente la actividad criminal de hoy en día. El reto de la
comunidad policíaca es identificar, investigar e iniciar el procedimiento penal contra las personas
físicas y las organizaciones que usan éstas y otras tecnologías emergentes como medio para sus
operaciones ilícitas. Esto es lo que sucede durante un caso normal:
1.- La víctima notifica que un crimen ha ocurrido.

2.- La policía obtiene evidencia y detecta sospechosos.
3.- Entrevistas y/o interrogaciones pueden ser conducidas.
4.- Al sospechoso son aplicados los cargos.
5.- El caso es llevado a juicio para presentación ante el jurado.
Con el crecimiento del crimen electrónico, una serie de prácticas, procedimientos, procesos de
decisión, referencias, etc. han sido preparados por grupos de trabajo técnico y expertos en
crímenes electrónicos para asistir a las agencias policíacas. La serie de guías direccionarán el
proceso desde la respuesta inicial en la escena del crimen, el laboratorio y ante la corte.
Los departamentos deben contar con herramientas para procesar la escena del crimen. Los
siguientes dispositivos pueden ser útiles en la escena del crimen:
Herramientas de documentación:
Etiquetas de cables
Marcadores indelebles
Herramientas de desensamble y retiro
Desarmadores
Pinzas
Tijeras
Empaquetar y transportar
Bolsas antiestáticas
15
Cables de amarre
Evitar los materiales que puedan producir electricidad estática
Otros dispositivos
Guantes
Lentes de aumento
Maleta de mano
Lámpara
Los siguientes pasos son realizados en una respuesta a un incidente de seguridad:
Tabla 1.1 Pasos de un Respuesta a Incidentes
Preparación
Detección del incidente
Respuesta inicial
Identificar y recolectar evidencia
Proceso forense Preservar la evidencia
Analizar la evidencia
Presentar la evidencia
Recuperación
Implementación de
mecanismo de seguridad
Documentación
La preparación cubre todo lo que se necesita hacer antes de que el incidente tome lugar, como
preparar las herramientas de respuesta y forenses, aprender los ambientes, configurar los sistemas
para una respuesta óptima y monitoreo, asignar responsabilidades, formar equipos de trabajo
establecer procedimientos de escalación, etc.
Después de que se ha reportado e identificado el incidente, la respuesta inicial debe tomar los
pasos para asegurar la escena del crimen protegiéndo la integridad de la evidencia, tanto
tradicional como electrónica de todo el personal con acceso a la escena del crimen.
16
Después de asegurar la escena del crimen, la repuesta inicial debe identificar la evidencia
potencial, tanto la electrónica como la convencional. La respuesta inicial debe evaluar la escena
del crimen y formular el siguiente plan. Como actividades se deberá restringir inmediatamente el
acceso a la(s) computadora(s), obtener posibles huellas dactilares, identificar líneas telefónicas
atadas a dispositivos como modems e identificadores de llamadas, documentar, desconectar y
etiquetar cada línea telefónica, etc.
Para determinar el papel de las computadoras dentro del crimen, se pueden contestar las
siguientes preguntas:
• ¿La computadora es contrabando o fruto de un crimen?

o Por ejemplo, ¿el hardware o software de la computadora es robado?
• ¿El sistema computacional es una herramienta para el delito?
o Por ejemplo, ¿se utilizó el sistema en forma activa por el acusado para cometer el delito?
¿se prepararon identificaciones falsas u otros documentos falsificados usando la
computadora, un escáner y una impresora a color?
• ¿El sistema computacional es sólo incidental al delito?, es decir ¿se utilizó para almacenar
evidencia del delito?
o Por ejemplo, ¿el traficante de drogas mantiene sus registros de tráfico en su computadora?
• ¿El sistema computacional es tanto instrumental del delito como un dispositivo de
almacenamiento de la evidencia?
o Por ejemplo, ¿el “pirata” computacional utilizó su computadora para atacar otros sistemas
y también la usó para almacenar información robada de tarjetas de crédito?
Una vez que se conoce el papel de la computadora y que han sido satisfechos los requisitos
legales, se pueden seguir las siguientes recomendaciones:
• No encender la computadora si está apagada

• Si la computadora está encendida
o Consulte al especialista en computadoras
• Si el especialista no está disponible
17
o Tome fotografías del monitor. Desconecte todas las fuentes de energía; desconecte de
la pared y de la parte trasera de la computadora.
o Coloque cinta para proteger evidencia sobre cada entrada a las unidades de disco.
o Tome fotografías/haga un diagrama y coloque etiquetas en la parte de atrás de los
componentes de la computadora y las conexiones existentes.
o Coloque etiquetas a todos los conectores/terminales de cable para permitir el
reensamble, de ser necesario.
o Si se requiere transportación, empaque los componentes y transporte/almacene los
componentes como carga frágil.
o Manténgase alejado de los imanes, transmisores de radio y otros ambientes hostiles.
• Jalar el enchufe podría:
o Dañar en forma importante el sistema
o Interrumpir negocios legítimos
o Originar una responsabilidad para el oficial y el departamento
La evidencia computacional, como toda la evidencia, debe ser manejada cuidadosamente y de

manera que preserve su valor, esto se relaciona no solo con la integridad física, también con los
datos electrónicos que contiene. Las computadoras son instrumentos electrónicos frágiles que son
sensitivos a la temperatura, humedad, golpes físicos, electricidad estática y fuentes magnéticas,
por lo que precauciones especiales se deberán de tomar para empacar y transportar la evidencia
electrónica y mantener la cadena de custodia. Entre los procedimientos de empaque se debe:
• Asegurar que toda la evidencia esta etiquetada e inventariada.

• Utilizar empaques antiestáticos (bolsas de papel o de plástico antiestáticos)
• Evitar almacenar la evidencia electrónica en vehículos por periodos de tiempo
prolongados.
• Proteger de fuentes magnéticas, polvo y partículas contaminantes.
Una vez que se ha obtenido y analizado la evidencia necesaria, se reestablecerá el sistema,

configurando y tomando acciones que prevengan la recurrencia y regrese el sistema a su uso
regular. Documentar el caso resume la lección aprendida y sirve de conocimiento para incidentes
futuros similares. [2,36,44,45]
18
1.3 INVESTIGACIÓN FORENSE EN CÓMPUTO.
El análisis forense digital se está convirtiendo rápidamente en parte integral de una respuesta a
incidentes, incrementándose el número de investigadores forenses y herramientas (toolkits)
disponibles.
En el libro “Techniques of Crime Scene Investigation” escrito por Barry A.J. Fisher [3] se dice
que Forencia es “ciencia y tecnología aplicada a la solución de actos criminales que permite
asistir investigaciones policíacas” y que el Cómputo forense es la “ciencia de adquirir, recuperar,
preservar y presentar datos que han sido procesados electrónicamente y almacenados en un medio
computacional”.
El cómputo forense asegura la preservación y autenticación de los datos computacionales, que

son frágiles por naturaleza y pueden ser fácilmente alterados o borrados si no son manejados
apropiadamente. Adicionalmente, el cómputo forense facilita la recuperación y análisis de
archivos borrados o que no son normalmente visibles al usuario. El análisis forense en cómputo
requiere de la interpretación de expertos más que producir conclusiones, como sucede en el
análisis forense tradicional.
El trabajo de un investigador forense es obtener la mayor información de las fuentes de evidencia

(discos, controladores, archivos de bitácoras, cajas de medios removibles, etc.) tomando en
cuenta dos puntos principales [3]:
• Estar seguro de preservar los datos en su forma original.

• Reconstruir el evento que ocurrió durante un acto criminal.
Cuando se empieza la investigación de un incidente, primero es necesario determinar si en

realidad ha ocurrido un incidente de seguridad, a simple vista quizá no veríamos nada
(especialmente si un “rootkit” está instalado) o podríamos encontrar una saturación de red
originada por un simple “host” (rastreando su dirección ethernet o cuentas de paquetes en un
puerto de un switch) o un programa que se está consumiendo el 100% del CPU sin que el sistema
de archivos muestre algo relacionado con ese programa, cuando esto sucede se verifica que
19
realmente exista un problema de seguridad, muchas veces se trata sólo de un problema de

administración que no necesariamente pone en duda el sistema. Los pasos tomados en cada uno
de estos ejemplos puede ser completamente diferentes entre cada uno, un investigador utilizará la
experiencia e intuición acerca de que y como buscar, cuidando de recordar los pasos realizados
para preservar y recolectar evidencia en forma metódica. Las piezas de datos (evidencia) en el
sistema, exponen la historia de cómo ocurrió el suceso [21,7,3].
La investigación forense sigue métodos científicos, estas acciones metódicas ayudan a obtener y
analizar la evidencia. Grant Gottfried [1] define evidencia digital como “la información
almacenada o transmitida en forma binaria que pueda se útil en una corte de justicia”.
1.3.1 PASOS DEL PROCESO FORENSE
No hay duda de que una metodología o proceso es llevada a cabo en un fraude computacional,
por lo que tampoco hay duda de que en una investigación forense debemos contar también con un
proceso, además un proceso formal permite al investigador enfocar e investigar un crimen
racional y rápidamente. También es importante establecer un protocolo por el cual la evidencia
electrónica es obtenida y manejada, para reducir el riego de ser corrompida. Sin una metodología
o proceso bien definido será más difícil investigar exitosamente y por lo tanto controlar un abuso
o fraude computacional. Es requisito que en un proceso de investigación forense se exhiban las
características de una metodología científica. Por ejemplo un proceso válido debe consistir en
pasos bien definidos que puedan ser repetidos en toda la investigación, cada paso debe ser
consistente [8].
A continuación se exponen los cuatro pasos del proceso forense[4]:
1.3.1.1 PASO 1 Identificar y recolectar evidencia
Identificar la información que se encuentre disponible y determinar la mejor manera de

recolectarla. Este punto se profundizará en el siguiente capítulo.
20
1.3.1.2 PASO 2 Preservar evidencia
Una vez que se ha identificado y recolectado la evidencia es muy importante preservarla con la
menor cantidad de cambios, pero en el caso de realizar cambios se debe demostrar la
responsabilidad que se tenga sobre la evidencia.
La evidencia debe ser estrictamente asegurada y la cadena de custodia necesita ser claramente
documentada, la evidencia debe ser capaz de describir claramente como fue encontrada, como fue
manejada y todo lo que le ha sucedido (cadena de custodia).
Lo que debe ser documentado:

• Dónde, cuándo y por quién fue descubierta y obtenida la evidencia.
• Dónde, cuándo y por quién fue manejada y examinada la evidencia.
• Quién ha custodiado la evidencia, durante qué periodo y cómo fue almacenada.
• Cuándo la evidencia cambia de custodia, y cómo se hace la transferencia.
El acceso a la evidencia debe ser restrictivo y documentado para que se pueda detectar un acceso
no autorizado. Una vez capturada la información debe ser almacenada en medios de solo lectura
y marcar registros que conserven la integridad de la información para que no pueda ser alterada.
1.3.1.3 PASO 3 Analizar la evidencia
Para interpretar la evidencia se requiere de conocimiento profundo para entender como embonan
las piezas. Podemos comenzar por identificar qué cambió en el sistema cómo y cuándo, si es
posible obtener los comandos usados y cuando se usaron, rootkits instalados e información
oculta.
Se deben analizar solo copias (imágenes) de la evidencia, manteniendo la integridad original y

una cadena de custodia estricta. La integridad del sistema se debe verificar antes y después del
análisis.
21
1.3.1.4 PASO 4 Presentar la evidencia
Este paso se enfoca en la forma de presentar la evidencia ante una corte. La credibilidad de los
procesos usados para preservar y analizar la evidencia.
La evidencia computacional necesita ser:
Admisible: Debe conformar ciertas reglas legales antes de que pueda ponerse ante una corte
Auténtica: Debe ser posible atar material evidencial al incidente
Completa: Debe decir toda la historia y no solo una perspectiva particular.
Confiable: No debe haber duda sobre la autenticidad y veracidad de la evidencia ni de cómo
se recolectó.
Creíble: Debe haber credibilidad en la investigación y ser entendible para la corte.
1.4 ESTÁNDARES INTERNACIONALES
El grupo G8 de naciones más industrializadas ha propuesto 6 principios relacionados con

evidencia digital para asegurar una buena aplicación de los métodos y prácticas entre las naciones
y garantizar la habilidad de usar evidencia digital recolectada por un estado en la corte de otro
estado [9]:
1. Cuando se trata con evidencia digital, todos los principios forenses generales y
procedimientos deben ser aplicados.
2. Una vez obtenida la evidencia digital, las acciones que se tomen no deben cambiar la
evidencia.
3. Cuando sea necesario que una persona acceda a la evidencia digital, será necesario que
esté entrenada para ese propósito
4. Todas las actividades del embargo, acceso, almacenamiento o transferencia de evidencia
digital deben ser completamente documentadas, preservadas y disponibles para revisión.
5. Las personas que custodian la evidencia son responsables por todas las acciones tomadas
con respecto a la evidencia digital mientras ésta esté en su poder.
6. La agencia que sea responsable por el embargo, acceso, almacenamiento o transferencia
de la evidencia digital es responsable de cumplir estos principios.
22
Todas las políticas y procedimientos de cómputo forense deben ser desarrollados bajo estos
principios. No limitándose a sólo computadoras en el sentido tradicional, el campo abarca todo,
PDAs, ruteadores, etc. cubriendo crímenes que alcancen desde crear, poseer y diseminar
pornografía infantil hasta intrusiones de red.
Estos principios son un inicio para tratar de estandarizar pero mucho depende de las leyes locales
del estado o país.
1.5 MÉXICO Y LOS DELITOS INFORMÁTICOS
Existen varios estándares y procedimientos que se han creado en combate a los delitos
informáticos. A nivel internacional en países a la vanguardia sobre el tema, se han clasificado los
delitos en diferentes tipos tales como: el espionaje electrónico, la estafa electrónica, el sabotaje
electrónico, la falsificación informática, el plagio de dominios, el plagio de nombres comerciales
o marcas de Internet, el mercadeo de souvenirs que aludan fines xenofóbicos, la apología del
delito, la responsabilidad penal en que pueden incurrir los representantes legales de las empresas
que se dedican a ofrecer hospedaje virtual de anunciantes cuando la información sea considerada
como contraria a la ley o incite a la comisión de un delito, entre otros.
En México, el 17 de mayo del 2000 se publicaron varias reformas en el Diario Oficial de la

federación para la creación de los artículos 211 bis 1 al 7 de l código Penal Federal que se
muestran en el anexo A.
A pesar de los esfuerzos que se han realizado para proponer nuevas normas enfocadas a los
delitos informáticos, que puedan motivar la labor de los cuerpos especializados de investigación
criminal, como la Unidad de Policía Cibernética dependiente de la Policía Federal Preventiva, la
falta de normas legales limita su labor, ya que no cuentan con las disposiciones penales que
sirvan de apoyo para sancionar los delitos informáticos y por tanto, estos permanezcan impunes.
Sánchez Franco [42] expone que deben existir las herramientas legales adecuadas para que la parte
ofendida denuncie y acredite con pruebas los delitos ante la autoridad competente, ya que en caso
23
de no existir como hasta ahora, se favorece la labor de los abogados defensores y se favorece la
impunidad.
Es insuficiente la reforma penal de mayo del 2000, es necesario retomar conciencia sobre el tema
y apoyarse en los modelos avanzados que ya están estableciendo, regulando y sancionando este
tipo de ilícitos.
24
CAPITULO 2
RECOLECCIÓN DE EVIDENCIA Y
VOLATILIDAD DE LOS DATOS
25
2. RECOLECCIÓN DE EVIDENCIA
El cómputo forense envuelve la preservación, identificación, extracción, documentación e

interpretación de datos computacionales. Según Stephen Barish en su artículo “Un Caso de
Estudio”[22] “El cómputo forense es más un arte que una ciencia”, pero como es una disciplina
obliga a los especialista forenses a seguir en forma clara y bien definida metodologías y
procedimientos pero al mismo tiempo permite ser flexible al encontrar algo inusual.
Investigar la violación de un equipo de cómputo es como investigar la escena de un crimen, los

detectives recolectan evidencia, buscan claves que puedan ser útiles y toman un inventario de los
daños y pérdidas.
2.1 RECOLECCIÓN DE EVIDENCIA
El primer paso que debe seguir un investigador en un incidente de seguridad es la recolección de

evidencia. Según Timothy E. Write [8] el proceso de búsqueda de evidencia pasa por varios
estados:
1º. Se deberá formular un plan donde el investigador determinará la evidencia que será
buscada y decidirá el procedimiento de búsqueda
2º. El investigador llegará a la escena del crimen y asegurará la evidencia de personas no
autorizadas.
26
3º. El investigador tomará notas cuidadosamente de todos los dispositivos relevantes y la

evidencia encontrada.
4º. El investigador seleccionará, empaquetará y moverá evidencia
5º. Analizará la evidencia en un laboratorio cuidando de no modificarla.
Como se especifica en el RFC 3227, si la recolección de evidencia es hecha en forma correcta,

existe mayor oportunidad de que esta información sea útil en un juicio, facilitando el arresto de
un atacante.
Las principales recomendaciones especificadas en el RFC indican que:
• Los procedimientos de recolección deberán ser incluidos en las políticas de seguridad del
área de cómputo e involucrar al personal de incidentes de seguridad.
• Obtener como sea posible una fotografía exacta del sistema.
• Realizar notas detalladas.
• Anotar la diferencia entre el reloj del sistema y la UTC.
• Estar preparado para testificar todas las acciones que se realizaron y la hora.
• Minimizar cambios en los datos como se van recolectando.
• Cuando se enfrente con una elección entre recolección y análisis, se debe recolectar antes
de analizar.
• Ser metódico.
• La velocidad debe ser crítica, por lo que para un número de dispositivos que se requiere
examinar, será apropiado repartir el trabajo entre más personas para recolectar en forma
paralela.
• Proceder desde lo volátil a lo menos volátil.
• Hacer una copia a nivel de bit del sistema.
Dentro de las cosas que se deben evitar para no destruir evidencia el RFC recomienda:
• No dar de baja el sistema hasta que se ha completado la recolección. La evidencia puede

ser perdida y el atacante puede haber alterado el proceso de shutdown o los archivos
scripts de servicios para destruir esa información.
27
• No confiar en los programas del sistema. Correr los programas de recolección de

información en medios seguros y protegidos.
• No correr programas que modifiquen el tiempo de acceso de todos los archivos en el
sistema.
• Cuando se remueven dispositivos externos notar que la simple desconexión o filtro de la
red puede activar programas que detectan cuando se ha desconectado la red y borran
evidencia.
Los procedimientos de recolección deben ser detallados en lo posible, no deben ser ambiguos y
deben minimizar la cantidad de decisiones necesitadas durante el proceso de recolección. Los
métodos utilizados en la recolección de evidencia digital deben ser transparentes y reproducibles,
no olvidando documentar cada paso. Se debe estar preparado para reproducir precisamente el
método usado, además estos métodos deben ser probados por expertos independientes.
• La cadena de custodia necesita ser claramente documentada, debe describir como se

encontró la evidencia, como fue manejada y todo lo que sucedió.
• Debe documentarse dónde, cuándo y por quién fue descubierta y obtenida, aumentada y
examinada la evidencia.
• Quién la ha custodiado, durante qué periodo y cómo fue almacenada.
• Cuándo la evidencia cambia de custodia y cómo se hace la transferencia.
Los métodos usados para la recolección de evidencia deben ser transparentes y reproducibles [6].
2.1.1 DONDE Y COMO ARCHIVAR
En la medida de lo posible usar medios de almacenamiento de evidencia estándares. El acceso a

la evidencia debe ser restrictivo y documentado claramente, para detectar accesos no autorizados.
Una consideración importante a la hora de hacer las copias es esterilizar los dispositivos en los
que se guardará la copia. Para lo cual se puede esterilizar un dispositivo sobrescribiendo el medio
con ceros.
28
2.1.2 HERRAMIENTAS ÚTILES
Se debe contar con programas de recolección de evidencia en medios de solo lectura (ejemplo:
CD). Contar con un conjunto de herramientas por cada sistema operativo, que contenga
programas para examinar procesos, para hacer copias bit a bit, para generar marcas de tiempo
(checksums) y firmas, etc.
Los programas en el conjunto de herramientas deben ser ligados estáticamente y no deben

requerir el uso de librerías. Se debe estar preparado para testificar la autenticidad y confiabilidad
de las herramientas que se utilicen.
Uno de los problemas a los que se enfrenta el investigador es que los administradores algunas
veces rechazan la idea de dar de baja un sistema, especialmente cuando éste estará abajo por una
indeterminada cantidad de tiempo. Pero solo se puede bajar el nivel de rigor después de que se ha
determinado que el caso no será enjuiciado
2.2 VOLATILIDAD DE LOS DATOS
La evidencia puede ser encontrada en muchos dispositivos electrónicos, como teléfonos,

celulares, asistentes personales digitales (PDAs), cámaras digitales, componentes de red, pagers,
etc. En el caso de las computadoras se puede obtener información a través de los dispositivos de
almacenamiento de datos con los que cuenta, como los son el procesador, memoria, disco duro,
medios removibles (floppy disks, cintas, discos compactos, discos versátiles digitales (DVD)),
impresoras, etc.
El tiempo de vida de los datos digitales depende de donde se encuentren almacenados. Dan
Farmer y Wietse Venema establecieron el siguiente orden de volatilidad:
1 Procesador
2 Sistemas de almacenamiento
3 Tablas del kernel
4 Medios fijos
29
5 Medios removibles
6 Impresiones
Mientras mayor volatilidad de los datos es mayor la dificultad de capturarlos, y menor el tiempo
que tenemos para realizar un análisis. Por ejemplo en el caso del procesador es improbable que se
pueda utilizar el contenido de los registros, el simple acto de buscar en ellos puede modificarlos,
así es que, buscando sobre el contenido de la memoria del sistema y el estado de la red podemos
obtener claves valiosas, el tipo y la fuente de un ataque de entrada, etc. Examinar esta tipo de
estructuras requiere de cierta experiencia para analizar y capturar los datos en forma segura.
A continuación se muestra la tabla 2.1 que publica las diferentes fuentes de sistemas de datos su
volatilidad y su utilidad en la investigación [2].
Tabla 2.1 Fuentes de sistemas de datos su volatilidad y utilidad
Máximo Categoría Tipo de Significado para el investigador forense

tiempo de almacenamiento
vida de datos
Tan corto Procesador Registros Captura irrealizable y mínima utilidad
como un ciclo
de reloj Caches Captura irrealizable como una entidad discreta pero
puede obtenerse información a través de una
imagen de memoria del sistema.
Video RAM La pantalla actual puede ser capturada y provee

información útil si se sospecha que el intruso entró
al sistema mediante la consola o en una terminal X
Windows
Hasta que el Sistemas de RAM Incluye información sobre todos los procesos
host es dado almacenamiento corriendo y el estado del kernel. Fácil de capturar,
de baja pero el acto de capturarlos puede cambiarlos.
Requiere conocimiento especializado para
reconstruirlo completamente, pero no requiere
habilidades especiales para buscar estos datos por
palabras clave.
Tablas de Estado de red Puede ayudar a determinar si una puerta trasera

Kernel “backdoor” ha sido instalada y si está activa. Debe
ser analizado para determinar la actividad de red.
Procesos Algunos procesos pueden mostrar actividad no

corriendo autorizada. Todos los procesos deberán ser
verificados contra binarios seguros, verificando que
30
Máximo Categoría Tipo de Significado para el investigador forense

tiempo de almacenamiento
vida de datos
no sean caballos de Troya.
Hasta que Medios fijos Espacio swap Cuando las demandas del sistema exceden la
sean sobre- (Discos duros) capacidad de la RAM, algunos datos del kernel son
escritos o copiados al disco duro. Estos datos complementan
borrados los de la memoria RAM para el análisis de tiempos.
Directorios Incluye información sobre procesos corriendo y
Queue actividades incompletas. Se puede observar correo
saliente y trabajos de impresión que no existen en
otro lugar en el sistema
Directorios Son archivos de trabajo de todo el sistema. Se
Temp. espera que sea borrado periódicamente, por lo que
es un lugar apropiado para dejar datos que no serán
necesitados en el futuro. Se pueden encontrar datos
que fueron deliberadamente borrados sobre otras
partes del sistema
Directorios Esto es crucial para la reconstrucción de eventos.
Log La dificultad es que crecen demasiado, los logs son
mantenidos, viejos datos son eventualmente
borrados o sobre-escritos.
Directorios de Cada parte del sistema de archivos que no es
configuración, considerada temporal, como bitácoras que incluyen
usuario, binarios archivos que pueden permanecer indefinidamente.
y librerías. Sin embargo, cualquier usuario con acceso de
escritura podrá borrar o cambiar los datos.
Medios Discos floppy Uso menos frecuente en ambientes de red, pero
removibles puede contener archivos útiles. Discos de alta
capacidad que pueden ser usado para respaldos
Cintas Son una fuente confiable de información acerca del
contenido histórico del sistema. En caso de existir
cintas antes del incidente, pueden ser usadas para
determinar el periodo de tiempo durante el cual un
incidente ocurrió.
CD-ROM El estándar para CDs es ahora multisesion.
Read/write Debemos estar seguros de que examinar un CD
sospechoso puede mostrar todas las sesiones. Los
datos no pueden ser sobrescritos, pero cada sesión
crea una nueva tabla de directorio.
Hasta que CD-ROM Medio de escritura de una sola vez, es un lugar
sean Write/only excelente para almacenar archivos log porque ellos
físicamente no pueden ser alterados.
destruidos Salidas Impresiones en Es difícil hacer búsquedas en impresiones muy
papel largas, pero su periodo de destrucción es corto. Es
probablemente el mecanismo de almacenamiento
de mayor vida
Es imposible completar la captura de todo el estado de una computadora en un incidente. El

simple acto de examinar los datos volátiles provoca que el estado del sistema se modifique.
31
2.3 PROBLEMÁTICA DE RECOLECCIÓN DE DATOS EN UNA

INVESTIGACIÓN FORENSE
De acuerdo a lo que se ha expresado en las secciones anteriores podemos encontrar diversos

problemas a los que se puede enfrentar un investigador forense en la recolección de información.
Ante una respuesta a un incidente, el personal que atiende el incidente debe decidir si el equipo se
queda encendido o apagado. En caso de apagarlo también debe decidir si debe desconectarlo de
la energía o realizar un apagado (shutdown) normal.
Sea lo que decida el personal de respuesta a incidentes el investigador forense realizará la

recolección tal como encontró el equipo y deberá recolectar la información posible que le pueda
llevar a encontrar claves para resolver el caso al que se enfrente.
Por lo que podemos generalizar son dos situaciones a las que se enfrentará el investigador forense
para la recolección de información, cuando el equipo esta encendido y cuando el equipo está
apagado.
Se sabe que en algunas situaciones, especialmente en intrusiones de Internet, la evidencia puede

ser encontrada solamente en la memoria, pero debido a su alta volatilidad si se desconecta el
equipo antes de capturarla, se puede destruir la poca evidencia existente. Por lo que para
recolectar información volátil de un sistema utilizando las herramientas tradicionales de software
necesitamos tener el equipo encendido y corriendo sus procesos en forma normal.
Pero con el sistema corriendo es fácil cometer errores que traigan consecuencias graves, además
se viola uno de los principales principios de investigación forense que es no modificar la
evidencia, como por ejemplo en Linux, cada herramienta en el espacio de usuario o kernel
utilizada para capturar datos, por naturaleza cambia el estado del sistema. Correr herramientas en
un sistema vivo, hace que éstas se carguen en memoria y creen por lo menos un proceso que
puede sobrescribir evidencia. Creando un nuevo proceso, los sistemas de administración de
memoria del sistema operativo colocan datos en memoria principal y puede sobrescribir datos no
32
colocados en la memoria principal o en la memoria swap, que también es totalmente válido en los
ambientes Windows.
Otro problema se presenta cuando queremos tomar acciones legales y necesitamos cumplir con
las leyes locales. Las señales de intrusión encontradas en imágenes de memoria principal pueden
ser no confiables, porque son creadas con herramientas que adquirimos. Por lo que al tomar una
acción debemos decidir si o no, vamos a obtener datos volátiles de un sistema comprometido.
Pero algunas veces el procedimiento vivo describe la única forma de adquirir datos del incidente,
porque cierto código malicioso como algunos “rootkits” son cargados en memoria y no modifican
archivos o directorios.
2.4 PROPUESTAS DE SOLUCIÓN
Como ya hemos mencionado en la mayoría de los casos de atención de incidentes, se encuentra al

sistema en dos estados, se puede encontrar un sistema vivo (donde todavía se puede obtener
evidencia volátil) o se puede encontrar el sistema muerto (el investigador lo encuentra apagado).
El estado del sistema determinará cuales son las primeras acciones que se tomarán. En un sistema
vivo se tiene la opción de monitorear la red, se puede optar por dejar el sistema corriendo después
de recolectar la evidencia y/o instalar algún sniffer en el sistema (si es que lo permiten las
políticas).
En el caso de que el investigador se encuentre con un equipo encendido o “vivo”, lo importante

es actuar lo más rápido posible para capturar información, pero teniendo en cuenta que cada
acción que se tome durante la investigación, debe ser hecha de manera que pueda explicarse
fácilmente, ya que cada error en el sistema vivo puede traer consecuencias.
En el caso de que el investigador encuentre el equipo apagado o “muerto”, podemos pensar que
ya no es posible recuperar la información volátil del sistema, pero de acuerdo a la investigación
realizada en este proyecto, sí se puede recuperar algo de información de la memoria RAM
utilizando métodos físicos. Esto abre la posibilidad de que todavía podamos obtener claves para
una investigación forense aún si encontramos el equipo apagado.
33
No hay duda de que una metodología es llevada a cabo en un fraude computacional, por lo que
tampoco hay duda de que una investigación forense debe contar con una metodología también,
además una metodología formal permite al investigador enfocar e investigar un crimen en forma
racional y rápidamente. También es importante establecer un protocolo por el cual la evidencia
electrónica es obtenida y manejada para reducir el riego de ser corrompida. Sin una metodología
será más difícil investigar exitosamente y por lo tanto controlar un abuso o fraude computacional.
Es requisito que en un proceso de investigación forense se exhiban las características de una
metodología científica. Por ejemplo un proceso válido debe consistir en pasos bien definidos que
puedan ser repetidos en toda la investigación, cada paso debe ser consistente. Sin una
metodología formal comprobada la evidencia recopilada no será tomada seriamente en una corte.
En este trabajo se ha establecido una metodología general aplicada al estado “vivo” del sistema,
para que a partir de ésta se pueda llevar a cabo una recolección de información volátil útil en una
investigación forense, esta metodología será aplicada en cincos casos diferentes con el equipo
encendido y con sus procesos corriendo en forma “normal”, bajo los sistemas operativos más
comunes Linux con Red Hat Entreprise 3 y Windows 2000.
Como parte de la investigación también se mostrarán las herramientas útiles para llevar a cabo
cada procedimiento, dentro de las dos plataformas descritas, esto con el fin de que una vez que
conozcamos lo que existe en el mercado y lo que podemos utilizar del sistema operativo
tengamos la oportunidad de crear un conjunto de herramientas que nos va a ayudar a realizar la
recolección de información. Este paso de crear el conjunto de herramientas es tan importante
como el de la investigación misma, por lo que el siguiente capítulo mostrará estas herramientas,
así el investigador podrá decidir cuales son la que utilizará en su investigación.
Considerando también el problema al que se enfrenta el investigador forense en una situación

donde el estado del sistema esta “muerto”, en el último capítulo se expondrá una serie de
ejemplos experimentales llevados a cabo por Universidades con especialidades en
semiconductores y seguridad, que se basan en los defectos de los dispositivos semiconductores
para recuperación de información en las memorias, y así obtener información clave para una
investigación forense.
34
CAPITULO 3
HERRAMIENTAS PARA LA
RECOLECCIÓN DE INFORMACIÓN
DE DATOS VOLÁTILES Y MEMORIA
35
3. HERRAMIENTAS PARA LA RECOLECCIÓN DE

INFORMACIÓN DE DATOS VOLÁTILES Y MEMORIA.
Como hemos mencionado el conjunto de herramientas que utilizará el investigador forense o el

equipo de respuesta a incidentes para la captura de información volátil es tan importante como los
pasos del proceso forense.
Es importante conocer las herramientas que existen en el mercado y las que el sistema trae ya
integrado. La memoria RAM como dispositivo de alta volatilidad involucra que muchas veces el
investigador tenga que recolectar información con lo que tenga a primera mano, este es el caso
del sistema operativo. Con experiencia y el conocimiento propio, el sistema operativo puede ser
una excelente plataforma para realizar la recolección de evidencia.
Durante este capítulo se presentarán las principales herramientas de sistema para la recolección
de información volátil, programas para realizar imágenes de memoria, así como software forense
especializado que nos puede ser útil para conformar nuestro conjunto de herramientas de
recolección.
36
3.1 SO WINDOWS NT Y 2000
3.1.1 HERRAMIENTAS DE CAPTURA CON UTILERÍAS DEL SO PARA WINDOWS
Los comandos y utilerías para tareas administrativas del sistema pueden ser de gran utilidad ante
una respuesta inmediata. Esta es la razón por la que a continuación se exponen herramientas del
sistema operativo que no tiene el propósito específico de capturar información para un proceso de
investigación forense, pero se pueden utilizar para ese fin.
3.1.1.1 MS-DOS y comandos del sistema
La tabla 3.1 muestra los comandos útiles y su función en la recolección de datos. Todos estos
comandos van incorporados dentro del sistema operativo, por lo que no será necesario bajarlos de
Internet o comprarlos, a menos que no contemos con el sistema operativo.
Tabla 3.1 Comandos del sistema operativo Windows
Utilería Función
debug y dump Visualiza la memoria, carga porciones del disco en memoria y vuelve a
grabarlas, pero del subsistema de MSDOS únicamente.
mem Muestra qué y cuánta memoria se está utilizando, pero del subsistema
de MSDOS únicamente.
at.exe El comando AT programa la ejecución de comandos y programas en un
equipo a una hora y fecha especificadas. El servicio de programación
debe estar en ejecución para utilizar el comando AT.
cmd.exe Inicia una nueva instancia del intérprete de comandos de Windows XP
dir.exe Muestra la lista de subdirectorios y archivos de un directorio.
ipconfig.exe Muestra la dirección IP, máscara, subred, puerta de enlace. Puede

liberar o renovar las concesiones de dirección IP.
nbtstat.exe Muestra las estadísticas del protocolo y las conexiones actuales de
TCP/IP usando NBT (NetBIOS sobre TCP/IP).
net.exe Muestra información de cuentas, computadoras, estadísticas de red.
netstat.exe Muestra estadísticas del protocolo y conexiones TCP/IP actuales
nslookup.exe Muestra información acerca del nombre de host o de dominio
route.exe Manipula tablas de enrutamiento
tracert.exe Muestra la ruta para llegar a un host determinado, los saltos y el tiempo
37
Utilería Función
de espera
hostname Comando de sistema que despliega el nombre de la máquina
arp Despliega y modifica la tabla de direcciones IP a direcciones físicas,

utilizando el protocolo ARP
doskey Almacena el historial de comandos aplicados en la línea de comandos.
archivo .dmp Archivo donde se descarga la memoria RAM.
dumpchk.exe Comando que se utiliza para verificar que un archivo dump ha sido
creado correctamente, es localizado en el CD-ROM de Windows. Se
instala ejecutando setup.exe desde el directorio Support\Tools del CD
[25].
reg Estas herramientas permiten hacer una copia del registry. Reg permite
regedit agregar, cambiar, buscar, respaldar, restaurar y realizar operaciones
sobre el registry en una línea de comandos, puede ser usada en
computadoras locales y remotas.
3.1.1.2 Windows Resource Kits
El Resource Kit de Windows es un conjunto de herramientas, artículos y referencias que ayudan

al profesionista en Tecnologías de Información a dar soporte al sistema operativo. Contiene un
conjunto de herramientas que ayuda al administrador con tareas comunes y soporte a fallas en la
operación del sistema. Principalmente para la administración del “Active Directory” 1 ,
configuración de red, características de seguridad y desarrollo de aplicaciones [23].
El Resource Kit de Windows 2000 incluye muchas herramientas, pero solo algunas de ellas están
libres en Internet. Estos archivos son ejecutables autoextraibles que instalan la herramienta y su
documentación en la computadora, de entre ellas podemos utilizar y adquirir las publicadas en la
tabla 3.2.
Tabla 3.2 Herramientas de Windows Resource Kit libres
Utilería Función
dh.exe Es un comando en línea que despliega información acerca del uso de procesos en modo
usuario y modo kernel. Acepta switches para identificar el proceso desplegar y enviar a
un archivo de texto. Es muy útil para listar la basura de memoria y llamadas de
asignación de memoria. Despliega “memory hogs” (programas que utilizan mucha
memoria. Envía la información a un archivo de descarga (dmp). Nota: Se tienen que
1
El Directorio activo de Windows es un componente central de dicho sistema operativo que proporciona los medios para gestionar las identidades
y relaciones que organizan su entorno de red.
38
Utilería Función
configurar algunas variables globales en el sistema (gflags) y en el registry

drivers.exe Esta herramienta lista los drivers cargados en la máquina.
Nota: Se aplica solo localmente
pfmon.exe Este comando en línea permite al desarrollador o administrador de sistema monitorear
fallas de páginas (page faults) que se presentan cuando una aplicación está corriendo.
pstat.exe Es una herramienta que lista todos los hilos (threads) que están corriendo y despliega su
estado. Esta herramienta es similar a Qslice.exe, pero utiliza una línea de comandos en
vez de la interfaz gráfica. Esta versión de pstat toma una fotografía (snapshot) del
sistema.
pulist.exe Esta herramienta despliega procesos corriendo en maquinas locales o remotas. Despliega
el nombre del proceso, su ID e intenta obtener el user name asociado. Esto es importante
cuando múltiples procesos se están ejecutando en el sistema en diferentes contextos de
seguridad.
qslice.exe Muestra el porcentaje del total de CPU en uso por cada proceso en el sistema. Es similar
a pstat.exe pero presenta la información en forma gráfica.
showperf.exe Es una herramienta gráfica que permite a los desarrolladores descargar y desplegar raw
performance data del registry y desplegarla.
apimon.exe Monitorea aplicaciones corriendo de todas las llamadas API (Application Programming
Interface) de un proceso.
sclist Es un comando en línea que muestra los servicios actualmente corriendo, los servicios
parados o todos los servicios en una computadora local o remota.
http://www.petri.co.il/download_free_reskit_tools.htm
Nota: En forma remota solo si se encuentra dentro del dominio
svrinfo Es un comando que despliega los servicios, información acerca del espacio en disco y
tipo de particiones en un servidor remoto.
Nota: Despliega la información local y la información de servidores donde se este
conectado o WinXP.
showmembers Es un comando que muestra los miembros de un grupo dentro de un dominio o los
grupos en forma local.
Nota: Para mostrar los miembros del dominio se necesita estar dentro de éste.
dumpel.exe Es un comando en línea que descarga la bitácora de eventos de un sistema local o remoto
a un archivo de texto (tab-separated)
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/dumpel-o.asp
now.exe Despliega la fecha y tiempo del sistema en la salida estándar
Los comandos publicados en la tabla 3.3 no se encuentran libres, por lo que hay que comprarlos:
Tabla 3.3 Herramientas de Windows Resource Kit con costo
Utilería Función
cconect.exe Concurrent Connection Limiter. Provee un método para rastrear conexiones

39
Utilería Función
concurrentes y monitorear que usuarios están conectados al sistema.

showacls.exe Enumera los derechos de acceso para archivos, fólderes y árboles.
sleep.exe Batch Files Wait. Causa que la computadora espere por una cantidad de tiempo
especificada.
top.exe Time-Ordered Processes. Lista los procesos que está usando el tiempo del procesador.
totlproc.exe Total Processors. Mide el uso de memoria de todos los procesos instalados.
usrstat.exe User Statistics. Lista los nombres completos de usuarios y su última conexión.
3.1.1.3 Herramientas para Windows no propietarias
Existen herramientas libres en Internet para Windows. Una de las más importantes es
md5sum.exe que determina cuando la información ha sido modificada. Una buena práctica es
correr las herramientas de captura, enviar la salida a algún medio e inmediatamente generar un
md5sum o registro de tiempo de los datos.
Otras herramientas útiles son el fport.exe, ethereal, winhex y las utilerías de PsTools [10]. Una
búsqueda en Internet obtendrá estas y otras herramientas, que se podrán utilizar durante una
examinación forense.
PsTools
Los kits de recursos de Windows NT y Windows 2000 vienen con un número de herramientas de
comandos en línea que ayudan a administrar el sistema. PsTools es un conjunto de herramientas
no propietario de Microsoft que incluye comandos similares a los kit de recursos de Windows [27].
Todas estas utilerías trabajan en Windows NT, Windows 2000 y Windows XP y no necesitan ser
instaladas como las herramientas del Resource Kit. La suite PsTools incluye las utilerías
mostradas en la tabla 3.4.
40
Tabla 3.4 Suite PsTools
Utilería Función
psexec Ejecuta procesos remotamente. Nota: Se necesita cuenta y password de la máquina

remota para ejecutar el comando deseado.
psfile Muestra los archivos de la máquina que han sido abiertos remotamente
psgetsid Despliega el SID de una computadora o usuario
pskill Elimina procesos por nombre o ID
psinfo Lista información detallada acerca de los procesos, el tipo de SO, versión, etc.
psloggedon Muestra quien esta en una sesión localmente y quienes están conectados a recursos
compartidos y desde que hora iniciaron la sesión.
Si el servidor esta dentro de un dominio conectado con otros servidores puede dar
algunas otras conexiones de usuarios con otros servidores diferente a el.
psloglist Descarga la bitácora de eventos.
Nota: Solo para WinXP.
pspasswd Cambia los passwords de cuentas
psservice Muestra y controla servicios
psshutdown Da de baja o reinicializa la computadora
pssuspend Suspende procesos de la máquina remota o local
psuptime Muestra cuanto tiempo el sistema ha estado arriba. Se ha incorporado a psinfo.
pslist PsList es una utilería que muestra una combinación de información de los dos
comandos del Resource Kit (ps y list), incorporando la habilidad de poder ver procesos
y estadísticas de hilos en una computadora remota.
Con los parámetros de default PsList muestra información orientada a CPU de todos los
procesos que están corriendo en el sistema local. La información listada por cada
proceso incluye el tiempo de procesador en que se ha ejecutado y cantidad de memoria
física asignada.
Nota: Para obtener los datos remotamente se necesita que el equipo remoto tenga
habilitado el puerto RPC o tener corriendo los servicios remotos del registry.
SYSINTERNALS
listdlls Lista los DLLs abiertos por cada proceso, etiqueta los DLLs cargados con diferentes
números de versiones que pueden corresponder a archivos en disco y pueden decir cual
DLL esta relocalizado porque no está cargado en su dirección base.
Nota: Corre en la máquina localmente

process explorer Muestra la información acerca de un proceso determinado y sus DLLs cargadas o
abiertas. Consiste en dos ventanas. Una ventana muestra una lista de los procesos
activos, incluyendo el nombre de sus propietarios, si el proceso es un DLL se observará
la memoria mapeada.
Nota: Corren en la máquina localmente

tcpcon /tcpiew Enumera los “endpoints” de TCP y UDP
41
Utilería Función
http://www.sysinternals.com/utilities/tcpview.html
Nota: Funciona localmente
3.1.1.4 Herramientas varias
Un posible ataque lo podemos detectar al encontrar un volumen de tráfico inesperado en lugares

inusuales. Para detectar el tráfico anómalo debemos entender muy bien el flujo de tráfico de red.
Para lo cual podemos utilizar algunas herramientas libres disponibles e instalarlas en cualquier
linux para formar un buen conjunto de herramientas, aunque el objeto de análisis sea Windows
[22].
Mientras no contemos con una solución integrada, podemos construir un conjunto simple y
rápidamente con las herramientas mostradas en la tabla 3.5.
Tabla 3.5 Herramientas varias Windows
Utilería Función
ethereal Permite capturar y graficar tráfico de red, corre bajo Windows y bajo Linux.
La habilidad de Ethereal para capturar el tráfico de red 802.11 en Windows es limitado
debido al bajo soporte ofrecido por los drivers 802.11 de los adaptadores.
En Windows, no se puede administrar la captura o controlar los frames, tampoco se puede
capturar en modo promiscuo, por lo que solo se podrá capturar el tráfico para y desde la
máquina que está corriendo Ethereal.
Esto se debe considerar al correr este software en Windows.
etherape Construye “talkers map” para un segmento de red dado, es una gran herramienta para
caracterizar trafico “normal”.
tcpreplay Permite repetir tráfico capturado y controlar la velocidad en la cual fluye a través de otro
programa.
fport.exe Fport es soportado por Windows NT, 2000 y XP. Este comando reporta todos los puertos
TCP/IP y UDP abiertos. Es la misma información que se despliega usando el comando
“netstat -an”, pero muestra estos procesos con el PID corriendo, nombre y ruta. Puede ser
utilizado para identificar rápidamente puertos desconocidos abiertos y sus aplicaciones
asociadas. http://www.foundstone.com
winhex Es un editor hexadecimal que es utilizado en recuperación de datos y procesamiento de
datos a bajo nivel. Inspecciona y edita toda clase de archivos, recupera archivos borrados o
datos perdidos del disco duro en sistemas de archivos corruptos y también en tarjetas de
cámaras digitales. Se puede descargar de la siguiente dirección:
http://www.winhex.com/winhex/index-e.html
l0pthcrack L0pthCrack o LC es una aplicación para recuperar y auditar passwords. Se puede obtener
una versión de evaluación por 15 días en Internet.
http://www.atstake.com/products/lc/
pwdump2 Descarga los password hashes (trozos de password encriptados en formato ASCII) del
42
Utilería Función
Active DIrectory. Es una herramienta libre en Internet.

http://www.bindview.com/Services/razor/Utilities/Windows/pwdump2_readme.cfm
quickwiper Es una utilería para limpiar discos y archivos, se puede obtener una versión de evaluación
en Internet.
http://www.soft32.com/download_4586.html
e-timestamp Obtiene un sello de tiempo de los archivos, se puede obtener una versión de evaluación en
Internet. http://www.e-timestamp.com/
md5sum.exe Con la verificación md5 se compara la huella digital (fingerprint) de los archivos que se
bajaron con la huella digital de los archivos publicados en el servidor, esto con el fin de
verificar que los archivos no estén corruptos. Esta herramienta se encuentra libre en
Internet.
http://www.etree.org/md5com.html
nmap.exe Programa de escaneo de puertos, versión libre para Linux y para Windows.
http://www.insecure.org/nmap/nmap_download.html
Necesita tener instalado winpcap ( http://www.winpcap.org/ ) que es una serie de librerías
Open Source Windows, que son usadas por capas de red de bajo nivel y es la máquina
(engine) de varias herramientas de red comerciales y de código abierto (open source).
Como nmap, snort, windump, ntop, etc.
Nota: Necesita tener instalado winpcap en la máquina donde será corrido.

ntlast Analizador de bitácoras de seguridad. Identifica quien ha ganado acceso al sistema.
http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/res
ources/freetools.htm
Nota: En el equipo bajo análisis deben estar habilitadas las políticas de auditoría
showin Muestra información acerca de Windows. Revela passwords
bintext Encuentra strings en un archivo.
filemon Monitorea y despliega la actividad del sistema de archivos en tiempo real. Explora la forma
en que trabaja Windows, buscando cómo las aplicaciones utilizan los archivos y DLLs. La
característica de sello de tiempo (timestamp) de Filemon muestra cuando la abertura,
lectura, escritura o borrado se llevó a cabo y el resultado.
http://www.sysinternals.com/Utilities/Filemon.html
netcat Utilería usada para crear un canal de comunicación entre dos sistemas diferentes. Cryptcat
(cryptcat) es usada para crear canales de comunicación encriptado. Netcat provee la forma de
transferir información entre sistemas en red.
3.1.1.5 Volcado de memoria
El volcado de memoria es un procedimiento de descarga de información de memoria a un un

archivo creado en el sistema con extensión “*.dmp”. Las acciones que realiza Windows cuando
se produce este error son: escribir un suceso en el registro del sistema, alertar a los
administradores, vaciar la memoria del sistema en un archivo que se puede depurar y reinicia
automáticamente el sistema [24].
43
Los registros del archivo de volcado de memoria son un conjunto de información que puede
ayudar a identificar porque la computadora ha parado inesperadamente. Esta opción requiere un
archivo de pagineo (paging file) de por lo menos 2 MB (megabytes) en el volumen de booteo. En
computadoras corriendo Windows 2000 o sistemas recientes, Windows crea un archivo nuevo
cada vez que la computadora para inesperadamente.
Userdump.exe
Esta herramienta se puede utilizar para generar un volcado de usuario de un proceso que se cierra
con una excepción o cuando un proceso deja de responder (bloqueos) [25].
Como leer los archivos dump

Para leer los archivos dump utilizamos la herramienta WinDbg que permite ver el contenido de
los archivos generados por un volcado de memoria producidas por violaciones de acceso por
fallas de página inválidas o fallas de protección [26].
3.1.3 HERRAMIENTAS FORENSES PARA WINDOWS
La mayoría del software forense que se puede correr en Windows es comercial y se necesita
pagar una licencia para poder utilizarlo, en algunos sitios se puede bajar un demo para presentar
el producto. A continuación se muestran algunos productos, pero no se hace uso de ellos en esta
investigación.
3.1.3.1 Software comercial
El software comercial, tiene un costo para poder utilizarlo, algunos de estos productos tienen una
copia de evaluación o demostración, que el investigador podrá bajar y si es útil y se puede
adaptar fácil a sus necesidades, comprarlo. Algunos de los productos comerciales para Windows
son mostrados en la tabla 3.6.
Tabla 3.6 Software comercial para Windows

44
Producto Características
detective y Ambas herramientas son comercializadas por la compañía Tech Assist Inc.
byteback
Byte Back es una herramienta de recuperación. Dentro de sus características se encuentra la
clonación o creación de imágenes, la recuperación de archivos en particiones FAT y NTFS.
Detective es una herramienta de búsqueda y reporte sobre windows, diseñada para

investigar PCs en red y stand-alone. Se puede obtener una copia de evaluación en la
siguiente dirección en Internet previo registro http://www.toolsthatwork.com.
encase EnCase es un software para Win95/98 y NT, se utiliza para la recuperación de archivos.
forensic Utiliza un lenguaje de programación EnScript que permiten al investigador diseñar sus
edition propias rutinas. Los sistemas de archivos interpretados por este software son: FAT, NTFS,
HFS, Sun Solaris UFS, EXT, BSD, Palm entre otros. Se puede obtener un CD de
evaluación en Internet previo registro en la dirección http://www.guidancesoftware.com/
forensic Se puede obtener un software de demostración en Internet previo registro en la dirección

utility suite http://www.lc-tech.com para el kit con Filerecovery, Photorecovery y RescuePro.
forensic Access Data es una empresa que ofrece capacitación y servicios en forensia, dentro de sus
toolkit productos se encuentran:
password Forensic Toolkit. Existe una versión de demostración en su página de Internet en la

toolkit siguiente dirección : http://www.accessdata.com
Password Toolkit. Se puede obtener de la siguiente dirección http://www.accessdata.com
ghost Norton Ghost 2002. Software de Symantec que puede clonar y restaurar particiones
individuales o discos completos, y puede enviar y recibir imágenes de disco a través de
partition LAN, USB, y conexiones de puertos paralelos. El editor de imágenes de Ghost Explorer
magic permite usar drag-and-drop para mover archivos y directorios dentro o fuera de la imagen
clonada.
Partition Magic. Software que permite realizar particiones en diversas plataformas.
Ambos productos se pueden obtener de la siguiente dirección en Internet :

http://www.symantec.com
safeback Software que es utilizado para crear imágenes de disco duro. Las imágenes de SafeBack no
pueden ser modificadas o alteradas. Se puede obtener en la siguiente
dirección:http://www.forensics-intl.com/
forensic Paraben Corporation es una empresa que se dedica a ofrecer servicios forenses,
replicator capacitación, equipo y software, a través de su página en Internet http://www.paraben.com,
podemos encontrar los siguientes productos:
forensic
sorter Forensic replicator. Se utiliza para crear réplicas exactas de controladores (drives) y
medios. Es basado en windows.
pda seizure
Forensic sorter. Ordena los datos en una forma efectiva para hacer búsquedas exactas.
PDA Seizure. Herramienta diseñada para capturar y reportar datos de un PDA, reportando
sobre un ambiente windows.
ilook Es distribuido gratuitamente para agencias calificadas como: Inteligencia, Militar y
Gobierno. Se puede encontrar en la siguiente dirección: http://www.ilook-forensics.org.
45
3.1.3.2 Hardware forense
Ya hemos hablado del software necesario para la recolección y análisis forense, pero es necesario
contar con un equipo donde se corra este software que nos va a ser de utilidad para recolectar
datos, monitorear la red y hacer imágenes de disco. Este equipo puede construirse o adquirirse.
Como desconocemos el tipo de SO, equipo de cómputo o dispositivo de comunicación con el que
nos vamos a enfrentar, lo mejor es contar con la mayor cantidad de controladores (drivers) de
dispositivos y Sistemas Operativos. Aún así se puede utilizar cualquier computadora, pero en el
caso de un investigador profesional es mejor estar preparado. Algunos productos de hardware
forense son mostrados en la tabla 3.7.
Tabla 3.7 Hardware Forense
Empresa Producto y descripción
Intelligence, Inc FRED (Forensic Recovery of Evidence Device). Es un equipo que

puede ser usado tanto para la adquisición como para el análisis de
Compañía que ofrece evidencia. Es modular y se puede usar como una PC estándar.
soluciones de hardware y
software para el cómputo Tiene preconfigurado multi-boot de Sistemas Operativos (DOS 6.22,
forense. Sus productos se Windows 98, XP Prof), contiene el software DriveSpy que es un shell
pueden obtener en la siguiente de DOS que puede procesar particiones FAT ocultas de DOS, archivos
dirección: borrados, espacio asignado o no y RedHat con Norton SystemWorks.
http://www.digitalintel.com/ Otras de las utilerías con las que cuenta es Image (genera imágenes de
discos floppy), PDWipe (limpia el disco duro), PDBlock (previene
escrituras inesperadas a un dirve físico), Part (provee información
acerca de las particiones del disco duro) y hash MD5.
Existen varias versiones de este tipo de equipo más equipadas o más

portátiles.
UltraBlock
Es un dispositivo que protege a controladores (drives) de escrituras
inesperadas, se puede conectar a través de FireWIre y USB.
UltraBlockIDE utiliza manejadores (drives) IDE, ATA, SCSI,etc
46
The Shadow
Es un dispositivo que es instalado entre el controlador IDE sospechoso
y el disco duro sospechoso. Permite a un sistema bootear en el
ambiente sospechoso, manteniendo la integridad del ambiente bajo
análisis. Para lo cual almacena y administra todas las operaciones de
escritura y modificación del sistema. Asegurando que todas las
actualizaciones y escrituras son obtenidas y almacenadas internamente
redireccionándolas a una cache interna. Como opera a nivel físico, es
compatible con todos los sistemas operativos.
Intelligent Computer Forensic Link MASSter

Solutions Es un equipo portátil conteniendo un software de adquisición de datos.
Realiza transferencia entre el disco duro sospechoso y un puerto
Es una empresa que se dedica FireWire o USB. Soporta MD5, SHA1 y CRC32 durante la
al diseño y manufactura de adquisición. Captura cualquier Sistema Operativo, realizando copias a
duplicación de equipos a alta nivel de bit de drive sospechoso incluyendo todos los datos
velocidad, software de almacenados, archivos borrados, espacio libre y archivos slack. Los
clonación, diagnóstico de métodos de captura de datos se realizan con las herramientas Forensic
sistemas y productos forenses. Tool Kit, Encase y dd de Unix.
Sus productos se pueden
encontrar en la siguiente
dirección:
http://www.ics-
iq.com/products_cat_fr.cfm
47
Image MASSter
Es un software de duplicación de dispositivos hecho para capturar datos
de disco.
Forensic Workhorse IV Equipo portable que contiene manejadores para CD-ROM, DVD, SCSI,
IDE. El equipo es compatible con todo el software de forensia
comercial, Encase, Forensic Tool Kit, Safe Back, Mares, etc. Este
producto se puede encontrar en la siguiente dirección: www.forensics-
computer.com
Adicional al conjunto de herramientas principal, hay muchos otros elementos de los que debemos
disponer cuando se realiza una investigación. Estos elementos incluyen elementos que ayudaran a
documentar actividades en el área. Los dispositivos de registro como cámaras fotográficas, los
medios de almacenamiento seguro y una buena libreta de apuntes.
Es necesario contar con un equipo de red pequeño, como un concentrador (hub) de 4 puertos y
cable de red. Un CD o floppy de respuesta a incidentes para ayudar a buscar y recoger evidencia
en forma segura, sin afectar al sistema victima.
Toma mucho tiempo crear un buen conjunto de herramientas, la mejor forma es probar y
anticipar los sistemas que pueden sufrir intrusiones. Poco a poco se hará mas completo hasta
crear un buen conjunto de herramientas para cada SO, tipo de kernel, etc.
La respuesta a un incidente dependerá de las herramientas que se tengan disponibles.

48
3.2 SO LINUX
La respuesta inicial en Unix y Linux es similar a la respuesta inicial en Windows, el objetivo es

obtener datos volátiles de los sistemas antes de proceder a la duplicación forense y poder
expandir el alcance de la respuesta inicial para obtener archivos de bitácoras, archivos de
configuración, sistemas de archivos y archivos relevantes (como herramientas hacker o
programas sospechosos) para confirmar rápidamente si ha ocurrido un incidente o no.
Lo bueno de utilizar Linux para Forensia es que la mayoría de las herramientas son libres y el
ambiente es flexible. Las limitaciones son que como la mayoría de las herramientas son libres, no
se tiene soporte técnico.
Según Kevin Mandia y Chris Prosise [36] una de las diferencias de trabajar en Unix y Linux con
respecto a Windows es la dificultad de recuperar archivos borrados en algunas variantes de Unix
y Linux. Cuando se ejecuta un proceso en Windows NT/2000, no se puede borrar el archivo
correspondiente al proceso. Sin embargo Unix y Linux permite borrar un programa después de
que ha sido ejecutado, el proceso puede seguir corriendo, aun cuando el archivo ha sido borrado
del disco duro.
3.2.1 HERRAMIENTAS DE CAPTURA PARA EL SO LINUX
Linux provee muchas utilerías para realizar recolección y restauración de información del
sistema, cuenta con software de captura de imágenes de memoria como dd y dio. Preparar el
conjunto de herramientas (toolkit) no es tan fácil y toma tiempo, porque cada variante del sistema
operativo puede llegar a requerir un conjunto de herramientas único.
49
3.2.1.1 Comandos del Sistema Operativo Linux
Para evitar una dependencia de las bibliotecas en el sistema víctima, se deben compilar las
herramientas estáticamente. Con la opción “static” para crear un programa ejecutable que no
requiera el uso de bibliotecas compartidas. En caso de ser necesario se puede utilizar el comando
“ldd” para determinar si el programa incluye librerías dinámicas e incluir éstas en el conjunto de
herramientas.
La tabla 3.8 expone comandos del sistema operativo Linux y su utilidad para la recolección de
información.
Tabla 3.8 Comandos del Sistema Operativo Linux para recolección
Utilería Función
ps Recopila información de los procesos

-aux
lsof Lista los archivos abiertos
top Despliega los proceso del CPU
netstat Imprime conexiones de red, tablas de ruteo, etc.

-nr
nmap Herramientas de exploración de red y escaneo de seguridad.
$ nmap –O IPaddr Intenta adivinar el tipo de SO de la IPaddr
nslookup Permite interactuar con un DNS
whois Cliente para el servicio de directorios Whois
host Utilería para la búsqueda en el DNS
nc Netcat, permite conexiones de TCP y UDP
uptime Dice cuanto tiempo el sistema ha estado corriendo
w, who Muestra quien está logeado y que está haciendo.
fuser Identifica procesos usando archivos o sockets
strace Rastrea llamadas a sistema y señales

50
Utilería Función
ltrace Rastrea llamadas a librerías dinámicas que son llamadas por el proceso ejecutado.
strings Imprime los caracteres reconocibles de un archivo. Es útil para determinar el contenido
de archivos que no son de texto.
Md5sum Crea y verifica la autenticidad del archivo (checksum)
dd Convierte y copia un archivo

Lee dispositivo de discos bloque por bloque, incluyendo bloques de datos marcados
como borrados. Copia datos que no copian las herramientas para respaldos regulares
como tar o dump.
cat Concatena archivos e imprime en la salida estándar.
lsmod Lista los módulos cargados. Esta información también se encuentra en /proc/modules:
$ cat /proc/modules
sfdisk Manipula la tabla de particiones de Linux
df Reporta el espacio utilizado por el sistema de archivos del disco
dmesg Imprime los mensajes de inicio en el booteo
Last Muestra la lista de los usuarios loggeados
date Despliega la fecha y hora del sistema
Ifconfig -a Despliega la información acerca de la tarjeta de red.
ls Información de timestamp, último acceso, modificación y creación para cada archivo.

Las opciones son: -c para la última modificación del i-nodo, -a para el último acceso,
-ls para la última modificación del estado del archivo.
La modificación del i-nodo puede ser: cambiar los permisos (Mode changed), cambiar
el nombre del archivo, copiarlo a otro equipo o crear el archivo (File created).
El acceso puede ser: verlo o copiarlo con ftp.
El estado del archivo puede ser realizar un cambio interno.
find Busca archivos. Ejemplos pueden ser:
Buscar archivos por permisos: $ find / -perm 540 –ls
Buscar archivos donde el propietario es root: $ find / -user root –ls
Buscar archivos modificados en los ultimos 5 días: $find / -mtime -5
Mostrar archivos modificados la semana anterior: $ find / -mtime +2 –a +mtime -7
printenv Imprime todo o parte de un ambiente
file Determina el tipo de archivo. Clasifica los archivos en varios tipos, prueba el sistema
de archivos, el número mágico y el lenguaje.
ptrace Llamada a sistema que provee una interfaz por la cual un proceso padre puede
observar y controlar la ejecución de otro proceso, examinar y cambiar su imagen core y
registros. Es usada principalmente para implementar “breakpoints debugging”
script Hace un typescript de todo lo que se ha impreso en la Terminal. Para iniciar la captura
solo se ejecuta el comando “script” para finalizar la captura se puede usar CTRL-d.
more Filtro para páginas a través de texto en una pantalla a la vez
51
Utilería Función
gzip Comprime o expande archivos
bash Shell Bourne. Abre un shell, o espacio de trabajo.
DES Algoritmo criptográfico.
modinfo Despliega información acerca del módulo de kernel
vi Editor de texto. Nota: se puede evitar que los comandos se guarden en el historial con !:
“ : ! cat /etc/passwd “
pkginfo Despliega los paquetes de software instalados, para versiones de UNIX , AIX y Solaris.
rpm Red Hat Package Manager. Utilería que permite desplegar los paquetes de software
instalados e información referente a estos con la opción: rpm –qa,
rpm –qai paquete
rm Remueve archivos y directorios
cp Copia archivos y directorios
mmap Mapea o desmapea archivos o dispositivos en memoria. Es una función para programar
/usr/sbin/tcpd Tcpd anota todos los intentos de conexión que le llegan en /var/log/secure para que
tenga la posibilidad de saber quien intenta conectarse a su máquina y si lo consigue
openssl Es una herramienta de criptografía que puede ser utilizada para la creación de llaves
RSA, DH, DSA, creación de certificados, el cálculo de los “message digest”, cifrar o
descifrar, pruebas de servidores con SSL y TLS, y manejo de correo encriptado.
pkg-config Obtiene metainformación acerca de las librerías instaladas. El directorio donde está
instalada, etc.
#pkg-config - -cflags glib
#pkg-config - - modversion glib
iptables Herramienta de administración para el filtrado de paquetes
$iptable –L Lista
debugfs Depurador del sistema de archivos ext2
Para listar los inodos borrados:
$ debug /imagenes/floopy.img
debug: lsdel
ldd Imprime dependencias de librerías compartidas
mount Comando que permite montar Sistemas de Archivos: CDROM, floppy,etc.

swapon Habilita o deshabilita dispositivos y archivos para pagineo y swapeo
swapoff
pstree Despliega el árbol de procesos
Los archivos y programas mostrados en la tabla 3.9 también ayudan a proveer más información
sobre el sistema:
Tabla 3.9 Archivos y programas del sistema operativo Linux

52
Archivo Utilidad
/proc Es un pseudo-filesystem que funciona como interfaz para las

estructuras de datos del kernel
/proc/meminfo Permite determinar la cantidad de memoria física. Podemos
observar su contenido con cat.
/etc/inetd.conf o /etc/xinetd.conf Configuración de los servicios de Internet
Perl Lenguaje de programación, incluido en el SO (Red Hat)
/dev/mem Archivo de dispositivo tipo caracter que corresponde a la

memoria física del sistema. Es un archivo especial que refleja
la memoria principal – byte offsets en el archivo de dispositivo
son interpretados como direcciones de memoria por el kernel
/dev/kmem Archivo de la memoria virtual del kernel, representa el espacio
de direcciones virtual del kernel y una vista mas uniforme de
la memoria en cuestión.
/var/log/wtmp Permite ver quien está logeado
$ last –f ./wtmp | more
/etc/passwd Información de usuarios
/var/log/messages Información de las bitácoras
/etc/issue Archivo que contiene la información del SO y su versión.
/var/log/boot.log Archivo que contiene registros de inicialización del sistema.
/etc/fstab Mapa de particiones.
PATH La variable de ambiente PATH, direcciona la ejecución de los

programas a la trayectoria definida por esta variable.
3.2.1.2 Volcado de memoria (Memory dump)
La facilidad de crear volcados de memoria (memory dump) provee un análisis de primera falla.
La caída de un sistema (crash) se presenta con una falla (bug) de hardware o software (Oops,
BUG() o panic). En Linux la información del volcado de memoria contiene el estado del
procesador, un rastreo de la pila y un conjunto limitado de instrucciones.
Existen parches disponibles para Linux e implementaciones de algunas versiones de Unix, que
reinicializan el sistema sin limpiar la memoria, vaciando una imagen de memoria a disco duro en
una partición swap. Este procedimiento no es estandarizado y generalmente no es disponible ya
que no todos tienen la facilidad del firmware PCBIOS para hacerlo, aún entre cambios de
53
versiones del mismo firmware, por lo que no es una solución razonable para sistemas operativos
de propósito general [15].
Existen máquinas Intel que no limpian la memoria en la reinicialización. Para saber si el equipo
con el que trabajamos es de ese tipo, en el kernel se coloca el parámetro “reboot=w”. Esto
advierte un “warm reboot” instruyendo al BIOS para saltar el chequeo de memoria. Algunas
veces funciona, aunque la mayoría no [13].
En la distribución de Linux Red Hat existen varias herramientas que podemos utilizar para
obtener información realizando un volcado de memoria: Netdump y GDB
Netdump (Network Console and Crash Dump Facility)
Los dispositivos de red son simples, permiten de una forma fácil habilitar un modo de
interrupciones no manejadas, esta característica le permite al sistema seguir trabajando, aun
cuando ocurra una caída del sistema (crash).
Netdump incluido en la versión de Red Hat Advanced Server 2.1 aprovecha esta ventaja y provee
la facilidad de realizar crash-dump y enviar la información a través de red. Netdump es una
arquitectura cliente-servidor, se debe instalar el paquete netdump-server y configurarlo, los
clientes configuran la dirección del servidor donde enviarán los mensajes del kernel y podrán
vaciar imágenes de memoria al servidor centralizado vía la red.
El servidor centralizado registra los mensajes del kernel, incluyendo crash signature messages,
etc. Los dumps son preservados para análisis comparativos, algo que no es fácil con crash dumps
sobre discos [15].
El crash dump se realiza antes de reinicializar el equipo, esto permite reservar solo la memoria
necesitada por el código de crash dump (algunas páginas de memoria), y extender la información
provista por el dump, incluyendo el estado del hardware.
GDB (GNU Project Debbuger)

54
GDB (Proyecto debugger GNU) desarrollado por Richard Stallman, es el depurador de GNU,
permite ver qué está pasando dentro de un programa cuando se está ejecutando o que otro
programa se está ejecutando en el momento de un crash. Viene incorporado en varios sistemas
como RedHat Enterprise.
Una vez iniciado, gdb lee los comandos desde la terminal. Dentro de GDB los comandos
“dump”, “append” y “restore” en GDB pueden copiar datos entre memoria y archivos. Los
comandos dump y append escriben datos a un archivo, y el comando restore lee los datos del
archivo para regresarlos a memoria. Los archivos pueden estar en formato binario[14].
El siguiente ejemplo vacía el contenido de la memoria desde la dirección de memoria start_addr

(0x00000) hasta la dirección end_addr(0xFFFFF):
(gdb) dump memory descarga 0x00000 0xFFFFF
En el siguiente ejemplo el comando append agrega el contenido de la memoria desde la dirección

de memoria start_addr hasta la dirección end_addr al archivo filename en forma binaria.
(gdb)append [binary] memory filename start_addr end_addr
El comando restore, restaura el contenido del archivo en memoria. El parámetro “bias” es

agregado a la dirección contenida en el archivo. Los archivos binarios siempre empiezan en cero,
por lo que estos deberán ser restaurados en la dirección “bias”.
(gdb)restore filename [binary] bias start end
Proyecto LKCD
Existen varios módulos ya creados para Linux que nos permiten obtener información de la
memoria. Uno de éstos fue creado por el proyecto Linux Kernel Crash Dump (LKCD). Este fue
diseñado para que los administradores de sistemas tuvieran un método confiable para guardar
información y poder examinar una caída de su sistema (system crash).
El proyecto usa código a nivel de usuario y de kernel con los siguientes objetivos:
55
1) Salvar una imagen de memoria del kernel debido a una falla de software.
2) Recuperar una imagen de memoria del kernel cuando el sistema ha sido reinicializado (reboot).
3) Analizar la imagen de memoria para determinar que sucedió cuando la falla ocurrió.
La imagen de memoria es almacenada en una partición definida del sistema que es conocida
como dispositivo “dump”. Una vez que el sistema se normaliza después de la reinicialización del
sistema, pero antes de que la partición swap sea montada, el archivo dump es recuperado
utilizando la herramienta “lcrash” (Linux Crash).
LKCD permite realizar volcados no destructivos. Esto significa que el sistema continúa corriendo
después del proceso de volcado, pero en operaciones destructivas como “panic” el sistema se
reinicializará. La instalación de LKCD requiere que se reconstruya el kernel[11, 24].
3.2.2 HERRAMIENTAS FORENSES PARA LINUX.
El software que vimos en las secciones anteriores tiene como objetivo apoyar al administrador
del sistema, pero las herramientas forenses están diseñadas para apoyar al investigador forense.
Al igual que el software de capítulos anteriores, el conjunto de herramientas debe contener de

preferencia binarios estáticos que no utilicen bibliotecas o recursos dinámicos compartidos en el
sistema.
También puede ser útil no ejecutar los programas con nombre obvios de programas forenses o de
respuesta a incidentes como “graverobber”, “lazarus” o “mactime”. Por lo que se puede
renombrar las herramientas con nombre menos evidentes.
3.2.2.1 TCT Coroner´s Toolkit
TCT Coroner´s Toolkit es un paquete de utilerías escritas por Dan Farmer y Wietse Venema [35]
para la realización de un análisis forense en un sistema UNIX. Este software fue presentado por
primera vez en agosto de 1999. Fue diseñado para los sistemas Unix, pero puede recolectar y
analizar datos en discos o medios que no son de Unix. El sistema corre en FreeBSD, OpenBSD,
SunOS y Linux.
56
Los programas principales de TCT son:
• Grave-robber
Herramienta de captura de datos.
• Las herramientas C (ils, icat, pcat, file, etc.).
Estas son utilizadas por grave-robber, pero pueden ser utilizadas individualmente.
• Unrm & lazarus
Herramientas para recuperar archivos borrados y datos ocultos o perdidos. Unrm hace una copia
de todo el espacio en disco accesible y no asignado, lazarus analiza esta copia y trata de
determinar cada bloque de datos y su tipo.
• mactime
Herramientas que despliegan los patrones de acceso de los archivos.
De estas herramientas la más utilizada es grave-robber y mactime. Unrm y lazarus se utilizan si

se tiene tiempo y espacio suficiente para un análisis post-mortem por lo que no explicaremos
estas dos últimas herramientas ya que nuestro objetivo es la recolección de información volátil.
El tiempo necesario para obtener datos con TCT depende del sistema, su procesador y el espacio
requerido. Utilizar esta herramienta puede tomar tiempo considerable y crear un gran volumen de
datos. El análisis de esta información puede tomar horas.
Pasos de instalación:
#cd /home/hforenses/
#tar zxvf tct-1.15.tar.gz
#cd tct-1.15
#make
Se requieren varios megabytes para la salida del TCT. La herramienta unrm puede consumir más
del espacio localizado en el disco duro. TCT usa nombres de path completos.
Almacenar TCT en un floppy

57
Para preparar una copia de TCT y poder almacenarla en un floppy podemos realizar los
siguientes pasos:
# mkdir /home/hforenses/tct
# cp –R /home/hforenses/tct-1.15/* /home/hforenses/tct
# rm –rf /home/hforenses/tct/data
# rm –rf /home/hforenses/tct/src
# rm /home/hforenses/tct/*.log
Después de este paso copiamos los archivos del directorio tct en un floppy:
# cp –R /home/hforenses/tct/* /floppy/tct/
Debido a que la copia todavía tiene referencias a los directorios donde se realizó la instalación,
todas estas referencias deben ser cambiadas, para este propósito los autores de TCT proveen el
script de configuración que hace esta tarea muy simple:
# cd /floppy/tct
# perl reconfig
Terminado el script obtenemos la copia que necesitamos.
GRAVE-ROBBER
Es la herramienta de captura de datos de TCT, intenta obtener y salvar información del sistema
necesaria para el análisis. Esta herramienta puede ser usada en una máquina “viva” o en una
imagen de disco del sistema de archivos de la victima. En el modo “vivo” grave-robber obtiene la
información según el siguiente orden de volatilidad:
1) Toma los atributos de todos los comandos y archivos. Esta información es recolectada
primero para preservar los atributos de tiempo MAC
2) Toma información del estado de los procesos y opcionalmente la memoria de todos los
procesos corriendo
3) Los archivos borrados que aún están activos.
4) Los archivos ejecutables de todos los procesos.
5) Los atributos de los archivos borrados
6) La información del estado de la red
58
7) La información del estado del host, vía comandos dependientes del sistema que proveen
información de configuración.
8) Los atributos de archivos existentes.
9) Opcionalmente, la información sensitiva como archivos que garantizan acceso remoto a
cuentas de usuarios y trabajos “cron” para comandos de ejecución desatendida.
10) Copia archivos de configuración y archivos críticos.
Toda esta información es almacenada en un directorio protegido que tiene el nombre del host y la
hora de inicio de la recolección de datos. Para cada archivo que es almacenado, grave-robber
aplica md5 hash.
Por default grave-robber corre para el sistema completo, se recomienda que corra como root para
que capture archivos y procesos de información que no son disponibles para usuarios normales.
Esta captura puede tomar varias horas.
Grave-robber es útil sobre sistemas “vivos”, pero también puede usarse sobre la imagen de un
disco. Las opciones que maneja son:
-c Esta opción se utiliza para especificar la ruta donde se encuentra la imagen.

-o Indica el tipo de SO de la imagen.
-E Recolecta todo lo que puede, incluyendo operaciones como pcat.
-f Captura rápida. Trata de evitar rutinas “caras” de recolección.
-F Captura archivos de sistema de archivos.
-i Recolecta datos de i-nodos de áreas no asignadas.
-I Captura archivos ejecutables de procesos corriendo. Primero trata de copiarlo
utilizando /proc, después usa icat con información del inodo que fue obtenida de
lsof
-p Copia procesos de memoria a archivos con el comando pcat.
-P Corre los comandos –pcat, lsof, icat- para obtener datos de los procesos corriendo
y hacer copias de lo archivos ejecutables.
-s Ejecuta comandos de shell para obtener información de host y de la red -netstat,
df, etc-
59
-t Recolecta información de servicios (etc, hosts.equiv, xhosts, .rhosts)

-v verbose
-M Realiza un md5sum de todos los archivos
-V Obtiene el número mayor y menor de /dev
-d Especifíca el directorio donde se almacenará la información recolectada (data)
La información recolectada es almacenada en el subdirectorio “data/hostname”. Dentro de este

subdirectorio existirán los archivos y subdirectorios mostrados en la tabla 3.10.
Tabla 3.10 Archivos y directorios de Grave Robber
Archivo y directorio Función
body Este es un archivo donde se concentra la base de datos de “mactime” de todos

los archivos examinados como su información de inodo, checksum md5 y
tiempo de acceso
body.s Este archivo contiene la misma estructura de “body” pero contiene
información acerca de los archivos SegUID solamente.
coroner.log Archivo que contiene la lista la ejecución de los programas que fueron
iniciados con argumentos y registros de tiempo.
error.log Archivo que contiene mensajes de error ocurridos durante la recolección de
datos.
MD5_all Archivo que contiene la lista de todos los registros MD5 de todas las salidas
generadas por grave-robber
MD5_all.md5 Archivo que contiene el registro MD5 del archivo MD5_all.
pcat Este directorio contiene las imágenes de los procesos corriendo que pcat
puede recuperar. Obtiene el history de los shells. Puede preservar o saltar
huecos en memoria, además de imprimir un mapa de memoria de procesos.
Opera sobre id de procesos.
proc Este directorio contiene imágenes de los procesos corriendo pero en base al
sistema de archivos /proc.
Removed_but_running Este directorio contiene todos los archivos borrados que estaban abiertos o
corriendo a la hora de obtener la información.
user_vault Copia de archivos sensitivos de los usuarios encontrados mientras se realiza el
análisis del sistema (como SSH key, archivos history, etc.)
deleted_files Este directorio contiene los archivos borrados que estaban abiertos o corriendo
cuando grave-robber arrancó.
command_out El directorio de la salida de la mayoría de los comandos que ejecuta
grave.robber
conf_vault Todos los archivos que son de interés para grave-robber son copiados en este
directorio. Este incluye archivos de configuración, archivos críticos,
directorios, etc.
trust Se almacenan los archivos respecto a relaciones de confianza entre equipos
(.rhosts, etc.)
60
También podemos utilizar las herramientas “C” en forma independiente como se muestra a
continuación:
PCAT
Pcat es útil en un sistema vivo para examinar procesos, porque copia el contenido de la memoria
del proceso a una salida estándar, pero no copia procesos de sistema. Un ejemplo se muestra en
el siguiente comando que envía a pantalla la información legible (con “strings”) del proceso
id_proceso.
# /tct/bin/./pcat id_proceso | strings | less
También se puede enviar esta información a un archivo para almacenarlo, ejemplo:
# /tct/bin/./pcat id_proceso > archivo.txt
ILS
Ils lista la información de i-nodos, en un análisis post mortem es muy útil para recolectar i-nodos
de archivos borrados. Ils es útil en sistemas vivos para determinar datos que posiblemente estén
ocultos (archivos abiertos pero “desligados” (unlinked)).
# /tct/bin/./ils –of ext2fs /dev/hda6 > archivo.txt
e = lista todo los inodos del sistema de archivos

r = lista solo los inodos de archivos borrados
o = lista solo los inodos de archivos borrados que aun están abriendo o ejecutando
f = especifica el tipo de Sistema de Archivos
Archivos no usados:
# /tct/bin/./ils –zf ext2fs /dev/hda6
z = lista los inodos con estado cero en “change time”. Por lo tanto son inodos que nunca han sido
usados (archivo no usados)
61
Este comando nos pueden indicar cuantos archivos están instalados en el sistema y que nunca
hemos utilizado.
ICAT
La herramienta icat copia archivos por el número de i-nodo de un dispositivo dado a la salida
estándar, es útil para recuperar archivos borrados. La podemos usar directamente sobre el disco
para recuperar archivos borrados, como se muestra a continuación:
# /tct/bin/./ils –rf ext2fs /dev/hda2
O aplicarla a una imagen de disco, recuperando los archivos junto con ils, como se muestra a
continuación:
# /tct/bin/./ils –rf ext2fs /imagenes/dev_hda2.img
class|host|start_time
body|pegaso|1129578295
st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_dtime|st_mode|st_nlink
28|a|0|0|1125313915|1125313915|1125313915|0|0|…
…st_size|st_block0|st_block1
…0|0|0
Donde st_ino es el número de inodo.

Con el resultado de ils utilizamos icat para recuperar el archivo :
# /tct/bin/./icat –hf tipo_FS devide_name num_inodo
# /tct/bin/./icat –hf ext2fs/imagenes/dev_hda2.img 28
h = salta hoyos en archivos, por lo que la información de la dirección absoluta es perdida

H = preserva la dirección absoluta porque copia los hoyos como bloques nulos
f = especifica el tipo de sistema de archivos que estamos utilizando.
FILE
File hace una clasificación por tipos de archivos, haciendo pruebas de sistema de archivos,
número mágico o de lenguaje:
62
# /tct/bin/./file Nombre_de_archivo
# /tct/bin/./file /tmp/borrados/*
/tmp/borrados/1207: empty
/tmp/borrados/16110: ASCII text
/tmp/borrados/2039: ELF 32-bit LSB executable, Intel 80386, version 1
/tmp/borrados/2047: perl commands text
MAC times
Mactime es un programa que intenta determinar que archivos fueron accedidos o modificados
con una ventana de tiempo dada. El programa mactime ordena el resultado y produce una lista,
mostrando las tres características de tiempo de los archivos, modificación, acceso y cambio, que
nos permitirá inferir alguna actividad del intruso en cuanto a tiempos.
El siguiente es un ejemplo de utilización de mactime, para crear un reporte de registro de tiempo

de todo el sistema de archivos (se asume que todos los archivos fueron creados después de Enero
2 de 1970):
# /tct/bin/./mactime –y –R –d / 1/2/1970
-R recursivamente a través de los subdirectorios

-d especifica el directorio de escaneo en vez de utilizar la base de datos del archivo body.
-y despliega la fecha como “YY MM DD” en vez de “MM DD YY”
También se puede especificar un periodo de tiempo:
# /tct/bin/./mactime –y –R –d bin 1/1/2005-1/14/2005
Todos los archivos son listados en orden por fecha y tiempo (primera columna). La segunda
columna lista el tamaño del archivo, la siguiente columna contiene la acción en el archivo: “m”
para modificación, “a” para acceso y “c” para creación.
Usando la opción –m con grave.robber, también llamamos a mactime para recolectar los registros
de tiempo.
# /tct/bin/./grave-robber –m /mnt/hack/root
63
Este resultado es almacenado en la base de datos de recolección de información de TCT en

“data”.
3.2.2.2 MEMDUMP
Memdump es un programa que fue escrito para evitar los problemas que se pueden tener con
“dd” o “cat”. Fue diseñado para alterar la memoria lo menos posible [18]. Después de instalarlo se
crea un archivo ejecutable y se puede obtener una imagen de la memoria sin reinicializar el
sistema y puede ser transferido por la red con netcat o ssl
Esta herramienta provista por los mismos autores de TCT, permite obtener una descarga (dump)
de la memoria física.
En una descarga de sistema de memoria “system memory dump”, se espera encontrar

información del sistema operativo, de procesos corriendo y de cada archivo y directorio que ha
sido accedido recientemente. Dependiendo del sistema operativo, se puede encontrar información
de archivos borrados, sin embargo esta información tiende a ser de corta vida.[18]
Este programa descarga la memoria del sistema a la salida estándar, saltando los hoyos en los
mapas de memoria. Por default, el programa descarga el contenido de /dev/mem. La salida esta
en formato crudo. Sus opciones son:
-k = Intenta descargar la memoria del kernel /dev/kmem

-b = Número de bytes por operación leída en memoria
-d = Número de bytes de memoria a descargar
-m = Escribe el mapa de memoria a un archivo
-p = Especifica el tamaño de la página de memoria
-v = Modo verbose
A continuación se muestra el uso de memdump a través de la red:
memdump | nc hosts port

64
memdump | openssl s_client –connect host:port
Para un mejor resultado enviamos la salida sobre la red usando “netcat” u “openssl.
3.2.2.3 Sleuth Kit y Autopsy
Sleuth Kit (TSK) es una colección de herramientas basadas en TCT y Autopsy, es una interfaz
gráfica para TSK. Estas dos herramientas son de código abierto, corren en sistemas como Linux,
OS X FreeBSD, OpenBSD y Solaris, y analizan sistemas de archivos NTFS, FAT, UFS, EXT2FS
y EXT3FS [16].
Sleuth Kit (TSK) previamente conocida como @stake Sleuth Kit (TASK), es una colección de
herramientas de comandos en línea basada en TCT. Permite examinar el sistema de archivos de
una computadora sospechosa en una forma no intrusiva, porque estas herramientas no se
relacionan con el SO. Soporta particiones DOS, BSD y Mac.
TSK permite analizar la imagen de un sistema de archivos creado con dd o un software similar.
Autopsy proporciona una interfaz gráfica para utilizar las herramientas de TSK. Estas dos
herramientas, en conjunto con TCT hacen un poderoso paquete de herramientas forenses para
Unix, Linux y Windows.
TSK
Algunas de las herramientas que utiliza son:
fsstat Muestra los detalles y estadísticas del sistema de archivos.
dcat Despliega el contenido de un “pedazo” de disco de una imagen forense. La imagen
debe ser creada con dd.
dls Recupera datos de disco. Lista los detalles acerca de unidades de datos y puede
extraer espacio no asignado (unallocated) del sistema de archivos. Es llamado
“unrm” en TCT
dstat Despliega las estadísticas acerca de una unidad de datos dada.
dcalc Calcula donde existen datos en una imagen (dd), en una imagen “slack” (dls –s) o
una imagen “unallocated” (dls).
65
icat Copia archivos por número de inodo. Extrae las unidades de datos de un archivo
ifind Encuentra la estructura del metadato que tiene asignada una unidad de disco dada.
ils Lista la información de los inodos o estructura de metadatos
istat Despliega las estadísticas y detalles acerca de una estructura de metadatos dada.
ffind Encuentra el nombre de un archivo o directorio en base a un inodo dado. Asigna y
libera el nombre de archivos que apuntan a una estructura de datos dada.
fls Lista los nombre de archivos y directorios de una imagen.
hffind Utiliza un algoritmo de ordenamiento binario, que busca hashes.
mactime Toma las salidas de archivos fls e ils para crear una línea de tiempo de la
actividad de los archivos
sorter Ordena los archivos basados en su tipo y extensión
mmls Despliega la distribución del disco, incluyendo el espacio no asignado.
Estas herramientas del sistema de archivos permiten examinar archivos de sistema de una
computadora sospechosa de una manera no-intrusiva. Debido a que las herramientas no dependen
del sistema operativo para procesar archivos de sistema.
Autopsy
Autopsy Forensic Browser, es una interfaz gráfica para la herramienta de análisis forense TSK.
Hace posible el análisis de una imagen obtenida de la máquina víctima a nivel de archivo bloques
e inodo. Autopsy y TSK juntas proveen muchas de las características de herramientas
comerciales de análisis forense para sistemas de archivos Windows y Unix. Autopsy es basado en
HTML, cuenta con un administrador de archivos que muestra los detalles de archivos borrados.
Para la instalación de Autpsy es necesario haber hecho antes la instalación de TSK pues lo que
hace es proporcionar una interfaz gráfica para utilizar las herramientas de TSK. También es
necesario indicarle el directorio donde se concentrará la información de los casos que se manejen.
Una vez instalado se aplica el siguiente comando:
#./autopsy
66
Este comando correrá un proceso y deberá permanecer abierto mientras se abre un navegador
HTML con el puerto 9999 del host local. Autopsy puede escuchar solicitudes de cualquier puerto,
por lo que el usuario puede conectarse desde cualquier otro sistema (Windows o Linux) para
operar con Autopsy utilizando un navegador.
La siguiente pantalla muestra el menú inicial, donde podemos ir documentando y analizando cada
caso:
Fig. 3.1 Autposy inicio
A continuación se le indica a Autpsy la creación de un nuevo caso:
Fig. 3.2 Autopsy nuevo caso

67
3.2.2.4 LIVE CD
BIATCHUX BOOTEABLE CD FORENSIC TOOLKIT
Es un CDROM booteable con una distribución portable que provee un ambiente inmediato para
realizar análisis forense, respuesta a incidentes, recuperación de datos, escaneo de virus.
Provee las herramientas necesarias para un análisis forense en vivo, solo montando el CD ROM,
es posible utilizarlos en SO win32, sparc Solaris y x86 linux, los binarios estáticos están
disponibles en /statbins [37].
Las últimas versiones cambiaron al nombre de FIRE
FIRE (Forensic and Incident Response Environment)
Es un CD-ROM booteable que contiene una distribución de Linux con herramientas de

seguridad útiles y un menú de sistema fácil de usar. Es creado y mantenido por William Salusky
[38]. Permite recolectar datos de un host comprometido para iniciar un análisis forense, provee las
herramientas necesarias para responder a un incidente de seguridad utilizando binarios estáticos
confiables de diferentes sistemas operativos como Linux, Solaris y Win32, puede recuperar datos
de particiones perdidas, realizar una verificación de virus y de discos duros en un ambiente
limpio y realizar pruebas de penetración y vulnerabilidades.
FIRE puede ser inicializado en un ambiente de ventanas (X-Windows) o con modo consola.
Requiere un procesador Intel x86 con por lo menos 48MB de RAM. Algunas de las herramientas
que son incluidas son nessus, nmap, hping2, ethereal, snort, tcpdump, ettercap, dsniff, airsnort,
chkrootkit, F-Prot, tct, tctutils, autopsy, testdisk, fdisk,, SSH (client and Server), VNC (client and
server) y perl.
68
Menú de utilidades:
Después de bootear con el CD, se despliega un menú de utilidades, mostrando las siguientes
opciones:
• Start-Here Configuración básica, red, DHCP, Nombre del servidor, etc.

• Virus Scan Realiza un escaneo de virus, puede actualizar firmas de red o desde un
floppy
• Forensics MounDrvsRO/UnMountDrvs que monta y desmonta las particiones
GetWin32Reg que busca los registros Win32 de la máquina local
GetUnixAuth que busca archivos de autenticación de la máquina local
Graphicimgs que busca imágenes
Mac-robber corre en los sistemas de archivos montados
ObtainDrvImg crea imágenes para almacenar
AutopsySetup inicia Autopsy
Si necesitamos utilizar un shell de comandos, podemos utilizar las teclas ALT-F1, ALT-F2, etc.
Con el menú de utilidades podemos montar todas las particiones, pero es importante también
desmontarlas una vez que se haya terminado de utilizarlas. El password de root es firefire.
El CD contiene varios binarios ligados estáticamente que pueden ser utilizados para recolección
de información y análisis forense en un sistema vivo.
KNOPPIX
Es un DVD o CD de inicialización (booteo) con una colección de software GNU/Linux,

detección de hardware automática y soporte para varias tarjetas gráficas y de sonido, SCSI y
USB. Es utilizado como un Linux de escritorio, CD educacional, sistema de respuesta o utilizado
como una plataforma de demostración para software comercial. Debido a la descompresión “on-
the-fly” el CD puede llegar a tener arriba de 2GB de software instalado en el.
69
El software instalado es: Linux-Kernel 2.6.x, KDE V3.x, K Office y Konqueror, X Multimedia
System, programas de manipulación de imágenes GNU, herramientas de seguridad y análisis para
administradores de red, OpenOffice [39].
PENGUIN SLEUTH
CD de booteo para Forensia basado en Knoppix [40]. Las herramientas de seguridad y Forensia
que tiene instaladas se muestran en la tabla 3.11.
Tabla 3.11 Herramientas de seguridad y Forensia para Linux
Herramienta Descripción
Sleuth Kit Herramienta de Forensia
Autopsy Parte de Sleuth Kit
Foremost Herramienta para recuperar archivos utilizando sus cabeceras (headers) o parte final del
archivo (footers) – foremost.sourceforge.net
Glimpse Herramienta para realizar búsquedas rápidas a través de sistemas de archivos completos –
www.webglimpse.net
Wipe Utilería en línea de comandos para borrado seguro – wipe.sourceforge.net
Dcfldd Convierte y copia archivos, es una herramienta similar a dd.
Etherape Monitor de red gráfico – etherape.sourceforge.net
Fenris Herramienta de análisis de trayectorias. “Tracer “ multipropósito

razor.bindview.xom/tools/fenris/
Honeyd Demonio honeypot. Crea hosts virtuales una red especificada.
www.citi.umich.edu/u/provos/honeyd
Snort Sistema de detección de intrusos – www.snort.org
Dsniff Sniffer de passwords – www.monkey.org/~dugsong/dsniff/
John The Herramienta de crackeo de password. Para llamarla ejecutamos “john”

Ripper www.openwall.com/john/
Nikto Herramienta para encontrar archivos web de default y examinar servidores Web y CGI.
Ejecutar sobre la línea de comandos. – www.cirt.net/code/nikto.shtml
Nbtscan Herramienta en línea de comandos que escanea por información NETBIOS –
www.unixwiz.net/tools/nbtscan.html
Ngrep Función grep en línea de comandos por red – www.packetfactory.net/projects/ngrep
70
Herramienta Descripción
Nemesis Inyector de paquetes de red en línea de comandos. Sus ejecutables se encuentran en el

directorio /KNOPPIX/usr/sbin/ nemesis-arp, nemesis-icmp, nemesis-rip, etc. -
www.packetfactory.net/Projects/nemesis
Fragroute Herramienta de pruebas de intrusión de red. Intercepta, modifica y reescribe tráfico de
salida – monkey.org/~dugsong/fragroute/
Fping Utilería en línea de comandos para múltiples “pings” – www.fping.com
TCPtraceroute Traza la ruta “traceroute” de paquetes TCP - michael.toren.net/code/tcptraceroute/
Tcpreplay Utilería en línea de comandos que reenvía paquetes de archivos capturados –

tcpreplay.sourceforge.net
Nessus Cliente del escaner de seguridad de red, el servidor está a cargo del atacante –
www.nesus.org
Ethereal Analizador de red gráfico –www.ethereal.com
Netcat Herramienta en línea de comandos para leer y escribir sobre red –

www.atstake.com/research/tools/network_utilities/
Tcpdump Herramienta en línea de comandos que descarga tráfico de red –www.tcpdump.org/
Hping2 Envío de paquetes TCP/IP arbitrarios sobre hosts en red – www.hping.org
Ettercap Sniffer multipropósito para LANs switcheadas – ettercap.sourceforge.net
Openssh Utilería de conexión segura remota – www.openssh.com
Kismet Sniffer de redes inalámbricas – www.kismetwireless.net
Airsnort Herramienta de intrusión de red inalámbrica – airsnort.shmoo.com
Gpg Utilerías de cifrado y firmas – www.gnupg.org
Openssl Utilería de conexión segura remota – www.openssl.org
Lsof Utilería en línea de comandos que lista los archivos abiertos
Hunt Herramienta de auditoría de seguridad lin.fsid.cvut.cz/~kra/index.html
Stunnel Paquete de conexión con SSL – stunnel.mirt.net
Arpwatch Monitor ethernet en línea de comandos
Dig Herramienta en línea de comandos para hacer peticiones a servidores de nombres

Chkrootkit Busca por rootkits – www.chrootkit.org
Estos se encuentran en el menú de inicio en las secciones de “Internet” y “System”

71
Por default el usuario con el que se bootea es knoppix, se puede utilizar un shell y convertirse en
root para realizar ciertas tareas, pero en caso de necesitar root en todo el ambiente, se necesita
indicar en el prompt de boot : knoppix 2 y después startx.
SMART
Es un CD con distribución de Linux diseñado para Respuesta a Incidentes investigación

Forenses, creado por la empresa ASR Data [41].
3.2.2.5 Herramientas varias
La tabla 3.12 muestra más herramientas de utilidad para el proceso de recolección de datos que
son disponibles en Internet:
Tabla 3.12 Herramientas varias Linux
Utilería Función
md5deep Md5s recursivo, se puede obtener de la siguiente dirección:

md5deep.sourceforge.net
fatback Archivo de recuperación de sistemas de archivos FAT

Sourceforge.net/projects/biatchux
stegdetect Detecta clases de esteganografía en imágenes

www.outguess.org
galleta IE cookie parser

www.foundstone.com/
pasco IE Activity Parser
www.openforensics,org
libpst Convierte archivos de Outlook y Outlook Express a un formato mbox de Linux
Sourceforge.net/projects/ol2mbox
flag (forensic and long www.dsd.goc.au/software/flag
analysis gui)
sleauthkit/autopsy Casos de estudio: www.sleuthkit.org/case/index.php
chkrootkit Contiene una base de datos de los rootkits mas populares para saber si nuestro
equipo está infectado:
#chkrootkit –r /devicename
72
Utilería Función
www.chkrootkit.org
carbonite www.foundstone.com
smart CD con distribución de linux diseñado para Forensia y Respuesta a incidentes

www.asrdata2.com
ethereal Analizador de protocolos de red. Corre en plataformas Unix, Linux y Windows.
Ethereal es una herramienta utilizada para obtener información de la red, esta
herramienta nos ayuda a procesar y desplegar paquetes completos capturados
por tcpdump. http://www.ethereal.com/
dio (mission critical La utilería dio desarrollada por Mission Critical Linux como open source puede
linux) generar lecturas y/o escrituras a un dispositivo crudo (raw device), a un archivo
o a memoria. Soporta archivos grandes y tamaños de bloque variable
http://public.planetmirror.com/pub/mclx/oss/ . Es un comando similar a dd .
pdd. Es una herramienta basada en windows, que realiza imágenes de memoria y
adquisición de datos. Fue escrita por Joes Grand, esta disponible la versión 1.10
de marzo 2002.
pdzap Es una pequeña aplicación que cuando es colocada en un teléfono celular P800
de SonyEricsson, permite obtener imágenes de los dispositivos flash a un stick
de memoria.
maresware El software comercial para cómputo forense tiene un precio de $325 dólares.
La empresa ofrece capacitación.
<http://www.maresware.com/>
kstat Detectar módulos de rootkit

http://www.s0ftpj.org/en/site.html
tripwire Es una herramienta que verifica la integridad de los sistemas. Puede funcionar
como detector de intrusos. http://sourceforge.net/projects/tripwire/
tcp-wrapper Servicio que verifica el origen de las conexiones con su base de datos
/etc/hosts.allow y /etc/hosts.deny. Provee un control de acceso basado en la
fuente y destino de la conexión y el registro de las conexiones exitosas o no. El
programa de implementación de tcp-wrapper es tcpd ubicado en /usr/sbin
http://www.iec.csic.es/criptonomicon/linux/tcpwrapper.html
3.3 ANÁLISIS COMPARATIVO DE LAS HERRAMIENTAS
Hay que hacer notar que las herramientas descritas no son las únicas, existen muchas más, pero
es cuestión de cada investigador el encontrar la herramienta con la que mejor se adapte.
Una vez conocidas las herramientas con las que podemos disponer, podemos hacer un análisis del
uso de las herramientas para investigación forense. Para nuestro análisis dividiremos las
herramientas en dos grupos:
• Herramientas comerciales y libres

73
• Herramientas administrativas y forenses
Herramientas comerciales y libres

Las herramientas comerciales independientemente del sistema operativo que manejen se obtiene
al pagar los derechos por utilizar el software, las herramientas libres se obtienen sin pago alguno
a través de Internet, estas por lo regular corren en SO Linux.
Las herramientas administrativas y forenses

Las herramientas administrativas son las que el SO trae consigo y no se tienen que descargar de
ningún sitio, las herramientas forenses son herramientas especializadas que puede ser comerciales
o libres, en nuestro caso solo utilizamos las herramientas libres.
Comparación de herramientas comerciales con respecto a las herramientas libres
Lo bueno de utilizar Linux para Forensia es que la mayoría de las herramientas son libres, el
ambiente es flexible y cuando las herramientas son usadas apropiadamente, la evidencia puede
ser relevante para levantar cargos al culpable.
La limitación es que como la mayoría de las herramientas son libres, no se tiene soporte técnico y
no se puede llamar al autor a una corte si es necesario, lo cual permite a la defensa recorrer el
código en busca de errores “bugs” y poder descartar la información obtenida por la herramienta
en cuestión. Otra limitación es que no tienen todas las características como los paquetes
comerciales y son más complicadas de usar que las herramientas comerciales.
Por otra parte, las herramientas comerciales tienen todo el respaldo de la empresa o autor que lo
patrocina, pero debemos pagar el precio que marca y las posibles actualizaciones para contar con
la garantía de dicho producto.
Comparación de herramientas forenses con respecto a las herramientas administrativas
Las herramientas administrativas son de gran utilidad para el administrador del sistema nos dan
información fácil y rápidamente, pero no están diseñadas para la recolección y análisis forense
74
En el caso de utilizar las herramientas forenses con respecto a las herramientas administrativas, la
razón por lo que es preferible usar las herramientas forenses es que la mayoría de los sistemas no
pueden ser simplemente desmantelados, los datos crudos (raw data) son demasiado voluminosos
y no es fácil manejarlos. Las herramientas forenses como TCT contienen programas de captura y
de análisis que permiten al investigador entender como operan los sistemas y como defenderse en
incidentes de seguridad futuros.
Para trabajar con las herramientas forenses se necesita mucha práctica para entender cómo
funciona el software y saber interpretar bien los resultados. La recopilación y análisis de
información los crea en paquete sin tener una amplia flexibilidad de lo que queremos y no
queremos respaldar. Las herramientas TSK y Autopsy hacen el análisis sobre imágenes de disco
del sistema bajo análisis y no propiamente sobre la información volátil que es donde nos estamos
enfocando en este trabajo.
Las herramientas de volcado de memoria
Las herramientas de volcado de memoria son software desarrollado para obtener información
después de una falla de sistema que cause su caída, debe ser instalado y configurado previamente
en el sistema, por lo que para este tipo de software se necesita que el usuario esté familiarizado
con el equipo ya que se configura y reconstruye el kernel.
Beneficios de contar un CD LIVE
Utilizar los CD LIVE o CD con sistema operativo y herramientas de seguridad integrados son de
gran utilidad ya que contienen lo necesario para una respuesta rápida, pueden contener un sistema
de menús que hace más fácil su uso, ofrecen una gran cantidad de aplicaciones y detección de
hardware, con las herramientas relevantes para expertos en seguridad, pero es conveniente que el
investigador forense cree su propio conjunto de herramientas que va ir complementando en cada
caso que resuelva.
75
CAPITULO 4
METODOLOGÍA PARA LA
RECOLECCIÓN DE INFORMACIÓN
Y CASOS
76
4. METODOLOGÍA PARA LA RECOLECCIÓN DE

INFORMACIÓN Y CASOS.
En este capítulo se presentará una metodología general de recolección de información volátil y

memoria en un sistema vivo en base a la volatilidad de los datos, esta metodología se aplicará a
cinco casos que se dividirán en el tipo de acceso al sistema sospechoso, es decir si está conectado
en red o se trabajará en forma local y sobre las plataformas más comunes Windows y Linux.
Dentro de cada caso se explicará a detalle la obtención de datos utilizando diversas herramientas
y comandos del sistema operativo y forense, con el fin de capturar datos volátiles y de la
memoria RAM antes de quitar la energía del equipo bajo análisis.
En la figura 4.1 se muestra cada uno de los casos con el estado del sistema “vivo”, así como el
estado del sistema cuando no tiene energía de alimentación o “muerto”, pero esta última parte se
verá con detalle en el siguiente capítulo.
VIVO Estado MUERTO

del
sistema
Por red Tipo de Local

Recuperación de datos
acceso al
con métodos físicos
sistema
(ejemplos)
CASO 2: CASO 4: CASO 1: CASO 3: CASO 5:

Windows Linux Windows Linux Grave_robber
Linux
Fig. 4.1 Casos a considerar para la presente investigación

77
4.1 ESTABLECIENDO UN PROCEDIMIENTO “GENERAL” PARA

APLICAR EN CADA CASO.
Dentro de los pasos forenses debemos obtener, guardar y seguir la pista de información acerca de
una posible actividad criminal, esto significa que se debe tener mucha precaución para recolectar
en forma exacta y confiable los datos para hacerlos seguros.
En general la mejor práctica para recolectar evidencia es usar herramientas confiables, salvar
datos en medios removibles y asegurar la autenticidad de los datos. Considerando que nada
acerca del sistema puede ser confiable, debemos tratar cada equipo como si estuviera
comprometido, tuviera “rootkits” instalados o pudiera estar monitoreado por atacantes.
De acuerdo a Kevin Mandia y Chris Prosise en su libro “Incident Response” [36], para la
recolección de datos volátiles es más importante la respuesta inicial que el análisis técnico
posterior. Al dar de baja el sistema bajo investigación se puede llegar a destruir evidencia crítica,
esto debido a que los atacantes han aprendido a tomar ventajas de los medios de almacenamiento
volátil.
Una de las reglas básicas del cómputo forense es que no debemos trabajar con los datos
originales, pero para capturar la información volátil quizá sea la única forma de poder obtenerla.
Por lo que si vamos a trabajar con un sistema vivo debemos recordar que para cada decisión y
paso a tomar, el investigador deberá tener razones sólidas de cada acción realizada y ser
debidamente documentada.
Si sabemos que el examinar datos volátiles los altera, consideraremos que el sistema se
modificará por lo que deberemos saber específicamente qué y porqué se modificó, para lo cual
deberemos conocer muy bien las herramientas que utilizaremos y saber que archivos se
modifican al utilizarlas, también deberemos tomar un registro de tiempo de todos los archivos del
sistema antes y después de proceder a la captura. Con esto sabremos qué estaremos modificando
en el momento de la recolección.
78
Independientemente del sistema operativo con el que cuente el equipo bajo análisis y de acuerdo
a lo explicado en el capítulo 2, los siguientes datos son perdidos una vez que el sistema es dado
de baja:
• Los registros del procesador y el contenido del cache.

• El contenido de la memoria.
• El estado de las conexiones de red.
• El estado de los procesos que están corriendo en ese momento.
El contenido en los registros del procesador y su cache es casi imposible obtenerlos debido a que
el simple intento de capturarlos los alteraría, por lo que no intentaremos capturar esta
información.
En la memoria también existen áreas principales que pueden ser alteradas, algunas páginas en el
área de memoria serán modificadas al correr los comandos de nuestro conjunto de herramientas y
cuando hagamos una clonación o descarga de ésta.
Obtener el estado de las conexiones de red y procesos corriendo tiene un impacto menor en el
sistema. La información es generalmente almacenada en tablas residentes en la memoria del
kernel y la simple lectura de los datos no los modificará.
Todo esto nos lleva a la conclusión de que antes de revisar un sistema “vivo” debemos contar
con una metodología de captura.
A continuación se propone una metodología “general” que contiene los pasos para obtener los
datos volátiles más críticos:
(1) Establecer una línea de comandos segura (shell)
En este paso se realizará una conexión donde los comandos y programas que aplicaremos sean
confiables.
79
(2) Realizar un registro de tiempo del sistema (time stamp)
En este paso iniciamos la obtención de datos utilizando herramientas que nos permitan obtener el
tiempo y fecha del sistema y obtener un registro de tiempo de todos los archivos y directorios
(timestamp).
(3) Obtener los datos y el estado del sistema
En este paso empezaremos a recolectar la información, realizando las siguientes acciones que a
continuación se describen:
a.- Obtener los datos del sistema (nombre, dirección IP, etc.)
b.- Determinar los puertos abiertos
c.- Listar los procesos corriendo (sockets, servicios, etc.)
d.- Respuesta inicial profunda (bitácoras), en el caso de contar con el tiempo necesario.
(4) Determinar quien está dentro del sistema y quienes se han conectado recientemente
En este paso tratamos de determinar las conexiones actuales y recientes al sistema bajo análisis
además de la información de red contenida en el sistema.
(5) Realizar un segundo registro de tiempo
En este paso realizaremos nuevamente un registro de tiempo en los archivos y directorios para
que podamos compararlo con el primer registro y sepamos los cambios que hicimos durante
nuestra recolección de información.
(6) Hacer una copia de la memoria RAM
Finalmente haremos una imagen del sistema de memoria RAM, para después analizarlo con
mayor tiempo y no durante la respuesta inicial.
80
(7) Documentar y transferir a un medio seguro
Una vez obtenida la información deberemos trasferirla y almacenarla en un lugar seguro.

Podremos realizar estos pasos rápidamente si los concentramos en un script. Finalmente todos
estos pasos los tenemos que documentar
Los pasos establecidos en la metodología pueden cambiar de orden, dependiendo de las

circunstancias de la investigación, del sistema operativo, versiones, y también del objetivo de la
investigación ya que puede ser buscar al culpable más que recuperar la información.
Equipo de herramientas
Ya con la metodología establecida, el primer paso es contar con un buen conjunto de

herramientas, que ya hemos conformado con los comandos y software explicados en el capítulo
anterior, que en general deberá incluir:
• Un programa para examinar procesos.

• Programas para examinar el estado del sistema
• Un programa para realizar copias bit a bit
• Programas para generar checksum y firmas
• Programas para generar imágenes core
• Scripts para automatizar la recolección de evidencia.
Contar con el password de acceso
Otra situación a la que se enfrenta el investigador forense es contar con un password de acceso al
sistema, debido a que para recuperar el password de acceso a un sistema muchas veces es
necesario reiniciarlo, o que para tratar de adivinarlo, el proceso lleva tiempo, hemos tomado la
decisión de que en caso de no contar con el password de acceso procederemos a apagar el equipo
sin recolectar la información volátil, debido a que al tratar de obtener el password de acceso
perderemos casi toda la información volátil que estamos buscando, por lo que en los casos
propuestos se considera que se tiene un password de acceso al sistema.
81
4.2 APLICANDO EL PROCEDIMIENTO DE RECOLECCIÓN: CASO 1

WINDOWS CON ACCESO LOCAL
Después de haber establecido la metodología general donde el objetivo es recolectar información

volátil aplicaremos esos pasos al primer caso.
Las condiciones bajo las cuales se encuentra el equipo bajo sospecha son; el estado del sistema
será “vivo”, es decir el equipo sospechoso estará conectado a la energía y corriendo sus procesos
en forma “normal”, el sistema operativo al que se enfrentará el investigador será Windows 2000
y se contará con el password de acceso.
VIVO Estado MUERTO

del
sistema

acceso al
sistema
(ejemplos)
CASO 1:
CASO 2: CASO 4: CASO 3: CASO 5:
Linux
Fig. 4.2 Caso 1: Aplicación de metodología con Windows en forma local
Tal como consta la figura 4.2 el procedimiento se aplicará a un sistema vivo donde el
investigador forense se conectará directamente en la consola del equipo sospechoso estableciendo
una conexión segura en forma local, una vez establecida esta comunicación el investigador
aplicará los comandos de su conjunto de herramientas a través de esta conexión.
Los programas que utilizará en esta captura no serán instalados en el sistema bajo análisis,
correrán desde una fuente de archivos “confiables” que puede ser un floppy o un drive USB, estas
herramientas correrán sobre el sistema operativo en cuestión y finalmente los resultados
obtenidos se almacenará en un medio confiable (floppy o drive USB).
82
PASO 1: ESTABLECER UNA LÍNEA DE COMANDOS SEGURA (shell)
En este primer paso vamos a hacer disponible el conjunto de herramientas montando el medio en
el sistema, después procedemos a establecer una línea de comandos segura ejecutando la
herramienta “cmd.exe” confiable. Se debe tener cuidado de que el atacante haya puesto algunas
trampas para hacer fracasar la captura de datos, por ejemplo se puede presentar la situación en
que al ejecutar el comando cmd.exe en la máquina victima se active un proceso aplicando el
comando del *.* en el directorio \winnt\System32, haciendo el sistema virtualmente inoperable.
Por lo que ejecutaremos el comando “cmd.exe” de manera confiable, direccionándolo al drive
donde se almacenan nuestras herramientas, en este caso será la letra “a:”, como se muestra en la
siguiente ventana:
Fig. 4.3 cmd.exe
PASO 2: REALIZAR UN REGISTRO DE TIEMPO DEL SISTEMA (TIMESTAMP)
Después de crear un “shell” seguro, se captura la hora (time) y fecha (date) del sistema con las
herramientas almacenadas en nuestro medio seguro (drive a:), la opción –t de los comandos
obliga a que el comando no quede en espera.
a:\toolkit>date /t
The current date is: Thu 08/18/2005
a:\toolkit>time /T
The current time is: 16:58:09.14
También podemos utilizar el comando “now” del resource kit, que despliega “date” y “time” en
un solo comando:
A:\toolkit\now
Fri Apr 07 17:53:09 2006
Después de obtener el tiempo y fecha del sistema hacemos un registro de tiempo de todos los
archivos del sistema, utilizando el comando “dir” para obtener un listado de todos los archivos en
el sistema bajo análisis, tiempos de acceso, modificación y creación.
83
Utilizando el comando “dir”, se puede hacer un despliegue por propietario (/Q) y tiempo de
último acceso al archivo (/TA) de todos los archivos del sistema (/S), esto con el fin de marcar un
sello de tiempo (time stamp):
a:\toolkit>dir c:\ /Q /S /TA
Volume in drive C has no label.

Volume Serial Number is ECD3-2160
Directory of c:\
08/16/2005 05:43p 36,112 BUILTIN\Administrators Auditpol.exe

08/16/2005 05:43p 24,848 BUILTIN\Administrators dh.exe
08/16/2005 05:43p 9,488 BUILTIN\Administrators dhcmp.exe
08/18/2005 05:51p <DIR> BUILTIN\Administrators Documents and Settings
08/16/2005 05:43p 6,928 BUILTIN\Administrators drivers.exe
08/17/2005 12:34p 114,688 BUILTIN\Administrators Fport.exe
08/18/2005 04:29p <DIR> BUILTIN\Administrators Inetpub
08/16/2005 05:43p 53,248 BUILTIN\Administrators listdlls.exe
08/18/2005 04:29p <DIR> BUILTIN\Administrators nmap
08/16/2005 05:43p 208,948 BUILTIN\Administrators NTLast.exe
08/18/2005 04:29p <DIR> BUILTIN\Administrators Program Files
08/18/2005 04:29p <DIR> BUILTIN\Administrators programas
08/17/2005 05:26p 25,252,224 LUNA\alicia_user resp.reg
08/18/2005 04:29p <DIR> BUILTIN\Administrators temp
08/18/2005 04:29p <DIR> BUILTIN\Administrators toolkit
08/18/2005 04:29p <DIR> BUILTIN\Administrators WINNT
8 File(s) 25,706,484 bytes
Directory of c:\Documents and Settings
08/18/2005 05:51p <DIR> BUILTIN\Administrators .

08/18/2005 05:51p <DIR> BUILTIN\Administrators ..
08/18/2005 05:51p <DIR> BUILTIN\Administrators Administrator
08/17/2005 04:42p <DIR> BUILTIN\Administrators alicia_user
08/18/2005 01:58p <DIR> BUILTIN\Administrators All Users
0 File(s) 0 bytes
Directory of c:\Documents and Settings\Administrator

.
.
.
El siguiente comando provee un listado recursivo de los tiempos de acceso al drive C

a:\toolkit>dir /t:a /a /s /o:d c
El siguiente comando provee un listado recursivo de los tiempos de modificación del drive D
a:\toolkit>dir /t:w /a /s /o:d d
El siguiente comando provee un listado recursivo de los tiempos de creación del drive E
a:\toolkit>dir /t:c /a /s /o:d e
Para obtener los listados recursivos de los tiempos de acceso, modificación y creación también
podemos utilizar el comando “ls.exe” incluido en el CD-live de FIRE.
a:\toolkit>ls –alRu para tiempos de acceso

a:\toolkit>ls –alRc para tiempos de modificación
a:\toolkit>ls –alR para tiempos de creación
84
PASO 3: DETERMINAR LOS DATOS Y EL ESTADO DEL SISTEMA
Para determinar el estado del sistema realizaremos las siguientes acciones:
1. Obtener los datos del sistema

2. Determinar los puertos abiertos
3. Listar todos los procesos corriendo
4. Respuesta inicial mas profunda
o Obtener la bitácora de eventos durante una respuesta viva
o Revisar el “registry” durante la respuesta viva
Acción 1: Obtener los datos del sistema
Para obtener los datos del sistema verificamos el nombre del equipo con el comando “hostname”:
a:\toolkit>hostname
comprometido
A continuación obtenemos la identificación de red del equipo con el comando “ipconfig” como
se muestra a continuación:
a:\toolkit>ipconfig /all
Windows 2000 IP Configuration

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :

IP Address. . . . . . . . . . . . : 172.29.69.83
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.29.69.254
Acción 2: Determinar los puertos abiertos
Para enumerar los puertos por los cuales los procesos están escuchando, utilizamos la
herramienta “fport”, esta herramienta nos muestra los puertos que están actualmente escuchando,
pero no nos dice que puertos están sirviendo a usuarios remotos en el momento. Para esto
utilizamos el comando de Windows “netstat” que enumera los puertos escuchando y además las
conexiones a esos puertos:
a:\toolkit>fport
FPort v2.0 - TCP/IP Process to Port Mapper

85
Copyright 2000 by Foundstone, Inc.

http://www.foundstone.com
Pid Process Port Proto Path

1052 inetinfo -> 25 TCP C:\WINNT\System32\inetsrv\inetinfo.exe
436 svchost -> 135 TCP C:\WINNT\system32\svchost.exe
8 System -> 139 TCP
8 System -> 445 TCP
492 msdtc -> 1025 TCP C:\WINNT\System32\msdtc.exe
880 MSTask -> 1026 TCP C:\WINNT\system32\MSTask.exe
8 System -> 1030 TCP
436 svchost -> 135 UDP C:\WINNT\system32\svchost.exe

8 System -> 137 UDP
8 System -> 138 UDP
8 System -> 445 UDP
228 lsass -> 500 UDP C:\WINNT\system32\lsass.exe
1052 inetinfo -> 1029 UDP C:\WINNT\System32\inetsrv\inetinfo.exe
600 svchost -> 1031 UDP C:\WINNT\System32\svchost.exe
8 System -> 1701 UDP
A continuación se muestra la aplicación de la herramienta ”netstat” que es útil para grabar datos
volátiles como conexiones actuales y las que han terminado.
a:\toolkit>netstat -an
Active Connections
Proto Local Address Foreign Address State

TCP 0.0.0.0:25 0.0.0.0:0 LISTENING
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1028 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1030 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1050 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1723 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2087 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3372 0.0.0.0:0 LISTENING
TCP 172.29.69.83:139 0.0.0.0:0 LISTENING
TCP 172.29.69.83:139 172.29.69.69:3415 ESTABLISHED
UDP 0.0.0.0:135 *:*
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:1029 *:*
UDP 0.0.0.0:1033 *:*
UDP 0.0.0.0:1645 *:*
UDP 0.0.0.0:1646 *:*
UDP 0.0.0.0:1701 *:*
UDP 0.0.0.0:1812 *:*
UDP 0.0.0.0:1813 *:*
UDP 0.0.0.0:3456 *:*
UDP 127.0.0.1:1031 *:*
UDP 127.0.0.1:1032 *:*
UDP 172.29.69.83:137 *:*
86
UDP 172.29.69.83:138 *:*

UDP 172.29.69.83:500 *:*
En este caso son de particular interés las conexiones externas (172.29.69.69) más que las locales
(127.0.0.1 o 172.29.69.83). Con “fport” se obtienen los procesos sospechosos esperando una
conexión y con “netstat” se obtiene las conexiones actuales a ese proceso. El comando “tcpvcon”
es similar a la utilería “netstat” de Windows, por lo que se puede utilizar en vez de netstat.
a:\toolkit>tcpvcon -a
La opción –a muestra todas las conexiones TCP y UDP establecidas
Acción 3: Listando todos los procesos corriendo
Antes de apagar el equipo bajo análisis es importante grabar todos los procesos que están
corriendo. Esta información no puede ser obtenida si se desconecta el cordón de energía. Cuando
un proceso se está ejecutando en Windows se crea un objeto kernel y un espacio de direcciones
conteniendo el código ejecutable. El objeto kernel creado es usado por el sistema operativo para
manejar el proceso y contener información estadística acerca del proceso.
Para obtener la lista de procesos que está corriendo en el sistema podemos utilizar la herramienta
“pslist”, como se muestra a continuación:
a:\toolkit>pslist
PsList 1.26 - Process Information Lister

Copyright (C) 1999-2004 Mark Russinovich
Sysinternals - www.sysinternals.com
Process information for LUNA:
Name Pid Pri Thd Hnd Priv CPU Time Elapsed Time
Idle 0 0 1 0 0 7:56:24.963 7:59:01.778
System 8 8 44 208 24 0:00:10.304 7:59:01.778
SMSS 144 11 6 33 1096 0:00:00.560 7:59:01.778
CSRSS 168 13 10 469 1580 0:00:05.778 7:58:50.672
WINLOGON 188 13 18 434 6888 0:00:03.024 7:58:49.330
SERVICES 216 9 37 550 3192 0:00:04.045 7:58:47.267
LSASS 228 9 21 297 2916 0:00:07.160 7:58:47.237
svchost 436 8 8 243 1572 0:00:00.560 7:58:42.100
spoolsv 464 8 11 134 2716 0:00:00.380 7:58:41.088
msdtc 492 8 21 198 1968 0:00:00.360 7:58:40.978
svchost 600 8 29 1085 9612 0:00:04.606 7:58:38.715
LLSSRV 628 9 10 79 796 0:00:00.070 7:58:37.744
FrameworkServic 660 8 10 194 2952 0:00:01.131 7:58:37.423
Mcshield 732 13 20 204 18308 0:00:55.369 7:58:35.801
VsTskMgr 748 8 11 132 5112 0:00:00.230 7:58:35.480
naPrdMgr 792 8 4 108 4560 0:00:00.140 7:58:34.068
regsvc 848 8 2 30 288 0:00:00.050 7:58:27.779
mstask 880 8 6 114 1136 0:00:00.250 7:58:25.656
userdump 924 8 4 47 332 0:00:00.030 7:58:19.608
WinMgmt 952 8 4 115 1276 0:00:10.324 7:58:17.865
svchost 1000 8 6 208 5924 0:00:03.745 7:58:12.187
dfssvc 1032 8 2 36 484 0:00:00.060 7:58:10.755
87
inetinfo 1052 8 27 590 6512 0:00:01.251 7:58:08.782

svchost 1360 8 11 168 1580 0:00:00.250 7:57:13.753
explorer 708 8 15 351 8108 0:00:35.931 5:25:09.453
shstat 1600 8 6 63 4604 0:00:00.240 5:24:45.608
UpdaterUI 1540 8 4 96 1008 0:00:00.240 5:24:41.132
internat 1468 8 1 27 372 0:00:00.080 5:24:40.611
wuauclt 1040 8 5 101 1572 0:00:00.200 5:23:43.930
CMD 1644 8 1 21 340 0:00:00.110 3:15:59.980
cmd 1008 8 1 23 360 0:00:00.430 1:32:41.026
cmd 980 8 1 21 1432 0:00:00.030 1:21:04.975
CMD 776 8 1 21 312 0:00:00.180 0:51:57.903
pslist 712 13 2 88 736 0:00:00.120 0:00:01.692
nc 512 8 2 74 1064 0:00:00.170 0:00:01.532
Es importante poder identificar la diferencia entre los procesos críticos, normales y procesos no
permitidos. Por ejemplo si “pslist” revela que el proceso EVENTVWR está corriendo, esto
sugiere que alguien está observando las bitácoras. Si se observa el USRMGR, se puede sospechar
que alguien trata de cambiar las políticas de auditoría, borrar o agregar una cuenta de usuario o
cambiar los datos de una cuenta de usuario o password.
Acción 4: Respuesta inicial más profunda
Si es que se cuenta con mayor tiempo se pueden ejecutar los siguientes comandos con el fin de
obtener un poco más de información sobre el sistema vivo, en caso de no contar con mayor
tiempo continuaremos con el siguiente paso de la metodología planteada.
Para obtener una bitácora de los accesos que ha habido al sistema podemos utilizar la herramienta
“Ntlast” que nos permite monitorear las entradas (“logons”) exitosas y fallidas al sistema y si la
auditoría de entradas/salidas (“logon/logoff”) fue activada o desactivada en el sistema. “Ntlast”
con la opción –r lista todas las entradas exitosas de un sistema remoto y la opción –f lista los
intentos fallidos.
a:\toolkit>ntlast
Administrator LUNA LUNA Thu Aug 18 12:37:52pm 2005

Administrator LUNA LUNA Wed Aug 17 06:26:26pm 2005
alicia_user LUNA LUNA Wed Aug 17 02:09:24pm 2005
Administrator LUNA LUNA Wed Aug 17 12:14:31pm 2005
- End Of File -
Nota: Este comando da información solo si las políticas de auditoría están habilitadas en el
equipo bajo análisis.
88
Obteniendo la bitácora de eventos durante una respuesta viva

Según Kevin Mandia [36] existen dos fuentes importantes de información en Win2000 y NT: la
bitácora de eventos y el Registry.
El comando “dumpel” se puede utilizar para obtener las bitácoras y copiarlas a un archivo de
texto, a continuación se muestra la captura de los eventos de seguridad, aplicación y sistema:
dumpel –l security –t descarga las bitácoras de seguridad

dumpel –l application –t descarga las bitácoras de aplicación.
dumpel –l system –t descarga las bitácoras de sistema.
Ejemplo de aplicación del comando:

a:\toolkit>dumpel –l security –t
8/17/2005 12:14:24 PM 16 2 529 Security NT AUTHORITY\SYSTEM

LUNA atorres LUNA 2 User32 Negotiate LUNA
LUNA MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 administrator LUNA
8/17/2005 12:14:31 PM 8 2 528 Security LUNA\Administrator
LUNA Administrator LUNA (0x0,0x27C7C) 2 User32 Negotiate LUNA
LUNA MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 atorres ATORRES 3221225572
8/17/2005 12:34:08 PM 8 2 538 Security NT AUTHORITY\ANONYMOUS
LOGON LUNA ANONYMOUS LOGON NT AUTHORITY (0x0,0x377B2) 3
LOGON LUNA ANONYMOUS LOGON NT AUTHORITY (0x0,0x37D3A) 3
LOGON LUNA ANONYMOUS LOGON NT AUTHORITY (0x0,0x38345) 3
LOGON LUNA ANONYMOUS LOGON NT AUTHORITY (0x0,0xDBA2) 3
8/18/2005 10:10:27 AM 8 2 538 Security NT AUTHORITY\ANONYMOUS
LOGON LUNA ANONYMOUS LOGON NT AUTHORITY (0x0,0xDD2B) 3
. . . . . . .
. . . . . . .
Capturando el registry durante la respuesta viva
El Registry NT/2000 almacena datos útiles durante la respuesta inicial. Para obtener estos datos
podemos utilizar las herramientas “regedit” o “reg”. Regedit genera un archivo grande y reg
obtiene solo valores específicos que sean de nuestro interés (keys).
a:\toolkit\regedit –e respaldo_registry.reg
a:\toolkit\reg export HKLM respaldo_registry.reg

The operation completed succesfully
:
Para obtener información de los usuarios podemos aplicar la siguiente sintaxis:
reg query “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\REgisteresOwner”
reg query “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon”
Para obtener información del sistema podemos aplicar la siguiente sintaxis:

89
reg query “HKLM\SYSTEM\ControlSet001\Control\ComputerName\Computername”

reg query “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDVersion”
El siguiente es un ejemplo de aplicación del comando “reg”, con la llave para obtener
información de usuarios:
a:>toolkit>reg query “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon”
! REG.EXE VERSION 3.0
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon
AutoRestartShell REG_DWORD 0x1
DefaultDomainName REG_SZ LUNA
DefaultUserName REG_SZ administrator
LegalNoticeCaption REG_SZ
LegalNoticeText REG_SZ
PowerdownAfterShutdown REG_SZ 0
ReportBootOk REG_SZ 1
Shell REG_SZ Explorer.exe
ShutdownWithoutLogon REG_SZ 0
System REG_SZ
Userinit REG_SZ C:\WINNT\system32\userinit.exe,
VmApplet REG_SZ rundll32 shell32,Control_RunDLL "sysdm.cpl"
SfcQuota REG_DWORD 0xffffffff
allocatecdroms REG_SZ 0
allocatedasd REG_SZ 0
allocatefloppies REG_SZ 0
cachedlogonscount REG_SZ 10
passwordexpirywarning REG_DWORD 0xe
scremoveoption REG_SZ 0
DontDisplayLastUserName REG_SZ 0
AppSetup REG_SZ
DebugServerCommand REG_SZ no
SFCDisable REG_DWORD 0x0
ShowLogonOptions REG_DWORD 0x1
AltDefaultUserName REG_SZ administrator
AltDefaultDomainName REG_SZ LUNA
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon\GPExtensions
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon\Notify
PASO 4: DETERMINANDO QUIEN ESTÁ EN EL SISTEMA
El siguiente paso es determinar que cuentas de usuarios tiene conexiones activas al sistema. Para
esto nos ayudaremos con la utilería de PStools “psloggedon”:
a:\toolkit>psloggedon
PsLoggedOn v1.31 - Logon Session Displayer

Users logged on locally:

8/18/2005 12:38:01 PM LUNA\Administrator
Users logged on via resource shares:

8/18/2005 5:02:49 PM (null)\ALICIA_USER
Para determinar quien está conectado al sistema utilizamos “net session”, “arp” y “nbtstat”.
La herramienta “nbtstat” es usada para acceder al cache NetBIOS, permitiéndonos listar las
conexiones recientes, con la opción –c se muestra la información en cache de Netbios
90
a:\toolkit>nbtstat –c
Local Area Connection:

Node IpAddress: [172.29.69.83] Scope Id: []
No names in cache
La herramienta “nbtstat” con la opción –n muestra los nombres de Netbios locales

a:\toolkit>nbtstat –n

NetBIOS Local Name Table
Name Type Status

---------------------------------------------
COMPROMETIDO <00> UNIQUE Registered
FORE <00> GROUP Registered
FORE <1E> GROUP Registered
FORE <1D> UNIQUE Registered
..__MSBROWSE__.<01> GROUP Registered
INet~Services <1C> GROUP Registered
IS~COMPROMETIDO....<00> UNIQUE Registered
La herramienta “nbtstat” con la opción –r lista los nombres resueltos por broadcast vía WINS
a:\toolkit>nbtstat –r
NetBIOS Names Resolution and Registration Statistics

----------------------------------------------------
Resolved By Broadcast = 0
Resolved By Name Server = 2
Registered By Broadcast = 0
Registered By Name Server = 9
La herramienta “nbtstat” con la opción –s lista la tabla de sesiones

a:\toolkit>nbtstat –s
NetBIOS Connection Table
Local Name State In/Out Remote Host Input Output

----------------------------------------------------------------------------
COMPROMETIDO <03> Listening
El comando “net” con la opción “session”, obtiene una lista de sesiones establecidas en el
sistema, como se muestra a continuación.
a:\toolkit>net session
Computer User name Client Type Open Idle time

---------------------------------------------------------------------------------
\\172.29.69.69 ATORRES Windows 2002 Serv 1 02:21:03
El comando “arp” es utilizado para mapear direcciones IP a direcciones físicas MAC con las
cuales el sistema se ha comunicado. Con la opción “–a” se muestra y modifica la tabla de
conversión de direcciones IP a direcciones físicas.
91
a:\toolkit>arp –a
Interface: 172.29.69.83 on Interface 0x1000003

Internet Address Physical Address Type
172.29.69.254 00-20-9c-12-db-b4 dynamic
PASO 5: REALIZAR EL SEGUNDO REGISTRO DE TIEMPO DEL SISTEMA (TIME

STAMP)
Este paso tiene el fin de obtener un segundo registro para que al compararlo con el primero
podamos identificar bien los cambios que hemos hecho en el sistema a la hora de la recolección
de información, para lo cual nos podemos ayudar nuevamente de la herramienta “dir” o “ls”
como en el paso 1:

Directory of c:\

8 File(s) 25,706,484 bytes
. . . .
. . .
. .
PASO 6: REALIZAR UNA COPIA DE LA MEMORIA
Este paso se deberá realizar una vez concluidos los anteriores porque se producirá un volcado de
memoria que modificará el registry y reiniciará el sistema.
Por lo que para forzar al sistema para que cree un archivo “.dmp” cambiamos la configuración
del “registry” con el siguiente comando que utiliza la herramienta “reg.exe”:
a:\>reg ADD HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters /v CrashOnCtrlScroll /t

REG_DWORD /d 0x1
92
Después de haber realizado esta configuración en el “registry” y para poder crear el archivo
dump, será necesario provocar el fallo en la computadora oprimiendo la tecla derecha CTRL y al
mismo tiempo oprimir dos veces la tecla Bloq/despl (ScrollLock). Se pondrá la pantalla azul y se
reiniciará el sistema.
Después de que reinicie la computadora se habrá creado el archivo de descarga o volcado de la

memoria en el directorio del sistema. Por ejemplo c:\WINNT>MEMORY.DMP
PASO 7: DOCUMENTANDO LOS COMANDOS USADOS DURANTE LA RESPUESTA

INICIAL, TRANSFERIR Y ALMACENAR LOS DATOS
Todos los pasos con sus respectivas acciones y herramientas aplicadas son resumidos en la tabla
4.1.
Tabla 4.1 Pasos y acciones realizadas: Caso 1
Pasos Acciones Windows

NT/2000
1 Línea de comandos seguros Hacer disponible el conjunto de herramientas cmd.exe
Establecer un nuevo shell
2 Registro de tiempo Obtener el tiempo y fecha del sistema date, time, now
Time stamp, tiempo de creación de los archivos dir, ls
3 Estado del sistema Nombre del equipo hostname
Información ipconfig
Obtener los puertos abiertos fport
Listar los procesos que corren actualmente pslist
Listar los procesos que abren sockets netstat
Lista las conexiones exitosas y fallidas ntlast
Obtiene las bitácoras y hace la transferencia dumpel
Obtiene valores de interés del registry reg
Descarga todo el registry a un archivo regedit
4 Quien esta en el sistema Conexiones activas psloggedon
Conexiones recientes nbtstat
Sesiones establecidas net session
Tabla de direcciones arp
5 2o. Registro de tiempo Listar archivos y directorios dir, ls
6 Copia de la memoria Volcado de memoria reg y archivos
.dmp
7 Documentación Transferir y almacenar los datos en un lugar script
seguro md5
Identificar y documentar los pasos
93
Todos estos comandos pueden ser incorporados en un programa batch como script y hacer la
captura con mayor velocidad. Para realizarlo creamos un archivo de texto con los comandos
requeridos y le ponemos la extensión bat.
En este caso elaboramos 5 scripts, en el primero se concentran los comandos aplicados y para la
respuesta inicial profunda donde se almacenan las bitácoras y el resultado del “registry”,
elaboramos los 4 script restantes.
La figura 4.4 muestra los scripts elaborados.
Fig. 4.4 Scripts
Después de ejecutarlos aplicamos el comando “md5sum” al archivo generado por el script para
asignarle una identificación de integridad de los datos.
94
Se ejecuta el script “comandos” y se genera el archivo “datos.txt”, al cual se le aplica el comando

“md5sum” generando el archivo “datos.sum” que contiene el identificador de integridad.
a:>toolkit>commandos >> datos.txt

a:>toolkit>md5sum datos.txt >> datos.sum
a:>toolkit>type datos.sum
7122f802e1a087a0b31848f70862c0d1 *datos.txt
Este ejemplo ejecuta el script “copy_reg” que hace una copia del registry, al cual se le realiza el
mismo procedimiento anterior.
a:>toolkit>copy_reg >> copy_reg.txt

a:>toolkit>md5sum copy_reg.txt >> copy_reg.sum
a:>toolkit>type copy_reg.sum
116798d3a85f14acdd5870ee16c4608d *copy_reg.txt
Por último se ejecuta el script “sys_log” que obtiene la bitácora de sistema y al cual se le realiza
el mismo procedimiento anterior.
a:>toolkit>sys_log >> sys_log.txt

a:>toolkit>md5sum sys_log.txt >> sys_log.sum
a:>toolkit>type sys_log.sum
301657924f0263c89caa702e08cc48e7 *sys_log.txt
Ya que es necesario llevar nota de todos los pasos realizados, nos ayudaremos de la tabla 4.1
para registrar los datos importantes como la hora de inicio de la captura, el comando aplicado, si
es confiable o no, la salida del md5sum al archivo de datos y posibles comentarios, como se
muestra en la tabla 4.2.
Tabla 4.2 Documentando: Caso 1
Tiemp Programa Archivo Comando Confiable Salida del Notas

o de BAT generado aplicado md5sum
inicio
SI NO
9:19:20 montaje X 116798d3a
85f14acdd
5870ee16c
4608d
9:22:23 cmd.exe cmd.exe X 301657924
f0263c89c
aa702e08c
c48e7
9:27:22 comandos.bat datos.txt date /t X 7122f802e El archivo
time /t 1a087a0b3 generado es
dir c:\ /Q /S /TA 1848f7086 guardado en
hostname 2c0d1 el medio
ipconfig confiable
fport
netstat -an
pslist
ntlast
95
Confiable
psloggedon
nbtstat -c
nbtstat -n
nbtstat -r
nbtstat -s
net session
arp –a
dir c:\ /Q /S /TA
9:32:20 copy_reg.bat copy_reg. regedit -e X 116798d3a

txt respaldo_registry.re 85f14acdd
g 5870ee16c
4608d
9:35:23 sys_log.bat sys_log.tx dumpel -l system –t X 301657924
t f0263c89c
aa702e08c
c48e7
9:38:18 reg_add.bat memory.d reg ADD X El archivo
mp HKLM\SYSTEM\ generado es
CurrentControlSet\ guardado en
Services\i8042prt\P el directorio
arameters /v de sistema
CrashOnCtrlScroll del equipo
/t REG_DWORD bajo análisis
/d 0x1
La información obtenida, será copiada a un lugar de almacenamiento seguro, a un medio

conectado a la estación de trabajo bajo análisis como una memoria USB o un floppy. También se
puede transferir por red a una estación de trabajo segura con el comando “netcat”. Otra
herramienta útil es contar con una cámara fotográfica para tomar fotografías de todas las
pantallas posibles.
96

WINDOWS CON ACCESO REMOTO
En el segundo caso las condiciones bajo las cuales se encuentra el equipo bajo sospecha son
similares al primer caso, el sistema se encontrará “vivo” conectado a energía eléctrica y con sus
procesos en estado “normal”, solamente que en este caso no se tiene acceso local al sistema, por
lo que se tendrá que obtener la información a través de la red. El sistema operativo con el que se
enfrentará el investigador será Windows 2000 y se cuenta con el password de acceso. La
siguiente figura muestra el tipo de caso a tratar:
VIVO Estado MUERTO

del
sistema

acceso al
sistema
(ejemplos)
CASO 2:
Windows CASO 4: CASO 1: CASO 3: CASO 5:
Linux Windows Linux Grave_robber
Linux
Fig. 4.5 Caso 2: Aplicación de metodología con Windows en forma remota
El equipo bajo sospecha puede ser un servidor o estación de trabajo conectado en red, por lo que
en este caso observamos que se puede obtener información de dos formas; la primera a través de
lo que el mismo equipo bajo sospecha emana a través de la red y por lo tanto a todos los equipos
conectados a ésta, sin establecer ningún tipo de conexión al sistema sospechoso, y la segunda
forma estableciendo una conexión segura específica al sistema sospechoso para obtener toda la
información volátil posible con comandos locales aplicados remotamente.
Por lo que la metodología la vamos a aplicar dos veces:

97
• Procedimiento1: Aplicación de la metodología obteniendo información a través de los

servicios activos de red disponibles del equipo comprometido, sin que se tenga que
establecer una conexión segura a través de la red y directa al equipo.
• Procedimiento 2: Aplicación de la metodología estableciendo una línea de comunicación
segura específica al equipo sospechoso a través de la red.
La información recolectada por ambos procedimientos podrá complementarse para obtener

mayor información del sistema bajo sospecha.
Para tener una mejor idea de la situación, la figura 4.6 muestra el diagrama de conexión de los
equipos en la red y los procedimientos que se llevarán a cabo para realizar la recolección:
Investigador forense
Equipo comprometido
Win2000
Procedimiento 1:
Servicios activos en red
Procedimiento 2: shell seguro
Fig. 4.6 Diagrama de conexión: Caso 2
La estación forense tendrá cargado el conjunto de herramientas que se utilizará y ésta misma
almacenará los datos recolectados.
98
PROCEDIMIENTO 1: Información obtenida a través de los servicios de red disponibles de

la máquina comprometida
Dentro de este procedimiento aplicaremos los pasos de la metodología propuesta.
PASO 1: ESTABLECER UNA LINEA DE COMANDOS SEGURO
Para este caso en una primera etapa trataremos de obtener todos los datos posibles a través de
servicios disponibles en red de la máquina bajo análisis, por lo que nos saltaremos este paso y
comenzaremos con el segundo.
PASO 2: REALIZAR UN REGISTRO DE TIEMPO
En este paso de la metodología vamos a obtener información en forma remota. Los comandos
que aplicaremos nos permiten obtener información a través de la red, sin necesidad de tener algún
tipo de acceso al equipo.
Primero obtenemos el tiempo y fecha del sistema con el comando “net time”, como se muestra a
continuación:
net time \\machinename
(forense)C:\pruebas>net time \\comprometido

La hora actual en \\luna es 8/16/2005 4:42 PM
Se ha completado el comando correctamente.
PASO 3: OBTENER EL ESTADO DEL SISTEMA
A continuación podemos obtener información del sistema con el comando “srvinfo” que es una
utilería del resource kit.
(forense)C:\pruebas>srvinfo \\comprometido
Server Name: comprometido

Security: Users
NT Type: NT Member Server - Enterprise
Version: 5.0
Build: 2195, Service Pack 4
Current Type: Uniprocessor Free
Product Name: Microsoft Windows 2000
Registered Owner: alicia
99
Registered Organization: cna

ProductID: 51879-270-5770243-05434
Original Install Date: Tue Jul 05 10:36:02 2005
Domain: Error 2
PDC: Error 1717
IP Address: 172.29.69.83
CPU[0]: x86 Family 6 Model 7 Stepping 3: 498 MHz
Hotfixes:
[ServicePackUninstall]:
[Q147222]:
[KB842526]:
[KB841873]:
[KB841872]:
[KB840315]:
[KB839645]:
[KB839643]:
[KB837001]:
[KB824146]:
[KB824141]:
[KB824105]:
Drive: [FileSys] [ Size ] [ Free ] [ Used ]
C$ NTFS 3050 994 2056
Services:
[Running] Alerter
[Stopped] Application Management
[Stopped] Background Intelligent Transfer Service
[Running] Computer Browser
[Stopped] Indexing Service
[Stopped] ClipBook
[Running] Distributed File System
[Running] DHCP Client
[Stopped] Logical Disk Manager Administrative Service
[Running] Logical Disk Manager
[Running] DNS Client
[Running] Event Log
[Running] COM+ Event System
[Stopped] Fax Service
[Running] IIS Admin Service
[Stopped] Intersite Messaging
[Stopped] Kerberos Key Distribution Center
[Running] Server
[Running] Workstation
[Running] License Logging Service
[Running] TCP/IP NetBIOS Helper Service
[Running] McAfee Framework Service
[Running] Network Associates McShield
[Running] Network Associates Task Manager
[Running] Messenger
[Stopped] NetMeeting Remote Desktop Sharing
[Running] Distributed Transaction Coordinator
[Stopped] Windows Installer
[Stopped] Network DDE
[Stopped] Network DDE DSDM
[Stopped] Net Logon
[Running] Network Connections
[Stopped] File Replication
[Stopped] NT LM Security Support Provider
[Running] Removable Storage
[Running] Plug and Play
[Running] IPSEC Policy Agent
[Running] Protected Storage
[Stopped] Remote Access Auto Connection Manager
[Running] Remote Access Connection Manager
[Running] Routing and Remote Access
[Running] Remote Registry Service
[Stopped] Remote Procedure Call (RPC) Locator
[Running] Remote Procedure Call (RPC)
[Stopped] QoS RSVP
[Running] Security Accounts Manager
[Stopped] Smart Card Helper
[Stopped] Smart Card
[Running] Task Scheduler
[Running] RunAs Service
[Running] System Event Notification
100
[Stopped] Internet Connection Sharing

[Running] Simple Mail Transport Protocol (SMTP)
[Running] Print Spooler
[Stopped] Performance Logs and Alerts
[Running] Telephony
[Stopped] Terminal Services
[Stopped] Telnet
[Stopped] Distributed Link Tracking Server
[Running] Distributed Link Tracking Client
[Running] User Mode Process Dump
[Stopped] Uninterruptible Power Supply
[Stopped] Utility Manager
[Stopped] Windows Time
[Running] World Wide Web Publishing Service
[Running] Windows Management Instrumentation
[Running] Windows Management Instrumentation Driver Extensions
[Running] Automatic Updates
[Stopped] Wireless Configuration
Network Card [0]:
System Up Time: 0 Days, 3 Hr, 13 Min, 47 Sec
Aplicamos el comando “pslist” para obtener los procesos que están corriendo en el sistema
utilizando la siguiente sintaxis: pslist \\machinename
(forense)C:\toolkit>pslist \\comprometido

Process information for comprometido:
Idle 0 0 1 0 0 2:04:11.534 2:05:42.836
System 8 8 47 210 24 0:00:09.253 2:05:42.836
SMSS 144 11 6 33 1096 0:00:00.530 2:05:42.836
CSRSS 168 13 10 437 1288 0:00:02.463 2:05:31.820
WINLOGON 164 13 18 429 6788 0:00:02.663 2:05:30.538
SERVICES 216 9 38 531 3144 0:00:03.695 2:05:28.565
LSASS 228 9 20 291 2896 0:00:01.632 2:05:28.535
svchost 436 8 9 276 1704 0:00:00.851 2:05:23.037
spoolsv 464 8 11 136 2700 0:00:00.540 2:05:22.446
msdtc 492 8 21 207 1992 0:00:00.330 2:05:22.336
svchost 600 8 28 1246 9768 0:00:04.947 2:05:20.233
LLSSRV 628 9 9 75 776 0:00:00.120 2:05:19.492
FrameworkServic 672 8 10 193 2944 0:00:01.041 2:05:18.400
Mcshield 732 13 20 203 18320 0:00:32.556 2:05:17.018
VsTskMgr 748 8 11 131 5112 0:00:00.250 2:05:16.568
naPrdMgr 792 8 4 108 4560 0:00:00.220 2:05:14.625
regsvc 868 8 4 91 744 0:00:00.250 2:05:09.978
mstask 880 8 6 114 1140 0:00:00.270 2:05:08.446
userdump 936 8 4 47 332 0:00:00.020 2:04:58.071
WinMgmt 1000 8 5 117 1332 0:00:10.414 2:04:55.297
svchost 1032 8 6 213 5904 0:00:03.885 2:04:53.965
dfssvc 1056 8 2 36 484 0:00:00.070 2:04:53.495
inetinfo 1084 8 36 776 7424 0:00:02.032 2:04:50.911
svchost 1368 8 11 168 1580 0:00:00.220 2:03:58.786
explorer 1336 8 12 248 4888 0:00:07.821 2:02:37.549
shstat 724 8 6 61 4600 0:00:00.210 2:02:03.160
UpdaterUI 636 8 4 96 1004 0:00:00.260 2:02:00.937
internat 1288 8 1 27 372 0:00:00.070 2:02:00.396
wuauclt 1700 8 5 101 1572 0:00:00.150 2:01:03.163
CMD 1716 8 1 21 316 0:00:00.060 2:00:55.562
DLLHOST 720 8 8 143 1724 0:00:01.001 1:52:07.874
mdm 1620 8 3 88 828 0:00:00.140 1:24:16.150
Aplicamos el comando “nmap” para realizar un escaneo de puertos, utilizando la siguiente

sintaxis, donde la opción “sT” significa conexiones TCP : nmap –sT <dirección IP>
101
(forense)C:\toolkit\nmap\nmap-3.81>nmap -sT 172.29.69.83
Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-08-16 11:27 Hora est

. de AmÚrica Central
Warning: OS detection will be MUCH less reliable because we did not find at lea
st 1 open and 1 closed TCP port
Interesting ports on 172.29.69.83:
(The 1654 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
25/tcp open smtp
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
1025/tcp open NFS-or-IIS
1723/tcp open pptp
3372/tcp open msdtc
MAC Address: 00:50:DA:B7:D5:BD (3com)
Device type: general purpose
Running: Microsoft Windows 95/98/ME|NT/2K/XP
OS details: Microsoft Windows Millennium Edition (Me), Windows 2000 Pro or Advan
ced Server, or Windows XP
Nmap finished: 1 IP address (1 host up) scanned in 118.749 seconds
Los rootkits y otros programas de acceso remoto son ejecutados desde un servicio, por lo que
listamos los servicios utilizando “sclist”:
(forense)C:\toolkit>sclist \\comprometido
--------------------------------------------
- Service list for \\comprometido
--------------------------------------------
running Alerter Alerter
stopped AppMgmt Application Management
stopped BITS Background Intelligent Transfe
running Browser Computer Browser
stopped cisvc Indexing Service
stopped ClipSrv ClipBook
running Dfs Distributed File System
running Dhcp DHCP Client
stopped dmadmin Logical Disk Manager Administr
running dmserver Logical Disk Manager
running Dnscache DNS Client
running Eventlog Event Log
running EventSystem COM+ Event System
stopped Fax Fax Service
running IISADMIN IIS Admin Service
stopped IsmServ Intersite Messaging
stopped kdc Kerberos Key Distribution Cent
running lanmanserver Server
running lanmanworkstation Workstation
running LicenseService License Logging Service
running LmHosts TCP/IP NetBIOS Helper Service
running McAfeeFramework McAfee Framework Service
running McShield Network Associates McShield
running McTaskManager Network Associates Task Manage
running Messenger Messenger
stopped mnmsrvc NetMeeting Remote Desktop Shar
running MSDTC Distributed Transaction Coordi
stopped MSIServer Windows Installer
stopped NetDDE Network DDE
stopped NetDDEdsdm Network DDE DSDM
stopped Netlogon Net Logon
running Netman Network Connections
stopped NtFrs File Replication
stopped NtLmSsp NT LM Security Support Provide
running NtmsSvc Removable Storage
running PlugPlay Plug and Play
102
running PolicyAgent IPSEC Policy Agent

running ProtectedStorage Protected Storage
running PSEXESVC PsExec
stopped RasAuto Remote Access Auto Connection
running RasMan Remote Access Connection Manag
running RemoteAccess Routing and Remote Access
running RemoteRegistry Remote Registry Service
stopped RpcLocator Remote Procedure Call (RPC) Lo
running RpcSs Remote Procedure Call (RPC)
stopped RSVP QoS RSVP
running SamSs Security Accounts Manager
stopped SCardDrv Smart Card Helper
stopped SCardSvr Smart Card
running Schedule Task Scheduler
running seclogon RunAs Service
running SENS System Event Notification
stopped SharedAccess Internet Connection Sharing
running SMTPSVC Simple Mail Transport Protocol
running Spooler Print Spooler
stopped SysmonLog Performance Logs and Alerts
running TapiSrv Telephony
stopped TermService Terminal Services
stopped TlntSvr Telnet
stopped TrkSvr Distributed Link Tracking Serv
running TrkWks Distributed Link Tracking Clie
running udmpsvc User Mode Process Dump
stopped UPS Uninterruptible Power Supply
stopped UtilMan Utility Manager
stopped W32Time Windows Time
running W3SVC World Wide Web Publishing Serv
running WinMgmt Windows Management Instrumenta
running Wmi Windows Management Instrumenta
running wuauserv Automatic Updates
stopped WZCSVC Wireless Configuration
Otra de las herramientas que podemos aplicar para listar los archivos compartidos y quien los ha
accedido es “srvcheck”, pero debe ser aplicado con una cuenta privilegiada, que en el siguiente
ejemplo muestra al usuario alicia_user y al usuario alicia_admin con privilegios totales sobre la
carpeta_compartida_de_comprometido.
(forense)C:\toolkit\srvcheck \\comprometido
\\comprometido\carpeta_compartida_de_comprometido
COMPROMETIDO\alicia_user Full Control
COMPROMETIDO\alicia_admin Full Control
PASO 4: DETERMINAR LAS CONEXIONES AL SISTEMA
En este paso de la metodología obtenemos las estadísticas del protocolo y las conexiones actuales
de TCPIP con el comando “nbtstat” y la siguiente sintaxis:
nbtstat –a \\machinename La opción “-a” hace una lista de los equipos remotos
Ejemplo de aplicación del comando

(forense)C:\toolkit>nbtstat -a comprometido
103
Conexión de área local:

Dirección IP: [172.29.69.69] Id. de ámbito : []
NetBIOS Remote Machine Name Table
Nombre Tipo Estado

---------------------------------------------
LUNA <00> Único Registrado
FORE <00> Grupo Registrado
FORE <1E> Grupo Registrado
FORE <1D> Único Registrado
..__MSBROWSE__.<01> Grupo Registrado
INet~Services <1C> Grupo Registrado
IS~LUNA........<00> Único Registrado
Dirección MAC = 00-50-DA-B7-D5-BD
PROCEDIMIENTO 2: Con línea de comunicación segura
En este procedimiento primero estableceremos una línea de comunicación segura a través de la

red para aplicar las herramientas y una vez hecha, capturamos la información.
PASO 1: ESTABLECER UNA LÍNEA DE COMANDOS SEGURA
Aplicaremos el primer paso de la metodología estableciendo una conexión segura, ya que el

investigador forense no se encuentra físicamente en el lugar donde se ubica el quipo bajo análisis.
Los comandos se copiarán remotamente y se ejecutarán en forma local.
Para realizar una conexión administrativa a la máquina remota utilizamos el comando “net use”
desde la estación forense con la siguiente sintaxis:
Net use \\machine\ipc$ /user:machine\administrator password
Ejemplo de aplicación:
(forense)C:\>net use \\comprometido\ipc$ /user:administrator password
Se ha completado el comando correctamente.
Una vez establecida la conexión copiamos los comandos confiables de nuestro conjunto de
herramientas (toolkit) con el comando xcopy:
(forense) C:\>xcopy /SVI toolkit \\comprometido\c$\toolkit

toolkit\Auditpol.exe
toolkit\dh.exe
toolkit\dhcmp.exe
toolkit\drivers.exe
toolkit\Fport.exe
104
toolkit\listdlls.exe
toolkit\NTLast.exe
toolkit\perms.exe
toolkit\procexp.chm
toolkit\procexp.exe
toolkit\psexec.exe
toolkit\psfile.exe
toolkit\psgetsid.exe
toolkit\Psinfo.exe
toolkit\pskill.exe
toolkit\pslist.exe
toolkit\psloggedon.exe
toolkit\psloglist.exe
toolkit\pspasswd.exe
toolkit\psservice.exe
toolkit\psshutdown.exe
toolkit\pssuspend.exe
toolkit\Rasusers.exe
toolkit\README.TXT
toolkit\Regrest.exe
toolkit\Sclist.exe
toolkit\Showmbrs.exe
toolkit\Srvcheck.exe
toolkit\Srvinfo.exe
toolkit\tcpvcon.exe
toolkit\nmap\nmap-os-fingerprints
toolkit\nmap\nmap-services
toolkit\nmap\nmap.exe
33 archivos copiados
Una vez copiados los archivos, establecemos una línea de comandos segura (cmd.exe) aplicando
la herramienta “psexec” con la siguiente sintaxis: psexec \\machine cmd
Ejemplo de aplicación
(forense)C:\>cd toolkit
(forense)C:\toolkit>psexec \\comprometido cmd
PsExec v1.55 - Execute processes remotely

Microsoft Windows 2000 [Version 5.00.2195]

(C) Copyright 1985-2000 Microsoft Corp.
(comprometido)C:\WINNT\system32>cd \toolkit
PASO 2: REALIZAR UN REGISTRO DE TIEMPO DEL SISTEMA (TIME STAMP)
Como en el caso 1 utilizamos el comando “dir” o “ls” para obtener un listado de todos los
archivos en el sistema bajo análisis, tiempos de acceso, modificación y creación.

Directory of c:\

105

8 File(s) 25,706,484 bytes
. . . .
. . .
. .
PASO 3: OBTENER EL ESTADO DEL SISTEMA
Una vez hecho el registro de tiempo en el equipo comprometido, procedemos a obtener el estado
del sistema con los comandos de nuestro conjunto de herramientas que ya se encuentra en el
sistema bajo análisis:
Acción 1: Obtener los datos del sistema
Como en el caso anterior obtenemos la identificación de red del equipo con el comando
“ipconfig”, como se muestra a continuación:
(forense) C:\toolkit>ipconfig /all
Windows 2000 IP Configuration

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :

IP Address. . . . . . . . . . . . : 172.29.69.83
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.29.69.254
Acción 2: Determinar los puertos abiertos
Para enumerar los puertos por los cuales los procesos están escuchando, utilizamos la
herramienta “fport”:
(comprometido)C:\toolkit\fport.exe
(comprometido)C:\toolkit>fport
FPort v2.0 - TCP/IP Process to Port Mapper
Copyright 2000 by Foundstone, Inc.
http://www.foundstone.com
Pid Process Port Proto Path

8 System -> 139 TCP
106

8 System -> 445 TCP
880 MSTask -> 1026 TCP C:\WINNT\system32\MSTask.exe
436 svchost -> 135 UDP C:\WINNT\system32\svchost.exe

8 System -> 137 UDP
8 System -> 138 UDP
8 System -> 445 UDP
228 lsass -> 500 UDP C:\WINNT\system32\lsass.exe
8 System -> 1701 UDP
Acción 3: Listando los procesos corriendo
Para obtener la lista de procesos que está corriendo en el sistema utilizamos la herramienta
“pslist”, esta información ya la obtuvimos en forma remota, pero a menos que no se haya podido
obtener, procederemos a su captura mediante la conexión segura al equipo.
Este paso se realiza si se cuenta con tiempo suficiente para obtener las bitácoras del sistema.
Primero podemos descargar la información del “registry” a un archivo, con el comando “reg” y
“regedit”, como se muestra a continuación:
(comprometido)c:\toolkit\regedit –e respaldo_registry.reg
(comprometido)c:\toolkit\reg export HKLM respaldo_registry.reg
The operation completed successfully
Para obtener las bitácoras nos podemos auxiliar del comando dumpel.exe del resource kit. En el
siguiente ejemplo se muestra la obtención de las bitácoras de seguridad, sistema y aplicaciones:
(comprometido)c:\toolkit\dumpel –f security.bck –l security

(comprometido)c:\toolkit\dumpel –f system.bck –l system

(comprometido)c:\toolkit\dumpel –f application.bck –l application

The operation completed succesfully
107
PASO 4: DETERMINAR LAS CONEXIONES AL SISTEMA
El siguiente paso es saber quien esta en el sistema para lo cual utilizaremos las herramientas “net
session” y “tcpvcon”
(comprometido)C:\toolkit>net session
Computer User name Client Type Opens Idle time
-------------------------------------------------------------------------------
\\ATORRES ADMINISTRATOR Windows 2002 Serv 4 00:00:00
The command completed successfully.
(comprometido)C:\toolkit>tcpvcon
TCPView v2.34 - TCP/UDP endpoint lister

[TCP] System
PID: 8
State: ESTABLISHED
Local: comprometido:netbios-ssn
Remote: atorres:4082
También listamos los miembros del grupo administrador usando la herramienta “showmbrs” para
verificar algo inusual
(comprometido)C:\toolkit>showmbrs administrators
Members of local group [\administrators]:
COMPROMETIDO\Administrator
COMPROMETIDO\alicia_admin
Utilizamos la herramienta “psloggedon” para mostrar los usuarios que están en el sistema (logged
on) actualmente.
(comprometido)C:\toolkit>psloggedon
PsLoggedOn v1.31 - Logon Session Displayer

Users logged on locally:

8/16/2005 5:37:00 PM COMPROMETIDO\Administrator
Users logged on via resource shares:

8/16/2005 6:04:31 PM (null)\ADMINISTRATOR
Con la herramienta “arp” mostramos las conexiones en la tabla de direcciones.

(comprometido)C:\toolkit>arp -a
Interface: 172.29.69.83 on Interface 0x1000003

Internet Address Physical Address Type
172.29.69.69 00-09-6b-14-84-c9 dynamic
172.29.69.254 00-20-9c-12-db-b4 dynamic
108
Con la herramienta “netstat” mostramos las conexiones activas.

(comprometido)C:\toolkit>netstat -a
Active Connections
Proto Local Address Foreign Address State

TCP comprometido:smtp comprometido:0 LISTENING
TCP comprometido:http comprometido:0 LISTENING
TCP comprometido:epmap comprometido:0 LISTENING
TCP comprometido:https comprometido:0 LISTENING
TCP comprometido:microsoft-ds comprometido:0 LISTENING
TCP comprometido:1025 comprometido:0 LISTENING
TCP comprometido:pptp comprometido:0 LISTENING
TCP comprometido:netbios-ssn comprometido:0 LISTENING
TCP comprometido:netbios-ssn ATORRES:4082 ESTABLISHED
TCP comprometido:1041 ATORRES:netbios-ssn TIME_WAIT
UDP comprometido:epmap *:*
UDP comprometido:microsoft-ds *:*
UDP comprometido:1029 *:*
UDP comprometido:l2tp *:*
UDP comprometido:radius *:*
UDP comprometido:radacct *:*
UDP comprometido:netbios-ns *:*
UDP comprometido:netbios-dgm *:*
UDP comprometido:isakmp *:*
Para encontrar un historial de entrada al sistema (login history) utilizamos la herramienta

“ntlast.exe“, como se muestra a continuación:
(comprometido)C:\toolkit>ntlast
alicia_user COMPROMETIDO COMPROMETIDO Wed Aug 17 02:09:24pm 2005
Administrator COMPROMETIDO COMPROMETIDO Wed Aug 17 12:14:31pm 2005
- End Of File -
PASO 5: REALIZAR EL 2º. REGISTRO DE TIEMPO
Como en el paso 1 nuevamente utilizamos el comando “dir” para obtener un listado de todos los
archivos en el sistema bajo análisis, tiempos de acceso, modificación y creación.
(forense) C:\toolkit>dir c:\ /Q /S /TA

Directory of c:\

109

8 File(s) 25,706,484 bytes
. . . .
. . .
. .
PASO 6: HACER UNA COPIA DE LA MEMORIA
Para obtener una copia de la memoria, en este caso podemos utilizar la utilería “pslist” en forma
remota con sus opciones “x” que muestra los detalles de la memoria y proceso hijos (threds) y “t”
que muestra el árbol de procesos. El siguiente comando envía la salida de esta herramienta a un
archivo pslistx.txt.
Ejemplo de aplicación con la opción “x”:
(forense)c:\toolkit>pslist –x \\comprometido –u administrator –p password >> pslistx.txt

Process and thread information for comprometido:
Idle 0 0 1 0 0 0:47:56.105 0:47:58.269
VM WS Priv Priv Pk Faults NonP Page
0 16 0 0 1 0 0
Tid Pri Cswtch State User Time Kernel Time Elapsed Time
0 0 178577 Running 0:00:00.000 0:47:56.125 0:00:00.000
System 8 8 48 187 28 0:00:13.088 0:47:58.269
1672 36 28 176 2292 0 0
4 0 2028 Ready 0:00:00.000 0:00:11.576 0:00:00.000
12 13 6 Wait:Queue 0:00:00.000 0:00:00.000 0:48:21.302
16 13 25459 Wait:Queue 0:00:00.000 0:00:00.080 0:48:21.302
20 13 2536 Wait:Queue 0:00:00.000 0:00:00.060 0:48:21.302
24 13 32722 Wait:Queue 0:00:00.000 0:00:00.060 0:48:21.302
28 13 1635 Wait:Queue 0:00:00.000 0:00:00.100 0:48:21.302
32 13 3581 Wait:Queue 0:00:00.000 0:00:00.270 0:48:21.302
36 13 14 Wait:Queue 0:00:00.000 0:00:00.000 0:48:21.302
40 12 965 Wait:Queue 0:00:00.000 0:00:00.210 0:48:21.302
44 13 1838 Wait:Queue 0:00:00.000 0:00:00.260 0:48:21.302
48 15 253 Wait:Queue 0:00:00.000 0:00:00.000 0:48:21.302
52 15 2944 Wait:Executive 0:00:00.000 0:00:00.000 0:48:21.302
56 18 681 Wait:VirtualMem 0:00:00.000 0:00:00.040 0:48:21.282
60 17 1951 Wait:FreePage 0:00:00.000 0:00:00.150 0:48:21.282
64 16 47802 Wait:Executive 0:00:00.000 0:00:00.010 0:48:21.282
68 23 78867 Wait:Executive 0:00:00.000 0:00:00.010 0:48:21.282
72 16 3 Wait:Queue 0:00:00.000 0:00:00.000 0:48:21.122
110
76 17 19 Wait:Queue 0:00:00.000 0:00:00.000 0:48:21.122

80 8 345 Wait:Executive 0:00:00.000 0:00:00.020 0:48:20.792
84 17 93 Wait:VirtualMem 0:00:00.000 0:00:00.000 0:48:20.771
88 8 1 Wait:Executive 0:00:00.000 0:00:00.000 0:48:20.411
92 8 15 Wait:Queue 0:00:00.000 0:00:00.000 0:48:14.242
104 8 6 Wait:Executive 0:00:00.000 0:00:00.000 0:47:59.791
108 8 1 Wait:Executive 0:00:00.000 0:00:00.000 0:47:59.791
112 8 1 Wait:Executive 0:00:00.000 0:00:00.000 0:47:58.790
120 8 1 Wait:Queue 0:00:00.000 0:00:00.000 0:47:58.479
mstask 760 8 6 111 1144 0:00:00.140 0:47:28.226
26924 460 1144 1160 1343 14 23
684 9 121 Wait:Executive 0:00:00.020 0:00:00.010 0:47:28.216
780 8 272 Wait:UserReq 0:00:00.040 0:00:00.030 0:47:23.459
800 9 7 Wait:LpcReceive 0:00:00.000 0:00:00.010 0:47:21.366
836 8 1 Wait:UserReq 0:00:00.000 0:00:00.000 0:47:12.684
864 9 19 Wait:Queue 0:00:00.000 0:00:00.000 0:47:12.684
896 10 469 Wait:UserReq 0:00:00.000 0:00:00.020 0:47:11.912
userdump 820 8 4 47 336 0:00:00.020 0:47:18.212
17056 72 336 336 299 1 14
816 14 47 Wait:Executive 0:00:00.010 0:00:00.000 0:47:18.212
876 8 7 Wait:UserReq 0:00:00.000 0:00:00.000 0:47:12.433
880 8 2 Wait:UserReq 0:00:00.000 0:00:00.000 0:47:12.433
884 8 2 Wait:UserReq 0:00:00.000 0:00:00.000 0:47:12.403
WinMgmt 908 8 4 112 1156 0:00:10.404 0:47:11.702
23452 108 1156 2168 8965 11 15
904 9 101 Wait:Executive 0:00:00.050 0:00:00.020 0:47:11.702
796 9 683 Wait:UserReq 0:00:00.040 0:00:00.110 0:47:09.940
1084 10 524 Wait:LpcReceive 0:00:00.080 0:00:00.080 0:46:53.406
344 9 30 Wait:Queue 0:00:00.000 0:00:00.000 0:45:55.823
Ejemplo de aplicación de “pslist” con la opción “t”:
c:\toolkit>pslist –t \\comprometido –u administrator –p password >> pslistt.txt

Process information for comprometido:
Name Pid Pri Thd Hnd VM WS Priv

Idle 0 0 1 0 0 16 0
System 8 8 48 190 1672 36 28
SMSS 144 11 6 33 7304 60 1104
CSRSS 168 13 9 419 19388 396 1092
WINLOGON 188 13 17 421 41260 1180 7140
SERVICES 216 9 42 542 38684 3300 4260
svchost 416 8 8 288 23544 2364 1632
naPrdMgr 656 8 4 106 35684 264 3392
DLLHOST 988 8 13 149 24988 5596 1796
spoolsv 444 8 11 135 30936 1068 2716
svchost 476 8 33 1269 148640 3920 9944
LLSSRV 500 9 10 77 19496 644 792
FrameworkServic 540 8 10 194 33788 1056 2976
Mcshield 600 13 20 199 77152 5912 18644
VsTskMgr 620 8 11 131 45004 300 3960
regsvc 732 8 4 95 14904 1376 748
mstask 760 8 6 111 26924 460 1144
userdump 820 8 4 47 17056 72 336
WinMgmt 908 8 4 112 23452 108 1156
111
svchost 920 8 5 171 29020 1508 3720

dfssvc 952 8 2 36 11776 116 492
inetinfo 968 8 34 703 64024 5052 7204
svchost 972 8 4 187 26132 476 2596
msdtc 984 8 21 195 33660 464 1976
svchost 1344 8 10 161 23556 276 1576
LSASS 228 9 15 277 33444 2296 2756
explorer 1500 8 13 225 37800 2628 3716
internat 272 8 1 27 17388 100 380
UpdaterUI 1288 8 4 96 28572 348 1008
shstat 1296 8 6 60 38004 600 3448
PASO 7: TRANSFERIR A UN MEDIO SEGURO Y DOCUMENTAR
La tabla 4.3 resume los pasos realizados, las acciones tomadas y las herramientas utilizadas que
nos ayudarán a realizar la documentación apropiada de la captura de datos.

NT/2000
Procedimiento 1: Información obtenida vía la red
2 Registro de tiempo Tiempo y fecha del sistema net time
3 Estado y datos del sistema Información del equipo srvinfo
Listar los procesos que abren sockets pslist
Obtener los puertos abiertos nmap
Listar los servicios sclist
Directorios compartidos y quien los ha accedido srvchk
4 Conexiones al sistema Conexiones actuales establecidas nbtstat
Procedimiento 2: Información obtenida localmente
1 Conectarse remotamente Establecer una conexión administrativa net use
Copias remotas xcopy
Ejecución de comandos remotos psexec
2 Registro de tiempo Time stamp, tiempo de creación de los archivos dir
3 Estado del sistema Obtener los puertos abiertos fport
Respuesta inicial profunda
Descarga todo el registry a un archivo regedit, reg
Obteniendo las bitácoras dumpel
4 Conexiones al sistema Listar la conexiones abiertas net session,
Listar los miembros del grupo administrador tcpvcon
Determinar quien está dentro del sistema showmbrs
Listar conexiones recientes netstat
Desplegar direcciones IP y físicas psloggedon
Lista las conexiones exitosas y fallidas arp
Historial de entradas al sistema netstat
nlast
5 2º. Registro de tiempo Time stamp, tiempo de creación de los archivos dir
6 Información de la memoria Obtener detalles de la memoria y procesos pslist –t
pslist –x
7 Transferir y documentar Transferir y almacenar los datos en un lugar script
112

NT/2000
seguro netcat
md5sum
Documentar los pasos
Una vez seleccionados los programas y pasos, realizamos un programa script que corra todos
estos comandos al mismo tiempo o también se puede correr cada comando en forma individual y
transferirlos a un sitio seguro con ayuda de la herramienta “netcat”, que envía información a
través de la red.
Para utilizar “netcat” el primer paso es levantar el servicio en nuestra estación de trabajo
(dirección IP 172.29.69.69), para escuchar (l) o recibir los datos remotos por el puerto (p) que en
este caso será el número 2222:
(forense)c:\WSForense>nc –l –p 2222 > datos
En el equipo bajo análisis se dirige la salida del script generado hacia la dirección IP de la
estación de trabajo forense:
(comprometido)c:\toolkit>script | nc 172.29.69.69 2222
En caso de la aplicación de cada comando en forma individual, en la estación forense se abrirá un

archivo para recibir los datos del comando aplicado
(forense)c:\WSForense>nc –l –p 2222 > timestamp1.txt
En el equipo comprometido se ejecutará el comando y la salida de dicho comando saldrá por la

red al archivo que hemos abierto en la estación forense:
(comprometido)c:\toolkit>dir c:\ /Q /S /TA >> | nc 172.29.69.69 2222
Y así sucesivamente para cada comando.
Para cerrar la conexión se puede teclear CTRL-C.
Una vez concentrada la información en la estación de trabajo forense, se coloca una

identificación de integridad a la información obtenida con la herramienta “md5sum.exe”, como
se muestra a continuación:
113
(forense)c:\WSForense>md5sum datos > datos.sum
Para el caso donde se ejecuta cada comando en forma individual, también se aplica esa misma
herramienta, de la siguiente manera:
(forense)c:\WSForense>md5sum timestamp1.txt > timestamp1.sum

114

LINUX CON ACCESO LOCAL
Ahora aplicaremos la metodología sobre la plataforma Linux. La respuesta inicial en un sistema

Linux es similar a la respuesta inicial en Windows, el objetivo es obtener datos volátiles del
2
sistema antes de proceder a obtener la información estática . Las condiciones bajo las cuales se
encuentra el equipo bajo sospecha son que el estado del sistema será “vivo”, estará trabajando
sobre Linux Red Hat Enterprise y el investigador contará con el password de acceso, tal como se
consta en la figura 4.7.
VIVO Estado MUERTO

del
sistema

acceso al
sistema
(ejemplos)
CASO 3:
Windows Linux Windows
Linux Grave_robber
Linux
Fig. 4.7 Caso 3: Aplicación de metodología en Linux con acceso local
El procedimiento se aplicará directamente a la consola del equipo sospechoso estableciendo una

conexión segura en forma local, esto elimina la posibilidad de que el atacante esté monitoreando
la respuesta y asegura que se corran comandos confiables.
Los programas que serán utilizados en esta captura trabajan sobre Linux y no serán instalados en
el sistema bajo análisis, estos correrán desde un CDROM y la información capturada será enviada
a un floppy o USB.
2
La información estática es la información que permanece en el sistema hasta que sea sobrescrita, borrada o
destruída como pueden ser archivos de bitácoras, archivos de configuración, sistemas de archivos y que no se pierde
al apagar el equipo.
115
PASO 1: LINEA DE COMANDOS SEGURA
Acceder localmente en la consola de la víctima puede evitar la generación de tráfico de red. En

este punto se monta el toolkit confiable y el medio donde se almacenará la información que se
recolecte:
# mount /dev/hdc /mnt/fcdrom Para montar un cdrom
El primer paso en toda respuesta es estar seguro de que se están ejecutando comandos seguros en
el shell. Los shells de Linux pueden ser alterados (trojaned) por un atacante, que provocan que
los comandos ejecutados realicen operaciones erróneas en los comandos del investigador. Por lo
que será necesario ejecutar un shell seguro también (bash). Una vez ejecutado se direccionarán
todos los comandos a ese shell, colocando la variable de ambiente PATH igual a punto (.),
evitando ejecutar accidentalmente un comando no confiable. Un tip es cambiar el nombre de
nuestros ejecutables confiables para no cometer ese error, por ejemplo en vez de teclear netstat,
tecleamos tnetstat.
# /mnt/floppy/bash
# /mnt/floppy/PATH=.
# /mnt/cdrom/mount /dev/fd0 /mnt/floppy Para montar el floppy o USB donde almacenar la información.
# /mnt/cdrom/mount /dev/sda1 /mnt/memstick
# /mnt/cdrom/mount /dev/sda1 –n vfat /mnt/memstick Especificando en tipo de sistema
Los binarios no deben utilizar bibliotecas dinámicas, pero en caso necesario se deberán ligar a
bibliotecas en el CD. Los CD con distribución portable ya contienen herramientas en forma
estática (FIRE, knoppix o Trinux).
PASO 2: REGISTRO DE TIEMPO
Obtener el tiempo y fecha del sistema
Una vez montadas las herramientas obtenemos un registro de tiempo del sistema con el comando
“date”:
# /mnt/cdrom/date > /mnt/floppy/date_start.txt
Obtener el MAC (Modification, Creation, Access Time) de todos los archivos

116
Una vez que se decide realizar la respuesta inicial, se deben obtener todos los “time/date stamp”
en el sistema de archivos, para eso utilizaremos el comando “ls” con los siguientes argumentos:
# /mnt/cdrom/ls –alRu > /mnt/floppy/access_start.txt

# /mnt/cdrom/ls –alRc > /mnt/floppy/modification_start.txt
# /mnt/cdrom/ls –alR > /mnt/floppy/creation_start.txt
PASO 3: ESTADO DEL SISTEMA
Para determinar el estado del sistema realizaremos las siguientes acciones:
1. Obtener los procesos corriendo

2. Capturar información del sistema /proc
3. Listar los puertos abiertos y aplicaciones en escucha
4. Respuesta inicial mas profunda
o Detectando y capturando un proceso sospechoso
Acción 1: Listar los procesos corriendo
Para obtener todos los procesos corriendo utilizaremos los comandos estándar “ps” o “pstree”.
# /mnt/cdrom/pstree –pla > /mnt/floppy/pstree.txt
l= líneas largas, a= argumentos
Ejemplo de salida del comando aplicado :

init,1
├─apmd,1624 -p 10 -w 5 -W -P /etc/sysconfig/apm-scripts/apmscript
├─atd,1812
├─(bdflush,7)*
├─bonobo-activati,1974 --ac-activate --ior-output-fd=16
├─cardmgr,1600
├─crond,1773
├─cupsd,1665
├─eggcups,1999 --sm-client-id default6
├─gconfd-2,1971 5
├─gdm-binary,1832 -nodaemon
│ └─gdm-binary,1885 -nodaemon
│ ├─X,1886 :0 -auth /var/gdm/:0.Xauth vt7
│ └─gnome-session,1895
│ └─ssh-agent,1961 /etc/X11/xinit/Xclients
├─gnome-panel,1992 --sm-client-id default2
………
………
# /mnt/cdrom/ps –Al > /mnt/floppy/procesos.txt La opción Al indica todos los procesos en un formato largo
Ejemplo de salida del comando:
UID PID PPID C STIME TTY TIME CMD

root 1 0 0 08:01 ? 00:00:04 init
root 2 1 0 08:01 ? 00:00:00 [keventd]
root 3 1 0 08:01 ? 00:00:00 [kapmd]
117
root 4 1 0 08:01 ? 00:00:00 [ksoftirqd/0]

root 7 1 0 08:01 ? 00:00:00 [bdflush]
root 5 1 0 08:01 ? 00:00:00 [kswapd]
root 6 1 0 08:01 ? 00:00:00 [kscand]
root 8 1 0 08:01 ? 00:00:00 [kupdated]
root 9 1 0 08:01 ? 00:00:00 [mdrecoveryd]
root 13 1 0 08:01 ? 00:00:01 [kjournald]
root 68 1 0 08:01 ? 00:00:00 [khubd]
root 1495 1 0 08:02 ? 00:00:00 syslogd -m 0
root 1499 1 0 08:02 ? 00:00:00 klogd -x
rpc 1525 1 0 08:02 ? 00:00:00 portmap
rpcuser 1544 1 0 08:02 ? 00:00:00 rpc.statd
root 1600 1 0 08:02 ? 00:00:00 /sbin/cardmgr
root 1624 1 0 08:02 ? 00:00:00 /usr/sbin/apmd -p 10 -w 5 -W -P
root 1665 1 0 08:02 ? 00:00:01 cupsd
root 1705 1 0 08:02 ? 00:00:00 /usr/sbin/sshd
root 1719 1 0 08:02 ? 00:00:00 xinetd -stayalive -pidfile /var/
root 1745 1 0 08:02 ? 00:00:00 sendmail: accepting connections
smmsp 1754 1 0 08:02 ? 00:00:00 sendmail: Queue runner@01:00:00
root 1764 1 0 08:02 ? 00:00:00 gpm -t ps/2 -m /dev/mouse
... … …
Acción 2: Listar los puertos abiertos y aplicaciones en escucha
En Linux, el comando “netstat” tiene la opción “-p” que mapea el nombre de la aplicación del
proceso, su ID, el puerto, la dirección y si están en escucha:
# /mnt/cdrom/netstat –anp > /mnt/floppy/netstat.txt

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN 1544/rpc.statd
tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN 1719/xinetd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1525/portmap
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 1886/X
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1705/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1665/cupsd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1745/sendmail:
acce
tcp 0 0 127.0.0.1:631 127.0.0.1:32771 ESTABLISHED 1665/cupsd
tcp 0 0 127.0.0.1:32771 127.0.0.1:631 ESTABLISHED 1999/eggcups
udp 0 0 0.0.0.0:32768 0.0.0.0:* 1544/rpc.statd
udp 0 0 0.0.0.0:872 0.0.0.0:* 1544/rpc.statd
udp 0 0 0.0.0.0:111 0.0.0.0:* 1525/portmap
udp 0 0 0.0.0.0:631 0.0.0.0:* 1665/cupsd
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 2855 1988/metacity /tmp/orbit-
root/linc-7c4-0-315ee1028f6b
unix 2 [ ACC ] STREAM LISTENING 3067 2009/notification-a /tmp/orbit-
root/linc-7d9-0-50b626573cc46
unix 2 [ ACC ] STREAM LISTENING 3095 2003/python /tmp/orbit-
root/linc-7d3-0-43893ea45b517
unix 2 [ ACC ] STREAM LISTENING 2885 1992/gnome-panel /tmp/orbit-
root/linc-7c8-0-7c0eafdf5ddba
unix 2 [ ACC ] STREAM LISTENING 2906 1996/magicdev /tmp/orbit-
root/linc-7cc-0-7c0eafdf867db
unix 2 [ ACC ] STREAM LISTENING 2924 1994/nautilus /tmp/orbit-
root/linc-7ca-0-6e5ddaca9702b
unix 2 [ ACC ] STREAM LISTENING 2943 1999/eggcups /tmp/orbit-
root/linc-7cf-0-6e5ddacae056c
unix 2 [ ACC ] STREAM LISTENING 2627 1886/X /tmp/.X11-unix/X0
unix 2 [ ACC ] STREAM LISTENING 2617 1832/gdm-binary /tmp/.gdm_socket
118
Acción 3: Listar los archivos abiertos
Se ejecuta “lsof” para localizar procesos sospechosos, lsof lista todos los procesos corriendo y los
descriptores de archivos que abren los procesos.
# /mnt/cdrom/lsof > /mnt/floppy/lsof.txt

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
portmap 1522 rpc 3u IPv4 1631 UDP *:sunrpc
portmap 1522 rpc 4u IPv4 1634 TCP *:sunrpc (LISTEN)
rpc.statd 1541 rpcuser 4u IPv4 1668 UDP *:32768
rpc.statd 1541 rpcuser 5u IPv4 1658 UDP *:869
rpc.statd 1541 rpcuser 6u IPv4 1671 TCP *:32768 (LISTEN)
cupsd 1662 root 2u IPv4 2235 UDP *:ipp
cupsd 1662 root 3u IPv4 3039 TCP pegaso:ipp->pegaso:32771 (ESTABLISHED)
sshd 1702 root 3u IPv4 2256 TCP *:ssh (LISTEN)
xinetd 1716 root 5u IPv4 2297 TCP pegaso:32769 (LISTEN)
sendmail 1742 root 4u IPv4 2406 TCP pegaso:smtp (LISTEN)
X 1883 root 1u IPv4 2604 TCP *:x11 (LISTEN)
fam 1978 root 0u IPv4 2297 TCP pegaso:32769 (LISTEN)
fam 1978 root 1u IPv4 2297 TCP pegaso:32769 (LISTEN)
ggcups 1996 root 14u IPv4 3038 TCP pegaso:32771->pegaso:ipp (ESTABLISHED)
Como “lsof “ muestra los archivos abiertos , también se puede utilizar para identificar programas
sniffer ilícitos utilizando cuentas y passwords válidos robados. El atacante no querrá sobrescribir
los datos que ha capturado, por lo que los archivos serán fáciles de obtener[36].
Capturando información del sistema de archivos /PROC
El sistema de archivos /proc es un pseudo sistema que es usado como una interfaz a la estructura
de datos del kernel. Cambiándose al directorio /proc realmente se está accediendo a las
estructuras de datos del kernel, no a un directorio verdadero. Cada proceso tiene un subdirectorio
en /proc que corresponde a su ID. Por lo que cada proceso corriendo tendrá un subdirectorio
numérico. El sistema de archivos /proc es prácticamente la representación de todo nuestro
sistema en texto, los archivos y directorios bajo /proc contienen datos sobre cantidad de memoria,
procesos que están corriendo en el sistema y sockets.
# /mnt/cdrom/ls /proc > /mnt/floppy/proc.txt

1 13 1492 1496 1522 1541 1597 1621 1662 1702 1716 1742
1751 1761 1770 1800 1809 1823 1824 1825 1826 1827 1828 1829
1882 1883 1892 1958 1968 1971 1973 1978 1985 1989 1991 1993
1996 1998 2 2000 2001 2006 2008 2009 2010 2054 3 4
5 6 68 7 8 9 apm bus cmdline cpuinfocrypto devices
dma driver exec domains fb filesystems fs ide interrupts iomem
ioports irq kcore kmsg ksyms loadavg locks mdstat meminfo misc modules
mounts mtrr net partitions pci self slabinfo stat swaps sys
sysrq-trigger sysvipc tty uptime version
119
Detectando y capturando un proceso sospechoso
En el caso de contar con tiempo para capturar información en vivo, podemos obtener información
de un proceso identificado como sospechoso, en el siguiente orden:
1) Identificar el proceso sospechoso

2) Listar el ID en el FS /proc/<pid>
3) Copiar el archivo binario
4) Identificar la línea de comandos del proceso
Ejemplo:
1.- Identificamos el proceso sospechoso con el comando “ps”
#ps –aux
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 08:01 ? 00:00:04 init
root 2 1 0 08:01 ? 00:00:00 [keventd]
root 3 1 0 08:01 ? 00:00:00 [kapmd]
root 970 1 0 08:02 ? 00:00:00 proc_sosp
rpc 1525 1 0 08:02 ? 00:00:00 portmap
rpcuser 1544 1 0 08:02 ? 00:00:00 rpc.statd
root 1600 1 0 08:02 ? 00:00:00 /sbin/cardmgr
root 1624 1 0 08:02 ? 00:00:00 /usr/sbin/apmd -p 10 -w 5 -W -P
2.- Nos cambiamos al directorio /proc del ID del proceso

#cd /proc/970
#ls -al
total 0
dr-xr-xr-x 3 root root 0 Oct 10 10:33 .
dr-xr-xr-x 68 root root 0 Oct 10 03:01 ..
-r--r--r-- 1 root root 0 Oct 10 10:41 cmdline
lrwxrwxrwx 1 root root 0 Oct 10 10:41 cwd -> /
-r-------- 1 root root 0 Oct 10 10:41 environ
lrwxrwxrwx 1 root root 0 Oct 10 10:41 exe
dr-x------ 2 root root 0 Oct 10 10:41 fd
-r--r----- 1 root root 0 Oct 10 10:41 maps
-rw------- 1 root root 0 Oct 10 10:41 mem
-r--r--r-- 1 root root 0 Oct 10 10:41 mounts
lrwxrwxrwx 1 root root 0 Oct 10 10:41 root -> /
-r--r--r-- 1 root root 0 Oct 10 10:41 stat
-r--r--r-- 1 root root 0 Oct 10 10:41 statm
-r--r--r-- 1 root root 0 Oct 10 10:41 status
3.- Copiamos el archivo binario. La información más significativa se puede encontrar en el

directorio “fd”, la liga “exe” y el archivo “cmdline”.
120
La liga exe permite al investigador recuperar los archivos borrados que aún siguen corriendo. Por
ejemplo, si se ejecutó el siguiente comando:
# rm /root/ir/proc_sosp
rm: remove ‘/root/ir/proc_sosp?y
Aunque se haya removido el programa sospechoso, éste está ligado al sistema de archivos. El
comando “ls” no mostrará el archivo en el FS, sin embargo, en el contenido del directorio
/proc/970, se verá la siguiente salida:
970# ls –al
lrwx------- 1 root root 0 Apr 5 20:13 exe -> /root/ir/proc_sosp (deleted).
Se puede usar el comando “cp” para crear una copia del ejecutable corriendo en el sistema de
archivos.
En el subdirectorio “fd” (file descriptor), se pueden identificar todos los procesos que un archivo
ha abierto. Cuando el kernel de Linux, abre, lee, escribe o crea un archivo o socket de red, este
regresa un “file descriptor” (un entero positivo) que es usado para referenciar el archivo o socket
de red. Se pueden ignorar los fd 0, 1 y 2 que son “file descriptors” predefinidos para la salida o
entrada estándar.
fd# ls –la
lrwx------- 1 root root 64 Apr 5 20:12 1 -> /dev/pts/4

lrwx------- 1 root root 64 Apr 5 20:12 4 -> socket: [1359]
El archivo “cmdline” muestra los argumentos exactos de la línea de comandos usados para correr
dicha aplicación. Normalmente, este es desplegado cuando un usuario ejecuta un comando “ps”.
Para desplegar su contenido tecleamos:
# cat cmdline
nautilus --no-default-window --sm-client-id default3
PASO 4: QUIEN ESTÁ EN EL SISTEMA
Determinar quien está en el sistema es un poco más simple. Solo ejecutamos el comando “w”
(what), y desplegará los IDs de usuarios conectados, de que sistemas están entrando y que están
ejecutando. También provee la hora y fecha del sistema:
# /mnt/cdrom/w > /mnt/floppy/w.txt
Ejemplo de salida del comando

121
11:01:55 up 3:00, 3 users, load average: 0.08, 0.04, 0.04

USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root :0 - 8:02am ? 0.00s 0.94s /usr/bin/gnome-
root pts/0 :0.0 8:04am 0.00s 2.98s 0.04s w
root pts/1 :0.0 10:11am 48:33 0.23s 0.23s bash
La línea de cabecera indica la hora actual del sistema, cuánto tiempo el sistema ha estado arriba y
cuántos usuarios están actualmente conectados
El comando para determinar si la interfaz está en modo promiscuo es “ifconfig”:
# /mnt/cdrom/ifconfig –a > /mnt/floppy/ifconfig.txt
eth0 Link encap:Ethernet HWaddr 00:00:39:77:E3:C6

inet addr:172.29.69.111 Bcast:172.29.69.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3088 errors:0 dropped:0 overruns:0 frame:0
TX packets:174 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:338230 (330.3 Kb) TX bytes:67384 (65.8 Kb)
Interrupt:11 Base address:0xef40 Memory:f7efe000-f7efe038
lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:3503 errors:0 dropped:0 overruns:0 frame:0
TX packets:3503 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:364926 (356.3 Kb) TX bytes:364926 (356.3 Kb)
Si la tarjeta se descubre en modo promiscuo, se puede suponer que existe un sniffer en el sistema
bajo análisis que eleva la severidad del ataque. Esto sugiere que el sistema comprometido no es
únicamente ese, también significa que el atacante tiene acceso a nivel de root [36].
Para obtener el nombre del sistema y el tiempo que ha estado levantado tecleamos los siguientes
comandos:
# /mnt/cdrom/hostname > /mnt/floppy/hostname.txt

# /mnt/cdrom/uptime > /mnt/floppy/uptime.txt
PASO 5: DESCARGA DE MEMORIA
En el caso de Linux a diferencia de Windows no es necesario reiniciar el equipo para obtener una
copia de la memoria RAM, por lo que en este caso intercambiamos el paso 5 por el paso 6.
122
No existen muchas formas de descargar la memoria RAM en máquinas Linux. Normalmente se

transfiere el archivo /proc/mem o /proc/kcore del sistema bajo análisis. Este archivo contiene el
sistema RAM en un arreglo no continuo.
El comando dd es parte de el paquete fileutils de Red Hat, lo podemos utilizar para crear una
imagen o copia exacta de un archivo. Para copiar directamente el dispositivo de memoria
utilizamos la siguiente sintaxis:
# mnt/cdrom/dd if=/dev/mem of=/dev/fd0/image_memory
129024+0 records in
129024+0 records out
# ls –l image_memory
-rw-r--r-- 1 root 66060288 Sep 25 18:27 image_memory
El tipo de archivo obtenido no se puede leer con un “cat” normal, pero se puede utilizar el
comando “string” para obtener los caracteres entendibles y mandarlos a un archivo que después
podamos analizar con tiempo.
# string image_memory > resultado
Utilizando GDB para capturar memoria
GDB puede estar ejecutándose en la misma máquina o remotamente, en algún dispositivo externo
de solo lectura.
Para invocar gdb:
[root@luna gdb-6.0]# gdb

GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
(gdb)
Dentro de GDB los comandos dump, append y restore copian datos entre memoria y archivos.
Los comandos dump y append escriben datos a un archivo, y el comando restore lee los datos del
archivo para regresarlos a memoria. Los archivos pueden estar en formato binario.
(gdb) dump memory descarga 0x00000 0xFFFFF

123
El comando anterior vacía el contenido de la memoria desde start_addr (0x00000) hasta

end_addr(0xFFFFF).
PASO 6: REGISTRO DE TIEMPO
Nuevamente como en el paso 2 volvemos a tomar el registro de tiempo del sistema y de los
archivos, para saber que archivos pudimos haber modificado durante la recolección de
información:
# /mnt/cdrom/date > /mnt/floppy/date_end.txt

# /mnt/cdrom/ls –alRu > /mnt/floppy/access_end.txt
# /mnt/cdrom/ls –alRc > /mnt/floppy/modification_end.txt
# /mnt/cdrom/ls –alR > /mnt/floppy/creation_end.txt
PASO 7: DOCUMENTACION
La tabla 4.4 muestra los pasos que se siguieron y los programas que se utilizaron para llevar a
cabo cada paso. Esto nos ayudará a documentar todos los pasos realizados:
Pasos Acciones Comandos

Linux
1 Línea de comandos seguros Montar el CD con las herramientas mount
Establecer un nuevo shell bash
Definir rutas de binarios y librerías seguros PATH
2 Registro de Tiempo Obtener el tiempo y fecha del sistema date
Obtener el MAC de todos los archivos ls
3 Estado del sistema Listar los procesos que corren actualmente pstree
Listar los procesos que corren actualmente ps
Obtener los puertos abiertos netstat
Listar los archivos abiertos lsof
Capturando información en el FS proc /proc
Para un solo proceso sospechoso
Listar los procesos ps –aux
Identificar el ID en el FS /proc /proc/ID
Copiar el archivo binario /proc/ID/exe
Identificar las líneas de comandos del proceso /proc/ID/cmdline
4 Quien esta en el sistema Determinar quien está dentro del sistema w
Información de la tarjeta de red ifconfig
Nombre del equipo hostname
Tiempo que el sistema ha estado levantado uptime
5 Copia de la memoria Captura de la memoria física dd, /dev/mem
dd, /dev/kmem
6 Registro de tiempo Obtener el tiempo y fecha del sistema date
Time stamp, tiempo de creación de los archivos ls
124

Linux
7 Documentación Identificar y documentar los pasos
Registro de integridad md5
Automatizar la recolección bash script
Registro de integridad
A cada uno de los comandos aplicados se le debe generar un registro de integridad de la

evidencia original para validarla. Para lo cual podemos utilizar “md5sum”:
# /mnt/cdrom/md5sum image_mem
166e20b346bff5b030cbf07b3f4963718 image_mem
Automatizar la recolección
En este caso también se puede realizar un script que automatice todos los pasos realizados y la
recolección de información sea más rápida. Lo importante es estar seguro de que cualquier
archivo creado o copiado por un script esté en un medio seguro.
Para realizar un script en Linux creamos el siguiente archivo:
# !/bin/bash
# SCRIPT DE RECOLECCIÓN DE INFORMACIÓN
# PASO 2: REGISTRO DE TIEMPO
/mnt/cdrom/date > /mnt/floppy/date_start.txt

/mnt/cdrom/md5sum date_start.txt > date_start.md5
/mnt/cdrom/ls –alRu > /mnt/floppy/access_start.txt
/mnt/cdrom/md5sum access_start.txt > access_start.md5
/mnt/cdrom/ls –alRc > /mnt/floppy/modification_start.txt
/mnt/cdrom/md5sum modification_start.txt > modification_start.md5
/mnt/cdrom/ls –alR > /mnt/floppy/creation_start.txt
/mnt/cdrom/md5sum creation_start.txt > creation_start.md5
# PASO 3: ESTADO DEL SISTEMA
/mnt/cdrom/pstree –pla > /mnt/floppy/pstree.txt

/mnt/cdrom/md5sum pstree.txt > pstree.md5
/mnt/cdrom/ps –Auxw > /mnt/floppy/procesos.txt
/mnt/cdrom/md5sum procesos.txt > procesos.md5
/mnt/cdrom/netstat –anp > /mnt/floppy/netstat.txt
/mnt/cdrom/md5sum netstat.txt > netstat.md5
/mnt/cdrom/lsof > /mnt/floppy/lsof.txt
/mnt/cdrom/md5sum lsof.txt > lsof.md5
/mnt/cdrom/ls /proc > /mnt/floppy/proc.txt
/mnt/cdrom/md5sum proc.txt > proc.md5
# PASO 4: QUIEN ESTA EN EL SISTEMA
/mnt/cdrom/w > /mnt/floppy/w.txt

/mnt/cdrom/md5sum w.txt > w.md5
/mnt/cdrom/ifconfig –a > /mnt/floppy/ifconfig.txt
/mnt/cdrom/md5sum ifconfig.txt > ifconfig.md5
/mnt/cdrom/hostname > /mnt/floppy/hostname.txt
125
/mnt/cdrom/md5sum hostname.txt > /mnt/floppy/hostname.md5

/mnt/cdrom/uptime > /mnt/floppy/uptime.txt
/mnt/cdrom/md5sum uptime.txt > /mnt/floppy/uptime.md5
# PASO 5: COPIA DE MEMORIA
/mnt/cdrom/dd if=/dev/mem of=/dev/fd0/image_memory.txt

/mnt/cdrom/md5sum image_memory.txt > image_memory.md5
# PASO 6: REGISTRO DE TIEMPO
/mnt/cdrom/date > /mnt/floppy/date_end.txt

/mnt/cdrom/md5sum date_end.txt > date_end.md5
/mnt/cdrom/ls –alRu > /mnt/floppy/access_end.txt
/mnt/cdrom/md5sum access_end.txt > access_end.md5
/mnt/cdrom/ls –alRc > /mnt/floppy/modification_end.txt
/mnt/cdrom/md5sum modification_end.txt > modification_end.md5
/mnt/cdrom/ls –alR > /mnt/floppy/creation_end.txt
/mnt/cdrom/md5sum creation_end.txt > creation_end.md5
El script contiene todos y cada uno de los pasos ejecutados, esto también puede ser una referencia
de documentación del proceso.
126

LINUX A TRAVÉS DE RED
Las condiciones bajo las cuales se aplicará la metodología en este caso serán sobre un sistema
vivo, el tipo de acceso que se tendrá al sistema será local y la información se recolectará a través
de la red, el sistema operativo con el que se enfrentará el investigador será Linux Red Hat
Enterprise y se contará con el password de acceso. La siguiente figura muestra el tipo de caso a
tratar.
VIVO Estado MUERTO

del
sistema

acceso al
sistema
(ejemplos)
CASO 5:
Captura de CASO 2: CASO 4: CASO 1: CASO 3: Grave_robber
paquetes Windows Windows Linux
Analizador Linux Linux
Fig. 4.8 Caso 4: Aplicación de la metodología a través de la red con Linux
El equipo bajo sospecha puede ser un servidor o estación de trabajo conectado a red, por lo que la
información recolectada puede ser enviada a través de la red misma a una estación segura,
complementando la información con un equipo analizador de paquetes conectado a la misma red,
como se observa en la figura 4.9.
Equipo comprometido Estación forense
Linux Linux
Conexión segura Fig. 4.9

Investigador
forense Diagrama de
oooooooo conexión:
Monitor
Caso 4
de red
127
Por lo que en este caso se conectarán dos equipos seguros la estación forense para recopilar
información y el equipo de monitoreo que en forma paralela estará capturando los paquetes que
circulen por la red.
MONITOREO DE RED
Para obtener datos de un sistema vivo, podemos correr un analizador de paquetes de red (network
sniffer) y observar el flujo de información para y desde el equipo comprometido, así, podemos
detectar algún tipo de actividad maliciosa, grabando y analizando en tiempo real su
comunicación.
Para capturar el tráfico del equipo sospechoso configuramos el switch donde esta conectado el
equipo para que envíe una copia del tráfico de ese puerto al puerto donde tenemos colocado
nuestro analizador de red. Para que esto se pueda realizar el switch debe tener disponible en los
puertos la técnica “Port Mirror” para que se pueda realizar esta acción.
El analizador de red que podemos utilizar es Ethereal que viene instalado en la versión de Red
Hat con la que estamos trabajando, a continuación presentamos las ventanas para correr una
captura de paquetes. Toda esta información puede ser guardada a un archivo que puede analizarse
posteriormente:
Fig. 4.10 Pantallas Ethereal

128
Fig. 4.10 Pantallas Ethereal
Una vez mostrada la forma de obtener los datos a través de un equipo de monitoreo podemos
empezar a aplicar los pasos de la metodología planteada:
PASO 1: ESTABLECIENDO UNA CONEXIÓN SEGURA
En este paso primero haremos disponible el conjunto de herramientas confiable, éste se montará
en el sistema comprometido. Por lo que vamos a usar el comando “mount” no confiable de ese
sistema para realizar esta tarea, esperando que sea el único comando no confiable que habremos
de correr.
Para verificar el impacto que el comando “mount” tendrá en el sistema podemos utilizar el
comando “strace” del sistema operativo que nos ayuda a identificar los archivos y directorios que
son modificados al aplicar el comando “mount”:
#strace /bin/mount /mnt/cdrom
execve("/bin/mount", ["/bin/mount", "/mnt/cdrom"], [/* 32 vars */]) = 0

uname({sys="Linux", node="pegaso", ...}) = 0
brk(0) = 0x8059cc0
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=65998, ...}) = 0
old_mmap(NULL, 65998, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb75da000
close(3) = 0
open("/lib/tls/libc.so.6", O_RDONLY) = 3
..
129
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
..
lstat64("/etc/mtab", {st_mode=S_IFREG|0644, st_size=156, ...}) = 0
..
open("/etc/fstab", O_RDONLY|O_LARGEFILE) = 3
..
mount("/dev/cdrom", "/mnt/cdrom", "udf", MS_RDONLY|MS_NOSUID|MS_NODEV|0xc0ed0000, 0x805bb20) = -1
ENODEV (No such device)
Concluimos que los archivos que se modifican son:
/etc/ld.so.cache
/lib/tls/libc.so.6
/usr/lib/locale-archive
/etc/fstab
/etc/mtab
/dev/cdrom
/bin/mount
Es evidente que este procedimiento debe haberse realizado antes de aplicar la metodología en una
investigación.
Como ya sabemos los archivos que se modificarán al utilizar el comando “mount” no confiable,
procedemos a montar el CDROM con el toolkit creado:
(comprometido)# mount –n /mnt/cdrom
La opción –n monta sin escribir en el archivo /etc/mtab.

Una vez montado el CD con las herramientas establecemos un shell seguro:
(host comprometido) # /mnt/cdrom/./bash
(host comprometido) # /mnt/cdrom/PATH=.
PASO 2: REGISTRO DEL TIEMPO
Enviamos información de la fecha y hora del sistema comprometido a la estación forense que
almacenará los datos (en este caso 192.29.69.69) a través de “netcat” por el puerto 2222 como
sigue:
(forense) # nc –l –p 2222 > datos_recolectados
En el host comprometido aplicamos los comandos, direccionándo la salida a la estación forense:

(comprometido)# /mnt/cdrom/statbins/./date | /mnt/cdrom/./nc 192.29.69.69 2222
Para mantener la integridad de la evidencia digital, calculamos el valor “hash” del archivo
recolectado.
130
(forense)# md5sum datos_recolectados > datos_recolectados.md5
Para tomar la hora del sistema utilizamos el mismo comando “date” con la opción “-u”, el
resultado es presentado en el formato UTC (Coordinated Universal Time)
(forense) # nc –l –p 2222 > start_time

(comprometido)# /mnt/cdrom/statbins/./date –u | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense) # md5sum start_time > start_time.md5
A continuación tomamos una referencia de tiempo de todos los archivos en el sistema (time
stamp) con el comando “mactime” para tener un control de lo que habremos de modificar en la
recolección de información:
(forense) # nc –l –p 2222 > mactime.txt

(comprometido)# /mnt/cdrom/statbins/./mactime –y –R –d / /mnt/cdrom/statbins/./nc 172.29.69.69
2222
(forense) # md5sum mactime.txt > mactime_txt.md5
También lo podemos hacer con el comando “ls” con sus opciones “c” que muestra modificación
del inodo, “u” del último acceso y sin parámetro la fecha de modificación del estado del archivo
o de creación del archivo.
(forense)# nc -l -p 2222 > maChange

(comprometido)#/mnt/cdrom/statbins/./ls –lRc / | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense)# md5sum maChange > maChange.md5
(forense)# nc -l -p 2222 > mAccesc

(comprometido)#/mnt/cdrom/statbins/./ls –lRu / | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense)# md5sum mAccesc > mAccesc.md5
(forense)# nc -l -p 2222 > Modifyac

(comprometido)#/mnt/cdrom/statbins/./ls –lR / | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense)# md5sum Modifyac > Modifyac.md5
PASO 3: ESTADO DEL SISTEMA
Acción 1: La lista de los procesos activos
La información acerca de los procesos, puertos y archivos abiertos puede ser recolectada por la
herramienta “lsof”.
(forense)# nc -l -p 2222 > lsof

(comprometido)#/mnt/cdrom/statbins/./lsof -n -P -l | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense)# md5sum lsof > lsof.md5
Acción 2: Listar los módulos cargados en la memoria del kernel de un SO

131
Listar el directorio “modules” dentro de /proc nos puede servir para observar qué módulos están
cargados en memoria y poder detectar si tenemos un rootkit instalado. Algunas veces los rootkits
débiles pueden exportar sus símbolos, que se encuentran en el directorio “ksyms” de /proc por lo
que procedemos a obtener todo el sistema /proc de la siguiente manera:
(forense)#nc -l -p 2222 > proc

(comprometido)#/mnt/cdrom/statbins/./cat /proc | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense)# md5sum proc > proc.md5
Acción 3: Nombre y tiempo del sistema
Para obtener el nombre del sistema utilizamos el comando hostname
(forense) # nc –l –p 2222 > hostname

(comprometido)# /mnt/cdrom/statbins/./hostname | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense) # md5sum hostname > hostname.md5
Para obtener el tiempo que ha estado levantado el sistema utilizamos el comando uptime:
(forense) # nc –l –p 2222 > uptime
(comprometido)# /mnt/cdrom/statbins/./uptime | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense) # md5sum uptime > uptime.md5
Recolectando un proceso sospechoso
Si algunos de los procesos activos son sospechosos podemos obtener información específica de
ese proceso o tal vez recuperarlo. Copiando un proceso particular podemos separar de mejor
manera los datos maliciosos de la memoria del sistema comprometido
El primer paso es listar los procesos que están corriendo:
(comprometido)#/mnt/cdrom/statbins/./ps -aux
Con “lsof” podemos listar las conexiones y archivos abiertos por el proceso:
(comprometido)#/mnt/cdrom/statbins/./lsof -p proc_id
Observar el proceso, registrando las llamadas a sistema y señales del proceso
(comprometido)#/mnt/cdrom/statbins/./strace -p proc_id
Registrar las llamadas a rutinas (librerías) que realiza el proceso

132
(comprometido)#/mnt/cdrom/statbins/./ltrace -p proc_id
Una vez identificado el proceso sospechoso. Utilizamos la herramienta “pcat” para copiar la
memoria del proceso.
(comprometido)#/mnt/cdrom/statbins/./pcat proc_id > mem_proces_ID.txt
PASO 4: QUIEN ESTÁ EN EL SISTEMA
Información de Cache
Primero recolectamos información de la tabla cache por el tiempo de vida de estos datos (que es
muy corto). Recolectamos datos de las tablas de ruteo y arp.
Tabla cache de direcciones MAC:
(forense) # nc –l –p 2222 > arp

(comprometido) # /mnt/cdrom/statbins/./arp –an | mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense) # md5sum arp > arp.md5
Tabla cache del ruteo IP del Kernel:

(forense) # nc –l –p 2222 > route
(comprometido) # /mnt/cdrom/statbins/./route –Cn | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense) # md5sum route > route.md5
C=Operar en el cache de ruteo del Kernel

N=Mostrar las direcciones numéricas
Conexiones actuales, pendientes y puertos TCP/UDP abiertos
Recolectamos las conexiones y puertos abierto con el comando “netstat”:
(forense) # nc –l –p 2222 > netstat.txt

(comprometido) # /mnt/cdrom/statbins/./netstat –an | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense) # md5sum netstat.txt > netstat_txt.md5
También se puede utilizar el comando “cat” en vez de “netstat” con la información de puertos
abiertos que es almacenada en el sistema de archivos proc (Archivos: /proc/net/tcp y
/proc/net/udp). La información de la conexiones activas se encuentra en el archivo
/proc/net/netstat. Todos los datos en estos archivos se presentan en formato hexadecimal, por
ejemplo la dirección 0100007F:0401 en decimal es 127.0.0.1:1025. Las conexiones activas
también pueden ser detectadas por el analizador de tráfico.
133
Para obtener la dirección de red tecleamos lo siguiente:
(forense) # nc –l –p 2222 > ifconfig

(comprometido)# /mnt/cdrom/statbins/./ifconfig -a | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense) # md5sum ifconfig > ifconfig.md5
PASO 5: IMAGEN DE MEMORIA
Se puede obtener la memoria física copiando directamente el dispositivo /dev/mem como lo

hicimos en el caso anterior, pero también podemos hacerlo a través del archivo kcore. Este
archivo representa la RAM en un sistema operativo Linux, es encontrado en el directorio /proc,
su tamaño es igual al de la memoria física, la ventaja de utilizar kcore es que este archivo tiene
formato ELF, por lo que puede ser depurado fácilmente con la herramienta “gdb”.
Utilizar una computadora remota como en este caso puede ser la mejor manera de salvar datos
con un mínimo de modificación sobre la memoria.
(remoto)# nc -l -p 2222 > kcore

(comprometido)# /mnt/cdrom/statbins/./dd < /proc/kcore | /mnt/cdrom/statbins/./nc 172.29.69.69
2222
(remoto)# md5sum kcore > kcore.md5
Cuando copiamos todo el sistema de memoria, se copian los datos colocados y los no colocados
(allocated/unallocated) porque el proceso copia la imagen entera de la memoria física.
También se puede utilizar memdump para obtener una imagen de la memoria sin reinicializar el
sistema y puede ser transferido por la red con netcat o ssl:
(forense)# nc -l -p 2222 > memdump

(comprometido)# /mnt/cdrom/statbins/./memdump | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense)# md5sum memdump > memdump.md5
Sintaxis para ssl:
(forense)# memdump | openssl s_client –connect host:port
También podemos copiar la información en la memoria swap. La forma más fácil de copiar este
tipo de memoria es con un “cat” o “dd” al dispositivo de archivos en cuestión.
(forense)# /mnt/cdrom/statbins/./swapon –s
Filename Type Size Used Priority
/dev/hda3 partition 449812 0 -1
(forense)# /mnt/cdrom/statbins/./cat /dev/hda3 >> swap_cap.file

134
PASO 6: 2º. REGISTRO DE TIEMPO
Después de finalizar la recolección de información, nuevamente registramos la hora del sistema.
(forense)#nc -l -p 2222 > end_time

(comprometido)# /mnt/cdrom/statbins/./date | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
Para tomar un registro de tiempo de todos los archivos utilizamos los comandos “ls” o “mactime”
como lo hicimos en el paso 2.
(forense) # nc –l –p 2222 > end_time

(comprometido)# /mnt/cdrom/statbins/./date –u | /mnt/cdrom/statbins/./nc 172.29.69.69 2222
(forense) # md5sum start_time > end_time.md5
(forense) # nc –l –p 2222 > mactime_end

(comprometido)# /mnt/cdrom/statbins/./mactime –y –R –d / /mnt/cdrom/statbins/./nc 172.29.69.69
2222
(forense) # md5sum mactime.txt > mactime_end.md5
En este punto podemos desconectar de la energía el equipo comprometido. Recordando que no se

deberá utilizar “shut down” o “init”. Deberemos desconectar el cable directamente de la
alimentación de energía.
PASO 7: DOCUMENTACIÓN
La tabla 4.5 muestra los pasos que se siguieron y los programas que se utilizaron y con esta tabla
podemos a empezar a documentar todas nuestras acciones:

Linux
Información obtenida vía la red
Obtener información de red Detectar tráfico anómalo ethereal
Información obtenida localmente

1 Estableciendo una conexión Montar el conjunto de herramientas mount
al sistema Obtener un shell seguro bash
Time stamp de los archivos mactime
Time stamp, tiempo de creación de los archivos ls
3 Quien esta en el sistema Información de cache arp
route
Listar las conexiones y puertos abiertos netstat
Desplegar direcciones IP y físicas ifconfig
4 Estado del sistema Listar los procesos activos lsof
Listar los módulos cargados cat /proc/modules
135

Linux
Símbolos exportados por el modulo kernel cat /proc/ksyms
Nombre del equipo hostname
Tiempo que el sistema ha estado levantado uptime
Para un solo proceso sospechoso
Listar los procesos que corren ps-aux
Lista las conexiones y archivos abiertos lsof –p PID
Observar el proceso strace –p PID
Registrar las llamadas a rutinas (librerías) ltrace –p PID
Copiar el contenido de la memoria del proceso pcat
5 Información de la memoria Obtener una copia de la memoria dd /proc/kcore
memdump
Obtener una copia de la memoria swap swapon
Registro de tiempo de todos los archivos mactime
7 Documentación Documentar los pasos
Nuestro siguiente paso es documentar la información obtenida del sistema comprometido. Esta
información es necesaria para preparar una descripción propia del incidente y realizar una copia
de todo el sistema de archivos. Recordando que todos los resultados tienen que ser enviados a la
estación forense remota. La tabla 4.6 es un resumen de los comandos que conjuntan esa
información:
Tabla 4.6 Documentando: Caso 4
Tiempo Acción Comando aplicado Archivo Confia Salida del

de inicio generado ble md5sum
S N
I O
9:19:20 Montar el mount –n /mnt/cdrom X
CD
9:22:23 Abrir un /mnt/cdrom/statbins/./bash X
shell
9:23:24 Tomar la /mnt/cdrom/statbins/./date -u start_time X 7122f802e1a087
hora del a0b31848f70862
sistema c0d1
9:24:00 Registros /mnt/cdrom/statbins/./mactime – Mactime X aec67122f802e1
MAC de y –R –d / a08727bfa62844
archivos 7285
9:24:25 Modificaci /mnt/cdrom/statbins/./ls –lRc maChange X 89caa702e08cc4
ones del 8301657924f026
inodo del 3cca
archivo
9:25:26 Acceso al /mnt/cdrom/statbins/./ls –lRa mAccesc X cdd5870ee16c46
archivo 0a702e08cc48a7
0ccc
136
Tiempo Acción Comando aplicado Archivo Confia Salida del

de inicio generado ble md5sum
S N
I O
9:26:27 Modificaci /mnt/cdrom/statbins/./ls –lRs Modifyac X 301657924f0263
ones del c7122f802e1a08
estado del 7ade
archivo
9:27:28 Direcciones /mnt/cdrom/statbins/./arp –an arp.md5 X 472854960acebf
MAC 27baec629ba518
4cef
9:27:40 Ruteo IP /mnt/cdrom/statbins/./route –Cn route.md5 X 85027bfa628492
be1743953719ba
8146
9:28:00 Conexiones /mnt/cdrom/statbins/./netstat –an netstat.txt X 2849174ab4395c
y puertos a63859b128462
abiertos 9aef9
9:28:17 Dirección /mnt/cdrom/statbins/./ifconfig -a ifconfig X caa702e08cc480

de red 2e08cc487122f8
70
9:28:29 Procesos lsof -n -P -l lsof X 702e08cc48a702
activos e08cc487122f87
0aaf
9:29:18 Módulos cat /proc/modules lkms X 116798d3a85f14
cargados acdd5870ee16c4
608d
9:30:30 Símbolos cat /proc/ksyms ksyms X e08cc483016579
del kernel 24f0263ca702e0
8cc48
9:31:29 Nombre del /mnt/cdrom/statbins/./hostname hostname X Cc482e1a087a3
equipo 01657924f0263c
22f8e
9:32:22 Tiempo de /mnt/cdrom/statbins/./uptime uptime X Ca89caa702e08c
trabajo del c48a702e022f80
sistema 2e 88
9:33:24 Copia de /mnt/cdrom/statbins/./dd < kcore X C2e1a087a7022f
memoria /proc/kcore 802e2e08cc4871
22f8
9:33:24 Copia de /mnt/cdrom/statbins/./memdump memdump X C2e1a087a7022f
memoria 802e2e08cc4871
22f8
9:50:33 Registro de /mnt/cdrom/statbins/./date end_time X caa702e08cc483
hora 01657924f0222f
802e
9:53:00 Registro de /mnt/cdrom/statbins/./mactime mactime_e X 08cc41653919ae
tiempo de nd 30581bcf193828
los archivos 4677
137
4.6 RECOLECCIÓN DE INFORMACIÓN CON GRAVE-ROBBER: CASO 5
En este caso vamos a aplicar la herramienta forense “grave-robber” de TCT sobre un sistema
“vivo” a través de un acceso local directo en la consola del equipo sospechoso. La figura 4.11
muestra el tipo de caso a tratar:
VIVO Estado MUERTO

del
sistema

acceso al
sistema
(ejemplos)

CASO 5:
Linux
Fig. 4.11 Caso 5: Herramientas forenses “grave robber”
Se trabajará bajo las siguientes condiciones:
• El procedimiento se aplicará a un sistema vivo antes de quitar la energía eléctrica.

• Se accederá al sistema a través de la consola del sistema y no a través de la red.
• El investigador forense se conectará al equipo sospechoso estableciendo una conexión
segura en forma local.
• El sistema operativo del equipo comprometido es Linux (Red Hat Enterprise 3.0)
• Se cuenta con el password de acceso.
• La herramienta forense de captura será “grave-robber” que corre desde un floppy y los
archivos generados serán copiados a una memoria USB.
Las herramientas forenses ya traen incluida su metodología a seguir y sus scripts de recopilación
de información como se mencionó en el capitulo 3. Por lo que los pasos 2, 3, 4, 5 y 6 de la
metodología se realizarán en este caso en un solo paso.
138
PASO 1: ESTABLECIMIENTO DE UNA CONEXIÓN SEGURA
El primer paso será montar la herramienta:
(comprometido)# mount /dev/fd0 /mnt/floppy
Una vez montado el medio con las herramientas establecemos un shell seguro:
(comprometido) # /mnt/floppy/./bash
(comprometido) # /mnt/floppy/PATH=.
Montamos el medio donde se almacenará la información, puede ser el mismo donde tenemos la
herramienta, pero en nuestro caso utilizaremos un stick de memoria:
(comprometido)# mount /dev/sda1 –t vfat /mnt/memstick
Se debe tomar en cuenta que puede que no esté creado el directorio memstick en /mnt
PASOS 2,3,4,5,6: RECOLECCIÓN DE INFORMACIÓN VOLÁTIL DEL SISTEMA
Para una recolección rápida con grave-robber podemos usar las siguientes opciones:
(comprometido)# /mnt/cdrom/tct/bin/grave-robber –d /mnt/memstick –lPstv /
Para una recolección mayor con grave-robber podemos usar las siguientes opciones, auque esta
recolección puede durar horas:
# /tct/bin/grave-robber –d /mnt/memstick –E –v /
A continuación se muestra la información obtenida en el directorio /data cuando aplicamos el

comando de recolección rápida
body
md5|file|st_dev|st_ino|st_mode|st_ls|st_nlink|st_uid|st_gid|st_rdev|st_size|st_atime|…
000|/sbin/arp|770|340184|33261|-rwxr-xr-x|1|0|0|5632|38364|1129561396|…
000|/usr/bin/at|770|567699|35309|-rwsr-xr-x|1|0|0|0|36904|1129560411|…
…st_mtime|st_ctime|st_blksize|st_blocks
…1061824441|1125332924|4096|80
…1063360476|1125333129|4096|80
body.s
139
md5|file|st_dev|st_ino|st_mode|st_ls|st_nlink|st_uid|st_gid|st_rdev|st_size|st_atime…
000|/usr/bin/at|770|567699|35309|-rwsr-xr-x|1|0|0|0|36904|1129560411|…
000|/usr/bin/crontab|770|568049|35309|-rwsr-xr-x|1|0|0|0|110114|1129560234|…
…st_mtime|st_ctime|st_blksize|st_blocks
…1063360476|1125333129|4096|80
…1045661968|1125333199|4096|224
md5_all
Mon Oct 17 14:47:32 CDT 2005
md5_all.md5
d3aacbe1530ee815573d2450c3803144 /home/alicia/foren/tct-1.15/data//pegaso/MD5_all
command.out
Directorio \command_out
17/10/2005 01:47 p.m. 29 arp

17/10/2005 01:47 p.m. 90 arp.md5
17/10/2005 01:47 p.m. 219 df
17/10/2005 01:47 p.m. 89 df.md5
17/10/2005 01:47 p.m. 7,130 dmesg
17/10/2005 01:47 p.m. 92 dmesg.md5
17/10/2005 01:47 p.m. 348 finger
17/10/2005 01:47 p.m. 93 finger.md5
17/10/2005 01:47 p.m. 29 ifconfig
17/10/2005 01:47 p.m. 95 ifconfig.md5
17/10/2005 01:47 p.m. 1,130 ipcs
17/10/2005 01:47 p.m. 91 ipcs.md5
17/10/2005 01:47 p.m. 24,404 ksyms
17/10/2005 01:47 p.m. 92 ksyms.md5
17/10/2005 01:47 p.m. 9,846 last
17/10/2005 01:47 p.m. 91 last.md5
17/10/2005 01:47 p.m. 29 lastcomm
17/10/2005 01:47 p.m. 95 lastcomm.md5
18/10/2005 10:28 a.m. 0 lista.txt
17/10/2005 01:47 p.m. 982 lsmod
17/10/2005 01:47 p.m. 92 lsmod.md5
17/10/2005 01:46 p.m. 161,701 lsof
17/10/2005 01:46 p.m. 91 lsof.md5
17/10/2005 01:46 p.m. 117,631 lsof0
17/10/2005 01:46 p.m. 92 lsof0.md5
17/10/2005 01:46 p.m. 449,467 major_minor
17/10/2005 01:46 p.m. 1,216 netstat-a
17/10/2005 01:46 p.m. 96 netstat-a.md5
17/10/2005 01:46 p.m. 136 netstat-in
17/10/2005 01:46 p.m. 97 netstat-in.md5
17/10/2005 01:47 p.m. 1,216 netstat-na
17/10/2005 01:47 p.m. 97 netstat-na.md5
17/10/2005 01:46 p.m. 520 netstat-rn
17/10/2005 01:46 p.m. 97 netstat-rn.md5
17/10/2005 01:47 p.m. 29 nfsstat
17/10/2005 01:47 p.m. 94 nfsstat.md5
17/10/2005 01:46 p.m. 2,079 ps
17/10/2005 01:46 p.m. 89 ps.md5
17/10/2005 01:47 p.m. 252 rpcinfo
17/10/2005 01:47 p.m. 94 rpcinfo.md5
17/10/2005 01:47 p.m. 29 rpm
17/10/2005 01:47 p.m. 90 rpm.md5
17/10/2005 01:47 p.m. 29 showmount-a
17/10/2005 01:47 p.m. 98 showmount-a.md5
17/10/2005 01:47 p.m. 29 showmount-e
17/10/2005 01:47 p.m. 98 showmount-e.md5
17/10/2005 01:47 p.m. 5,134 top
17/10/2005 01:47 p.m. 90 top.md5
17/10/2005 01:47 p.m. 110 uname
17/10/2005 01:47 p.m. 92 uname.md5
17/10/2005 01:47 p.m. 92 uptime
17/10/2005 01:47 p.m. 93 uptime.md5
17/10/2005 01:47 p.m. 402 w
17/10/2005 01:47 p.m. 88 w.md5
140
17/10/2005 01:47 p.m. 161 who

17/10/2005 01:47 p.m. 90 who.md5
En cada archivo se encuentra el resultado de la ejecución del comando. Por ejemplo en la

aplicación del comando “df” el contenido del archivo es el siguiente:
Mon Oct 17 14:47:08 CDT 2005

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/hda2 7131448 4660160 2109024 69% /
none 119384 0 119384 0% /dev/shm
trust
Directorio \trust
17/10/2005 01:47 p.m. 29 time

17/10/2005 01:47 p.m. 85 time.md5
17/10/2005 01:47 p.m. 415 trust.time
17/10/2005 01:47 p.m. 98 window_systems
17/10/2005 01:47 p.m. 95 window_systems.md5
user_vault
Directorio \user_vault
17/10/2005 01:47 p.m. 87 alicia__home_alicia_.bash_history

17/10/2005 01:47 p.m. 119 alicia__home_alicia_.bash_history.md5
17/10/2005 01:47 p.m. 11,404 operator__root_.bash_history
17/10/2005 01:47 p.m. 114 operator__root_.bash_history.md5
17/10/2005 01:47 p.m. 11,404 root__root_.bash_history
17/10/2005 01:47 p.m. 110 root__root_.bash_history.md5
conf.vault
Directorio \conf_vault
17/10/2005 01:47 p.m. 156 index.html
Paso 7: Documentar
Por lo regular las herramientas forenses traen un sistema de introducción de datos que ordena la
información para cada caso en particular, en el caso de “Autopsy” para iniciar la documentación
de un caso se pide la imagen recopilada del disco. Pero en nuestro caso sólo utilizamos la
herramienta “grave-robber” de “TCT” que obtiene sólo la información volátil en forma de
archivos y no de imágenes. Por lo que utilizaremos para el análisis los archivos generados
directamente por la herramienta.
141
CAPITULO 5
RECUPERACIÓN DE
INFORMACIÓN EN MEMORIA RAM
A TRAVÉS DE PROCEDIMIENTOS
FÍSICOS
142
5. RECUPERACIÓN DE INFORMACIÓN EN MEMORIA

RAM A TRAVÉS DE PROCEDIMIENTOS FÍSICOS.
Se ha mencionado que una de las decisiones a las que se enfrenta el equipo de respuesta a
incidentes es dar de baja o no el sistema para realizar la captura de datos, en el capítulo anterior
se expusieron procedimientos en base a una metodología general para obtener datos de memoria
cuando el sistema permanecía encendido y corriendo sus procesos en forma “normal”.
En este capítulo hablaremos del caso donde el investigador forense encuentra el equipo apagado
o “muerto” y veremos que todavía es posible recuperar algo de la información de la memoria
RAM, por lo que ahora en lugar de utilizar el concepto de captura de datos utilizaremos el
concepto de recuperación de datos.
VIVO Estado MUERTO

del
sistema

acceso al
sistema Recuperación de datos
(ejemplos)
CASO 5:
CASO 2: CASO 4: CASO 1: CASO 3: Grave_robber
Windows Linux Windows Linux Linux
Fig. 5.1 Recuperación de datos en un sistema “muerto”

143
Para mostrar esto, daremos una introducción a los problemas en semiconductores que pueden
generar que se guarde algo de información en las memorias y mostraremos nueve ejemplos de
recuperación de datos de la memoria RAM utilizando métodos físicos:
1. Retención de datos en base a la temperatura

2. Recuperación de datos en base al estrés generado en los transistores de una celda SRAM
3. Recuperación de datos en base al estrés del óxido en el capacitor dieléctrico
4. Recuperación de datos utilizando pruebas de estrés: “Burn in” e “Iddq”
5. Recuperación de datos en base a la alteración del estado preferente de encendido de una
celda SRAM
6. Recuperación de datos en smart cards en base al análisis de parámetros
7. Recuperación de datos en smart cards utilizando métodos invasivos
8. Lectura óptica de una SRAM CMOS
9. Prueba electromagnética en smartcards
Es importante mencionar que estos ejemplos han sido realizados en microcontroladores y tarjetas
“smartcards” por Universidades y centros de investigación especializados en semiconductores y
seguridad.
Durante esta investigación no se plantea una metodología para recuperar información volátil en
un sistema que ha sido apagado, pero estos ejemplos muestran la posibilidad de que aún se puede
obtener información de memoria en equipos donde se ha eliminado la energía eléctrica y que
pueden ser aplicados en alguna computadora o estación de trabajo que esté bajo una investigación
forense.
5.1 INTRODUCCIÓN
“Contrario a lo que se sabe, la memoria semiconductora “volátil” no pierde completamente su

contenido cuando la energía es removida”. Esto es debido a la remanencia en el dispositivo.
“Ambas memorias SRAM y DRAM retienen algo de información de los datos almacenados
cuando la energía era aplicada”, esto es lo que expresa el doctor e investigador del departamento
144
de Ciencias Computacionales de la Universidad de Auckland Peter Gutman en su artículo

“Secure Deletion of Data from Magnetic and Solid-Sate Memory” [19].
La remanencia es la representación física residual del dato que ha sido borrado de alguna forma.
Después de que un medio de almacenamiento es borrado existen algunas características físicas
que permiten al dato ser reconstruido [28].
Algunas veces durante el ciclo de vida de un sistema de información, su unidad de

almacenamiento primario o secundario puede ser reutilizada, destruida o liberada. Es importante
que los oficiales de seguridad, operadores de computadoras u otros usuarios de estos recursos
estén informados de los riesgos que corren. Se deben utilizar procedimientos para prevenir la
revelación de información “sensitiva” que se haya almacenado en el medio.
El problema de la remanencia fue reconocido desde el año 1960. Se encontró que sin la
aplicación de procedimientos seguros de borrado de datos, la información sensitiva podía ser
revelada en un ambiente controlado. La remanencia de datos puede ocurrir en todos los
dispositivos semiconductores, es difícil de contrarrestar porque depende grandemente de las
características y defectos de los semiconductores.
El concepto de la remanencia se ha estudiado como un problema. Pero para nuestro caso, donde
lo que buscamos es una pista de información remanente en los dispositivos semiconductores esto
se vuelve más que un problema una solución.
5.2 DEFECTOS FÍSICOS EN LOS DISPOSITIVOS DE MEMORIA
Desde mediados de los 90’s la demanda de confiabilidad y tolerancia a fallas en memorias

semiconductoras ha crecido. Con la constante miniaturización de los transistores MOSFET o
MOS, las memorias se han vuelto vulnerables a variaciones resultado del bajo rendimiento de
manufacturación y confiabilidad. Asociados a estas variaciones se encuentran varia fallas
paramétricas como lo son fugas de corriente en el óxido de la compuerta (gate oxide) y cambios
en los umbrales de voltaje, ataques de iones, de partículas alfa, de neutrones o radiación cósmica
145
que pueden causar un trastorno en el almacenamiento de los datos. Otros efectos simples como la
ruptura de una compuerta pueden destruir el dispositivo.
Algunos de los problemas que acompañan las nuevas generaciones de memoria debido a la
miniaturización de los dispositivos son [35]:
1) Problemas de energía (supply voltaje and power constraints)
Para realizar un escalamiento confiable es necesario mantener el campo eléctrico constante en los
dispositivos mientras las dimensiones disminuyen. Sin embargo, reducir la alimentación de
voltaje asocia problemas de retraso y estandarización en el chip. Por lo que la alimentación de
voltaje se ha reducido tradicionalmente en un factor mas pequeño que el espesor del óxido de la
compuerta, produciendo una gran fuerza en el campo del óxido de la compuerta (gate oxide).
3) Confiabilidad del oxido de la compuerta
La confiabilidad del óxido de la compuerta (gate oxide) es afectada por defectos físicos durante la
fabricación, como el espesor del óxido que puede incrementar las fuerzas del campo eléctrico.
Este espesor del óxido abajo de los 4nm 3 produce una corriente en el óxido que pueden aumentar
los campos eléctricos, la temperatura y causar rupturas.
4) Degradación Hot Carrier
Se sabe que los efectos por inyección de portadoras aceleradas (hot carrier) pueden causar
sobrecarga de portadoras en el substrato, degradación del tiempo de refresco de la DRAM y en
algunos casos ruptura de los transistores MOSFET. Existe un decremento exponencial de los hot
carriers con respecto a la alimentación de voltaje. Por lo que la degradación por hot carrier no
afecta en gran medida a las DRAMs en el rango de los gigabits que tratan la alimentación de
voltaje de menos de 1V. Sin embargo, voltajes por arriba de éste pueden incrementar la
probabilidad de la degradación.
3
nm= nanómetro, unidad de longitud que equivale a una milmillonésmina parte de un metro, 1nm=1x10-9 m
146
Compuerta/ Gate/Base
Compuerta- Gate
Fuente/source/Emisor Drenado/drain/colector
Barrera de
Aislamiento
o Tipo n Tipo n
Tamperproof
Substrato tipo p Fuente Drenador
coating
o Substrato tipo p
Capa de
pasivación
Contacto ohmico
Diagrama físico Esquema simbólico
Fig. 5.2 Transistor MOSFET
5) Descargas electrostáticas y sobrestrés eléctrico
Las descargas electrostáticas y el sobrestrés eléctrico puede originar electricidad estática por el
cuerpo humano o por el ambiente en equipos mal aterrizados, esto puede generar rupturas en la
capa delgada de la compuerta (gate oxide). La fuerza del campo eléctrico requerido para romper
el SiO2 es cerca de 10 MV/cm. En años recientes los MOSFET se han hecho más sensibles a las
descargas. En chips con protección a estas descargas se coloca una circuitería de protección en
los pines I/O para proteger el dispositivo de picos de voltaje.
6) Confiabilidad de la metalización
En el proceso de escalación, la corriente de saturación del drenador del MOSFET se incrementa

moderadamente debido a la reducción significante del voltaje efectivo de la compuerta (gate), por
el bajo voltaje de alimentación. En primera instancia se podría esperar que un pequeño
incremento en la corriente del drenador no representa un problema serio de electromigración en
líneas de metal llevando esta corriente, sin embargo, la presencia de granos limitantes en todo el
ancho de la línea puede causar regiones localizadas de densidad de corriente incrementada y
vulnerabilidades de electromigración. La migración de estrés representa un problema de
confiabilidad en la metalización para tecnologías de escalación. La migración de estrés es estrés
mecánico que causa la difusión de iones de metal y crea vacíos. No es independiente de la
electromigración, la migración de estrés es causada por el desajuste entre el coeficiente térmico
de expansión de la línea de metal y del aislador.
147
La electromigración, la migración de estrés (stress migration) y la contaminación en el metal con

elementos radiactivos como uranio y torio, compromete la confiabilidad de la metalización.
5.3 RECUPERACIÓN DE DATOS
En la construcción de los circuitos integrados (CI) los problemas derivados de la miniaturización

producen defectos físicos que pueden ocurrir durante varios estados de fabricación desde la
formación del cristal de Si, la oxidación, la difusión, litografía óptica, metalización y
empaquetación. Aunque se han desarrollado técnicas, materiales y procesos para reducir estos
problemas, estos defectos pueden ser aprovechados por atacantes que buscan modificar, recuperar
o dañar ciertas partes del circuito objetivo.
Existe una variedad de formas en las cuales los datos almacenados pueden dejar trazos de su
existencia.
Estas formas se llevan a cabo a nivel físico del dispositivo semiconductor, desde la composición
del transistor, el arreglo de éstos y los capacitores que conforman la celda de memoria, hasta los
elementos complementarios como los amplificadores de sensibilidad que constituyen el sistema
de memoria.
Los efectos del estrés eléctrico en dispositivos semiconductores, producidos por contaminantes
iónicos, hot carrier y electromigración, pueden ser utilizados para determinar, después de un
período de tiempo indefinido, que tipo de señal fue llevada por una parte específica del circuito.
Por la amplia variación de métodos experimentales y la gran variedad de dispositivos no es

posible proveer información definitiva de cómo llevar a cabo un proceso de recuperación de
datos.
Otras investigaciones demuestran que a bajas temperaturas se puede incrementar el tiempo de

retención de un SRAM a muchos segundos e incluso minutos. Otra posible forma es “congelar”
el estado de la celda de memoria aplicando temperatura baja al dispositivo. En este caso la
148
SRAM puede retener información por varios minutos y aún horas dependiendo de la temperatura
(-20ºC).
Los ejemplos a continuación son llevados a cabo bajo situaciones experimentales en

microcontroladores y smartcards, que contienen diferentes tipos de memoria SRAM y DRAM.
No está descartado que estas técnicas pueden ser aplicadas a los dispositivos de memoria de una
estación de trabajo [20,28,31,35] .
5.4 EJEMPLOS
Como se mencionó, los ejemplos a continuación fueron desarrollados por Universidades y

Centros de Investigación:
5.4.1 EJEMPLO 1: RETENCIÓN DE DATOS EN BASE A LA TEMPERATURA
Es común asumir que una vez removida la energía de la SRAM, el contenido de la memoria es
destruido inmediatamente. Este no es el caso, los datos puede mantenerse por varios segundos, en
que el dispositivo revertirá a su estado anterior si la energía regresa de nuevo. Si el CI es
congelado, el periodo de remanencia puede incrementarse en minutos u horas. La remanencia
varía entre los diferentes componentes.
Los ingenieros de seguridad están interesados en el periodo de tiempo en el cual una SRAM
retiene los datos una vez que se ha removido la energía. En los 80s una serie de experimentos
demostró que a bajas temperaturas la retención de datos de una SRAM se incrementaba de
segundos a minutos. Con los dispositivos de esa época se encontró que la retención de datos
comenzaba a -20ºC.
Algunos dispositivos son diseñados con sensores de temperatura, cuando detectan una baja de
temperatura después de los -20ºC, se trata como un intento de intromisión y la memoria es puesta
en ceros inmediatamente.
149
Sergei Skorobogatov de la Universidad de Cambridge en 2002 [31] realizó una serie de

experimentos donde demostraba la retención de datos en CIs SRAM en función de la
temperatura. Concluyendo que la temperatura en la cual el 80% de los datos es retenido por un
minuto varía ampliamente entre dispositivos, algunos requieren enfriamiento de por lo menos
-50ºC, mientras otros retienen los datos por este periodo a temperatura ambiente. En ese trabajo
se propuso una solución para atenuar este problema colocando una tierra del voltaje de
alimentación en lugar de dejarlo sin conexión.
También concluyó que los tiempos de retención de la memoria varían no solo de un dispositivo a
otro, también entre dispositivos del mismo fabricante. Esto es porque los fabricantes no incluyen
en su proceso de fabricación el control de la retención de datos. Versiones de baja potencia del
mismo chip tuvieron más tiempo de retención de datos [28,31].
5.4.2 EJEMPLO 2 : RECUPERACIÓN DE DATOS EN BASE AL ESTRÉS GENERADO

EN LOS TRANSISTORES DE UNA CELDA SRAM
Peter Gutman de la Universidad de Auckland expuso [20] que en una serie de pruebas aplicadas a
un dispositivo SRAM, el dispositivo cambia el voltaje de umbral, transconductancia y corriente
drenador-fuente después de los 100-500 segundos de estrés, correspondiendo con un cambio en el
tiempo de acceso a la SRAM y la operación de voltaje.
Esto hace posible determinar donde fue almacenado un 0 o 1 detectando que transistor fue más
estresado. Como se observa en la celda SRAM, al leer o escribir un 0 o 1 se utiliza un transistor
de acceso diferente.
+V
Dispositivos
de carga
Data Data
A B
Select Select
Read/Write (R/W)
Fig. 5.3 Celda SRAM

150
Los puntos grises en los transistores de la figura 5.2 muestran donde es localizado el principal
estrés. Los cambios en el comportamiento de la celda pueden ser determinados obteniendo el
tiempo de acceso de la celda a través de una microprueba de voltaje en las celdas de transistores o
utilizando técnicas similares.
Pruebas similares han sido realizadas en DRAMs sin embargo en este caso el énfasis de los
efectos de estrés fue en los circuitos compartidos como son los buffers de direcciones y los
amplificadores de sensibilidad (sense amplifiers) [20].
5.4.3 EJEMPLO 3 : RECUPERACIÓN DE DATOS EN BASE AL ESTRÉS DEL ÓXIDO

EN EL CAPACITOR DIELÉCTRICO DE UNA CELDA DRAM
La DRAM también puede “recordar” el último estado almacenado, pero de manera diferente.
Esto no es en base a la carga que es retenida en la celda (voltaje en los capacitores), sino al óxido
delgado que forma el dieléctrico del capacitor que es estresado altamente cuando se aplica un
campo y se relaja cuando no es aplicado (se estresa de acuerdo al estado del dato), este efecto
puede presentarse en forma inversa, es la conclusión a la que llega Peter Gutman en Julio 1996
[19].
Aún un óxido perfecto es susceptible a cambiar cuando se aplica un campo magnético. En la

presencia de un campo eléctrico los átomos con una carga positiva migran hacia el polo negativo
con una velocidad que depende de la temperatura, la calidad del óxido y los contaminantes
(sodio). Si el campo eléctrico es cero o no existe por suficiente tiempo, el estrés tiende a disiparse
eventualmente.
El estrés en la celda tiene un efecto acumulativo, como la carga de un circuito RC. Si el dato es
aplicado por solo unos milisegundos se efectuará un pequeño aprendizaje en las celdas. Por lo
que las propiedades del óxido cambian ligeramente dependiendo del dato.
Los efectos del estrés pueden ser medidos utilizando pruebas de memoria ”built-in-self” en las
celdas. En estas pruebas se induce un voltaje débil a la celda de almacenamiento para medir su
151
margen. Las celdas mostrarán diferentes márgenes dependiendo de cuanto óxido estresado esté
presente.
Un método simple pero destructivo para eliminar los datos almacenados en memorias
semiconductoras es elevar la temperatura. Tanto la DRAM como la SRAM perderán el contenido
mientras se llegue mas rápido a la temperatura Tjunction=140ºC. Varias horas sin energía
aplicada a esta temperatura, serán suficientes para hacer más difícil la recuperación de datos.
Contrario a esto, extender la vida de los bits almacenados cuando la energía es removida puede
llevarse a cabo debajo de los -60ºC, por días e incluso semanas[19].
5.4.4 EJEMPLO 4: RECUPERACIÓN DE DATOS UTILIZANDO PRUEBAS DE

ESTRÉS: “BURN IN” E “IDDQ”
Burn in
En el trabajo de Peter Gutman también se afirma que es posible recuperar datos directamente del
dispositivo sin preocuparse por restaurarlo. En dispositivos de los 80’s fue común leer los datos
almacenados en largos periodos en una SRAM con técnicas “Burn in”. Burn-in es una prueba
eléctrica de estrés que emplea voltaje y temperatura para acelerar las fallas eléctricas del
dispositivo.
Burn-in es realizado a 125ºC, con excitación eléctrica aplicada a muestras. Las memorias son
cargadas en tarjetas de prueba y son insertadas en hornos burn-in, los cuales proporcionan los
voltajes necesarios para las muestras a la temperatura de la prueba. Los sistemas dinámicos burn-
in aplican voltajes a temperaturas extremas mientras ejercitan las entradas del dispositivo bajo
prueba. Este procedimiento involucra altos costos por el manejo individual de los dispositivos [35].
Iddq
En los dispositivos SRAM más recientes se requiere de métodos mas sofisticados para hacer la
lectura de datos. Algunas técnicas se enfocan al uso de pruebas de dispositivos como lo es la
prueba Iddq (Corriente en reposo de la fuente de poder (quiescent current)) en cada vector
funcional de prueba, utilizando monitores de corriente de alta velocidad para mediciones rápidas.
Esta metodología de prueba envuelve la ejecución de un conjunto de vectores hasta una
152
localización alcanzada (conocida como medida paramétrica de paro o PM) en este punto el
dispositivo es interrumpido y la corriente es medida.
Variando los parámetros como el voltaje aplicado y la temperatura de operación es posible

identificar dispositivos que han sido sujetos a efectos de estrés de “hot carrier” que alteran sus
parámetros operacionales. El diseño de la compuerta (floating-gate) puede tener características de
Iddq dependiendo del tiempo, en la cual la compuerta causa que los MOSFET n y p esté
parcialmente en “on” y conduzcan un flujo de corriente que cesa lentamente conforme a la carga
de la compuerta para un estado lógico en especial. La carga inicial (o carencia de ésta) en la
compuerta y el cambio en la carga puede ser observado en la lectura por Iddq [19].
5.4.5 EJEMPLO 5: RECUPERACIÓN DE DATOS EN BASE A LA ALTERACIÓN DEL

ESTADO PREFERENTE DE ENCENDIDO DE UNA CELDA SRAM
Otra de las conclusiones a las que llega Peter Gutman en su investigación es que la SRAM es
susceptible a la remanencia debido a que el almacenamiento del mismo dato sobre un largo
periodo de tiempo tiene el efecto de alterar el estado preferente de encendido (power up). CIs
antiguos pueden “recordar” el estado previo al apagar el equipo por varios días. De hecho, es
posible fabricar SRAMs que tengan cierto estado de encendido, pero que no se sobrescriban
como una “ROM escribible”.
Una llave contenida en una memoria RAM estática por un largo periodo de tiempo puede ser
revelada en el siguiente “power on” debido a la remanencia [19,28].
5.4.6 EJEMPLO 6: RECUPERACIÓN DE DATOS EN SMART CARDS EN BASE AL

ANÁLISIS DE PARÁMETROS
Análisis de energía (Power analysis)
En el análisis de energía se miden las fluctuaciones en la corriente consumida por el dispositivo.

Las diferentes instrucciones causan diferentes niveles de actividad en el decodificador de
instrucciones y unidad aritmética, que pueden ser claramente distinguidas y parte de los
algoritmos puede ser reconstruida.
153
El desarrollo del análisis de energía y energía diferencial ha habilitado ataques severos en todos
los procesadores actuales en las smart cards. Cada cambio de bit en el bus del chip de la tarjeta
causa una corriente extra, una cantidad medible que es dibujada en la alimentación. Si los detalles
de implementación del software de la tarjeta son conocidos, se puede establecer un ataque
habilitando los valores de las llaves [33,30].
Análisis de corriente
Utilizando resistencias de 10 y 15 ohms en la fuente de poder, podemos medir con un convertidor

analógico-digital las fluctuaciones en la corriente consumida por la tarjeta. Preferentemente, las
mediciones deberán hacerse a por lo menos 12 bits de resolución y el muestreo de frecuencia
debería ser un entero múltiple de la frecuencia del reloj de la tarjeta.
El manejo de los buses de datos y direcciones consiste de más de una docena de inversores
paralelos por bit, cada uno maneja una gran carga capacitiva. Estos pueden causar un corto
circuito durante alguna transición. Los cambios en un bus de un 0 a 1 o inversamente contribuyen
de entre 0.5 y 1 mA del total de la corriente en el tiempo de un salto de reloj, así 12 bits son
suficientes para estimar el número de bits en el bus que cambian a la vez. SRAM escribe
operaciones generadas por fuertes señales. Promediando las mediciones de corriente de
transacciones idénticas repetidas, se pueden identificar señales pequeñas que no son transmitidas
por el bus. Estas señales llevan los estados de los bits. Señales como el estado del bit de acarreo
(carry bit state) son de interés especial, porque muchos algoritmos criptográficos utilizan el
cambio en la operación para elegir un bit de la llave individual en la bandera carry [30].
Análisis de frecuencia
Las diferentes instrucciones causan niveles de actividad diferentes en el decodificador de

instrucciones y unidad aritmética, que pueden ser claramente distinguidas y pueden ayudar a
reconstruir un algoritmo. Los diferentes procesadores tienen sus switcheos en tiempos diferentes
que son relativos al reloj y pueden ser identificados en mediciones de alta frecuencia [30].
154
5.4.7 EJEMPLO 7: RECUPERACION DE DATOS EN SMART CARDS UTILIZANDO

MÉTODO INVASIVO
Los ataques invasivos empiezan desempaquetando el chip. Una vez que el chip es abierto se
realizan las pruebas o ataques. Se debe remover por lo menos la capa de pasivación (passivation
layer) antes de que las pruebas puedan establecer contacto. Esto se puede realizar grabando
(etching), taladrando (drilling) o cortando con láser.
Para realizar estos ataques, el invasor debe estar familiarizado con las técnicas de diseño de los
CMOS VLSI (Very Large Scale Integration) y arquitectura de microcontroladores. Capas
profundas pueden ser accedidas utilizando equipo y herramienta especializados. También
utilizando estas técnicas se puede modificar la estructura del chip creando nuevas líneas de
conexiones y aún nuevos transistores.
Todos los ataques invasivos son complicados. Requieren de horas o semanas en un laboratorio
especializado y en el proceso destruyen el paquete. En suma los ataques invasivos requieren de
especialistas altamente calificados y un presupuesto propio.
Una vez que el chip es abierto, es posible realizar pruebas o ataques. La herramienta mas
importante para un ataque invasivo es una estación de trabajo para micropruebas (microprobing
Workstation). Su mayor componente es un microscopio óptico especial con distancia de trabajo
de por lo menos 8mm entre la superficie del chip y los lentes.
No es muy práctico leer información almacenada en un procesador de seguridad directamente de

cada celda de memoria, excepto para ROM. Los datos almacenados tienen que ser accedidos vía
un bus de memoria donde todos los datos estén disponibles para una localización simple. Las
micropruebas son usadas para observar el bus entero y grabar los valores de memoria que son
accedidos.
Es difícil observar todos lo buses de datos y direcciones al mismo tiempo (mas de 20). Pero
varias técnicas se pueden realizar, por ejemplo podemos repetir la misma transacción muchas
veces y utilizar dos o cuatro probadores para observar varios conjuntos de buses. Tan pronto
como el procesador realice la misma secuencia de acceso a memoria.
155
Para leer las celdas de memoria sin ayuda de software de tarjeta, se necesita utilizar algunos de
los componentes del CPU como un contador de direcciones para acceder a todas las celdas de
memoria. El contador de programa se incrementa automáticamente durante cada ciclo de
instrucción y la utiliza para leer la siguiente dirección, la cual nos sirve como generador de
secuencia de instrucciones. Solo se necesita prevenir que el procesador ejecute un salto, retorno o
llamada al procesador, que pueda afectar el contador de programa en su secuencia normal de
lectura. Pequeñas modificaciones al decodificador de instrucciones o al circuito contador del
programa tienen el efecto deseado con abrir las interconexiones correctas con el láser [29].
5.4.8: EJEMPLO 8: LECTURA ÓPTICA DE UNA SRAM CMOS
Una forma tradicional de lectura de datos en memorias de smartcards es realizada con un ataque
invasivo utilizando pruebas mecánicas en el bus del procesador. Estos ataques involucran
desempaque físico del chip y lectura de sus estados internos haciendo conexiones eléctricas a
componentes internos utilizando micropruebas. Siendo una tarea difícil el acceso a los circuitos
debido a la miniaturización de los elementos, estos ataques pueden ser realizados con diversas
herramientas como luz UV, rayos X y otras fuentes de radiación iónica, láser y campos
electromagnéticos.
El equipo de investigadores de la Universidad Católica de Louvain (Samyde y Quisquater) junto

con los investigadores de la Universidad de Cambridge (Skorobogatov y Anderson) desarrollaron
ataques donde las técnicas semi-invasivas podían ser usadas para leer el estado de la celda de
memoria de una forma no destructiva. Ejemplos de estos ataques son las pruebas ópticas y las
pruebas Electromagnéticas.
En las pruebas ópticas un láser es usado para inducir una falla transitoria en una o más
compuertas de forma que cause una fuga de información [32,34].
La base teórica de los experimentos se basa en los fotones que produce un haz de láser rojo
(659nm de longitud de onda) que al chocar con un dispositivo semiconductor produce mas
energía que la banda gap del Si (silicon band gap), haciendo que las áreas del CI apuntadas con el
láser se ionizen. Si los fotones alcanzan el área cercana a las uniones (junctions) p-n de un
156
transistor, se decrementará la resistencia del canal por la inyección de portadoras libres y se

producirá una fotocorriente debido al efecto fotovoltáico.
La habilitación de lectura a los estados de la celda de memoria se realiza a través del decremento
en la resistencia de los canales (n y p). En los experimento que llevaron a cabo los investigadores
se apuntó el rayo del láser en un transistor de un CI, pudiéndose distinguir los dos posibles
estados de memoria. Esta técnica es similar a la usada para cambiar el estado de memoria de los
bits usando rayos láser de baja potencia.
5.4.9 EJEMPLO 9: PRUEBA ELECTROMAGNÉTICA EN SMARTCARDS
Similar a las pruebas ópticas se pueden utilizar técnicas con pruebas electromagnéticas para
obtener datos de la memoria de un CI. Investigadores de la Universidad Católica de Louvain en
Bélgica en 2002 trabajaron con un análisis electromagnético, utilizando inducción
electromagnética para escanear un semiconductor. En esta técnica se utiliza un pequeño probador
en la superficie baja del CI y se mide la corriente inducida en él por un campo magnético en su
superficie. En algunas circunstancias esto da información similar a la obtenida en mediciones de
consumo de energía por el CI (power analysis). Este análisis mostró más información de la
requerida ya que el campo magnético obtenía otros campos magnéticos generados por señales
locales que no eran presentadas fuera del CI.
En los experimentos que llevó a cabo el equipo de investigadores se construyó un inductor

miniatura, colocando cientos de vueltas de alambre alrededor de la punta de la aguja en un equipo
de microprueba. Al inductor se le inyectó una corriente en el espiral que generó un campo
magnético donde las líneas del campo se dibujaron sobre la aguja.
La punta de prueba se colocó algunos micrómetros (microns) sobre la superficie del procesador
de prueba y se conectó el espiral al bulbo del flash de una cámara donde la corriente de remolino
creada por el campo magnético se sensó permitiendo construir un mapa del CI, como se muestra
en la figura 5.3.
157
Fig. 5.4 Mapa construído usando la corriente de eddy en una fotografía de la misma área.
Se observó que esta técnica de inducción, también podía ser usada para leer datos en forma no
destructiva. Con el mismo sensor se escaneó un chip creando una pequeña perturbación en la
celda de memoria. La idea fue mover por un corto tiempo el punto de polarización del transistor.
Cuando el punto de polarización es movido de su estado original, la velocidad o el tiempo que
tarda en regresar a ese estado original refleja el dato guardado en el transistor pudiendo ser un “0”
o un “1”. Con el equipo utilizado fue difícil crear la suficiente corriente en el chip sin alterar el
contenido de las celdas de memoria, pero mejorando los equipos, técnicas de laboratorio y con un
procesamiento de señal más sofisticado se puede poner en práctica el uso de técnicas
electromagnéticas para leer memorias con mayor eficacia [33].
158
CONCLUSIONES
Uno de los problemas a los que se enfrenta un investigador forense a la hora de capturar
información, es obtener información volátil y de memoria que puede ser borrada o sobrescrita al
querer obtenerla.
La memoria guarda información importante que puede ser la única fuente de información que el
atacante haya dejado en una violación a un sistema y puede convertirse en evidencia crucial para
detectar las causas del incidente.
Pero el análisis vivo no es ideal para un proceso de investigación forense porque se trabaja
directamente sobre el sistema sospechoso, esto puede alterar la información recolectada y si esta
información es llevada a un juicio ante una corte, puede que no sea aprobado como evidencia
porque no es una copia fiel de la escena del crimen, por lo que considerando esta situación el
investigador deberá conocer muy bien las herramientas de captura que utilice, por si llega a
modificar algo, sepa exactamente que cambia en el sistema una vez ejecutado cada comando.
No cabe duda que una metodología es aplicada por un atacante para llevar a cabo una intrusión,
por lo que tener una metodología para realizar la investigación forense también es necesaria y
sobre todo en el primer paso de recolección de información volátil. Con los pasos bien definidos
a seguir durante la recolección podremos capturar mayor y de mejor manera información volátil
que pueda complementar la información estática y así obtener mayor evidencia para asistir al
investigador en determinar las causas del incidente, hasta llegar al culpable.
159
La respuesta a incidentes en investigaciones, se centra en el primer intento del investigador por

verificar el incidente, quien atiende un incidente puede verse forzado a elegir una acción que
podría modificar la evidencia. En el proceso de investigación forense se aplican técnicas
científicas y analíticas a infraestructura de cómputo, para identificar, preservar, analizar y
presentar evidencia de manera que sea aceptable en un procedimiento legal para reconstruir los
hechos pasados con base en la evidencia que se recolecta.
Es en la respuesta inicial donde será incluido el procedimiento propuesto, ya que se debe obtener
la información volátil que nos pueda ayudar a obtener datos importantes de la verificación de un
incidente y así mismo la evidencia necesaria para llegar a ese objetivo.
La aplicación de una metodología para el sólo paso de la recolección de información es de

extrema utilidad ya que puede servir como una guía para que el investigador pueda recolectar la
información volátil con la menor alteración posible, esta metodología se realizó en base al orden
de volatilidad considerando que independientemente del sistema operativo con el que cuente el
equipo bajo análisis los registros del procesador, el contenido de la memoria y el estado de las
conexiones y los procesos es perdido cuando el sistema es apagado. Por lo que se puede aplicar
en diferentes sistemas operativos.
En la metodología planteada expone siete pasos de recolección de información volátil sobre

equipos de cómputo; el primer paso establece una línea de conexión segura al sistema donde
podamos aplicar las herramientas de nuestro conjunto en forma confiable, una vez establecida
esta comunicación se realiza un registro de tiempo de todo el sistema y se procede a obtener los
datos del sistema (en base a la volatilidad), una vez finalizadas estas tareas se realiza un nuevo
registro de tiempo y una copia de la memoria que muchas veces causa la reinicialización de la
máquina. El paso final se refiere a la documentación de la información, que es tan importante
como cada uno de los pasos anteriores.
Esta metodología se aplicó sobre los sistemas operativos Windows y Linux ya que son los de uso
más común, y se consideraron dos tipos de accesos, en forma local y a través de la red,
pudiéndose observar la utilidad de las herramientas existentes en cada una de las versiones de los
160
sistemas operativos elegidos ya que éstos son una excelente plataforma que permite flexibilidad
para ejecutar comandos de recolección de información volátil.
Varias herramientas y procedimientos puede que no trabajen como se describe en la

investigación, debido a que Windows y Linux parchan sus sistemas continuamente
protegiéndolos contra ataques y por lo tanto contra la recolección forense. Cada situación
requerirá quizá de una herramienta nueva que se tendrá que adecuar al caso, por lo que el
investigador forense tiene que saber muy bien el uso de cada herramienta, ya que el orden en que
se pueden o deben usar depende de los efectos que tienen.
En el caso del uso de las herramientas forenses como grave-robber se observó que este tipo de
software aplica una metodología planteada por el desarrollador, la cual se ejecuta con comandos
internos de los cuales solo observamos el resultado, sin tener la flexibilidad de profundizar sobre
un punto, modificarlo o quizá saltarnos algunas acciones. Por lo que la creación del propio
conjunto de herramientas es importante para la recolección.
Las herramientas utilizadas para la recolección de información volátil en los primeros casos no
fueron especializadas o forenses, se utilizaron herramientas del administrador del sistema, esto
porque la recolección de información volátil muchas veces requiere que el investigador utilice lo
que tienen a primera mano, además de que el sistema operativo tiene los comandos necesarios
para aplicarlos donde el investigador exactamente lo requiere, más que aplicar un solo comando
para realizar toda la captura como lo ejecutan las herramientas forense.
Finalmente la elección del conjunto de herramientas dependerá completamente del investigador,

en este trabajo solo se exponen las ventajas y desventajas que se pudieran tener en caso de
decidirse por una u otra herramienta.
El objetivo del análisis forense es una actividad orientada a respuesta, es decir, determinar qué
sucedió, quién fue el culpable y cuál es el impacto de los eventos. Las herramientas descritas y la
metodologías es útil, pero la habilidad del investigador es la que determina si el caso será resuelto
o no.
161
Dentro del alcance de este trabajo no se plantea una metodología para la recuperación de
información sobre un sistema muerto, ya que lleva un proceso y herramientas muy diferentes a un
sistema vivo, pero se expusieron varios ejemplos realizados por Universidades dedicadas a
semiconductores y seguridad que muestran que todavía es posible obtener algo de información de
la memoria RAM aunque el equipo esté desconectado de energía.
El concepto en que se basa esta serie de experimentos es la retención de datos en dispositivos de

memoria (remanencia), causado principalmente por los problemas que se generan en el proceso
de miniaturización de los dispositivos de memoria. Estos problemas pueden no estar
contemplados en la construcción y generar defectos que pueden aprovecharse para la
recuperación de información en estos dispositivos.
Aunque para los desarrolladores de software y los constructores de circuitos integrados los
defectos en los sistemas representan problemas, para el investigador forense estos defectos son
una forma que pueden emplear para recuperar u obtener evidencia. Pero la utilización de equipo
especializado y pruebas experimentales hace difícil que los dueños de los equipos puedan
acceder a estas acciones en el caso de una investigación judicial. Tal vez no se pueda incluir
como evidencia en una corte, pero es una buena noticia saber que existe una forma de obtener
información de memoria aunque el sistema esté completamente muerto.
Los pasos de la metodología general propuesta puede que no sean apropiados en todas las
jurisdicciones, por lo que se debe realizar un procedimiento de recolección de información volátil
para cada sitio en específico, y la metodología propuesta puede ser de gran utilidad.
Hemos hablado de llevar la información recolectada a una corte, pero en México son pocas las
leyes establecidas para delitos informáticos, por lo que esta metodología general se adecuará a
cada sitio en específico, es por eso que una metodología puede ayudar a hacer el proceso más
formal y obtener un punto más a favor en la lucha contra los crímenes digitales.
162
REFERENCIAS BIBLIOGRÁFICAS
[1] Gottfried, Grant. ”Emerging Technology: Taking a Byte Out Of Crime”. Itarchitect
Network Magazine [en línea]. Mayo 2001. [ref. Marzo 2003]. Disponible en WWW :
<http://www.networkmagazine.com/article/NMG20010125S0001>
[2] Kruse, Warren G., y Heiser, Jay G. “Computer Forensics (Incident Response Essentials)”.
Editorial Addison Wesley, Septiembre 2001.
[3] Dittrich, Dave. “Basic Steps in Forensic Analysis of Unix Systems”. Computer Forensics
[en línea]. [ref. Marzo 2003]. Disponible en WWW:
<http://staff.washington.edu/dittrich/>
[4] Grego, Adolfo. “Presentación Computación Forense”

ALAPSI/ITESM 2001
[5] Department of Energy, Computer Forensics Laboratory.”First Responder´s Manual”. [en

línea] . [ref. Marzo 2003]. Disponible en pdf en Internet:
<http://www.linuxsecurity.com/resource_files/documentation/firstres.pdf>
[6] Brezinski, D. y Killalea, T. “Guidelines for Evidence Collection and Archiving”. Request
for Comments[en línea]. RFC 3227, categoría: Best Current Practice. Febrero 2002. [ref.
Abril 2003]. Disponible en Internet: <http://www.rfc-archive.org/getrfc.php?rfc=3227>
[7] Aquino Luna, Rubén. “Análisis forenses en sistemas Windows/Unix.”

Cómputo Académico UNAM. Marzo 2003.
[8] Write, Timothy E. “The Field Guide for Investigating Computer Crime: Overview of a
Methodology for the”. Security Focus [en linea]. Mayo 26 2002 [ref. Jul 2003].
Disponible en WWW: <http://www.securityfocus.com/infocus/1245>
[9] International Organization on Computer Evidence. “G8 proposed principles for forensic
evidence”. International Organization on Computer Evidence IOCE [en línea]. 2002.
[ref. Ago 2003]. Disponible en pdf en Internet. <http://www.ioce.org/ >
163
[10] Russinovich, Mark. “Ps Tools”. Sysinternals [en línea]. 2005. [ref. Octubre 2005].
Conjunto de herramientas disponible en
Internet:<http://www.sysinternals.com/Utilities/PsTools.html>
[11] Robinson, Matt D. y Morano, Tom. “Linux Kernel Crash Dump”. Sourceforge [en línea].
2000. [ref. Sep 2004]. Disponible en WWW: <http://lkcd.sourceforge.net/>
[12] Linux Education. “LKCD Installation and Configuration”. IBM Global Services [en
línea]. 2000.[ref. Sep 2004]. Disponible en pdf en Internet:
<http://lkcd.sourceforge.net/doc/lkcd_tutorial.pdf>
[13] Winchell, Dave, Moyer, Jeff y Huber, Josh. “Mission Critical Linux”. Mission Critical
Linux [en línea]. Inc. 2000. [ref. Oct 2004]. Disponible en WWW:
<http://oss.missioncriticallinux.com/projects/mcore/>
[14] The GNU Project Debugger. “GDB”. The GNU Project Debugger [en línea]. Enero 2002.
[ref Sep 2004]. Disponible en Internet: <http://sources.redhat.com/gdb/>
[15] Johnson, Michael K. “Netdump Rationale”. Red Hat, Inc.'s Network Console and Crash
Dump Facility [en línea]. 2002. [ref. Ago 2003]. Disponible en WWW:
<http://www.redhat.com/support/wpapers/redhat/netdump/>
[16] Carrier, Brian. “ Sleuth Kit” y “Autopsy Browser”. Sleuthkit.org [en línea]. [ref. Mayo
2005]. Disponible en WWW: <http://www.sleuthkit.org/>
[17] Venema, Wietse. “The Coronoer´s Toolkit (TCT). Porcupine.org [en línea]. [ref. Mayo
2005].Disponible en WWW:< http://www.porcupine.org/forensics/tct.html>
[18] Venema, Wietse. “Memdump”. Porcupine.org [en línea]. [ref. Mayo 2005].Disponible en
WWW:<http://www.porcupine.org/forensics/memdump-1.0.README>
[19] Gutman, Peter. “ Secure Deletion of Data from Magnetic and Solid-State Memory”.
Department of Computer Science, University of Auckland [en linea]. 6o. Simposio de
Seguridad USENIX, Julio 1996. [ref. Enero 2005]. Disponible en formato pdf en Internet:
<http://www.cs.auckland.ac.nz/~pgut001/>
[20] Gutman, Peter. “ Data Remanence in Semiconductor Devices.”. IBM T.J. Watson
Research Center [en línea].10 Simposio de Seguridad USENIX, Agosto 2001. [ref. Enero
2005]. Disponible en Internet: <http://www.cs.auckland.ac.nz/~pgut001/>
[21] Schweitzer, Douglas. “Incident Response: Computer Forensics Toolkit”. HNS [en línea].
Octubre 2003. Capitulo 1. [ref. Dic 2004]. Disponible en formato pdf en Internet:
<http://www.net-security.org/dl/reviews/0764526367.pdf>
[22] Barish, Stephen. “Windows Forensics: A Case Study”. SecurityFocus [en línea].
Diciembre 2002 [ref. Mayo 2005]. Disponible en WWW:
<http://www.securityfocus.com/infocus/1653>
164
[23] Microsoft. “Windows 2000 Resource Kits”. Microsoft Corporation [en línea]. 2004. [ref.
Mayo 2005]. Disponible en WWW:
<http://www.microsoft.com/windows2000/techinfo/reskit/default.asp>
[24] Microsoft. “How to configure system failure and recovery options in Windows”.
Microsoft Corporation [en línea]. 2003. [ref. Agosto 2005]. Disponible en WWW:
<http://support.microsoft.com/kb/307973>
[25] Microsoft Support. “How to Use Dumpchk.exe to Check a Memory Dump File”.
Microsoft Corporation [en línea]. 2003. [ref. Agosto 2005]. Versión en español Id. del
artículo 241215 Disponible en WWW:
<http://support.microsoft.com/kb/315271/EN-US/> inglés
<http://support.microsoft.com/default.aspx?scid=kb;es;241215 > español
[26] Microsoft. “Debugging Tools for Windows”. Microsoft Corporation [en línea]. 2003.
[ref. Agosto 2005]. Disponible en WWW:
<http://www.microsoft.com/whdc/devtools/debugging/default.mspx>
[27] Russinovich, Mark. “PsTools”. Sysinternals [en línea]. 2004. [ref. Mayo 2005].
Disponible en WWW: <http://www.sysinternals.com/ntw2k/freeware/pstools.shtml>
[28] Nacional Computer Security Center. “A Guide to Understanding Data Remanence in

Automated Information Systems”. Department of Defense Trusted Computer System
Evaluation Criteria [en línea]. Rainbow Series. Library No. 5-236,082, version 2,
Septiembre 1991. [ref. Febrero 2005]. Disponible en WWW:
<http://www.fas.org/irp/nsa/rainbow/tg025-2.htm>
[29] Skorobogatov, Sergei P. “Semi-Invasive Attacks (definition). University of Cambridge

[en línea]. Octubre 2001. [ref. Febrero 2005]. Disponible en WWW:
<http://www.cl.cam.ac.uk/~sps32/semi-inv_def.html>
[30] Skorobogatov, Sergei P. “Copy Protection in Modern Microcontrollers”. University of

Cambridge [en línea]. Noviembre 2001. [ref. Febrero 2005]. Disponible en WWW:
<http://www.cl.cam.ac.uk/~sps32/mcu_lock.html>
[31] Skorobogatov, Sergei. “Low Temperature Data Remanence in Static RAM”. University of
Cambridge Computer Laboratory. Junio 2002. [ref. Febrero 2005]. Disponible en pdf en
Internet: < http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-536.html>
[32] Skorobogatov, Sergei y Anderson Ross. “Optical Fault Induction Attacks” University of
Cambridge [en línea]. Mayo 2002. [ref. Marzo 2005]. Disponible en WWW:
<http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/faultpap3.pdf>
[33] Moore, Simon. 3rd Generation Smart Card Project [en línea]. G3Card IST-1999-13515.
Enero 2003. [ref. Marzo 2005]. Disponible en WWW: <http://www.g3card.com/>
[34] Skorobogatov, Sergei y Anderson Ross. “On a New Way to Read Data from Memory”.
University of Cambridge [en línea]. Diciembre 2002. [ref. Marzo 2005]. Disponible en
formato pdf en Internet: <http://www.cl.cam.ac.uk/~sps32/>
165
[35] Chakraborty, Kanad y Mazumder, Pinaki. “Reliability and Fault Tolerance of RAMs”.
Pearson Education, Informit [en línea]. Ejemplo de Capítulo cortesía de Prentice Hall.
Octubre 2002. [ref. Abril 2005]. Disponible en WWW:
<http://www.informit.com/articles/article.asp?p=29732>
[36] Mandia, Kevin y Prosise, Chris. “Incident Response: Investigating Computer Crime”.
Editorial: Osborne/McGraw Hill. 2001.
[37] Wreski, Dave. “Biatchux Booteable CD Forensics Toolkit”. Linux Security.com [en línea]
Febrero 2002. [ref. Agosto 2005]. Disponible en Internet:
<http://www.linuxsecurity.com/content/view/111308/65/>
[38] Salusky, William. “Forensic and Incident Response Environment”. Source Forge [en
línea] 2004.[ref. Septiembre 2005]. Disponible la herramienta y documentación en
Internet: <http://fire.dmzs.com/>
[39] Knopper, Klaus. “Knoppix”. Knopper.net [en línea]. [ref. Septiembre 2005]. Disponible la
herramienta y documentación en Internet: < http://www.knoppix.org/>
[40] Baca Ernest. Penguin Sleuth Booteable CD”. Linux-Forensics.com [en línea] 2003. [ref.
Septiembre 2005]. Disponible herramienta y documentación en Internet:
< http://www.linux-forensics.com/downloads.html>
[41] ASR Data. “Smart Linux”. ASR Data [en línea] 2005. [ref. Septiembre 2005]. Disponible
la herramienta y documentación en Internet: <http://www.asrdata2.com/>
[42] Sánchez Franco, Alfredo. “Delitos Informáticos y su prueba - Algunas Consideraciones

sobre la Ley Penal Mexicana, con base en la Legislación Penal Internacional”. Delitos
Informáticos [en línea]. Enero 2004. [ref Octubre 2005]. Disponible en WWW:
<http://www.delitosinformaticos.com/delitos/ensayomexico.shtml>
[43] Semiconfareast.com. “Microprobing”. Semiconfareast.com [en línea]. [ref. Octubre 2005].

Disponible en Internet: http://www.semiconfareast.com/microprobing.htm
[44] Gómez, Roberto. “Mejores Prácticas para confiscar evidencia electrónica”. [ref. Mayo
2006].Apuntes de la MCC ITESM Campus Estado de México.
[45] Peikaru, Cyrus y Chuvakin, Antón. “Security Warrior”. Editorial: O´Reilly&Associates.

2004
166
ANEXO A
ARTICULO 211 bis CODIGO PENAL FEDERAL
ARTICULO 211 bis 1.- Al que sin autorización modifique, destruya o provoque pérdida de
información contenida en sistemas o equipos de informática protegidos por algún mecanismo de
seguridad, se le impondrán de seis meses a dos años de prisión y de cien a trescientos días multa.
Al que sin autorización conozca o copie información contenida en sistemas o equipos de
informática protegidos por algún mecanismo de seguridad, se le impondrán de tres meses a un
año de prisión y de cincuenta a ciento cincuenta días de multa.
información contenida en sistemas o equipos de informática del Estado, protegidos por algún
mecanismo de seguridad, se le impondrán de uno a cuatro años de prisión y de doscientos a
seiscientos días multa. Al que sin autorización conozca o copie información contenida en
sistemas o equipos de informática del Estado, protegidos por algún mecanismo de seguridad, se
le impondrán de seis meses a dos años de prisión y de cien a trescientos días de multa.
ARTICULO 211 bis 3.- Al que estando autorizado para acceder a sistemas y equipos de
informática del Estado, indebidamente modifique, destruya o provoque pérdida de información
que contengan, se le impondrán de dos a ocho años de prisión y de trescientos a novecientos días
de multa.
Al que estando autorizado para acceder a sistemas y equipos de informática del Estado,
indebidamente copie información que contengan, se le impondrán de uno a cuatro años de prisión
y de ciento cincuenta a cuatrocientos cincuenta días de multa.
información contenida en sistemas o equipos de informática de las instituciones que integran el
167
sistema financiero, protegidos por algún mecanismo de seguridad, se le impondrán de seis meses
a cuatro años de prisión y de cien a seiscientos días de multa.
Al que sin autorización conozca o copie información contenida en sistemas o equipos de
informática de las instituciones que integran el sistema financiero, protegidos por algún
mecanismo de seguridad, se le impondrán de tres meses a dos años de prisión y de cincuenta a
trescientos días de multa.
ARTICULO 211 bis 5.- Al que estando autorizado para acceder a sistemas y equipos de
informática de las instituciones que integran el sistema financiero, indebidamente modifique,
destruya o provoque pérdida de información que contengan, se le impondrán de seis meses a
cuatro años de prisión y de cien a seiscientos días multa.
Al que estando autorizado para acceder a sistemas y equipos de informática de las instituciones
que integran el sistema financiero, indebidamente copie información que contengan, se le
impondrán de tres meses a dos años de prisión y de cincuenta a trescientos días multa. Las penas
previstas en este artículo se incrementarán en una mitad cuando las conductas sean cometidas por
funcionarios o empleados de las instituciones que integran el sistema financiero.
ARTICULO 211 bis 6.- Para los efectos de los artículos 211 bis 4 y 211 bis 5 anteriores, se
entiende por instituciones que integran el sistema financiero, las señaladas en el artículo 400 bis
de este Código.
ARTICULO 211 bis 7.- Las penas previstas en este capítulo se aumentarán hasta en una mitad
cuando la información obtenida se utilice en provecho propio o ajeno [42].
168
ANEXO B
MICROPRUEBAS
Micropruebas (microprobing) o simplemente probing, es una técnica de análisis de fallas

utilizada para realizar contactos eléctricos o acceso a un punto en un circuito activo o muerto.
Emplea una pieza especial de equipo conocido como estación de microprueba, algunos ejemplos
se muestran en la siguiente figura:
Durante al análisis de circuitos en una micropruena, el analista emplea el mismo proceso de

análisis que en una falla de un circuito de gran tamaño. La microprueba es solo una herramienta
para que el analista acceda a nodos críticos o circuitos microscópicos mientras analiza el
comportamiento de varias partes del circuito.
169
Las mediciones de corriente y voltaje son realizadas por instrumentos de medición eléctricos
implementadas en el probador y manejadas a través de micromanipuladores, como los mostrados
abajo:
Instrumentos comunes son voltímetros, osciloscopios, fuentes de voltaje, generadores de onda. La

glassivation (deposición al final de la capa de pasivación, que protege de daños mecánicos y
corrosión) en la cubierta de un CI es removida por un grabado de iones reactivos (reactive ion
etching) antes de la prueba.
Las micropruebas también requieren de un diagrama esquemático del dispositivo para ser
efectivo y eficiente. El análisis necesita estos diagramas par apuntar inmediatamente a nodos
críticos para la prueba y aislamiento de la falla. Pero aún que el analista no esté familiarizado
con el funcionamiento del circuito y no tenga los diagramas, se puede llevar a cabo el análisis
correlacionando lo que es conocido y comparando voltajes y señales. La coordinación de ojos y
manos, así como la experiencia se necesitan para localizar un área de interés, elegir un punto de
prueba y ejercer la presión correcta par un buen contacto eléctrico [43].
170
ANEXO C
GLOSARIO
Archivo de símbolos (Symbol File)

Un archivo de símbolos contiene información de depuración similar a la que provee un archivo
ejecutable, sin embargo, esta información es almacenada en un archivo debug (.dbg) o una base
de datos de programas (program database - .pdb), mas que un ejecutable.
Apología
Discurso en el que se alaba o defiende a una persona o a una causa.
BIOS (Basic Input/Output System)

Es una memoria flash colocada en la mayoría de las computadoras donde se almacena los
programas de entradas y salidas del sistema (BIOS). El BIOS asegura que todos los otros chips,
discos duros, puertos y CPU funcionen juntos.
Built in Self Test y algoritmos de prueba

Es una técnica de diseño de hardware y software en circuitos integrados, que permiten la
realización de auto pruebas.
Checksum
Es una forma simple de medición que protege la integridad de los datos detectando errores.
Trabaja añadiendo un componente al mensaje y almacenando el valor resultante en el mensaje.
Cluster de disco
Es un grupo de sectores de disco.
CMOS (Complimentary Metal Oxide Semiconductor)

Tipo de material usado en la construcción de un chip.
CRC (Cyclic Redundance check)

Es un tipo de función hash usado para producir un checksum.
171
CYGWIN
Es una colección de herramientas de software libre, que permite a varias versiones de Microsoft
Windows actuar como un sistema UNIX.
Deep Submicron Fabrication Technologies

Esta tecnología habilita la creación de circuitos con decenas de millones de transistores. Las
tecnologías de fabricación deep-submicron permiten a los ingenieros de diseño poner un número
impresionante de componentes como microprocesadores, memorias e interfaces en un simple
microchip.
Depurar (debugging)
Es un proceso metódico para encontrar y reducir el número de “bugs” o defectos de un programa
o hardware electrónico.
DFT (Design for Test)

DFT (también referida como “structured test”) agrega transistores adicionales a la circuitería de
un chip para hacer más fácil las pruebas sobre éstos. Utilizar una metodología DFT agrega
trabajo y tiempo adicional al proceso del diseño, pero también puede eliminar tiempo significante
en el programa de pruebas.
Dieléctrico
Sustancia aislante en la cual puede existir un campo eléctrico en estado estacionario. Esta
sustancia tiene como principales características eléctricas su permitividad y su poder de
aislamiento
Dopante
Elemento introducido en un semiconductor para establecer conductividad tipo p o n; comúnmente
los dopantes de Si son para el tipo p Boro (B) y para tipo n Fósforo (P), Arsénico (As) y
Antimonio (Sb).
Eddy Current Non-Destructive Testing (Prueba NDT)

La corriente de remolino (eddy) es creada a través de un proceso llamado inducción
electromagnética. Cuando corriente alterna es aplicada a un conductor (alambre de cobre) un
campo magnético es desarrollado alrededor del conductor, este campo magnético se expande
cuando la corriente aumenta, si otro conductor eléctrico es acercado al campo se inducirá una
corriente por el segundo conductor. La corriente de remolino es corriente eléctrica inducida que
fluye en una trayectoria circular o de remolino.
ELF (Executable and Linking Format)

ELF (Executable and Linking Format) define el formato binario de default en los SO para Linux,
Solaris y SVR.
EOS- Electrical Overstress (Sobre-estrés electrica)

Se refiere a la destrucción de circuitos debido a voltaje, corriente o potencia excesiva.
ESD- Electrostatic Discharge (Descargas electrostáticas)

Es un caso especial de EOS. Es una transferencia de carga electrostática entre dos objetos.
172
Excepciones
Una excepción es una herramienta de programación útil para el manejo de errores. Cuando se
encuentra un error (un caso excepcional), simplemente se manda una excepción. Las excepciones
proveen una forma conveniente de manejar condiciones anormales.
File descriptor
Es un entero no asignado usado por un proceso para identificar un archivo abierto. Dos mil
descriptores de archivos son disponibles por cada proceso. Las subrutinas “open, pipe, create y
fcntl” generan descriptores de archivos. Los descriptores de archivos son generalmente únicos
por cada proceso, pero pueden ser compartidos por sus procesos hijos creados con una subrutina
“fork” .Los descriptores de archivos son indexados a una tabla de descriptores de archivos en un
área mantenida por el kernel para cada proceso.
Firmware
Software (programas o datos) que han sido escritos para memorias de solo lectura (ROM). El
firmware es una combinación de software y hardware. ROMs, PROMs y EPROMs que tienen
datos o programas grabados son firmware.
FireWIre
(IEEE 1394) Estándar de bus externo que soporta velocidades de transmisión arriba de 400Mbps
(1394a) y 800Mbps (1394b)
Floating gate (en la memoria FLASH)

Área central de almacenamiento de una celda de memoria FLASH, que es de 80 por 160
nanómetros.
GDB (GNU Debugger)

Es el depurador estándar de GNU.
GNU (“GNU´s Not Unix”)

Proyecto que involucra el desarrollo de software libre, permitiendo a los usuarios copiar
modificar o redistribuir código.
Hash (Función hash)

Es una función (subrutina o secuencia de código que realiza tareas específicas) que convierte una
entrada de gran rango en una salida de pequeño rango (valor hash).
IDE/ATA (Integrated Drive Electronics/AT Attachment)

IDE es una interfaz usada para controlar los discos duros, también es conocida con otra variedad
de nombres como ATA, ATA/ATAPI, EIDE,ATA-2, Fast ATA, ATA-3, Ultra ATA, Ultra
DMA, etc.
Ionización
La ionización es un mecanismo mediante el cual un electrón puede absorber suficiente energía
para desprenderse de la estructura atómica y unirse a portadores libres en la banda de conducción.
Interferómetro láser
Aparato de medición de precisión sobre superficies planas hechas de cristal, metal y cerámica.
173
Kernel
El módulo central del sistema operativo
Latch
Registro de instrucciones o registro de direcciones. Latch up es definido como la creación de una
trayectoria de baja impedancia entre la energía de alimentación y la circuitería de salida. Es un
caso especial de sobre-estrés eléctrico.
Lógica Transistor-Transistor (TTL)

El circuito básico de la compuerta TTL consiste de un transistor multiemisor de entrada y un
transistor de salida.
LKM (Loadable Kernel Module)

El LKM permite al administrador del sistema agregar o remover funcionalidad a un sistema
corriendo. Esta habilidad ayuda a los desarrolladores a crear nuevas partes del kernel sin tener
que rebotear la máquina constantemente para probar los cambios.
Malware (Malicious Software)

Software diseñado para dañar o destruir un sistema, este puede ser un virus o un caballo de
Troya.
MD5 (Message Digest Algorithm 5)

Es una función hash criptográfica que utiliza un valor hash de 128. MD5 ha sido utilizado en una
amplia variedad de aplicaciones de seguridad y es referido al estándar de Internet RFC1321.
Memory Stick
Es un medio diseñado para grabar, compartir e intercambiar información digital, como
fotografías, datos de computadora, música, imágenes, etc.
Memoria RAM tipos

La memoria RAM (Random Access Memory) es una forma de almacenamiento electrónico con
la característica de ser rápida y temporal. Se clasifica en memorias RAM estáticas (SRAM, Static
Random Access Memory) y memorias RAM dinámicas (Dynamic Random Access Memory)
Memoria ROM
Read Only Memory. Memoria de solo lectura
MOSFET
Tipo de transistor que compone una celda DRAM en serie con un capacitor, también es referido
como transistor array-acces o dispositivo de transferencia.
Object File u Object Code

Es una representación intermedia de código generada por el compilador después de que procesa
su código fuente. Un formato de archivo objeto es un formato usado para almacenar el código
objeto y sus datos relacionados típicamente producidos por el compilador o ensamblador.
174
PDA (Personal Digital Assistant)

Dispositivo móvil que combina organización y tecnologías de conectividad en un pequeño
paquete. Se puede enviar correo, faxes o hacer llamadas telefónicas, contiene un software
organizador para contactos y agenda.
Portable Executable
El formato PE es un formato de archivo ejecutable utilizado en versiones de Windows32 y 64. El
termino “portable” se refiere a la portabilidad del formato a través de 32 bits. PE es una versión
modificada del formato de archivos de Unix COFF.
Port Mirroring
También conocido como “Roving Analysis Port”, es un método para monitorear tráfico de red
que envía una copia de cada entrada o salida de paquetes de un puerto de un switch a otro puerto,
donde el paquete puede ser estudiado. Es una herramienta de diagnóstico.
Pruebas funcionales
Es el proceso que aplica vectores de un patrón a un dispositivo y verifica la salida para
determinar si el dispositivo está operando acorde a su tabla de verdad (Pruebas paramétricas).
También puedes ser el proceso de probar un dispositivo para identificar su habilidad en la
realización de sus funciones (ejemplos: lectura/escritura de pruebas de memoria, pruebas de
conversión analógico digital, etc.)
Prueba paramétrica
Es el proceso de probar un dispositivo con respecto a sus especificaciones para medidas con
características eléctricas como lo es voltaje o corriente.
Rootkit
Herramientas normalmente en software que se utilizan para comprometer un sistema de cómputo
“sin detectarse”. Un programa para “hackear” root.
SCSI (Small Computer System Interface)

Es un bus de alta velocidad (arriba de 160 Mbps) para conectar componentes en estaciones de
trabajo y equipos de cómputo, entre los componentes se encuentras: discos duros, escaner, CD-
ROM, impresoras, etc.
Señales
Las señales son usadas para notificar un proceso o hilo de un evento particular. Las señales se
describen como una interrupción de software. Cuando una señal es enviada a un proceso o hilo,
un manejador de señal entra en funcionamiento de manera similar al trabajo desarrollado por un
manejador de interrupciones en cuestión de hardware.
SHA (Secure Hash Algorithm).

Es un conjunto de funciones cirptográficas hash. La más común es SHA-1, que es empleada en
una gran variedad de aplicaciones de seguridad y protocolos incluyendo IPSec, PGP y SSH.
SHA-1 es considerado a ser el sucesor de MD5.
Slack space
Espacio no usado en un disco o cluster de discos.
175
.sig archivos
Es un bloque corto de texto al final de un mensaje identificando el emisor del mensaje y provee
información adicional acerca de él.
Símbolos en Windows
Un símbolo es un nombre que representa un registro o un valor absoluto o una dirección de
memoria absoluta o relativa. Los símbolos son generados por el compilador, explican la relación
entre el código fuente y objeto. Los módulos y símbolos de Windows proveen información
diferente dependiendo del depurador que esté corriendo. Los símbolos obtienen las direcciones
hexadecimales del procedimiento. Un símbolo se asigna cuando se crea un objeto de un recurso
en la programación de Windows.
Sistema de Archivos (File System)

Es un método para almacenar y organizar los archivos y datos para acceder a ellos y encontrarlos
fácilmente. Tipos de sistemas de archivos pueden ser de disco, red o base de datos.
Sistema de Archivos de disco

Almacena los archivos y datos por un controlador de disco, que puede estar conectado directa o
indirectamente a la computadora. Algunos ejemplos son:
FAT (File Allocation Table) Desarrollado por MS-DOS para consumidores de Windows
Microsoft.
NTFS (New Technology File System) Es un sistemas de archivos estándar para WinNT, 2000 y
sus descendientes
Ext2 (Second Extended File System) Fué un sistema de archivos estándar utilizado en SO Linux
ISO 9660 Define un sistema de archivos para CDROM
ODS-5 o Files 11 (On-Disk Structure) Es el sistema de archivos utilizado por Hewlett Packard
para el SO OpenVMS.
UDF (Universal Disk Format) Es una especificación de formatos para almacenar archivos en
medios regrabables.
UFS (Unix File System) Es un Sistema de archivos utilizado por Unix.
CDFS (Compact Disc Files System)
ReiserFS Sistema de archivos de propósito general. Actualmente soportado por Linux.
Sistema de Archivos de red

También conocido como sistema de archivos distribuidos, es un sistema de archivos donde los
archivos son accedidos mediante la red, con la finalidad de estar compartidos por varias
computadoras. Ejemplos son:
NFS (Network File System) Comparte archivos sobre la red en base a UDP
CIFS (Common Internet Files System) Versión de Microsoft del SMB (Server Message Block)
que es un protocolo de red para compartir archivos, impresoras y puertos seriales en la red.
Lustre Es un sistema de archivos Open Source, generalmente utilizado por clusters.
Global File System Sistema de archivos para clusters.
Sistema de Archivos de bases de datos

Es un nuevo concepto de administración de archivos en base a archivos de bases de datos. En
lugar de utilizar una estructura jerárquica, los archivos son identificados por sus características
como tipo de archivo, tópico, autor, etc. Ejemplos son: Gnomo Storage y WInFS.
176
State-of-the-art
El nivel de desarrollo (de un dispositivo, procedimiento, proceso, técnica o ciencia) alcanzada a
una fecha en particular frecuentemente como resultado de métodos modernos.
Temperatura Tjunction
Temperatura de empalme PN o límite de transición entre materiales tipo P y tipo N en un
dispositivo semiconductor.
Time stamp
Prueba inequívoca de que el contenido de tu trabajo existió en un punto en el tiempo y que el
contenido ha tenido cambio desde esa fecha.
Transconductancia
Es una expresión del rendimiento de un transistor bipolar o un FET (field effect transistor). En
general, la transconductancia se mide por la capacidad de ganancia (amplificación) que el
dispositivo es capaz de generar, cuando todos los demás factores permanecen constantes.
USB (Universal Serial Bus)

Bus externo que soporta velocidades de 12 Mbps. Permite conectar diversos periféricos y
sustituye el bus serial y paralelo. USB2 soporta velocidades de 480Mbps.
VLSI (Very Large Scale Integration)

Término que describe circuitos integrados compuestos de cientos de elementos lógicos o celdas
de memoria.

Yvvvzu 1579025421

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Yvvvzu 1579025421

Cargado por

Copyright:

Formatos disponibles

Instituto Tecnológico y de Estudios Superiores de Monterrey

Atizapán de Zaragoza , Estado de México a 4 de Septiembre de 2006.

Lic. Arturo Azuara Flores:

Rosa Alicia Torres García

Title Metodología para la Recolección de Datos Volátiles

Authors Rosa Alicia Torres García

Affiliation ITESM-Campus Estado de México

Issue Date 2006-04-01

Item type Tesis

Rights Open Access

Downloaded 19-Jan-2017 10:39:19

Link to item http://hdl.handle.net/11285/567549

CAMPUS ESTADO DE MÉXICO

METODOLOGÍA PARA LA RECOLECCIÓN DE DATOS

TESIS QUE PARA OPTAR EL GRADO DE

ROSA ALICIA TORRES GARCÍA

Asesor: Dr. ROBERTO GÓMEZ CÁRDENAS

Comité de tesis: Dr. JOSÉ DE JESÚS VÁZQUEZ GÓMEZ

Jurado: Dr. JOSÉ DE JESÚS VÁZQUEZ GÓMEZ Presidente

Atizapán de Zaragoza, Edo. Méx., Abril de 2006.

2.2 Volatilidad de los datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.6 Aplicando el procedimiento de recolección: CASO 5 Grave Robber Linux. . . . 137

En un incidente de seguridad, donde se ha realizado una intrusión no permitida a un equipo de

El presente trabajo se encuentra organizado de la siguiente forma: en el primer capítulo se

FIGURA 3.1 Autopsy inicio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

TABLA 1.1 Metodología de un Respuesta a Incidentes . . . . . . . . . . . . . . . . . . . . . . . 15

1. LA INVESTIGACIÓN FORENSE EN CÓMPUTO.

1.1 RESPUESTA A INCIDENTES

En una respuesta a incidentes el equipo de emergencia hace la verificación del incidente,

Las organizaciones necesitan desarrollar un equipo especializado que tenga la capacidad de

Mientras la respuesta a incidentes varía dependiendo de las circunstancias, los objetivos

• Recuperarse rápida y eficientemente del incidente de seguridad.

Las organizaciones deben desarrollar e implementar un plan de seguridad, llevarlo a cabo y

1.1.1.1 Respuesta inicial del administrador del sistema

1.1.1.2 Protegiendo la integridad de la evidencia

Es de gran importancia tener cuidado en preservar la evidencia en su estado original, el simple

1.1.1.3 Procedimientos shut-down

Cuando se da de baja limpiamente el sistema, se modifica la información del disco y la memoria,

1.1.1.4 Cadena de custodia

1.2 METODOLOGÍA EN UNA RESPUESTA A INCIDENTES

1.- La víctima notifica que un crimen ha ocurrido.

Los siguientes pasos son realizados en una respuesta a un incidente de seguridad:

Tabla 1.1 Pasos de un Respuesta a Incidentes

Detección del incidente

• ¿La computadora es contrabando o fruto de un crimen?

• No encender la computadora si está apagada

La evidencia computacional, como toda la evidencia, debe ser manejada cuidadosamente y de

• Asegurar que toda la evidencia esta etiquetada e inventariada.

Una vez que se ha obtenido y analizado la evidencia necesaria, se reestablecerá el sistema,

1.3 INVESTIGACIÓN FORENSE EN CÓMPUTO.

El cómputo forense asegura la preservación y autenticación de los datos computacionales, que

El trabajo de un investigador forense es obtener la mayor información de las fuentes de evidencia

• Estar seguro de preservar los datos en su forma original.

Cuando se empieza la investigación de un incidente, primero es necesario determinar si en

realmente exista un problema de seguridad, muchas veces se trata sólo de un problema de

1.3.1 PASOS DEL PROCESO FORENSE

A continuación se exponen los cuatro pasos del proceso forense[4]:

1.3.1.1 PASO 1 Identificar y recolectar evidencia

Identificar la información que se encuentre disponible y determinar la mejor manera de

1.3.1.2 PASO 2 Preservar evidencia

Lo que debe ser documentado:

1.3.1.3 PASO 3 Analizar la evidencia

Se deben analizar solo copias (imágenes) de la evidencia, manteniendo la integridad original y