lunes, 23 de febrero de 2015

"SANS DFIR Network Forensics Challenge" Writeup Step-by-Step (a la mexicana)

A finales del año pasado el SANS Institute lanzo un reto de forense de red por su curso "Advanced Network Forensics and Analysis". Obviamente como amante de las ciencias forenses y de los retos, me puse manos a la obra, aunque la forensia en red no ha sido mi mayor fuerte, últimamente por cuestiones laborales me he metido con muchos logs y alguna que otra captura de red.

Lamentablemente el reto no lo gane (Se seleccionó al ganador aleatoriamente entre todos los que contestaron), aunque si conteste las 6 preguntas, identifique que en una de ellas me equivoque parcialmente...como sea, a continuación presento la resolución para dichos retos. 

________________________________________________________________________

Pregunta 1: Dificultad: Fácil (Evidencia: SWT-syslog_messages)

At what time (UTC, including year) did the portscanning activity from IP address 123.150.207.231 start?

Para esta pregunta se nos proporciono un log del servicio syslog, del cual debemos averiguar cuando y a que hora comenzo el escaneo de puertos de la IP dada. Cuidando que se debe dar la hora en UTC.

Lo mas fácil es filtrar por IP:


Donde veríamos que el escaneo empezó el 29 de Agosto a las 09:58:55...Sin embargo como forenses debemos cuidar la zona horaria, y aquí no sabemos que zona esta establecida (por ello que pidieran el UTC). Por otro lado tampoco sabemos el año.

Afortunadamente este syslog nos proporciona con información bastante útil, por lo que rápidamente puedo buscar la expresión UTC y la IP:


Aquí vemos que el log se sincronizo para el "29/08/2013" con una hora local "07:07:40" y en UTC seria "11:07:08" por lo que tenemos una diferencia de +4 horas. Por lo que ya tenemos nuestros datos


  • Año: 2013
  • Hora: 09:58:55 + 4 hrs = 13:58:55


Respuesta: 29/Aug/2013 - 13:58:55 (UTC)


________________________________________________________________________


Pregunta 2: Dificultad: Fácil (Evidencia: nitroba.pcap)

What IP addresses were used by the system claiming the MAC Address 00:1f:f3:5a:77:9b?

Para la pregunta 2, tenemos un PCAP (que es una captura de red). Y nos piden identificar que direcciones IP fueron usadas por el dispositivo que tenia dicha dirección MAC.

Con wireshark podemos crear rápidamente unos cuantos filtros siguiente las siguientes reglas:
  1. Que nuestra dirección MAC origen sea 00:1f:f3:5a:77:9b
  2. Que nos elimine todo lo que sea ARP (Puesto que a nivel capa 2, aun no hay direcciones IP)


O "a la mexicana" y como me gusta todo a mí, a línea de comandos con "Tshark" en donde todo se vuelve mas visible, rápido y manipulable:


Donde:
-Y '<filtro>'    (Se crea el filtro como en wireshark)
-Tfields -e ip.src     (Muestra solo la columna de dirección ip origen)
-r nitroba.pcap        (Archivo pcap)
De esta forma ya tenemos nuestra respuesta.

Respuesta: 169.254.90.183, 192.168.1.64, 169.254.20.167.

________________________________________________________________________

Pregunta 3: Dificultad: Media (Evidencia: ftp-example.pcap)

What IP (source and destination) and TCP ports (source and destination) are used to transfer the "scenery-backgrounds-6.0.0-1.el6.noarch.rpm" file?

Para la pregunta 3, nos proporcionan otra captura de red con una sesión FTP, se nos pregunta las IP y puertos origen y destino asociados a la transferencia del archivo.

La manera vaga de resolverlo, es en wireshark buscar la cadena y encontrarlo.


