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

4 de febrero de 2022 Por

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

Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior Ángela había terminado de desgranar todas las acciones de los atacantes, por lo que ya sabía lo que había sucedido realmente y tenía una explicación completa del incidente:

  1. Los atacantes envían un phishing a Pepe Contento, que cae en el mismo e introduce las credenciales.
  2. Leen el correo de Pepe Contento, y no encuentran nada de interés
  3. Crean una app maliciosa en su tenant de Azure y la configuran para que solicite entre otros acceso al correo.
  4. Entran con la cuenta de O365 de Pepe Contento a Teams, y convencen a Inocencio Crédulo para que de permisos a esa aplicación, dando a los atacantes acceso a su correo.
  5. Leen el correo de Inocencio Crédulo y encuentran las credenciales de la cuenta de emergencia.
  6. Inician sesión con la cuenta de emergencia, y despliegan todas las acciones de evasión (usuario administrador global, regla de correo) y de espionaje (permisos sobre los buzones de correo y sitios de Sharepoint).
  7. Desde la cuenta de emergencia, intentan engañar (sin éxito) a la Directora General para que instale un Grunt de Covenant.
  8. La Directora General comparte el documento con uno de sus adjuntos, que poco después lo comparte con el otro adjunto vía O365.
  9. Los atacantes exfiltran el documento del O365 de Pepe Contento, y lo filtran al “Happy Gossipy”.

Sabiendo todo lo que han hecho los atacantes, Ángela puede pasar a la fase de contención y erradicación (que en este caso ocurre de forma simultánea, y según el “método Pelayo”, se realiza con contundencia):

  1. Borramos las cuentas de microsoftsupport y emergencia con extremo prejuicio.
  2. Revocamos los tokens de ambas cuentas con el comando Revoke-AzureADUserAllRefreshToken (mucho cuidado, porque aunque bloqueemos el usuario o cambiemos su contraseña, los tokens ya asignados están activos. Ángela no tiene claro sobre lo que sucede en el caso de cuentas borradas, pero en este caso aplicamos el principio de contundencia y lo hacemos en modo “mejor que sobre que no que falte”).
  3. Deshacemos todos los cambios realizados por los atacantes: eliminamos la app maliciosa, la regla de correo y los permisos sobre los usuarios.
  4. Eliminamos la carpeta de Sharepoint con malware.
  5. Forzamos un cambio de contraseña de todos los usuarios (por si acaso).
  6. Revisamos los IOC obtenidos en el análisis para verificar que no tenemos más contactos con otros equipos de la infraestructura del MINAF.
  7. Creamos el incidente en LUCIA con los IOC y un resumen del mismo.

La fase de recuperación en este caso es muy sencilla, ya que todos los recursos afectados se encuentran en O365 (excepto el equipo de la DG, que tras revisarlo a conciencia no tiene señas de infección, y aunque se recomienda su replataformado la DG lo rechaza).

La semana siguiente el comité de crisis se reúne para evaluar el incidente y las lecciones aprendidas, con los siguientes resultados:

  • La concienciación es necesaria: si Pepe Contento hubiera estado un poco más atento, no habría caído en el phishing que supuso el comienzo del ataque. Aunque como medida única es insuficiente, forma parte imprescindible del conjunto de medidas de seguridad.
  • MFA obligatorio en todos los accesos: todos los controles adicionales a la autenticación siempre complican la vida a los atacantes. O365 soporta MFA (Autenticación de Factor Múltiple), que es similar a 2FA con la única diferencia de que no se limita a un doble factor sino que puede pedir varios factores (app, correo, llamada, SMS) con conjunción.  Además O365 soporta MFA condicional, lo que permite aplicar condiciones a la autenticación (por ej, cuando la IP origen sea la de salida de la Organización no aplicar MFA, o cuando sea un administrador forzar siempre 3 factores de autenticación).
  • O365 te intenta ayudar:  en más de un momento del incidente O365 ha lanzado mensajes de alerta indicando posibles riesgos de seguridad.  Si se hubieran tenido en cuenta esos mensajes el ataque se habría detenido en sus primeras fases.
  • O365 te da información muy útil: los logs de UAL nos ofrecen una gran cantidad de información, con la ventaja de que no pueden ser manipulados (y el problema de que solo se guardan 90 días). El descargar periódicamente esos logs y transportarlos al SIEM permitiría generar reglas que detectaran anomalías con rapidez.
  • Los procedimientos están para cumplirlos: Si Inocencio Crédulo hubiera borrado el correo con las credenciales, o si no hubiera instalado la app maliciosa, o si Pepe Contento no hubiera compartido el documento por O365, los atacantes no habrían podido robarlo. Si se hubieran seguido las buenas prácticas establecidas, el ataque no habría tenido éxito.
  • Los Administradores Globales son muy poderosos: y por ende, deberían de darse a personal con los conocimientos y experiencia necesarios para su buen uso.
  • O365 podría haber evitado la exfiltración: en la licencia de E3 están incluidas políticas de DLP (Data Loss Prevention). Podría haberse creado una política que indicara que los documentos con una serie de palabras clave no pudieran subirse a O365 (evitando de esta forma que el plan de Naciones Unidas estuviera al alcance de los atacantes).
  • Estar en E3 tiene su precio: en el nivel E5 existen una serie de herramientas de seguridad adicionales como las políticas anti phishing mejoradas, el control de aplicaciones con MCAS o los logs de auditoria avanzada (AAL), pero el coste adicional es importante. Se podría plantear un esquema de licenciamiento mixto, en el que algunas cuentas críticas como los altos cargos y el personal de IT tuvieran E5 y el resto de usuarios E3.

La conclusión final de todo el incidente es que, aunque O365 ponga los medios e intente hacerlo fácil, la responsabilidad de la seguridad recae en cada Organización. Configuración segura, mínimo privilegio, concienciación y monitorización son proyectos que debemos abordar si queremos que nuestra experiencia en la nube sea productiva, y sobre todo, segura.