1. Estudio de mercado del software que se utiliza en la gestión de incidentes y sus principales funcionalidades.
Tras realizar un pequeño estudio de mercado sobre el software de gestión de incidentes, sacamos la conclusión de que existen varias soluciones interesantes en el mercado, cada una con sus propias características y funcionalidades. Estos sistemas ayudan a las organizaciones a detectar, rastrear, priorizar y resolver incidentes de manera eficiente y efectiva. Algunas de las principales soluciones de gestión de incidentes son “ServiceNow”, “Jira Service Management”, “Zendesk”, “Freshservice” y “BMC Helix ITSM”.
Las principales funcionalidades de un software de gestión de incidentes son:
- Registro y seguimiento de incidentes: Los sistemas de gestión de incidentes permiten a los usuarios registrar y rastrear incidentes de manera centralizada, lo que facilita la organización y el monitoreo de problemas en tiempo real.
- Priorización y clasificación: Estos sistemas ayudan a priorizar y categorizar incidentes según su severidad, impacto y urgencia, lo que permite a las organizaciones asignar recursos y atención adecuados a cada incidente.
- Automatización del flujo de trabajo: La automatización del flujo de trabajo es una característica esencial en un software de gestión de incidentes, ya que permite asignar incidentes automáticamente a los equipos y miembros apropiados, además de generar y actualizar tickets automáticamente.
- Comunicación y colaboración: Los sistemas de gestión de incidentes ofrecen herramientas de comunicación y colaboración para facilitar el intercambio de información y la resolución de problemas en equipo. Esto puede incluir la integración con aplicaciones de mensajería, foros de discusión y funciones de comentarios en tiempo real.
- Base de conocimientos: Estos sistemas a menudo incluyen una base de conocimientos que permite a los usuarios buscar y acceder a información relevante, como soluciones a problemas comunes, documentos de soporte y guías de mejores prácticas.
- Informes y análisis: Un software de gestión de incidentes debe proporcionar informes y análisis detallados, lo que permite a las organizaciones identificar tendencias, áreas problemáticas y oportunidades de mejora.
- Integración con otros sistemas: La capacidad de integrarse con otros sistemas, como software de monitoreo de red, sistemas de gestión de activos y aplicaciones de soporte al cliente, es crucial para garantizar una gestión de incidentes eficiente y completa.
- Accesibilidad y movilidad: Los sistemas de gestión de incidentes modernos a menudo ofrecen acceso móvil y basado en la nube, lo que permite a los usuarios acceder a la información y gestionar incidentes desde cualquier lugar y en cualquier momento.
De todo lo anterior se concluye que un software de gestión de incidentes, para que sea eficiente y eficaz en sus funciones, debe contar con distintas funcionalidades que incluyan registro y seguimiento de incidentes, priorización y clasificación, automatización del flujo de trabajo, comunicación y colaboración, acceso a una base de conocimientos, informes y análisis, integración con otros sistemas y accesibilidad móvil y basada en la nube. Como es obvio, la elección de la solución adecuada dependerá de las necesidades específicas de cada organización y de su enfoque en la gestión de incidentes.
2. Porqué aislar un terminal de telefonía móvil de la red y de qué maneras distintas se puede realizar este proceso.
En base a la guía del NIST (National Institute of Standards and Technology), Guidelines on Mobile Device Forensics, podemos decir que es necesario aislar un terminal de telefonía móvil de la red, desde el punto de vista forense, por varias razones:
- Preservar la evidencia: Aislar un dispositivo móvil de la red es crucial para garantizar la integridad de los datos almacenados en él y prevenir cualquier alteración o eliminación remota de evidencia, tanto intencional como accidental. El acceso a la red podría permitir que terceros modifiquen o eliminen información relevante para llevar a cabo una investigación.
- Evitar la comunicación remota: Al desconectar un dispositivo móvil de la red, se impide que reciba o envíe llamadas, mensajes SMS, correos electrónicos u otras comunicaciones que puedan interferir con la investigación forense.
- Prevenir actualizaciones automáticas: Los dispositivos móviles pueden recibir actualizaciones automáticas de software y aplicaciones, lo que podría modificar los datos almacenados y afectar el análisis forense. Aislar el dispositivo de la red ayuda a garantizar que no se produzcan actualizaciones durante la investigación.
- Proteger la privacidad del usuario: Aislar un dispositivo móvil de la red ayuda a proteger la privacidad del usuario y garantizar que la información personal no sea accesible para terceros no autorizados durante el proceso de la investigación forense.
Respondiendo a la segunda pregunta, existen varias maneras de aislar un terminal de telefonía móvil de la red:
- Modo avión: Activar el modo avión en el dispositivo móvil deshabilita todas las funciones de comunicación inalámbrica, como Wi-Fi, Bluetooth y conexiones de datos móviles, lo que impide el acceso a la red.
- Bolsas o jaulas de Faraday: Estas bolsas o jaulas están diseñadas para bloquear las señales de radiofrecuencia, lo que evita que el dispositivo móvil se comunique con la red. Al colocar un dispositivo móvil dentro de una bolsa de Faraday se garantiza su aislamiento de la red. Como curiosidad indicar que es mediante el uso de Jaulas de Faraday como se mantienen seguros de ataques tipo TEMPEST los sistemas de Mando y Control aéreos, para evitar que sean perturbados/atacados por sistemas que proyecten emanaciones electromagnéticas.
- Herramientas de bloqueo de red: Estas herramientas, también conocidas como bloqueadores de señal o jammer, generan interferencia en las señales de radiofrecuencia para evitar que el dispositivo móvil se conecte a la red. Sin embargo, su uso puede ser ilegal, por lo que es importante verificar las leyes antes de emplearlas.
De todo lo anterior se concluye que aislar un terminal de telefonía móvil de la red es esencial para llevar a cabo un análisis forense con la finalidad de preservar la evidencia, evitar la comunicación remota, prevenir actualizaciones automáticas y proteger la privacidad del usuario. De los diferentes métodos para llevar a cabo este proceso los más adecuados desde mi punto de vista son el modo avión y las bolsas/jaulas de Faraday.
3. Ejemplo de un plan para implementar las capacidades de respuesta a incidentes de una compañía.
Para llevar a cabo el desarrollo de un plan para la implementación de las capacidades de respuesta a incidentes es fundamental seguir la guía del NIST 800-61 Computer Security Incident Handling Guide y considerar los siguientes aspectos:
- Creación del equipo de respuesta a incidentes (CSIRT):
- Establecer un equipo multidisciplinario que incluya miembros con habilidades en seguridad de la información, TI, redes, sistemas operativos, comunicaciones y gestión de riesgos.
- Proporcionar capacitación y formación continua al equipo de respuesta a incidentes para mantener sus habilidades actualizadas y estar preparados ante nuevas amenazas.
- Definir claramente los roles y responsabilidades de cada miembro del equipo, como la detección y análisis de incidentes, la contención y erradicación, y la recuperación y seguimiento.
- Infraestructura y herramientas necesarias:
- Implementar soluciones de software para registrar, rastrear y gestionar incidentes de seguridad, como un sistema de ticketing o un GRC.
- Utilizar soluciones de monitorización como sistemas tipo SIEM, de prevención de intrusiones (IPS) y de detección de intrusiones (IDS) para identificar posibles incidentes de seguridad.
- Implementar soluciones de protección de endpoints como antivirus, antimalware y software de cifrado.
- Establecer una infraestructura de respaldo y recuperación para garantizar la continuidad del negocio en caso de un incidente de seguridad.
- Adquirir herramientas de análisis forense para investigar y analizar incidentes de seguridad (Autopsy, Forensics Tool Kit, etc.).
- Establecer una plataforma de comunicación segura y eficiente para el intercambio de información dentro del equipo y con otras partes interesadas.
- Contratación externa:
- Considerar la contratación de servicios de consultoría o especializados, en caso de que el equipo interno no cuente con la experiencia o habilidades necesarias para abordar ciertos incidentes o situaciones.
- Contratar servicios de inteligencia de amenazas para mantenerse informado sobre las últimas tendencias y tácticas de los ciberdelincuentes.
- Alternativas:
- En lugar de crear un CSIRT interno, se puede considerar la posibilidad de contratar un proveedor de servicios de seguridad gestionados (MSSP) para externalizar la función de respuesta a incidentes.
- Evaluar si es más adecuado utilizar soluciones en la nube o locales teniendo en cuenta aspectos como la escalabilidad, la flexibilidad y los costos.
4. Práctica de un Análisis Forense Digital (AFD) de memoria RAM con Volatility.
El gerente de una tienda en línea, al sospechar que se ha producido una extracción no autorizada de información personal de sus sistemas, te contrata como perito forense para determinar si realmente ha ocurrido un incidente de seguridad. Para este análisis inicial, te proporciona únicamente una captura de la memoria RAM, realizada por el administrador del sistema, con el objetivo de decidir si es necesario realizar un análisis más exhaustivo del sistema.
Los valores hash de la adquisición de la evidencia son los siguientes:
MD5: 701409dc35ff7878b7c08a213d808861
SHA1: 1dbbbb924551f5234d911944a0e03fc2a6084450
Contesta las siguientes preguntas:
a) Antes de comenzar el análisis, se debe comprobar la integridad del fichero imagen de la memoria RAM y determinar el sistema operativo que tiene instalado el servidor sobre el que se ha realizado la captura.
A continuación se muestra el hash de integridad del archivo, tanto en SHA1 como en MD5. Ambos coinciden con los proporcionados en esta práctica.
A continuación se muestra una captura donde se puede observar una cadena de caracteres (strings) resultante del procesado del archivo binario proporcionado con IDA (herramienta de ingeniería inversa).
De la captura anterior se sacan las siguientes conclusiones en referencia al sistema operativo.
- Se trata de una versión de Linux, donde:
- «vmlinuz»: es el nombre del núcleo del sistema Linux comprimido.
- «4.14.62-65.117»: es la versión del núcleo del sistema Linux.
- «amzn1»: sugiere que es una versión de Linux utilizada por Amazon Web Services (AWS).
- «x86_64»: indica que es una versión de 64 bits para la arquitectura x86.
Se concluye que se trata de una instancia de Linux personalizada por Amazon Web Services basada en el kernel 4.14.62-65.117 y diseñada para funcionar en sistemas x86_64. Llegados a este punto creo que es interesante saber que AWS utiliza principalmente su propia distribución de Linux llamada Amazon Linux, que se basa en una mezcla de paquetes de distribuciones como Fedora y CentOS, y que está optimizada específicamente para su uso en servidores en la nube de AWS.
b) Mediante Volatility 2.6 se debe verificar que el perfil del sistema a analizar no está disponible en el paquete que se instala por defecto, y posteriormente se debe añadir el perfil que se adjunta en esta práctica.
Tras ejecutar el comando “python vol.py –info” en la instalación por defecto de Volatility 2.6, se comprueba que no aparece ningún perfil válido para el procesamiento del archivo binario. Una vez hemos introducido el archivo del perfil en el directorio “volatility\plugins\overlays\linux\”, podemos ver cómo la herramienta es capaz de listar el nuevo perfil. Se muestra captura a continuación.
A continuación, se muestra la captura donde se puede observar que con el nuevo perfil añadido a la herramienta se puede trabajar adecuadamente sobre el binario “memoria.bin”, ya que reconoce que dicho perfil da una identificación positiva de la imagen.
c) Se deben analizar las conexiones de red e identificar las distintas direcciones IP con las que interactúa el servidor. Esto es fundamental para identificar conexiones sospechosas.
De la gran cantidad de datos que nos arroja volatility en referencia a puertos abiertos y conexiones en el sistema, vamos a recoger únicamente aquellos que nos interesan para la ejecución de este ejercicio. A continuación, se muestra captura con las conexiones “establecidas”.
En la anterior captura se puede observar que hay varias conexiones establecidas que podrían considerarse sospechosas.
- La conexión entre las direcciones IP 172.31.36.177 y 172.31.44.165 al puerto 3306 podría ser una conexión legítima a un servidor MySQL, ya que el puerto 3306 es el puerto predeterminado para MySQL. Sin embargo, si no se esperan conexiones a ese servidor desde la IP 172.31.36.177, podría ser motivo de preocupación. Hay que tener en cuenta, además, que no es una buena práctica de seguridad el tener expuesto de manera pública el acceso a un servidor MySQL.
- La conexión entre las direcciones IP 172.31.36.177 y 88.0.112.115 al puerto 80 podría ser una conexión a un servidor web remoto a través del puerto HTTP predeterminado (80). Esto puede ser legítimo si el servidor necesita conectarse a un servidor web remoto, pero si no se espera esta conexión, es posible que esté sucediento una exfiltración de información en el sistema mediante el protocolo HTTP, lo cual no sería muy inteligente por parte de un atacante, ya que toda la información viajaría en texto claro durante su transmisión (no como con HTTPS), pero hay que tenerlo en cuenta.
- Las conexiones entre las direcciones IP 172.31.36.177 y 23.226.128.37 al puerto 22, así como 83.247.136.74, son conexiones entrantes al puerto 22 correspondiente al servidor de SSH. Si no se reconocen estas direcciones IP y no se esperan conexiones desde ellas, podrían ser intentos no autorizados de acceso al servidor a través de SSH.
Para investigar más a fondo, se deberían revisar los registros de acceso y error de los distintos servicios (Apache, MySQL, SSH) para obtener más detalles sobre las actividades realizadas en estas conexiones.
Sería una buena práctica de seguridad el bloquear el acceso a las direcciones IP sospechosas utilizando un cortafuegos o ajustando la configuración del servidor SSH para limitar el acceso a direcciones IP y usuarios específicos. Siempre es más seguro bloquear accesos mediante el uso de listas blancas, aunque dependiendo del servicio se deberá sopesar entre emplear listas blancas o negras.
d) Se deben analizar los comandos encontrados para determinar la actividad llevada a cabo en la máquina víctima.
Lo primero que llama la atención es que las marcas temporales de ejecución de los comandos parecen apuntar a que la ejecución de los mismos se han llevado a cabo a través de un mecanismo automatizado, ya que en una misma marca temporal (06:49:26, 08:28:08) se ejecutan una gran cantidad de comandos. Aún pensando en un script automatizado, es poco probable que todos los comandos se hayan ejecutado exactamente al mismo tiempo, ya que los sistemas operativos generalmente ejecutan comandos de manera secuencial, uno tras otro, para no caer en condiciones de carrera, aunque es cierto que pueden ejecutar múltiples comandos al mismo tiempo si se emplean múltiples núcleos de procesador, o si se ejecutan en paralelo utilizando técnicas de programación asíncrona.
No obstante, y tras revisar el log de comandos, podemos sacar una conclusión diferente, ya que como podemos observar en la siguiente captura, tras el último comando ejecutado a las 08:28:08 “sudo chkconfig http don”, la línea temporal continua hacia adelante hasta las 08:28:51 momento en el que se ejecuta el archivo “captura.sh”. Y es en este momento en el que la línea temporal va hacia atrás (algo totalmente fuera de lo natural) y procede a ejecutar comandos con una marca temporal de las 08:28:08 horas. También hay que detallar que el proceso de ejecución donde se llevan a cabo los comandos es distinto, ya que presenta un PID diferente (1149). Esto puede indicar que un usuario del sistema está manipulando las marcas temporales del sistema, bien a tiempo real, o bien tras haber finalizado la ejecución de comandos, habiendo llevado a cabo un posible “borrado de huellas” con técnicas de sustitución de datos para “engañar” a un posible perito forense digital.
Si continuamos estudiando la lista de comandos, podemos ver un patrón. Algunos comandos se repiten varias veces, y en general, siguen una secuencia similar. Algunas de las tareas que se realizan incluyen:
- Descargar archivos desde URLs, usando wget (por ejemplo, archivos .tar.gz de módulos Drupal) que ya veremos más adelante si se tratan de módulos vulnerables.
- Descarga e instalación de Drupal 7.57 y de módulos adicionales como “commerce_card”, “libraries”, y otros.
- Elimina los archivos descargados una vez no los necesita con el comando “rm”.
- Cambiar propietario y grupo de archivos y directorios, usando “sudo chown -R apache:apache *”.
- Compilación de programas usando comandos como “make, cmake, gcc”.
- Instalación y configuración de paquetes, usando comandos como “sudo yum install” y “sudo vi”.
- Control y manipulación de servicios, utilizando comandos como “sudo apachectl”, “sudo service”, etc.
- Clonación de repositorios Git, usando “git clone”.
- Visualización de los registros de Apache.
- Búsqueda de archivos de configuración mediante el uso de comandos tipo “ find . -name «conf*» ” o “ find . -name «sett*» ”. Estos archivos son muy interesantes debido a que suelen contener credenciales de acceso a servicios.
- Comandos para monitorear y administrar procesos y servicios: El usuario está utilizando comandos como «ps», «top», «netstat», «grep», «apachectl», «service» y «tail» y “history” para monitorear, administrar procesos y servicios del sistema, y observar historial de comandos.
- Conexión a un servidor remoto utilizando SSH.
- Instalación de varios paquetes usando yum, incluidos Python 2.7, Git, Apache 2.4, PHP 7.0 y MySQL 5.6.
- Uso de LiME para realizar labores de procesado sobre la memoria volátil. También se ve el uso de la herramienta Volatility y dwarfdump.
- Configuración de SSL utilizando Let’s Encrypt.
En la siguiente captura se puede observar claramente un patrón de ejecución de comandos reiterados, en este caso de “wget”.
Y en la siguiente captura un patrón con las conexiones a un servidor SSH alojado en AWS:
Y en la siguiente captura con las conexiones y configuraciones sobre el servidor MySQL, donde se puede observar que se conecta mediante el usuario “ganga”:
Para resumir sobre lo anterior, y obviando las marcas temporales de ejecución de los comandos, se observa un patrón en la ejecución de comandos que puede indicar que haya un script que automatice dicha ejecución a través de un crontab. De los comandos ejecutados se deduce que parece ser que el usuario estaba trabajando en la configuración de un servidor web Apache con una versión Drupal 7.57, incluyendo la configuración de SSL. Posteriormente a la instalación de dichos paquetes, procedía a su eliminación, posiblemente con la intención de borrar huellas.
Además, parece que el usuario estaba llevando a cabo operaciones de monitorización de eventos que sucedían en el sistema, así como el estudio de su historial de comandos. De la misma manera, el usuario realizaba backups de la memoria RAM del sistema a través de herramientas como Volatility, LiME y dwarfdump, y realizaba conexiones externas a un servidor SSH del que descarga archivos mediante el uso de “wget”, y a un servidor MySQL en el que ejecuta comandos internos.
Desde luego que toda esta descripción de eventos conforma un comportamiento bastante sopechoso.
e) Se debe emplear «BulkExtractor» para extraer datos de la memoria y poder analizar el tráfico de red desde las direcciones IP identificadas. Así se observarán posibles comportamientos sospechosos. Se explicará la vulnerabilidad que se ha explotado, encontrando así la brecha de seguridad por donde el atacante ingresó al sistema víctima.
- A continuación, se muestra captura de la ejecución del comando específico para la obtención de evidencias procesadas sobre la imagen “memoria.bin”.
Los datos extraídos se pueden observar en la siguiente captura.
- De todo lo anterior, se han identificado las siguientes direcciones IP que se detallan a continuación, junto con su reputación según Virustotal. Se ha marcado en rojo los datos más interesantes, donde se muestra información de que posiblemente pertenezcan o haya estado involucradas en actividades relacionadas con el cibercrimen. Hay que tener en cuenta que el ciberataque que se está analizando en esta práctica tuvo lugar en 2018 según el estudio de los registros, y los datos proporcionados por virustotal datan de años posteriores.
- Dirección IP 172.31.44.165:
https://www.virustotal.com/gui/ip-address/172.31.44.165/relations
-
- Dirección IP 88.0.112.115:
https://www.virustotal.com/gui/ip-address/88.0.112.115/relations
-
- Dirección IP 23.226.128.37:
https://www.virustotal.com/gui/ip-address/23.226.128.37/relations
-
- Dirección IP 83.247.136.74:
https://www.virustotal.com/gui/ip-address/83.247.136.74/relations
- Teniendo las direcciones IP ya identificadas a corde a su reputación, procedemos a estudiar el tráfico de red obtenido a través de la herramienta bulkextractor. Para ello vamos a proceder a analizar los siguientes archivos.
Primeramente vamos a estudiar con Wireshark el archivo pcap. Únicamente se expondrán los resultados de especial relevancia dada la extensión de información que arroja dicho archivo.
-
- En la siguiente captura de Wireshark podemos observar que la conexión establecida por la IP 88.0.112.115 mediante el puerto 80 transmite la información en texto plano. Así pues, se puede observar lo que parece ser una lista de comandos ejecutados en la máquina víctima, según podemos correlacionar con los logs de comandos estudiados en el apartado anterior (2.4).
También se puede observar información relativa a una base de datos. Esto puede llevarnos a la conclusión de que la brecha de seguridad haya podido tener su origen en la explotación de un servicio que corra bajo puerto 80 (un servidor web), y a través del cual el atacante haya podido llevar a cabo ejecución de comandos remotos (RCE), teniendo acceso incluso a la BBDD de la víctima. De momento nos queda la duda de si ha podido ser un ataque de SQLi o un ataque relativo a la WebAPP bajo un servidor apache.
-
- En la siguiente captura de Wireshark podemos observar que la conexión establecida por la IP 83.247.136.74 mediante SSH transmite la información encriptada por dicho protocolo, por lo que no se puede observar las acciones llevadas a cabo a través de él.
-
- En la siguiente captura de Wireshark podemos observar que la conexión establecida por la IP 172.31.36.177 al puerto 3306 correspondiente al servicio de MySQL de la víctima, transmite información en texto claro contenida en la BBDD. Los datos que aparecen son relativos a direcciones de email, órdenes de compras y relacionados con datos de pago.
- Para llevar a cabo el estudio del log de apache sobre las conexiones, he procesado manualmente el log proporcionado por bulkextractor, ya que bajo el mismo archivo se guardaban registros de distintos servicios, pues presentaban diferentes formatos. Así pues, el log queda procesado de la siguiente manera, donde se han descartado aquellas conexiones irrelevantes para la resolución del ejercicio.
En la siguiente capura se puede observar el momento en el que el atacante procedente de la dirección IP 88.0.112.115 procede a realizar escaneos sobre el servicio HTTP de la máquina víctima con la finalidad de encontrar y explotar vulnerabilidades en Drupal.
En la siguiente captura procedente del exlploit que aprovecha la vulnerabilidad de “Drupal v. 7.x” podemos observar cómo se encuentra en el log la cadena de caracteres señalada en rojo. Con estos datos ya sabemos cuál ha sido la brecha de seguridad y desde qué dirección IP ha sido explotada.
El resto de conexiones estudiadas no presentan mayor importancia.
- Para dar respuesta a la última cuestión de este ejercicio, explicaré brevemente en qué consiste la vulnerabilidad de Drupal explotada y la forma que tiene de actuar dicha vulnerabilidad.
La vulnerabilidad que presenta Drupal en su versión 7.57, que es la que estaba instalada en el servidor de la víctima, presenta una serie de vulnerabilidades que han sido descubiertas y explotadas en el pasado. La vulnerabilidad en cuestión que afecta a esta versión de Drupal, es la llamada «Drupalgeddon2» (CVE-2018-7600).
https://www.exploit-db.com/exploits/44449
Se trata de una vulnerabilidad crítica descubierta en el sistema de gestión de contenidos (CMS) Drupal. La vulnerabilidad, identificada como CVE-2018-7600, afecta a varias versiones de Drupal (6, 7 y 8) y permite a un atacante ejecutar código arbitrario en el servidor de forma remota (RCE) sin necesidad de autenticación (PRE-AUTH).
La explotación de esta vulnerabilidad se realiza mediante una petición HTTP especialmente diseñada que se envía al servidor Drupal. La vulnerabilidad es causada por un error en la sanitización de los parámetros de entrada en ciertas solicitudes HTTP, lo que permite a un atacante inyectar código malicioso a través de parámetros específicos en la solicitud (request).
Un atacante puede aprovechar esta vulnerabilidad para tomar el control del sitio web y ejecutar diversas acciones maliciosas, como:
-
- Ejecutar comandos en el servidor víctima y moverse lateralmente en la red (movimientos horizontales pivotando y movimientos verticales mediante escalada de privilegios).
- Acceder a información confidencial almacenada en la base de datos.
- Instalar malware, como puertas traseras o ransomware, en el servidor.
- O incluso utilizar el servidor víctima como parte de una botnet para lanzar ciberataques a otros sistemas informáticos.
Para llevar a cabo sus acciones crea distintos archivos PHP con código maligno en el disco de la máquina víctima, que se ejecutan del lado del servidor, y de los que se sirve para ejecutar comandos remotos.
Como hemos podido observar tras el análisis forense realizado en esta práctica, la explotación exitosa de Drupalgeddon2 puede tener consecuencias graves para la seguridad y la privacidad, tanto de los propietarios de sitios web como de sus visitantes. Huelga decir que para protegerse contra esta vulnerabilidad, se recomienda a los administradores que actualicen a las versiones más recientes y apliquen los parches de seguridad correspondientes en todos sus módulos. También sería conveniente que los administradores del sistema realizaran un bastionado correcto del mismo, mediante una configuración basada en la seguridad como principio fundamental, en la que garantizaran los permisos justos a cada usuario sin que estos pudieran ejecutar comandos o modificar archivos que no son de su competencia o interés.
f) Se deben identificar y extraer evidencias de la explotación de la vulnerabilidad anteriormente detallada, y analizarlas con Virustotal u otras herramientas en línea (any.run, etc.).
Para dar solución a este ejercicio vamos a estructurarlo en:
- Obtención de evidencias a través de paquetes de red (pcap).
- Obtención de evidencias a través de Volatility.
- Obtención de evidencias a través de strings del binario proporcionado (memoria.bin).
f.1) Obtención de evidencias a través del análisis del archive Pcap.
Sobre las evidencias que se pueden extraer del archivo “pcap” desde el que hemos analizado las conexiones anteriormente, Virustotal no indica ningún peligro.
Obtiene con todos los objetos extraídos el mismo resultado:
No obstante, cabe destacar que algunos de los archivos parecen haber sido encriptados con algún tipo de cifrado, es decir, que posiblemente sean archivos malignos pero al haber sido encriptados han podido evadir los distintos sistemas AV y sistemas perimetrales de seguridad.
f.2) Obtención de evidencias a través de Volatility.
A continuación, vamos a extraer archivos empleando volatility. Al tratarse de archivos empleados en la explotación de un Sistema Operativo Linux, no correremos ningún riesgo al realizar la extracción en disco bajo nuestro Sistema Operativo Windows, aunque habrá que tener en cuenta que posiblemente haya archivos PHP u otros, que el antivirus los elimine alegando que son malignos, aunque no puedan ser ejecutados en el sistema sin las condiciones de un escenario adecuado (bajo servidor apache, con PHP habilitado, etc.).
Para realizar el volcado del contenido de un proceso en nuestro disco, emplearemos el plugin “Linux_procdump” de volatility. Posteriormente, subiremos el binario resultante del volcado a Virustotal para ver qué resultados nos arroja sobre su reputación.
Con los plugins “linux_pstree”, “Linux_pslist” y “linux_threads” podemos obtener los procesos que estaban corriendo en el sistema víctima víctima, como se muestra en las siguientes capturas.
Llegados a este punto, ya podemos realizar el volcado en disco de todos los procesos más relevantes y proceder a analizarlos con Virustotal. De la captura anterior se deduce que el proceso más interesante a volcar es el “sh” (proceso hijo) con PID 11383 que cuelga del proceso “httpd” (proceso padre) con PID 1003. También parecen ser interesantes los procesos “bash” que cuelgan del proceso “sshd”.
Primeramente habíamos optado por ir volcando proceso a proceso, como se muestra en la siguiente captura, pero posteriormente hemos optado por realizar el volcado de todos los procesos y analizarlos uno a uno con Virustotal porque es bien sabido que muchos atacantes ponen nombres falsos a su malware con la intención de enmascarlo entre los procesos.
A continuación se muestra la captura de la obtención en disco del volcado de todos y cada uno de los procesos.
Tras subir todos los volcados a Virustotal, hemos descartado gran cantidad de ellos porque no arrojaban ninguna información de interés, quedándonos con los siguientes:
A continuación, se detallan los resultados aportados por Virustotal.
- El archivo resultante del volcado del proceso “sh” con PID 11383 que cuelga del proceso padre “httpd”, no hace saltar ninguna alarma en Virustotal. No obstante, dada la importancia que creo que tiene porque apunta a que la intrusión ha sido realizada desde él, hemos procedido a hacer una análisis de código estático con IDA y hemos podido observar algunas funciones de interés, como la llamada a ejecución de archivos binarios, o como otras funciones que llaman a procesar archivos internos del sistema como “.bash_prifle” o “.bash_login”, a los que un servicio web (httpd) no debería poder tener acceso.
- Aquellos archivos con 0kb, la herramienta nos reporta el siguiente resultado. Se entiende que se trata de un falso positivo de Virustotal, ya que no tiene lógica alguna que un archivo sin contenido pueda ser una amenaza en sí misma, sino posiblemente un “trigger” que mediante un nombre determinado de archivo haya otro proceso monitorizándolo a la espera de poder desatar acciones maliciosas. Estos archivos presentan todos el mismo hash de integridad, dado que los tres están vacíos, y en la captura anterior son los que han sido renombrados con el sufijo “_VIRUS”.
- Aquellos archivos que presentan el sufijo “_MITRE” se han catalogado así debido a que según Virustotal realizan algunas TTPs de MITRE, como podemos ver en la siguiente captura.
- Los archivos con el sufijo “_EXEC A FILE” se han catalogado así debido a que según informe de Tencent HABO, aportado por Virustotal, realizan la ejecución de un binario situado en “/tmp/bin/*.elf”, como podemos ver en la siguiente captura.
- Archivo “bash.11160.0x400000_EXEC A FILE”.
-
- Archivo “bash.11387.0x400000_EXEC A FILE”.
-
- Archivo “bash.11419.0x400000_EXEC A FILE”.
-
- Archivo “amazon-ssm-agen.2251.0x400000_EXEC A FILE”.
f.3) Obtención de evidencias a través de strings del binario “memoria.bin”.
Llegados a este punto, y conociendo que el funcionamiento del exploit, sabemos que para llevar a cabo la intrusión en el sistema víctima, el exploit inyecta payloads encargados de introducir código PHP en la máquina víctima. Esto lo realiza a través de las peticiones web que hemos podido observar en los resultados de Bulkextractor y que se muestran a continuación.
Así pues, vamos a realizar un estudio de las “strings” del binario “memoria.bin” buscando los nombres de los anteriores archivos PHP para ver qué resultados nos arroja la herramienta.
Como hemos visto en las capturas anteriores hemos podido extraer ambos archivos codificados en base64. A continuación procedemos a decodificarlos y a analizarlos con Virustotal.
- Archivo “VMg9u9DERxX28qM3axlrTvxqypuykNelCe0zYKItr.php”.
- Archivo “he8XB6cBspl9VudB9nNZZqLSveaVbNte.php”.
- Ahora, si decodificamos la string que inyectan los archivos PHP, vemos que se trata de un archivo ELF, es decir, un archivo binario ejecutable para sistemas Linux. Guardamos el resultado de la decodificación en un archivo y lo analizamos con Virustotal.
Si analizamos dicho archivo con Virustotal nos devuelve los siguientes resultados.
Vemos también que YARA tiene la firma del archivo malicioso en su BBDD, por lo que sacamos la conclusión (como crítica constructiva) de que en caso de haber integrado YARA con Volatility podríamos haber obtenido estos resultados con anterioridad.
Damos por finalizado este ejercicio habiendo sido capaces de obtener 3 archivos catalogados por Virustotal como maliciosos, evidenciando de esta manera la explotación de la vulnerabilidad explotada, como bien se solicita en el enunciado.
Si quieres ser un profesional en peritaje forense digital puedes adquirir nuestros siguientes cursos: