Zen y el arte de pescar APTs (I)

Comienza un día nuevo en la oficina. Todos los sistemas están funcionando correctamente, el generador de cafeína está a toda máquina y los comerciales están fuera haciendo visitas. Es un momento perfecto para revisar algunos artículos de investigación, o hasta para invertir un poco de tiempo en un par de scripts en Python a los que les llevo dando vueltas un rato… hasta que suena el teléfono.

El jefe ha recibido una llamada de la CIO de una empresa del IBEX 35 (a partir de ahora, la empresa será Empresa, y la directiva María). Según sus palabras, se ha producido una fuga de datos. Una fuga muy grave. Al parecer, parte de lo que se ha filtrado es el plan estratégico de la empresa para los próximos cinco años. Información a la que tiene acceso un grupo muy reducido de personas, entre las que se encuentra el consejo de dirección de la empresa.

Como todavía no sabemos a lo que nos enfrentamos, cogemos tanto la mochila de respuesta ante incidentes como la de informática forense y nos dirigimos a la sede de la empresa en Madrid para una primera toma de contacto.

La Empresa se toma la seguridad muy en serio: registran ambas mochilas, toman fotografías de todos los dispositivos y nos dan una tarjeta de identidad que por la pinta seguro que es capaz de hacer más de lo que parece. Cámaras de seguridad en todos los pasillos, y un ambiente totalmente profesional hasta que subimos a la planta noble, donde nos reunimos con María. Está visiblemente nerviosa, y viendo su traje parece que lleva más de un día en pie.

Dentro de las fases de la respuesta ante incidentes estaríamos todavía de la detección (sabemos que hay algo, pero todavía no conocemos el alcance de lo que está sucediendo). María nos cuenta que alguien está obteniendo información confidencial de la empresa, tan reservada que solo puede venir de los más altos cargos de la empresa: el director general, el director de operaciones, el director financiero, el director de ventas… o ella misma.

Tras firmar varios acuerdos de confidencialidad especialmente virulentos, empezamos nuestro trabajo con la aproximación más simple: un inside job, el clásico empleado descontento que ha robado la información. Pero al parecer todos los directivos son fanáticamente leales a la empresa e incluso su personal administrativo es de la mayor confianza, por lo que a priori podemos descartar esta teoría (en realidad no la descartamos, solo la guardamos para más tarde).

El espionaje clásico también queda excluido: la información robada no es algo que se pueda obtener poniendo un micrófono o “pinchando” un teléfono. Ha sido extraída de un ordenador.

La Empresa también se toma muy en serio la seguridad informática: seguridad en profundidad en toda la arquitectura, varios niveles de cortafuegos, antivirus actualizados, sistemas parcheados hasta la obsesión, acceso remoto por VPN, detectores de intrusos, contraseñas robustas cambiadas cada mes, etc. Uno de esos sitios en los que nunca se esperaría que sucediera nada, pero en el que aquí estamos trabajando.

Lo primero que hacemos es recoger información, toda la que seamos capaces de recopilar para proceder a su análisis y entender qué ha podido suceder. La Empresa tiene todo bien organizado, por lo que podemos hacernos con un paquete de datos completo: logs del proxy, de la pasarela de correo, de los antivirus, eventos de servidores y de las estaciones de trabajo y hasta de la VPN. El problema es que todos esos logs, si tomamos el acumulado de los últimos tres meses (el mínimo con el que empezamos), suman 200Gb de información. Comprimida.

Cogemos tres meses porque estamos empezando a sospechar que una APT (Advanced Persistent Threat) puede estar detrás de esto. Vamos, que alguien puede haber entrado hasta la cocina en la Empresa y se esté comiendo hasta los yogures caducados. El disponer de un histórico de datos nos permite detectar patrones y descartar falsos positivos, haciendo más eficaz nuestro trabajo.

Lo primero que hacemos es realizar un filtro inicial de la información, quedándonos con los equipos tanto de los directivos como de su personal de administración (diez en total), lo que reduce los registros a un poco menos de 20Gb de datos descomprimidos. A través de una serie de scripts normalizamos e importamos la información a una base de datos que nos permita realizar búsquedas y aplicar otros scripts que tenemos desarrollados.

Las primeras comprobaciones son casi rutinarias, pero hay que realizarlas: visitas a dominios infectados, eventos de la consola de antivirus, múltiples envíos de correos a direcciones no conocidas… serían signos que nos permitirían detectar rápidamente el equipo comprometido, pudiendo aislar la infección lo antes posible.

No hay suerte esta vez, aunque en realidad no esperábamos sacar nada en claro. Este incidente huele a algo avanzado desde el primer momento. Tenemos que pasar a la segunda fase: la detección de anomalías. Todos los sistemas (incluidos sus usuarios) siguen unos patrones de comportamiento, un conjunto de acciones y conexiones que pueden ser analizados para conformar un baseline o valor de referencia.

Ese baseline puede ser obtenido de los logs recuperados para hacer emerger todo lo raro, todo lo que no encaja: las anomalías. Es un trabajo complicado, porque la creación del baseline nunca es exacta, y abundan los falsos positivos (y además, nunca sabes si los “malos” han sido tan buenos como para esconder sus acciones tan bien como para que se hagan parte del baseline).

Al final es un trabajo minucioso, costoso y metódico que tiene que hacerse con sumo cuidado y atención al detalle para no dejarse nada. Es como buscar una aguja en un pajar, pero cuando el pajar es del tamaño de un campo de fútbol y no sabes siquiera que lo que quieres encontrar es una aguja.

Menos mal que, si llevas tiempo en el negocio, puedes tomar algunos atajos. Sabiendo cómo se comportan muchas amenazas es posible realizar una serie de modelos de ataque, conociendo qué tipo de anomalías generan en un sistema. De esta forma podemos buscar por esas miguitas de pan, esos indicios que nos permitan averiguar qué es lo que está sucediendo.

La cantidad de datos no es pequeña, así que tenemos algo de tiempo mientras nuestros programas trabajan. Un poco más de cafeína, una docena de correos y dos llamadas telefónicas más tarde, tenemos un listado de unas 30 anomalías.

Casi todas son falsos positivos, pero una de ellas salta a la vista: una petición POST a un nombre de dominio muy similar a un conocido periódico de tirada nacional (a partir de ahora www.period1co.es), tan similar que tan solo han cambiado una letra por otra casi idéntica. La petición en sí es bastante anodina, pareciendo la URL a primera vista el posteo de un comentario en una noticia.

Anomalía por partida doble. En primer lugar, ¿por qué tenemos un POST sin haber tenido antes ninguna comunicación con esa página web? Dentro de una comunicación HTTP el método POST es empleado para enviar datos a una página web, pero lo lógico es que antes hayamos descargado esa web, lo que suele conllevar un cierto trasiego de peticiones GET, que aquí a priori no existen.

En segundo lugar: ¿www.period1co.es? Lo buscamos en diversas páginas de reputación online y ninguna lo marca como malicioso, pero está claro que huele a chamusquina. Nos morimos de ganas por abrirlo en un navegador, pero no sabemos si los atacantes están vigilando los logs y los ponemos sobre aviso.

Mirando el lado positivo, tenemos ya dos hilos de los que tirar: el dominio supuestamente malicioso, y la IP origen de la petición, que resulta ser la del director de marketing de la Empresa.

Ahora podemos empezar a trabajar alrededor de estos indicios, lo que en la jerga conocemos como pivotar. Lo primero es ver más ocurrencias de ese dominio malicioso en todos los logs que tenemos recogidos, sean o no anómalos. Y el segundo paso sería analizar en detalle todo el tráfico de la IP 192.168.39.134, que parece ser a todas luces el equipo infectado.

La emoción de la caza es casi como una droga, así que mi jefe y yo miramos hipnotizados la pantalla mientras las herramientas hacen su trabajo. Diez angustiosamente largos minutos más tarde, tenemos resultados jugosos. Muy jugosos.

El equipo 192.168.39.134 ha realizado en los últimos dos meses 18 conexiones POST como la anterior a la URL www.period1co.es. Todas ellas en horario laboral, con unos tamaños bastante discretos (que hacen pensar a priori que la exfiltración de datos no se ha producido por esa vía) y a subpáginas del dominio con una estructura común (que podrían ser respondidas por un único script en el servidor y que ayudarían a que las URL variaran, haciendo más complicada su detección).

Y de forma adicional, tenemos 5 conexiones más al dominio desde dicha IP: