Análisis de una intrusión en la plataforma Aristeo como ejemplo de sus capacidades predictivas
Mientras aún había gente que felicitaba el año nuevo, a finales de enero, un señuelo de Aristeo era vulnerado por un atacante desconocido. En esta entrada haremos un breve relato sobre el análisis de dicha intrusión como muestra de las capacidades de Aristeo y de su habilidad para proporcionar una valiosa información predictiva a nuestros clientes.
No se trata, por lo tanto, de un artículo técnico de una amenaza concreta o de un actor o grupo APT, sino de una muestra de las capacidades de Aristeo en referencia a su talento para la detección de actores y amenazas no detectados previamente.
Para quien no conozca Aristeo, aquí va un breve resumen:
- Aristeo es una plataforma de inteligencia predictiva para combatir las ciberamenazas del ámbito industrial. Este ámbito mezcla hoy por hoy elementos OT, IT e IoT, por lo que es necesario que nuestra solución sea capaz de comprender e interpretar la información directamente relacionada con éstos.
- Aristeo genera su inteligencia estableciendo una red de sondas-señuelos diseñados con hardware industrial real, con la que captura las ciberamenazas del ámbito industrial, aprendiendo sobre ellas y detectando aquellas potencialmente más peligrosas.
- La utilización de hardware industrial real permite que las amenazas sean reales y asociadas de facto con estos entornos. Además, al estar expuesto 365 días al año a todas las ciberamenazas a nivel global, la información siempre es fresca y con el más alto grado de confianza.
- El concepto de señuelo es similar al de una placa de Petri en la que se cultivan virus y bacterias para aprender cómo se comportan estas amenazas. Gracias a este estudio, el ser humano puede desarrollar test de detección, vacunas, tratamientos para acabar con la infección, medidas de mitigación para reducir la sintomatología, etc.

1. Antecedentes
Era una fría mañana de enero cuando recibimos el aviso del sistema de alertas de Aristeo. Parte del sistema de un señuelo había caído.
En ese momento nos pusimos manos a la obra para saber qué había pasado ¿un fallo en el sistema? ¿una actualización no esperada? ¿alguien le ha pegado una patada al cable?
Pues no, lo que sucedió realmente es que alguien había entrado en la bahía de ingeniería de uno de los señuelos de Aristeo y se pasó de la raya, con lo que se cortó la conectividad y se acabó el problema.
Esta situación de corte de conectividad deja actuar al atacante hasta que comience acciones maliciosas contra terceros fuera de nuestro control, lo que permite que los señuelos desplegados en Aristeo no sirvan como herramientas de ataque a terceros.
2. Post mortem
Una vez vista la alerta, llegó el momento de analizar qué había ocurrido.
Por un lado, en Aristeo, teníamos registros de varios accesos remotos exitosos vía RDP en diferentes días contra la bahía de ingeniería, pero, por otro, al revisar los logs de la propia bahía, observamos que no había ni rastro de estos. Lo primero que inferimos, por lo tanto, es que el atacante había borrado los logs del sistema para pasar inadvertido.
Que el atacante no es un novato lo teníamos claro desde el principio. Nuestro RDP está bien configurado y actualizado, y la contraseña no es corta ni de diccionario. Hablamos de 20 caracteres de longitud en una contraseña para cuya comunicación utilizamos CredSSP + TLS 1.2 (preferentemente) para el cifrado de la conexión utilizando criptografía de curva elíptica.
2.1 ¿Cómo ha podido pasar?
Como hemos comentado más arriba, con Aristeo detectamos accesos exitosos, pero cuando fuimos a revisar la máquina… nada. Nada en los logs de eventos dentro de la máquina. La intrusión no había ocurrido… pero en la papelera de reciclaje había una carpeta con un escáner de puertos bastante conocido entre los cibermalos, KPortScan.
La carpeta, como se puede apreciar en la siguiente captura, tenía también dos ficheros de texto: uno, con nombre en francés, donde había información de posibles objetivos y otro, “results” donde figuraban las direcciones IP que intentó escanear el atacante del día 27 de enero. También hay librerías de Qt, un entorno de desarrollo, que no suponen en sí mismo un elemento malicioso o diferencial para detectar la amenaza.

