Volvemos a la investigación del incidente examinando lo que nuestra compañera había encontrado en los logs del OWA. Si recogemos todos los accesos realizados desde las dos IP con el User-Agent de Firefox, encontramos varios patrones de interés:
- Patrón 1: Acceso directo: Se observa en los logs cómo los atacantes acceden a la página de login, y luego a la pantalla principal del correo.
- Patrón 2: Accesos incorrectos: Los atacantes acceden a la página de login, pero la contraseña es incorrecta (observamos repetidos intentos de inicio de sesión, como si estuvieran realizando un ataque manual de fuerza bruta).
- Patrón 3: Accesos incorrectos + correcto: En un caso específico comprobamos como los atacantes realizan varios intentos de inicio de sesión y al quinto logran entrar.
Este último patrón es el más curioso ¿Cómo han podido los atacantes extraer las contraseñas de un usuario (que son robustas al tener 12 caracteres y forzada la complejidad) en unos pocos intentos?
Solicitamos a Sistemas los logs de los últimos meses, y buscamos la actividad maliciosa que tenemos perfectamente localizada gracias a la combinación de User-Agent y direcciones IP. El análisis de los logs nos permite comprobar que ese comportamiento se repite al milímetro en el resto de usuarios:
- Los atacantes a partir de un tiempo T logran entrar en el correo del usuario.
- T+n días más tarde (con n<30 días) los usuarios pierden el acceso (suponemos que porque el sistema obliga a cambiar la contraseña con periodicidad mensual).
- En el mismo día T+n los usuarios realizan varios intentos de login, y con menos de 20 intentos consiguen volver a acceder a la cuenta del usuario.
Tenemos una teoría de lo que está pasando, pero necesitamos contrastarla con una prueba empírica. Volvemos a hablar con nuestro paciente cero y le pedimos amablemente que cambie su contraseña por una totalmente distinta y que nos proporcione la antigua. La respuesta confirma nuestras sospechas:
PepeNoviembre2017
Con estas premisas, no hace falta ser un genio para saber la contraseña del usuario del mes pasado… ni la del mes que necesitemos. Y lo mejor de todo es que es una contraseña que cumple con la política establecida en el dominio Windows: tiene 17 lustrosos caracteres, mayúsculas, minúsculas y números. Y una vez los atacantes se han hecho con una de estas contraseñas con patrones, pueden seguir accediendo al sistema hasta el fin de los días.
Hablando con los otros usuarios afectados se confirman los hechos: todos empleaban patrones de contraseñas con un alto grado de reutilización, lo que hacía muy sencillo para los atacantes recuperar la nueva contraseña con un mínimo número de intentos.
Una vez entendidos todos los factores que han producido el incidente, podemos pasar a la fase de recuperación. En primer lugar, es necesario estimar el impacto sufrido por la Organización. Por lo que hemos extraído del análisis de los logs, los atacantes han tenido acceso a 4 buzones de usuario de la Organización durante un periodo aproximado de entre quince días y mes y medio, plazo durante el cual han tenido acceso a todo el correo del buzón de entrada.
En el lado positivo, los atacantes no han podido acceder a los correos archivados (que se guardan en .pst locales), ni tampoco a los correos borrados dentro del horario laboral (ya que los atacantes actuaban fuera del horario laboral para no despertar sospechas).
El análisis de los equipos no ha detectado ningún malware, y el análisis del Exchange parece indicar que está limpio, por lo que el incidente parece estar limitado a los accesos a los buzones de correo. María recuerda que hace tres meses la Organización sufrió un ataque de phishing muy dirigido relativo a la prestación del seguro médico, en el que probablemente puedan haber caído una buena parte de usuarios. Este ataque podría explicar la obtención de credenciales por parte de los atacantes.
Una vez resuelto el incidente, podemos pasar a las lecciones aprendidas, que en este caso son las siguientes:
Revisa el perímetro
Es imperativo y prioritario revisar el perímetro: si la Organización no hubiera tenido el acceso para los móviles abierto a su vez para el OWA, este incidente no se habría producido. Es fundamental controlar todos los servicios expuestos a Internet para evitar sorpresas de este tipo. Podemos para ello hacer uso de herramientas como nmap, o servicios online como Shodan.
Emplea 2FA en los accesos externos
Si en todos los accesos externos tuviéramos una doble autenticación (2FA), los atacantes no habrían tenido éxito en su ataque, ya que únicamente habrían obtenido la mitad de la información necesaria para acceder al OWA.
En este caso el acceso al OWA se realiza tras el acceso a una VPN (lo que podría contar como un cierto 2FA), pero aun habiendo cerrado el OWA “pirata” los atacantes podrían haber configurado un terminal móvil con los datos de acceso y seguir pudiendo entrar al correo. Para mitigar este riesgo, se propone en este caso hacer que el doble factor sea el propio terminal corporativo (Exchange permite crear una lista blanca de terminales autorizados, que en este caso son los terminales corporativos), lo que denegaría el acceso de los atacantes (y de paso, de los usuarios que configuran su correo en terminales no corporativos).
Conciencia a los usuarios
El incidente habría tenido un impacto mucho menor si los empleados hubieran sido entrenados en las buenas prácticas de seguridad: por un lado, a detectar posibles ataques de phishing, y por el otro a mantener una debida higiene de las contraseñas.
Se plantean dos actividades: en primer lugar, realizar una auditoría de fortaleza de contraseñas (de cuyos resultados a lo mejor hablamos en otro artículo), y en segundo lugar planificar un conjunto de actividades de concienciación para mejorar la postura de seguridad de los empleados de la Organización.
Aumenta las capacidades de log
Hemos tenido bastante suerte en este incidente, ya que hemos sido capaces de detectar con mucha rapidez su origen. Sin embargo, si hubiéramos tardado unos días más (imaginemos que no tenemos esas reglas de YARA en CARMEN y el ataque se detecta cuando los atacantes empiezan a exfiltrar datos), encontrar el punto de entrada habría sido muchísimo más complicado.
En nuestro caso, recomendamos el ampliar la capacidad del EventHistoryDB a 3 meses, aunque por motivos de espacio en disco duro nos tenemos que conformar con tan solo un mes. En lo referente a las carpetas de Elementos Recuperables volvemos a solicitar otros 3 meses, pero aceptamos la solución de compromiso de un mes / 40Gb de espacio. En ambos casos ampliamos el margen de detección de ataques sin comprometer el rendimiento del servicio, lo cual en sí mismo ya es una victoria.
Revisa los logs
Una correcta revisión de los logs del OWA podría haber detectado el ataque de fuerza bruta y haber contribuido a reducir sensiblemente el impacto del incidente. Se plantea como recomendación el integrar los logs del OWA dentro de una plataforma de gestión de logs como GrayLog o Splunk.
Al final todas las piezas del puzzle han encajado, y el incidente del correo fantasma ha sido resuelto con un impacto razonablemente pequeño para la Organización. Nos anotamos el mejorar la comunicación con el resto de áreas TIC (un tema siempre pendiente en la respuesta ante incidentes, pero sobre el que debemos trabajar día a día), y nos retiramos con la satisfacción del deber cumplido… hasta el siguiente incidente.
