Search Results for: CTF

DEFCON DFIR CTF 2019 (IV): Triage VM Questions

Las evidencias son un precioso fichero .7z (que en Debian no se puede abrir con unzip, hay que usar p7zip, ojo), que una vez descomprimido nos deja los siguientes ficheros:


# ls -laht
total 27G
drwxr-xr-x 2 root root 4.0K Aug 27 18:10 .
drwxr-xr-x 5 root root 4.0K Aug 27 17:43 ..
-rw-r--r-- 1 root root 4.0G Mar 22 22:21 DFA_CTF_Triage-0.vmdk
-rw-r--r-- 1 root root  23G Mar 22 22:21 DFA_CTF_Triage.vmdk
-rw-r--r-- 1 root root 2.0K Mar 22 22:14 DFA_CTF_Triage.vmx

Podríamos arrancar la máquina virtual en VMWare, pero vamos a tratar la VM como una evidencia muerta, para ver si somos capaces de sacar todas las evidencias de un modo más formal.

La forma más rápida de montar en Debian un .vmdk es, si tienes qemu instalado, la siguiente: [Read more…]

DEFCON DFIR CTF 2019 Writeup (III): Memory Forensics

1. ¿Cuál es el hash SHA1 del fichero triage.mem?

Un poquito de sha1sum para empezar a calentar…

# sha1sum adam.mem
c95e8cc8c946f95a109ea8e47a6800de10a27abd  adam.mem

* Respuesta: c95e8cc8c946f95a109ea8e47a6800de10a27abd

2. ¿Qué perfil de memoria es el más apropiado para esta máquina (ej: Win10x86_14393)

Volatility nos da la información gracias al plugin imageinfo: [Read more…]

DEFCON DFIR CTF 2019 writeup (II): Linux Forensics

Como habíamos visto en la parte de Windows, la adquisición forense del equipo Horcrux nos había dejado una tabla de particiones cargadita, siendo una de ellas una de Linux. Siendo Linux, parece tener sentido el realizar el forense desde otro Linux.

