UNIÓN EUROPEA

INSTITUTO DE EDUCACIÓN SECUNDARIA

Vicepresidencia, Consejería de
Fondo Social Europeo
Educación y Universidades
Código de centro: 28074852 El FSE invierte en tu futuro

ANÁLISIS FORENSE
INFORMÁTICO ANÁLISIS
FORENSE EN
ENTORNOS LINUX
 Análisis Forense en entornos Linux

Particularidades de los Sistemas Linux.

Adquisición de Evidencias en Sistemas Linux.
Análisis de Evidencias en Sistemas Linux.
Herramientas Forenses para el Análisis de
Sistemas Linux.

2
Introducción
La metodología vista hasta el momento se aplica igualmente en cuanto a triage
live de la máquina o adquisición en frío.
Los sistemas Linux son más sencillos en cuanto a dónde encontrar información.
Siguen una estructura estándar de directorios y la información habitualmente
está almacenada en texto, de modo que no necesitamos una aplicación para
cada artifact como sucede en Windows.
En Linux todo su estructura de datos, esta basada en ficheros.
Todo el sistema de ficheros parte desde una raíz, un root y desde ahí contienen
ficheros o puntos de montaje a otras particiones del mismo disco u otros
distintos.
Ejemplo /proc y /dev. Todo estos puntos los crea el kernel y la memoria.

3
Kernel

 Arranque: Kernel + módulos +

servicios
 Sistema de ficheros en modo árbol
 La memoria es un fichero
 Timestamp - EPOCH
 Servicios: User Space o User Land

4
Sistemas de ficheros de Unix (I)
Unix (y sus derivados) es un SSOO muy utilizado, sobre todo en
servidores, es rápido y muy flexible. Soporta gran variedad de
sistemas de ficheros: ext2, ext3, ext4, ReiserFS, XFS, JFS, UFS,
FAT, FAT32, NTFS, etc.
Existen múltiples distribuciones GNU/Linux, como Red Hat,
Debian, Suse, Ubuntu, etc.
Según la complejidad del sistema de ficheros, tienen
características como previsión de apagones, posibilidad de
recuperar datos, indexación de búsquedas rápidas, reducción de
la fragmentación para agilizar la lectura de datos, etc.

5
Sistemas de ficheros de Unix (II)
Ext2 está obsoleto. Tiene fragmentación muy baja, aunque es algo lento manejando
ficheros de gran tamaño.
Ext3 es la versión mejorada de ext2, con previsión de pérdida de datos por fallos del
disco o apagones, introduce el journaling. Es compatible con ext2.
Ext4 es la última versión de la familia de sistemas de ficheros ext. Es mucho más
eficiente (menor consumo de CPU, mejoras en la velocidad de lectura y escritura),
admite ficheros más grandes (hasta 16 TiB) y sistemas de ficheros de hasta 1024 PiB (1
EiB).
ReiserFS es un sistema de ficheros de última generación, organiza los ficheros
permitiendo agilizar la manipulación de los mismos. Muchas herramientas no lo
soportan para recuperar datos.
SWAP es el sistema de ficheros para la partición / ficheros de intercambio de Linux. Se
suelen usar para no saturar la memoria RAM cuando se excede su capacidad.

6
Estructura de los sistemas de ficheros Ext*
Una de las partes más importantes es el superbloque, que contiene
información sobre el sistema de ficheros. La tabla de inodos es el
equivalente a las entradas de la FAT y los bloques de datos es donde se
terminarán almacenando los datos de cada fichero.

7
Estructura de los sistemas de ficheros Ext*
Cada fichero posee un i-nodo (nodo-i, i-node) que guarda los números
de sus bloques de datos.
Un i-nodo además de la lista de bloques de datos almacena otras
informaciones del fichero como su tipo (fichero regular, directorio,
enlace simbólico, etc.), su tamaño, propietario, permisos, fecha de
creación, etc.
Cada dispositivo de almacenamiento posee su propia tabla de i-
nodos, y como cada i-nodo gestiona un archivo, un sistema de
ficheros puede contener como máximo el número de i-nodos que
quepa en su tabla. Este es otro motivo por el cual asignar cuotas de
disco a los usuarios, pero no por cantidad de espacio, sino por
cantidad de i-nodos, pues si no se hiciera, un usuario podría crear
muchos ficheros de 0 byte, así no consumiría su cuota de espacio, y
al no tener cuota de i-nodos podría ocuparlos todos y bloquear el
sistema.

8
Estructura de los sistemas de ficheros Ext*
Los i-nodos se identifican por un número llamado número-i. Podemos consultar el
número-i de un fichero con la orden stat, además de otros datos (fechas, tamaño,
dueño, grupo, etc.). También lo podemos visualizar con el comando ls -i.

9
Estructura de los sistemas de ficheros Ext*
Analizando la salida del siguiente comando:

$ stat [Link]
File: [Link]
Size: 5 Blocks: 8 IO Block: 4096 regular file
Device: 802h/2050d Inode: 3146179 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/sansforensics) Gid: ( 1000/sansforensics)
Access: 2022-06-03 [Link].779165973 +0000
Modify: 2022-06-03 [Link].779165973 +0000
Change: 2022-06-03 [Link].779165973 +0000
Birth: -

Nuestro fichero ocupa 5 bytes (tamaño lógico), está ocupando todo un bloque
físico (IO Block) de disco (sector de 4KiB). Tiene un parámetro Blocks: 8 que
indica que este fichero ocupa 8 bloques de 512 bytes, que son los que caben
en un sector de 4096 bytes.

10
Directorios de interés según FHS
FHS es el estándar de nomenclatura de directorios para
sistemas X.
Según este estándar, la información de interés forense se
encuentra en:
 /etc. Directorio dónde se encuentran los ficheros de
configuración del sistema
 /var/log. Directorio dónde se encuentran los logs del sistema
 /root. Directorio home del usuario root
 /home/<user>. Directorio home del usuario

11
Ficheros de Log
El servicio encargado de generar logs es rsyslog o syslog-ng.
Su configuración se encuentra en /etc/[Link].
✓ Los logs rotan, es decir, se van generando ficheros según los
criterios indicados al servicio logrotate, /etc/[Link].
El resultado es que encontraremos varios ficheros de log para
una misma aplicación, de los cuales uno será el actual o más
reciente y el resto, logs anteriores (histórico de logs).
✓ Los logs “rotados” aparecen con un . y un número secuencial
o comprimidos.

12
Ficheros de Log del sistema (I)
Todos están en la ruta /var/log
 messages: fichero de log de propósito general, donde
encontraremos información genérica del sistema. (Red Hat y
derivados).
 [Link]: registros de autenticación, de servicios o interactivas.
 [Link]: mensajes del kernel de Linux. También podemos usar
comando dmesg. Aquí veremos drivers y mensajes de estado del SO.
 btmp y wtmp: ficheros binarios con información sobre las sesiones.
Los consultamos con los comandos lastb, intentos de accesos
fallidos, y last para los intentos de acceso válidos.

13
Ficheros de Log del sistema (II)
/var/run/utmp -> log binario que mantiene registro
de los usuarios actuales en el sistema
De aquí saca la información cuando introducimos los
comandos who o w

14
Ficheros de Log de Aplicación
Habitualmente haremos forense de máquinas Linux que son servidores.
Entre los servicios más habituales, podemos encontrar servidores web,
servidores de BBDD y servicios de seguridad tipo firewall, UTM, VPN, etc.
Estos servicios dejan sus propios logs en un directorio con el nombre del
servicio, en la ruta /var/log, por ejemplo /var/log/apache2
Del servicio apache son interesantes los siguientes logs:
 [Link] -> registros de las peticiones get procesadas
 [Link] -> registro de las peticiones erróneas
Del servicio mysql (MariaDB) son interesantes los logs:
 [Link] -> registra los intentos de inicio de sesión erróneos, entre otros

15
Ficheros de Log del usuario
En el directorio home de cada usuario, hay una serie de ficheros y
subdirectorios ocultos, comienzan por “.”, que almacenan información de
la actividad de usuario.
El más relevante es .bash_history, que almacena los comandos
introducidos por consola por el usuario. Es un fichero de texto, aunque el
comando history nos permite opciones avanzadas sobre él.
Tenemos la caché de múltiples programas en el directorio .cache.
También podemos encontrar los comandos introducidos en la consola de
mysql en mysql_history.
Y los artifacts de navegación en el directorio
.mozilla/Firefox/xxxxx/default

16
Ficheros de Log (Systemd)
Con la aparición de systemd, existe el diario (journald), que se
encarga de recopilar y administrar de forma centralizada todos los
mensajes producidos por el kernel, initrd, servicios, etc.
El demonio journald recopila datos de todas las fuentes disponibles
y los almacena en un formato binario para una manipulación fácil y
dinámica. Almacenar los datos de registro en formato binario
permite que los datos puedan mostrarse en diferentes formatos de
salida dependiendo de nuestras necesidades. Por ejemplo, se puede
mostrar cada entrada como un objeto JSON para poder mostrar la
información mediante un gráfico.

17
Ficheros de Log (journalctl)
La utilidad journalctl, nos permite acceder y manipular los datos que se encuentran dentro del diario
(journald):
journalctl --utc -> Para mostrar las marcas de tiempo en hora UTC.
journalctl -b -> Mostrar los registros del arranque actual
journalctl -k -> Mostrar los mensajes del kernel del arranque actual
journalctl --list-boots -> Muestra todos los arranques del sistema. Cada arranque tiene un ID único.
journalctl -b 35b7fcb960d74c89a2abeab7d022ee8e -> Muestra un arranque concreto indicando el
ID de ese arranque. 0: emergencia
1: alerta
journalctl -b 2 -> Muestra el penúltimo arranque 2: crítico
3: error
journalctl --since "2021-10-12" --until "2021-10-15“ -> Muestra el interval 4: advertencia
5: aviso
journalctl -u [Link] -> Mostrará el log de ese servicio 6: información
7: depuración
journalctl -p err -b -> Filtra los mensajes por prioridad. Mostrará error, crítico, alerta o emergencia.
journalctl -u [Link] --since today -> Podemos combinar opciones

18
Comandos imprescindibles en el análisis de una máquina Linux (I)

Un mínimo manejo de la consola de Linux es necesario para encontrar información en

los ficheros de logs.
Hay una serie de comandos imprescindibles, cuyo conocimiento nos permitirá
encontrar lo que buscamos de una forma eficiente.
grep nos permite la búsqueda de cadenas en un fichero o en lo que enviemos como
entrada.
-v para excluir la cadena indicada
-i para obviar mayúsculas/minúsculas
-c cuenta las ocurrencias en vez de mostrar las líneas
-H nos devuelve el nombre del archivo en el que se encuentra la coincidencia
grep cadena_a_encontrar donde_buscarla o
comando | grep cadena_a_encontrar

19
Comandos imprescindibles en el análisis de una máquina Linux (II)

find nos permite buscar ficheros en el sistema de ficheros. Es una herramienta muy
potente y que tiene muchas opciones. Nos vamos a centrar en los básicos y en los
de tiempo.
-name para indicar el nombre de archivo
-iname no distingue entre mayúsculas/minúsculas
-type para indicar el tipo de fichero, f, b, d, l o c
-not para excluir una cadena en el nombre de los ficheros buscados
-ctime atime o mtime n, ficheros creados, accedidos o modificados en los n días
anteriores
-cmin amin o mmin n, ficheros creados, accedidos o modificados en los n
minutos anteriores
find donde_buscar criterios_de_busqueda