Y la manera "fregona" es a linea de comandos...De nuevo haremos uso de "tshark" donde buscaremos la cadena dentro de los frame y que sean de tipo "ftp-data". Lo demás es solo decirle que mostrarnos...En este caso le decimos nos muestre:
  • Numero de Frame
  • Ip Origen
  • Puerto Origen
  • Ip destino
  • Puerto Destino
  • Tiempo relativo


Nos arroja 5 coincidencias, Sin embargo el primer frame difiere en cuanto a los puertos, esto es por que en ese frame se recibe un listado de los archivos del sistema y la coincidencia es correcta, sin embargo no es el archivo per se...Para eso agregamos los campos de tiempo y frame, asi podemos buscar en los frames especificamente.

Respuesta: 149.20.20.135:30472 y 192.168.75.29:51851.


________________________________________________________________________


Pregunta 4: Dificultad: Media (Evidencia: nfcapd.201405230000 (requires nfdump v1.6.12. Note that nfcapd.201405230000.txt is the same data in nfdump’s “long” output format.))

How many IP addresses attempted to connect to destination IP address 63.141.241.10 on the default SSH port?

Esta pregunta era demasiado sencilla, se nos preguntaba cuantas direcciones IP trataron de conectarse a la IP destino 63.141.241.10 en el puerto 22. Se nos proporciono un archivo que se necesitaba leer con nfdump, sin embargo nos dieron la versión larga de salida en un TXT, por lo que lo mas sencillo es usar eso. Con un poco de magia, sale de volada.


Así vemos rápidamente las IP's que intentaron conectarse y que fueron 49.

Respuesta: 49.

________________________________________________________________________


Pregunta 5: Dificultad: Difícil (Evidencia: stark-20120403-full-smb_smb2.pcap)

What is the byte size for the file named “Researched Sub-Atomic Particles.xlsx”

Nos preguntan cual es el tamaño en bytes, del archivo. Con wireshark rapidamente se busca y en las propiedades encontramos el tamaño.


Como el protocolo SMB lo usa Windows, no hay mejor lugar que las referencias de microsoft para encontrar la explicación que necesitamos.

Respuesta: 13625 bytes.

________________________________________________________________________


Pregunta 6: Dificultad: Muy dificil (Evidencia: snort.log.1340504390.pcap)
  • The traffic in this Snort IDS pcap log contains traffic that is suspected to be a malware beaconing. Identify the substring and offset for a common substring that would support a unique Indicator Of Compromise for this activity.
  • Pregunta Extra: Identify the meaning of the bytes that precede the substring above.


Se nos proporciona una captura de red del detector de intrusos Snort. Se sospecha que se esta plantando malware y se nos pide identificar una subcadena precisa que pueda servir como IoC, así como su offset.

Además como pregunta extra se nos pide identificar el significado de los bytes que están antes de la subcadena.

Si damos un vistazo rápido con wireshark, se identifica a primera vista la subcadena.

  • La cadena es: ULQENP2 que puede ser usada como Indicador de Compromiso para una regla.
  • Offset: Empieza en el offset 4 de la "Data", los primeros 4 bytes son los que debemos averiguar que significan.


Para identificar bien todo el comportamiento, agarre la "data" de los primeros 5 y 5 ultimos frames de la captura, y los pase a un archivo para su análisis con un editor hexadecimal. Así puedo encontrar patrones.
  • Claramente identificamos que los bytes 0x554c51454e5032 pertenecen a la cadena ULQENP2.
  • Vemos que todo acaba con un salto de linea (\n) 0x0A.
  • Y que los primeros dos bytes se repiten 0x4FE6.


Enfocandonos en los primeros 5 frames:

Vemos que los primeros 3 bytes son iguales y solo varia levemente el 4 byte. Sin embargo en el frame 4 y 5 se repite el byte 0x78.

Revisando la trame de wireshark, en el frame 4 y 5 encontramos una coincidencia entre estos dos paquetes...

El frame 4 y 5 tienen el mismo segundo de cuando llego el paquete.

Frame 4:
Frame 5;

