campaña de ciberespionaje probablemente vinculada a OilRig

En 2024, investigadores de ESET descubrieron varias herramientas maliciosas en los sistemas utilizados por funcionarios del gobierno kurdo e iraquí. El grupo APT detrás de los ataques es BladedFeline, un actor de amenazas iraní que ha estado activo desde al menos 2017, cuando comprometió a funcionarios dentro del Gobierno Regional del Kurdistán (KRG). Este grupo desarrolla malware para mantener y ampliar el acceso dentro de las organizaciones en Irak y el GRK. Si bien este es nuestro primer blogpost sobre BladedFeline, descubrimos al grupo en 2023, después de que atacó a funcionarios diplomáticos kurdos con el backdoor Shahmaran, y anteriormente informamos sobre sus actividades en los informes de ESET APT Activity Q4 2023-Q1 2024 y Q2 2024-Q3 2024.

El conjunto de herramientas utilizadas en la reciente campaña muestra que, desde el despliegue de Shahmaran, BladedFeline ha seguido desarrollando su arsenal. Encontramos dos túneles inversos, diversas herramientas complementarias y, sobre todo, un backdoor que denominamos Whisper y un módulo IIS malicioso que denominamos PrimeCache. Whisper es un backdoor que se conecta a una cuenta de correo web comprometida en un servidor Microsoft Exchange y la utiliza para comunicarse con los atacantes a través de archivos adjuntos de correo electrónico. PrimeCache también sirve como backdoor: es un módulo IIS malicioso relacionado con lo que denominamos Grupo 2 en nuestro artículo de 2021 Anatomy of native IIS malware. Resulta significativo que PrimeCache también tenga similitudes con el backdoor RDAT utilizada por el grupo APT OilRig, alineado con Irán.

Basándonos en estas similitudes de código, así como en otras pruebas presentadas en este blogpost, evaluamos con confianza media que BladedFeline es un subgrupo de OilRig, un grupo APT alineado con Irán que persigue a gobiernos y empresas de Oriente Medio. Ya hemos informado anteriormente sobre otras actividades vinculadas a OilRig. Para evitar confusiones, desde entonces hemos refinado nuestro seguimiento de OilRig, y ahora rastreamos ambas operaciones bajo un subgrupo separado – Lyceum – dentro de OilRig.

BladedFeline ha trabajado constantemente para mantener el acceso ilícito a funcionarios diplomáticos kurdos, al tiempo que explotaba un proveedor regional de telecomunicaciones en Uzbekistán y desarrollaba y mantenía el acceso a funcionarios del gobierno de Irak. Este blogpost detalla los aspectos técnicos de los implantes iniciales entregados a los objetivos de BladedFeline, los vínculos entre las víctimas, y sienta las bases para asociar a este subgrupo con OilRig.

Puntos clave del blogpost:

• BladedFeline comprometió a funcionarios del Gobierno Regional del Kurdistán al menos desde 2017.
• Los implantes iniciales utilizados allí pueden rastrearse hasta OilRig.
• Descubrimos BladedFeline después de que sus operadores comprometieran a funcionarios diplomáticos kurdos con el backdoor de firma Shahmaran del grupo en 2023.
• Este grupo APT también se ha infiltrado en altos cargos del Gobierno de Irak.
• Evaluamos con confianza media que BladedFeline es un subgrupo dentro de OilRig.
• Analizamos dos túneles inversos (Laret y Pinar), un backdoor (Whisper), un módulo IIS malicioso (PrimeCache) y varias herramientas complementarias.

Visión general de BladedFeline

BladedFeline es un grupo de ciberespionaje alineado con Irán, activo desde al menos 2017 según la telemetría de ESET. Descubrimos al grupo en 2023 cuando desplegó su backdoor Shahmaran contra funcionarios diplomáticos kurdos. Shahmaran, llamado así por una criatura mítica mitad serpiente, mitad mujer del folclore iraní, es un ejecutable portable de 64 bits que encontramos en el directorio de inicio del objetivo. Este sencillo backdoor no utiliza ningún tipo de compresión o cifrado para las comunicaciones de red. Tras registrarse en el servidor de C&C, el backdoor ejecuta cualquier comando operador que se le proporcione, entre los que se incluyen la carga y descarga de archivos adicionales, solicitando atributos específicos de archivo y proporicionando API de manipulación de archivos y directorios.

Como demuestra el conjunto de herramientas de la campaña que describimos en este blogpost, desde el despliegue de Shahmaran, BladedFeline ha seguido desarrollando su malware con el fin de mantener y ampliar aún más su acceso al Gobierno Regional del Kurdistán y a los altos niveles del Gobierno de Irak. Descubrimos la campaña en 2024 tras encontrar el backdoor Whisper de BladedFeline, el backdoor PrimeCache IIS y un conjunto de herramientas poscompromiso en las redes de funcionarios diplomáticos kurdos, funcionarios del gobierno iraquí y un proveedor regional de telecomunicaciones en Uzbekistán.