20
Comandos imprescindibles en el análisis de una máquina Linux (III)

ls es la herramienta para listar el contenido de un directorio, con

opciones interesantes para la ordenación y filtrado.
-a muestra ficheros ocultos
-t los ordena por fecha de modificación, interesante para los logs
tail /head permite ver las últimas/primeras 10 líneas de un fichero
more/ less permite paginar la salida por pantalla de un fichero de
texto
strings para ver las cadenas de un fichero
file para ver que tipo de fichero tenemos entre manos

21
Pasos para un triage en caliente

 Extracción de información de la máquina

 Herramientas forenses en modo Read Only
 Binarios conocidos
 Librerías seguras
 Artefactos de usuario, sistemas y sistema de
ficheros

22
Scripts de automatización
Para la extracción de evidencias, al igual que teníamos con
Windows multitud de herramientas, con Linux, nos ocurre
casi lo mismo:

 Nix_Live_Response de Brimor Labs

 [Link]
 [Link]
 [Link]
 [Link]
La idea es realizar un export de los datos y posteriormente
comenzar a analizarlos.

23
SystemV vs SystemD

 IMPORTANTE, según el tipo de sistema, tendremos que usar una

distribución distinta.

 Para saber si estamos ante un equipo con systemV o systemD,

miramos el proceso init.

 Si el init es proceso 1 es una systemV, si no estamos ante una

systemD.

 Normalmente SystemD posee un arranque mucho más rápido.

 Lo normal y más común, es hacer forense en systemd.

24
Forense en SystemD
 En systemd hay un superdemonio que lo hace todo

 Posee varias unidades de arranque:

 /lib/systemd/system -> Nativas

 /etc/systemd/system -> De usuarios

 Lo mejor para hacer forense en sistemas con

systemD es usar el comando systemctl

25
Recomendaciones
Los binarios de /bin (ls, cp, cd…) son modificables por un
atacante.

/proc contiene los procesos cargados en memoria RAM

/proc/cmdline contiene las opciones de arranque del

kernel actual. También puede ser modificado y darnos
problemas.

Es IMPORTANTE “Enjaularse” en la máquina de manera que

todo lo ejecutado por nosotros, sea legítimo.

26
Time stamps (I)
El time stamp es crítico en cualquier análisis, y dependiendo del sistema de
ficheros, éste varía. Cuando se copia, modifica, mueve y se descarga algo, se
queda registrado su etiqueta de tiempo.
Lo primero es conocer la zona horaria del sistema a analizar. Para eso podemos
ejecutar:
$ ls -lh /etc/localtime
lrwxrwxrwx 1 root root 27 Jun 24 2021 /etc/localtime ->
/usr/share/zoneinfo/Etc/UTC
sansforensics@siftworkstation: ~
$ cat /etc/localtime
TZif2UTCTZif2UTC
UTC0
Como podemos observar, la zona horaria está configurada como UTC.

27
Time stamps (II)
Con el comando timedatectl también podemos ver la zona horaria:
$ timedatectl
Local time: mar 2023-04-18 [Link] CEST
Universal time: mar 2023-04-18 [Link] UTC
RTC time: mar 2023-04-18 [Link]
Time zone: Europe/Madrid (CEST, +0200)
System clock synchronized: no
NTP service: active
RTC in local TZ: no

28
Time stamps (III)
Todo i-nodo de cada fichero contiene los
siguientes timestamps:
mtime -> fecha / hora de modificación (modify)
atime -> fecha / hora de acceso (access)
ctime -> fecha / hora de cambio (modificación
de metadatos) (change)
crtime -> fecha / hora de creación (create)

29
Time stamps (IV)
 ctime registra el cambio de los metadatos, como por ejemplo cuando
ejecutamos chown, rename, chmod…
 crtime registra una de las marcas / etiquetas de tiempo más críticas
para un analista:
 El sistema ext3 solo registra tres marcas de tiempo: modificación,
acceso y modificación de metadatos.
 En ext4 se añade la cuarta marca de tiempo, que es la de creación,
pero el comando stat sigue mostrando sólo tres marcas de tiempo.
Para ver el crtime existe el comando debugfs. sudo debugfs -R
"stat /root/[Link]" /dev/sda2 | grep "crtime"
(Hay que poner la ruta relativa desde el / de cada partición)

30
Time stamps (V)
$ stat [Link]
Fichero: [Link]
Tamaño: 44 Bloques: 8 Bloque E/S: 4096 fichero regular
Dispositivo: 803h/2051d Nodo-i: 145457 Enlaces: 1
Acceso: (0644/-rw-r--r--) Uid: ( 1000/ madrid) Gid: ( 1000/ madrid)
Acceso: 2023-04-18 [Link].236277724 +0200
Modificación: 2022-11-25 [Link].964709129 +0100
Cambio: 2022-11-25 [Link].964709129 +0100
Creación: -

$ sudo /usr/sbin/debugfs -R 'stat madrid/[Link]' /dev/sda3

Inode: 145457 Type: regular Mode: 0644 Flags: 0x80000
Generation: 4050115954 Version: 0x00000000:00000001
User: 1000 Group: 1000 Project: 0 Size: 44
File ACL: 0
Links: 1 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x638091b4:e6012c24 -- Fri Nov 25 [Link] 2022
atime: 0x643e5d5a:38553f70 -- Tue Apr 18 [Link] 2023
mtime: 0x638091b4:e6012c24 -- Fri Nov 25 [Link] 2022
crtime: 0x63809178:b469ba10 -- Fri Nov 25 [Link] 2022
Size of extra inode fields: 32
Inode checksum: 0xa1428f10
EXTENTS:
(0):17416092

