Los que trabajamos en respuesta ante incidentes y forense siempre deseamos que todos los atacantes hicieran como aquél famoso monólogo de Gila, y avisaran antes de hacer sus maldades. Lo deseamos junto con el Lamborghini, el yate y el unicornio con arcoíris de fondo, y solemos obtener la misma respuesta en casi todos los casos: un mojón. En algunos casos, dos.
“Qué putada es tener un incidente a las 14.55h de un viernes”, pensaréis. Pues hay cosas peores: por ejemplo, que te llame tu jefe a las 15.00h de un sábado mientras estás durmiendo la siesta (después de haberte metido entre pecho y espalda una fideuá de carne de infarto), y te diga “agarra la maleta de incidentes que nos vamos de fiesta”.
En este caso, la fiesta consiste en cerca de 4h de viaje desde Madrid hasta Ponferrada, donde está situada la sede del MINAF (Minerías Alcázar y Ferrán), una empresa minera que no os sonará de nada, pero que factura más de 40 millones de euros y opera en 12 países.
Su problema es bien sencillo: ayer desaparecieron 100.000€ de sus cuentas bancarias. Lógicamente, están ligeramente preocupados y desean que realicemos una investigación interna antes de denunciar lo ocurrido ante las FCSE.
Hablamos tanto con Abelardo Alcázar (CEO del MINAF) como con Alfonso Ferrán (CFO del MINAF) y logramos conformar la siguiente línea de eventos:
- MINAF lleva meses en negociaciones con el gobierno de Coltanistán (una ex república soviética situada en Oriente Medio) para cerrar un acuerdo para explotar una de las mayores minas de coltán del mundo.
- Las negociaciones estaban en buen rumbo, y el CEO del MINAF viaja a Estambul el 7 de junio para afinar los últimos detalles y firmar el contrato.
- Abelardo Alcázar aterriza en el Aeropuerto Internacional Sabiha Gökçen a las 13.00h, y está en el hotel Ritz-Carlton a las 13.45h. A las 14.30h, después de un ligero refrigerio, comienzan las negociaciones finales.
- A las 18.00h Alfonso Ferrán recibe una serie de correos electrónicos de Abelardo Alcázar, instándole a que realice un conjunto de transferencias internacionales por valor de 100.000€.
- Sobre las 18.30h Alfonso Ferrán realiza las transferencias.
- Alrededor de las 20.30h Abelardo Alcázar finaliza las negociaciones con el gobierno de Coltanistán y envía un correo electrónico a Alfonso Ferrán comentando que todo ha salido como se esperaba.
- Alfonso Ferrán responde interesándose por las transferencias, pero Abelardo Alcázar asegura no haber recibido ese correo (ni obviamente haber demandado esas transferencias). Afirma que sobre las 20.45h del 7 de junio su teléfono empezó a “hacer cosas raras” y se borró su acceso al correo, así como todos sus contactos.
- Alfonso Ferrán intenta localizar a Abelardo Alcázar el viernes sin éxito. Cuando éste regresa a España al día siguiente sobre las 14.00h, logra ponerse en comunicación con él y se descubren las transferencias fraudulentas.
- Se declara incidente de seguridad a las 14.30h, y el CEO del MINAF entra en contacto con nosotros y solicita nuestra ayuda.
La ciberseguridad del MINAF es bastante razonable, teniendo en cuenta que es una PYME de 100 empleados con 2 informáticos: todos los equipos tienen antivirus y tienen las actualizaciones de seguridad al corriente. Se tienen logs tanto del correo como de la navegación, y se está comenzando un plan de concienciación en ciberseguridad para todos los empleados. Un nivel bastante superior a la media que estamos acostumbrados a encontrarnos, la verdad.
Aunque el caso huele a una estafa al CEO, no debemos cerrarnos a ninguna posibilidad. No va a ser la primera vez que algún avispado intenta hacer un “el perro se comió mis deberes” a la empresa, la aseguradora o incluso a los jefes/socios de la empresa. Es nuestro deber actuar de manera completamente imparcial y recabar todas las evidencias posibles para resolver el caso de la forma más clara posible.
Una de las cosas buenas de los incidentes es que todo lo que pides (menos el unicornio) te lo dan prácticamente al momento. En menos de 5 minutos tenemos delante los portátiles tanto del CEO como del CFO del MINAF, y un técnico nos facilita la cuenta de administrador local para que podamos lanzar rápidamente tanto una captura de memoria RAM con winpmem como un triage de datos con CYLR.
Dado que estamos tratando con un caso en el que el correo electrónico es crítico, vamos a arrancar los equipos con un LiveUSB de DEFT Linux (una distribución de Linux orientada al forense), montar el disco duro del portátil en modo solo lectura, y a obtener la carpeta de Outlook de ambos equipos, situada en:
C:\Users\abelardo.alcazar\AppData\Local\Microsoft\Outlook\
Los portátiles quedan bajo nuestra custodia por si fuera necesario realizar una imagen forense (ahora mismo, sin saber lo que ha pasado, es mejor dedicar los esfuerzos a obtener más información sobre el incidente).
Y en este caso vamos a intentar ir un poco más allá en la obtención de evidencias del correo. MINAF tiene su correo en un servidor Exchange 2010 en un VPS de un ISP mediano, pero que les facilita acceso de administrador sin problemas. Junto con una de las informáticas del MINAF, nos conectamos por Escritorio Remoto y hacemos una evaluación de las evidencias que queremos recoger.
En un principio querríamos cuatro tipos de evidencia (si están disponibles). De más alto a más bajo nivel podemos obtener:
- Buzones de correo: Cuando tenemos un Exchange lo normal es que los clientes tengan el buzón sincronizado contra el servidor (en este caso al menos, así es). Podremos entonces obtener el buzón directamente del Exchange con un poco de maña (y sobre todo, un poco de Powershell):
- Logs del CAS: Exchange tiene un frontal que gestiona todos los accesos al servidor, que se denomina CAS (Client Access Server). En el CAS tendremos todos los accesos realizados desde los clientes, desde el OWA hasta los clientes de Outlook (además de todos los terminales móviles corporativos). Por suerte, el CAS en realidad tiene por debajo corriendo un IIS, por lo que tendremos todos los logs en la carpeta: C:\inetpub\logs\LogFiles (y los logs tienen un formato en texto ya conocido, lo que hará muy fácil tratarlos).
- Logs de MessageTracking: El MessageTracking es un log de alto nivel que nos permite obtener los metadatos básicos de un correo (origen, destino, fecha de envío, asunto, etc…), algo que nos puede ser muy útil para tener una visión rápida de los correos. Por defecto se guardan los últimos 30 días, pero nunca está de menos comprobar el estado en el servidor con una consulta rápida:
En efecto, tenemos el valor por defecto así que podemos operar y recoger los últimos días del tracking de correo con otra consulta de Powershell:
- Logs del EventHistoryDB: El EventHistoryDB es el log de más bajo nivel de Exchange accesible, y guarda con atención obsesiva una cantidad ingente de datos sobre la vida y milagros de un correo. ¿Quieres saber cuándo se recibió un correo? ¿A qué hora lo abrió? ¿Si lo borró sin haberlo leído? EventHistoryDB te responde a todas esas preguntas (y alguna más). La pega es que por defecto solo guarda 7 días de logs. Comprobamos que se mantiene el valor por defecto:
Volvemos a tener los valores por defecto. En este caso el MINAF ha sido rapidísimo en detectar el problema y contactar con nosotros, ya que apenas han transcurrido 24h desde el incidente y podemos recuperar esta información con un par de comandos de Powershell:
Son casi las 21.00h cuando terminamos de realizar todas las adquisiciones. Dejamos una copia de todas las evidencias en manos del MINAF (les hará falta para la denuncia posterior) y, aunque Ponferrada es bien bonito, decidimos, en lugar de hacer noche, volvernos a Madrid para poder empezar el domingo a hacer el forense en un estado razonable…
Y en efecto, el domingo a las 09.00h, con algo más parecido a un pozal que a una taza de café, comenzamos el análisis forense. Lo primero es comprobar que tenemos todas las evidencias como es debido, así que calculamos los hashes con HashMyFiles:
F********!!!! El hash del fichero MINAF-PC1_Outlook.zip (el correo del CFO, Alfonso Ferrán) no concuerda con el que habíamos recogido en la ficha de adquisición de evidencias. Dado que el USB no ha salido en ningún caso de nuestras manos es imposible que lo hayan manipulado… pero puede haberse producido algún problema con el USB que haya afectado al fichero.
No es un problema grave porque el MINAF guarda los originales en su caja fuerte, pero no podremos disponer de esa evidencia hasta el lunes. Tendremos que ser creativos y ver cómo podemos sortear esta carencia de información en nuestra investigación.
Vamos a empezar con el correo del CEO, Abelardo Alcázar. Dado que tenemos su buzón de correo sacado del equipo (y recordemos que como está sincronizado con el servidor, en un principio debería ser el mismo en todas partes), vamos a abrirlo con Kernel Outlook OST Viewer y a echarle un ojo:
Mmm… aquí no aparece en la carpeta de “Enviados” ningún correo del 7 de junio. Y tampoco tenemos nada en la papelera de Outlook. Vamos a ver qué dice el correo del CFO, Alfonso Ferrán:
Ya tenemos claro porqué los hashes no coinciden: el fichero se debió copiar mal, o tenemos un fallo en el USB, porque el fichero está corrupto.
Para avanzar un poco más en el análisis vamos a consultar los logs de MessageTracking, pero eso será en el siguiente artículo…