Detectamos y recogimos una versión de Whisper y encontramos otra en VirusTotal, subida por un usuario de Irak. Son prácticamente idénticas, y pudimos determinar la identidad probable de quien las subió a VirusTotal, basándonos en los datos de la muestra de Whisper y otras muestras subidas con el mismo ID de remitente. PrimeCache, Flog (un webshell) y Hawking Listener (un implante en fase inicial que escucha en un puerto específico) fueron subidos a VirusTotal por el mismo remitente que subió las muestras de Whisper. Basándonos en el enlace de Whisper y en la proximidad temporal (ambos fueron subidos en cuestión de minutos) creemos que fue desplegado por BladedFeline a una víctima del gobierno de Irak. Algunas de las herramientas que se mencionan a continuación en la cronología se analizan más adelante en el informe (por ejemplo, Slippery Snakelet).

Cronología

2017-09-21 ● VideoSRV reverse shell on KRG system
           |
2018-01-30 ● RDAT backdoor on KRG system
           |
2019-07-09 ● Custom Plink on KRG system
           |
2021-05-01 ● Sheep Tunneler on KRG system
           |
2023-01-23 ● LSASS dumped on KRG system
           |
2023-02-01 ● Shahmaran backdoor on KRG system
           |
2023-03-25 ● First victim targeted at a telecommunications company in Uzbekistan
           |
2023-06-12 ● Shahmaran version 2 on KRG system for access maintenance
           |
2023-12-14 ● BladedFeline operators executing CLI commands on KRG system
           |
2023-12-16 ● Slippery Snakelet backdoor on KRG system
           |
2023-12-20 ● P.S. Olala (a PowerShell executor) on KRG system
           |
2023-12-20 ● PsExec on KRG system
           |
2024-01-07 ● Whisper backdoor on KRG system
           |
2024-02-01 ● Laret reverse tunnel on KRG system
           |
2024-02-20 ● Pinar reverse tunnel on KRG system
           |
2024-02-29 ● PrimeCache malicious IIS module uploaded to VirusTotal
           |
2024-03-11 ● Whisper version 2, Flog, and Hawking Listener uploaded to VirusTotal

Atribución

Nuestra atribución de esta campaña a BladedFeline se basa en lo siguiente:

• La campaña está dirigida a miembros del Gobierno Regional del Kurdistán, al igual que ataques anteriores realizados por BladedFeline.
• La actividad de ataque original dirigida a la organización KRG nos permitió identificar malware sucesivo, ya que BladedFeline ha intentado mantener y ampliar el acceso a la organización.
• Un análisis más detallado de los ataques nos llevó a identificar a la víctima de telecomunicaciones en Uzbekistán.
• Al mismo tiempo, investigar el backdoor Whisper nos ayudó a identificar a la víctima del Gobierno de la India.

Creemos que BladedFeline tiene como objetivo al Gobierno Regional del Kurdistán y al Gobierno de la India con fines de ciberespionaje, con la vista puesta en mantener el acceso estratégico a altos cargos de ambas entidades gubernamentales. La relación diplomática del GRK con las naciones occidentales, junto con las reservas de petróleo de la región del Kurdistán, lo convierten en un objetivo atractivo para que los actores de amenazas alineados con Irán espíen y potencialmente manipulen. En Irak, lo más probable es que estos actores intenten contrarrestar la influencia de los gobiernos occidentales tras la invasión y ocupación estadounidense del país.

Creemos con una confianza media que BladedFeline es un subgrupo de OilRig:

• Al igual que OilRig, BladedFeline tiene como objetivo organizaciones de Oriente Medio con fines de ciberespionaje.
• Hemos encontrado herramientas de OilRig (VideoSRV y RDAT) en un sistema comprometido del KRG.
• El módulo IIS malicioso PrimeCache de BladedFeline comparte similitudes de código con RDAT de OilRig.

BladedFeline no es el único subgrupo de OilRig que estamos vigilando: ya hemos estado siguiendo a Lyceum, también conocido como HEXANE o Storm-0133, como otro subgrupo de OilRig. Lyceum se centra en atacar a diversas organizaciones israelíes, incluidas entidades gubernamentales y de la administración local y organizaciones del sector sanitario. Las principales herramientas que atribuimos a Lyceum incluyen DanBot, los backdoors Shark, Milan y Marlin, Solar y Mango, OilForceGTX y una variedad de downloaders que utilizan servicios legítimos en la nube para la comunicación C&C.

Seguiremos utilizando el nombre OilRig para referirnos al grupo matriz, también conocido como APT34 o Hazel Sandstorm (antes EUROPIUM). OilRig es un grupo de ciberespionaje que lleva activo al menos desde 2014 y del que se cree que tiene su sede en Irán. Su objetivo son los gobiernos de Oriente Medio y diversos sectores empresariales, como el químico, el energético, el financiero y el de las telecomunicaciones. Las campañas de OilRig más destacadas incluyen la campaña de DNSpionage de 2018 y 2019, dirigida a víctimas en el Líbano y los Emiratos Árabes Unidos; la campaña HardPass de 2019-2020, que utiliza LinkedIn para atacar a víctimas de Oriente Medio en los sectores energético y gubernamental; el ataque de 2020 contra una organización de telecomunicaciones en Oriente Medio utilizando la puerta trasera RDAT; y los ataques de 2023 dirigidos a organizaciones en Oriente Medio con las puertas traseras PowerExchange y MrPerfectionManager.

