El trabajo dio como resultado el descubrimiento de una nueva variante del malware\u00a0Industroyer<\/a>, que junto con el CERT-UA llamamos Industroyer2; consulte la publicaci\u00f3n de CERT-UA\u00a0aqu\u00ed<\/a>. Industroyer es un malware que fue utilizada en 2016 por el grupo de\u00a0APT Sandworm<\/a>\u00a0para cortar el suministro el\u00e9ctrico en Ucrania.<\/p>\n Los atacantes detr\u00e1s de Sandworm intentaron implementar el malware Industroyer2 contra subestaciones el\u00e9ctricas de alto voltaje en Ucrania.<\/p>\n Adem\u00e1s de Industroyer2, Sandworm utiliz\u00f3 varias familias de malware destructivas, incluidas CaddyWiper, ORCSHRED, SOLOSHRED y AWFULSHRED. Descubrimos por primera vez a\u00a0CaddyWiper<\/a>\u00a0el 14 de marzo de 2022 cuando se us\u00f3 contra un banco ucraniano y se us\u00f3 nuevamente una variante de este malware el 08\/04\/2022 a las 14:58 contra el proveedor de energ\u00eda ucraniano mencionado anteriormente.<\/p>\n En este punto, no sabemos c\u00f3mo los atacantes lograron el compromiso inicial ni c\u00f3mo fue que se movieron de la red de TI a la red del Sistema de control industrial (ICS). La figura muestra una descripci\u00f3n general de los diferentes malware del tipo wiper que fueron utilizados en este ataque.<\/p>\n Resumen de la cadena de eventos.<\/p>\n En 2017, los investigadores de ESET revelaron que una pieza de malware llamada Industroyer que fue responsable de un apag\u00f3n que afect\u00f3 a la capital de Ucrania,\u00a0Kiev, en diciembre de 2016<\/a>.<\/p>\n Como explicamos en nuestro whitepaper sobre\u00a0Industroyer<\/a>\u00a0en el cual detallamos c\u00f3mo 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\u00eda el\u00e9ctrica. Esto incluye las siguientes tecnolog\u00edas IEC-101, IEC-104, IEC 61850 y OPC DA.<\/p>\n En aquel momento dijimos que \u201cera 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\u00edfico\u201d. Esto fue confirmado en 2020 por el gobierno de los Estados Unidos cuando seis oficiales de la Unidad Militar Rusa 74455 de la Direcci\u00f3n General de Inteligencia (GRU) fueron acusados \u200b\u200bpor su papel en m\u00faltiples ataques cibern\u00e9ticos, incluidos Industroyer y\u00a0NotPetya<\/a>. Para m\u00e1s informaci\u00f3n consulte la acusaci\u00f3n en\u00a0Justice.gov<\/a>\u00a0y nuestro\u00a0rese\u00f1a hist\u00f3rica de las operaciones de Sandworm<\/a>.<\/p>\n El malware descubierto recientemente es una nueva variante de Industroyer, de ah\u00ed el nombre Industroyer2.<\/p>\n Industroyer2<\/strong><\/p>\n Industroyer2 se despleg\u00f3 como un \u00fanico ejecutable de Windows llamado\u00a0108_100.exe\u00a0y se ejecut\u00f3 mediante una tarea programada el 2022-04-08 a las 16:10:00 UTC. Se compil\u00f3 el 23 de marzo de 2022, seg\u00fan el timestamp del PE, lo que sugiere que los atacantes hab\u00edan planeado su ataque durante m\u00e1s de dos semanas.<\/p>\n Industroyer2 solo implementa el protocolo IEC-104 (tambi\u00e9n conocido como\u00a0IEC 60870-5-104<\/a>) para comunicarse con equipos industriales. Esto incluye protecci\u00f3n de\u00a0rel\u00e9s<\/a>\u00a0utilizados en subestaciones el\u00e9ctricas. Este es un ligero cambio con respecto a la variante Industroyer de 2016, que es una plataforma completamente modular con\u00a0payloads<\/em>\u00a0para m\u00faltiples protocolos de sistemas de control industrial.<\/p>\n Industroyer2 comparte varias similitudes de c\u00f3digo con el payload\u00a0104.dll\u00a0de Industroyer. Consideramos con mucha confianza que la nueva variante se cre\u00f3 utilizando el mismo c\u00f3digo fuente.<\/p>\n Industroyer2 es altamente configurable. Contiene una configuraci\u00f3n detallada hardcodeada en su cuerpo, que impulsa las acciones del malware. Esto es diferente de Industroyer que almacena la configuraci\u00f3n en un archivo\u00a0.INI\u00a0separado. Por lo tanto, los atacantes deben volver a compilar Industroyer2 para cada nueva v\u00edctima o entorno. Sin embargo, dado que la familia de malware Industroyer* solo se despleg\u00f3 dos veces, con un lapso de cinco a\u00f1os entre cada versi\u00f3n, esto probablemente no sea una limitaci\u00f3n para los operadores de Sandworm.<\/p>\n El nuevo formato de configuraci\u00f3n se almacena como una string que luego se suministra a la rutina de comunicaci\u00f3n IEC-104 del malware. Industroyer2 puede comunicarse con m\u00faltiples dispositivos a la vez. Espec\u00edficamente, la muestra analizada contiene ocho direcciones IP diferentes de dispositivos.<\/p>\n La configuraci\u00f3n contiene valores que se utilizan durante la comunicaci\u00f3n a trav\u00e9s del protocolo IEC-104, como la direcci\u00f3n ASDU, que se refiere a Unidad de Datos de Servicios de Aplicaci\u00f3n (Application Service Data Unit), as\u00ed como direcciones de Objetos de Informaci\u00f3n (IOA), tiempos de espera, etc.<\/p>\n Antes de conectarse a los dispositivos apuntados, el malware finaliza un proceso leg\u00edtimo que se utiliza en las operaciones diarias est\u00e1ndar. Adem\u00e1s de eso, cambia el nombre de esta aplicaci\u00f3n agregando .MZ al nombre del archivo. Lo hace para evitar el reinicio autom\u00e1tico de este proceso leg\u00edtimo.<\/p>\n El an\u00e1lisis a\u00fan est\u00e1 en curso para determinar cu\u00e1les son las acciones exactas tomadas para cada dispositivo. Creemos que este componente puede controlar sistemas de control industrial espec\u00edficos para provocar un corte de energ\u00eda.<\/p>\n 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\u00f3n anterior, el malware escribe varios c\u00f3digos de error. Creemos que es un intento de ofuscaci\u00f3n por parte de los desarrolladores de Sandworm para dificultar el an\u00e1lisis.<\/p>\n CaddyWiper<\/strong><\/p>\n En coordinaci\u00f3n con el despliegue de Industroyer2 en la red de un Sistema de Control Industrial (ICS), los atacantes desplegaron una nueva versi\u00f3n del malware destructivo CaddyWiper. Creemos que la intenci\u00f3n era hacer m\u00e1s lento el proceso de recuperaci\u00f3n y evitar que los operadores de la compa\u00f1\u00eda de energ\u00eda recuperaran el control de las consolas ICS. Tambi\u00e9n se despleg\u00f3 en la m\u00e1quina donde se ejecut\u00f3 Industroyer2, probablemente para borrar cualquier rastro del malware.<\/p>\n La primera versi\u00f3n de CaddyWiper fue descubierta por investigadores de ESET en Ucrania el 14 de marzo de 2022 cuando se despleg\u00f3 en la red de un banco. Se despleg\u00f3 a trav\u00e9s de un objeto de pol\u00edtica de grupo (GPO, por sus siglas en ingl\u00e9s), lo que indica que los atacantes ten\u00edan control previo de la red de la v\u00edctima. El wiper borra datos del usuario y la informaci\u00f3n almacenada en las particiones de las unidades conectadas, lo que hace que el sistema quede inoperable e irrecuperable.<\/p>\n Nueva cadena para la carga CaddyWiper<\/strong><\/p>\n En la red del proveedor de energ\u00eda, los atacantes implementaron una nueva versi\u00f3n de CaddyWiper que utiliza un nuevo loader, denominado ARGUEPATCH por el CERT-UA. Se trata de una versi\u00f3n parcheada de un componente leg\u00edtimo del\u00a0software Hex-Rays de IDA Pro<\/a>, espec\u00edficamente el debugger de servidor remoto de IDA\u00a0win32_remote.exe. No se supone que IDA Pro se use en un entorno ICS, ya que su objetivo principal es la ingenier\u00eda inversa de software, incluido el an\u00e1lisis de malware. No sabemos por qu\u00e9 los atacantes eligieron troyanizar esta pieza de software, podr\u00eda ser un troll para los defensores.<\/p>\n 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\u00e1quina y a las 16:20 UTC en la m\u00e1quina donde se implement\u00f3 Industroyer2.<\/p>\n El binario parcheado carga un shellcode cifrado de un archivo y lo descifra con una clave, ambos son proporcionados a trav\u00e9s de la l\u00ednea de comandos. Una clave XOR de un solo byte es derivada de la clave de entrada y se utiliza para descifrar el shellcode.<\/p>\n El shellcode descifrado es una versi\u00f3n ligeramente modificada de CaddyWiper. En la siguientes figuras se proporciona una comparaci\u00f3n 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\u00e9n es casi id\u00e9ntica: llena todos los archivos con 0.<\/p>\n Finalmente, CaddyWiper llama a\u00a0DeviceIoControl\u00a0con\u00a0IOCTL_DISK_SET_DRIVE_LAYOUT_EX\u00a0y un\u00a0InputBuffer\u00a0puesto a cero para todos los discos desde\u00a0\\\\PHYSICALDRIVE9\u00a0a\u00a0\\\\PHYSICALDRIVE0. Esto borra la\u00a0informaci\u00f3n extendida<\/a>\u00a0de las particiones de la unidad: el Master boot record (MBR) o la Tabla de Particiones GUID (GPT, por sus siglas en ingl\u00e9s). La m\u00e1quina no podr\u00e1 volver a arrancar.<\/p>\n Enumeraci\u00f3n de Active Directory<\/strong><\/p>\n Junto con CaddyWiper se encontr\u00f3 un script de PowerShell, tanto en la red del proveedor de energ\u00eda como en el banco que hab\u00eda sido comprometido anteriormente con este malware.<\/p>\n Este script enumera objetos de pol\u00edtica de grupo (GPO) utilizando la interfaz de servicio de Active Directory (ADSI). El script, que puede observarse en la siguiente imagen, es casi id\u00e9ntico a un fragmento que fue compartido en una publicaci\u00f3n en Medium<\/a>.<\/p>\n Creemos que los atacantes implementaron CaddyWiper a trav\u00e9s de un GPO y usaron el script para verificar la existencia de este GPO.<\/p>\n Malware destructivo de Linux y Solaris (ORCSHRED, SOLOSHRED, AWFULSHRED)<\/strong><\/p>\n En la red de la compa\u00f1\u00eda de energ\u00eda apuntada tambi\u00e9n se encontr\u00f3 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 \u00faltimo se encontr\u00f3 en dos variantes, una para cada uno de los sistemas operativos de destino. Todo el malware se implement\u00f3 en Bash.<\/p>\n El gusano<\/strong><\/p>\n El primer componente lanzado por el atacante fue un gusano (tambi\u00e9n conocido en ingl\u00e9s como worm) cuyo archivo se llamaba\u00a0sc.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\u00e1 configurado en la hora local, UTC+3), a menos que haya sido lanzado con el argumento \u201cowner\u201d. Esta es probablemente una forma de evitar la autodestrucci\u00f3n del sistema inicial utilizado para lanzar el gusano.<\/p>\n Luego, la secuencia de comandos itera sobre las redes a las que puede acceder el sistema al observar el resultado de\u00a0ip route\u00a0o\u00a0ifconfig -a. Siempre asume que se puede acceder a una red de clase C (\/24) para cada direcci\u00f3n IP que recopila. Intentar\u00e1 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\u00eda credenciales antes del ataque para permitir la propagaci\u00f3n del wiper.<\/p>\n Si el sistema a\u00fan no ha sido comprometido, el malware se copia en el nuevo objetivo y se lanza el gusano. El gusano\u00a0no<\/em>\u00a0se inicia con el argumento\u00a0owner, por lo que el wiper est\u00e1 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\u00f3n debe haber comenzado al mismo tiempo que el sistema comprometido con CaddyWiper.<\/p>\n El wiper para Linux<\/strong><\/p>\n 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\u00eda de los valores literales tambi\u00e9n se reemplazaron con variables al principio del archivo.<\/p>\n En \u00faltima instancia, el wiper de Linux destruye todo el contenido de los discos conectados al sistema usando\u00a0shred<\/a>\u00a0si est\u00e1 disponible o de lo contrario simplemente dd (con if=\/dev\/random). Si se conectan varios discos, la eliminaci\u00f3n de datos se realiza en paralelo para acelerar el proceso.<\/p>\n Dependiendo del tama\u00f1o, el disco completo puede tardar horas en borrarse por completo. Para que el sistema deje de funcionar m\u00e1s r\u00e1pido, primero intenta detener y deshabilitar los servicios HTTP y SSH. Los servicios se deshabilitan usando\u00a0systemctl\u00a0disabled. Para garantizar que el servicio no se vuelva a habilitar, el archivo de la unidad\u00a0systemd\u00a0responsable de cargar el servicio se elimina del disco.<\/p>\n Los archivos de\u00a0\/boot,\u00a0\/home\u00a0y\u00a0\/var\/log\u00a0tambi\u00e9n, se eliminan antes de destruir las unidades totalmente. Esto hace que el sistema quede inoperable m\u00e1s r\u00e1pido, elimina los datos del usuario y quiz\u00e1s elimine registros incriminatorios.<\/p>\n La \u00faltima acci\u00f3n del script malicioso es iniciar a la fuerza un reinicio usando\u00a0SysRq<\/a>. Dado que todas las unidades est\u00e1n llenas de datos aleatorios, ning\u00fan sistema operativo se iniciar\u00e1.<\/p>\n El wiper para Solaris<\/strong><\/p>\n A diferencia del wiper para Linux, la variante para Solaris no est\u00e1 ofuscada.<\/p>\n Al igual que la variante para Linux, el script malicioso itera sobre todos los servicios para detenerlos y deshabilitarlos si contienen la palabra clave\u00a0ssh,\u00a0http,\u00a0apache\u00a0y, \u00a0adem\u00e1s,\u00a0ora_\u00a0u\u00a0oracle. Es muy probable que esos servicios sean utilizados por aplicaciones utilizadas para manejar sistemas de control industrial. Eliminarlos evitar\u00eda que los operadores de la empresa energ\u00e9tica puedan recuperar el control de las subestaciones y reviertan las acciones de Industroyer2.<\/p>\n Utiliza\u00a0systemctl\u00a0o\u00a0svcadm<\/a>\u00a0dependiendo de lo que est\u00e9 disponible. Lo \u00faltimo es lo m\u00e1s probable ya que Solaris no est\u00e1 ejecutando systemd.<\/p>\n La destrucci\u00f3n de archivos comienza con la eliminaci\u00f3n de bases de datos. Elimina, usando\u00a0shred\u00a0y luego\u00a0rm, todos los archivos y directorios contenidos en las variables de entorno que comienzan con\u00a0ORA. Oracle Database utiliza las\u00a0siguientes variables<\/a>\u00a0para definir la ubicaci\u00f3n de los archivos y el software de la base de datos:\u00a0ORACLE_BASE,\u00a0ORACLE_HOME\u00a0y\u00a0ORACLE_PATH. Tenga en cuenta que shred se asegura de que la recuperaci\u00f3n de los datos (sin una copia de seguridad) no sea posible.<\/p>\n Al igual que la variante de Linux, los archivos en\u00a0\/boot,\u00a0\/home\u00a0y\u00a0\/var\/log\u00a0se eliminan con prioridad.<\/p>\n Luego, el script itera sobre los discos conectados al sistema, que se encuentran en\u00a0\/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\u00a0shred. Para minimizar el tiempo necesario para realizar el borrado, todos los discos se borran en paralelo.<\/p>\n Por \u00faltimo, el script se autodestruye.<\/p>\n Conclusion<\/strong><\/p>\n Ucrania vuelve a estar en el centro de los ciberataques dirigidos a su infraestructura cr\u00edtica. Esta nueva campa\u00f1a de Industroyer surge luego de m\u00faltiples oleadas de wipers que han sido utilizados en ataques dirigidos a varios sectores en Ucrania. Los investigadores de ESET continuar\u00e1n monitoreando el panorama de amenazas para proteger mejor a las organizaciones de este tipo de ataques destructivos.<\/p>\n\n
![\"\"](\"https:\/\/www.fie.undef.edu.ar\/ceptm\/wp-content\/uploads\/2022\/04\/Figure-3-Timestamp-and-compiler-information..png\")
![\"\"](\"https:\/\/www.fie.undef.edu.ar\/ceptm\/wp-content\/uploads\/2022\/04\/Figure-4a-\u2013-Hardcoded-configuration-found-in-Industroyer2-sample.png\")
<\/p>\n![\"\"](\"https:\/\/www.fie.undef.edu.ar\/ceptm\/wp-content\/uploads\/2022\/04\/Figure-4b-\u2013-Hardcoded-configuration-found-in-Industroyer2-sample-1.png\")
![\"\"](\"https:\/\/www.fie.undef.edu.ar\/ceptm\/wp-content\/uploads\/2022\/04\/Figure-5.-Output-produced-by-Industroyer2-malware-updated-1.png\")
![\"\"](\"https:\/\/www.fie.undef.edu.ar\/ceptm\/wp-content\/uploads\/2022\/04\/Figure-6.-Main-routine-of-the-first-sample-of-CaddyWiper..png\")
![\"\"](\"https:\/\/www.fie.undef.edu.ar\/ceptm\/wp-content\/uploads\/2022\/04\/Figure-7.-Main-routine-of-the-CaddyWiper-sample-deployed-at-the-energy-provider..png\")
![\"\"](\"https:\/\/www.fie.undef.edu.ar\/ceptm\/wp-content\/uploads\/2022\/04\/Figure-8.-PowerShell-script-to-enumerate-GPO-beautified..png\")
![\"\"](\"https:\/\/www.fie.undef.edu.ar\/ceptm\/wp-content\/uploads\/2022\/04\/Figure-9.-Setting-up-the-cron-job-to-launch-the-wiper-at-5.58pm.-The-correct-wiper-is-picked-depending-on-the-installed-operating-system.-1024x607-1.png\")
![\"\"](\"https:\/\/www.fie.undef.edu.ar\/ceptm\/wp-content\/uploads\/2022\/04\/Figure-10.-Excerpt-from-the-obfuscated-script-whitespace-optimized..png\")
![\"\"](\"https:\/\/www.fie.undef.edu.ar\/ceptm\/wp-content\/uploads\/2022\/04\/Figure-11.-Deobfuscation-of-the-above-obtained-by-renaming-functions-and-variables-and-using-literals-1.png\")