Análisis Forense Digital - Desarrollo
Análisis Forense Digital - Desarrollo
Análisis Forense Digital - Desarrollo
3
Fases de un Análisis Forense Digital
Si sospecha que sus sistemas han sido comprometidos lo primero que tiene que hacer
es ¡NO PERDER LA CALMA!, piense que no es el primero y que menos aún va a ser el úl-
timo al que le ocurre. Antes de comenzar una búsqueda desesperada de señales del incidente
que lo único que conlleve sea una eliminación de “huellas”, actúe de forma metódica y profe-
sional.
Para iniciar una primera inspección del equipo deberá tener en mente la premisa de
que debe conservar la evidencia, por ello NO HAGA NADA QUE PUEDA MODIFICARLA.
Deberá utilizar herramientas que no cambien los sellos de tiempo de acceso (timestamp), o
provoquen modificaciones en los archivos, y por supuesto que no borren nada.
No estría de más en este momento crear un CD o DVD como parte de sus herramien-
tas para la respuesta a incidentes, y si trabaja en entornos mixtos UNIX/Linux y Windows,
tendrá que preparar uno para cada plataforma. Aunque existen gran cantidad de utilidades a
continuación propongo una relación de aquellas que considero debería incluir en su ToolKit,
y que le permitan, al menos, realizar las siguientes tareas:
Al iniciar la investigación nunca sabremos con qué nos vamos a topar, de hecho al
principio puede que no se aprecie, a simple vista ninguna huella o indicio del ataque espe-
cialmente si para realizarlo han empleado e instalado en sus equipos un rootkit.
Primero sería interesante conocer los procesos que se están ejecutando actualmente en
el equipo, en busca de alguno que le resulte extraño, deberán llamarnos la atención aquellos
que consuman recursos en exceso, con ubicaciones poco frecuentes en el sistema de archivos,
que mantengan conexiones de red en puertos TCP o UDP no habituales, etc.
Este último punto nos llevará a realizar otra comprobación de interés, listar todos los
puertos TCP y UDP abiertos además de los procesos (PID), usuarios y aplicaciones que los
utilizan, siempre con la idea de identificar actividad no usual, recuerde la importancia de que
el administrador conozca muy bien los parámetros de actividad normal del sistema. La apari-
ción en el listado de procesos sin nombre o que emplean puertos altos (por encima del 1024)
pueden ser indicios de la ejecución de un troyano o puerta trasera (backdoor) en el equipo.
Una buena opción sería buscar en Internet (especialmente en Google) alguna referencia sobre
el puerto o proceso que le resulta sospechoso.
Si tras estas consultas sus temores aumentan, pase ahora a editar los archidos de regis-
tro del sistema y logs en busca de entradas y avisos sobre fallos de instalación, accesos no
autorizados, conexiones erróneas o fallidas, etc. Dependiendo de la plataforma que emplee
encontrará estos archivos en distintas ubicaciones.
aporten puede consultar la base de datos de ayuda de Microsoft. Otro lugar donde se
esconde gran cantidad información es el registro de Windows. La aplicación del sis-
tema regedit.exe puede ayudarle en esta tarea, pero si no se fía de ella use las
herramientas de su CD tales como reg (permite hacer consultas al registro sin modifi-
carlo), o regdmp (exporta el registro en formato de texto plano, .txt), para su posterior
consulta. En estos archivos tendrá que buscar “una aguja en un pajar”, debido a la in-
gente cantidad de información que almacena y que se mezcla. Un punto de partida
podría ser buscar en las claves del registro Run, RunOnce, RunOnceEx, RunServices,
RunServicesOnce, Winlogon, pues bajo estas claves se encuentran los servicios, progra-
mas y aplicaciones que se cargarán en el inicio del sistema. Si ve algo raro, acuda nue-
vamente a Google.
Además los programas y aplicaciones crean normalmente sus propios archivos de re-
gistro, que podrá encontrar bajo el directorio /var. Todos estos archivos están en mo-
do texto, por lo que podrá utilizar cualquier editor o visor de texto para buscar indicios
del ataque. Observe el siguiente fragmento de un archivo /var/log/messages, en
una máquina comprometida:
.....
Aug 22 23:37:55 localhost ftpd[7020]: FTP session closed
Aug 23 00:12:15 localhost ftpd[7045]: FTP session closed
Aug 23 00:19:19 localhost ftpd[7046]: FTP session closed
Aug 22 22:21:05 localhost ftpd[7049]: Anonymous FTP login from
200.47.186.114 [200.47.186.114], mozilla@
Aug 22 22:22:48 localhost ftpd[7052]: Anonymous FTP login from
200.47.186.114 [200.47.186.114], mozilla@
Aug 23 00:25:03 localhost kernel: Kernel logging (proc) stopped.
Aug 23 00:25:03 localhost kernel: Kernel log daemon terminating.
.....
¿No aprecia nada raro?, fíjese en la 4ª y 5ª entradas del archivo, éste parece haber sido
modificado pues aparece un salto en la secuencia de fechas, con dos entradas fechadas
el 22 de agosto tras dos entradas con fecha 23 de agosto. Este tipo de detalles, aunque
no son determinantes, si pueden ser síntomas de que han estado “trasteando” en sus
sistemas.
Además de estos archivos de registro, también pueden contener indicios los archivos
de claves, usuarios y grupos, podrá encontrarlos en /etc/passwd, /etc/shadow,
Análisis Forense Digital 13
Recopilación de evidencias
Bien, ya está seguro de que sus sistemas informáticos han sido atacados. En este punto
deberá decidir cuál es su prioridad:
Si no está seguro de lo que está haciendo, ¡NO HAGA NADA!, y póngase en contacto
con expertos en la materia.
Asumamos que elige el “Plan B”, que el análisis forense es su prioridad y que está
capacitado para realizarlo, así que a partir de ahora tendrá que seguir una serie de pasos en-
caminados a recopilar evidencias que le permitan determinar el método de entrada al siste-
ma, la actividad de los intrusos, su identidad y origen, duración del compromiso y todo ello
extremando las precauciones para evitar alterar las evidencias durante el proceso de recolec-
ción.
Este es un buen momento para hacerse con un cuaderno donde comenzar a tomar
apuntes detallados de todas las operaciones que realice sobre los sistemas atacados, no se fíe
de su memoria, anote la fecha y hora de inicio y fin de cada uno de los pasos que dé, anote
también características como números de serie de cada equipo, de sus componentes, de su
S.O., etc. No escatime en la recopilación de datos incluso haga fotografías de los equipos y
del entorno, nunca se sabe si tendrá que vérselas con sus atacantes en un juicio, y cualquier
evidencia puede ser definitiva. También sería recomendable que le acompañase otra persona
durante el proceso de recopilación de evidencias, ésta actuaría como testigo de sus acciones,
así que si es alguien imparcial mejor, y si puede permitirse que le acompañe un Notario mejor
que mejor, recuerde los requisitos legales para que una evidencia pase a ser considerada como
prueba en un juicio. No sería la primera vez que un excelente análisis técnico de un incidente
es rechazado en un juicio por no guardar las debidas garantías procesales.
Ahora que ya está preparado para la recolección de evidencias tendrá que decidir si
comienza a tomar muestras sobre el sistema “vivo” o “muerto”. Tenga presente que en el sis-
Análisis Forense Digital 14
tema habrá pruebas ocultas con diferentes niveles de volatilidad, como los registros del proce-
sador, estructuras de datos en la memoria RAM o memoria de tipo caché, conexiones de red
activas, usuarios y procesos actuales, sistema de archivos, etc. Será muy difícil reunir toda
esta información a la vez y gran parte de esta se perderá si decide apagar el equipo de la forma
habitual, ya que en este proceso se realizan una serie de pasos programados para cerrar el sis-
tema de forma limpia, pero si además el atacante ha instalado las herramientas adecuadas éste
podría eliminar, modificar y sustituir ficheros a su antojo durante el apagado, y se “limpiarán”
también del equipo las huellas de su atacante. Además si el atacante sigue on-line, puede de-
tectar su actividad y actuar con una acción evasiva o, peor aún, destructiva eliminando todo
tipo de información. Pero si por la severidad del ataque o por la importancia de los datos
comprometidos decide apagar el equipo, no lo dude ¡DESCONÉCTELO DIRECTAMENTE
DE LA RED ELÉCTRICA!, si ha leído bien, de esta forma perderá la información volátil de
la RAM, micro, etc. Pero conservará aún bastante información sobre el ataque.
Supongamos que puede mantener su equipo “vivo” un poco más, comience a recopilar
evidencias siguiendo el orden de mayor a menor volatilidad. Este proceso se describe muy
bien e el RFC 3227, .Estableceremos el siguiente orden de volatilidad y por tanto de recopila-
ción de evidencias:
Observe que los cuatro primeros puntos representan un tipo de datos, volátil, que se perde-
rán o modificarán si apaga o reinicia el sistema, es por tanto muy fácil eliminar evidencias de
forma inadvertida.
Dentro de las evidencias volátiles será de interés recuperar los siguientes datos del sistema
en tiempo real:
Fecha y hora.
Procesos activos.
Conexiones de red.
Puertos TCP/UDP abiertos y aplicaciones asociadas “a la escucha”.
Usuarios conectados remota y localmente.
Durante este proceso de recopilación de evidencias, tendrá que hacer uso de su Tool-
Kit, pero como se indicó anteriormente, deberá tener precaución pues el atacante aún puede
estar fisgoneando por sus sistemas. Con un buen entrenamiento será capaz de recopilar toda
esta información con un número de comandos mínimo, haciendo su labor casi desapercibida,
incluso sería recomendable que tuviese preparado un script en Perl para sistemas UNIX/Linux
o un archivo de proceso por lotes para entornos Windows que realizase todas estas operacio-
nes de forma automatizada y que, además, enviase la información a un lugar seguro.
Y ahora viene otra cuestión , a la hora de recopilar estas evidencias volátiles, ¿dónde
las almacenamos?, ¿dónde está ese lugar seguro?. Las salidas de algunos comandos pueden
ocupar poco espacio, pero otros pueden generar tal cantidad de información que sea necesario
Análisis Forense Digital 15
el uso de medios de almacenamiento con una capacidad considerable (desde cientos de Mby-
tes hasta decenas de Gbytes). Una Opción interesante sería usar discos externos USB, muy
económicos y que le permiten gran flexibilidad de manejo y transporte de grandes cantidades
de información. Otra opción es emplear herramientas de transmisión de datos por la red tipo
netcat, que le permitiría enviar toda la información recopilada a un sistema seguro, como
por ejemplo un equipo conectado en la misma red o un portátil conectado directamente al sis-
tema afectado.
Tan pronto como haya obtenido toda la información volátil del sistema tendremos que
recopilar la información contenida en los discos duros, teniendo en cuenta que estos dispositi-
vos no sólo contienen las particiones, los archivos, directorios, etc. Sino que también contie-
nen otro tipo de datos que hacen referencia a los propios archivos y a flujos de información,
son los metadatos que serán de gran importancia en el análisis forense.
En este punto cabe hacer una aclaración muy importante, cuando se realiza una copia
de seguridad de un disco o soporte en general se procede a copiar los archivos tal cual el sis-
tema operativo los “ve”, perdiéndose gran cantidad de información oculta en el disco. Por el
contrario si realizamos una imagen del disco, creamos una copia bit-a-bit del disco original
preservando toda la información que contenga, incluyendo los bloques de los ficheros elimi-
nados, espacio libre tras cada bloque, inodos (metadatos), etc.
Como norma general, obtendremos siempre imágenes de los discos duros para su pos-
terior análisis y, siempre sobre medios de sólo lectura.
Una de las herramientas más empleadas en entornos UNIX/Linux es dd, ésta permite
crear imágenes de discos bit-a-bit, además de ofrecer otras opciones como obtención del hash
MD5 de la copia, etc. Si además la combinamos con la herramienta netcat, podríamos
transferir las imágenes completas a través de la red.
Preservación de la evidencia
Aunque el primer motivo que le habrá llevado a la recopilación de evidencias sobre el
incidente sea la resolución del mismo, puede que las necesite posteriormente para iniciar un
proceso judicial contra sus atacantes y en tal caso deberá documentar de forma clara cómo ha
sido preservada la evidencia tras la recopilación. En este proceso, como se expondrá a conti-
nuación, es imprescindible definir métodos adecuados para el almacenamiento y etiquetado de
las evidencias.
Muy bien, ya tenemos la evidencia del ataque, ahora veremos que ha de continuar
siendo metódico y sobre todo conservando intactas las “huellas del crimen”, debe asegurar esa
evidencia a toda costa, por lo tanto ¡NI SE LE OCURRA COMENZAR EL ANÁLISIS SO-
BRE ESA COPIA!.
Como primer paso deberá realizar dos copias de las evidencias obtenidas, genere una
suma de comprobación de la integridad de cada copia mediante el empleo de funciones hash
Análisis Forense Digital 16
tales como MD5 o SHA1. Incluya estas firmas en la etiqueta de cada copia de la evidencia
sobre el propio CD o DVD, incluya también en el etiquetado la fecha y hora de creación de la
copia, nombre cada copia, por ejemplo “COPIA A”, “COPIA B” para distinguirlas claramente
del original. Traslade estos datos a otra etiqueta y péguela en la caja contenedora del soporte,
incluso sería conveniente precintar el original para evitar su manipulación inadecuada.
Si además decide extraer los discos duros del sistema para utilizarlos como evidencia,
deberá seguir el mismo procedimiento, coloque sobre ellos la etiqueta “EVIDENCIA ORI-
GINAL”, incluya además las correspondientes sumas hash, fecha y hora de la extracción del
equipo, datos de la persona que realizó la operación, fecha, hora y lugar donde se almacenó,
por ejemplo en una caja fuerte. Piense, además, que existen factores externos como cambios
bruscos de temperatura o campos electromagnéticos que pueden alterar la evidencia. Toda
precaución es poca, incluso si decide enviar esos discos a que sean analizados por empresas
especializadas solicite que los aseguren por un importe similar a los daños causados en sus
equipos.
Otro aspecto a tener en cuenta, y que está relacionado con el comentario anterior, es el
proceso que se conoce como la cadena de custodia, donde se establecen las responsabilida-
des y controles de cada una de las personas que manipulen la evidencia. Deberá preparar un
documento en el que se registren los datos personales de todos los implicados en el proceso de
manipulación de las copias, desde que se tomaron hasta su almacenamiento. Sería interesante
documentar:
Todas estas medidas harán que el acceso a la evidencia sea muy restrictivo y quede
claramente documentado, posibilitando detectar y pedir responsabilidades ante manipulacio-
nes incorrectas a intentos de acceso no autorizados.
Análisis de la evidencia
Una vez que disponemos de las evidencias digitales recopiladas y almacenadas de
forma adecuada, pasemos a la fase quizás más laboriosa, el Análisis Forense propiamente
dicho, cuyo objetivo es reconstruir con todos los datos disponibles la línea temporal del ata-
que o timeline, determinando la cadena de acontecimientos que tuvieron lugar desde el instan-
te inmediatamente anterior al inicio del ataque, hasta el momento de su descubrimiento.
Este análisis se dará por concluido cuando conozcamos cómo se produjo el ataque,
quién o quienes lo llevaron a cabo, bajo qué circunstancias se produjo, cuál era el objetivo del
ataque, qué daños causaron, etc.
der mejor el funcionamiento de las herramientas específicas para el análisis forense de siste-
mas que se expondrán más adelante.
Si no dispone de estos recursos, puede utilizar software como VMware, que le permiti-
rá crear una plataforma de trabajo con varias máquinas virtuales (varios equipos lógicos inde-
pendientes funcionando sobre un único equipo físico). También puede decantarse por una
versión LIVE de sistemas operativos como Linux, que le permitirá interactuar con las imáge-
nes montadas pero sin modificarlas. Pero si tuvo la “feliz idea” de hacer que su ToolKit en
CD o DVD fuese autoarrancable, ahora es el momento de utilizarlo.
Si está muy seguro de sus posibilidades y de lo que va a hacer, puede conectar los dis-
cos duros originales del sistema atacado a una estación de trabajo independiente para intentar
hacer un análisis “en caliente” del sistema, deberá tomar la precaución de montar los disposi-
tivos en modo sólo lectura, esto se puede hacer con sistemas anfitriones UNIX/Linux, pero no
con entornos Windows.
Inodos asociados.
Marcas de tiempo MACD (fecha y hora de modificación, acceso, creación y borrado).
Ruta completa.
Tamaño en bytes y tipo de fichero.
Usuarios y grupos a quien pertenece.
Permisos de acceso.
Si fue borrado o no.
Análisis Forense Digital 18
Sin duda esta será la información que más tiempo le llevará recopilar, pero será el pun-
to de partida para su análisis, podría plantearse aquí dedicar un poco de tiempo a preparar un
script que automatizase el proceso de creación del timeline, empleando los comandos que le
proporciona el sistema operativo y su ToolKit.
Para comenzar ordene los archivos por sus fechas MAC, esta primera comprobación,
aunque simple, es muy interesante pues la mayoría de los archivos tendrán la fecha de instala-
ción del sistema operativo, por lo que un sistema que se instaló hace meses y que fue com-
prometido recientemente presentará en los ficheros nuevos, inodos y fechas MAC muy distin-
tas a las de los ficheros más antiguos.
La idea es buscar ficheros y directorios que han sido creados, modificados o borrados
recientemente, o instalaciones de programas posteriores a la del sistema operativo y que ade-
más se encuentren en rutas poco comunes. Piense que la mayoría de los atacantes y sus
herramientas crearán directorios y descargarán sus “aplicaciones” en lugares donde no se sue-
le mirar, como por ejemplo en los directorios temporales.
A modo de guía céntrese primero en buscar los archivos de sistema modificados tras la
instalación del sistema operativo, averigüe después la ubicación de los archivos ocultos y
écheles un vistazo a ver dónde están y de qué tipo son, busque también los archivos borrados
o fragmentos de éstos, pues pueden ser restos de logs y registros borrados por sus atacantes.
Aquí cabe destacar nuevamente la importancia de realizar imágenes de los discos pues po-
dremos acceder al espacio residual que hay detrás de cada archivo, (recordemos que los fiche-
ros suelen almacenarse por bloques cuyo tamaño de clúster depende del tipo de sistema de
archivos que se emplee), y leer en zonas que el sistema operativo no ve.
Piense que está buscando “una aguja en un pajar”, por lo que deberá ser metódico,
vaya de lo general a lo particular, por ejemplo parta de los archivos borrados, intente recupe-
rar su contenido, anote su fecha de borrado y cotéjela con la actividad del resto de los archi-
vos, puede que en esos momentos se estuviesen dando los primeros pasos del ataque.
Sin perder de vista ese timestamp anterior, comience a examinar ahora con más detalle
los ficheros logs y de registros que ya ojeó durante la búsqueda de indicios del ataque, intente
buscar una correlación temporal entre eventos. Piense que los archivos log y de registro son
generados de forma automática por el propio sistema operativo o por aplicaciones específicas,
conteniendo datos sobre accesos al equipo, errores de inicialización, creación o modificación
de usuarios, estado del sistema, etc. Por lo que tendremos que buscar nuevamente entradas
anómalas y compararlas con la actividad de los ficheros. Edite también el archivo de contra-
señas y busque la creación de usuarios y cuentas extrañas sobre la hora que considere se inició
el compromiso del sistema
Siguiendo con el ejemplo que se expuso en el apartado 3.1.1., en el fragmento del ar-
chivo /var/log/messages se detectaron dos accesos FTP, al examinar la actividad de los
ficheros se descubrió que sobre esa fecha y hora se crearon varios archivos bajo el directorio
/var/ftp de la máquina comprometida (directorio raíz del servicio ftp en sistemas
UNIX/Linux), que además había sido borrado por el atacante. Al ser recuperado, se encontró
la descarga de archivos que eran propiedad de usuario root (administradores del sistema) sur-
giendo la pregunta ¿qué hacía el administrador descargando archivos a esas horas?, el archivo
recuperado era un conocido rootkit, se comprobó mediante el estudio del archivo de registro,
que momentos después el atacante descomprimió, compiló y ejecutó sus “herramientas”, acto
Análisis Forense Digital 19
seguido (segundos después) se observa que un gran número de archivos de comandos del sis-
tema operativo son modificados.
Una vez que disponga de la cadena de acontecimientos que se han producido, deberá
determinar cuál fue la vía de entrada a su sistema, averiguando qué vulnerabilidad o fallo de
administración causó el agujero de seguridad y que herramientas utilizó el atacante para apro-
vecharse de tal brecha. Estos datos, al igual que en el caso anterior, deberá obtenerlos de for-
ma metódica, empleando una combinación de consultas a archivos de logs, registro, claves,
cuentas de usuarios, etc.
Un buen punto de partida es repasar los servicios y procesos abiertos que recopiló co-
mo evidencia volátil, así como los puertos TCP/UDP y conexiones que estaban abiertas cuan-
do el sistema estaba aún “vivo”. Examine con más detalle aquellas circunstancias que le resul-
taron sospechosas cuando buscó indicios sobre el ataque, y realice con ellos un búsqueda de
vulnerabilidades a través de Internet, emplee Google o utilice páginas específicas donde en-
contrará perfectamente documentadas cientos de vulnerabilidades, como por ejemplo el
CERT, www.cert.org o en la base bugtraq en www.securityfocus.com.
Siguiendo con el ejemplo anterior, se sospechaba que al ataque se inició a través del
servicio FTP que ejecutaba la máquina comprometida, se conocía una vulnerabilidad en dicho
servicio y al realizar la consulta correspondiente se descubrió que efectivamente, ésta máqui-
na era vulnerable pues no había sido instalado el parche de seguridad correspondiente, ¿re-
cuerda el punto 1 del apartado Prevención de ataques a sistemas?. Pero no se confíe piense
que si existía esa vulnerabilidad puede que haya otras, realice el proceso de búsqueda cuantas
veces crea necesario, se imagina que ocurriría si volviese a instalar el sistema y dejase otra
brecha de seguridad.
Si ya tiene claro cuál fue la vulnerabilidad que dejó su sistema “al desnudo”, vaya un
paso más allá y busque en Internet algún exploit anterior a la fecha del compromiso, que utili-
ce esa vulnerabilidad. Generalmente lo encontrará en forma de rootkit y un buen lugar donde
comenzar su búsqueda es, nuevamente, Google aunque también le será de utilidad anotar la
siguiente dirección www.packetstormsecurity.org.
En este punto es muy importante que sea metódico, refuerce cada una de sus hipótesis
empleando una formulación causa-efecto, también es el momento de arrancar y comenzar a
utilizar nuestra máquina “conejillo de Indias”. Pruebe sobre ella los exploits que ha encontra-
do, si he leído bien, NO TENGA MIEDO, recuerde que en el análisis forense una premisa es
que los hechos han de ser reproducibles y sus resultados verificables, por lo tanto compruebe
si la ejecución de ese exploit sobre una máquina igual que la comprometida y en perfecto es-
tado (causa posible), genera los mismos eventos que ha encontrado entre sus evidencias (efec-
to verificable).
Si no es tan atrevido, puede recurrir a las bases de datos sobre ataques de los honey-
pots, herramientas de seguridad informática (implantadas por hardware o por software), cuya
intención es atraer a crackers o spammers, simulando ser sistemas vulnerables o débiles a los
Análisis Forense Digital 20
ataques, permitiendo recoger información sobre los atacantes y sus técnicas, permitiendo un
examen en profundidad del atacante, durante y después del ataque al honeypot.
Si ya ha logrado averiguar cómo entraron en sus sistemas, ahora le toca saber quién o
quiénes lo hicieron. Para este propósito le será de utilidad consultar nuevamente algunas evi-
dencias volátiles que recopiló en las primeras fases, revise las conexiones que estaban abier-
tas, en qué puertos y qué direcciones IP las solicitaron, además busque entre las entradas a los
logs de conexiones. También puede indagar entre los archivos borrados que recuperó por si el
atacante eliminó alguna huella que quedaba en ellos.
Pero si decide perseguir a sus atacantes, deberá realizar algunas pesquisas como parte
del proceso de identificación. Primero intente averiguar la dirección IP de su atacante, para
ello revise con detenimiento los registros de conexiones de red y los procesos y servicios que
se encontraban a la escucha. También podría encontrar esta información en fragmentos de las
evidencias volátiles, la memoria virtual o archivos temporales y borrados, como restos de e-
mail, conexiones fallidas, etc.
También puede emplear técnicas hacker, eso sí ¡DE FORMA ÉTICA!, para identifi-
car a su atacante, piense que si este dejó ejecutándose en el equipo comprometido “un regali-
to” como una puerta trasera o un troyano, está claro que en el equipo del atacante deberán
estar a la escucha esos programas y en los puertos correspondientes, bien esperando noticias o
buscando nuevas víctimas. Aquí entra en juego nuevamente nuestro ordenador “conejillo de
indias”.
Si procede de esta forma, use una de las herramientas más impresionantes y baratas
que encontrará nmap, este “mapeador de redes” es una utilidad de código abierto (por lo tanto
gratuita) para exploración de redes y auditoría de seguridad. Se diseñó para analizar
rápidamente grandes redes, aunque funciona muy bien contra equipos individuales. Nmap
utiliza paquetes IP "crudos" de forma novedosa, para determinar qué equipos se encuentran
disponibles en una red, qué servicios (nombre y versión de la aplicación) ofrecen, qué
sistemas operativos (y sus versiones) ejecutan, qué tipo de filtros de paquetes o cortafuegos se
están utilizando y así hasta como docenas de características.... Una auténtica joya para los
analistas de sistemas.
Análisis Forense Digital 21
Otro aspecto que le interesaría averiguar es el perfil de sus atacantes, aunque sin entrar
en detalles podrá encontrarse con los siguientes tipos de “tipos”:
Hackers: Son los más populares y tienen hasta su propia película (HACKERS de Iain
Softley, 1995). Se trata de personas con conocimientos en técnicas de programación,
redes, Internet y sistemas operativos. Sus ataque suelen tener motivaciones de tipo
ideológico (pacifistas, ecologistas, anti globalización, anti Microsoft, etc.) o
simplemente lo consideran como un ”desafío intelectual”.
Ataques pasivos: en los que no se altera la información ni la operación normal de los sistemas,
limitándose el atacante a fisgonear por ellos.
Ataques activos, en los que se altera, y en ocasiones seriamente, tanto la información como la
capacidad de operación del sistema.
Deberá tener en cuanta, además otros aspectos del ataque como los efectos negativos
de tipo técnico que ha causado el incidente, tanto inmediatos como potenciales además de lo
crítico que eran los sistemas atacados. Por ejemplo ataques al cortafuegos, el router de co-
nexión a Internet o Intranet, el servidor Web corporativo, los servidores de bases de datos,
tendrán diferente repercusión según el tipo de servicio o negocio que preste su organización y
las relaciones de dependencia entre sus usuarios. Piense que una manipulación de una Web
corporativa que realiza funciones meramente publicitarias tendrá un impacto mucho menor
Análisis Forense Digital 22
que si eso mismo ocurre por ejemplo en eBay, que su negocio está basado totalmente en las
subastas por Internet y un parón en su servidor Web puede traducirse en miles de euros de
pérdidas por cada hora.
Puede también recurrir a métodos como BIA (Bussines Impact Analysis) que le
indicarán como determinar el impacto de eventos específicos, permitiéndole valorar los daños
en cantidades monetarias, que podrá presentar dado el caso, a su compañía de seguros.
Pero no piense sólo en los daños y pérdidas actuales, sino que tendrá que pensar en
daños potenciales, si no conoce qué actividades han llevado a cabo los atacantes, no sabrá
hasta dónde han podido “fastidiarle” sus sistemas, o peor aún, hasta dónde pueden llegar, pues
¿qué ocurriría si desconoce que su atacante consiguió descargarse un archivo que contenía
datos de carácter personal de sus empleados?, y peor aún, ¿qué pasaría si el atacante
alardeando de su proeza publica esos ficheros en Internet?. Pues bien, el artículo 44.3.h de la
Ley Orgánica 15/1999,de 13 de Diciembre, de Protección de Datos de Carácter Personal se lo
aclarará rápidamente:
Sólo comentar que las sanciones para este tipo de infracciones son de 60.000 a
600.000 €.
Por otro lado, cuando se haya concluido el análisis y durante éste, tendrá que mantener
informados a las personas adecuadas de la organización, por lo que será interesante que
disponga de diversos métodos de comunicación. Además como se verá necesitará tener
preparados una serie de formularios y presentar tras la resolución del incidente al menos dos
tipos de informes uno Técnico y otro Ejecutivo.
El Informe Técnico
Este informe consiste en una exposición detallada del análisis efectuado. Deberá
describir en profundidad la metodología, técnicas y hallazgos del equipo forense. A modo de
orientación, deberá contener, al menos, los siguientes puntos:
El Informe Ejecutivo
Este informe consiste en un resumen del análisis efectuado pero empleando una
explicación no técnica, con lenguaje común, en el que se expondrá los hechos más destacables
de lo ocurrido en el sistema analizado. Constará de pocas páginas, entre tres y cinco, y será de
especial interés para exponer lo sucedido a personal no especializado en sistemas
informáticos, como pueda ser el departamento de Recursos Humanos, Administración, e
incluso algunos directivos. En este informe deberá, donde se describir, al menos, lo siguiente:
Motivos de la intrusión.
Desarrollo de la intrusión
Resultados del análisis.
Recomendaciones.