Herramientas OilRig utilizadas por BladedFeline

Hemos encontrado dos herramientas OilRig en las máquinas del KRG comprometidas por BladedFeline.

RDAT

Hemos descubierto una versión del backdoor RDAT de OilRig de la que no se había informado anteriormente en dos sistemas víctimas del KRG. Al analizar el RDAT, descubrimos que el flujo operativo (véase el informe de la Unidad 42 para más detalles), la marca de tiempo de compilación (2017-12-26 10:49:35) y la hora de escritura del archivo (2018-01-30) coinciden con la actividad y los objetivos de OilRig, en particular con respecto a la actividad del grupo en 2017. Observamos un archivo con un SHA-1 de 562E1678EC8FDC1D83A3F73EB511A6DDA08F3B3D y una ruta de C:\Windows\System32\LogonUl.exe en ambos sistemas. La ruta PDB también corrobora que este binario es RDAT: C:\sers\Void\Desktop\RDAT\client\x64\Release\client.pdb. Hasta la fecha, sólo hemos observado RDAT en uso por OilRig. Además, no hemos visto ningún implante personalizado compartido entre OilRig y otros grupos de Oriente Medio, y rara vez ocurre entre actores de amenazas alineados con Irán.

El análisis que vincula RDAT con PrimeCache, un módulo malicioso de IIS que fue subido a VirusTotal presumiblemente por la víctima del Gobierno de la India, refuerza aún más la idea de que BladedFeline es un subgrupo de OilRig, al igual que Lyceum. Este vínculo se explora en mayor profundidad en la sección Vínculos con OilRig del blogpost.

VideoSRV

Un dato adicional sobre la conexión entre OilRig y BladedFeline es una shell inversa desplegada en una de las víctimas del Gobierno Regional del Kurdistán (21 de septiembre de 2017) antes de que RDAT cayera en el mismo sistema (30 de enero de 2018). VideoSRV (SHA-1: BE0AD25B7B48347984908175404996531CFD74B7), llamado así por su nombre de archivo videosrv.exe, tiene la cadena PDB C:\sers\v0id\Desktop\reverseShell\clientProxy\x64\Release\ConsoleApplication1.pdb, que tiene algunas similitudes con la cadena PDB RDAT C:\Users\Void\Desktop\RDAT\client\x64\Release\client.pdb.

Análisis técnico

Acceso inicial

Aún no está claro cómo BladedFeline desarrolla el acceso a sus víctimas. Lo que sabemos es que en el caso de las víctimas del GRK, los actores de la amenaza obtuvieron acceso al menos en 2017 y lo han mantenido desde entonces. En cuanto a las víctimas del GOI, sospechamos que el grupo explotó una vulnerabilidad en una aplicación en un servidor web orientado a Internet, lo que les permitió desplegar el webshell Flog.

Conjunto de herramientas

PrimeCache – módulo IIS malicioso

PrimeCache, cuyo nombre derivamos del RTTI AVRSAPrimeSelector y su nombre de archivo(cachehttp.dll), es un backdoor pasivo implementado como un módulo IIS nativo con un nombre interno de HttpModule.dll. Fue subido a VirusTotal por el mismo usuario que subió una de las muestras del backdoor Whisper. Es una DLL C++ de 64 bits con una fecha de compilación de 2023-05-14 06:55:52 y tiene una cadena PDB minimizada de sólo HttpModule.pdb. Tiene una única exportación: RegisterModule.

PrimeCache es el sucesor de una colección de backdoors IIS no atribuidos que hemos reportado previamente como Grupo 2 (backdoors IIS simples) en nuestro blogpost de 2021, Anatomy of native IIS malware. Obtuvimos esas muestras originales de VirusTotal, donde fueron subidas por usuarios de Bahréin, Israel y Pakistán, entre 2018 y 2020. Basándonos únicamente en la ubicación de las presuntas víctimas, es posible que esos casos también estuvieran relacionados con las actividades de BladedFeline -o, más ampliamente, OilRig-.

Funcionalidad principal

La funcionalidad principal de PrimeCache se implementa en el manejador CGlobalModule::OnGlobalPreBeginRequest. Se trata de una implementación única, a diferencia de sus predecesores, que utilizaban el controlador CHttpModule::OnBeginRequest. PrimeCache filtra las peticiones HTTP entrantes, procesando sólo las de los operadores BladedFeline, que son reconocidos por tener una cabecera cookie con la estructura

F=<command_ID>,<param>;

Tenga en cuenta que este valor puede ser independiente o estar incrustado en una cookie más larga, rodeada de caracteres de punto y coma (;).

El backdoor funciona de una forma inusual (nueva en esta versión en comparación con nuestro análisis de 2021). En lugar de aceptar un comando backdoor y todos sus parámetros en una única petición HTTP, cada acción se divide en varias peticiones. En primer lugar, el operador BladedFeline envía una solicitud individual para cada parámetro; estos parámetros se almacenan en una estructura global. A continuación, el operador envía otra petición para activar el comando backdoor. Por último, PrimeCache utiliza los parámetros recibidos anteriormente para ejecutar la acción especificada y, a continuación, borra los parámetros almacenados en caché.