31
Time stamps (VI)
La técnica de timestomp más común es usar el comando
touch. Este comando permite modificar la fecha
modificación y/o acceso de un fichero a la fecha actual o
a una fecha que especifiquemos. Si el fichero no existe lo
crea con tamaño 0 bytes.

touch -m -d ‘2022-08-10 [Link]’ [Link] -> Solo fecha de modificación

touch -a -d ‘2022-08-10 [Link]’ [Link] -> Solo fecha de último acceso
touch -d ‘next monday’ [Link] -> Actualiza ambas fechas
touch [Link] -r fichero_existente -> Utiliza un fichero como referencia

32
Time stamps (VII)
El comando touch no cambia el tiempo de modificación de los metadatos.

Es conveniente revisar el histórico de comandos y ejecuciones .bash_history u otros

mecanismos de registro en búsqueda de posibles empleos de la técnica de timestomp con
touch.

Cuando copiamos un archivo en un directorio:

 El archivo hereda la propiedad del directorio destino
 El mtime, ctime, y atime del archivo cambian a la hora en la que se copia.
 El mtime y ctime del directorio destino cambian a la hora de copiado.

Cuando movemos un archivo a un directorio:

 El archivo no hereda la propiedad del directorio destino
 El ctime del archivo cambia a la hora en la que se mueve.
 El mtime y ctime del directorio destino cambian a la hora en la que se mueve.

33
Autopsy
• Autopsy es una herramienta forense que se puede instalar en Windows, Linux y MacOS creada por
Basis Technology. Es la principal plataforma forense digital de código abierto con todas las funciones
principales que se espera de las herramientas forenses comerciales. No es una distribución forense,
pero viene incluida en las principales distribuciones forenses. Es la interfaz gráfica para The Sleuth
Kit y otras herramientas forenses digitales. Es utilizado por las fuerzas del orden, militares, etc.
Existen módulos complementarios de terceros desarrollados en Java y Python. Cubre todas las etapas
del análisis forense.

34
Instalación de Autopsy
Hay que seguir tres pasos: instalar los prerequisitos, instalar El Sleuth Kit, y instalar
Autopsy. Descargamos desde aquí.
• Instalando los Prerequisitos
sudo bash ./linux_macos_install_scripts/install_prereqs_ubuntu.sh.
• Instalando El Sleuth Kit
sudo apt update && sudo apt install /path/to/[Link].
• Instalando Autopsy
sudo bash ./install_application.sh -z ../../[Link] -i ~/autopsy -j
/usr/lib/jvm/bellsoft-java8-full-amd64.
Ejecutamos Autopsy
~/autopsy/autopsy-4.20.0/bin$ sudo bash autopsy
Podemos acceder a la documentación en
[Link]
35
The Sleuth Kit (TSK) (I)
The Sleuth Kit es una colección de herramientas de línea de comandos y una biblioteca C que le permite
analizar imágenes de disco y recuperar archivos de ellas. Se utilizan desde la interfaz gráfica de Autopsy y
desde muchas otras herramientas forenses comerciales y de código abierto. La funcionalidad principal de
TSK le permite analizar el volumen y los datos del sistema de archivos. Está escrito en C y PERL. Analiza
imágenes de disco raw (dd), Expert Witness (EnCase) y AFF. Analiza el sistema de archivos y las imágenes
de disco sin procesar (es decir, dd), Expert Witness (es decir, EnCase) y AFF. Admite los sistemas de archivos
NTFS, FAT, ExFAT, UFS 1, UFS 2, EXT2FS, EXT3FS, Ext4, HFS, ISO 9660 y YAFFS2. Tiene interfaz web.

36
The Sleuth Kit (TSK) (II)
TSK organiza sus utilidades en 5 distintos niveles o capas:
 Capa de volúmenes, comandos que comienzan con “mm”, media management

mmstat, mmls , mmcat

 Capa del sistema de ficheros, comandos que comienzan con “ fs ”, file system

fsstat
 Capa de acceso a bloque, comandos que comienzan con “ blk ”,

blkls, blkcat , blkstat , blkcalc

 Capa de acceso a metadatos del file system comienzan con “i”, de inodo aunque el
concepto es válido para sistemas de ficheros que no se basan en inodos
icat, ifind , istat , ils
 Capa de archivo o human interface comienzan con “f”, de file

fls, ffind

37
TSK (The Sleuth Kit) (III)
Aparte de las herramientas por capas, ofrece otra serie de
herramientas útiles para el trabajo de análisis:
tsk_comparedir: Compara una estructura de ficheros con una de la
imagen
tsk_gettimes: Extrae los datos temporales para la elaboración de la
línea de tiempos
tsk_recover: Extrae los ficheros contenidos en una imagen a un
directorio para la comparación de un estructura de ficheros con una
de la imagen
tsk_loaddb: Genera una BBDD con los metadatos de la partición o
imagen, para su análisis posterior
38
 TSK (The Sleuth Kit) (IV)
Lo primero es mostrar el contenido de la imagen forense con mmls:

39
 TSK (The Sleuth Kit) (V)
A continuación, con el comando fsstat, buscamos información de la partición que nos interese, utilizando
el offset que hemos obtenido en el comando anterior. Vemos que es un Windows XP.

40
 TSK (The Sleuth Kit) (VI)
A continuación, con el comando fls, podemos ver el directorio \ de esa partición, utilizando el offset que
hemos obtenido en el comando anterior. Si añadimos -R podremos ver el contenido de TODO el sistema
de ficheros.

41
 TSK (The Sleuth Kit) (VII)
