El 12 de abril de 2022, CERT-UA y ESET informaron que un ciberataque físico afectó la tecnología operativa (OT) que respalda las operaciones de la red eléctrica en Ucrania. El ataque aprovechó diferentes piezas de malware, incluida una variante de INDUSTROYER, una conocida pieza de malware ICS orientada a ataques la cual se implementó originalmente en diciembre de 2016 para provocar cortes de energía en Ucrania.

El ataque es significativo no solo porque los ataques dirigidos a OT son raros, sino también porque esta es la primera instancia en la que el código de malware OT, orientado a ataques y ampliamente conocido, se volvió a implementar contra una nueva víctima. A pesar de cinco años de análisis sustancial de INDUSTROYER, por parte de una variedad de investigadores, el actor aún intentó reutilizar la herramienta y personalizarla para alcanzar nuevos objetivos. INDUSTROYER.V2 (el nombre de Mandiant para la nueva variante) refuerza la idea de que el malware OT se puede adaptar para su uso contra múltiples víctimas, lo que tiene serias implicaciones para otras familias de malware OT conocidas públicamente como INCONTROLLER.

Si bien gran parte de la historia que rodea la implementación de INDUSTROYER.V2 ya está disponible públicamente, Mandiant analizó, más a fondo, el malware para compartir información adicional para los defensores y la comunidad OT. En esta publicación de blog, documentamos detalles técnicos adicionales de INDUSTROYER.V2 en función de nuestro análisis de dos muestras diferentes. También proporcionamos reglas de detección para identificar actividades relacionadas.

Si necesita ayuda para responder a una actividad relacionada, comuníquese con el equipo de consultoría de Mandiant. El análisis adicional de las amenazas relacionadas, incluido el malware adicional que se implementó junto con INDUSTROYER.V2, está disponible como parte de Mandiant Advantage Threat Intelligence.

INDUSTROYER.V2 en pocas palabras

INDUSTROYER.V2 es similar a su predecesor, sin embargo, esta variante contiene una funcionalidad más específica. A diferencia del INDUSTROYER original, el cual era un marco que aprovechaba módulos externos para implementar cuatro protocolos OT diferentes, esta variante es autónoma y solo implementa el protocolo de comunicaciones IEC 60870-5-104 (IEC-104). IEC-104 se utiliza para monitorear y controlar el sistema de energía por medio del TCP y se implementa principalmente en Europa y Medio Oriente.

Lo que es más importante, la nueva variante de malware permite al actor incorporar configuraciones personalizadas las cuales modifican el comportamiento del malware en dispositivos electrónicos inteligentes (IED) específicos (por ejemplo, relés de protección, unidades de fusión, etc.) dentro del entorno de destino. El cambio de diseño para incorporar configuraciones personalizadas en INDUSTROYER.V2 reduce el esfuerzo requerido por el actor para reproducir el ataque contra diferentes entornos de víctimas y le permite contener el impacto en IED específicos.

Dos muestras personalizadas de INDUSTROYER.V2 muestran la amplitud del ataque

Para comprender completamente las implicaciones de las nuevas capacidades de personalización en INDUSTROYER.V2, analizamos y comparamos dos muestras diferentes. La segunda muestra, la cual probablemente sea una versión recompilada, está disponible públicamente y en plataformas de escaneo de malware en línea (MD5: 7c05da2e4612fca213430b6c93e76b06).

Creemos que ambas muestras están relacionadas con la misma operación. Los registros de fechas de la compilación tenían minutos de diferencia y aproximadamente dos semanas antes del ataque previsto. Es posible que el actor estuviera modificando la configuración del malware para personalizar la carga útil para diferentes objetivos.

Cada muestra contiene diferentes configuraciones codificadas dentro del binario. Una muestra contiene ocho direcciones IP de destino codificadas de forma rígida únicas, mientras que la otra solo contiene tres.

En ambas muestras, el malware finalizó un proceso específico. Sin embargo, la ruta de archivo definida, utilizada para concatenar con el proceso, difería entre las dos muestras. Esto muestra una comprensión matizada del entorno de la víctima.

La Ilustración 1 muestra un ejemplo de configuración de INDUSTROYER.V2 para la muestra disponible públicamente.

En función de las ligeras diferencias entre ambas muestras, podemos inferir detalles adicionales sobre la escala del ataque, el nivel probable de acceso que tenía el actor dentro de las redes de la víctima y el reconocimiento el cual probablemente realizó el atacante antes de la implementación del malware.

