El aislamiento de una red, que en inglés se conoce como air-gapping, es algo que se utiliza para proteger las redes más sensibles. Solo en la primera mitad de 2020 surgieron cuatro frameworks que hasta ese momento eran desconocidos y que estaban diseñados para comprometer redes aisladas, lo que elevó el total, según nuestro recuento, a 17 frameworks utilizados para este fin. Por eso, el equipo de ESET Research decidió revisar cada uno de los frameworks conocido hasta la fecha para ponerlos uno al lado del otro y compararlos.

Hallazgos más importantes de este reporte

  • Todos los frameworks están diseñados para realizar espionaje en alguna de sus formas.
  • Todos los frameworks utilizaban unidades USB como medio de transmisión físico para transferir datos dentro y fuera de las redes aisladas atacadas.
  • No hemos encontrado ningún caso real o presunto de transmisión física encubierta.
  • Más del 75% de los frameworks utilizaban archivos LNK maliciosos o archivos autorun en unidades USB para realizar tanto el compromiso inicial del sistema bajo una red aislada o para moverse lateralmente dentro de la red aislada.
  • Más de 10 vulnerabilidades de ejecución remota de código críticas relacionadas con LNK en Windows fueron descubiertas y luego parcheadas por Microsoft en los últimos 10 años.

En nuestro whitepaper describimos cómo operan los framework de malware para atacar redes aisladas, y proporcionamos una comparación de sus TTP más importantes. También proponemos una serie de técnicas de detección y mitigación para proteger las redes “air-gapped” de las principales técnicas utilizadas por todos los frameworks maliciosos conocidos públicamente hasta la fecha.

Utilizando como referencia información publicada por más de 10 organizaciones diferentes a lo largo de los años, y sumando algunos análisis ad hoc para aclarar o confirmar algunos detalles técnicos, pusimos los frameworks en perspectiva para ver qué es lo que la historia podría enseñarnos tanto para mejorar la seguridad de las redes aisladas como nuestra capacidad para detectar y mitigar futuros ataques.

Este estudio exhaustivo nos permitió identificar varias similitudes importantes en todos estos frameworks, incluso en aquellos que fueron creados con 15 años de diferencia. Enfocamos nuestra atención específicamente en los mecanismos de ejecución de malware utilizados tanto en el lado conectado como en el lado de las redes aisladas atacadas y en las funcionalidades del malware dentro de la red aislada (persistencia, reconocimiento, propagación, espionaje y —al menos en una caso—actividades de sabotaje), con especial atención en los canales de comunicación y exfiltración utilizados para sortear las barreras y mecanismos de control que son ejecutados en las redes aisladas. Esto también dio como resultado una estructura de análisis sistemático que puede reutilizarse para documentar malware dirigido a redes aisladas que se descubran en el futuro.

A pesar de algunas diferencias y matices entre todos los frameworks estudiados, nuestro análisis muestra cómo la mayoría difiere en muchos de esos aspectos solo desde una perspectiva de implementación, principalmente debido a las severas restricciones impuestas por los entornos aislados. Armados con esta información, destacaremos algunas oportunidades de detección específicas a partir de las técnicas reales que observamos en actividad.

Nuestro objetivo es convencer al lector de la importancia de tener todos los mecanismos de defensa adecuados para mitigar las técnicas utilizadas por prácticamente todos estos frameworks que se han observado en actividad, antes de comenzar a analizar las muchas teorías de técnicas de evasión de redes aisladas que han recibido mucha atención en los últimos años a pesar de que ninguna de ellas se utilizó en un ataque real o que se haya conocido públicamente.

Victimología, perfiles de atacantes, cronología

Una red aislada es aquella que está físicamente aislada de cualquier otra red para aumentar su seguridad. El aislamiento es una técnica utilizada para proteger redes con los sistemas más sensibles y de mayor valor dentro de una organización, sistemas que naturalmente son de gran interés para numerosos atacantes, incluidos todos y cada uno de los grupos APT.

Podemos afirmar sin temor a contradecirnos que los actores de amenazas detrás de los frameworks de malware conocidos y diseñados para atacar redes aisladas pertenecen a la categoría de amenazas persistentes avanzadas (APT). A pesar de la variedad de actores de amenazas detrás de estos frameworks, todos compartían un propósito común: el espionaje.

