Tema 10

Hacking Ético

Metodología de análisis
de malware
 Índice
Esquema 3

Ideas clave 4
10.1. Introducción y objetivos 4
© Universidad Internacional de La Rioja (UNIR)

10.2. Métodos de obtención de malware 5

10.3. Laboratorio de análisis de malware 6
10.4. Metodología de análisis de malware 10
10.5. Lecciones magistrales 26

A fondo 27

Test 28
 © Universidad Internacional de La Rioja (UNIR)

Tema 10. Esquema

Esquema

Hacking Ético
3
 Ideas clave

10.1. Introducción y objetivos

Con el objetivo de ayudar al analista y obtener una comprensión e información

completa del malware bajo estudio, se necesita una metodología que implemente un
proceso sistemático de análisis de malware, basado en una serie de procedimientos
de uso de los métodos y técnicas de análisis y sus herramientas asociadas.

Esta necesidad se justifica dada la gran diversidad de herramientas, técnicas y

métodos de análisis de malware existentes en la actualidad, la cada vez mayor
complejidad que este presenta y los inconvenientes que tienen los análisis
automáticos dinámicos o de comportamiento en Sandbox.

El presente tema se centra en el estudio de una metodología de análisis e ingeniería

inversa de malware, utilizando técnicas y métodos de análisis y reingeniería de
malware, cuyo principal objetivo es la adquisición de conocimiento y la obtención de
un entendimiento completo de un malware concreto, su funcionamiento,
identificación y formas de eliminación.

Objetivos:

 Conocer los diferentes tipos de métodos de obtención de malware.

 Obtener los conocimientos necesarios para implementar un laboratorio de análisis
de malware.
© Universidad Internacional de La Rioja (UNIR)

 Conocer los aspectos fundamentales que comprende una metodología de análisis.

 Explicar los diferentes alcances de los diferentes pasos de la metodología de
análisis propuesta: acciones iniciales, clasificación, análisis dinámico y análisis
código.

Hacking Ético
4
Tema 10. Ideas clave
 10.2. Métodos de obtención de malware

El análisis de malware parte de la obtención previa de muestras maliciosas, bien sea

en el transcurso de un incidente (a la hora de analizar un artefacto instalado en una
máquina infectada), mediante la consulta en fuentes abiertas o mediante la
instalación de sistemas de recolección de muestras.

Podemos recolectar malware de una máquina infectada a través de volcados de

memoria (con herramientas como Volatility) o utilizando herramientas más cercanas
al triaje forense, como FastIR Collector, WinTriage, etc.

También existen varias fuentes abiertas de soporte al threat hunting o dedicadas a

la catalogación de muestras del malware:

 MalwareBazaar. Base de datos de la Universidad de Berna para contribuir en la

lucha contra el malware.

 theZoo. Repositorio de GitHub que contiene un amplio catálogo de muestras y de

algunos códigos fuente.

 [Link]. Esta plataforma de sandboxing hace públicas las muestras subidas por
los clientes que no tienen funcionalidades de pago, por lo que también será una
buena fuente de obtención de artefactos maliciosos.

 vx-underground. Comunidad de analistas que, además de contenido divulgativo

relacionado con el desarrollo de malware y diferentes técnicas ejecutadas por
© Universidad Internacional de La Rioja (UNIR)

actores maliciosos, conserva un repositorio de muestras.

Por último, recurriremos a sistemas de decepción para la obtención de muestras más

recientes. Los sistemas por excelencia, con este cometido, son conocidos como
honeypots. Un honeypot es un sistema que imita el funcionamiento de una

Hacking Ético
5
Tema 10. Ideas clave
 máquina normal, susceptible de ser atacada por una amenaza concreta, pero que no
está involucrada en los procesos de la organización. Cuando un malware infecta esta
máquina, podremos recoger registros sobre su actividad y, en última instancia,
recuperar la muestra que la ha infectado. En función del grado de realismo que tiene
la máquina, íntimamente relacionado con su coste, diferenciaremos entre:

 Honeypots de baja interacción. Exponen puertos relacionados con servicios y

ofrecen una mínima interacción con el atacante. Suelen carecer de capacidad de
mantenimiento de sesión, pero son baratas de mantener.

 Honeypots de alta interacción. En lugar de limitarse a fingir ser un servicio,

implementan el servicio completo, pero alejado de una operativa real. Requieren
de una gran cantidad de recursos, tanto para ejecutar los servicios, como para
monitorizarlos. Sin embargo, son más susceptibles de obtener información sobre
ataques reales que normalmente pueden detectar un entorno simulado

La instalación de estas honeypots debe hacerse siempre en un entorno controlado,

alejado de activos de información reales, para evitar incidentes. Normalmente se
ubican en entornos conocidos como honeynets que, además de emular servicios
concretos, emulan la infraestructura de soporte (arquitectura, componentes de red,
etc.).

10.3. Laboratorio de análisis de malware

Para analizar malware sin correr riesgos, debemos contar con cierta infraestructura
© Universidad Internacional de La Rioja (UNIR)

técnica y organizativa, que se concretará en forma de laboratorio de análisis.

Ilustraremos los componentes hardware, software, procedimentales y los
relacionados con la planificación necesaria para ejecutar esta tarea.

Hacking Ético
6
Tema 10. Ideas clave
 Para construir nuestro laboratorio, utilizaremos tecnologías de virtualización, que
permitirán ahorrar costes frente al uso de hardware e incluso tendrá ciertas ventajas.
Necesitaremos:

1. Anfitrión con capacidad hardware suficiente y software de virtualización.

2. Máquina víctima.
3. Máquina proxy de análisis.

Preparación del anfitrión

El equipo anfitrión (nuestro equipo) debe contar con un hipervisor que permita la
virtualización de hardware, así como la creación de snapshots (guardar el estado de
la máquina de forma que sea recuperable). Algunas de las tecnologías más comunes
en este ámbito son:

 Virtualbox.
 VMware.
 Qemu.

Crearemos dos máquinas virtuales: una para la víctima y otra para el proxy. Cuando
estén configuradas, estableceremos la siguiente configuración de red:

 Red 1. Red entre la máquina proxy y el anfitrión. Debe permitir que el proxy
acceda a Internet.

 Red 2. Red entre la máquina víctima y la máquina proxy. No debe permitir que la
víctima acceda a Internet a no ser que se configure el proxy para que enrute el
© Universidad Internacional de La Rioja (UNIR)

tráfico a través de la Red 1.

De esta forma, podremos controlar el tráfico generado por la máquina víctima y

manipularlo sin que tenga visibilidad de la máquina anfitrión (Figura 1).

Hacking Ético
7
Tema 10. Ideas clave
 Figura 1. Laboratorio de análisis de malware. Fuente: elaboración propia.

Proxy de análisis

El proxy de análisis debe contar con todas las herramientas necesarias para poder
interceptar y manipular el tráfico de red. Además, al igual que la máquina anfitriona,
debe estar diseñado con una tecnología diferente a la máquina víctima, para evitar
posibles movimientos laterales (si estamos analizando una víctima Linux, utilizar
como proxy y anfitrión un Windows, por si el malware es capaz de «saltar»).
Al analizar principalmente sistemas Windows, nuestra máquina proxy contará con un
sistema Linux llamado REMnux.

Máquina víctima

La máquina víctima debe correr un sistema operativo en el que pueda ejecutarse el

malware. Aunque podemos trabajar con cualquier edición de Windows, desde
Windows 8 el sistema operativo ejecuta una ingente cantidad de tareas en segundo
© Universidad Internacional de La Rioja (UNIR)

plano que pueden dificultar el análisis dinámico, por lo que se recomienda el uso de
Windows 7 (siempre que sea posible y la muestra vaya a ejecutarse en dicha versión).

Además, debemos introducir dentro del sistema las herramientas necesarias para el
análisis de la muestra. Para ello, contaremos con FlareVM. Este script transforma

Hacking Ético
8
Tema 10. Ideas clave
 completamente el sistema instalando todo el software necesario para hacer
cualquier análisis y configura la máquina para facilitar el estudio. Debemos tener en
cuenta que las medidas de protección de la máquina (Windows Defender, Firewall,
etc.) pueden suponer un obstáculo para el análisis de malware, por lo que debemos
deshabilitarlas cuando sea necesario.