Con esto podemos sugerir que los primeros 4 bytes se refieren al tiempo. Si convertimos los bytes 0x4fe6c278 (Big Endian) a decimal...nos da "1340523128".


Lo cual es la parte entera del tiempo "epoch". Osea que es un UNIX timestamp. Si eso lo convertimos nos da:


Efectivamente concuerda con lo esperado.

Respuesta: ULQENP2, offset 4, y lo que esta antes es un UNIX timestamp.


________________________________________________________________________


Si requieren la evidencia para practicar, se las podemos proporcionar.
Espero les agrade el post y nos sigan en nuestro twitter @bu5t3r5 donde ponemos tips, comandos y más... 

¡Saludos!

jueves, 12 de febrero de 2015

Registry Explorer es MUST en su arsenal Forense

Saludos BugBu5t3r5!

Sé que no es tan común escribir dos posts seguidos sin embargo cosas como estas no pueden esperar! 

La herramienta en cuestión está hecha por EricZimmerman (sino saben quién es les sugiero encarecidamente que echen un ojo a su blog vale muchísimo la pena) se llama Registry Explorer y tal como su nombre lo indica te permite ver llaves del registro sin embargo te permite hacerlo offline, es decir puedes extraer tus llaves del registro de tu evidencia y cargarlas en la herramienta, ya jugamos un poco con ella  y la verdad es que vale muchísimo la pena, tiene un par de features por ahí que no encontraran en otro parcer del Registo, Le pedimos chance a Eric para escribir una pequeña reseña de las características principales de la herramienta y como usarla asi que se las presentamos.

La herramienta la pueden descargar aquí, les recomiendo que lo hagan en Firefox o IE puesto que Chrome bloqueaba la descarga. Una vez descargada solo extraigan el contenido del .zip y listo doble click al .exe y verán algo similar a la siguiente imagen.

lunes, 9 de febrero de 2015

Informacion de TimeZone, perder o ganar un caso

Saludos BugBu5t3r5! 

Hace un par de días un cliente me llamo y me dijo que su área de seguridad de la información estaba llevando a cabo una investigación de robo de secretos industriales, me comentó que sospechaban que el usuario “sabia más de computadoras de lo que aparentaba” y que suponían que estaba utilizando técnicas anti forenses ya que las horas y fechas de creación y modificación de todos los archivos de la maquina no correspondía con lo que el administrador de sistemas les reportaba de cuándo y a qué hora este usuario se había loggeado a su máquina, es decir, la consola de administración les daba pistas de ciertos accesos al sistema del sospechoso a ciertas horas y en ciertos días no comunes pero las fechas y horas de los archivos no soportaban esa evidencia. La pregunta era; si, ¿Yo sabía de algún software o técnica anti forense y como remediarlo?.

Mi primera respuesta como la de muchos de ustedes hubiera sido fue, “claro, si por supuesto que hay formas de modificar esa información en los archivos, Timestomp por ejemplo, y no es tan sencillo encontrar evidencia de esto en un sistema” sin embargo al hacer un perfilamiento del sospechoso me parecía poco probable que esa fuera la razón de discrepancia de las timestamps. Así que pedí revisar su metodología de adquisición de evidencia y sus formatos de cadena de custodia y hoja de adquisición de evidencia digital, y fue ahí cuando vi la luz! El equipo del cual provenía la evidencia estaba en un estado diferente del cual estaba siendo analizado, de hecho con otra zona horaria, ¿ya saben por qué la discrepancia entre las timestamps?

Mi siguiente pregunta fue obvia ¿revisaron la configuración de la zona horaria? ¿Hicieron los ajustes necesarios en el sistema en el que fue analizado? El silencio que siguió a las preguntas me dijo todo… ese era el problema, es por eso y como respuesta a la petición del equipo de seguridad de la información que decidí  hacer este pequeño post acerca de cómo verificar e interpretar correctamente la información de las zonas horarias.