Comandos de operador

Hay tres tipos de peticiones que pueden ser recibidas por el backdoor, como se muestra en la Tabla 1.

Tabla 1. Comandos de operador de PrimeCache

Una vez que la acción se activa (a través de <command_ID>=0), PrimeCache realiza una acción, basada en los parámetros obtenidos previamente, como se muestra en la Tabla 2. Una nota en la tabla de abajo:

La acción PrimeCache es comando de operador (OpCom) a, la clave de sesión es OpCom k, datos binarios es OpCom b, y el nombre de archivo es OpCom f.

Tabla 2. PrimeCache post-operador s

Cifrado

Al igual que sus predecesores, PrimeCache utiliza tanto RSA como AES-CBC para su comunicación C&C. Los parámetros y los valores de retorno siempre se cifran mediante AES-CBC utilizando la clave de sesión y, a continuación, se codifican en base64. La clave de sesión está encriptada con RSA; el backdoor tiene una clave RSA pública y otra privada codificadas (no un par) para manejar ambas direcciones de la comunicación.

Se utiliza una biblioteca Crypto++ vinculada estáticamente para manejar las operaciones de cifrado y descifrado.

Comunicaciones C&C

Los comandos del operador se transmiten en la cabecera de la cookie (otra desviación de las versiones anteriores, que utilizaban la URL o el cuerpo de la petición HTTP). Las respuestas PrimeCache se añaden al cuerpo de la respuesta HTTP. Si se está exfiltrando un archivo, el encabezado Content-Type se establece como attachment, igualando la funcionalidad de las versiones anteriores.

Los predecesores de PrimeCache también utilizaban el mismo esquema de cifrado y nombres de parámetros similares(a, c, f, k), pero todos se enviaban a la puerta trasera en una única petición. Los únicos comandos soportados eran r, u y d.

Vínculos con OilRig

Cuando comparamos PrimeCache con RDAT, como se describe en la subsección de atribución de RDAT, vemos varias similitudes que apoyan nuestra suposición de que BladedFeline es un subgrupo de OilRig.

• Tanto RDAT como PrimeCache utilizan la biblioteca Crypto++, y ambos analizan los comandos de puerta trasera utilizando la expresión regular [^,]+
  • La carga útil intenta analizar el texto claro descifrado utilizando la expresión regular [^,]+ para obtener el valor del comando y los argumentos del comando que se dividen con una coma.
• Ambos comparten una función, mostrada en la Figura 1, que ejecuta un comando shell y lee la salida, que, a través de nuestro corpus, sólo se encuentra en estas dos piezas de malware.

La puerta trasera Whisper

Whisper es un binario de Windows de 32 bits escrito en C#/.NET, cuyo nombre proviene de sus cadenas PDB G:\csharp\Whisper_Trojan_winform\Whisper_Trojan_winform\Whisper_Trojan_winform\obj\Release\Veaty.pdb y Z:\csharp\Whisper_Trojan_winform_for_release\Whisper_Trojan_winform\Whisper_Trojan_winform\obj\Release\Veaty.pdb. Utiliza un servidor Microsoft Exchange para comunicarse con los atacantes mediante el envío de archivos adjuntos de correo electrónico a través de una cuenta de correo web comprometida. Hemos visto dos versiones del backdoor: detectamos y recogimos una versión, y fue subida a VirusTotal desde Irak. Estas muestras son prácticamente idénticas, pero pudimos determinar la identidad probable de quien las subió a VirusTotal basándonos en los datos de la muestra de Whisper y otras muestras subidas por ese usuario.

Ambas versiones de Whisper tienen marcas de tiempo de compilación (2090-04-11 23:38:14 y 2080-12-11 03:50:47). Se compilan utilizando Costura, presumiblemente para garantizar que el sistema de la víctima utiliza las DLL empaquetadas con el binario y no las DLL de la caché global de ensamblados.

La operación de Whisper no es la primera vez que observamos que un subgrupo de OilRig utiliza servicios en la nube para su protocolo de C&C. Aunque, a diferencia de Whisper, no se enviaron correos electrónicos reales, Lyceum utilizó borradores de correo electrónico para la comunicación entre su malware y los operadores a lo largo de 2022, como describimos en una entrada anterior.

Workflow operativo

Whisper no requiere ni acepta argumentos. En su lugar, su dropper -al que hemos denominado Protocolo Whisper por su nombre de archivo, Protocol.pdf.exe- escribe su archivo de configuración en el disco junto con él (véase la sección Protocolo Whisper ). El archivo de configuración, que se muestra en la Figura 2, está en formato XML con sus cadenas de claves y valores codificadas en base64. Es llamado por la clase Specs de Whisper, que utiliza una función – DelockItems – para decodificar en base64 las variables de configuración.

La figura 3 muestra el workflow operativo de Whisper, que detallamos en los párrafos siguientes.

El workflow operativo de Whisper puede dividirse en siete pasos:

