Los peligros de andar por las nubes : DFIR en O365 (III)

N.d.A.: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio. Una breve explicación con algunas notas aclaratorias se puede leer al comienzo del primer artículo.

Recursos: i) vídeo del taller que el autor dio en las XV Jornadas STIC del CCN-CERT, ii) slides de la presentación, iii) evidencias ya trabajadas para poder seguir el caso paso por paso, iv) evidencias en bruto para hacer investigación propia, v) CTF DFIR preparado que va desgranando el caso a medida que se responde a los diversos retos

En el artículo anterior, Ángela acaba de recopilar los datos de O365 del MINAF y toda la información de eDiscover de la Directora General, así que se puede poner manos a la obra. El correo electrónico suele ser una vía de entrada de todos los males, así que lo primero que hace es cargar el buzón de correo con Kernel Outlook PST Viewer. 

Como tenemos un marco temporal sobre el que pivotar (sobre el 18 de noviembre a partir de las 19:00h UTC aproximadamente) y un sospechoso (el usuario emergencia), no cuesta mucho encontrar un correo sospechoso:

Queda claro que emergencia compartió esa carpeta con la DG, pero… ¿se intentó instalar todo eso por ciencia infusa? Parece necesaria alguna interacción necesaria, así que Ángela revisa los mensajes de Teams (que se muestran como .msg separados y pueden ser leídos en un equipo Windows con Outlook, o en Linux con msgconvert o readpst), y pivotando de nuevo sobre el marco temporal no tarda en encontrar un mensaje muy revelador:

Inocencio (o posiblemente alguien haciéndose pasar por él) inicia una conversación con la DG diciendo que debido a unos ataques es necesario instalar una actualización urgente de seguridad (lo que parece ser el Grunt de Covenant), al más puro estilo de las “llamadas del técnico de Microsoft” pero a través de Teams.

La conversación lleva su tiempo, pero al parecer no es fructífera:

[Cómo se hizo]: O365 en este caso avisa a la usuaria de que el fichero Updater.ps1.zip puede tener malware, y además indica que el .bat es sospechoso… lo que no ha impedido su descarga y ejecución.

A primera vista parece que el equipo de la DG no ha sido comprometido, pero entonces … ¿de dónde han sacado los atacantes el documento? Ángela revisa el correo y los mensajes de la DG, y no tarda en encontrar una respuesta en una combinación de correo y Teams:

La DG envió un correo a Pepe Contento (uno de sus adjuntos), y el día 19 lo compartió con él en su servidor seguro, por lo que ya tenemos una prueba de que el documento existía en el equipo de pepe.contento. Ángela podría obtener unos datos de triage del equipo de pepe.contento, pero viendo la implicación de O365 le interesa más seguir esa línea de investigación, así que realiza otro volcado de eDiscover de su cuenta.

Un análisis preliminar de los datos permite encontrar el documento en la carpeta personal de Sharepoint del usuario:

Está claro que pepe.contento ha subido el documento a O365 (en clara violación de las políticas de seguridad establecidas). Si analizamos los correos y mensajes de Teams de pepe.contento encontramos la razón:

Franchesco Fiestas (el otro adjunto de la DG) le ha pedido a Pepe Contento que le comparta el documento por OneDrive para poder acelerar el papeleo, y al final lo ha convencido porque lo hemos visto colgado en el espacio del usuario. Ángela se plantea la siguiente hipótesis: si el documento estaba en O365, y los atacantes tenían una cuenta con permisos de Administrador Global, lo han podido descargar de O365.

Llega el momento de sacar los logs de UAL y buscar por la opción de “File Downloaded”, que rápidamente despeja nuestras dudas:

Ni un cuarto de hora han tardado los atacantes en descargarse el documento desde que Pepe Contento lo sube a su OneDrive (de hecho lo descargan antes de que lo haga Franchesco Fiestas). Un detalle muy interesante de los logs de UAL es que no solo indican qué usuario realizó la acción, sino también desde qué dirección IP se realizó, en este caso:

La dirección IP 20.190.160.24 constituye otro IOC, este altamente pivotable porque asumimos que los atacantes habrán realizado más acciones. Sin embargo, Ángela decide abrir el foco y recopilar todas las IP en las que ha estado involucrado el usuario emergencia (recordemos que es un usuario para emergencias, así que a priori todas las acciones y direcciones IP son sospechosas). Un poco de grep en Linux nos da la respuesta:

[Nota del autor: En Windows la mejor forma de trabajar con los logs de UAL (que son un engendro demoníaco mitad .csv, mitad JSON) es empleando Excel 2016+ y la funcionalidad de Power Query]

Sin embargo, cuando geolocalizamos estas direcciones IP, todas nos salen relativas a Microsoft:

