El enunciado de esta cuarta parte nos dice lo siguiente:

Based on the information available to you, what is the maximum amount of time Vivian Alyse could have spent composing the final message in the thread that you examined? That is, time elapsed from the moment she pressed the “Reply” or “Forward” button, to the moment she hit “Send”. Assume that the following is true:

Vivian used Outlook to compose and send the message
All of the computers involved in the email conversation keep perfectly accurate time

Enter the duration in minutes rounding up. For example, enter 46 for 45 minutes and 31 seconds.

Este es bastante fácil. Si lo retomamos dónde lo dejamos en el artículo anterior, en la propiedad PR_CONVERSATION_INDEX tenemos unos valores llamados TimeDelta y de estos nos interesa el segundo que es la última respuesta a este correo.


El valor 0x00000AE9 lo tenemos que convertir a decimal y posteriormente a minutos quedando que son 1 minuto y 47 segundos, que redondeando hacia arriba como nos pide el enunciado nos queda el valor de 2 minutos. :checkered_flag:

Y con esto ya hemos terminado este reto. :tada:

El enunciado de esta tercera parte nos dice lo siguiente:

It is believed that the email you examined in Part 1 and Part 2 of this challenge was the last message in a conversation thread that comprises multiple messages. Based on the information available to you, when was the initial message in this conversation thread likely sent?

Enter the timestamp in UTC in the following format: yyyy-mm-dd hh:mm:ss (e.g., 2005-11-20 13:17:48)

Una vez que abrimos el mensaje en Outlook y hacemos clic sobre el botón “iMessage” veremos toda la información interna del fichero incluyendo sus propiedades MAPI. La propiedad que debemos buscar es PR_CONVERSATION_INDEX. Dentro de esta propiedad lo que nos interesa es el campo Value que contiene una cadena hexadecimal de 32 bytes que tenemos que descomponer.


De toda esta estructura lo que nos interesa son los primeros doce caracteres a los que debemos añadir cuatro ceros (0000) en la parte posterior quedando el valor 01D5D17A24E40000 y así completar la longitud de 32 bits.