En el paso 1, Whisper utiliza las credenciales del archivo de configuración (línea 15 de la figura 2) y la clase ExchangeService de Microsoft Exchange Web Services para intentar iniciar sesión en las cuentas de correo web comprometidas. Una vez que Whisper inicia sesión con éxito en una cuenta, guarda las credenciales en la memoria y escribe lo siguiente en el archivo de registro c:\Windows\Temp\WindowsEventLogs.txt:

———— ItemContext is set: user name [<user_name>] , use_defaultCred: [credentials>]

Si no hay credenciales válidas en el archivo de configuración, Whisper registra los siguientes mensajes de error en el archivo de registro:

———————————- there was No Way to access any Mailbox.

__________ Extraction function is called.

Si se detecta un error inesperado, Whisper escribe lo siguiente en el archivo de registro (nótese el error ortográfico de la palabra happened, indicativo de un hablante no nativo de inglés) y sale utilizando el método Environment.Exit(Int32). Extrañamente, el exitCode utilizado, 0, indica que el proceso finalizó con éxito.

———————————-__ an unknown Exception happend. program turned off

A continuación, en el Paso 2, Whisper utiliza las credenciales del paso anterior para buscar reglas de bandeja de entrada utilizando el método ExchangeService.GetInboxRules (que [r]ecobra una colección de reglas de bandeja de entrada que están asociadas con el usuario especificado). Utilizando el valor de la línea 13 del archivo de configuración(key=”receive_sign”, value=”PMO”), Whisper itera sobre las reglas de la bandeja de entrada buscando que ese valor se especifique en uno de estos tres lugares: subject, body, o subjectorbody y que los correos que coincidan con ese valor se envíen a una ubicación especificada(deleteditems o inbox, dependiendo de la versión de Whisper). Si la bandeja de entrada tiene una regla de este tipo, Whisper pasa al siguiente paso; de lo contrario, Whisper crea una regla con los parámetros indicados:

• Rule name: MicosoftDefaultRules.
• Move to folder: deleteditems o inbox
  • Una versión de Whisper especifica la carpeta deleteditems; la otra apunta a la inbox. Ambos están codificados en los binarios separados.
• Mark as read: true.
• Condition: el subject contiene PMO
  • La ubicación para buscar el string, subject, está codificada en ambas versiones de Whisper. El string a buscar, PMO, se encuentra en el archivo de configuración utilizado por Whisper; no hemos podido obtener el otro archivo de configuración.

En el Paso 3, Whisper inicia un loop interminable que envía un mensaje de correo electrónico de confirmación desde la cuenta de correo electrónico comprometida en el Paso 1 a una dirección de correo electrónico especificada en el archivo de configuración (línea 16, key=”alive_mail”). El mensaje de check-in se envía cada 10 horas (línea 10 del archivo de configuración, key= “al_time”; en minutos), el asunto (línea 17, key=”alive_msg_subj”) es Content, y el cuerpo del mensaje contiene el string definida a continuación:

“Content ID: “ + base64_encode(“COMPUTERNAME:USERDNSDOMAIN:USERNAME”)

A continuación, en el paso 4, Whisper obtiene los comandos del operador. Para ello, busca en la bandeja de entrada identificada en el paso 1 archivos en una carpeta determinada(deleteditems o inbox, según la versión de Whisper) con archivos adjuntos cuyo asunto coincida con una cadena (suministrada en el archivo de configuración; PMO en el único archivo de configuración que recopilamos). Para los correos electrónicos con archivos adjuntos que coincidan, Whisper raspa el cuerpo del adjunto (que debería contener comandos cifrados) y almacena la dirección de correo electrónico del remitente para utilizarla posteriormente como servidor C&C al que se cargan los resultados de los comandos del operador.

En el paso 5, Whisper descifra los comandos del operador. Para ello, primero descodifica en base64 la cadena que contiene el comando y, a continuación, descifra el resultado utilizando la clase .NET AES con un vector de inicialización de 16 bytes y la clave de cifrado que se encuentra en el archivo de configuración (línea 18, key=”enc_key” value=”cXdlcmFzZHp4Y3ZmZ2d0aGhsZGZvZ2g/bHZtZ2xrZyE=”). Los comandos desencriptados tienen la forma <id_comando>;<comando_a_ejecutar>. El ID del comando, los comandos y la salida del comando se guardan en el siguiente formato:

base64-encoded(<command_id>: <cmd_id>cn<cmd_output>\n)

A continuación, en el paso 6, Whisper ejecuta los comandos backdoor y registra los resultados. Los posibles comandos incluyen:

Los datos escritos en el disco son

this is my file content

<filepath>

<filename>

<nbytes-to-write>

Los bytes a escribir están codificados en base64 (y decodificados antes de escribir en disco). La ejecución exitosa devuelve:

archifile received properly. wrote to: <filepath> <filename>

• Send a file to the C&C server

Este comando lleva el prefijo this is my required file path seguido de \n<unknown_variable>\n<filepath>\<filename>. Whisper lee el contenido del archivo en memoria, lo codifica en base64 y lo devuelve:

this is my required file <path>\n<unknown_variable>\n<filename>\n<base64_encoded_file_contents>.

• Ejecutar un script PowerShell