Y si las buscamos en los logs de UAL, varias de ellas han sido usadas por usuarios del MINAF por lo que esta vía de investigación no nos ofrece resultados claros (como suele ser habitual en otras investigaciones de O365, ya que el combo de “Geolocalizar IP + horarios extraños” suele ser muy potente).  Ángela decide centrarse en las acciones de la cuenta de emergencia, y analizar con detalle todo lo que han hecho. En un análisis cronológico inverso, la primera acción antes de la descarga del documento confidencial se ve clara:

En Sharepoint los sitios personales son privados para cada usuario… pero un administrador global puede conceder permisos, que es justo lo que han hecho: se han dado permisos a ellos mismos sobre los sitios de María José Feliz y Pepe Contento, teniéndolos monitorizados y siendo este el motivo por el que lo descargaron con tanta rapidez una vez Pepe lo subió. 

El que hubieran sabido con tanto acierto qué sitios monitorizar hizo pensar a Ángela que los atacantes se habían dado permisos sobre el correo (si recordamos, María José Feliz envió un correo a Pepe Contento diciendo que ya tenía el documento). Revisando la acción “Add-MailboxPermission”, Ángela encuentra rápidamente lo que ya sospechaba:

Los atacantes se han dado permisos de acceso completo a la cuenta de la DG, la de Inocencio Crédulo… y la suya. Está claro lo que los atacantes tenían en mente: monitorizar los correos del personal de O365 y de Seguridad para tener una alerta temprana en caso de que detectáramos su intrusión.  Otra táctica muy frecuente de los atacantes es desplegar una regla de correo que impida la recepción de mensajes “inconvenientes”. Si se busca por la acción “New-TransportRule”, se observa que los atacantes no están dejando cabos sueltos:

Básicamente lo que dice la regla es “Si el asunto o el cuerpo del mensaje tienen las palabras ‘seguridad,hacking o security’, bórralo directamente. Y desplegada para todo el MINAF, sin tonterías.

Buscando en los logs de UAL, Ángela encuentra cerca de los permisos de correo otra acción de los atacantes muy interesante y en la que no había pensado:

Lo que han hecho los atacantes es dar al usuario emergencia los permisos necesarios para enviar correo como el usuario inocencio.credulo. De esta forma el From de los correos será el de este usuario, algo que daría mucha más confianza a los receptores. Bien jugado, atacantes, pero no lo suficiente.

Pensando como un atacante, Ángela cree que una de las primeras acciones que haría si entrara en una infraestructura sería la de darse persistencia, en este caso creando un nuevo usuario. Buscando en los logs las acciones relacionadas con nuevos usuarios, le cuesta poco encontrar una cuenta de usuario recientemente añadida:

No hace falta decir qué permisos tiene la nueva cuenta “microsoftsupport”, ¿verdad? Llegados a este punto, a Ángela solo le queda saber cuándo empezó el compromiso de la cuenta emergencia. Buscando en los logs de UAL por la acción “UserLoggedIn”:

Por lo menos los atacantes no parecen llevar varios meses dentro del MINAF (por ahora). Hasta el momento el incidente parece claro: los atacantes se han hecho de algún modo con la cuenta de emergencia, han desplegado varias acciones de monitorización y evasión, han intentado engañar a la DG para que instalara malware en su equipo sin éxito y finalmente han conseguido documento por un descuido de Pepe Contento.

En este punto Ángela tiene que tomar una decisión importante: los atacantes tienen control de dos cuentas con permisos de administrador global del O365 del MINAF, lo que les pemite hacer lo que quieran con los recursos existentes. Una opción sería la de bloquear el acceso a las cuentas (algo que ella puede hacer ya que también tiene privilegios de administrador global), pero ello podría alertar a los atacantes (y todavía no sabe a ciencia cierta si los atacantes han dejado otros “regalitos”). Sin embargo, el dejar a los atacantes campar a sus anchas tampoco es algo que apetezca en exceso.

¿Qué decisión es la correcta? La que diga el comité de crisis, ya que este es un claro ejemplo de “apetito del riesgo” de la Organización, en la que es necesario tomar una decisión con una visión estratégica. Afortunadamente el comité confía en Ángela, y la “vía Pelayo” de “aprende todo sobre los atacantes, planifica concienzudamente tu contraataque y echalos con contundencia extrema. Con el beneplácito del comité, Ángela continua la investigación. Quedan todavía muchas incógnitas por resolver, siendo la primera encontrar cómo los atacantes se han hecho con la cuenta de emergencia.  En el siguiente artículo veremos lo que se encuentra…

La entrada Los peligros de andar por las nubes : DFIR en O365 (III) aparece primero en Security Art Work.