DEFCON 2018 DFIR CTF – Reto forense (Nivel 2)

7 de enero de 2019 Por
DEFCON 2018 DFIR CTF [1] [2] [3]

Servidor de ficheros – Nivel básico

1. ¿Cuál es el número de serie del volumen de la única partición de la imagen de disco del servidor de ficheros?

El número de serie del volumen es un valor hexadecimal que se genera cuando se crea el sistema de ficheros. La documentación de Microsoft nos dice que para sistemas de ficheros NTFS lo tenemos en la posición 0x48 del BPB (Bios Parameter Block), que es parte del sector de arranque. Este sector lo tenemos en el disco en el $boot (en el raiz del disco). Montamos el disco con FTK Imager y accedemos al valor hexadecimal:

Ahí tenemos el valor: 652496C0. [Read more…]

DEFCON 2018 DFIR CTF – Reto forense (Intro + Nivel 1)

4 de enero de 2019 Por
(N.d.E.: nos damos un respiro con los artículos sobre la Comunidad de Ciberinteligencia rusa, el GRU (volverán pronto), para adentrarnos en el reto forense que nos introduce Antonio Sanz.)

Comentaban unos alumnos del curso de análisis forense hace unas cuantas semanas la dificultad de conseguir experiencia en forense y respuesta ante incidentes, no sin parte de razón. En muchas ocasiones yo comparo, salvando las obvias distancias, el trabajo de DFIR (Digital Forensics and Incident Response) con el de un bombero: gran parte del tiempo de relajación mezclado con una pequeña parte de tiempo de intensidad y stress máximos.

Aquí estamos, sin embargo, no siendo del todo exactos: ¿qué hacen los bomberos cuando no se deslizan por el tubo y salen corriendo a salvar gente? La respuesta es muy sencilla: ENTRENAN.

En el mundo DFIR el entrenamiento es fundamental, ya que en muy pocos trabajos se está el 100% del tiempo “en harina” (hay que tener en cuenta que estar en un incidente a máxima capacidad de trabajo durante un periodo largo de tiempo cuesta, y mucho). El entrenamiento, además, permite detectar carencias y áreas de mejora, así como afianzar conceptos y aprender nuevas formas de hacer las cosas. [Read more…]

He descubierto un delito… ¿y ahora qué?

22 de junio de 2018 Por

[Nota del autor: el autor de este artículo es un técnico, no un abogado. Aunque se ha consultado con varios juristas para corroborar que no se ha dicho ninguna barbaridad legal, se recomienda encarecidamente consultar con un profesional del ámbito legal de confianza en caso necesario].

[Nota del autor 2: quiero agradecer las ideas y comentarios ofrecidas por el grupo de Telegram de Informática Forense: https://t.me/forense, cuya actividad ha propiciado e impulsado el presente artículo].

Imaginemos que María es una analista forense que está trabajando en un caso de espionaje corporativo. Mientras está analizando unos ficheros comprimidos con unos nombres extraños, descubre horrorizada que están repletos de imágenes de pornografía infantil.

Imaginemos que Pepe es un pentester que tiene como objetivo hacerse con el control de un servidor de correo, teniendo que presentar como prueba correos de media docena de altos cargos. Una vez logrado su objetivo extrae varios correos al azar de las cuentas de correo, pero comprueba con indignación que contienen información sobre el soborno a un funcionario para la concesión de una importante contratación pública.

Tanto María como Pepe han firmado un estricto acuerdo de confidencialidad con la empresa en la que trabajan, en el que se especifica claramente que “toda la información de la que tengan conocimiento durante su actividad laboral debe ser mantenida en el más estricto secreto”. [Read more…]

Caso práctico: “RATas inminentes” (III)

30 de mayo de 2018 Por
Artículos de la serie “Caso práctico: “RATas inminentes”: [1] [2] [3]
(Nota: Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.
Estos artículos forman parte de un taller de respuesta ante incidente básico. Por ello, hay cosas que se podrían hacer de una forma más eficiente y elegante… pero la idea era hacerlas de forma sencilla para que fueran fáciles de entender. Y como todo buen taller práctico, se puede seguir paso a paso: es posible descargar una máquina virtual de Remnux con todo lo necesario para el taller aquí (para VMWare) o aquí (formato .ova))

Análisis adicional

El incidente quedó prácticamente resuelto en el artículo anterior, pero nos quedan todavía algunas dudas en el tintero:

  • ¿Qué acciones ha realizado el malware en el sistema?
  • ¿Qué tipo de malware es?

Para salir de dudas ejecutamos el documento en una máquina virtual especialmente tuneada con medidas anti-anti-VM, que además tiene Noriben y Sysmon instalado. Adicionalmente capturamos el tráfico saliente con WireShark para tener una visión lo más completa posible de lo que hace el malware.
[Read more…]

Caso práctico: “RATas inminentes” (II)

29 de mayo de 2018 Por
Artículos de la serie “Caso práctico: “RATas inminentes”: [1] [2] [3]
(Nota: Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.
Estos artículos forman parte de un taller de respuesta ante incidente básico. Por ello, hay cosas que se podrían hacer de una forma más eficiente y elegante… pero la idea era hacerlas de forma sencilla para que fueran fáciles de entender. Y como todo buen taller práctico, se puede seguir paso a paso: es posible descargar una máquina virtual de Remnux con todo lo necesario para el taller aquí (para VMWare) o aquí (formato .ova))

Análisis (continuación)

En el artículo anterior habíamos determinado que había “algo raro” en el equipo, y nos habíamos descargado tanto un .doc posiblemente malicioso como un ejecutable y un buzón de correo del usuario. Toca ponerse manos a la obra para ver qué pueden contener…

[Nota: Una buena práctica de seguridad es que NUNCA se comparten ficheros maliciosos sin una mínima protección. Por ello, puedes descargar ambos ficheros desde aquí, pero están comprimidos y protegidos por la contraseña “infected”. Manéjadlos con extremo cuidado, avisados estáis).

Lo primero que podemos hacer es abrir la .pst del usuario para comprobar que la vía de infección es la correcta, algo que podemos hacer fácilmente desde Windows con el Kernel Outlook PST Viewer:
[Read more…]

Caso práctico: “RATas inminentes” (I)

28 de mayo de 2018 Por
(Nota: Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte tecnológica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo.
Estos artículos forman parte de un taller de respuesta ante incidente básico. Por ello, hay cosas que se podrían hacer de una forma más eficiente y elegante… pero la idea era hacerlas de forma sencilla para que fueran fáciles de entender. Y como todo buen taller práctico, se puede seguir paso a paso: es posible descargar una máquina virtual de Remnux con todo lo necesario para el taller aquí (para VMWare) o aquí (formato .ova))

Respuesta ante Incidentes en menos de 15 líneas

Resumen ultra rápido de lo que es la respuesta ante incidentes:

  • Preparación: Nos preparamos para un posible ataque desplegando medidas de detección y respuesta en la Organización.
  • Detección y análisis: Detectamos posibles ataques y los analizamos para determinar si son o no falsos positivos, y en caso de un ataque analizamos su alcance gravedad.
  • Contención, erradicación y recuperación: Contenemos la extensión de los atacantes por el sistema, los expulsamos y devolvemos el sistema a la operación normal.
  • Lecciones post incidente: Analizamos el incidente en busca de medidas de mejora tanto en la seguridad del sistema como en la propia respuesta para futuros incidentes.

[Read more…]

Exchange forensics: El misterioso caso del correo fantasma (IV)

16 de abril de 2018 Por
Artículos de la serie “Exchange forensics: El misterioso caso del correo fantasma”: [1] [2] [3] [4]
(Nota: Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte técnica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo. Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XI Jornadas STIC del CCN-CERT aquí).

Volvemos a la investigación del incidente examinando lo que nuestra compañera había encontrado en los logs del OWA. Si recogemos todos los accesos realizados desde las dos IP con el User-Agent de Firefox, encontramos varios patrones de interés:

  • Patrón 1: Acceso directo: Se observa en los logs cómo los atacantes acceden a la página de login, y luego a la pantalla principal del correo.
  • Patrón 2: Accesos incorrectos: Los atacantes acceden a la página de login, pero la contraseña es incorrecta (observamos repetidos intentos de inicio de sesión, como si estuvieran realizando un ataque manual de fuerza bruta).
  • Patrón 3: Accesos incorrectos + correcto: En un caso específico comprobamos como los atacantes realizan varios intentos de inicio de sesión y al quinto logran entrar.

Este último patrón es el más curioso ¿Cómo han podido los atacantes extraer las contraseñas de un usuario (que son robustas al tener 12 caracteres y forzada la complejidad) en unos pocos intentos? [Read more…]

Exchange forensics: El misterioso caso del correo fantasma (III)

11 de abril de 2018 Por
Artículos de la serie “Exchange forensics: El misterioso caso del correo fantasma”: [1] [2] [3] [4]
(Nota: Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte técnica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo. Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XI Jornadas STIC del CCN-CERT aquí).

Después de una noche con poco sueño (vueltas, vueltas al incidente intentando comprender qué ha podido pasar, qué nos hemos podido pasar por alto, qué nos falta por probar), volvemos cargados de cafeína a la Organización.

Autopsy ha terminado el procesado de la imagen de disco duro, pero tras un análisis superficial de los resultados nuestra teoría inicial se confirma: el equipo del usuario está limpio. De hecho, está tan limpio que el correo malicioso ni siquiera llegó a tocar ese equipo. Por lo tanto, se confirma que todo lo que haya pasado ha tenido que pasar en el Exchange.

Seguimos dándole vueltas al incidente, y hay algo que nos reconcome: si los atacantes tuvieran control completo del Exchange, habrían podido borrar el correo de la carpeta de los Elementos Recuperables, cosa que no han hecho. Pero lo que sí que han logrado ha sido poder borrarlo de la tabla EventHistoryDB, que opera a más bajo nivel… ¿o a lo mejor no lo han hecho?

[Read more…]

Exchange forensics: El misterioso caso del correo fantasma (II)

9 de abril de 2018 Por
Artículos de la serie “Exchange forensics: El misterioso caso del correo fantasma”: [1] [2] [3] [4]

(Nota: Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte técnica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo. Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en   las XI Jornadas STIC del CCN-CERT aquí )

Dejamos el anterior artículo con nuestras miras puestas sobre el servidor de correo de la Organización, un Microsoft Exchange 2010.  Lo primero que podemos hacer es solicitar a Sistemas que haga un message tracking (seguimiento del mensaje) del correo, que mediante una herramienta gráfica (aunque también podemos hacerlo por consola) nos localiza el histórico de un correo a alto nivel dentro de Exchange.

Primer intento, y el correo sigue sin aparecer. Repetimos las direcciones y el técnico de Sistemas repite la búsqueda sin éxito. El correo tiene que estar por fuerza, así que le pedimos que busque de nuevo en todo el día completo… y por fin lo encontramos, 14 minutos más tarde de cuando tenía que haber sido enviado.

Al parecer la Organización no tiene bien implementada su estrategia de sincronización de tiempos, y tenemos una deriva de 14 minutos entre el servidor Exchange y los clientes (nota mental: insistir en la necesidad de desplegar un servidor NTP lo antes posible), pero al fin hemos localizado el correo. El pantallazo enviado por Sistemas sería algo similar a este (por temas de confidencialidad no podemos poner ninguno de los originales):

[Read more…]

Exchange forensics: El misterioso caso del correo fantasma (I)

6 de abril de 2018 Por
Artículos de la serie “Exchange forensics: El misterioso caso del correo fantasma”: [1] [2] [3] [4]

(Nota: Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte técnica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo. Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en   las XI Jornadas STIC del CCN-CERT aquí).

Otro día más en la oficina, con una lista de tareas pendientes a planificar más larga que la barba de Richard Stallman y ninguna de ellas entretenida: informes, documentación de un par de proyectos y la preparación de una reunión es lo que depara el menú del día para casi toda la semana.

Por suerte, el dicho de que “ningún plan sobrevive al contacto con el enemigo” en este caso juega a nuestro favor. Suena el teléfono, y mi jefe va directo al turrón: “Ha saltado una regla YARA del grupo ATD en la CARMEN de [Redacted] (entidad cuya identidad vamos a dejar en el anonimato denominándola a partir de ahora “la Organización”). Coge tus cosas y ve para allí a la carrera”.

El subidón ante la emoción de la caza es instantáneo: ATD es nuestra denominación interna de un grupo de atacantes que cazamos hace unos meses en otro cliente, y nuestros reverser destriparon el malware de arriba a abajo sin piedad. El análisis permitió detectar una serie de “irregularidades” particulares en su forma de actuar, lo que nos permitió generar una serie de reglas de YARA de alta fidelidad (es decir, falsos positivos prácticamente nulos). Si ha saltado en CARMEN (nuestra herramienta de detección avanzada de intrusos), es que tenemos “trufa” al 99%. [Read more…]