Este comando no tiene prefijo y en su lugar sólo contiene un comando en texto plano que PowerShell es capaz de ejecutar, postfixed con una pipe después de lo cual Whisper añade Out-String. La salida se guarda de esta forma:

base64-encoded(<command_id>: <cmd_id>\n<cmd_output>\n)

Finalmente, en el Paso 7, Whisper envía la salida del comando en un mensaje de correo electrónico a la bandeja de entrada del C&C encontrada en el Paso 4. El correo electrónico tiene el siguiente formato

• dirección de correo electrónico remitente: bandeja de entrada del Paso 1,
• destinatario: dirección de correo electrónico del Paso 4,
• asunto: Email(del archivo de configuración, línea 14, key=”send_sign”),
• cuerpo del mensaje: Hey there! find your results in the attachment (codificado en el binario), y
• adjunto: salida de los comandos del paso 6, cifrada con la misma clave de cifrado del paso 5 (archivo de configuración, línea 18, key=”enc_key” value=”cXdlcmFzZHp4Y3ZmZ2d0aGhsZGZvZ2g/bHZtZ2xrZyE=”).

Los pasos del 4 al 7 continúan en un loop utilizando el mismo programa de comprobación del paso 3 hasta que se cambien las credenciales codificadas en el archivo de configuración.

Backdoor Shahmaran

El backdoor Shahmaran, llamado así por una mítica criatura mitad serpiente, mitad mujer del folclore iraní, es un PE de 64 bits que se encontró en la carpeta de inicio como:

%ROAMINGAPPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\adobeupdater.exe

Al iniciar el sistema, Shahmaran crea un objeto de evento de Windows, SysPrep. Es posible que los desarrolladores de Shahmaran eligieran SysPrep como nombre del evento para mezclarse con el ruido de fondo, ya que SysPrep forma parte del proceso de creación de imágenes de Windows. Los administradores de Windows lo utilizan para crear una imagen estándar de Windows (a menudo denominada imagen Gold o Golden) antes de su despliegue en los sistemas de la empresa. La Figura 4 muestra el objeto de evento SysPrep en un sistema comprometido, visto por WinObj de Sysinternals.

El dominio del C&C está codificado, olinpa[.]com, al igual que el puerto, 80, y la cadena User-Agent, que son dos. La conexión inicial al C&C utiliza una cadena User-Agent incompleta (le falta el paréntesis de cierre):

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0

La comunicación posterior con el C&C utiliza la cadena User-Agent corregida:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

Shahmaran no utiliza ningún tipo de compresión o cifrado para las comunicaciones de red. Y aunque el puerto está codificado(80), hay fragmentos de código que comprueban el puerto en uso y actualizan las variables de comunicación si se utiliza el puerto 443.

Después de registrarse en el servidor de C&C, Shahmaran ejecuta cualquier comando de operador proporcionado, devuelve cualquier salida de esos comandos, luego duerme durante 30 segundos antes de registrarse de nuevo en el servidor de C&C, ad infinitum. La Tabla 3 muestra los comandos de operador disponibles y sus funciones.

Tabla 3. Comandos de operador y sus descripciones Comandos de operador y sus descripciones

Después de ejecutar un comando de operador, Shahmaran envía la salida al servidor de C&C utilizando el formato t=<comando_operador>&<salida_comando>, como t=1&s=<fecha_fecha_archivo>.

Backdoor Slippery Snakelet

Slippery Snakelet es un pequeño backdoor basado en Python con capacidades limitadas:

1. ejecuta un comando a través de cmd.exe,

2. descarga un archivo desde una URL, y

3. sube un archivo a la ruta /newfile/URI.

Slippery Snakelet tiene un servidor de C&C hardcoded, zaincell[.]store, y se comunica con él a través de URLs de la forma https://zaincell[.]store/request/<UID>, donde el <UID> es el dominio de inicio de sesión de la víctima y el nombre del ordenador comprometido separados por un punto y luego codificados en base64 (por ejemplo, victim_domain.computer_name = dmljdGltX2RvbWFpbi5jb21wdXRlcl9uYW1l).

Slippery Snakelet también tiene este User-Agent harcodeado:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/88.0.4324.104 Safari/537.36