Por último, habida cuenta de que el malware ha ido perfeccionando sus capacidades
para detectar entornos virtuales y evitar ser analizado, tendremos que configurar la
máquina para que sea lo más discreta posible en este sentido. Para ello, contaremos
con herramientas que, emulando al malware real, nos asesoren acerca de qué
elementos pueden desenmascarar nuestras intenciones (Figura 2). Algunas de estas
herramientas son:

 Pafish.
 InviZzzible.
 Al-Khaser.
© Universidad Internacional de La Rioja (UNIR)

Figura 2. Ejecución de pafish en el entorno [Link]. Fuente: elaboración propia.

Hacking Ético
9
Tema 10. Ideas clave
 Inicialización de los entornos

Una vez preparado el laboratorio, es importante que guardemos un snapshot de

cada máquina, de forma que si en algún momento alguna se corrompe (por acción
del malware o alguna operación mal realizada), podamos restaurarlo asegurándonos
tener una configuración estable, probada y segura.

10.4. Metodología de análisis de malware

Definición de objetivos

Antes de comenzar a analizar cualquier muestra, debemos tener claros cuáles son
nuestros objetivos, de cara a priorizar las actividades y la documentación de
nuestros hallazgos. Algunos objetivos habituales son:

 Obtención de indicadores de compromiso (IOC) para alimentar sistemas de

detección.
 Determinar el origen de la amenaza.
 Desarrollar mecanismos de prevención, respuesta y/o recuperación.
 Búsqueda de atribución de la amenaza.

Clasificación de la muestra

Antes de analizarla, debemos inventariar la muestra correctamente para evitar

errores, como ejecutarla sin querer en un entorno no controlado, o pérdidas, como
© Universidad Internacional de La Rioja (UNIR)

introducirla en un entorno donde un antivirus pueda borrarla. Para identificarla,

realizaremos varios hashes:

 Hashes criptográficos (sha1, sha256). Calculan la identidad única de la muestra.

Hacking Ético
10
Tema 10. Ideas clave
  Ssdeep. Genera una huella de la muestra que permita, además de identificarla,
determinar cuánto se parece a otras similares (para poder agruparlas por familias).

 Imphash. Similar a ssdeep, pero estudia las librerías importadas en lugar de

analizar el binario de la muestra. Si dos ejecutables importan las mismas librerías,
es fácil que tengan un comportamiento similar.

Cuantas menos operaciones realicemos con la muestra en la máquina anfitrión,

mejor. Podemos calcular todos estos valores desde la máquina REMnux, creando
antes de nada una copia protegida de la misma. Lo habitual es comprimir esta
muestra en un fichero zip con contraseña, es habitual el uso de la contraseña
infected (no necesitamos que sea confidencial, sólo queremos que esté cifrado para
que no genere alarmas en un sistema antivirus y no se ejecute por error).

Normalmente se utiliza el hash sha256 como nombre del fichero zip cifrado, así que
podemos calcular este valor, antes que nada, o introducirla con un nombre temporal,
y renombrarla después. Obviamente, para calcular el resto de los hashes debemos
trabajar con la muestra descomprimida, por lo que cuando esté en un entorno seguro
(dentro del proxy), procederemos a desempaquetarla y realizar el primer análisis,
asegurándonos previamente, eso sí, de no perder la copia protegida (el zip con
contraseña).

Con los comandos file y binwalk podremos analizar el número mágico del archivo
y los posibles binarios contenidos en él; y con exiftools obtener algunos metadatos
que ayuden a categorizarlo.

Estos datos serán nuestros primeros indicadores de compromiso (IOC), junto con las
© Universidad Internacional de La Rioja (UNIR)

cadenas de texto más relevantes que encontremos. Podemos extraerlas usando los
siguientes comandos:

Hacking Ético
11
Tema 10. Ideas clave
  Strings: busca patrones de texto en ficheros binarios, independientemente del
formato.

 Rabin2: Ejecutable desarrollado en el marco del programa radare2 que permite la

búsqueda de cadenas en ejecutables, analizándolos por secciones.

 FLOSS: programa desarrollado por FireEye para buscar cadenas de texto en

ficheros ofuscados.

Aunque muchas veces dependerá de nuestro análisis posterior, en este momento

podemos utilizar fuentes abiertas de inteligencia para determinar la relevancia de las
cadenas encontradas. Dentro de la máquina víctima, podremos utilizar otros
programas para hacer esta misma búsqueda con una puntuación automática.

