Nueva versión del malware Industroyer utilizada en ataque contra proveedor de energía en Ucrania

Esta es una historia en desarrollo y el blog se actualizará a medida que haya nueva información disponible.

Resumen ejecutivo

Este artículo presenta el análisis de un ciberataque dirigido a un proveedor de energía ucraniano.

Industroyer2: Industroyer recargado

Investigadores de ESET respondieron a un incidente de seguridad que afectó a un proveedor de energía en Ucrania. Trabajamos en estrecha colaboración con el CERT-UA (Centro de respuesta a incidentes de Ucrania) para remediar y proteger la red de esta infraestructura crítica.

El trabajo dio como resultado el descubrimiento de una nueva variante del malware Industroyer, que junto con el CERT-UA llamamos Industroyer2; consulte la publicación de CERT-UA aquí. Industroyer es un malware que fue utilizada en 2016 por el grupo de APT Sandworm para cortar el suministro eléctrico en Ucrania.

Los atacantes detrás de Sandworm intentaron implementar el malware Industroyer2 contra subestaciones eléctricas de alto voltaje en Ucrania.

Además de Industroyer2, Sandworm utilizó varias familias de malware destructivas, incluidas CaddyWiper, ORCSHRED, SOLOSHRED y AWFULSHRED. Descubrimos por primera vez a CaddyWiper el 14 de marzo de 2022 cuando se usó contra un banco ucraniano y se usó nuevamente una variante de este malware el 08/04/2022 a las 14:58 contra el proveedor de energía ucraniano mencionado anteriormente.

En este punto, no sabemos cómo los atacantes lograron el compromiso inicial ni cómo fue que se movieron de la red de TI a la red del Sistema de control industrial (ICS). La figura 1 muestra una descripción general de los diferentes malware del tipo wiper que fueron utilizados en este ataque.

Figura 1. Vista general de los componentes

La Figura 2 resume la cadena de eventos.

Figura 2. Línea de tiempo de los eventos.

En 2017, los investigadores de ESET revelaron que una pieza de malware llamada Industroyer que fue responsable de un apagón que afectó a la capital de Ucrania, Kiev, en diciembre de 2016.

Como explicamos en nuestro whitepaper sobre Industroyer en el cual detallamos cómo funciona esta amenaza para sistemas de control industrial, este malware es capaz de interactuar con sistemas de control industrial que normalmente se utilizan en los sistemas de energía eléctrica. Esto incluye las siguientes tecnologías IEC-101, IEC-104, IEC 61850 y OPC DA.

En aquel momento dijimos que "era muy poco probable que alguien pueda escribir y probar un malware como ese sin tener acceso al equipamiento especializado que se utiliza en el entorno industrial específico". Esto fue confirmado en 2020 por el gobierno de los Estados Unidos cuando seis oficiales de la Unidad Militar Rusa 74455 de la Dirección General de Inteligencia (GRU) fueron acusados ​​por su papel en múltiples ataques cibernéticos, incluidos Industroyer y NotPetya. Para más información consulte la acusación en Justice.gov y nuestro reseña histórica de las operaciones de Sandworm.

El malware descubierto recientemente es una nueva variante de Industroyer, de ahí el nombre Industroyer2.

Industroyer2

Industroyer2 se desplegó como un único ejecutable de Windows llamado 108_100.exe y se ejecutó mediante una tarea programada el 2022-04-08 a las 16:10:00 UTC. Se compiló el 23 de marzo de 2022, según el timestamp del PE, lo que sugiere que los atacantes habían planeado su ataque durante más de dos semanas.

Figura 3. Marca de tiempo e información del compilador

Industroyer2 solo implementa el protocolo IEC-104 (también conocido como IEC 60870-5-104) para comunicarse con equipos industriales. Esto incluye protección de relés utilizados en subestaciones eléctricas. Este es un ligero cambio con respecto a la variante Industroyer de 2016, que es una plataforma completamente modular con payloads para múltiples protocolos de sistemas de control industrial.