A continuación, con el comando icat, podemos ver el contenido de
un fichero a partir del número de inodo del mismo. Funciona
también con sistemas de ficheros fat, ntfs, etc. Indicamos el
sistema de ficheros, el offset de la partición y el número de inodo
(en este caso correspondiente al fichero [Link]).

42
Captura de memoria RAM de máquinas virtuales
 En Virtualbox generamos un VM Core File en formato 64-bit ELF que contiene un
volcado de la memoria y CPU.
vboxmanage debugvm “nombre maquina” dumpvmcore --filename
[Link]
vboxmanage debugvm “nombre maquina” dumpguestcore --filename
[Link] (versiones antiguas)
 En VMware (Fusion, Workstation y Server)

Acceder al directorio vmwarevm y obtener el fichero .vmem (Si el anfitrión es

Linux, por defecto no lo crea, hay que añadir [Link] = "named“
en el fichero .vmx).
 En VMware (ESXi)

Se hace un snapshot (.VMSS)

43
Análisis de memoria RAM de máquinas virtuales
En Virtualbox, a partir del fichero VM Core File (.elf) generado:
Nos interesa la referencia a la memoria RAM, y para eso ejecutamos:
$ objdump -h [Link] | egrep -w "(Idx|load1)"
Idx Name Size VMA LMA File off Algn
1 load1 40000000 0000000000000000 0000000000000000 00000720 2**0
El volcado de la RAM comienza en en el offset 0x720 y continua 0x40000000 bytes (1024Mb)
Extraemos la RAM:
size=0x40000000;off=0x720;head -c $(($size+$off)) [Link] | tail -c +$(($off+1)) >
[Link]
Ahora podemos procesar la imagen de la RAM con Volatility:
# volatility -f [Link] imageinfo
En VMWare podemos procesar directamente el fichero .vmem con Volatility.

44
Proceso de análisis en Linux
 Si se ha clonado a un disco físico, se busca con fdisk -l y montamos la partición con:

mount /dev/sdxn /media/caso

 Si se ha clonado a imagen, usando por ejemplo guymager, dd, dc3dd, etc.

Para ver el contenido y particiones de la imagen adquirida:

fdisk -l /media/adquisición/[Link]
mmls /media/adquisición/[Link]

Para montar la imagen, en ocasiones habrá que especificar el sistema de ficheros, cual es la partición que se
debe montar y el bloque donde comienza la partición. Para eso necesitamos calcular el offset o
desplazamiento de la partición en bytes. Para eso el comando mmls incluido en TSK muestra la disposición de
las particiones en un volumen. Para calcular el offset, multiplicamos el sector de inicio de la partición a montar
por el tamaño del sector en bytes.

 mkdir /path/punto_montaje
 sudo mount -t filesystem -o loop,ro /path/[Link] /path/punto_montaje >> ERROR!!
 sudo mount -t filesystem -o loop,ro,offset=$((start*512)) /path/[Link] /path/punto_montaje
 noexec, no ejecuta ficheros
 show_sys_files, para ver los ficheros NTFS que empiezan por $
 streams_interface=windows, para poder ver los ADS de NTFS

Otra opción para montarlo en un Linux es usar FTK Imager Lite

45
Forense de RAM
Para hacer el volcado de memoria se puede intentar almacenar la
memoria /dev/mem en un fichero:

sudo dd if=/dev/mem of=./[Link]

dd: error reading '/dev/mem': Operation not permitted
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0286207 s, 36.6 MB/s

Pero esto solo copia 1 MiB, por lo que es necesario utilizar

herramientas.

46
Forense de RAM – LIME (I)
LIME (Linux Memory Extractor) es un módulo de kernel cargable (LKM) que
permite la adquisición de memoria volátil desde Linux y dispositivos basados en
Linux, como Android. Además permite la adquisición en diferentes formatos
(lime, raw y padded) y el envío del volcado de memoria por red.
Minimiza su interacción entre el usuario y los procesos de espacio del kernel
durante la adquisición, lo que le permite producir capturas de memoria que son
más sólidas desde el punto de vista forense que las de otras herramientas
diseñadas para la adquisición de memoria de Linux.
Es necesario recompilarlo con la versión exacta del kernel de la máquina de la
que se desea adquirir el volcado.
Para poder visualizar la información con Volatility hay que tener un perfil
asociado a esa versión de kernel.

47
Forense de RAM – LIME (II)
Hay que incluir los headers de la versión y unos cuantos programas más:
apt update
apt install linux-headers-generic
apt install linux-headers-$(uname -r)
apt install build-essential
apt install gcc make
Se clona el proyecto de LiME desde github:
[Link]
Se compila con el kernel adecuado al equipo objetivo y se vuelca en un dispositivo
de almacenamiento que se utilizará en el equipo objetivo.
Dentro del directorio de las fuentes (LiMe/src) se crea el módulo: cd LiMe/src &&
make
Se genera el fichero [Link]

48
Forense de RAM – LIME (III)

49
Forense de RAM – LIME (IV)
El dump se ejecutará cuando el módulo sea cargado usando los parámetros que recibe
como argumentos.
sudo insmod [Link] "path=/[Link] format=lime“

Otra función que proporciona es realizar el volcado por red:

insmod [Link] “path=tcp:8000 format=lime”
Mientras en la estación forense: nc [Link] 8000 | dd of=/[Link]
Y para descargar el módulo: rmmod [Link]
Finalmente tenemos que comprobar que el tamaño del volcado se corresponde
con el tamaño de la memoria RAM.

50
Forense de RAM – AVML
AVML (Acquire Volatile Memory for Linux)
Una herramienta portátil de adquisición de memoria volátil X86_64 para
Linux. Está escrita en Rust. AVML se puede utilizar para adquirir memoria
sin conocer a priori la distribución del sistema operativo de destino o el
kernel. No se necesita compilación en destino ni huellas dactilares.
wget [Link]

