En el artículo anterior habíamos comprobado que se habían mandado una serie de correos desde la cuenta del CEO del MINAF al CFO, logrando mediante ingeniería social la realización de una serie de transferencias. Nos quedamos en un punto de la investigación en la que queremos saber más acerca de esos correos, y para ello tenemos que irnos a la base de datos de bajo nivel de Exchange: EventHistoryDB.
El EventHistoryDB es una base de datos que recoge con un detalle minucioso todo el ciclo de vida de un correo en Exchange. Gracias al EventHistoryDB podríamos llegar a saber detalles tan granulares como:
- Cuándo se empezó a escribir un correo.
- Cuándo se envió.
- Si fue o no leído por el destinatario, y cuándo.
- Si el correo fue movido a una carpeta.
- Si el correo fue respondido.
- Si el correo fue enviado a la papelera, o incluso si fue borrado de la misma.
Por desgracia no todo es perfecto en el EventHistoryDB. Solo es accesible mediante Powershell (nada de interfaces gráficos bonitos), y solo se guardan por defecto los últimos 7 días. Sin embargo, en este caso el MINAF ha reaccionado con gran rapidez y esto nos ha permitido entrar holgadamente dentro de ese plazo, por lo que es posible recuperar íntegramente los registros para los dos usuarios afectados.
Para que veáis el aspecto de una entrada de EventHistoryDB, aquí tenéis una muestra:
De la entrada nos interesan principalmente 4 campos:
- ItemEntryID: Es un identificador del mensaje que aparece a su vez en el MessageTracking, y que va a servirnos como relación entre ambas fuentes de información.
- EventName: Indica la acción que se ha producido sobre el mensaje (en este caso, que se ha modificado).
- ClientCategory: el tipo de cliente que ha realizado la operación (MOMT = Cliente de Outlook).
- DocumentId: Identificador único dentro de EventHistoryDB de un correo (ItemEntryID ya veremos que no es 100% único, así que tendremos que recurrir al DocumentId).
Vamos a coger como elementos de prueba dos mensajes importantes del MessageTracking: el primer mensaje supuestamente enviado por los atacantes, y el mensaje enviado por Alfonso Ferrán que Abelardo Alcázar afirma no haber leído. Extraemos los metadatos y creamos este fichero (hemos eliminado los “-” porque ese es el formato en el que se registran en el EventHistoryDB):
Lo primero que hacemos es un grep básico para verificar que tenemos localizado el ItemEntryID correcto. Y como no podía suceder de otra forma, el comando nos da un resultado nulo. No es la primera vez que el formato del EventHistoryDB nos “alegra el día“… pero esta vez estamos preparados.
Un less del fichero nos indica que contiene caracteres binarios (algo que no le suele gustar NADA a grep), por lo que hacemos una conversión muy sencilla con type, y repetimos la operación logrando localizar nuestro ItemEntryID elegantemente:
Si nos quedamos con la primera ocurrencia, observamos una cosa muy curiosa:
Si nos fijamos en la fecha de creación del evento, comprobamos que fue creado a las 15:56:07 UTC+0. Pero sabemos que el correo se envió a las 16:02:10 UTC+0, así que… ¿qué está pasando aquí?
Muy sencillo: como hemos comentado, EventHistoryDB guarda de forma obsesivo compulsiva TODO el ciclo de vida del correo. Lo que estamos viendo a las 15:56:07 es la CREACIÓN del mensaje de correo (es decir, cuando el atacante ha pulsado en “Nuevo Correo”. Así de minucioso llega a ser EventHistoryDB…
Si buscamos por nuestra hora elegida, comprobamos que en efecto se ha recibido en el Exchange el correo:
Una vez tenemos localizado el correo que queremos examinar, lo más sencillo suele ser recoger el DocumentId y buscarlo de nuevo en todo el fichero (en algunas circunstancias el ItemEntryID puede cambiar, pero el DocumentId permanece siempre constante).
Si examinamos todas las transiciones del DocumentId 14386, nos encontramos con dos que son muy interesantes:
Si os fijáis en el EventName (la acción que sucede) comprobamos que es ObjectMoved. Aquí es cuando recomendamos que aprendáis blasfemias nuevas, porque pasa una cosa muy curiosa: EventHistoryDB tiene un EventName llamado “ObjectDeleted”, que en efecto sirve para indicar que un correo ha sido borrado… pero de la cola de envío, no de un buzón.
El EventName que se emplea para borrar un correo es, como os podréis imaginar… ObjectMoved. La explicación de Exchange para este baile de nombres es que, en realidad, borrar un correo es “moverlo” a la Papelera. Con ese pequeño dato en mente podemos ver desde otra óptica estos eventos, y comprender qué es lo que significan.
Lo que estamos viendo con el primero de los ObjetcMoved es el movimiento a la papelera del correo enviado por los atacantes, y el segundo ObjectMoved constituye el borrado definitivo del correo al vaciar la papelera. Si revisamos el resto de mensajes de la conversación comprobamos que ha ocurrido lo mismo para todos y cada uno de ellos.
¿Por qué han borrado de una forma tan drástica estos correos los atacantes? Muy sencillo: recordemos que todos los dispositivos están sincronizados con Exchange, por lo que cualquier correo acabaría llegando al terminal móvil de Abelardo Alcázar y éste terminaría tarde o temprano leyéndolo. Pero si los atacantes borran el correo del Exchange, esa misma sincronización provocaría que a su vez se borrara del terminal. En resumidas cuentas, lo que están haciendo los atacantes es borrar sus huellas para evitar su detección y ganar tiempo.
Si observamos el correo enviado por el CEO del MINAF (ese que el CEO afirma que no leyó nunca), podemos comprobar que pasa algo parecido:
Aquí se comprueba que el correo ha sido accedido por los atacantes. Unos segundos más tarde, sufre el mismo destino que los correos anteriores:
Si nos fijamos bien, podemos comprobar que no han transcurrido ni 20 segundos desde que el correo ha llegado al buzón de Abelardo Alcázar y los atacantes lo han leído, han comprobado que les perjudica, y lo han eliminado sin miramientos de la bandeja de entrada.
¿Qué nos dice esto? Que los atacantes estaban monitorizando el buzón del CEO del MINAF de forma constante y minuciosa, “censurando” cualquier correo que pusiera en peligro su ataque. Esto indica que los atacantes sabían perfectamente lo que hacían, y que han ejecutado el golpe a la perfección.
Tan solo nos queda un detalle por desvelar del EventHistoryDB: el origen de todas estas acciones. Revisando todos los eventos comprobamos que se han realizado a través del OWA (Outlook Web Access), el webmail de Exchange. Afortunadamente tenemos una buena cantidad de logs del CAS (que recoge también las acciones realizadas a través del OWA), por lo que tenemos material sobre el que trabajar… en el siguiente artículo.