Análisis en sandbox

Conocemos como sistemas sandbox a entornos emulados (virtualizados o físicos,

pero siempre aislados de cualquier activo real de la organización) que permiten
ejecutar muestras de malware y recolectar de forma automática evidencias
relacionadas con su comportamiento.

Mediante una sandbox, realizaremos un proceso muy similar al que ejecutaremos en

el análisis de comportamiento, pero de una forma menos versátil, con el objetivo de
extraer rápidamente los primeros indicadores de compromiso: solo ejecutaremos
la muestra, pero normalmente no interactuaremos con ella.

Algunas de las tecnologías de sandbox más conocidas que podemos instalar en

© Universidad Internacional de La Rioja (UNIR)

nuestra máquina son:

Hacking Ético
12
Tema 10. Ideas clave
  Cuckoo. Durante muchos años ha sido el principal sistema de sandboxing, pero
desde 2020 su desarrollo encuentra en un impasse hasta que termine de ser
portado a python3.

 CAPE. Derivado de cuckoo, cuenta con numerosas herramientas de análisis.

 WinlogBeat + Sysmon. Recientemente, gracias a la suite de herramientas basadas

en ElasticSearch, se ha popularizado la creación de sandboxes propias utilizando
herramientas de monitorización. Aunque son efectivas, con este tipo de sistemas
corremos el riesgo de que la máquina no esté lo suficientemente bien configurada
para prevenir movimientos laterales de la muestra ejecutada.

También podemos utilizar sistemas online que son más arriesgados desde el punto
de vista de la confidencialidad: la muestra puede ser dirigida a nuestra organización
y el atacante monitoriza estos servicios para detectar que está siendo analizado, o la
propia muestra se ha generado utilizando información confidencial de nuestra
organización. A pesar del riesgo, son mucho más económicas y efectivas. Algunas de
ellas son:

 [Link]. Permite la visualización y cierta interacción con la muestra, a la vez que

genera indicadores relacionados con la red, los archivos generados en disco, la
creación de procesos, etc.

 JOE Sandbox. Genera un exhaustivo informe que documenta las acciones

tomadas por el malware en la máquina y realiza una caracterización preliminar del
tipo de malware con base en su heurística.
© Universidad Internacional de La Rioja (UNIR)

Transmisión a la máquina víctima

Asumiendo que tenemos la muestra que queremos analizar en la máquina proxy,

para transmitirla a la máquina víctima debemos utilizar algún software que permita
hacerlo por red. Algunas sandbox, como cuckoo, instalan un agente propio en la

Hacking Ético
13
Tema 10. Ideas clave
 víctima que se encarga de recibir la muestra a través de la red interna y ejecutarla.
Como nuestro objetivo es realizar un análisis manual, debemos tomar otras
aproximaciones. Entre estas otras, podemos:

 Aprovechar los servicios del sistema y crear una carpeta compartida en la

máquina víctima, en la que depositaremos la muestra.
 Instalar un servidor FTP en la máquina víctima y subir a través de este la muestra.
 Instalar algún sistema en la máquina proxy que sirva archivos de forma remota:
servidor web, FTP, etc.
 Programar un agente propio que, a través de sockets, reciba la muestra y la
almacene en el disco.

Una vez depositemos la muestra en la máquina víctima, realizaremos un primer

snapshot para no tener que enviarla de nuevo cada vez que repitamos el proceso de
análisis.

Análisis de comportamiento

El análisis de comportamiento consistirá en ejecutar varias veces la muestra

(ejecutarla, restaurar el primer snapshot, volverla a ejecutar, etc.) observando cómo
interactúa con los distintos componentes del sistema operativo. En el caso de ser un
.exe, ejecutaremos la muestra como cualquier otro programa. Si, por el contrario,
fuese un .dll, utilizaremos el comando rundll32 especificando qué función queremos
lanzar, como se muestra en la Figura 3.
© Universidad Internacional de La Rioja (UNIR)

Figura 3. Código: ejecución de función de dll. Fuente: elaboración propia.

Antes de ejecutar la muestra, conviene calcular su entropía para determinar si puede

estar cifrada o empaquetada. Esta tarea puede realizarse en la fase de catalogación
de la muestra o directamente en la máquina víctima, donde contaremos con

Hacking Ético
14
Tema 10. Ideas clave
 herramientas que, además, pueden detectar qué tecnología se ha utilizado para su
ofuscación.

Podremos analizar el comportamiento del malware atendiendo, iterativamente, a

su interacción con los siguientes subsistemas:

Procesos

Antes de ejecutar la muestra, debemos abrir una aplicación de monitorización de

procesos, como Process Hacker o Process Explorer de sysinternals. Desde aquí,
analizaremos el árbol de llamadas que lleva a la ejecución del proceso y
manipularemos su ejecución para poder seguirle la pista con el resto de las
herramientas (Figura 4).

Figura 4. Suspensión de proceso desde Process Hacker. Fuente: elaboración propia.

Desde las propiedades del proceso, podemos también analizar los ficheros y mutex
que utiliza (handles), su token del sistema, etc. En caso de que no encontremos el
© Universidad Internacional de La Rioja (UNIR)

proceso, iremos a la pestaña «Find handles or DLLs» y buscaremos el nombre del

ejecutable lanzado, para obtener el nombre del proceso (Figura 5).

Hacking Ético
15
Tema 10. Ideas clave
 Figura 5. Búsqueda de handles. Fuente: elaboración propia.

Registro

Antes de lanzar la muestra, realizaremos una captura del registro con la herramienta
regshot. Una vez completada, procederemos a ejecutar el malware y, tras un tiempo
prudencial para que pueda realizar sus funciones, realizaremos una segunda captura.

Utilizando la opción de comparación, obtendremos una lista con todos los registros
modificados, borrados y creados entre ambas capturas. Entre estos registros se
encontrará toda la actividad realizada por el malware, mezclada con la de procesos
legítimos (Figura 6), así que debemos aprender a discriminar una de otra.
Si queremos ser más meticulosos, podemos trabajar con Procmon, filtrando por
operaciones con el registro.
© Universidad Internacional de La Rioja (UNIR)

Figura 6. Resultados de regshot. Fuente: elaboración propia.

Hacking Ético
16
Tema 10. Ideas clave
 Disco / Almacenamiento

Podemos monitorizar la interacción que tiene el malware con el disco duro

utilizando Procmon, de Sysinternals. En esta fase buscamos enumerar los accesos que
realiza a nuestros archivos, pero también qué ficheros crea, en aras de determinar si
está obteniendo nuevos ejecutables o incluso si podemos analizar algún fichero de
configuración.

Lanzaremos Procmon y nos aseguraremos de que todavía no está capturando

eventos (no debe aparecer activo «File» > «Capture events») o se nos desbordará la
interfaz con todos los eventos que se estén produciendo en el sistema. Por si se ha
«colado» alguno, pulsaremos el botón «Clear» (o el atajo Ctrl+X) y pasaremos a filtrar
la actividad del malware en el menú «Filter» > «Filter» (o también, con el atajo Ctrl+L).

Esta herramienta es de las más potentes y versátiles que tenemos en nuestro arsenal,
porque permite analizar prácticamente cualquier ámbito del sistema, pero esta vez
lo restringiremos al uso de disco filtrando:

 Por nombre de proceso: elegiremos la opción «Process name», la condición «is»

o «contains» («contains» puede meter información de otros procesos, pero en
una primera iteración nos ayudará a no perdernos nada) y el nombre (o parte del
nombre) del proceso que hemos detectado anteriormente.

 Por operación: para esta tarea filtraremos por operaciones que terminen en «File»
(operaciones con archivos de la API de Windows).
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
17
Tema 10. Ideas clave
 Figura 7. Configuración de filtros en Procmon. Fuente: elaboración propia.

Una vez establecidos todos los filtros (Figura 7), arrancaremos la captura (pulsando
de nuevo Ctrl+E o a través del menú de archivo) y ejecutaremos la muestra. Cuando
consideremos que tenemos suficientes eventos, pararemos la captura (o seguirá
hasta desbordarse) y comenzaremos a analizar qué archivos han sido creados o
abiertos (operación «CreateFile»), escritos (operación «WriteFile»), etc. La captura
obtenida en la Figura 8 muestra, como ejemplo, las operaciones sobre archivos que
realiza OneDrive para sincronizar un fichero en edición.
© Universidad Internacional de La Rioja (UNIR)

