Los extraordinarios plugins BE2, sus ataques contra Siemens, y las fallas en su diseño

En nuestro artículo de noviembre presentamos nuestra investigación de BlackEnergy2 (BE2) y describimos los nuevos hallazgos sobre las actividades del grupo. Presentamos los detalles de sus plugins y los hallazgos sobre algunos de sus blancos y víctimas. En esta entrega, examinaremos de cerca varios plugins adicionales, nos concentraremos en los detalles sobre los ataques contra Siemens, y en algunas fallas de su inusual código.

Anteriormente presentamos un conjunto desconocido de seis plugins y funciones para la plataforma Linux. Para la plataforma Windows identificamos 17 plugins. En el último artículo notamos la dificultad de recopilación sobre este grupo. En este artículo completaremos las descripciones del conjunto.

bs
cert
dstr
s
grc
n
kl
prx
ps
d
scan
sn
ss
tv
upd
usb
vsnet

También recopilamos plugins para las arquitecturas MIPS/ARM, como anotamos en el anterior artículo sobre BE2.

weap
ps
nm
snif
hook
uper

Funciones extraordinarias

Primero examinemos algunos de los plugins para Windows más recientes y más sorprendentes. Resulta interesante que todos estos plugins utilizan una función personalizada “FindByHash” para evadir los esquemas de detección y ralentizar su análisis.

El plugin “Destroy”, dstr

El plugin más problemático en la lista es el “dstr”. Se trata de un plugin sólo para Windows. Se usa para que el actor BE2 re-escriba los contenidos de los archivos, y destruya los datos guardados en los discos duros. Si bien es posible que se lo use con la intención de borrar sus huellas en una red, resulta excesivo usar este tipo de herramientas para dicho fin. Muy probablemente sea una herramienta de sabotaje, muy parecida al limpiador Destover que atacó a las redes de Sony Pictures Entertainment. Sin embargo, resulta interesante que los desarrolladores de BE2 crearan con código limpiador distinto a Destover y a Shamoon que vimos en los ataques contra Saudi Aramco y SPE. En lugar de reutilizar los controladores comerciales EldoS RawDisk en su programa malicioso, los desarrolladores de BE2 escribieron sus propias rutinas de destrucción de archivos y discos de nivel bajo. El despliegue de los limpiadores es espeluznante, pues en lugar de enviarlo a un estudio de producción con bajas protecciones, fue enviado a ambientes de Control de Sistemas Industriales (ICS).

Para rescribir los datos almacenados en todas las versiones de Windows, el plugin dsrt soporta las funciones del limpiador en modo usuario y modo núcleo, lo que es sorprendente. El componente mantiene una librería embebida win32 y módulos de controlador win64 para el funcionamiento de su modo núcleo. Están cifrados con rc4.

Función modo usuario

El plugin identifica la identidad del dispositivo para el disco duro del sistema y crea un handle para la unidad física del sistema, con acceso GENERIC_READ o GENERIC_WRITE. Varias llamadas a DeviceIoControl recopilan datos sobre la localización física del volumen, y el tamaño y propiedades del disco. Tambien utiliza DeviceIoControl con el código de control IOCTL_DISK_GET_DRIVE_GEOMETRY para recuperar el valor Bytes Per Sector. dsrt, después limpia todos los handles abiertos al disco, desmontándolo con el código de control FSCTL_DISMOUNT_VOLUME.

Esta rutina prepara el sistema para ser rescrito y garantiza que no hayan conflictos para plugin archivo I/O. Después, realiza múltiples llamadas WriteFile para crear un buffer escrito en ceros en el disco.

El plugin dstr mantiene código para desbloquear y eliminar el controlador de BE2 del disco, contribuyendo al objetivo del grupo de esconder sus huellas de los ojos de los investigadores. Fíjense que en el conjunto de llamadas FindByHash de arriba, la llamada sfc_os deshabilita la protección de archivos de Windows por un minuto mientras una aplicación puede eliminar o modificar el archivo bloqueado. De esta manera, el plugin y su llamada pueden proceder a eliminar el controlador.

