Sumérgete en los archivos LNK nivel experto

Saludos Bug Bu5t3r5!!

Hace un par de días  estaba leyendo un post en Hacking Exposed Computer Forensic Blog acerca de los artefactos de Windows, y algo que me llamo mucho la atención es que David Cowen comentaba que cuando él está entrevistando a candidatos para formar parte de su equipo se enfoca mucho en el entendimiento que tiene el examinador de los artefactos de Windows y en la interpretación de la información que puede obtener de ellos, una de las preguntas que más me llamo la atención y de donde tome la idea para este post es: ¿Qué puedes determinar a partir de un archivo LNK?

Mr. Cowen después explica que él puede medir el nivel de expertise de un candidato en base a su respuesta, piensen en la pregunta y respondan antes de ver lo que David considera como posibles respuestas y midan en donde están, para esto  me permitiré traducir este fragmento del post de hacking exposed.

Respuesta de principiante: Un LNK   nos puede decir a que archivos o programas ha accedido un usuario.

Respuesta intermedia: Un LNK revela a que archivos o programas ha accedido un usuario y que ruta tienen en la red y la MAC address del equipo.

Respuesta Experimentada: Un LNK revela a que archivos o programas ha accedido un usuario y que ruta tienen en la red y la MAC address del equipo, también contiene timestamps del archivo y/o el programa que se está teniendo acceso el cual representa al archivo en el momento en que fue accedido.

Respuesta Senior: Un LNK revela a que archivos o programas ha accedido un usuario y que ruta tienen en la red y la MAC address del equipo, también contiene timestamps del archivo y/o el programa que se está teniendo acceso el cual representa al archivo en el momento en que fue accedido. También contiene el serial del dispositivo o volumen que puede ser utilizado para hacer match con el volumen del cual proviene si no hay volumen nos puede decir la fuente de red de la que proviene. Los archivos LNK también contienen elementos de Shell permitiendo así al examinador determinar qué tipo de carpeta está siendo accedida (volumen/network/file/uri).

Respuesta de experto: Un archivo de vinculo (lnk) contiene dos conjuntos de timestamps que son relevantes para el examinador. El primer conjunto de MAC times pertenece al mismo archivo lnk, nos revela por medio de la fecha de creación cuando fue accedido el archivo por primera vez según lo registra el archivo lnk, la fecha de modificación registra la última vez que el archivo lnk fue actualizado y  debería reflejar el ultimo acceso exitoso. El segundo conjunto de fechas se mantienen en el target al que el link file hace referencia y se puede erealizar la correlacion basados en  el ultimo acceso exitoso al archivo desde el  lnk. Para poder determinar estados previos del archivo es posible analizar los puntos de restauración (WinXP), las volumen shadow copies (Win7) y hacer un carving de los archivos lnk para encontrar otras versiones de este archivo lnk que también hagan referencia al archivo en cuestión al serial del volumen o a los elementos de Shell. Cada conjunto de MAC times que es actualizado representa otro acceso exitoso al archivo a través del lnk y debe ser considerado como “en uso”.

Interesante no? Si se fijan la respuesta que daría un experto no tiene nada que ver con cuestiones técnicas como la estructura interna del archivo o los FO en que se encuentra cierta información que si bien es importante no es tan importante como saber interpretar correcta y puntualmente la información dada por el archivo. El leer esto me puso a pensar no solo en qué respuesta hubiera dado yo si me hubieran preguntado antes de leer el post sino también en como poder ver, obtener  e interpretar esa información que nos haría dar una respuesta de expertos. La única parte que no cubriré en este post será el análisis de restore points  y VSS ya que eso lo dejaremos para otra ocasión.

Es cierto que los link files pueden residir en casi cualquier carpeta del sistema sin embargo la ubicación principal para estos archivos por lo general es %APPDATA% \Microsoft\Windows\Recent Items\<archivos de vinculo> en donde %APPDATA% se traduce como C:\Users\<nombre del usuario>\AppData\Roaming. Aquí es en donde el sistema operativo de forma automática crea un shortcut basado en un usuario dando doble click a una aplicación para ejecutarla y estos puede perdurar incluso cuando la aplicación original hjaya sido eliminada. 