Figura 8. Operaciones sobre archivos. Fuente: elaboración propia.

Hacking Ético
18
Tema 10. Ideas clave
 Red

El análisis que podamos hacer de las operaciones de red de la muestra depende del
protocolo utilizado para comunicarse (si está cifrado o no y la tecnología concreta),
si utiliza algún tipo de canal encubierto, etc. De forma genérica, utilizando una
herramienta como Wireshark, podemos centrarnos en detectar:

 Nombres de dominio consultados: analizando las peticiones DNS.

 Direcciones IP a las que accede: simplemente enumerándolas.
 Contenido en claro mandado en las peticiones: cuando las peticiones no estén
cifradas, veremos el contenido e incluso podremos recuperar de la propia captura
los archivos descargados.

Ejecutando FakeNet en la máquina proxy (Figura 9), podemos levantar diferentes

servicios que actuarán como sistemas finales para el malware. Simularemos
servidores HTTP, FTP, DNS, etc.; de forma que, cuando el malware trate de
conectarse con sistemas externos, podamos capturar la comunicación e, incluso,
emular una respuesta.
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
19
Tema 10. Ideas clave
 Figura 9. Ejecución y resultados de Fakeet-NG. Fuente: elaboración propia.

En REMNux, para que FakeNet pueda desplegar correctamente el sistema de

resolución DNS, debemos detener el servicio systemd-resolved (que ocupa tambien
el puerto 53). Al igual que Wireshark, FakeNet también almacenará un fichero pcap
por cada sesión, para que posteriormente podamos realizar un análisis de lo ocurrido.

Idealmente, si toda la comunicación realizada por el malware fuese a través de

peticiones HTTP, aun si fuesen cifradas, contamos con numerosas herramientas que
pueden actuar como proxy del contenido. Burp, ZAP o mitmproxy ofrecen la
posibilidad de, incluso, acceder al tráfico https de una forma sencilla. Si utiliza algún
protocolo propio, en muchas ocasiones tendremos que programar nuestros propios
sistemas de análisis.
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
20
Tema 10. Ideas clave
 Análisis de memoria

Con el elemento a analizar en ejecución, podemos obtener un volcado de memoria

para analizar elementos a los que antes, por las limitaciones del sistema (controles
de seguridad, niveles de ejecución, etc.) no podíamos acceder. Esta técnica es
especialmente relevante a la hora de analizar sistemas que trabajan en modo kernel
o que incluso estén cargados previamente (bootkits, rootkits, etc.).

Comenzaremos realizando un volcado de memoria. Cuando trabajamos en una

máquina virtual, es sencillo obtenerla a través de los menús del hipervisor. Cuando
trabajemos en una máquina real (o en una virtual, pero queramos un volcado
realizado por el sistema operativo), tendremos que utilizar herramientas específicas.

Podemos obtener un volcado de la memoria del proceso concreto con muchas

herramientas, pero esta práctica busca obtener la memoria de todo el sistema
operativo. Conseguiremos esto a través de una de las siguientes técnicas:

 Crashes del sistema con notmyfault: crearemos un volcado de memoria, mediante

interfaz gráfica o por consola, generando un fallo del sistema.

 Crashes manuales: si el malware puede detectar el uso de la herramienta, pueden

configurarse atajos de teclado que generen un error crítico en el sistema.

Previamente, desde la configuración del sistema (Figura 10), debemos establecer el

tipo de volcado que queremos que se genere cuando haya fallos críticos (completo,
sólo del espacio de kernel, etc.) y la ruta en la que queremos que se guarde
(generalmente, se generará el volcado en la ruta C:\Windows\[Link]).
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
21
Tema 10. Ideas clave
 Figura 10. Configuración de dumps. Fuente: elaboración propia.

Una vez generado el volcado, procederemos a analizarlo (Figura 11), podemos

utilizar herramientas como WinDBG o Volatility. Esta última, en concreto, cuenta con
numerosos plugins ampliamente documentados y creados para el análisis de
malware, como malfind o yarascan.

Figura 11. Ejecución de yarascan en Volatility. Fuente: elaboración propia.

Análisis estático de código