Algunos frameworks han sido atribuidos a ciertos actores de amenazas bien definidos y conocidos:

En otros casos la atribución ha sido menos clara, especulativa o controvertida. Agent.BTZ, por ejemplo, ha sido atribuido a Turla, pero otros expertos no están tan convencidos de esto.

Finalmente, tenemos una trilogía de frameworks que constituyen nuestros casos especiales: estos frameworks fueron encontrados en la documentación de las filtraciones de Vault7 y allí se describe que han estado en funcionamiento en un rango de tiempo de 2013 a 2016; sin embargo, no hemos encontrado muestras activas para analizar de primera mano.

La siguiente imagen muestra el período de actividad de cada framework, junto el año en que se conocieron. Esto también es una muestra de lo difícil que es detectar este tipo de frameworks, ya que varios han estado activos durante muchos años antes de que se conocieran.

Tenga en cuenta que los períodos de actividad se basan en lo que se ha informado públicamente; en algunos casos, los investigadores no pudieron determinar un período preciso de actividad basado en hechos observables, sino que fueron aproximados o inferidos mediante el uso de algunas hipótesis razonables.

Figura 1. Período de actividad de todos los frameworks conocidos junto con el año de la primera aparición en un reporte público

Anatomía de los sistemas de redes aisladas desde la perspectiva del malware

El ataque y el compromiso de los sistemas en redes aisladas requieren que los atacantes desarrollen capacidades que permitan que sus herramientas se comuniquen a través de canales que no suelen ser necesarios en las operaciones normales. La razón es obvia: tienen que lidiar con el hecho de que estas redes están aisladas de Internet.

No existe una definición precisa de lo que es en realidad “air-gapped malware” o “malware para redes aisladas”, desde una perspectiva puramente técnica. Esto provocó algunas discusiones animadas internamente, hasta que finalmente acordamos, a los efectos de este documento, la siguiente definición de malware para redes aisladas:

Malware, o un conjunto de componentes de un malware que actúan juntos (un framework), que implementa un mecanismo de comunicación externo entre un sistema de red aislado y el atacante. Esta comunicación puede ser bidireccional (comando y respuesta) o unidireccional (solo exfiltración de datos).

Decidimos separar los frameworks en dos categorías muy amplias: conectados y sin conexión. La mayoría de los frameworks están diseñados para proporcionar conectividad de extremo a extremo completamente remota entre el atacante y los sistemas comprometidos dentro de la red aislada. A estos los llamamos "frameworks conectados ". El esquema operativo general es el siguiente:

Figura 2. Descripción general de los componentes y las acciones de un framework conectado diseñado para atacar redes aisladas

Los frameworks conectados más básicos solo tienen conectividad en línea con el atacante para fines de exfiltración de datos. Los más potentes admiten un protocolo de comunicación bidireccional (representado por las flechas amarillas). A través de un sistema comprometido del lado conectado el atacante envía comandos al malware ubicado en la red aislada. Esto se hace a través de un canal de comunicación encubierto que a menudo es colocado en una unidad USB. Esta característica otorga a los atacantes la capacidad de ejecutar de forma remota código arbitrario dentro de redes aisladas.

En los otros casos, más raros, el escenario de ataque no involucra ningún sistema conectado a Internet en absoluto. A estos los llamamos "frameworks sin conexión ". En estos casos, todo indica la presencia de un operador o colaborador en el lugar para realizar las acciones que habitualmente realiza la parte conectada de los frameworks conectados, como preparar la unidad USB maliciosa inicial responsable de la ejecución dentro de la red aislada, ejecutar el malware en el sistema aislado, extraer los datos exfiltrados de la unidad y enviar comandos adicionales al lado de la red aislada.

Figura 3. Descripción general de los componentes y acciones de un framework sin conexión diseñado para atacar redes aisladas

Con esas definiciones formales establecidas, podemos comparar las principales características que tienen en común todos los framworks.

Vector de ejecución del lado conectado

En el caso de los frameworks conectados, el primer paso para comprometer con éxito la red aislada es lograr poner un pie adentro de un sistema que tenga conectividad a Internet. Cuando se trata de APT, no siempre es posible saber exactamente cómo sucedió el acceso inicial, pero para los casos que sí conocemos, los métodos observados no difieren mucho de lo que vemos en el malware general: correos electrónicos con archivos adjuntos maliciosos, enlaces o gusanos USB.