Se copia avml: cp avml /ruta/de/la/maquina/a/analizar

Se cambian los permisos: sudo chmod +x avml
Se lanza con un nombre de fichero para el volcado:
sudo ./avml <<fichero_dump.dd>>

51
Forense de RAM – Perfil (I)
Volatility se basa en perfiles para poder localizar en el volcado los diferentes
elementos que estructuran la memoria de los sistemas operativos analizados, y
es por ello que si no disponemos del perfil correspondiente al origen del volcado
deberemos generarlo previamente.
Necesitamos el perfil específico para cada módulo, para el caso específico del
Kernel de la máquina que estemos investigando.
Afortunadamente gracias a muchos héroes anónimos tenemos cientos de
repositorios, donde se incluyen multitud de módulos para LiME y profile del
Volatility.
Existe una versión de Volatility para Python 2.x y Volatility 3 para Python 3.x.
Para ver los perfiles, plugins… existentes ejecutamos:
$ /usr/bin/python2.7 [Link] --info | more

52
Forense de RAM – Perfil (II)
Para generar un perfil para un kernel concreto, tenemos que instalar en un equipo con el mismo kernel que el
equipo a analizar:
 Instalamos dwarfdump: apt install dwarfdump
 Se clona Volatility desde github: git clone [Link]
 Una vez hecho, se entra dentro del directorio de herramientas de Linux:

cd volatility/tools/linux
• Desde ese directorio, se genera el fichero [Link] necesario:
make clean
make
Si aparece este mensaje de error:

ERROR: modpost: missing MODULE_LICENSE() in /root/volatility/tools/linux/module.o

Ejecutamos: echo 'MODULE_LICENSE("GPL");' >> module.c

Y volvemos a ejecutar make

53
Forense de RAM – Perfil (III)

54
Forense de RAM – Perfil (IV)
Hay que incluir ese fichero [Link] y la tabla de símbolos de
esa distribución de Kernel en concreto en un zip:
zip [Link] tools/linux/[Link] /boot/Systemmap-x.x.x-xx-
generic

Se copia ese fichero a la máquina donde se va a analizar el volcado de

memoria con Volatility instalado y se introduce en el directorio de
plugins:
mv [Link]
volatility/plugins/overlays/linux/
Para comprobar que Volatility tiene el nuevo perfil, ejecutamos:
$ /usr/bin/python2.7 [Link] --info | grep -i "linux"

55
Forense de RAM – Perfil (V)

Con ese nombre de perfil, se puede analizar el volcado de memoria:

[Link] -f [Link] --profile [Link].x-xx-genericx64 linux_pslist

[Link] --plugins=dirplug/ -f [Link] --profile [Link].x-xx-genericx64 linux_pslist

56
Forense de RAM – PROCDUMP
En el caso que queramos hacer un volcado de un proceso
específico, podemos utilizar la funcionalidad de
PROCDUMP.
La versión del Kernel tiene que ser superior a la 3.5.
Podemos descargar la herramienta desde:
[Link]
Funciona de tal manera, que identificando el PID del proceso
con ps -ef (por ejemplo), podemos ejecutarlo, extraerlo y
analizarlo.

57
Volatility (I)
En muchas ocasiones no es posible analizar un problema o detectar una amenaza estudiando los
logs, los ficheros, las bases de datos , etc., pues las trazas del problema sólo están en la memoria
RAM de la máquina en ciertos momentos. Esto es, son volátiles.
En estas circunstancias se impone lo que denominamos análisis forense. Este tipo de análisis se
efectúa en diferido, esto es, capturando instantáneas de la memoria RAM de la máquina,
volcándolas a disco y analizándolas en detalle posteriormente.
La herramienta open source más popular para efectuar este tipo de análisis es el Framework
Volatility . Existen dos versiones principales, la 2.x que funciona con Python 2.x, y la versión 3.x
que funciona con Python 3.x. La versión 2.x dejó de tener soporte en enero de 2020.
La versión 3 es mucho más rápida que la 2.x, pero no tiene la misma cantidad de
complementos/funciones que Volatility 2, por lo que es mejor instalar ambas versiones y usar la
versión que mejor se adapte a una tarea en particular, que por ahora es probablemente Volatility
2.
El framework se puede ejecutar en diferentes plataformas, no obstante, por cuestiones de
versatilidad y flexibilidad usaremos una máquina Linux.

58
Volatility (II)
Instalarlo en un Linux es sencillo:
git clone [Link]
cd volatility3
sudo python3.x [Link] install
Queda en el siguiente path
/usr/local/lib/python2.7/dist-packages/[Link]
Requiere varios paquetes recomendados para funcionar:

Distorm3 - Powerful Disassembler Library For x86/AMD64

Yara - A malware identification and classification tool
PyCrypto - The Python Cryptography Toolkit
PIL - Python Imaging Library
OpenPyxl - Python library to read/write Excel 2007 xlsx/xlsm files
ujson - Ultra fast JSON parsing library
Para instalarlos: pip3 install storm3 yara pycrypto Pil-Lite openpyxl ujson
pip3 install –r [Link]

59
Volatility (III)
Para poder trabajar con un volcado de memoria hay que saber
primero qué perfil tiene, es decir, de qué sistema operativo se
tomó (es lento)
[Link] -f [Link] imageinfo
[Link] -f [Link] kdbgscan
Después se puede probar con cualquier comando como listar
los procesos que estaban activos (indicando el perfil).
[Link] -f [Link] --profile PerfilWindows pslist
[Link] -f [Link] --profile Win8SP0x64 pslist