Como podemos ver a nivel sistema operativo parecería que esta carpeta almacenara los archivos en sí, sin embargo datos como el tipo de los archivos y su tamaño delatan que realmente se tratan de archivos LNK , visto desde otra aplicación en este caso EnCase , podemos ver que todos son archivos de vinculo. dentro de los archivos vistos en case pueden ver que hay algunos que apuntan hacia volumens, estos son LNK que fueron creados a partir de archivos que residian en medios extraibles.

Si tomamos uno de estos archivos LNK y lo mandamos a un editor hexadecimal (yo estoy utilizando HxD) podremos empezar a identificar la información que es relevante para nuestras investigaciones, ahora, yo sé que hay mucha más información en los archivos LNK que la que voy a explicar sin embargo no es el objetivo de este post explicar toda la estructura del archivo si quieren echarse un clavado en el mundo de información que estos archivos contienen, pueden ver aquí y aquí , son excelentes y aprenderán muchísimo de la estructura interna de los LNK.

Para este post usare un LNK de mi equipo llamado 01.jpg lo primero que vemos es el encabezado del archivo el cual tiene un valor de 0x0000004C .

La siguiente información de relevancia para nosotros es el primer conjunto de timestamps en el FO 28 por 8 bytes tenemos la fecha/fecha hora de creación, los siguientes 8 bytes muestran la fecha/hora de ultimo acceso y los siguientes 8 bytes muestran la fecha/hora de ultima escritura.

Para poder descifrar estas fechas/horas vamos a utilizar una herramienta llamada DCode la pueden descargar gratis aquí, esta herramienta es increíblemente sencilla de utilizar la única información que necesitan saber es el ADD Bias, para la Cd. De México es UTC -5:00, necesitan conocer el formato que usaremos para decodificar en este caso Windows:64 bit Hex Value en Little Endian y  copiar el valor hexadecimal a decodificar, listo. 

Nuestra fecha/ hora de creación: AC 52 8C 9E 67 83 D0 01

Nuestra fecha/ hora de ultimo acceso: 0D B8 9D 9E 67 83 D0 01

Nuestra fecha/ hora de ultima escritura: 1D DF 9D 9E 67 83 D0 01

Al finalizar esta información en el FO 52 por 8 bytes tenemos el tamaño del archivo, sin embargo este valor tiene que ser interpretado de hexadecimal a Little Endian INT32 ,aquí podrán encontrar un convertidor en línea muy útil, el valor resultante de esa conversión es el tamaño logico del archivo en bytes en este caso 74297 bytes.

En ocasiones tendremos que verificar el tipo de disco en el que el target para este LNK esta almacenado esta infomracion se encuentra 16 bytes antes del nombre del volumen del target en este caso es el FO 438 y tiene un valor de 03 00 00 00 por lo cual este LNK esta apuntando a un archivo que se encuentra en el disco duro. 

Valor	Significado
DRIVE_UNKNOWN 0x00000000	El tipo de disco no puede ser identificado.
DRIVE_NO_ROOT_DIR 0x00000001	La ruta principal es inválida, por ejemplo, no hay ningún volumen montado en esa ruta.
DRIVE_REMOVABLE 0x00000002	Este disco es removible, tal como un lector de tarjetas flash o un USB.
DRIVE_REMOTE 0x00000003	El disco es fix media, es decir un disco duro.
DRIVE_CDROM 0x00000004	El disco es remoto es decir se encuentra en la red.
DRIVE_RAMDISK 0x00000005	CD-ROM
DRIVE_RAMDISK 0x00000006	RAM disk