Vector de ejecución inicial del lado de la red aislada

Este es uno de los elementos más interesantes que estudiamos: ¿cómo se las arreglan los atacantes en primer lugar para ejecutar código malicioso en un sistema aislado? Todos los frameworks han ideado sus propios métodos, pero todos tienen una cosa en común: sin excepción, usaban como arma unidades USB. La principal diferencia entre los frameworks conectados y sin conexión es en primer lugar la forma en que la unidad USB se utiliza como arma. Los frameworks conectados generalmente implementan un componente en el sistema conectado que monitoreará la inserción de nuevas unidades USB y que colocará automáticamente el código malicioso necesario para comprometer el sistema aislado. Los frameworks sin conexión, por otro lado, se basan en que los atacantes confeccionen intencionalmente su propia unidad USB. Lo que es interesante aquí es la variedad de técnicas utilizadas a lo largo del tiempo por estos frameworks para ejecutar su payload en el sistema de destino. Podemos clasificarlos en tres grandes categorías.

  • Ejecución automatizada: el código malicioso se ejecuta sin la intervención del usuario. Esto implica la explotación de alguna vulnerabilidad, la más famosa es CVE-2010-2568, también conocida como “Stuxnet LNK exploit”.
  • Ejecución no automatizada (activada sin saberlo): la ejecución del código malicioso depende de engañar a un usuario legítimo desprevenido para que ejecute el código malicioso en el sistema de destino. Esto se puede realizar, por ejemplo, colocando como señuelo en la unidad USB un documento malicioso o un troyano camuflado como instalador de software.
  • Ejecución no automatizada (realizada deliberadamente): el código malicioso está oculto en la unidad USB y debe ser ejecutado deliberadamente por un actor humano con acceso físico al sistema de destino.

Tabla 1. Técnicas utilizadas para comprometer el primer sistema aislado

Funcionalidades laterales

Analizamos las tres funcionalidades más importantes de los frameworks disponibles en el lado aislado: persistencia, actividad de reconocimiento y espionaje, y propagación y movimiento lateral. Esto puso en evidencia cómo los frameworks varían mucho en términos de objetivos operativos y complejidad: algunos están diseñados para realizar una acción maliciosa y huir, con tareas hardcodeadas para el robo de archivos y sin persistencia, mientras que otros implementan mecanismos de persistencia sofisticados y sigilosos, y mecanismos de propagación efectivos dentro del sistema aislado. Consulte la Sección 4.3 del whitepaper para conocer todos los detalles.

Canal de comunicación y exfiltración

Esta es la característica más interesante de estudiar cuando se observa el malware que ataca redes aisladas. Anteriormente en este artículo aclaramos nuestra definición de "malware para redes aisladas " y dividimos los frameworks para redes aisladas en dos categorías: conectados y sin conexión.

La diferencia desde el punto de vista de la comunicación y la exfiltración es significativa: los frameworks conectados requieren un canal de comunicación online con el tradicional C&C que conecte al atacante con el host comprometido del lado conectado, y un segundo canal sin conexión, que conecte el host comprometido del lado conectado con los sistemas aislados, como se muestra en la figura siguiente.

Figura 4. Canales de comunicación conectados y sin conexión en frameworks conectados

Por otro lado, la figura siguiente muestra cómo los frameworks sin conexión solo requieren el canal de comunicación sin conexión.

Figura 5. Canal de comunicación sin conexión en frameworks sin conexión

La parte medular del malware para redes aisladas y que lo define como tal es la presencia de un canal de comunicación sin conexión. Así es como el malware logra evadir la capa de seguridad que ofrece el aislamiento para transferir información de entrada y salida de la red atacada.

Un canal sin conexión puede verse como un protocolo de comunicación específico que se ejecuta desde un determinado medio de transmisión hacia un espacio aislado.

