(Nota: Esta es una historia de ficción; los personajes y situaciones no son reales; lo único real es la parte técnica, que se basa en una mezcla de trabajos realizados, experiencias de otros compañeros e investigaciones llevadas a cabo. Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XI Jornadas STIC del CCN-CERT aquí )
Dejamos el anterior artículo con nuestras miras puestas sobre el servidor de correo de la Organización, un Microsoft Exchange 2010. Lo primero que podemos hacer es solicitar a Sistemas que haga un message tracking (seguimiento del mensaje) del correo, que mediante una herramienta gráfica (aunque también podemos hacerlo por consola) nos localiza el histórico de un correo a alto nivel dentro de Exchange.
Primer intento, y el correo sigue sin aparecer. Repetimos las direcciones y el técnico de Sistemas repite la búsqueda sin éxito. El correo tiene que estar por fuerza, así que le pedimos que busque de nuevo en todo el día completo… y por fin lo encontramos, 14 minutos más tarde de cuando tenía que haber sido enviado.
Al parecer la Organización no tiene bien implementada su estrategia de sincronización de tiempos, y tenemos una deriva de 14 minutos entre el servidor Exchange y los clientes (nota mental: insistir en la necesidad de desplegar un servidor NTP lo antes posible), pero al fin hemos localizado el correo. El pantallazo enviado por Sistemas sería algo similar a este (por temas de confidencialidad no podemos poner ninguno de los originales):
Lo más interesante del seguimiento del mensaje es que nos permite extraer el ItemEntryId, que dentro de Exchange constituye un identificador único que permite buscar en la EventHistoryDB, una tabla interna de Exchange que recoge de forma exhaustiva TODA la actividad del ciclo de vida de un correo (desde cuándo se crea el mensaje pasando por cuándo ha sido guardado como borrador, o con qué medio ha sido enviado). Exchange por defecto solo guarda esta información durante 7 días, pero en este caso tenemos tiempo de sobra, por lo que podremos extraer toda la información que necesitemos.
Extraemos el ItemEntryId, y le pedimos a Sistemas que nos extraiga toda la información relevante. En este caso no tenemos herramienta gráfica y les toca emplear un poco de Powershell:
El resultado debería de ser algo parecido a esto:
Con una entrada para cada actividad del buzón de correo en cuestión. En nuestro caso, un fichero de texto de unos 50Mb (el usuario está claro que enviaba correos). Desgraciadamente, nuestra búsqueda del ItemEntryId nos devuelve de nuevo un NULL como respuesta. La cosa empieza a tomar un cariz un tanto desagradable: el correo no está en el equipo del usuario, y tampoco lo encontramos en el Exchange.
Hay que empezar a considerar seriamente la posibilidad de que los atacantes hayan comprometido el Exchange ya que forma parte de su repertorio de TTP (Técnicas, Tácticas y Procedimientos). Si lo han hecho, el incidente va a tener un impacto crítico: los atacantes pueden leer todos los correos de la Organización, así como capturar todas las contraseñas de acceso (que habitualmente suelen ser las del dominio Windows). Y… ¿qué mejor forma de exfiltrar información que por un simple e “inocente” correo?
Sin embargo, antes de plantearnos el “quemar” el servidor de correo de la Organización (con una cantidad considerable de buzones de correo) necesitamos encontrar pruebas sólidas y contundentes, lo que nos obliga a agotar todas las vías de investigación posibles.
En primer lugar, podemos comprobar si el buzón del usuario tiene la auditoría activada, lo que nos permitiría comprobar con detalle los posibles accesos. El comando en Powershell sería muy similar a este:
… y los resultados son negativos (la auditoría consume recursos del sistema, estando por ello desactivada por defecto para todos los buzones).
Si no tenemos auditoría no vamos a poder controlar las delegaciones de buzones, algo bastante frecuente en entornos corporativos cuando una persona necesita acceder al buzón de otra (o se tienen buzones genéricos compartidos). Sin embargo, otra llamada a Sistemas nos confirma que el buzón de este usuario no tiene delegaciones, por lo que otra puerta más que cerramos en nuestra investigación.
Nos queda una opción: recuperar el buzón completo del usuario del Exchange. Aunque en el cliente de escritorio o de móvil pensemos que tenemos un acceso completo a nuestros datos, en realidad Exchange guarda una buena cantidad de información extra, siendo nuestro objetivo una carpeta en especial: la de Elementos Recuperables.
Esta carpeta hace las funciones de papelera, y TODOS los correos que se borran quedan almacenados en dicha carpeta durante 14 días o hasta que dicha carpeta tiene un tamaño de 30Gb (lo que suceda antes). Por lo tanto, en un entorno corporativo en el que los clientes tengan los buzones sincronizados vía MAPI (fundamental para poder tener acceso al correo desde OWA o los móviles), si el usuario borra un correo en su cliente de escritorio el cambio se reflejará en su buzón… pero el correo pasará a esta carpeta. Adicionalmente, esta carpeta es inaccesible por el usuario (y probablemente, tampoco pueda haber sido manipulada por los atacantes a menos que hayan comprometido el Exchange entero).
Pasan de las 22.00h, pero María está de acuerdo en que el incidente tiene prioridad máxima, así que llamamos por teléfono al usuario y le solicitamos su permiso para realizar una exportación de su buzón de usuario (insistimos: aunque la política de seguridad de la Organización pueda autorizar la monitorización de los correos, siempre es mejor informar y solicitar el consentimiento para ser escrupulosamente cumplidores con los derechos a la privacidad de los usuarios).
El usuario es totalmente cooperativo y nos facilita dicha autorización, por lo que hablamos con Sistemas para la exportación completa del buzón del usuario, algo que se realiza en Powershell con este comando:
La exportación nos da el buzón completo que podemos cargar de nuevo en Kernel Outlook PST Viewer. Una búsqueda rápida nos da una alegría: ¡el correo está en la carpeta de Elementos Recuperables! Por fin tenemos una pista sólida de lo que puede estar pasando. Si revisamos el correo cuidadosamente encontramos varios datos de interés:
- El correo ha sido borrado (lógico, está en la carpeta de Elementos Recuperables). Si no lo ha hecho el usuario, alguien ha tenido que borrarlo por fuerza.
- Podemos localizar el documento original, empleado para generar el documento malicioso, unos días antes en el buzón del usuario.
- La firma del correo malicioso es ligeramente distinta a la original (los cargos no están completos, y falta una imagen en la firma).
- El correo ha sido escrito en idioma inglés (cuando el idioma por defecto de la Organización es el español).
Pasa la medianoche y no tenemos más líneas directas de investigación. Todo parece apuntar a que los atacantes han comprometido el Exchange de la Organización, por lo que mañana tocará empezar a analizar los cuatro servidores que conforman el cluster de correo. Dejamos el Autopsy trabajando sobre la imagen forense y nos retiramos hasta mañana.
El análisis continuará, pero en el capítulo siguiente…