Si os estáis preguntando qué representa este valor pues os cuento que es el número de nanosegundos que han pasado desde el 1 de enero de 1601 que es lo que se conoce como unidades FILETIME (https://docs.microsoft.com/es-es/office/client-developer/outlook/mapi/filetime).

Lo más rápido para convertir esto a una fecha “humana” es utilizar un conversor de FILETIME como el de la página https://www.epochconverter.com/ldap. Tras convertirlo nos queda la fecha 22 de enero de 2020 a las 23:17:41 que es la respuesta que buscamos. Tan solo queda formatearlo tal y como se nos indica, con lo que la respuesta final es 2020-01-22 23:17:41.

El enunciado de esta segunda parte nos dice lo siguiente:

Regardless of whether you believe it is legitimate or fake, what is the last modification timestamp you were able to find for the attachment in Part 1?

Enter the timestamp in UTC with 0.1 microsecond precision in the following format: yyyy-mm-dd hh:mm:ss.fffffff (e.g., 2005-11-20 13:17:48.1234567)

Recuperamos la salida del script de la primera parte con el siguiente contenido:

┌──(kali㉿kali)-[~/Desktop/msgopen]
└─$ php ex1.php
Message Creation time: 1607983178 => 2020-12-14 16:59:38.000000 EST
Message Last modification time: 1607983178 => 2020-12-14, 16:59:38.000000 EST

Attachment: FC_4fca-8f34_Specs.txt
Attachment creation time: 1591119805 => 2020-06-02 13:43:25.000000 EDT
Attachment last modification time: 1591385420 => 2020-06-05 15:30:20.000000 EDT
┌──(kali㉿kali)-[~/Desktop/msgopen]
└─$ 

Cuidado con el enunciado que nos pide que demos la respuesta en zona horaria UTC y nosotros tenemos la respuesta en EST/EDT. Podríamos modificar el script anterior para que nos muestre las fechas en UTC pero es mucho más rápido “googlear” un poco y averiguar que la diferencia horaria es de 4 horas hacia delante desde EST a UTC y sumarlas obteniendo 2020-06-05 19:30:20.0000000 que es la respuesta solicitada.

El enunciado de esta primera parte nos dice lo siguiente:

You are being asked to examine an email1 between two colleagues within the same corporation. The email contains an important business document known to have been created and maintained on a volume formatted with the NT File System (NTFS).

Based on your examination of the email, are the creation and last modification timestamps of the attachment more likely to be legitimate or fake? Enter L for legitimate, F for fake.

1SHA-256: FB42631EC43891EE2D877E02D911 A1FFB95E9B31825986F09DEFE8B9A55F2614

El primer paso es descargarse el fichero en formato msg. Como siempre usamos el comando sha256sum y comprobamos que el “hash” coincide.

──(kali㉿kali)-[~/Desktop/msgopen]
└─$ sha256sum FW__New_Finite_Curvature_Product_Line_Specs.msg                                                 127 ⨯
fb42631ec43891ee2d877e02d911a1ffb95e9b31825986f09defe8b9a55f2614  FW__New_Finite_Curvature_Product_Line_Specs.msg
                                                                                                                    
┌──(kali㉿kali)-[~/Desktop/msgopen]

El siguiente paso lógico sería pasar por VirusTotal el fichero para ver si tiene algo raro dentro pero vamos a omitir este paso porque ya sabemos que es algo que todos hacemos antes de abrir un fichero. :wink:

Aquí lo normal sería utilizar alguna herramienta para Windows y poder husmear dentro de las propiedades MAPI del fichero pero como a mí me gusta hacer las cosas al “estilo software libre” voy a usar una librería de PHP llamada hfig/mapi (https://github.com/hfig/MAPI) en un pequeño script. Aquí os dejo su contenido:

<?php
require 'vendor/autoload.php';

use Hfig\MAPI;
use Hfig\MAPI\OLE\Pear;

// message parsing and file IO are kept separate
$messageFactory = new MAPI\MapiMessageFactory();
$documentFactory = new Pear\DocumentFactory(); 

$ole = $documentFactory->createFromFile('FW__New_Finite_Curvature_Product_Line_Specs.msg');
$message = $messageFactory->parseMessage($ole);

$dateToPrint = date_create();
date_timestamp_set($dateToPrint, $message->properties['creation_time']);
echo 'Message Creation time: ', date_format($dateToPrint,'U => Y-m-d H:i:s.u T'), "\n";
date_timestamp_set($dateToPrint, $message->properties['last_modification_time']);
echo 'Message Last modification time: ', date_format($dateToPrint, 'U => Y-m-d, H:i:s.u T'), "\n\n";
foreach ($message->getAttachments() as $attachment) {
  echo 'Attachment: ', $attachment->properties['display_name'], "\n";
  date_timestamp_set($dateToPrint, $attachment->properties['creation_time']);
  echo 'Attachment creation time: ', date_format($dateToPrint,'U => Y-m-d H:i:s.u T'), "\n";
  date_timestamp_set($dateToPrint, $attachment->properties['last_modification_time']);
  echo 'Attachment last modification time: ', date_format($dateToPrint,'U => Y-m-d H:i:s.u T'), "\n";
}
?>

Tras ejecutarlo la salida que muestra es la siguiente:

┌──(kali㉿kali)-[~/Desktop/msgopen]
└─$ php ex1.php
Message Creation time: 1607983178 => 2020-12-14 16:59:38.000000 EST
Message Last modification time: 1607983178 => 2020-12-14, 16:59:38.000000 EST

Attachment: FC_4fca-8f34_Specs.txt
Attachment creation time: 1591119805 => 2020-06-02 13:43:25.000000 EDT
Attachment last modification time: 1591385420 => 2020-06-05 15:30:20.000000 EDT
┌──(kali㉿kali)-[~/Desktop/msgopen]
└─$ 

Aunque no lo pueda demostrar fehacientemente, es bastante probable que se hayan modificado las fechas de creación y modificación de este correo y de sus adjuntos porque es muy poco probable que todas estas acciones se realicen justo en el microsegundo cero.

El enunciado nos dice lo siguiente:

Congrats on making that determination! You are now asked to take this a step further, and determine the earliest date and time the email could have been sent based on the timing information you can locate within the file.

You will be examining the same email1. Included here again for convenience.

1SHA-256: 42B6FD78DAF38C03E1A744ECA1A0CB 44F6859AB892E0F32B01763EFD835B5648

Enter the timestamp in UTC in the following format: yyyy-mm-dd hh:mm (e.g., 2005-11-20 13:17)

Ya nos habíamos descargado el fichero pero si no lo tenemos lo podemos descargar otra vez desde este mismo reto. Como siempre usamos el comando sha256sum y comprobamos que el “hash” coincide.

(kali㉿kali)-[~/Desktop]
└─$ sha256sum Draft_Agreement.eml 
42b6fd78daf38c03e1a744eca1a0cb44f6859ab892e0f32b01763efd835b5648  Draft_Agreement.eml
                                                                           
┌──(kali㉿kali)-[~/Desktop]
└─$ 

El siguiente paso lógico sería pasar por VirusTotal el fichero para ver si tiene algo raro dentro pero vamos a omitir este paso porque ya sabemos que es algo que todos hacemos antes de abrir un fichero. :wink:

Nos están pidiendo la primera fecha en la que el correo pudo ser enviada. Como ya sabemos del artículo anterior no es posible que podamos obtener ese dato de las cabeceras del correo electrónico, pero si recordáis en el correo había un fichero adjunto llamado “Agreement_v2.pdf”.

──(kali㉿kali)-[~/Desktop]
└─$ grep 'Content-' Draft_Agreement.eml                              130 ⨯
Content-Type: multipart/mixed; 
Content-Length: 70085
Content-Type: multipart/alternative; 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Agreement_v2.pdf"
Content-ID: <bd1c0c4c-3c0e-20e0-f6b2-5bc858aab23a@yahoo.com>

Vamos a separarlo utilizando el comando munpack para poder manipularlo. Por cierto, en Kali no viene instalado por defecto y es necesario instalar el paquete mpack.

──(kali㉿kali)-[~/Desktop]
└─$ sudo munpack Draft_Agreement.eml
tempdesc.txt: File exists
)greement_v2.pdf.1 (application/pdf
                                                                           
┌──(kali㉿kali)-[~/Desktop]
└─$ 

Yo no tengo ganas de abrir el fichero porque ya sabemos las cosas malas que se pueden meter en un PDF y además dudo que sea tan sencillo de resolver como visualizar el fichero. Sin embargo, sí hay algo que sabemos de antes que nos puede ayudar. ¿Recordáis la fecha de la versión de Chrome que vimos en la cabecera “X-Mailer”? Pues vamos a rastrear el fichero PDF del adjunto para ver si podemos obtener cadenas de texto que hagan referencia al año 2020 mediante el comando pdf-parser.

(kali㉿kali)-[~/Desktop]
└─$ pdf-parser Agreement_v2.pdf|grep -B10 2020
 Type: /Annot
 Referencing: 46 0 R, 9 0 R

  <<
    /AP
      <<
        /N 46 0 R
      >>
    /C [1.0 1.0 1.0]
    /Contents (Dean Vinny)
    /CreationDate "(D:20201206151800-08'00')"
    /DA (0.898 0.1333 0.2157 rg /Helv 12 Tf)
    /DS (font: Helvetica,sans-serif 12.0pt; text-align:left; color:#E52237 )
    /F 4
    /M "(D:20201206151937-08'00')"

Aquí tenemos dos fechas muy interesantes. Si nos fijamos en el resultado se ve el contenido de una anotación cuyo contenido es el nombre de la persona y además dos fechas casi seguidas. La primera se corresponde con la fecha de creación de la anotación y la segunda con la fecha de la última modificación de esa anotación. Vamos a coger la segunda fecha porque parece difícil que se puede enviar un fichero antes de terminar de editarlo. En esta fecha que fijarse que es necesario calcular la diferencia horaria para sumarla a la hora y con eso ya tendríamos la respuesta, el 6 de diciembre de 2020 a las 23:19.

El enunciado nos dice lo siguiente:

You have received the email1 below in connection with a legal action. The timing of the email is critical. Examine the email and determine if it is more likely to be legitimate or fake.

Enter L for legitimate, F for fake. More to come based on your answer.

SHA-256: 42B6FD78DAF38C03E1A744ECA1A0CB 44F6859AB892E0F32B01763EFD835B5648

Si nos descargamos el fichero EML, el primer paso como siempre es comprobar la suma SHA256. Para ello usamos el comando sha256sum y comprobamos que el “hash” coincide.

(kali㉿kali)-[~/Desktop]
└─$ sha256sum Draft_Agreement.eml 
42b6fd78daf38c03e1a744eca1a0cb44f6859ab892e0f32b01763efd835b5648  Draft_Agreement.eml
                                                                           
┌──(kali㉿kali)-[~/Desktop]
└─$ 

El siguiente paso lógico sería pasar por VirusTotal el fichero para ver si tiene algo raro dentro pero vamos a omitir este paso porque ya sabemos que es algo que todos hacemos antes de abrir un fichero. :wink:

Yo prefiero usar un editor de textos para abrir los ficheros EML y así poder revisar tranquilamente su contenido. En este artículo voy a utilizar el comando grep para simplificar su redacción.

A primera vista las cabeceras que contienen fechas parecen legitimas y están sincronizadas por lo que el correo parece provenir del 7 de marzo de 2016, pero aquí tiene que haber algún truco, no me creo que sea tan sencillo.

──(kali㉿kali)-[~/Desktop]
└─$ grep Mar Draft_Agreement.eml
        Mon, 7 Mar 2016 14:38:34 -0800 (PST)
        Mon, 07 Mar 2016 14:38:34 -0800 (PST)
        Mon, 07 Mar 2016 14:38:34 -0800 (PST)
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Mon, 7 Mar 2016 22:38:33 +0000
Date: Mon, 7 Mar 2016 22:38:31 +0000 (UTC)

Comprobando el resto de cabeceras vemos que hay una interesante, la que se corresponde con “X-Mailer” que habla de la versión 87.0.4280.67 de Chrome y de Edge basado en Chromium tal y como se puede ver en la siguiente captura.

┌──(kali㉿kali)-[~/Desktop]
└─$ grep 'X-Mailer' Draft_Agreement.eml        
X-Mailer: WebService/1.1.17111 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.67 Safari/537.36 Edg/87.0.664.55

Aquí hay algo raro. Si buscamos en Google podemos confirmar que esa versión de Chrome es del 17 de noviembre de 2020, con lo que es imposible que el correo sea del año 2016.

¡Bingo! Ya tenemos la prueba para demostrar que la fecha del correo fue alterada.