• Como muestran los detalles embebidos en las configuraciones del malware, el actor realizó al menos un reconocimiento de la red interna para identificar IED específicos en los entornos de las víctimas y comprender cómo acceder a ellos.
• Las configuraciones de malware atacan a dispositivos por medio de subredes específicas, destacando que el actor logró identificar y penetrar en las redes circundantes.
• La implementación exitosa de IEC-104, por parte del actor para interactuar con los dispositivos objetivo, indica una comprensión sólida del protocolo y el conocimiento del entorno de la víctima. Por ejemplo, en las muestras que analizamos, el actor manipuló una lista seleccionada de direcciones de objetos de información (IOA), los cuales se utilizan para interactuar con interruptores de línea eléctrica o disyuntores en una unidad terminal remota (RTU) o configuración de relé.

• Por el contrario, el propio código de malware muestra cierto grado de descuido o posibles limitaciones de tiempo. Por ejemplo, las muestras de INDUSTROYER.V2 contienen métodos limitados de ofuscación y evasión de defensa. La falta de ofuscación en los binarios brinda a los defensores sugerencias rápidas sobre su funcionalidad y capacidad para atacar a los activos de OT.

Panorama

Los marcos extensibles, como INDUSTROYER e INCONTROLLER originales, a menudo son preferidos por los actores de amenazas debido a la flexibilidad de su diseño modular, lo que permite el despliegue de cargas útiles específicas para atacar a diferentes activos de víctimas o protocolos de comunicación. Sin embargo, en el caso de INDUSTROYER.V2, el actor volvió a implementar solo uno de los componentes originales del marco anterior y creó un nuevo ejecutable autónomo.

No está claro por qué el actor de amenazas realizó las modificaciones particulares a INDUSTROYER.V2. Quizás el actor quería desarrollar una versión más simplificada para dirigirse a un entorno muy específico, o no quería exponer herramientas más valiosas o capaces; o simplemente creía que este enfoque sería eficiente ya que no requeriría recursos adicionales para impactar en el objetivo.

Independientemente de las motivaciones, la reutilización de código de malware OT conocido destaca el valor de la caza y las detecciones basadas en indicadores conocidos. Por ejemplo, algunas detecciones que construimos para el INDUSTROYER original identificaron con éxito INDUSTROYER.V2 “in the wild”. Si bien a menudo se cree que es probable que el malware OT no se utilice en más de un entorno, las herramientas que aprovechan las características de OT, inseguras por diseño, como INDUSTROYER.V2 se pueden emplear varias veces para atacar a múltiples víctimas. La comunidad de seguridad de OT debe reconocer estas herramientas como marcos o capacidades y no simplemente como características de incidentes de ciberseguridad aislados y herramientas de un solo uso.

Análisis técnico de INDUSTROYER.V2

INDUSTROYER.V2 está escrito en C++ e implementa el protocolo IEC-104 para modificar el estado de las unidades terminales remotas (RTU) sobre TCP. Los clientes TCP del protocolo IEC-104 se denominan estaciones de control y los servidores TCP se denominan estaciones remotas. El malware crea mensajes configurables de la unidad de datos de servicio de aplicación (ASDU) IEC-104, también conocidos como telegramas, para cambiar el estado de las direcciones de objetos de información (IOA) de una estación remota a ON u OFF. Los IOA identifican un elemento de datos específico en un dispositivo y pueden corresponder a interruptores de línea de alimentación o disyuntores en una RTU o configuración de relé.

El malware es un ejecutable autónomo en el que el operador puede establecer parámetros de configuración para atacar a estaciones remotas específicas, definir opciones de ejecución y crear mensajes ASDU. También acepta los argumentos de línea de comando opcionales (-o) para imprimir mensajes de depuración en un archivo de salida o (-t) para crear un retraso de tiempo antes de la ejecución.

Capacidades de configuración

Después de analizar los argumentos de la interfaz de la línea de comandos, INDUSTROYER.V2 itera por medio de las entradas de configuración embebidas. La ejecución del programa es altamente configurable. Según nuestro análisis de dos muestras de INDUSTROYER.V2, el malware contiene entradas de configuración estructuradas como cadenas en el orden que se muestra en la Tabla 1.

En la Ilustración 2 se presenta un ejemplo de entrada de configuración extraída de la muestra 7c05da2e4612fca213430b6c93e76b06.