60
Análisis de Malware (I)
Un rootkit se usa habitualmente para esconder algunas aplicaciones que podrían actuar en
el sistema atacado. Suelen incluir backdoors (puertas traseras) para ayudar al intruso a
acceder fácilmente al sistema una vez que se ha conseguido entrar por primera vez. Por
ejemplo, el rootkit puede esconder una aplicación que lance una consola cada vez que el
atacante se conecte al sistema a través de un determinado puerto. Los rootkits del kernel o
núcleo pueden contener funcionalidades similares. Un backdoor puede permitir también que
los procesos lanzados por un usuario sin privilegios de administrador ejecuten algunas
funcionalidades reservadas únicamente al superusuario. Todo tipo de herramientas útiles
para obtener información de forma ilícita pueden ser ocultadas mediante rootkits.
Los rootkits se utilizan también para usar el sistema atacado como «base de operaciones»,
es decir, usarlo a su vez para lanzar ataques contra otros equipos. De este modo puede
parecer que es el sistema infiltrado el que lanza los ataques y no el intruso externo. Este
tipo de ataques podrían ser de denegación de servicio (DoS), ataques mediante IRC o
mediante correo electrónico (spam).

61
Análisis de Malware (II)
Rootkit a nivel kernel
Los que actúan desde el kernel añaden o modifican una parte del código de dicho núcleo
para ocultar el backdoor. Normalmente este procedimiento se complementa añadiendo
nuevo código al kernel, ya sea mediante un controlador (driver) o un módulo, como los
módulos del kernel de Linux o los dispositivos del sistema de Windows. Estos rootkits
suelen parchear las llamadas al sistema con versiones que esconden información sobre
el intruso. Son los más peligrosos, ya que su detección puede ser muy complicada.

Rootkit a nivel aplicación

Los rootkits que actúan como aplicaciones pueden reemplazar los archivos ejecutables
originales con versiones crackeadas que contengan algún troyano, o también pueden
modificar el comportamiento de las aplicaciones existentes usando hacks, parches,
código inyectado, etc.

62
Análisis de Malware - chkrootkit
El comando chkrootkit es una herramienta para buscar localmente signos de un rootkit. Si bien su ejecución es directa,
cuenta con los siguientes scripts que llevaran adelante las diferentes instancias de análisis cuando ejecutemos el
comando:
 chkrootkit: El programa principal que chequea los binarios del sistema operativo en busca de modificaciones
hechas por rootkits para saber si los códigos fueron adulterados.
 Ifpromisc.c: Chequea si las interfaces están modo promiscuo, si una interfaz de red está en modo promiscuo puede
ser usada por un atacante o por un software malicioso para captura tráfico de la red y analizarlo después.
 chklastlog.c: Revisa lo que fue eliminado de lastlog. Lastlog es un comando que muestra información sobre los
logins en el sistema. Un atacante o rootkit podría modificarlos para evitar detección si el administrador usa el
comando para acceder a información sobre los ingresos.
 Chkwtmp.c: Similar al script anterior, este script chequea el archivo wtmp que contiene información sobre los logins
en el sistema, chkwtmp.c intenta detectar modificaciones en este archivo.
 check_wtmpx.c: Igual que el anterior pero para sistemas Unix Solaris.
 chkproc.c: Busca indicios de troyanos en LKM (Loadable Kernel Modules).
 chkdirs.c: Similar al anterior chequea por troyanos dentro de los módulos del kernel.
 strings.c: Busca por reemplazo de strings que puedan ocultar rootkits.
 Chkutmp.c: Trabaja sobre el archivo utmp.

63
Análisis de Malware - chkrootkit
Instalamos chkrootkit: sudo apt install chkrootkit
Y lo ejecutamos como superusuario:

64
Análisis de Malware - rkhunter
Rkhunter (o Rootkit Hunter) es una herramienta de Unix que detecta los rootkits, las puertas traseras y los
exploit locales mediante la comparación de los resúmenes MD5 de ficheros importantes con su firma
correcta en una base de datos en línea, buscando los directorios por defecto (de rootkits), los permisos
incorrectos, los archivos ocultos, las cadenas sospechosas en los módulos del kernel, y las pruebas
especiales para Linux y FreeBSD.

En el archivo /etc/default/rkhunter se define que las actualizaciones de la base de datos sean semanales,
que la verificación de rootkits sea diaria y que los resultados sean enviados por e-mail al administrador del
sistema (root).

No obstante, si queremos asegurarnos, podemos actualizar la base de datos con el siguiente comando:

# rkhunter --propupd

Para comprobar que nuestro sistema esté libro de estos «bichos» simplemente ejecutamos:

$ sudo rkhunter --check

La aplicación comenzará a realizar una serie de comprobaciones y en su momento nos pedirá oprimir la
tecla ENTER para continuar. Todos los resultados los podremos consultar en el fichero
/var/log/[Link]

65
Análisis de Malware - rkhunter

66
Análisis de Malware - unhide
Unhide es una herramienta forense para encontrar
procesos y puertos TCP/UDP ocultos por rootkits, módulos
del kernel de Linux u otras técnicas. Incluye dos
utilidades: unhide y unhide-tcp.
Instalamos: sudo apt install unhide
Una vez instalado tenemos que indicar el tipo de test a
realizar. Hay test estándar (brute, proc, procall, procfs,
quick, reverse y sys) y test elementales (checkkill,
checkgetsid, checkchdir, etc.).

67
Análisis de Malware - unhide

68
Recuperación de archivos

Es importante diferenciar un fichero de texto de uno binario.