A la hora de analizar el código, definiremos una serie de ítems clave que facilitarán
© Universidad Internacional de La Rioja (UNIR)

nuestro trabajo. Utilizando IDA, comenzaremos por conocer los siguientes aspectos:

Hacking Ético
22
Tema 10. Ideas clave
 Librerías y funciones utilizadas

Si la muestra se ha creado utilizando enlazado dinámico, tendrá codificada una tabla

(la sección .edata) en la que haga referencia a qué funciones y de qué librerías del
sistema va a ejecutar. Desde la pestaña Imports, de IDA, enumeraremos las
funciones del sistema (o de otras dll) utilizadas por el malware. Esto nos dará una
primera perspectiva orientándonos acerca de qué funcionalidades va a tener. Por
ejemplo, la muestra analizada en la Figura 12 realizará claramente peticiones a algún
servicio web.

Figura 12. Funciones de red importadas por la muestra. Fuente: elaboración propia.

Funciones exportadas

En ocasiones. la muestra no será un .exe, sino un .dll con código malicioso. Para
analizar su comportamiento, tendremos que detectar qué funciones exporta, pues
serán los puntos de entrada utilizados por la pieza encargada de ejecutarlo.

Identificar secuencias clave en el código

Analizando el código ensamblador, podremos detectar si el malware hace

© Universidad Internacional de La Rioja (UNIR)

comprobaciones previas a su ejecución y obtener un conocimiento mucho más

profundo de determinadas funcionalidades que antes desconocíamos.

A modo de ejemplo, la Figura 13 muestra el fragmento de un malware en el que, a

través de un bucle, se descifra una secuencia utilizando la función XOR en cada uno

Hacking Ético
23
Tema 10. Ideas clave
 de los valores de un array. Este es un mecanismo simple y pobre de cifrado, pero muy
utilizado por el malware para ofuscar configuraciones.

Figura 13. Ejemplo de cifrado XOR. Fuente: elaboración propia.

Análisis dinámico de código

El análisis dinámico consistirá en la ejecución del malware, pero esta vez, en lugar de
observar sus efectos sobre el sistema operativo, analizaremos su funcionamiento
interno. Para ello, cargaremos la muestra en un entorno de depuración, como
x64dbg.
© Universidad Internacional de La Rioja (UNIR)

Una vez cargado, normalmente la herramienta ejecuta la muestra, pero la detiene en

la primera instrucción (el entrypoint). Nuestra tarea será ejecutar las instrucciones
de forma que podamos entender qué ocurre en cada bloque de código, con la
particularidad de que podremos ver también:

Hacking Ético
24
Tema 10. Ideas clave
  Funcionalidades que no tenía previamente: librerías cargadas, código
desempaquetado, etc.
 Valores en memoria: valores introducidos en los registros, en la pila, etc.

Normalmente no ejecutaremos las instrucciones de una en una, más que en

momentos puntuales, sino que buscaremos fragmentos concretos. Para ello, de
forma similar, identificaremos las llamadas a funciones, por ejemplo, el cuadro
superior de la Figura 14 muestra las funciones relacionadas con el uso de registro
utilizadas por un programa, y en vez de «tirar del hilo», buscando el origen de las
llamadas, configuraremos puntos de interrupción (breakpoints).

Cuando ejecutamos el programa (si es un .dll, en lugar de un .exe, podemos hacerlo

a través de [Link]), si el flujo de ejecución pasa por uno de estos breakpoints,
se detendrá. En este momento podremos observar, en la memoria, valores que nos
habría sido posible identificar en el análisis estático. En el ejemplo de la Figura 14
vemos el registro concreto al que intenta acceder el programa al llamar a la función
RegOpenKeyExInternalw (la función que se acaba ejecutando a bajo nivel cuando se
accede a un registro).
© Universidad Internacional de La Rioja (UNIR)

Figura 14. Lectura de valores en la pila. Fuente: elaboración propia.

Hacking Ético
25
Tema 10. Ideas clave
 El programa x64dbg también permite proceder a la inversa. Buscando un valor en
memoria, podemos establecer un punto de ruptura que se active cuando el programa
acceda a dicho valor. De esta forma, podremos saber en qué contexto lo utiliza
(podremos identificar qué función abre un fichero de configuración almacenado en
una ruta conocida y, de esta forma, analizar cómo lo procesa).

10.5. Lecciones magistrales

En este video, titulado Malware en fuentes abiertas, se muestra el proceso de

búsqueda de una muestra de malware concreto, en base a sus indicadores de
compromiso, a través de distintas fuentes abiertas. La obtención de muestras es
imprescindible para realizar un análisis prospectivo.
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
26
Tema 10. Ideas clave
 A fondo
Rootkit Necurs: No es un bug, es una feature!

C0r0n4con Congreso. (2020, mayo 18). Rootkit Necurs ¡No es un bug, es una feature!
[Vídeo]. Youtube. [Link]

En el vídeo, los investigadores Roberto Santos y Javier Rascón muestran todo el

proceso desarrollado para analizar y comprender el funcionamiento del rootkit
Necurs. Uno de los aspectos más interesantes es cómo, más allá del método seguido,
en ocasiones puede tocar lidiar con comportamientos muy inesperados.

Sandbox fingerprinting - Evadiendo entornos de análisis

Rooted CON (2020, mayo 23). Sandbox fingerprinting: Evadiendo entornos de análisis –
Roberto Amado & Victor Calvo [RootedCON2020-ES] [Vídeo]. Youtube.
[Link]

Ponencia acerca de los riesgos que pueden correr el analista y su entorno si la

implementación de nuestro laboratorio de análisis no es correcta.
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
27
Tema 10. A fondo
 Test
1. ¿Cómo se llama a una máquina instalada para obtener malware emulando
sistemas reales, pero sin llegar a implementarlos?
A. Sandbox.
B. Honeypot de baja interacción.
C. Honeypot de alta interacción.
D. Honeypot de media interacción.

2. El hash que permite buscar las similitudes entre dos binarios se llama:
A. HashDiff.
B. ssdeep.
C. nltk.
D. SHA-1.

3. Un imphash:
A. Es para hacer hashes de archivos muy pequeños.
B. Es para hacer hashes de archivos muy grandes.
C. Genera una firma con las funciones utilizadas por el binario.
D. Genera una firma única de ficheros importantes.

4. Señale la opción menos prioritaria. Es importante que el entorno de ejecución del

malware sea:
A. Creíble.
B. Rápido.
C. Analizable.
© Universidad Internacional de La Rioja (UNIR)

D. Robusto.

Hacking Ético
28
Tema 10. Test
 5. Mediante el comando strings podemos:
A. Analizar el malware por hilos.
B. Extraer rápidamente IOC de texto.
C. Convertir el malware en cadenas de texto.
D. Convertir caracteres en estructuras de datos complejas.

6. Si no tenemos conocimiento de los requisitos de confidencialidad del malware, no

debemos:
A. Analizarlo en una sandbox local.
B. Analizarlo en una sandbox online.
C. Realizar un análisis dinámico de código.
D. Esperar a tenerlos claros.

7. El programa desarrollado por Sysinternals, Procmon, no permite:

A. Analizar el uso del registro.
B. Analizar el tráfico de red.
C. Analizar el uso de disco.
D. Analizar los procesos ejecutados.

8. ¿Cómo podemos ver el valor de los parámetros utilizados en las llamadas a

funciones?
A. Mediante análisis de código con IDA.
B. Mediante análisis dinámico con x64dbg.
C. Consultando con el parámetro -h.
D. Mediante análisis de funciones con PeStudio.
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
29
Tema 10. Test
 9. Si queremos analizar las funcionalidades de un programa malicioso que no se
ejecuta en el entorno de usuario:
A. Procederemos a arrastrarlo al entorno de usuario mediante hooking.
B. Buscaremos en Internet información, porque es imposible acceder a otras
áreas.
C. Lo haremos a través de un análisis de memoria.
D. Lo haremos mediante desensamblado del MBR.

10. Si no tenemos ninguna información, cuando el malware realice operaciones de

red, debemos:
A. Tratar de emular los servicios que quiere utilizar en el proxy.
B. Darle salida a Internet y capturar el tráfico.
C. Bloquear todas sus conexiones para evitar movimientos laterales.
D. Buscar una versión desactivada del malware para analizarla primero.
© Universidad Internacional de La Rioja (UNIR)

Hacking Ético
30
Tema 10. Test