Threat Hunting: Probability based model for TTP covering (Parte I)

Las tareas de Threat Hunting como búsqueda de lo desconocido ha abierto la puerta a un sinfín de interpretaciones y metodologías de análisis proactivo, además de formular múltiples preguntas sobre cómo organizar la búsqueda y poder medir el tipo de servicio que se ofrece.

La investigación, que se presentará en tres partes, tiene como objetivo analizar las tareas de la revisión proactiva con el fin de establecer un modelo de desarrollo de Unidades de Inteligencia en función de la cobertura de las técnicas descritas en la matriz de MITRE ATT&CK, así como un modelo matemático para la planificación de las tareas de Threat Hunting basado en la probabilidad de detección para la eficiencia de las horas de analista. Puede leerse el estudio al completo aquí.

La Unidad de Inteligencia en Threat Hunting

En la seguridad gestionada convencional el objetivo es la detección de amenazas de manera automática. Es decir, la detección del mayor número de amenazas con la menor tasa de falsos positivos. En este caso, idealmente, el valor de la inteligencia es siempre incremental, es decir; existe una relación directamente proporcional entre el número de reglas (correctamente calibradas) y la calidad del servicio, pues cuanto mayor número de reglas se dispongan, mayor número de amenazas será posible detectar. Es decir, la regla tiene que identificar de manera inequívoca un patrón malicioso. No es así para el Threat Hunting.

[Read more…]

R2wars, una competición diferente

(Esta entrada ha sido elaborada por Erik Martínez y Vicente Lahoz)

INTRODUCCIÓN

La semana pasada asistimos a la r2con, una conferencia con una comunidad muy comprometida, centrada en el análisis de malware, ingeniería inversa, explotación de binarios y mucho más. La conferencia está organizada por los desarrolladores de la herramienta radare2, un framework de reversing de código abierto muy potente que ofrece multitud de posibilidades, como el ensamblado y desensamblado de archivos, debugging de ejecutables o explotación de software.

Todo esto ejecutado desde la línea de comandos (también tiene una GUI llamada Cutter), así que puedes automatizar tareas y gestionar las salidas del terminal como desees. También tiene una API disponible para la mayoría de lenguajes de programación llamada r2pipe, por lo que puedes integrarla en tus propios scripts y herramientas de una forma muy sencilla. ¡Bastante chulo!

La r2con se compone de charlas, talleres y competiciones (entre varias pausas para café) [Véase github.com/radareorg/r2con2019]. En este post, vamos a contar nuestra experiencia en r2wars, una de las competiciones que se celebran durante la conferencia.

[Read more…]

La importancia del bastionado de servidores – Parte 3. El incidente

Hoy publicamos el tercero, y último, de los artículos cortesía de Jorge García sobre la importancia del bastionado de servidores. Aquí tenéis todos los artículos de la serie [1] [2] [3]

Con la tienda ya publicada y en servicio, llega el momento de poner en práctica todas las cosas que hemos mencionado arriba: mantener una correcta vigilancia, mantener la aplicación y sistemas actualizados, etc.

Personalmente reviso casi todas las mañanas las alertas de Suricata de todos los servicios que tengo publicados. Filtro aquellas que no considero relevantes y me centro en las que sí que lo son. Normalmente se tratan de intentos de intrusión que han sido bloqueados o intentos de explotar una tecnología que no está desplegada en el servidor. Esto ocurre a menudo cuando, por ejemplo, se publica una vulnerabilidad de WordPress y los atacantes intentan explotarla en cualquier CMS accesible desde Internet, aunque no disponga de la versión vulnerable o ni siquiera sea del mismo fabricante del que se haya publicado la vulnerabilidad. [Read more…]

La importancia del bastionado de servidores – Parte 2. Bastionando el servidor

Hoy publicamos el segundo de tres artículos cortesía de Jorge García sobre la importancia del bastionado de servidores. Aquí tenéis todos los artículos de la serie [1] [2] [3]

De acuerdo, tenemos la misión de hospedar una aplicación web de comercio online y ofrecerla al mundo en un servidor que tenemos en propiedad. Nuestro objetivo es que sea lo más inexpugnable posible a todos los niveles. Dado que se trata de una aplicación web, es previsible que el principal vector de entrada de ataques sea a través de vulnerabilidades de la propia aplicación. A ver, no nos engañemos, todos los CMS son firmes candidatos a tener vulnerabilidades severas. El esquema de cómo estará organizada la plataforma es el habitual en un servidor virtual:

Por lo tanto, la cuestión es elegir un CMS con estas premisas:

  1. Que se desarrolle activamente y esté respaldado por una comunidad numerosa de desarrolladores o por una gran empresa. Esto nos garantiza que cuando se publique una vulnerabilidad, ésta sea rápidamente corregida.
  2. Que el CMS instalado sea la última versión disponible de una rama que tenga soporte, y que se prevea que siga teniéndolo durante bastante tiempo. No hay que olvidar que, dado que no disponemos de entorno de desarrollo en casa, las actualizaciones o migraciones implican pérdida de servicio que a su vez implica potencial pérdida de dinero.
  3. Que sea compatible con el sistema operativo del servidor que disponemos. Una consideración que es obvia pero importante.
  4. Que el historial de vulnerabilidades críticas sea lo más bajo posible. Un CMS que se desarrolla activamente y tiene buen soporte pero que de media se descubre una vulnerabilidad crítica cada semana no es viable de mantener ni seguro de utilizar.

[Read more…]

La importancia del bastionado de servidores – Parte 1. Introducción y tipos de infraestructura

Hoy publicamos el primero de tres artículos cortesía de Jorge García sobre la importancia del bastionado de servidores. Jorge se presenta de la siguiente forma: “Aunque oficialmente soy administrador de sistemas y responsable de seguridad en la empresa donde trabajo, lo cierto es que mi trabajo también es mi hobby. Soy un gran aficionado a la informática geek, a la seguridad defensiva, a desplegarme mis propios servidores y a todo proceso DIY (‘do it yourself’) que me plantee nuevos retos de aprendizaje mientras me busco la vida para solucionar los problemas. La evolución es mi pasión.

Todas las empresas, sin importar el ámbito en el que se desarrollan, disponen en mayor o menor medida de una infraestructura informática de servidores que almacenan y procesan información corporativa de vital importancia para el negocio. La duda que siempre me asalta es: si tan importante es esta información, ¿por qué la experiencia nos dice que es tan frecuente que las empresas no mantengan sus servidores, aplicaciones y equipos actualizados y debidamente bastionados?

Bien es sabido que una gran parte de las empresas no toman en serio la seguridad informática. Sin ir más lejos este informe publicado hace tres meses indica que 7 de las 10 vulnerabilidades más explotadas durante 2018 tenían entre 1 y 6 años de antigüedad; o este otro informe que indica que una gran cantidad de empresas no parchean sus sistemas de forma rápida. Esto es debido a que, las empresas piensan que no son objetivo escudándose en el el típico pensamiento de “mi empresa es pequeña y no tiene nada atractivo para los hackers”, o bien porque no tienen o no consideran necesario disponer de recursos de personal y herramientas para mantener la plataforma actualizada. O al menos no lo hacen hasta que ya es demasiado tarde, y de eso mismo voy a hablaros en el post de hoy. It’s a true story. Vamos con un poco de background. [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…]