Una de las primeras cosas que me viene a la mente cuando se habla de ataques contra redes aisladas es cómo se puede sortear ese aislamiento. De hecho, periódicamente se publican nuevas investigaciones sobre medios de transmisión físicos encubiertos. Uno de los investigadores más prolíficos en ese dominio es sin duda Mordechai Guri, un investigador en ciberseguridad de la Universidad Ben-Gurion del Negev. Él y su equipo han demostrado la viabilidad de numerosas técnicas que permiten la transferencia de información a través de espacios aislados con varios niveles de complejidad respecto de la implementación de los ataques y el ancho de banda disponible.

Si bien ha habido supuestos avistamientos de ataques reales (in the wild) utilizando tales técnicas, ningún caso analizado por investigadores colegas ha sido divulgado públicamente. Prácticamente todos los frameworks maliciosos conocidos públicamente dirigidos a redes aisladas hasta la fecha utilizaban unidades USB como medio de transmisión físico para transferir información a través entornos aislados.

La siguiente tabla ilustra cómo aproximadamente la mitad de los frameworks solo implementan protocolos unidireccionales. En estos escenarios de ataque, la información solo puede fluir desde el sistema aislado comprometido hasta el atacante, y no al revés. Esto significa que el componente de malware que se ejecuta en el lado aislado no tiene ningún mecanismo de actualización o capacidad de backdoor y está diseñado para realizar tareas específicas codificadas, generalmente reconocimiento y robo de información, y luego exfiltrar la información al atacante a través de la unidad USB. El atacante no tiene forma alguna de enviar actualizaciones o comandos para controlar el sistema comprometido.

Los frameworks que implementan protocolos bidireccionales son más flexibles, ya que permiten al atacante tener un control mucho mejor sobre los hosts comprometidos aislados. Curiosamente, no todos los frameworks con protocolos bidireccionales hacen un uso completo de esta capacidad. De hecho, la mayoría implementa solo un pequeño conjunto de comandos no muy flexible, como robar archivos que coinciden con patrones específicos o ejecutar un archivo ejecutable específico presente en la unidad USB.

Tabla 2. Tipos de protocolos de comunicación sin conexión

Defendiendo las redes aisladas

No hace falta decir que defender las redes aisladas frente a los ciberataques es un tema muy complejo que involucra a varias disciplinas. Está lejos de nuestra intención afirmar que tenemos una solución mágica a este problema. Dicho esto, es valioso comprender cómo operan los frameworks en entornos aislados y derivar formas de detectar y bloquear actividades maliciosas comunes.

La sección 5 de nuestro whitepaper incluye ideas para detectar y bloquear actividades maliciosas que son comunes a una parte significativa de los frameworks estudiados. Ninguno de ellos es revolucionario, pero esperamos que nuestro enfoque basado en datos ayude a los defensores a priorizar sus mecanismos de defensa. En otras palabras, que los responsables de la seguridad primero implementen mecanismos de defensa contra lo que el malware ya conocido ha estado haciendo hasta ahora, antes de intentar bloquear técnicas que aún no se han utilizado.

Conclusión

Hemos visto cómo los frameworks se pueden dividir en dos categorías: marcos conectados, que se operan de forma totalmente remota, y marcos sin conexión, que dependen de un activo humano en el lugar. A pesar del uso de varias técnicas para violar el sistema aislados, para propagarse dentro de la red o para exfiltrar información robada, todos los frameworks comparten un objetivo común: espiar a su objetivo.

Descubrir y analizar este tipo de frameworks plantea desafíos únicos. A veces están compuestos por múltiples componentes que deben analizarse todos juntos para tener una imagen completa de cómo se están llevando a cabo realmente los ataques.

Además, los proveedores de seguridad como ESET confían en la telemetría para descubrir nuevas amenazas en los sistemas donde se ejecutan sus productos. Por definición, los sistemas que se ejecutan dentro de redes aisladas no envían dicha telemetría, lo que crea un punto ciego significativo que contribuye a aumentar el tiempo para el descubrimiento y detección de nuevo malware dirigido a redes aisladas.

Comprender cómo el malware ataca las redes aisladas puede ayudar a identificar y priorizar los mecanismos de detección y protección. Por ejemplo, vimos cómo todos los frameworks se basaban en unidades USB de una forma u otra para espiar los sistemas aislados, y ninguno de ellos usaba ningún otro tipo de canales de comunicación encubiertos contra los cuales las restricciones TEMPEST deberían implementarse.