Es habitual que cada profesional tenga sus preferencias en cuanto a herramientas y modo de trabajar. En general, estas preferencias vienen determinadas por nuestra experiencia y formación; y con el paso del tiempo, la colección de scripts y programas que usamos crece exponencialmente.
Una manera interesante de mantener todo este material recopilado organizado y clasificado es configurar un testbed o laboratorio de pruebas. Esta práctica es seguida habitualmente por profesionales de respuesta a incidentes y peritos, con el objetivo de probar la fiabilidad de las herramientas que usan. Sin embargo, yo aconsejo realizarlo también a otros profesionales debido a las ventajas que ofrece:
- Dispones de un entorno de referencia para probar herramientas y técnicas forenses.
- Puedes probar programas y comandos, y evaluar cuales son más apropiadas para diferentes entornos y situaciones (por ejemplo: por tiempo de ejecución, trazas dejadas en el sistema operativo o fiabilidad en los resultados).
- A pesar de llevar bastante tiempo, una vez configurado y documentado, el entorno es fácilmente reproducible.
A continuación se explican brevemente los pasos a seguir.
1. Instalar el entorno.
Para ello se necesita un ordenador o máquina virtual. Si optas por un ordenador, hay que asegurase de realizar un borrado seguro (wipe) y reinstalar desde cero. Por otra parte, si optas por máquinas virtuales es más sencillo disponer de diferentes sistemas operativos y revertir al estado inicial de la máquina, por lo que yo aconsejo esta segunda opción.
Una vez tienes el sistema operativo de tu elección hay que instalar algunas aplicaciones comunes en entornos de trabajo, y asegúrate de que este todo actualizado y con parches para disponer de un escenario lo más realista posible.
El siguiente paso es hacer un hash de las librerías o DLLs. Esto servirá para verificar posteriormente si fueron modificadas durante la ejecución de las pruebas.
2. Preparar utilidades de análisis
Para monitorizar y evaluar la ejecución de los programas que estemos probando debemos instalar diferentes utilidades. Si el entorno de trabajo es Windows, una posibilidad es utilizar algunas de las capacidades de SysInternals Suite. Como mínimo:
- Process Monitor para monitorizar los cambios en registros y sistemas de ficheros.
- Process Explorer para conocer los DLLs, ficheros y directorios que son cargados o accedidos por un proceso.
- DiskMon que muestra la actividad de lectura/escritura en el disco duro.
En un entorno Linux se pueden usar diferentes comandos como htop, lsof, strace, vmstat, slabtop o sar.
En este momento conviene hacer una copia de seguridad o snapshot.
3. Documentar el banco de pruebas
Se debe documentar, al menos:
- Sistema operativo y versión.
- Hardware.
- Aplicaciones instaladas.
- Parches y actualizaciones.
- Hashes de las librerías y/o DLLs.
4. Diseñar las pruebas a realizar en base a los objetivos que quieres conseguir.
Las pruebas dependerán del objetivo que quieres conseguir. Si quieres probar herramientas de análisis, deberás evaluar la usabilidad, la fiabilidad de los resultados y el formato de estos, por ejemplo.
Si lo que deseas es crear tu propio set de herramientas para respuesta a incidentes es importante verificar el impacto de estas herramientas sobre el sistema y su efecto sobre las posibles evidencias.
5. Realizar las pruebas.
- Análisis preliminar: el objetivo es entender qué hace el programa y cómo. Consiste en revisar la documentación disponible y los diferentes comandos u opciones que puedes utilizar. Si lo crees necesario puedes hacer búsqueda de cadenas y palabras clave, e incluso revisar los binarios.
- Análisis en ejecución: ejecuta la herramienta y evalúa los parámetros que definiste previamente en las pruebas.
6. Documentar los resultados
Para cada prueba crea la siguiente documentación organizada:
- Ejecutable o binario y hash del mismo.
- Descripción: propósito, sistema operativo compatible.
- Documentación disponible.
- Fecha del análisis y resultado: si necesita alguna librería, trazas dejadas en el sistema, etcétera.
- Evaluación personal: apunta todo aquello que te parezca interesante.
Ya puedes empezar a probar las herramientas y empezar a crear tu propia “biblioteca”. Como último consejo, si aun no dispones de un kit de herramientas favoritas puedes empezar probando las de otros.
Un punto de partida muy interesante para análisis forense y respuesta a incidentes son las que propone Pedro Sánchez Cordero, de Conexión Inversa, en su web.
NOTA: La metodología aquí descrita está basada en la enseñada por Richard Nolan y Cal Waits (CERT Training and Education).