El plugin supervisa todos los servicios en la carpeta %system32%drivers y verifica los permisos de escritura. Si es posible el acceso, desbloquea el archivo, rescribe el controlador embebido bajo el nombre del controlador existente y lo ejecuta.

Controladores y función modo núcleo

Controlador descifrado 32-bit

Controlador descifrado 64-bit

Los controladores 32-bit y 64-bit son idénticos y se compilaron desde el mismo código fuente. Estos pequeños controladores Windows supuestamente soportan los sistemas de ficheros de FAT32 y NTFS, pero tienen dos grandes errores en la implementación de su código. A pesar de estos errores, queda claro que el objetivo del autor era analizar un sistema de archivos y de ahí escribir datos aleatorios en los archivos.

Errores extraordinarios

Estos errores en la implementación del código son exclusivos de este plugin dstr, lo cual sugiere el esfuerzo del equipo de desarrollo para el código del plugin.

Error #1.- Los autores invirtieron las rutinas de borrado de datos de FAT32 y NTFS cuando revisa si los caracteres “FAT32” están presentes en los primeros 1024-bytes del disco del sistema.

Error #2.- En la rutina de FAT32, el número de sector del directorio raíz se calcula y considera como el offset absoluto dentro del archivo, en vez de multiplicar este número por los bytes por sector.

En comparación, la rutina de NTFS no contiene este error, y el cálculo del offset MFT se implementa de forma apropiada:

Objetivo: Corromper el contenido de los archivos

Aparte de esto, es interesante que los autores implementaran la eliminacion de NTFS de una forma poco común, con una lógica extraña en comparación a la eliminacion ‘directa’ de FAT32. El plugin verifica los registros FILE y en un principio los salta. Después, bajo ciertas condiciones, rescribe los sectores alternos a los registros FILE con un buffer aleatorio que probablemente corresponde al contenido de algunos archivos y continua el bucle de ejecucion. Finalmente, termina de rescribir los primeros sectores de MFT y MFT mirror.

Plugin de sustitución de comunicaciones grc, plus.google.com

Este plugin crea un canal de comunicaciones de respaldo con otro servicio legítimo. Muy probablemente, este canal de respaldo se utiliza para ocultar comunicaciones salientes en las redes monitoreadas. Hemos visto APTs que usaban todo, desde Twitter hasta Google Docs, para ocultar las comunicaciones a plena vista; esta vez, el servicio abusado es Google Plus.

Este plugin implementa los servicios HTTP estándar de Windows para interactuar con Google Plus sobre HTTPS, en busca de un archivo png.

El plugin está provisto con una identidad específica de Google Plus, con la cual se conecta, y usa el API de Windows de almacenamiento estructurado de flujo OLE junto a las funciones GDI+ bitmap para manejar y analizar este archivo png. El contenido del archivo png es en realidad un conjunto de datos cifrados que contienen el nuevo archivo de configuración de BE tal como se lo obtuvo mediante la comunicación ‘normal’ con el C&C.  El contenido está cifrado con RC4, tal como los controladores dstr embebidos. Pero, a diferencia del esquema ‘típico’ de BE de descifrado RC4 que utiliza RC4 una sola vez, aquí utiliza RC4 tres veces: una vez con una llave de codificación estática localizada en el binario grc, la segunda usando la llave extraída del resultado previamente descifrado, y la tercera usando el identificador ‘id’ del equipo que normalmente sirve como la llave de cifrado durante la comunicación con el C&C.

Plugin de recopilación de datos USB

El plugin USB recopila toda la información disponible sobre dispositivos USB conectados, y escribe todos estos datos en un archivo de texto, lo empaca, y se lo provee el código principal BlackEnergy que se comunica con un servidor C&C.