Industroyer2 comparte varias similitudes de código con el payload 104.dll de Industroyer. Consideramos con mucha confianza que la nueva variante se creó utilizando el mismo código fuente.

Industroyer2 es altamente configurable. Contiene una configuración detallada hardcodeada en su cuerpo, que impulsa las acciones del malware. Esto es diferente de Industroyer que almacena la configuración en un archivo .INI separado. Por lo tanto, los atacantes deben volver a compilar Industroyer2 para cada nueva víctima o entorno. Sin embargo, dado que la familia de malware Industroyer* solo se desplegó dos veces, con un lapso de cinco años entre cada versión, esto probablemente no sea una limitación para los operadores de Sandworm.

El nuevo formato de configuración se almacena como una string que luego se suministra a la rutina de comunicación IEC-104 del malware. Industroyer2 puede comunicarse con múltiples dispositivos a la vez. Específicamente, la muestra analizada contiene ocho direcciones IP diferentes de dispositivos; consulte la Figura 4.

Figura 4. Configuración hardcodeada que encontramos en la muestra de Industroyer2

La configuración contiene valores que se utilizan durante la comunicación a través del protocolo IEC-104, como la dirección ASDU, que se refiere a Unidad de Datos de Servicios de Aplicación (Application Service Data Unit), así como direcciones de Objetos de Información (IOA), tiempos de espera, etc.

Antes de conectarse a los dispositivos apuntados, el malware finaliza un proceso legítimo que se utiliza en las operaciones diarias estándar. Además de eso, cambia el nombre de esta aplicación agregando .MZ al nombre del archivo. Lo hace para evitar el reinicio automático de este proceso legítimo.

El análisis aún está en curso para determinar cuáles son las acciones exactas tomadas para cada dispositivo. Creemos que este componente puede controlar sistemas de control industrial específicos para provocar un corte de energía.

Industroyer2 puede producir un archivo de registro o enviar su progreso a la ventana de la consola. Sin embargo, en lugar de mensajes de texto significativos como en la versión anterior, el malware escribe varios códigos de error; consulte la Figura 5. Creemos que es un intento de ofuscación por parte de los desarrolladores de Sandworm para dificultar el análisis.

Figura 5. Output producido por el malware Industroyer2 (direcciones IP redactadas por ESET)

CaddyWiper

En coordinación con el despliegue de Industroyer2 en la red de un Sistema de Control Industrial (ICS), los atacantes desplegaron una nueva versión del malware destructivo CaddyWiper. Creemos que la intención era hacer más lento el proceso de recuperación y evitar que los operadores de la compañía de energía recuperaran el control de las consolas ICS. También se desplegó en la máquina donde se ejecutó Industroyer2, probablemente para borrar cualquier rastro del malware.

La primera versión de CaddyWiper fue descubierta por investigadores de ESET en Ucrania el 14 de marzo de 2022 cuando se desplegó en la red de un banco. Se desplegó a través de un objeto de política de grupo (GPO, por sus siglas en inglés), lo que indica que los atacantes tenían control previo de la red de la víctima. El wiper borra datos del usuario y la información almacenada en las particiones de las unidades conectadas, lo que hace que el sistema quede inoperable e irrecuperable.

Nueva cadena para la carga CaddyWiper

En la red del proveedor de energía, los atacantes implementaron una nueva versión de CaddyWiper que utiliza un nuevo loader, denominado ARGUEPATCH por el CERT-UA. Se trata de una versión parcheada de un componente legítimo del software Hex-Rays de IDA Pro, específicamente el debugger de servidor remoto de IDA win32_remote.exe. No se supone que IDA Pro se use en un entorno ICS, ya que su objetivo principal es la ingeniería inversa de software, incluido el análisis de malware. No sabemos por qué los atacantes eligieron troyanizar esta pieza de software, podría ser un troll para los defensores.

ARGUEPATCH fue ejecutado por una tarea programada que estaba destinada a ser lanzada una vez el 2022-04-08 a las 14:58 UTC en una máquina y a las 16:20 UTC en la máquina donde se implementó Industroyer2.

El binario parcheado carga un shellcode cifrado de un archivo y lo descifra con una clave, ambos son proporcionados a través de la línea de comandos. Una clave XOR de un solo byte es derivada de la clave de entrada y se utiliza para descifrar el shellcode.

El shellcode descifrado es una versión ligeramente modificada de CaddyWiper. En la Figura 6 y la Figura 7 se proporciona una comparación de sus principales rutinas. Tenga en cuenta que no borran el controlador de dominio y borran C:\Users\ y los discos de D:\ a [:\. La rutina de borrado también es casi idéntica: llena todos los archivos con 0.

Figura 6. Rutina principal de la primera muestra de CaddyWiper.

Figura 7. Rutina principal de la muestra CaddyWiper desplegada en los sistemas del proveedor de energía

Finalmente, CaddyWiper llama a DeviceIoControl con IOCTL_DISK_SET_DRIVE_LAYOUT_EX y un InputBuffer puesto a cero para todos los discos desde \\PHYSICALDRIVE9 a \\PHYSICALDRIVE0. Esto borra la información extendida de las particiones de la unidad: el Master boot record (MBR) o la Tabla de Particiones GUID (GPT, por sus siglas en inglés). La máquina no podrá volver a arrancar.

Enumeración de Active Directory

Junto con CaddyWiper se encontró un script de PowerShell, tanto en la red del proveedor de energía como en el banco que había sido comprometido anteriormente con este malware.

Este script enumera objetos de política de grupo (GPO) utilizando la interfaz de servicio de Active Directory (ADSI). El script, que puede observarse en la Figura 8, es casi idéntico a un fragmento que fue compartido en una publicación en Medium.

Creemos que los atacantes implementaron CaddyWiper a través de un GPO y usaron el script para verificar la existencia de este GPO.

Figura 8. Script de PowerShell para enumerar GPO (embellecido)

Malware destructivo de Linux y Solaris (ORCSHRED, SOLOSHRED, AWFULSHRED)

En la red de la compañía de energía apuntada también se encontró malware destructivo dirigido a sistemas que corren Linux y Solaris. Son dos los componentes principales que se utilizan para llevar adelante este ataque: un gusano y un wiper. Este último se encontró en dos variantes, una para cada uno de los sistemas operativos de destino. Todo el malware se implementó en Bash.

El gusano

El primer componente lanzado por el atacante fue un gusano (también conocido en inglés como worm) cuyo archivo se llamaba sc.sh. Este script de Bash comienza agregando una tarea programada (cron job) para iniciar el componente que borra datos (wiper) a las 2:58pm UTC (asumiendo que el sistema está configurado en la hora local, UTC+3), a menos que haya sido lanzado con el argumento “owner”. Esta es probablemente una forma de evitar la autodestrucción del sistema inicial utilizado para lanzar el gusano.

Figura 9. Configuración de la terea programada para iniciar el wiper a las 5:58 p. m. El wiper correcto es elegido según el sistema operativo instalado.

Luego, la secuencia de comandos itera sobre las redes a las que puede acceder el sistema al observar el resultado de ip route o ifconfig -a. Siempre asume que se puede acceder a una red de clase C (/24) para cada dirección IP que recopila. Intentará conectarse a todos los hosts en esas redes usando desde SSH a los puertos TCP 22, 2468, 24687 y 522. Una vez que encuentra un servidor SSH accesible, prueba credenciales de una lista provista con el script malicioso. Creemos que el atacante tenía credenciales antes del ataque para permitir la propagación del wiper.

Si el sistema aún no ha sido comprometido, el malware se copia en el nuevo objetivo y se lanza el gusano. El gusano no se inicia con el argumento owner, por lo que el wiper está programado para iniciarse a las 2:58 p. m. UTC y destruir todos los datos. Si esos sistemas se configuraron en la zona horaria local, la destrucción debe haber comenzado al mismo tiempo que el sistema comprometido con CaddyWiper.

El wiper para Linux

La variante para Linux del wiper tiene variables ligeramente ofuscadas y los nombres de las funciones se reemplazaron con una palabra de 8 letras sin sentido. La mayoría de los valores literales también se reemplazaron con variables al principio del archivo.

Figura 10. Excepto por el script ofuscado (espacio en blanco optimizado).

Figura 11. Desofuscación de la anterior que fue obtenida al renombrar funciones y variables y usar literales

En última instancia, el wiper de Linux destruye todo el contenido de los discos conectados al sistema usando shred si está disponible o de lo contrario simplemente dd (con if=/dev/random). Si se conectan varios discos, la eliminación de datos se realiza en paralelo para acelerar el proceso.

Dependiendo del tamaño, el disco completo puede tardar horas en borrarse por completo. Para que el sistema deje de funcionar más rápido, primero intenta detener y deshabilitar los servicios HTTP y SSH. Los servicios se deshabilitan usando systemctl disabled. Para garantizar que el servicio no se vuelva a habilitar, el archivo de la unidad systemd responsable de cargar el servicio se elimina del disco.

Los archivos de /boot, /home y /var/log también, se eliminan antes de destruir las unidades totalmente. Esto hace que el sistema quede inoperable más rápido, elimina los datos del usuario y quizás elimine registros incriminatorios.

La última acción del script malicioso es iniciar a la fuerza un reinicio usando SysRq. Dado que todas las unidades están llenas de datos aleatorios, ningún sistema operativo se iniciará.

El wiper para Solaris

A diferencia del wiper para Linux, la variante para Solaris no está ofuscada.

Al igual que la variante para Linux, el script malicioso itera sobre todos los servicios para detenerlos y deshabilitarlos si contienen la palabra clave ssh, http, apache y,  además, ora_ u oracle. Es muy probable que esos servicios sean utilizados por aplicaciones utilizadas para manejar sistemas de control industrial. Eliminarlos evitaría que los operadores de la empresa energética puedan recuperar el control de las subestaciones y reviertan las acciones de Industroyer2.

Utiliza systemctl o svcadm dependiendo de lo que esté disponible. Lo último es lo más probable ya que Solaris no está ejecutando systemd.

La destrucción de archivos comienza con la eliminación de bases de datos. Elimina, usando shred y luego rm, todos los archivos y directorios contenidos en las variables de entorno que comienzan con ORA. Oracle Database utiliza las siguientes variables para definir la ubicación de los archivos y el software de la base de datos: ORACLE_BASE, ORACLE_HOME y ORACLE_PATH. Tenga en cuenta que shred se asegura de que la recuperación de los datos (sin una copia de seguridad) no sea posible.

Al igual que la variante de Linux, los archivos en /boot, /home y /var/log se eliminan con prioridad.

Luego, el script itera sobre los discos conectados al sistema, que se encuentran en /dev/dsk/. Ignora los segmentos (particiones) y funciona solo en discos completos. Para cada uno de ellos, el script malicioso sobrescribe el contenido completo mediante shred. Para minimizar el tiempo necesario para realizar el borrado, todos los discos se borran en paralelo.

Por último, el script se autodestruye.

Conclusion

Ucrania vuelve a estar en el centro de los ciberataques dirigidos a su infraestructura crítica. Esta nueva campaña de Industroyer surge luego de múltiples oleadas de wipers que han sido utilizados en ataques dirigidos a varios sectores en Ucrania. Los investigadores de ESET continuarán monitoreando el panorama de amenazas para proteger mejor a las organizaciones de este tipo de ataques destructivos.

Y muchas gracias a @_CERT_UA que trabajó con nosotros en este caso y proporcionó muestras. Puede leer su aviso sobre esta campaña aquí.

Indicadores de Compromiso