Los ficheros de texto se representan con los caracteres que corresponden
al contenido binario, usando para ello una tabla de correspondencia
número / código --> carácter
Existen múltiples tablas y por lo tanto codificaciones, siendo ASCII las más
básica y primitiva, y que es la base para las codificaciones actuales.
Los ficheros binarios, dado que no tienen representación en caracteres, los
analizamos en su representación hexadecimal, por lo conveniente de este
sistema de numeración para expresar números binarios.
Entender un editor hexadecimal es importante para visualizar ficheros
binarios, volcados de memoria, capturas de red, etc.

69
Recuperación de archivos

En Linux tenemos múltiples editores

hexadecimales:
• xxd
• hexedit
• hexyl (en color)
• bless
• ghex
• … 70
Recuperación de archivos

Columna de
dirección u
OFFSET

Columna de
datos en
representación
hexadecimal

Columna de
interpretación
como texto
ASCII

71
Recuperación de archivos
La columna de dirección u offset nos indica el byte de comienzo de la línea
en relación al total del fichero. En el caso del ejemplo, la primera línea empieza
en 0 y la segunda en 1016 ,es decir, en el byte 16.

Cada carácter hexadecimal representa 4 bits. En la primera línea tenemos 32

caracteres hexadecimales o lo que es lo mismo, 128 bits, o 16 bytes, del 0 al
15.
En la columna de datos tenemos la secuencia de ceros y unos convertida a
hexadecimal, 128 bits, o 32 hexadecimales.
Por último, en la columna de interpretación como texto, el editor busca la
correspondencia de cada 8 bits con su carácter de la tabla ASCII, por lo que nos
presentará 16 caracteres. Si la información origen es texto, total o
parcialmente, aparecerán cadenas legibles.

72
Recuperación de archivos
Tipos de fichero
Acostumbramos a distinguir el tipo de fichero por la extensión, que se
corresponde con la cadena de texto que aparece a la derecha del punto en el
nombre del fichero.
Este tipo de identificación es precaria, ya que es fácilmente modificable.
Sin embargo, todos los tipos de ficheros tienen características comunes.
Atendiendo a su estructura, contienen un campo de firma o de cabecera (o
ambos), que nos permiten identificar de qué tipo de fichero se trata. Este valor
se conoce como Magic number y no sigue un estándar para todos los ficheros.
Los primeros 8 bytes son la cabecera.
Los ficheros PDF por ejemplo, tienen como cabecera 25 50 44 46.

73
Recuperación de archivos
Tipos de fichero
• Los ficheros JPG / JPEG tienen como cabecera 0x FF D8 FF (el 0x indica notación
hexadecimal).
• Los ficheros BMP tienen como cabecera 0x 42 4D
• Los ficheros GIF tienen como cabecera 0x 47 49 46
• Los ficheros PNG tienen como cabecera 0x 89 50 4E 47
• Los ficheros de Office (DOCX, PPTX, XLSX) tienen como cabecera 0x 50 4B 03 04 14 00
06 00
Página para consultar las firmas de otros tipos de ficheros.
Otra página es [Link]
Es importante tener en cuenta que dentro de la misma familia de códecs de compresión de
imagen, aún teniendo la misma extensión .jpg, varía algún dato de la cabecera, por ejemplo de
una foto tomada con Canon EOS o con un móvil Samsung.

74
Recuperación de archivos
 Dependiendo de la casuística se usarán una u otra técnica.
 En caso de que el sistema de ficheros esté corrupto, sólo nos queda usar
la técnica de carving, consistente en la búsqueda de fragmentos de
ficheros, recorriendo toda la superficie del disco. Se basa en la búsqueda
de patrones como firmas, y reconstrucción de ficheros a partir de estos.
 Las herramientas de carving son independientes del sistema de
ficheros, ya que buscan por un tipo de fichero en concreto, a partir de
una cantidad de datos en bruto (RAW), con las cabeceras y los pies
conocidos de dicho fichero. Algunas herramientas tratan de obtener
información del sistema de ficheros que facilite la recuperación como
Photorec.

75
Herramientas Carving
 Foremost. Herramienta desarrollada por el ejercito de EEUU, es, junto
con Photorec la que mejores resultados obtiene.
 Scalpel. Pertenece a la herramienta TSK. Es un fork de Foremost. Muy
rápido, pero no el que obtiene el mejor resultado.
 Photorec es la que mejores resultados ofrece, porque no procesa
únicamente las cabeceras o pies de los ficheros, sino que procesa todos
los bloques. Realiza múltiples comprobaciones basadas en el tamaño
del fichero. Es multiplataforma y dispone de un asistente en modo
texto. Eso si, es con diferencia la que más tiempo toma en el proceso.
Todas ellas están disponibles en distribuciones forenses, por ejemplo en
Paladin.

76
Herramientas Carving
Photorec

PhotoRec acompaña a TestDisk, una aplicación para recuperar particiones perdidas en una amplia
variedad de sistemas de archivos y que hace que los discos que no son booteables, sean booteables
de nuevo.

77
Herramientas de auditoria
Lynis - Herramienta de auditoría de seguridad y hardening, para sistemas basados
en UNIX, como Linux, macOS, BSD y otros.

Realiza un análisis de seguridad en profundidad y se ejecuta en el propio sistema. El objetivo

principal es poner a prueba las defensas de seguridad y proporcionar consejos para un mayor
endurecimiento del sistema. También buscará información general del sistema, paquetes de
software vulnerables y posibles problemas de configuración. Nos permite comprobar si
“alguien” ha cambiado la configuración del sistema durante un incidente. Lynis era utilizado
habitualmente por administradores de sistemas y auditores para evaluar las defensas de
seguridad de sus sistemas. Además del "equipo azul", hoy en día los pentesters también tienen
Lynis en su kit de herramientas.

[Link]

[Link]

78
Herramientas de auditoria
$sudo lynis audit system

Nos mostrará un log y un informe final.

También permite auditar un dockerfile.

79
 Enlaces relacionados
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]