Obsérvese el fichero en francés. ¿Muy listos para borrar los logs y muy aficionados para dejar una herramienta en la papelera?
Y, además ¿qué otras herramientas similares descargó el atacante?
Ninguna. No se efectuó ninguna descarga de herramientas de hacking/auditoría (llamémoslo X), pero sí se descargó un software legítimo y común en el entorno empresarial: . Cualquiera puede ver ese software de acceso remoto ampliamente utilizado por las empresas para acceder a los PC de sus empleados en caso de necesidad (como una asistencia remota) y nadie se plantea que pueda ser un problema. Incluso puede estar instalado por defecto en muchos dispositivos, estén en una oficina o en una nave industrial.
El problema es que no hay nada más. Nada. No hay registros de ningún tipo, no hay una referencia temporal, no hay direcciones IP, usuarios…
Necesitamos ayuda.
2.2 Aristeo, ayúdanos
En este momento un analista pierde opciones de saber qué ha sucedido. Sin embargo, si nos ponemos las gafas de Aristeo, el panorama es otro.
Lo primero que hicimos fue comprobar si las direcciones IP detectadas accediendo de manera exitosa (con origen en Marruecos) tenían algún tipo de pasado en Aristeo o en otros sistemas de captura de amenazas (los más reconocidos en el sector). Nada. Direcciones IP limpias.
Entonces, haciendo uso de la inteligencia proporcionada por Aristeo, comenzamos a buscar direcciones IP relacionadas, hallando actividad un mes antes de la primera intrusión. No la suficiente para vulnerar el sistema por fuerza bruta pero sí que hubo acciones coordinadas. A continuación, os mostramos una pequeña tabla con un ejemplo de lo detectado.

Merece la pena recordar que las direcciones IP pueden ser consideradas un dato de carácter personal, por lo que, en cumplimiento de la legislación vigente a nivel europeo, hemos ofuscado dos octetos. Aquí va una línea temporal con las principales interacciones contra nuestro señuelo asociados a los ataques exitosos.

Se puede observar que la cantidad de interacciones no justifica un acceso por fuerza bruta, por lo que el vector de entrada no fue ese. Adivinar la contraseña por fuerza bruta requeriría, según servicios públicos, 7 cuatrillones de años…
Cuando buscamos las trazas de los accesos exitosos al sistema, Aristeo sí nos las ofrece. Al incorporar toda la información al análisis, nos damos cuenta de lo que puede haber pasado. Parece que dos actores han tomado parte de este juego, lo cual explicaría por qué un atacante parece tan profesional un día y otro día parece tan novato.
- Un actor ha vulnerado nuestra máquina. El cómo es algo que nos reservamos para nuestro equipo de inteligencia. Tras tomar el control, descargó e instaló Anydesk para persistir el acceso en caso de perderlo vía RDP. Gracias a Aristeo (en la máquina todos los log estaban limpios), hemos encontrado trazas de conexiones directas a través de Anydesk tras la primera intrusión.
- Otro actor, presumiblemente, compró un pack con objetivos previamente vulnerados. Recordemos que parte de lo que encontramos en el sistema, fue un documento de texto en francés con varios objetivos. Estos no parecen conocidos, públicos o importantes más allá de ser, presuntamente víctimas previas del actor uno (o de otros).
Sin embargo, este actor no pudo poner en marcha su plan, porque antes intentó escanear 621 direcciones IP de un proveedor de servicios de internet británico, momento en el que internet “se cayó” (desde el punto de vista del atacante) y, por supuesto, no pudieron atacar a nadie más y perdieron el acceso a nuestra máquina.
2.3 Y ahora… ¿qué?
Ahora toca aprender de lo que ha sucedido y valorar si hay algo que se pueda mejorar en Aristeo o en la red de señuelos. Aunque estamos satisfechos con sus capacidades, siempre es bueno intentar ir un paso más allá.
Respecto al uso de la inteligencia generada por Aristeo, la seguridad de nuestros clientes se reforzó en cuanto sucedieron los hechos, porque transmitimos la información a nuestro DOC (Digital Operations Center) en tiempo real.
3. Anexo: IoC
3.1 Ficheros rescatados en el sistema

______
AUTORES
GABRIEL ÁLVAREZ
Responsable de Innovación OT
SERGIO VIDAL
Especialista en Innovación OT