En primer lugar vamos a montar la partición como es debido para poder ver lo que tenemos dentro (si estáis en un sistema Linux necesitaréis las ewftools, y aquí [https://www.andreafortuna.org/2018/04/11/how-to-mount-an-ewf-image-file-e01-on-linux/] tenéis un tutorial estupendo sobre cómo hacerlo):

Montamos el contenedor: [Read more…]

DEFCON DFIR CTF 2019 writeup (I): Crypto + Deadbox Forensics

Como ya parece ser una (estupenda) tradición dentro de la DEFCON, se ha vuelto a lanzar un reto forense no oficial. Este año se lanzó el día en el que me iba de vacaciones, así que llegamos con retraso para resolverlo, pero llegamos.

Lo primero son los datos con los que tenemos que trabajar. Las evidencias están disponibles en este enlace de Dropbox:

https://www.dropbox.com/sh/4qfk1miauqbvqst/AAAVCI1G8Sc8xMoqK_TtmSbia?dl=0

y aquí tenéis el enlace al sitio web del CTF:

https://defcon2019.ctfd.io/

El reto es más largo que un día sin pan (83 preguntas si he hecho bien las cuentas), así que para no volverme loco me he puesto un límite temporal: tengo una semana para dedicarle al reto, writeup incluido. El domingo 25 ya descargué todas las evidencias y dejé todo listo para empezar, así que el lunes 26 empezamos con ganas. [Read more…]

UCAM CTF Forense — Like old school II

En mi post anterior se hablaba de procesos básicos de cualquier análisis forense como son la recolección de información, preanálisis de sesiones de usuario/sistema y de credenciales LSASS. En este post voy a proporcionar una visión muy general de procesos y tácticas del adversario empleadas en las comunicaciones, para ganar persistencia, vectores de entrada y descuidos humanos.

Comunicaciones > USB

Los USB conectados al equipo de Lionel son fácilmente rastreables, tanto de forma manual como con herramientas de “botón gordo“. Veremos ambas formas, para entender mejor cómo se realizaba cuando no existían estas commodities.

Forma manual: En el fichero de eventos ‘System.evtx’ cazamos el EventID 20001 producido a las 19.04.09 23:29:57 (UTC) que nos indica que se ha instalado un nuevo driver; en este caso se observa que se trata de una memoria flash de la marca Kingston, modelo DT101 G2.

Forma automática: Importando el fichero del registro SYSTEM en la herramienta USBDeview de Nirsoft con ‘Options > Advanced Options > Load From: External SYSTEM Registy File, SYSTEM Registry File: {ruta del fichero SYSTEM}’ podemos observar de forma instantánea que se han obtenido las trazas que justifican que se ha introducido un Kingston DT101 G2.

Por dar otra alternativa, en la parte inferior de la imagen anterior vemos la GUI de USB Detective que, pese a ser una herramienta freemium, su versión Community nos muestra de forma elegante resultados muy similares a USBDeview. El USB en cuestión tendría la forma y color de uno de los siguientes. No he sido capaz de identificar su tamaño.

Comunicaciones > Ethernet

Observamos que hay una instalación de XAMPP que contiene en la ruta ‘\xampp\htdocs’ los ficheros de la web bufetehutz[.]com. XAMPP es un entorno multiplataforma de desarrollo web en PHP que contiene los componentes Apache, MariaDB, PHP y Perl. Recordemos que XAMPP está pensada para usarse en contextos educativos y de desarrollo, por lo que se desaconseja su uso en sistemas en producción. Además, tiene grandes carencias de seguridad por defecto, por ejemplo, la cuenta de administrador de MySQL (root) no tiene contraseña, y el demonio MySQL así como PhpMyAdmin y la página demo de XAMPP (carpeta dashboard) son accesibles por red.

Analizando su contenido, llama la atención el directorio ‘\testsite’ en el que existe una instalación de WordPress en local que es el CMS (Content Management System) más popular del mercado, y el que está corriendo la web de Lionel.

En el fichero wp-config.php tenemos la configuración del servidor MySQL del que está tirando la web. De él, podemos extraer las claves de conexión, prefijos de las tablas de la base de datos y varias variables de WordPress.

En este caso, se están empleando los valores por defecto (root:<blanco>) para conectarse a una MySQL alojada en el mismo equipo. Vista la seguridad muy cuestionable de la web es posible que el atacante hubiera accedido aprovechando varias de sus vulnerabilidades.

Analizando el fichero ‘\xampp\apache\logs\access.log’ y filtrando los accesos que se producen desde localhost (que eran varios cientos), se reducen a 43 las peticiones de recursos, desde las IPs locales 192.168.1.153 (17), 192.168.1.106 (3) y 192.168.1.42 (23), siendo la última IP la que más peticiones realiza al servidor web y también, concretamente, a la web del bufete.

Vamos a seguir un paso más a ver si somos capaces de acceder al panel de gestión de WordPress sabiendo que Lionel y las contraseñas robustas no son buenos amigos. En la ruta ‘\xampp\mysql\data\wordpress’ se encuentra el fichero wp_users.idb que junto a otros, conforman la base de datos MySQL con sus metadatos y datos. Si nos fijamos en su contenido, identificamos lo que parece el hash de la contraseña del usuario admin.

Es decir ‘admin:$P$BI9SyUjvR/RfnoKXRkXlOlmhP.bSBZ.’ solo hace falta crackearlo para obtenerla en plano, por ejemplo usando John, que nos devuelve a los pocos segundos admin1234.

Persistencia

La persistencia, AKA “capacidad de sobrevivir a un reinicio”, es una condición de victoria para cualquier atacante. La pueden conseguir de muchas formas y lugares del sistema operativo. Con diferencia la ubicación más frecuente sabemos que son los valores Run/RunOnce del registro de Windows, en los que se puede almacenar rutas de ficheros, comandos y scripts que se cargan en la fase de startup del equipo o sesión de usuario.

En el espacio de usuario que se carga de forma específica para cada usuario (Lionel, Secretaria, Jeff) tenemos varias rutas:

En el espacio del sistema que guarda la configuración específica del equipo y se carga para cualquier usuario que inicie sesión, también tenemos unas cuantas más:

Rebuscando de forma manual por ellas (una alternativa de botón gordo sería RegRipper), detectamos que para el espacio de usuario de Jeff se ha creado el valor “Iniciar” que contiene como dato la ruta de un archivo batch ‘C:\Windows\jeffi\backup.bat’.

Este fichero alojado en la carpeta ‘C:\Windows\jeffi\’ establece una shell reversa estableciendo una conexión netcat al puerto 6666 (dos archiconocidos por manejar en muchas ocasiones tráfico ilegítimo) hacia la IP 80.98.23.34 geolocalizada en Debrecen, Hajdú-Bihar (Hungría). Como no des explicaciones convincentes, individuo Jeff, estás en el punto de mira.

Si nos fijamos en el contenido de la carpeta, contiene una serie de ficheros en C y ejecutables que buscando por Internet apuntan a repositorios con una versión adaptada de netcat para Windows (ejemplo de fork aquí). Entre estos ficheros hay varios que no aparecen en netcat. Son ‘backup.bat’, ‘jijijiji.txt’ y un par más que están vacíos.

Si vemos el contenido de ‘jijijiji.txt’ tenemos el comando reg add, una instrucción de adición del valor “Iniciar” en una clave del registro de Windows, que coincide con la encontrada previamente, lo cual implica que con alta probabilidad se ha ejecutado en el equipo.

Hasta ahora hemos identificado la técnica de persistencia usada y un posible culpable, pero desconocemos el vector de entrada. No se encuentran antecedentes en Internet que vinculen la IP a actos malintencionados, por lo que se recomienda ponerla en cuarentena/blacklist y denunciarla a los FCSE competentes.

Vector de entrada

En la raíz del árbol de directorios del disco encontramos la carpeta ‘C:\Casos Bufete\’ que contiene subcarpetas de juicios con imágenes y correos de sus implicados. Tenemos que tener muy claro que, como peritos, tenemos la obligación de la confidencialidad para/con nuestros clientes. Por tanto, mientras esté justificado el motivo o necesidad, estaremos interfiriendo en la intimidad de los usuarios de los equipos que auditemos.

Si nos fijamos en la ruta ‘C:\Casos Bufete\Netflix vs Jeff Albertson\Operaciones cuentas.eml’ tenemos un .eml correspondiente a un email enviado a la dirección de correo corporativo de Lionel (lionel[at]bufetehutz[.]com) con fecha 19.04.08 17:38:04.

Su cabecera SPF (Sender Policy Framework) muestra una discrepancia entre los servidores de correo legítimos en origen y el empleado en este correo. El mecanismo SPF no valida el campo visible “From” de la cabecera, para ello está el mecanismo DMARC.

Sin entrar en detalles, lo que valida son varias de las cabeceras ocultas que se transmiten junto al correo.

Esto ya empieza a oler más fuerte. Si nos fijamos, la IP empleada como origen es la misma con la que se estaba ganando persistencia, 80.98.23.34.

Si nos fijamos en el cuerpo del email, se puede apreciar que hay faltas de ortografía (segundo indicativo de que el origen puede ser malicioso). Además está situada muy cerca de un enlace, aparentemente generado con algún tipo de DGA (Domain Generating Algorithm) en origen, que ni de lejos corresponde con la empresa BBVA. Por tanto, aumentan mucho las probabilidades de que sea malicioso. Como podemos leer a continuación, Jeff vuelve a estar por en medio, realizando una transferencia bancaria falsa de 661,20 EUR a una cuenta del bufete de abogados.

Desconocemos qué contenido se descargaba del dominio hxxp://3234djkkwqewq[.]com porque está caído (y entre tu y yo… nunca ha existido el dominio, la magia de los CTFs). Supondremos que el cliente de correo era el punto de infección del que se descargaba un maldoc que posteriormente se ejecutaba.

Analizamos los IOCs que tenemos: la IP 80.98.23.34, un dominio hxxp://3234djkkwqewq[.]com y email notificaciones-bbva[at]fake[.]com. Al igual que hemos hecho anteriormente y respetando el alcance del análisis, se recomienda ponerlos en cuarentena/blacklist y denunciarlo a los FCSE competentes.

Emails sobre corrupción y ladrones

Rebuscando más en la misma carpeta, encontramos otro .eml en la ruta ‘\Casos Bufete\Netflix vs Jeff Albertson\Operaciones cuentas.eml’ que contiene otro email enviado a Lionel (lionel[at]bufetehutz[.]com), donde un tal Snake realiza varias afirmaciones, que en resumen son:

  • Lionel, Snake y Fat el gordo tienen como objetivo atacar la imagen pública de Mayor Joe sacándole fotos comprometidas para acabar con su carrera política.
  • Para poder sacar esas fotos a Mayor Joe sin que se entere, simulan el robo del prototipo del profesor Flink en el despacho de Lionel, que lo permite.
  • Como respuesta, Mayor Joe contrata a Jeff para borrar todas las pruebas incriminatorias del despacho de Lionel.

Las fotos comprometedoras de Mayor Joe que Jeff no ha borrado están en la ruta ‘\Casos Bufete\Caso corrupción Mayor Joe y tesorero’.

Timestomping

Somos muy insistentes y seguimos analizando detalles en la carpeta de los juicios. Esta vez nos llama la atención la imagen ‘\Casos Bufete\Plagio del profesor Frink\top secret Frink.jpg’ que tiene una fecha de creación y última modificación de 2029.04.10; ya, sí, claro, … Claramente tiene los timestamps MACB modificados (técnica timestomping).

Tras un buen rato buscando, curiosamente, resulta que en la carpeta en la que se encuentra el software instalado, ‘\Program Files (x86)’ se encuentra también la herramienta SetFileDate de No Nonsense Software, cuyo objetivo es alterar tiempos y fechas de ficheros y carpetas. Tenemos premio. No nos aporta nada pero insisto en que es interesante saber las técnicas empleadas por el atacante.

Ahora creo que ya sí podemos concluir que, según los emails analizados al final y las pruebas recabadas con anterioridad, todo apunta a que Jeff es el principal sospechoso de haber cometido la exfiltración de datos del bufete de abogados de Lionel en un intento fallido por borrar los datos del Mayor Joe. Los detalles ya los hemos ido desgranando progresivamente.

Conclusiones

Hasta aquí el trabajo que nos ha pedido la compa del SOC. Unas horas bien invertidas en las que:

  1. hemos repasado acciones muy frecuentes durante un análisis forense
  2. hemos lanzado muchas ideas al aire
  3. hemos analizado alternativas (que valoro mucho) de resolución de cada paso que hemos dado, marcándonos una progresión a través de pequeños hitos.

Este análisis ha sido posible gracias al reto organizado por el Master en Informatica Forense y Peritaje Informático Judicial del Campus Internacional de Ciberseguridad. Desde aquí les mando un saludo. Agradecerle también a Antonio Sanz por el cable de 500XP que me ha echado para complementar y perfilar cada uno de los puntos que he tocado. Ya puedo decir que no es mi primer ni último post en SAW :)

Recursos destacados

UCAM CTF Forense — Like old school

Hoy, como aficionado al análisis forense digital (la parte puramente IT, sin entrar demasiado en lo legal), analizaré de forma didáctica el caso ficticio “Lionel Hutz papers” planteado en UCAM CTF, incidiendo en los procesos de resolución empleados y las conclusiones sobre la naturaleza del ataque. Espero que os parezca interesante.

En primer lugar, dos handicaps autoimpuestos:

  1. A diferencia de un ejercicio de IR (respuesta rápida ante incidentes), la evidencia la trataré siempre en frío.
  2. Por tanto, se usará exclusivamente el disco, like old school (que da nombre al post), sin tocar la RAM y mucho menos levantar la VM aislada para monitorizar su actividad.

En segundo lugar, al ser un ejercicio enmarcado en el formato CTF, responderemos de forma indirecta a cuestiones que bien pueden ser interesantes, o bien podrían ser irrelevantes o no concluyentes durante la elaboración de las conclusiones y por tanto en según que casos reales no se habría ni siquiera planteado. Dicho esto, ¡vamos al lío! [Read more…]

MUS CTF DFIR – Desktop (Nivel 4)

1. ¿Cuál es el hash SHA1 de la imagen forense del puesto de escritorio?

Si la captura forense no tiene hashes, no es una captura forense. Revisamos el fichero MUS-CTF-19-DESKTOP-001.E01.txt y encontramos en un periquete el hash:

[Computed Hashes]
MD5 checksum: c0d0eaf2c981cd247bf600b46e6487c3
SHA1 checksum: a20c2f43a80ddcad35b958b701a6cdd4b67e535c

* Respuesta: a20c2f43a80ddcad35b958b701a6cdd4b67e535c

2. ¿Quién adquirió la imagen forense del puesto de escritorio?

El mismo fichero de logs de la adquisición forense del apartado anterior nos da la respuesta.

Examiner: Powers

* Respuesta: M Powers
[Read more…]

MUS CTF DFIR – Activity (Nivel 3)

1. ¿Cuántos ficheros fueron descargados del Sharepoint de magnet4nsics?

Esta parece fácil: cargamos con BrowsingHistoryView de Nirsoft (a este gente habría que comprarles un jamón por la maravilla de utilidades que tienen para nuestro uso y disfrute) el historial de los usuarios y lo revisamos, obteniendo un listado de los accesos a Sharepoint:

Si contamos los ficheros que parecen almacenados en el OneDrive nos salen 7 … que resulta ser un precioso Fail. Si nos fijamos un poco, solo tenemos dos descargas reales de ficheros: at-5000-s1.jpg y high4.jpg (el resto entiendo que será navegación por carpetas o algo similar).

* Respuesta: 2

¡EXTRA BONUS! Al responder esta pregunta nos aparece otra (y tiene pinta de repetirse unas cuantas veces más, así que vamos a recolocar un poco el orden de las preguntas).
[Read more…]

MUS CTF DFIR – Secret Project (Nivel 2)

En la entrada anterior habíamos encontrado un .zip altamente jugoso, así que vamos a empezar a apalearlo para que cante todas las flags de este nivel…

1. ¿Qué lenguaje ha sido empleado para crear el ejecutable del proyecto secreto?

Esta la vamos a responder con la información de la última pregunta de la parte anterior. Dentro de ese estupendo .zip podemos encontrar un ejecutable cuyo icono es bastante delator:

* Respuesta: Python

!Extra Bonus! Cuando respondemos esta pregunta se abren 5 preguntas más. Esto parece que va para largo…

[Read more…]

MUS CTF DFIR – MOBILE (Nivel 1)

Este fin de semana se pronosticaba un tiempo de perros en Madrid, y todavía estaba arrastrando un malware elegante que no terminaba de curar, así que tocaba casa y manta. Y el mismo viernes por la tarde me entero que la gente de Magnet había abierto al público el reto forense que habían jugado en el MUS (Magnet User Summit), junto con una licencia de prueba de Magnet Axiom para poder probarlo y cacharrear al gusto.

Un poco de AC/DC, leche con miel y whisky (ambos son buenos para currar el catarro, o eso dicen) y un buen reto forense no son un mal plan para el finde ;-)

Enlaces de interés:

[Read more…]