Seguida de esta información tenemos 4 bytes que nos ayudaran  a determinar el número de serie del volumen en el que el target al que apunta este LNK está almacenado, este valor está almacenado en orden inverso. Para un volumen NTFS este sería el equivalente del valor corto del número de serie del volumen ya que el valor completo es de 8 bytes. Para nuestro ejemplo el valor original de los 4 bytes son 66 33 59 96 en orden inverso seria 96 59 33 66 para verificar que esta información sea correcta tenemos que ver el número de serie del volumen en este caso de C:\.

 Como se muestra la información encontrada en el archivo LNK coincide con la información del disco. 

Usando EnCase vamos a verificar las fechas y horas del target de este LNK aquí tenemos nuestro segundo set de timestamps, lo más importante es poder hacer match entre la fecha de creación del LNK y el archivo target, el archivo pudo desde entonces sufrir modificaciones y estas timestamps no coincidir. Es posible encontrar otro tipo de discrepancias entre esta información y la reflejada por el archivo LNK, los campos ya descritos de hora/fecha de modificación, acceso y creación reflejan la información del archivo LNK,  mientras que la de hora/fecha de modificación, acceso y creación del target reflejan la información del archivo al cual el LNK apunta por eso cuando copiamos un LNK den un sistema target a un archivo offline para analizarlo, las fechas reflejaran la información de cuando fue creado en el sistema offline, por eso es importante utilizar una herramienta forense en lugar copiar/pegar al mover los archivos LNK.  

Espero este pequeño post haya sido de utilidad, ahora no solo saben que contestar cuando alguien les pregunte que podemos determinar a partir de un LNK y no solo saberlo sino también poder obtener esa información utilizando únicamente un edito hexadecimal, es cierto que hay herramientas que nos dan esta información y mucho más aquí pueden leerse un documento que habla de una herramienta llamada lp.exe de TZWorks súper herramienta se las recomiendo, lamentablemente no es gratis pero nos da muchísima información de los archivos de vinculo y nos permite hacer muchas cosas más como hacer carving de un VSC. Échenle un ojo y Happy Busting!

Bu5t3r

Respuestas del 2o BugQuiz

Saludos!