El servidor de C&C estaba camuflado como un sitio Arabian Gulf E-Learning y la página de aterrizaje HTML por defecto no contiene ningún comando. Cuando Slippery Snakelet proporciona una solicitud con el formato correcto (por ejemplo, https://zaincell[.]store/request/<UID>), el servidor de C&C inserta etiquetas <code> como <code>6wjTyB3Y20KSzU1VUlTagp3aG9hbWkKbnVsbApudWxs</code> en la página, y Slippery Snakelet las recopila y descodifica.

Slippery Snakelet decodifica en base64 desde el octavo carácter hasta el final de la cadena (es decir, Y20KSzU1VUlTagp3aG9hbWkKbnVsbApudWxs en el ejemplo anterior). La salida descodificada está separada por una nueva línea y contiene los cinco elementos descritos en la Tabla 4

Tabla 4. Argumentos de Slippery Snakelet Argumentos y opciones de Slippery Snakelet

Laret y Pinar – túneles inversos

Laret y Pinar, cuyos nombres se derivan de los nombres internos de cada archivo respectivo, son binarios Windows de 32 bits escritos en C#/.NET. Ambos tienen marcas de tiempo de compilación PE con timestomping -una táctica común entre los grupos de amenazas de Oriente Medio (y en particular los relacionados con Irán)- de 2058-02-07 00:12:48 y 2072-07-10 18:26:15, respectivamente. Ambas se encontraron en dos sistemas en las ubicaciones de la Tabla 5.

Tabla 5. Ubicaciones de Laret y Pinar en el disco, junto con los nombres de los archivos

En el caso en el que no tenemos una ubicación en disco para Laret pero sí tenemos el nombre de archivo(wincapsrv.exe), pudimos ver que Laret se descargó de http://178.209.51[.]61:8000/wincapsrv.exe a través de PowerShell. Por desgracia, no conseguimos descubrir dónde se escribió en el disco. Los intentos de enumerar la IP y descargar el archivo fueron rechazados por el servidor de C&C, lo que probablemente indica que se requiere alguna forma de identificación del host comprometido en la configuración de la conexión (que no tenemos).

En cuanto a la escritura en disco, es probable que los operadores de BladedFeline hayan cambiado la fecha de creación del archivo Pinar a 2017-09-14 14:56:00 en uno de los dos sistemas comprometidos. Cómo se modificó la fecha de creación del archivo es una pregunta abierta, pero muestra que los atacantes han comprometido estos dos sistemas hasta tal punto que probablemente tienen derechos administrativos.

En tiempo de ejecución, tanto Laret como Pinar dependen de un archivo de configuración en el mismo directorio que sus binarios para ocho variables necesarias, que se enumeran en la Tabla 6.

Tabla 6. Parámetros de configuración de Laret y Pinar Parámetros de configuración de Laret y Pinar con valores por defecto

Hasta ahora no hemos recopilado el archivo de configuración, pero hemos reconstruido su contenido probable, que se encuentra en la Figura 5, basándonos en el análisis del código. La lectura del archivo de configuración se realiza decodificando en base64 la cadena codificada en bytes, lo que da como resultado cadenas de valores de caracteres delimitados por espacios y codificados en hexadecimal, que a su vez se decodifican en cadenas ASCII.

Los desarrolladores de BladedFeline se refieren a esto como Delocking y a lo contrario (escribir en el archivo de configuración) como Enlocking. Esto probablemente indica una familiaridad pasajera con el inglés, pero los desarrolladores estaban lejos de dominarlo. Otros ejemplos de escasa capacidad de traducción son

• time Alapsed and client not connected
• aerpoo after
• Waiting connection …
• error in creaate ssh client

Curiosamente, en otro punto de los túneles inversos, los desarrolladores escribieron correctamente la palabra transcurrido(time elapsed!), lo que es indicativo de una codificación deficiente y de una revisión de código poco rigurosa, si es que se realiza alguna (por ejemplo, hay mucho texto de resultado de comandos en la línea de comandos, como si los túneles inversos se enviaran inmediatamente después de completar las pruebas con éxito).

La función real y el flujo de Laret y Pinar después de recoger los parámetros del archivo de configuración es bastante banal, pero eso es probablemente un esfuerzo intencional para pasar desapercibido. Ambos buscan un nombre de archivo en el parámetro process_file y, si un archivo que coincide con el nombre suministrado está presente, lo ejecutan e inician dos hilos:

1. Establece una conexión SSH a la IP del C&C en el archivo de configuración usando la DLL Core.Renci.SshNet incluida en el binario. El puerto 22 está codificado como el puerto del C&C y el reenvío de puertos también está habilitado, usando la variable remote_port del archivo de configuración.
2. Establece una escucha en el puerto especificado en el parámetro local_port del archivo de configuración. Ten en cuenta que cualquier dato enviado al listener se hace en claro (es decir, no se usa encriptación u ofuscación más allá de caracteres \0 extra que son eliminados en el momento de la recepción por Laret y Pinar).

Si no se especifica ningún fichero en process_file, tanto Laret como Pinar omiten la configuración de un puerto de escucha.

Laret y Pinar sólo difieren significativamente en que Pinar configura un servicio, llamado Service1, para la persistencia antes de ejecutar los dos hilos. Laret no tiene ningún medio de persistencia más allá de su proceso que se ejecuta indefinidamente.

Herramientas complementarias

Flog webshell

Flog es una webshell encontrada subida a VirusTotal desde Irak por el mismo remitente que subió una de las versiones de Whisper. Basándonos en esto y en la proximidad temporal (ambas fueron subidas en cuestión de minutos) creemos que fue desplegada por BladedFeline a la víctima en el gobierno de Irak.

Flog, llamado así por su nombre de archivo – flogon.aspx – busca entradas específicas de los operadores de BladedFeline de la forma <password>=<(a|b|c|d)>#<path>.

Flog realiza un hash de la contraseña, que debe coincidir con la suma de comprobación MD5 4CC88CE123B0DA8D75C0FE66A39339F6.

Las variables(a|b|c|d) son opciones del comando:

• a devuelve, para la ruta proporcionada, un listado de directorios y la longitud en bytes de cada archivo,
• b crea un archivo en el disco, utilizando la ruta proporcionada,
• c divide la variable de ruta en una pipe y escribe un archivo en el disco donde la primera parte de la ruta es el nombre del archivo y la segunda parte son los datos a escribir, y
• d borra un archivo especificado en la ruta proporcionada.

Hawking Listener

Hawking Listener, llamado así por su cadena PDB – C:\Users\g18u04\source\repos\Hawking\Hawking\obj\Release\listner.pdb – es un binario .NET/C# Windows de 32 bits con un tiempo de compilación timestomped de 2057-11-14 16:59:12. También fue subido a VirusTotal por el mismo usuario que subió Flog y es probablemente una herramienta de BladedFeline. Implementa la clase .NET HTTPListener para configurar un receptor con una URL codificada (que no podemos revelar en este caso sin revelar la identidad de la víctima). Alternativamente, Hawking puede ser provisto en tiempo de ejecución con URLs para que el socket escuchador monitoree.

Hawking espera un QueryString proporcionado (de un operador BladedFeline) con snmflwkejrhgsey como clave en el par clave-valor. Una vez recibido, Hawking ejecuta el valor en cmd.exe y devuelve el resultado. Para detener Hawking, los operadores sólo tienen que enviar stop como clave en el QueryString con una variable no nula en el valor.

Hawking registra todas las interacciones, argumentos de ejecución y salida de comandos en el archivo log.txt de su directorio de trabajo.

P.S. Olala

P.S. Olala es un binario .NET de 32 bits llamado así por su función prevista (ejecutar scripts de PowerShell) y su ruta PDB G:\csharp\psExecuterService\ewsService\obj\Release\Olala.pdb. No acepta argumentos en tiempo de ejecución. Más bien, en tiempo de ejecución, P.S. Olala utiliza el método Run(ServiceBase[]) de la clase .NET ServiceBase para registrarse como servicio con el Gestor de Control de Servicios (para la persistencia).

Cuando se llama al servicio P.S. Olala, se crea un subproceso y se ejecuta la función mainLoop, que se muestra en la Figura 6. Esencialmente, P.S. Olala crea un subproceso y ejecuta la función mainLoop. Básicamente, P.S. Olala es un ejecutor del script PowerShell almacenado en %APPDATA%\Local\Microsoft\InputPersonalization\TrainedDataStore.ps1.

Lamentablemente, no pudimos recopilar ninguno de los scripts TrainedDataStore. ps1. Sin embargo, la información contextual indica que probablemente se trate de un ejecutor del backdoor Whisper, o de uno de los túneles inversos (Laret o Pinar). El flujo completo (P.S. Olala → TrainedDataStore → Whisper/Laret/Pinar) es probablemente una cadena de persistencia alargada con el objetivo de mantener el acceso.

Sheep Tunneler

Sheep Tunneler, una aplicación de tunelización personalizada a la que hemos puesto nombre basándonos en la cadena PDB C:\sers\sheep\source\repos\MP\MP\obj\Release\MP.pdb), se ha observado en las dos ubicaciones siguientes:

• %APPDATA%\Local\Microsoft\Windows\Ringtones\RingService.exe
• %APPDATA%\Local\Microsoft\Windows\Shell\mspsrv.exe

Sheep Tunneler puede ejecutarse en dos modos: túnel de red (utilizando el argumento de ejecución middle) o connect back (utilizando los argumentos cb <ip>:<port>).

Whisper Protocol

Whisper Protocol, llamado así por su nombre de archivo(Protocol.pdf.exe) es un binario de Windows de 64 bits compilado en Python con una fecha de compilación de 2024-03-11 09:01:20. Crea una carpeta en C:\ProgramData\VeeamUpdate y escribe tanto Whisper como su archivo de configuración en esa carpeta. El protocolo Whisper también se copia a sí mismo en %APPDATA%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\VeeamUpdate.lnk para su persistencia. Por último, ejecuta Whisper y sale.

Conclusión

BladedFeline es un grupo de amenazas avanzadas especializado en atacar a víctimas iraquíes y kurdas, en concreto a funcionarios y organizaciones gubernamentales. Creemos que el grupo es probablemente un subgrupo de OilRig. Esperamos que BladedFeline persista en el desarrollo de implantes con el fin de mantener y ampliar el acceso a su conjunto de víctimas comprometidas, probablemente con fines de ciberespionaje.

Para cualquier consulta sobre nuestra investigación publicada en WeLiveSecurity, por favor contáctenos en threatintel@eset.com.

ESET Research ofrece informes privados de inteligencia APT y fuentes de datos. Para cualquier consulta sobre este servicio, visite la página de ESET Threat Intelligence.

IoCs

Archivos

Red

Técnicas ATT&CK de MITRE

Esta tabla se ha elaborado utilizando la versión 17 del marco MITRE ATT&CK.

¡Para todos nuestros lectores!

Aprovechen esta oportunidad de obtener un trial gratuito de 30 días para Google Workspace, la mejor solución para tu empresa. Disfruta de todas sus funcionalidades, como correo electrónico personalizado, almacenamiento en la nube y herramientas de colaboración.

Comienza tu prueba gratuita