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.

2014-11-05 14:44:58 UTC - 192.168.39.134:49260 – XXX.XXX.XXX.XXX:80 - www.period1co.es - POST /nacional/noticias/comentarios.php

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:

2014-11-01 12:34:18 UTC - 192.168.39.134:34320 – XXX.XXX.XXX.XXX:80 - www.period1co.es - GET /imagenes/nacional/logo.jpg
  • En días separados, y cada una de ellas con un tamaño de descarga ligeramente diferente.

    Una petición única para descargar una imagen, sin descargarse ningún código HTML. Estamos casi seguros de que esa imagen tiene truco (una técnica muy habitual del malware es descargarse con una extensión distinta al .exe para poder pasar los filtros de los cortafuegos). Y el hecho de que tenga tamaño diferente… ¿cada cuánto cambian las imágenes de los logos de una página web? Sospechoso. Demasiado sospechoso. Dado que no sabemos lo cuidadosos que son los atacantes, tampoco podemos tocar esa imagen. Por ahora.

    Revisando todos los logs no encontramos ningún otro equipo que comparta estos patrones de acceso. Por un lado es una buena noticia, ya que el ataque está muy localizado, pero por el otro es muy mala noticia: los atacantes saben muy bien lo que están haciendo, comprometiendo el mínimo número posible de equipos para lograr sus objetivos.

    Como primera medida creamos reglas en nuestro Snort para detectar tanto accesos al dominio www.period1co.es como a ficheros con el nombre logo.jpg (sabemos que esta última generará muchos falsos positivos, pero por ahora estamos en modo paranoide total).

    Por ahora, a fin de cuentas, no vamos nada mal. En pocas horas nuestra investigación inicial ha cosechado excelentes resultados: tenemos dos URL claramente sospechosas y un equipo que está pidiendo a gritos un análisis forense.

    Dado que los logs del proxy no capturan la URL completa ni las imágenes descargadas, la investigación queda orientada de forma clara: Hay que analizar el equipo del director de marketing.

    La continuación de la investigación, en unos días…

  • Comments

    1. Vaya, muy interesante aproximación. Muchas gracias por compartirla con todos. Estoy deseoso de seguir leyendo más acerca de la caza y captura del APT. De forma adicional, veo buenos indicios para crear alertas de correlación y «automatizar» de alguna forma las investigaciones que llevasteis acabo por si se repiten en el futuro.

    2. Muy buenas tardes,

      Puede sonar un poco a autopublicidad, pero eso es justamente lo que estamos haciendo en S2 Grupo con CARMEN (https://www.s2grupo.es/pdf/NdPS2Carmen.pdf), nuestra herramienta de detección de APTs.

      Aunque con redes muy grandes, los tiempos de computación todavía siguen teniendo tela… ;)

      Un saludo,

      Antonio Sanz
      S2 Grupo

    3. ¿Usasteis Carmen en este incidente?

    4. María … es un secreto ;)

    5. Sherlock holmes decia, «Cuando todo aquello que es imposible ha sido eliminado, lo que quede, por muy improbable que parezca, es la verdad». Me juego la vida contra un vermut a que el director de Marketing esta implicado.

      Recordemos: «se ha filtrado es el plan estratégico de la empresa para los próximos cinco años». (NO cualquier cosa….)

      El director de marketing de una empresa de ese calibre, no debe ser un profano en informática. Si no se ha conectado a ningun sitio dudoso, no ha usado Linkedin ni facebook, ni nada parecido, lo que deduzco por las medidas de seguridad de la empresa y más a ese nivel. ¿Como se ha infectado su equipo?….

      Está en el Ajo.

    6. Yo tengo una gran duda… ¿cómo se sabe que se están filtrando datos?

    7. El tioTonet, tienes más razón que un santo a la hora de sospechar.

      Según muchos estudios, un porcentaje muy alto de los incidentes de seguridad son causados por insiders. Y cuanto más elevadas son las medidas de seguridad más difícil es entrar desde fuera y más apetecible se hace contar con «ayuda interna».

      A lo largo de esta semana y la que viene iremos deshojando la margarita, tened paciencia ;)

    8. emmental, en toda investigación se parte de unos «hechos iniciales», información que te dan los clientes para que empieces a trabajar y que en principio das como buena (aunque como dice House, los pacientes siempre mienten y hay que cogerla con pinzas).

      En muchas empresas grandes hay personal dedicado a seguridad interna. Llámalo contrainteligencia, llámalo inteligencia competitiva, llámalo «tengo un amigo en el periódico/Ministerio/XXX» … y las cosas se saben ;)

    9. El Tio Tonet says

      Pero tambien se lo que haria para salver el plan de Marqueting y anular esa amenaza. Es un poco fuerte. Si quieres saberlo, dimelo y te explico mi idea.

    10. Paco Castello says

      Me tienes intrigadísimo Antonio. Estoy impaciente por continuar leyendo una nueva entrega de tus aventuras ;)

    11. Si los datos proporcionados son verdaderos y no falsas pistas para ocultar la identidad de la Empresa contratante,teniendo en cuenta que es una empresa del Ibex, cuyo CIO es una mujer, y por la estructura directiva que se relata parece bastante probable que la empresa en cuestión sea Telefónica.

      En un plano más improbable podríamos estar hablando de Bankinter o Arcelormittal.

      Reitero que todo esto suponiendo como reales los datos proporcionados en la entrada.

      Un saludo y espero impaciente la continuación.

    12. Manuel Benet says

      Clarín, en caso de que la historia esté basada en un caso real (y no construida a partir de múltiples incidentes en múltiples organizaciones a lo largo de muchos años y además complementada y regada por la imaginación), ten por seguro que nunca se darían pistas para que alguien pudiese adivinar la empresa en cuestión.

      Como editor, te puedo garantizar eso al «ciento por ciento» :)

    13. Muy bueno, espero impaciente las siguientes entregas.
      Sin leer el título, y por el comienzo del artículo parecía un ataque de phishing…. pero ya veo que efectivamente, va por derroteros APT

    14. A mi lo que me hace ruido es que ante tanta seguridad y paranoia, se entregue una máquina diciendo quien es el usuario.
      Como empresa, necesito que se solucione urgente el problema, pero no veo el interés en que después se diga «fue por culpa de fulano o mengano»…
      Me parece que eso tambien falla en la seguridad.

    15. Muy buenas tardes, @MrFloydARG

      En muchas investigaciones de incidentes el contexto es fundamental para poder realizar el trabajo de forma rápida y exacta. Tener información de cómo funciona la empresa, qué es una IP o a quién pertenece permite acotar la investigación, descartar falsos positivos y poder concentrar tus esfuerzos donde realmente importa.

      Y tú como empresa lo que quieres es resolver el problema lo antes posible, por lo que te interesa es colaborar (aunque no te diré que en algunos sitios te dan la info con cuentagotas, y en cuanto averiguas lo que ha pasado te dicen «muchas gracias por todo, muy amables, ya si eso nos encargamos nosotros).

      Y sobra decir que en todas las respuestas ante incidentes se firman unos acuerdos de confidencialidad draconianos (los de empresas grandes da miedo solo verlos, y firmarlos hace que te corra un sudorcillo frío por la espalda que para qué), por lo que se tiene la seguridad de que lo que se averigüe «queda en casa».

      Un saludo,

      Antonio Sanz
      S2 Grupo

    Trackbacks

    1. […] En esta línea, Antonio Sanz nos deleitó con una serie (Zen y el arte de pescar APTs: I, II, III y […]