Habíamos dejado el artículo anterior con muchas lagunas en la cobertura de correo tanto del CEO como del CFO del MINAF. Una primera (y sobre todo, rápida) solución es recurrir a los logs de MessageTracking. Como ya hemos comentado, el MessageTracking es un log de alto nivel de Exchange que nos ofrece unos datos básicos del mensaje (origen, destino, fecha, asunto) junto con algunos identificadores de bajo nivel (de los que contaremos algo en su momento ya que van a ser fundamentales en nuestra investigación).
Para que os hagáis una idea, este es el aspecto que tiene un log de MessageTracking que hemos adecentado mínimamente:
Si abrimos el log y le echamos un vistazo rápido, encontramos una oleada de mensajes (cerca de 1000) bastante preocupantes:
Al parecer alguien ha ordenado el borrado remoto del terminal móvil de Abelardo Alcázar, algo que se puede realizar sin problemas desde Exchange si el terminal está configurado correctamente (y que es muy útil en caso de robo o pérdida del mismo, ya que no requerimos de tener una solución de gestión remota de terminales móviles o MDM). Este log concuerda con lo manifestado por Abelardo Alcazar, coincidiendo a su vez en fechas (recordad que en España en verano estamos en UTC+2, por lo que las 18.47h UTC se convierten en las 20.47h hora española).
Nos apuntamos este detalle y vamos a intentar localizar en el log los correos supuestamente enviados el 7 de junio. Y en efecto, parece que sí que han pasado por el Exchange:
(Ojo, en este caso las fechas están en hora española, o sea UTC+2). Si nos fijamos con un poco de cuidado, podemos ver la cadena de mensajes iniciada por el CEO a las 18:02:01 con el CFO, que termina a las 18:19:08 (los mensajes en amarillo). Abelardo Alcázar afirma que él no envió esos mensajes.
Sí que afirma enviar el mensaje en naranja, que según sus palabras fue para informar a Alfonso Ferrán del cierre del acuerdo en términos satisfactorios. La respuesta de Alfonso (en rojo, enviada a las 20:45:25) nunca fue recibida por Abelardo Alcázar (posiblemente porque en ese momento su terminal estaba siendo borrado remotamente).
Está claro que tenemos que tener acceso a esos correos “fantasma”, y que de poco nos van a servir los buzones obtenidos de los portátiles de los usuarios. Afortunadamente para nosotros, tenemos un as en la manga: hemos recuperado los buzones directamente del Exchange. Y no solo eso, sino que al exportarlos del Exchange nos hemos hecho con la carpeta de “Elementos Recuperables”.
Todo el mundo sabe que, cuando se mueve un fichero a la papelera, este puede ser recuperado de la misma sin problemas. Y que cuando se vacía la papelera, el fichero se ha borrado de forma definitiva (aunque si no se ha usado un programa de borrado seguro, los forenses ya sabemos que tenemos herramientas para que no sea tan “definitiva”).
En Exchange pasa algo similar: un usuario puede mover un correo a la papelera de su cliente y recuperarlo sin problemas, pero cuando se vacía la papelera el usuario ya no tiene acceso a los mismos (con el extra de que, dado que es habitual tener el correo sincronizado con Exchange este cambio se aplica al resto de dispositivos del usuario).
Lo que ya no es tan de dominio común es que Exchange crea para cada usuario una carpeta denominada “Elementos Recuperables”, accesible únicamente por el administrador de Exchange… y que guarda TODO lo borrado por el usuario: correos, contactos, citas, etc… durante un máximo de 14 días o 30Gb (lo que suceda antes).
Al exportar el buzón desde el Exchange, nos hemos hecho con esa carpeta, por lo que podemos abrirla con Kernel Outlook PST Viewer… y destapar todo el pastel. En primer lugar, comprobamos que en efecto todo el intercambio de correos entre la cuenta del CEO (vamos a creer por ahora a Abelardo Alcázar) y la del CFO existieron y fueron deliberadamente borrados y la papelera vaciada:
El intercambio de correos es como ver un choque de trenes a cámara lenta: sabes desde el primer momento lo que va a pasar, y no puedes hacer nada para evitarlo. En el primer correo, directamente la petición de una transferencia internacional (haciendo referencia a una cuenta denominada COBALTO, algo al parecer interno a la compañía):
El CFO contesta inquieto por la magnitud de las transferencias:
La respuesta es casi inmediata y tajante:
El CFO sigue poniendo pegas a las transferencias:
Al parecer COBALTO parece una cuenta “especial” usada en el MINAF para asuntos “especiales”. Como no somos auditores jurados de cuentas, ni hay prueba flagrante de delito, no es asunto nuestro. Lo que si nos interesa es la respuesta tajante y decisiva:
El CFO al final claudica y realiza las transferencias:
Y recibe un sucinto mensaje de agradecimiento:
Nos queda totalmente claro lo que ha sucedido, pero solo nos queda ver el desenlace de la tragedia, cuando Abelardo Alcázar envía el mensaje de “todo OK”:
Y la respuesta al borde del pánico del CFO, que Abelardo Alcázar afirma que nunca leyó:
Con estos correos tenemos una hipótesis de trabajo razonable: los atacantes han logrado acceder al correo del CEO del MINAF, y es más que probable que hayan estudiado su correo y agenda, en busca de la oportunidad adecuada para asestar su golpe.
El análisis del resto de correos del buzón del CEO permite establecer estas conclusiones adicionales:
- Existen correos anteriores que hacen referencia a una cuenta bancaria denominada COBALTO. Esta cuenta parece haber sido empleada para hacer transferencias que podrían parecer “cuestionables”.
- Existen correos que hablan de las negociaciones con Coltanistán, y del viaje a Estambul.
- Los atacantes han modelado sus correos con el estilo de Abelardo Alcázar, copiando su firma y escribiendo con un lenguaje escueto y directo.
Los buzones de Exchange nos han desvelado una parte de lo sucedido. Pero si queremos obtener más información del incidente, tendremos que bucear en los misterios del EventHistoryDB … en el siguiente artículo.
Esto es como juego de tronos. Espero al siguiente con ganas