En el artículo anterior habíamos visto cómo los atacantes habían estado monitorizando y manipulando a su antojo el correo del CEO del MINAF… y que lo habían hecho a través del OWA (Outlook Web Access), el webmail de Exchange.
Para saber cómo funcionan estos logs, tenemos que ver cómo funciona Exchange. Si lo simplificamos mucho, Exchange tiene dos componentes principales: CAS (Client Access Server) y DAG (Database Availability Group), que serían aproximadamente equivalentes al servidor web y a la base de datos de una aplicación web.
El CAS (que en realidad es un IIS, el servidor web de Microsoft), se encarga de toda la interacción con los clientes, ya sea a través de un cliente Outlook de escritorio, OWA o ActiveSync (el protocolo empleado para los móviles).
Los logs del CAS son siempre buenas noticias: no tienen periodo de retención (se guardan por defecto, así que hasta que el disco aguante). Hemos visto con gozo equipos con 5+ años de logs del CAS, el formato es bastante estándar (logs de IIS, muy bien documentados), y son de alto nivel (razonablemente fáciles de interpretar).
Dicho esto, vamos al tajo. En primer lugar vamos a localizar un correo que sepamos a ciencia cierta que ha sido enviado por el CEO del MINAF, como puede ser el que envió con su móvil al CFO el día de autos indicándole que las negociaciones habían llegado a buen puerto. Tras revisar con cariño los logs, aquí lo tenemos:
Este correo tiene una serie de marcadores que nos hacen pensar que es auténtico:
- Se está haciendo uso de ActiveSync (ha sido enviado por un terminal móvil)
- El User-Agent es Android-Mail/7.5.7.156101332.release (coherente con Android 8.1, SO de los S9 corporativos del MINAF)
- La IP origen es la 10.11.0.210 (la que ofrece el cliente VPN instalado en los terminales corporativos del MINAF).
En cambio, si revisamos el primero de los correos maliciosos comprobamos que tenemos una situación bastante diferente:
Si nos fijamos con cuidado observamos las diferencias:
- El acceso se está haciendo vía OWA en lugar de ActiveSync.
- El User-Agent es Mozilla/5.0+(Linux;+Android+7.0; +PLUS+Build/NRD90M) +AppleWebKit/537.36, lo que investigando un poco resulta ser un Chrome con alguna extensión que permite falsificar el User-Agent (para que una revisión somera de los logs identificara estos accesos como de móviles).
- La IP origen es la 101.132.122.100, que un poco de geolocalización sitúa en China (posiblemente un proxy empleado por los atacantes para ocultar su origen).
Si pivotamos un poco sobre esta IP que acabamos de encontrar obtenemos una interesante cantidad de contactos:
Estos logs, si sabemos interpretarlos, cuentan una historia con detalle. A las 15:04:12 UTC los atacantes inician sesión en el OWA con las credenciales del CEO del MINAF, y están accediendo de forma constante al correo. Se observa cómo se produce el envío de los correos maliciosos y se continua la monitorización del correo, terminando con la orden de borrado del correo remoto al ver los atacantes que el CFO del MINAF había visto que algo andaba mal.
El ataque se ha realizado como un reloj. Pero, por muy buenos que fueran los atacantes, es imposible que pudieran armar el ataque con tan poca preparación (y que tuvieran tanta suerte como para entrar cuando entraron). Todo indica que los atacantes lograron acceder a la cuenta del CEO al menos con varios días de antelación, así que vamos a ver si somos capaces de localizar el primer contacto de la IP maliciosa.
El resultado es muy interesante:
Si observamos atentamente los logs podemos ver que ninguno de los accesos ha sido exitoso: lo que podemos vez es una mezcla de códigos de resultado 401 (No autorizado) y de enlaces del owa con “reason=2” (contraseña no válida).
Estos accesos fallidos se repiten varias veces a lo largo de varios minutos, y si miramos el User-Agent podemos ver que es PowerShell. Si tuviéramos que apostar algo diríamos que es un ataque de fuerza bruta o de password spraying (probar una misma contraseña contra múltiples cuentas, para de estar forma no bloquear las cuentas tras varios intentos fallidos).
La segunda parte de los accesos fallidos tiene otro perfil:
El tiempo entre peticiones parece más aleatorio, menos rítmico (como si hubiera una persona detrás de los accesos), y el User-Agent en este caso es justo de una versión reciente de Chrome. Podría ser uno de los atacantes probando contraseñas de forma manual (habría que comprobar si existen direcciones de correo del MINAF en servicios como HaveIBeenPwned o similares).
Si seguimos buscando en los logs al final nuestra paciencia encuentra recompensa: el 6 de junio los atacantes logran iniciar sesión correctamente en el equipo:
Después de ese login correcto, los atacantes se dan un verdadero festín leyendo TODO el correo del CEO del MINAF (suponemos que en esa lectura reconocen la oportunidad de Estambúl, la existencia de COBALTO y el estilo de escritura del CEO).
Lo interesante es lo que sucede justo antes de ese inicio de sesión ¿Y qué vemos según los logs? NADA. El acceso de los atacantes se ha producido de forma directa, sin titubeos ni errores. Una de las máximas del análisis forense es “la ausencia de evidencia también es evidencia”. Es necesario que investiguemos qué ha podido pasar para que los atacantes pasen de intentos de acceso por fuerza bruta a una entrada limpia a la primera.
Los sospechosos habituales en estos casos son tanto el correo como la navegación, y afortunadamente tenemos esos datos entre la exportación de los buzones y la recogida del triage con CyLR.
Empecemos con el análisis del correo. La verdad es que da un poco de cosa no haberlo visto antes, porque este correo resulta ser bastante obvio:
Los atacantes han enviado un spear-phishing dirigido el CEO con información de su interés directo (en su perfil de LinkedIn aparece indicado que es un apasionado del golf, y entre las entidades a las que sigue está la Federación de Golf de Madrid).
Y, si correlamos la hora a la que se recibió el correo con la del primero acceso de los atacantes (recuerda que los logs del CAS son UTC+0, y los de Kernel Outlook PST Viewer los del sistema, UTC+2 por lo que tenemos dos horas de diferencia), casi ni hace falta revisar los logs de navegación del CyLR:
Estos logs nos dan la crónica de una tragedia anunciada. Aproximadamente cinco minutos después de recibir el correo, Abelardo Alcázar visita la web:
que por desgracia NO es la web de la Federación de Golf de Madrid:
…y en menos de 10 minutos tenemos a los atacantes accediendo al correo de Abelardo Alcázar. El motivo parece simple: el reuso de credenciales por parte del CEO, aplicando la misma contraseña de uso corporativo en otros sitios de menor importancia.
Con toda esta información podemos generar una línea temporal de eventos con todo lo sucedido:
- Los atacantes realizan el 5/Jun varios ataques contra cuentas de correo del MINAF.
- El dia 6/Jun lanzan un spear-phishing dirigido al CEO según sus gustos sociales.
- Poca superficie de ataque y dirigido OSINT previa por parte de los atacantes.
- El CEO cae en el spear-phishing y reusa credenciales, dando a los atacantes acceso a su cuenta de correo.
- El 7/Jun, entran a la cuenta simulando ser un Android y envían un correo al CFO, solicitando una serie de transferencias.
- Aprovechan la no disponibilidad del CEO (en las negociaciones).
- Hacen uso de conocimiento previo –> Lectura del correo por parte de los atacantes.
- Borran los correos al enviarlos para que el CEO no los lea en el terminal móvil.
- Vacían la papelera al terminar los envíos.
- Monitorizan la cuenta en busca de posibles correos.
- Borran la respuesta del CFO al CEO.
- Realizan un borrado remoto para ganar tiempo.
- Ejecución limpia y casi sin fisuras –> Grupo de atacantes profesionales.
El análisis del incidente permite determinar todos los puntos necesarios en una respuesta ante incidentes:
- Punto de entrada empleado por los atacantes (correo electrónico)
- Ataque realizado (spear-phishing dirigido)
- Movimientos realizados dentro del sistema (acceso al correo)
- Equipos afectados (realmente, ninguno)
- Información afectada (credenciales del usuario, correo)
- Marco temporal del incidente (6-7 de junio)
- Objetivo de los atacantes (realizar una estafa al CEO)
- Impacto causado (pérdida de 100k€)
Si algo positivo podemos sacar del incidente, es que es poco probable que los sistemas de información del MINAF estén comprometidos. El marco temporal del incidente (menos de dos días) y las acciones realizadas por los atacantes (limpios y eficientes, da a entender que no es la primera vez que hacen) indican que probablemente se dediquen únicamente a este tipo de ataques.
El incidente deja las siguientes lecciones aprendidas (aunque en este caso el coste de las mismas sea más bien elevado):
- Usa doble factor de autenticación: el uso de 2FA (a ser posible con un token físico como una Yubikey, o una app como Google Authenticator, el SMS debería de estar en desuso) habría evitado que los atacantes, aun teniendo credenciales válidas, hubieran podido acceder a la cuenta del CEO del MINAF.
- Guarda los logs: en este caso el MINAF se dio cuenta al momento, y se pudieron recuperar varios logs que fueron muy relevantes para resolver el incidente. El plantearse ampliar el periodo de retención de algunos logs (como el de “Elementos recuperables” de Exchange) es una idea muy interesante, siempre en función de los recursos disponibles.
- Reacciona con rapidez: en el momento que se detecta el incidente, es necesaria una respuesta inmediata. Contactar con el banco e intentar paralizar las transferencias es la primera acción a realizar. La segunda: busca a unos especialistas en respuesta ante incidentes y/o realizar una denuncia ante las FCSE.
- Conciencia a tus usuarios: los usuarios necesitan comprender la importancia de la ciberseguridad, porque son parte integral de la misma. Si el CEO del MINAF no hubiera caído en el spear-phishing, y sobre todo, si no hubiera reusado credenciales, el ataque no se habría producido. La ciberseguridad no es una tarea de IT: es de toda la organización.
- Controla el dinero: establece procedimientos y controles estrictos para toda transacción que supere un límite. Firmas previas, doble autorización, confirmación de las cuentas empleadas (y una forma blindada para los cambios de cuentas corrientes, otro ataque muy frecuente empleado por los cibercriminales).
En nuestro caso práctico el dinero nunca fue recuperado (en la mayoría de los casos nunca se recupera). Después de la charla de la c1b3rwall estuvimos hablando con varios miembros de las FCSE que nos confirmaron lo frecuente de estos ataques, y de la gravedad de los mismos. Como muestra, dos casos tratados el último año:
- Empresa a la que le hicieron prácticamente paso por paso lo ocurrido en nuestro caso práctico, pero en esta ocasión fueron varios cientos de miles de euros. Se salvaron in extremis porque el banco observó que el importe de la transferencia era inusual y decidieron esperar al día siguiente para confirmarla.
- Empresa con múltiples relaciones comerciales con China: en este empresa manejan facturación de forma frecuente con China. Los atacantes penetraron en el correo de la empresa china y solicitaron un cambio de cuenta bancaria en ambos extremos, estafando a ambas partes durante casi dos meses (y con un montante de varias decenas de miles de euros).
Este tipo de ataques está a la orden del día, y es muy empleado por los cibercriminales por su bajo coste y exposición (el dinero transferido a esas cuentas es rápidamente redistribuído a través de muleros, por lo que el seguimiento es muy complicado o directamente imposible), y sobre todo por su alto beneficio.
La solución pasa por incrementar la postura de seguridad de la organización (o como predica acertadamente el CCN-CERT, “trabaja como si estuvieras comprometido”). Con tanto cibercriminal ansioso por meterle mano a vuestra cartera, es la única alternativa posible…