Aqui les ponemos las respuesta del Quiz ... esperamos que les haya gustado, lamentablemente no hubo ganadores :(

1.     De manera predeterminada ¿cuál es el tamaño de un registro de la $MFT?
R=  De manera predeterminada un registro de MFT es de 1024 bytes de longitud, si un archivo es lo suficientemente pequeño su contenido se almacena dentro del registro de la MFT justo a un lado de su metadata de otra forma, existirá un puntero indicando cuales clusters contienen la información

2.     Hablando de VSS ¿cuál es el porcentaje máximo del total de tamaño del que un volume shadow copy puede ocupar en Windows Vista y Win7?
R=  Las limitaciones de un VSS  de forma predeterminada  para WinVista es del 15% total del disco y para Win7 3-5%

3.     En el tweet que fue posteado el 04/02/15 se muestra la siguiente pantalla:

 Si bien los dos comandos indican la capacidad de la RAM, la información mostrada por systeminfo es menor a la que wmic muestra, explica ¿por qué?
R=   La discrepancia se puede entender de la siguiente manera: el comando Wmic muestra el total de la memoria RAM instalada en el sistema mientras que el comando systeminfo muestra la memoria usable que se calcula como Memoria Total menos la memoria reservada para el hardware.

4.     Explica que indicadores dan las siguientes pantallas de que este proceso es malicioso:

R=  En la imagen mostrada hay ciertos indicadores bastantes claros de que este proceso es malicioso, comenzado por el Parent Porcess (PSEXESVC.EXE) , para un svchost.exe el PP siempre debe ser services, cualquier otra cosa mostrada es un fuerte indicio de un proceso que deberíamos analizar con más calma, lo siguiente son los argumentos del svchost.exe, si este fuera un proceso legitimo debería estar acompañado de algo como svchost.exe –k netsvcs , también sería bueno verificar la hora de inicio de otros scvhost.exe usualmente todos arrancan en tiempos iguales, sin embargo no podemos definir esto desde estas pantallas y por último el Security ID del usuario desde el cual es llamado el svchost es de un usuario standard lo cual es altamente inusual para este tipo de procesos.

5.     Si quisiera montar una imagen E01 en Linux con la capacidad de ver los archivos de sistema (como la $MFT) y ver la estructura de los archivos como un usuario los vería normalmente en Windows ¿Qué comando o comandos utilizaría? 
R= Para obtener los resultados por lo general yo utilizo mount -o ro,loop,show_sys_files,streams_interface=windows /mnt/ewf/<nombre de la imagen raw>  /mnt/windows_mount  

·                     Show_sys_files: esta opción muestra los metafiles de los listados de directorios, es decir vamos a poder ver archivos utilizados para almacenar la estructura de NTFS o FAT que normalmente no estarían visibles por ejemplo la $MFT.

·                     Streams_interface=windows: esta opción controla como el usuario puede acceder a Alternate Data Streams (ADS) al utilizar la opción=Windows les va a permitir visualizar los archivos como comúnmente se verían en Windows.

6. ¿Cuál es la mejor manera de saber si un archivo ".exe" fue ejecutado? (Considere que pudo haber técnicas antiforense) ¿Dónde buscaría, o que comandos ejecutaria?...La respuesta más ingeniosa y completa gana esta pregunta extra
para esta pregunta no habia una respuesta exacta por lo cual no podemos poner la respuesta correcta

Bu5tQuiz #2

Conmemorando nuestros 200 followers en twitter traemos el segundo Bu5tQuiz , las instrucciones han cambiado un poco así que por favor léanlas.

Instrucciones: 

El quiz consta de 6 preguntas cada una de ellas tiene un valor en puntos:

• 5 puntos para una respuesta completa y correcta.
• 3 puntos para una respuesta parcial y correcta.
• 0 puntos para una respuesta incorrecta.

Las preguntas son de diferente dificultad, sin embargo su valor en puntos es el mismo la persona que acumule más puntos con sus respuestas es el ganador.

No importa si no eres el primero en contestar, sino que tus respuestas sean las más acertadas y detalladas posibles.

Tienes hasta el viernes 3 de abril para poder enviar tus respuestas.

Las respuestas se envían a bugbu5t3r5@gmail.com 

Las respuestas a las preguntas se postearan cuando finalice el reto.

Los premios:

1er lugar: Libro iOS forensics y saga completa de Family Guy: Star Wars y un vale de 50% para un curso de BugBu5t3r5

2do lugar: Copia digital de El Hobbit: La batalla de los 5 ejércitos.

Si el o los ganadores viven fuera de la Ciudad de México, les haremos llegar su premio (LATAM). 

Las preguntas

1.     De manera predeterminada ¿cuál es el tamaño de un registro de la $MFT?

2.     Hablando de VSS ¿cuál es el porcentaje máximo del total de tamaño del que un volume shadow copy puede ocupar en Windows Vista y Win7?

3.     En el tweet que fue posteado el 04/02/15 se muestra la siguiente pantalla:

 Si bien los dos comandos indican la capacidad de la RAM, la información mostrada por systeminfo es menor a la que wmic muestra, explica ¿por qué?

4.     Explica que indicadores dan las siguientes pantallas de que este proceso es malicioso:

5.     Si quisiera montar una imagen E01 en Linux con la capacidad de ver los archivos de sistema (como la $MFT) y ver la estructura de los archivos como un usuario los vería normalmente en Windows ¿Qué comando o comandos utilizaría? 

6. ¿Cuál es la mejor manera de saber si un archivo ".exe" fue ejecutado? (Considere que pudo haber técnicas antiforense) ¿Dónde buscaría, o que comandos ejecutaria?...La respuesta más ingeniosa y completa gana esta pregunta extra

¡Saludos!

"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!

-@hecky-

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.