Search Results for: CTF

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

• https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx
• https://www.dfir.training/resources/downloads/windows-registry
• https://www.forwarddefense.com/pdfs/Event_Log_Analyst_Reference.pdf
• https://github.com/nsacyber/Event-Forwarding-Guidance/tree/master/Events

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…]