Utiliza llamadas múltiples API para recopilar información sobre múltiples tipos de dispositivos USB conectados. Enumera todos los dispositivos USB conectados al sistema y recupera datos de todos ellos, incluyendo los dispositivos SCSI de almacenamiento masivo. Y, lo que es más interesante, puede ser la primera implementación de técnicas relacionadas con BadUSB en malware COTS (common off-the-shelf) rediseñado para APT que hemos visto circulando en Internet.

El código busca dispositivos SCSI directamente y les envía dos tipos de comandos SCSI. El primer comando con el código de operación 0x1A que corresponde a MODE SENSE puede que solo ocasione el registro de la llamada fallida (mensaje ‘SendSCSICommand return false’).

El segundo tipo de comando SCSI sigue siendo un misterio. Usa un código operativo 0xf0 indefinido y no hay evidencia directa de su propósito, ya que se supone que es específico al fabricante. Este misterioso código operativo se menciona en el mismo periodo de desarrollo del plugin en la investigación ofensiva de BadUSB http://algorithmics.bu.edu/twiki/bin/view/EC521/SectionA1/Group5FinalReport. Aquí, se nota en el tráfico USB generado por una herramienta controladora SMI. Para ser más específicos, hay dos llamadas con el código operativo 0xf0 en el código, cada una con sus propios parámetros. Uno de los parámetros, 0x2A, se menciona en el documento para regresar los caracteres que contienen la versión del firmware, el ID del flash NAND, y el número de parte del controlador. Pero esta información recibida no se registra en ninguna parte.

Asimismo, el código hace bucles para recuperar datos físicos detallados sobre cada dispositivo de almacenamiento conectado:

• número de cilindros
• tipo de dispositivo (floppy, disco duro fijo, dispositivos portátiles, etc.)
• número de pistas por cilindro
• sectores por pista
• número de bytes por sector
• tamaño del disco físico en bytes
• ID de instancia de dispositivo

Plugin BIOS de recopilación de datos de la tarjeta madre y el firmware

El plugin BIOS recopila información de bajo nivel del sistema infectado:

• BIOS
• tarjeta madre
• procesador
• sistema operativo

Utiliza varias técnicas para recopilar esta información:

• WMI
• CPUID
• win32 api

Como una aplicación cliente de Windows Management Instrumentation (WMI), inicializa COM y se conecta con el namespace rootcimv2 para usar el puntero IWbemServices y hacer peticiones WMI. El código ejecuta peticiones wql (“wql” es “sql para wmi”, un subconjunto de sql) para recopilar información del sistema de la víctima, como la petición “SELECT Description, Manufacturer, Name, ProcessorId FROM Win32_Processor”. A continuación, varias peticiones del código del BlackEnergy2 plugin:

• SELECT Description, Manufacturer, Name, ProcessorId FROM Win32_Processor
• SELECT Product, Manufacturer, Version FROM Win32_BaseBoard
• SELECT Name, OSArchitecture, Version, BuildNumber FROM Win32_OperatingSystem
• SELECT SerialNumber, Description, Manufacturer, SMBIOSBIOSVersion FROM Win32_BIOS

Estas llamadas wql le proporcionan al atacante datos como los que aparecen a continuación:

Descripción=Intel64 Family 6 Model 60 Stepping 3
Fabricante=GenuineIntel
Nombre=Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
ProcessorId=1FEAFBCF000116A9

Producto=7MPXM1
Fabricante=AsusTek
Versión=??

Nombre=Microsoft Windows 8.1 Pro
Arquitectura del sistema operativo=64-bit
Versión=6.3.9600
Número de compilación=9600

Número de serie=7DTLG45
Descripción=A12
Fabricante=AsusTek
SMBIOSBIOSVersion=A12

Esta selectividad es bastante inusual. Y el plugin no modifica su propio comportamiento basado en los valores recopilados. ¿Qué podemos inferir de la selección de sólo estos valores, que sólo están siendo recopilados y enviados a los atacantes? Estas son algunas posibilidades:

• Los atacantes pretenden evadir las cajas de ejecución (sandbox), honeypots, y ambientes falsos, y usan los datos recopilados para identificar el sistema infectado.
• Los atacantes tienen conocimiento previo del ambiente que pretenden penetrar, incluyendo las marcas de los equipos. O tienen una idea del tipo de hardware que esperan o desean ver. En los ambientes ICS y SCADA, estos detalles podrían ser muy valiosos para un atacante en estado de preparacion. Estos datos podrían ayudar a establecer la persistencia, evaluar la verdadera capacidad y recursos, ayudar a rastrear la fuente de los equipos, o ayudar siguientes movimientos laterales.
• Los atacantes no saben nada de la red que están penetrando. Están recopilando esta información para comprender dónde se ejecuta este plugin en el ambiente atacado y planificando sus próximos movimientos.

Al usar win32 API estándar, la aplicación implementa llamadas para recuperar información sobre la localidad del sistema. Curiosamente, hay un handle especial para una región nórdica en este particular plugin: “Norwegian-Nynorsk”.

La función de recopilación de datos del CPU, primero llama directamente a la instrucción cpuid de Intel. También maneja directamente sistemas multi-CPU y cada uno de sus conjuntos de funciones. Este soporte SMP está codificado de forma estática directamente en el plugin.

Detalles adicionales del ataque contra Siemens

Los detalles de los blancos de BE2 son interesantes. Cuando se enfocó en centros de investigación e instalaciones energéticas, el grupo vulneró a distancia los sistemas Simatic WinCC de Siemens. En estos casos, los atacantes intentaron forzar al proceso ccprojectmgr.exe a descargar y ejecutar una carga útil específica de BlackEnergy2. Analicemos un par de ejemplos de blancos. Dados los diferentes retrasos para el retorno, es posible que los ataques no eran automatizados.

Blanco A:

El primer intento de explotación de KSN se registró en marzo de 2014. Los atacantes volvieron a intentarlo en abril de 2014, aproximadamente 30 días y 2 horas después.

Blanco B:

El actor BE2 atacó entonces otro sistema en mayo de 2014 y fracasó; volvió a intentarlo en julio de 2014.

Entonces, parece que sus visitas son cíclicas, pero los volúmenes aquí son muy bajos para ser significativos.

En estos cuatro intentos contra dos blancos diferentes, los atacantes trataron de descargar su carga desde hxxp://94.185.85(dot)122/favicon.ico. La carga útil cambió de forma mínima desde marzo de 2014 hasta el fin de julio de 2014, presentando los siguientes md5(s). Todos estos descargadores son malware de BE2 que modifica un servicio de controlador de núcleo existente, como “ACPIEC”, y comienza a cargar el módulo núcleo de BE2. Vale la pena recalcar que los atacantes planeaban volver a utilizar el mismo C&C para el primer blanco, pero cambiaron el C&C de retrollamada para el segundo blanco. Ninguno de estos componentes está firmado:

fda6f18cf72e479570e8205b0103a0d3 → descarga df84ff928709401c8ad44f322ec91392, controlador, hilo depurador:”xxxxxxxx.pdb”. C2: 144.76.119.48 (DE, Hetzner Online AG, AS24940)
fe6295c647e40f8481a16a14c1dfb222 → descarga 39835e790f8d9421d0a6279398bb76dc, controlador, hilo depurador: “xxxxxxxx.pdb”. C2: 144.76.119.48 (DE, Hetzner Online AG, AS24940)
ac1a265be63be7122b94c63aabcc9a66 → descarga b973daa1510b6d8e4adea3fb7af05870, controlador. C2: 95.143.193.131 (SE, Internetport Sweden AB, AS49770)
8e42fd3f9d5aac43d69ca740feb38f97 → descarga f4b9eb3ddcab6fd5d88d188bc682d21d, controlador. C2: 46.165.222.6 (DE, Leaseweb Germany GmbH, AS16265)