Si la entrada de configuración 4 está habilitada, el malware crea telegramas ASDU para enviar comandos Select y Execute y modificar el estado IOA de una estación remota como OFF. Los rangos de IOA a los que se envían estos telegramas se proporcionan en las entradas de configuración 5 y 6. Sin embargo, esta opción no estaba habilitada en las muestras recuperadas. En el Apéndice se incluye una asignación de configuración con el ejemplo de la Ilustración 2.

Todas las configuraciones que examinamos tenían las siguientes opciones habilitadas: Finalización del proceso, cambio de nombre del archivo y uso de entradas de datos ASDU. Las entradas de datos ASDU se utilizan para elaborar mensajes ASDU específicos a la estación remota y la entrada de datos está estructurada en el formato que se muestra en la Tabla 2.

Después de analizar cada entrada de configuración, INDUSTROYER.V2 enlista los procesos en ejecución con el fin de identificar si se está ejecutando un proceso codificado específico y lo finaliza. Una vez que se detiene este proceso, el malware vuelve a enlistar los procesos en ejecución y finaliza cualquier proceso especificado por el operador en la configuración.

Si la opción de cambio de nombre de archivo está habilitada, el malware crea una ruta de archivo utilizando sus datos de configuración y agrega una extensión .MZ a este archivo. Esta puede ser una técnica para evitar que se reinicie el proceso especificado finalizado anteriormente.

Para cada entrada de configuración, se crea un hilo el cual implementa la comunicación IEC-104 con el sistema controlado. IEC-104 utiliza la especificación de la unidad de datos de protocolo de aplicación (APDU).

Una trama de APDU puede estar compuesta simplemente por una trama de información de control de protocolo de aplicación (APCI); o un encabezado APCI y una trama subsiguiente de la unidad de datos de servicio de aplicación (ASDU).

Ejecución

INDUSTROYER.V2 primero envía mensajes de función de control, los cuales están contenidos dentro de un marco APCI. El primer mensaje de control es un “Test Frame” (TESTFR). El malware envía un TESTFR ACT a la estación remota la cual verifica una conexión establecida. Si existe, una estación remota responde con un TESTFR CON correspondiente.

A continuación, el malware abre un canal de transferencia de datos con la estación remota utilizando un tipo de mensaje de control posterior “Start Data Transfer” (STARTDT). De manera predeterminada, la transferencia de datos no está habilitada en una conexión activa entre una estación de control y una estación remota. Por lo tanto, el malware envía un STARTDT ACT para activar un canal de transferencia de datos y una estación remota envía un STARTDT CON correspondiente para confirmar una activación exitosa.

Con la transferencia de datos habilitada, el malware utiliza un marco ASDU para enviar comandos posteriores a la estación remota. Los mensajes ASDU, también conocidos como telegramas, son un conjunto de funciones de aplicación definidas por IEC-104 para monitorear y controlar estaciones remotas.

El malware envía un comando General Interrogation, el cual le permite obtener el estado actual de las señales digitales y analógicas monitoreadas de la estación remota. Posteriormente, el malware utiliza entradas de datos ASDU embebidas para crear un comando específico con el fin de modificar el IOA del objetivo a ON u OFF.

Estos comandos se elaboran utilizando opciones definidas dentro de su configuración y la entrada de datos ASDU individual. Por ejemplo, en la configuración que extrajimos de la muestra 7c05da2e4612fca213430b6c93e76b06 (presentada en la Ilustración 2), la primera entrada de datos de ASDU es:

• 1104 0 0 0 1 1

Según la entrada de configuración 15 (estado OFF), la entrada 16 (opción Disable Change) y sus valores de entrada de ASDU (descritos en la Tabla 2), el malware crea un paquete de ASDU con las siguientes características:

• Dirección del objeto de información: 1104
• Tipo de mensaje ASDU: C-DC_NA_1 (comando doble)
• Tipo de comando ASDU: Ejecutar
• Establecer valor de estado: OFF

El mensaje ASDU se muestra en el tráfico de red decodificado en la Ilustración 4.

Para cada estación remota objetivo, en una entrada de configuración, el malware itera por medio de las entradas de datos ASDU correspondientes, elabora telegramas específicos y los envía a la estación remota. Los ajustes de configuración del malware pueden indicarle que elabore un mensaje ASDU adicional, el cual invierte el estado ON/OFF en un comando y envía este mensaje adicional al IOA de la estación remota.

Una descripción de alto nivel de la secuencia de comunicación es la siguiente:

1. Envíe mensajes Test Frame para verificar una conexión establecida
2. Envíe mensajes Start Data Transfer para abrir un canal de transferencia de datos
3. Enviar un comando General Interrogation obteniendo el estado de la estación remota
4. Envíe tipos de comandos simples o dobles diseñados para modificar el estado del IOA de la estación remota

La Ilustración 5 ilustra la secuencia de mensajes descrita, capturada entre INDUSTROYER.V2 y una estación remota IEC-104 emulada en laboratorio. Muestra los comandos iniciales TESTFR, STARTDT e Interrogation, seguidos de los comandos ASDU elaborados y entregados a los IOA de las estaciones remotas específicas.

La naturaleza detallada de cómo se ataca a una estación remota específica, hasta los IOA únicos y el estado en que cada IOA debe modificarse para crear un efecto previsto, demuestra una comprensión integral o visibilidad del entorno de la víctima.

Notamos que, aunque los IOA atacados por el malware pueden proporcionar un contexto importante para la intención precisa del actor, las asignaciones de IOA a menudo difieren entre fabricantes, dispositivos e incluso usuarios. Por esta razón, la interpretación precisa de las acciones previstas por el actor requiere un conocimiento adicional sobre los activos objetivo.

Si bien en este momento no tenemos dicha información, exploramos posibles coincidencias de IOA en función de la documentación disponible públicamente sobre productos específicos. Por ejemplo, sabiendo que los RTU y los relés de ABB están muy desplegados en la región objetivo, realizamos un análisis de fuente abierta. En nuestro ejemplo anterior, observamos un IOA equivalente a 1104, el cual posteriormente, mapeamos a la documentación pública del producto de un “ABB Distribution Recloser Relay” correspondiente a "50BFT: InStr status".

En este estado, 50 es el número ANSI para el disyuntor, que es como se enumeran los elementos del relé cuando se configura un relé de protección. Entonces 50BFT significa protección contra fallas del interruptor automático. Proporcionamos un apéndice el cual ilustra el mapeo adicional de IOA extraídos de la configuración de la muestra pública INDUSTROYER.V2 contra el mismo “Distribution Recloser Relay”.

Se superpone con la variante INDUSTROYER anterior

Las dos versiones de INDUSTROYER contienen superposiciones en el código y similitudes en el flujo de ejecución y la funcionalidad. Identificamos las siguientes características compartidas en ejecución y funcionalidad:

• Ambas versiones contienen un código el cual, primero, finaliza un proceso específico en la estación del controlador de la víctima, antes de establecer la comunicación IEC-104.
• Ambas versiones elaboran mensajes ASDU específicos de acuerdo con los ajustes de configuración proporcionados.
• Ambas versiones contienen la capacidad de entregar mensajes ASDU predefinidos a un rango IOA específico.
• Ambas versiones contienen una opción para dirigir el malware para crear un mensaje ASDU adicional el cual invierte el comando ON/OFF anterior y lo envía a la estación remota de destino.

Una diferencia que identificamos entre ambas variantes es que, a diferencia de su predecesor, INDUSTROYER.V2 contiene mensajes de depuración alterados los cuales ofuscan el significado de los resultados. Sin embargo, notamos que estos mensajes de depuración están formateados e impresos en puntos de ejecución similares de funciones clave. Además, la ofuscación no se implementó en partes clave del código IEC-104 los cuales se reutilizan en ambas versiones, lo que nos permite visualizar las superposiciones.

Por ejemplo, ambas versiones de INDUSTROYER utilizan un código muy similar para analizar el tráfico de APDU e imprimir campos analizados específicos. La Ilustración 6 es una captura de pantalla de INDUSTROYER.V2 la cual se muestra a la izquierda y a la derecha una captura de pantalla del INDUSTROYER original.

Existen superposiciones notables y adicionales de código entre las dos versiones en la implementación de la creación de marcos ASDU, el envío de mensajes APDU, la ejecución de opciones de cambio y la configuración de subprocesos para la funcionalidad IEC-104.

Apéndice: Reglas YARA

Apéndice: Ejemplo de configuración asignada

Apéndice: Ejemplos de IOA del mapeo de muestra disponible públicamente a un ABB Distribution Recloser Relay

Agradecimientos

Esta investigación fue posible gracias al arduo trabajo de muchas personas que no figuran en la línea de autor. Muchas gracias a CERT UA y ESET. Un agradecimiento especial a Josh Triplett, Conor Quigley y Wesley Mok.