![\"Figure](\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/05-25\/bladedfeline\/figure-1.png\")
<\/p>\nEn 2024, investigadores de la empresa de seguridad: ESET descubrieron varias herramientas maliciosas en los sistemas utilizados por funcionarios del gobierno kurdo e iraqu\u00ed. El grupo APT detr\u00e1s de los ataques es BladedFeline, un actor de amenazas iran\u00ed que ha estado activo desde al menos 2017, cuando comprometi\u00f3 a funcionarios dentro del Gobierno Regional del Kurdist\u00e1n (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\u00e9s de que atac\u00f3 a funcionarios diplom\u00e1ticos 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.<\/p>\n
El conjunto de herramientas utilizadas en la reciente campa\u00f1a muestra que, desde el despliegue de Shahmaran, BladedFeline ha seguido desarrollando su arsenal. Encontramos dos t\u00faneles inversos, diversas herramientas complementarias y, sobre todo, un backdoor que denominamos Whisper y un m\u00f3dulo 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\u00e9s de archivos adjuntos de correo electr\u00f3nico. PrimeCache tambi\u00e9n sirve como backdoor: es un m\u00f3dulo IIS malicioso relacionado con lo que denominamos Grupo 2 en nuestro art\u00edculo de 2021 Anatomy of native IIS malware. Resulta significativo que PrimeCache tambi\u00e9n tenga similitudes con el backdoor RDAT utilizada por el grupo APT OilRig, alineado con Ir\u00e1n.<\/p>\n
Bas\u00e1ndonos en estas similitudes de c\u00f3digo, as\u00ed 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\u00e1n 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.<\/p>\n
BladedFeline ha trabajado constantemente para mantener el acceso il\u00edcito a funcionarios diplom\u00e1ticos kurdos, al tiempo que explotaba un proveedor regional de telecomunicaciones en Uzbekist\u00e1n y desarrollaba y manten\u00eda el acceso a funcionarios del gobierno de Irak. Este blogpost detalla los aspectos t\u00e9cnicos de los implantes iniciales entregados a los objetivos de BladedFeline, los v\u00ednculos entre las v\u00edctimas, y sienta las bases para asociar a este subgrupo con OilRig.<\/p>\n
Puntos clave del blogpost:
\nBladedFeline comprometi\u00f3 a funcionarios del Gobierno Regional del Kurdist\u00e1n al menos desde 2017.
\nLos implantes iniciales utilizados all\u00ed pueden rastrearse hasta OilRig.
\nDescubrimos BladedFeline despu\u00e9s de que sus operadores comprometieran a funcionarios diplom\u00e1ticos kurdos con el backdoor de firma Shahmaran del grupo en 2023.
\nEste grupo APT tambi\u00e9n se ha infiltrado en altos cargos del Gobierno de Irak.
\nEvaluamos con confianza media que BladedFeline es un subgrupo dentro de OilRig.
\nAnalizamos dos t\u00faneles inversos (Laret y Pinar), un backdoor (Whisper), un m\u00f3dulo IIS malicioso (PrimeCache) y varias herramientas complementarias.
\nVisi\u00f3n general de BladedFeline
\nBladedFeline es un grupo de ciberespionaje alineado con Ir\u00e1n, activo desde al menos 2017 seg\u00fan la telemetr\u00eda de ESET. Descubrimos al grupo en 2023 cuando despleg\u00f3 su backdoor Shahmaran contra funcionarios diplom\u00e1ticos kurdos. Shahmaran, llamado as\u00ed por una criatura m\u00edtica mitad serpiente, mitad mujer del folclore iran\u00ed, es un ejecutable portable de 64 bits que encontramos en el directorio de inicio del objetivo. Este sencillo backdoor no utiliza ning\u00fan tipo de compresi\u00f3n 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\u00edficos de archivo y proporicionando API de manipulaci\u00f3n de archivos y directorios.<\/p>\n
Como demuestra el conjunto de herramientas de la campa\u00f1a que describimos en este blogpost, desde el despliegue de Shahmaran, BladedFeline ha seguido desarrollando su malware con el fin de mantener y ampliar a\u00fan m\u00e1s su acceso al Gobierno Regional del Kurdist\u00e1n y a los altos niveles del Gobierno de Irak. Descubrimos la campa\u00f1a 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\u00e1ticos kurdos, funcionarios del gobierno iraqu\u00ed y un proveedor regional de telecomunicaciones en Uzbekist\u00e1n.<\/p>\n
Detectamos y recogimos una versi\u00f3n de Whisper y encontramos otra en VirusTotal, subida por un usuario de Irak. Son pr\u00e1cticamente id\u00e9nticas, y pudimos determinar la identidad probable de quien las subi\u00f3 a VirusTotal, bas\u00e1ndonos 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\u00edfico) fueron subidos a VirusTotal por el mismo remitente que subi\u00f3 las muestras de Whisper. Bas\u00e1ndonos en el enlace de Whisper y en la proximidad temporal (ambos fueron subidos en cuesti\u00f3n de minutos) creemos que fue desplegado por BladedFeline a una v\u00edctima del gobierno de Irak. Algunas de las herramientas que se mencionan a continuaci\u00f3n en la cronolog\u00eda se analizan m\u00e1s adelante en el informe (por ejemplo, Slippery Snakelet).<\/p>\n
Cronolog\u00eda
\n2017-09-21 \u25cf VideoSRV reverse shell on KRG system
\n|
\n2018-01-30 \u25cf RDAT backdoor on KRG system
\n|
\n2019-07-09 \u25cf Custom Plink on KRG system
\n|
\n2021-05-01 \u25cf Sheep Tunneler on KRG system
\n|
\n2023-01-23 \u25cf LSASS dumped on KRG system
\n|
\n2023-02-01 \u25cf Shahmaran backdoor on KRG system
\n|
\n2023-03-25 \u25cf First victim targeted at a telecommunications company in Uzbekistan
\n|
\n2023-06-12 \u25cf Shahmaran version 2 on KRG system for access maintenance
\n|
\n2023-12-14 \u25cf BladedFeline operators executing CLI commands on KRG system
\n|
\n2023-12-16 \u25cf Slippery Snakelet backdoor on KRG system
\n|
\n2023-12-20 \u25cf P.S. Olala (a PowerShell executor) on KRG system
\n|
\n2023-12-20 \u25cf PsExec on KRG system
\n|
\n2024-01-07 \u25cf Whisper backdoor on KRG system
\n|
\n2024-02-01 \u25cf Laret reverse tunnel on KRG system
\n|
\n2024-02-20 \u25cf Pinar reverse tunnel on KRG system
\n|
\n2024-02-29 \u25cf PrimeCache malicious IIS module uploaded to VirusTotal
\n|
\n2024-03-11 \u25cf Whisper version 2, Flog, and Hawking Listener uploaded to VirusTotal
\nAtribuci\u00f3n
\nNuestra atribuci\u00f3n de esta campa\u00f1a a BladedFeline se basa en lo siguiente:<\/p>\n
La campa\u00f1a est\u00e1 dirigida a miembros del Gobierno Regional del Kurdist\u00e1n, al igual que ataques anteriores realizados por BladedFeline.
\nLa actividad de ataque original dirigida a la organizaci\u00f3n KRG nos permiti\u00f3 identificar malware sucesivo, ya que BladedFeline ha intentado mantener y ampliar el acceso a la organizaci\u00f3n.
\nUn an\u00e1lisis m\u00e1s detallado de los ataques nos llev\u00f3 a identificar a la v\u00edctima de telecomunicaciones en Uzbekist\u00e1n.
\nAl mismo tiempo, investigar el backdoor Whisper nos ayud\u00f3 a identificar a la v\u00edctima del Gobierno de la India.
\nCreemos que BladedFeline tiene como objetivo al Gobierno Regional del Kurdist\u00e1n y al Gobierno de la India con fines de ciberespionaje, con la vista puesta en mantener el acceso estrat\u00e9gico a altos cargos de ambas entidades gubernamentales. La relaci\u00f3n diplom\u00e1tica del GRK con las naciones occidentales, junto con las reservas de petr\u00f3leo de la regi\u00f3n del Kurdist\u00e1n, lo convierten en un objetivo atractivo para que los actores de amenazas alineados con Ir\u00e1n esp\u00eden y potencialmente manipulen. En Irak, lo m\u00e1s probable es que estos actores intenten contrarrestar la influencia de los gobiernos occidentales tras la invasi\u00f3n y ocupaci\u00f3n estadounidense del pa\u00eds.<\/p>\n
Creemos con una confianza media que BladedFeline es un subgrupo de OilRig:<\/p>\n
Al igual que OilRig, BladedFeline tiene como objetivo organizaciones de Oriente Medio con fines de ciberespionaje.
\nHemos encontrado herramientas de OilRig (VideoSRV y RDAT) en un sistema comprometido del KRG.
\nEl m\u00f3dulo IIS malicioso PrimeCache de BladedFeline comparte similitudes de c\u00f3digo con RDAT de OilRig.
\nBladedFeline no es el \u00fanico subgrupo de OilRig que estamos vigilando: ya hemos estado siguiendo a Lyceum, tambi\u00e9n conocido como HEXANE o Storm-0133, como otro subgrupo de OilRig. Lyceum se centra en atacar a diversas organizaciones israel\u00edes, incluidas entidades gubernamentales y de la administraci\u00f3n 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\u00edtimos en la nube para la comunicaci\u00f3n C&C.<\/p>\n
Seguiremos utilizando el nombre OilRig para referirnos al grupo matriz, tambi\u00e9n 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\u00e1n. Su objetivo son los gobiernos de Oriente Medio y diversos sectores empresariales, como el qu\u00edmico, el energ\u00e9tico, el financiero y el de las telecomunicaciones. Las campa\u00f1as de OilRig m\u00e1s destacadas incluyen la campa\u00f1a de DNSpionage de 2018 y 2019, dirigida a v\u00edctimas en el L\u00edbano y los Emiratos \u00c1rabes Unidos; la campa\u00f1a HardPass de 2019-2020, que utiliza LinkedIn para atacar a v\u00edctimas de Oriente Medio en los sectores energ\u00e9tico y gubernamental; el ataque de 2020 contra una organizaci\u00f3n 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.<\/p>\n
Herramientas OilRig utilizadas por BladedFeline
\nHemos encontrado dos herramientas OilRig en las m\u00e1quinas del KRG comprometidas por BladedFeline.<\/p>\n
RDAT
\nHemos descubierto una versi\u00f3n del backdoor RDAT de OilRig de la que no se hab\u00eda informado anteriormente en dos sistemas v\u00edctimas del KRG. Al analizar el RDAT, descubrimos que el flujo operativo (v\u00e9ase el informe de la Unidad 42 para m\u00e1s detalles), la marca de tiempo de compilaci\u00f3n (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\u00e9n corrobora que este binario es RDAT: C:\\sers\\Void\\Desktop\\RDAT\\client\\x64\\Release\\client.pdb. Hasta la fecha, s\u00f3lo hemos observado RDAT en uso por OilRig. Adem\u00e1s, no hemos visto ning\u00fan implante personalizado compartido entre OilRig y otros grupos de Oriente Medio, y rara vez ocurre entre actores de amenazas alineados con Ir\u00e1n.<\/p>\n
El an\u00e1lisis que vincula RDAT con PrimeCache, un m\u00f3dulo malicioso de IIS que fue subido a VirusTotal presumiblemente por la v\u00edctima del Gobierno de la India, refuerza a\u00fan m\u00e1s la idea de que BladedFeline es un subgrupo de OilRig, al igual que Lyceum. Este v\u00ednculo se explora en mayor profundidad en la secci\u00f3n V\u00ednculos con OilRig del blogpost.<\/p>\n
VideoSRV
\nUn dato adicional sobre la conexi\u00f3n entre OilRig y BladedFeline es una shell inversa desplegada en una de las v\u00edctimas del Gobierno Regional del Kurdist\u00e1n (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\u00ed 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.<\/p>\n
An\u00e1lisis t\u00e9cnico
\nAcceso inicial
\nA\u00fan no est\u00e1 claro c\u00f3mo BladedFeline desarrolla el acceso a sus v\u00edctimas. Lo que sabemos es que en el caso de las v\u00edctimas del GRK, los actores de la amenaza obtuvieron acceso al menos en 2017 y lo han mantenido desde entonces. En cuanto a las v\u00edctimas del GOI, sospechamos que el grupo explot\u00f3 una vulnerabilidad en una aplicaci\u00f3n en un servidor web orientado a Internet, lo que les permiti\u00f3 desplegar el webshell Flog.<\/p>\n
Conjunto de herramientas
\nPrimeCache – m\u00f3dulo IIS malicioso
\nPrimeCache, cuyo nombre derivamos del RTTI AVRSAPrimeSelector y su nombre de archivo(cachehttp.dll), es un backdoor pasivo implementado como un m\u00f3dulo IIS nativo con un nombre interno de HttpModule.dll. Fue subido a VirusTotal por el mismo usuario que subi\u00f3 una de las muestras del backdoor Whisper. Es una DLL C++ de 64 bits con una fecha de compilaci\u00f3n de 2023-05-14 06:55:52 y tiene una cadena PDB minimizada de s\u00f3lo HttpModule.pdb. Tiene una \u00fanica exportaci\u00f3n: RegisterModule.<\/p>\n
PrimeCache es el sucesor de una colecci\u00f3n 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\u00e9in, Israel y Pakist\u00e1n, entre 2018 y 2020. Bas\u00e1ndonos \u00fanicamente en la ubicaci\u00f3n de las presuntas v\u00edctimas, es posible que esos casos tambi\u00e9n estuvieran relacionados con las actividades de BladedFeline -o, m\u00e1s ampliamente, OilRig-.<\/p>\n
Funcionalidad principal
\nLa funcionalidad principal de PrimeCache se implementa en el manejador CGlobalModule::OnGlobalPreBeginRequest. Se trata de una implementaci\u00f3n \u00fanica, a diferencia de sus predecesores, que utilizaban el controlador CHttpModule::OnBeginRequest. PrimeCache filtra las peticiones HTTP entrantes, procesando s\u00f3lo las de los operadores BladedFeline, que son reconocidos por tener una cabecera cookie con la estructura<\/p>\n
F=<command_ID>,<param>;<\/p>\n
Tenga en cuenta que este valor puede ser independiente o estar incrustado en una cookie m\u00e1s larga, rodeada de caracteres de punto y coma (;).<\/p>\n
El backdoor funciona de una forma inusual (nueva en esta versi\u00f3n en comparaci\u00f3n con nuestro an\u00e1lisis de 2021). En lugar de aceptar un comando backdoor y todos sus par\u00e1metros en una \u00fanica petici\u00f3n HTTP, cada acci\u00f3n se divide en varias peticiones. En primer lugar, el operador BladedFeline env\u00eda una solicitud individual para cada par\u00e1metro; estos par\u00e1metros se almacenan en una estructura global. A continuaci\u00f3n, el operador env\u00eda otra petici\u00f3n para activar el comando backdoor. Por \u00faltimo, PrimeCache utiliza los par\u00e1metros recibidos anteriormente para ejecutar la acci\u00f3n especificada y, a continuaci\u00f3n, borra los par\u00e1metros almacenados en cach\u00e9.<\/p>\n
Comandos de operador
\nHay tres tipos de peticiones que pueden ser recibidas por el backdoor, como se muestra en la Tabla 1.<\/p>\n
Tabla 1. Comandos de operador de PrimeCache<\/p>\n
<command_ID> Parameter Description
\n1 Format: <key>=<value> Clears the list of previously stored parameters and adds the new value. Most parameters are encrypted; see Encryption below.
\n0 Not used. Triggers the backdoor action, using previously transmitted backdoor parameters.
\nOther Format: <key>=<value> Adds the specified value to the list of stored parameters (doesn\u2019t clear the list). Most parameters are encrypted; see Encryption below.
\nUna vez que la acci\u00f3n se activa (a trav\u00e9s de <command_ID>=0), PrimeCache realiza una acci\u00f3n, basada en los par\u00e1metros obtenidos previamente, como se muestra en la Tabla 2. Una nota en la tabla de abajo:<\/p>\n
La acci\u00f3n PrimeCache es comando de operador (OpCom) a, la clave de sesi\u00f3n es OpCom k, datos binarios es OpCom b, y el nombre de archivo es OpCom f.<\/p>\n
Tabla 2. PrimeCache post-operador s<\/p>\n
PrimeCache action Session key Binary data Filename Command description Return value
\nr RSA-encrypted session key AES-encrypted command line Null Runs the specified command via popen. Command output
\nr2 Runs the specified command via CreateProcessW.
\nr3 (Presumably) runs the specified command by sending it to another (unknown) process via the named pipe \\\\.\\pipe\\iis, then reads (presumably) the command output from the same pipe.
\nu AES-encrypted file content Local filename Creates a local file with the specified name and content. OK
\nd Null Exfiltrates the given file from the compromised IIS server. File content
\nCifrado
\nAl igual que sus predecesores, PrimeCache utiliza tanto RSA como AES-CBC para su comunicaci\u00f3n C&C. Los par\u00e1metros y los valores de retorno siempre se cifran mediante AES-CBC utilizando la clave de sesi\u00f3n y, a continuaci\u00f3n, se codifican en base64. La clave de sesi\u00f3n est\u00e1 encriptada con RSA; el backdoor tiene una clave RSA p\u00fablica y otra privada codificadas (no un par) para manejar ambas direcciones de la comunicaci\u00f3n.<\/p>\n
Se utiliza una biblioteca Crypto++ vinculada est\u00e1ticamente para manejar las operaciones de cifrado y descifrado.<\/p>\n
Comunicaciones C&C
\nLos comandos del operador se transmiten en la cabecera de la cookie (otra desviaci\u00f3n de las versiones anteriores, que utilizaban la URL o el cuerpo de la petici\u00f3n HTTP). Las respuestas PrimeCache se a\u00f1aden al cuerpo de la respuesta HTTP. Si se est\u00e1 exfiltrando un archivo, el encabezado Content-Type se establece como attachment, igualando la funcionalidad de las versiones anteriores.<\/p>\n
Los predecesores de PrimeCache tambi\u00e9n utilizaban el mismo esquema de cifrado y nombres de par\u00e1metros similares(a, c, f, k), pero todos se enviaban a la puerta trasera en una \u00fanica petici\u00f3n. Los \u00fanicos comandos soportados eran r, u y d.<\/p>\n
V\u00ednculos con OilRig
\nCuando comparamos PrimeCache con RDAT, como se describe en la subsecci\u00f3n de atribuci\u00f3n de RDAT, vemos varias similitudes que apoyan nuestra suposici\u00f3n de que BladedFeline es un subgrupo de OilRig.<\/p>\n
Tanto RDAT como PrimeCache utilizan la biblioteca Crypto++, y ambos analizan los comandos de puerta trasera utilizando la expresi\u00f3n regular [^,]+
\nLa carga \u00fatil intenta analizar el texto claro descifrado utilizando la expresi\u00f3n regular [^,]+ para obtener el valor del comando y los argumentos del comando que se dividen con una coma.
\nAmbos comparten una funci\u00f3n, mostrada en la Figura 1, que ejecuta un comando shell y lee la salida, que, a trav\u00e9s de nuestro corpus, s\u00f3lo se encuentra en estas dos piezas de malware.<\/p>\n
<\/p>\n
<\/p>\n
La puerta trasera Whisper
\nWhisper 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\u00edo de archivos adjuntos de correo electr\u00f3nico a trav\u00e9s de una cuenta de correo web comprometida. Hemos visto dos versiones del backdoor: detectamos y recogimos una versi\u00f3n, y fue subida a VirusTotal desde Irak. Estas muestras son pr\u00e1cticamente id\u00e9nticas, pero pudimos determinar la identidad probable de quien las subi\u00f3 a VirusTotal bas\u00e1ndonos en los datos de la muestra de Whisper y otras muestras subidas por ese usuario.<\/p>\n
Ambas versiones de Whisper tienen marcas de tiempo de compilaci\u00f3n (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\u00edctima utiliza las DLL empaquetadas con el binario y no las DLL de la cach\u00e9 global de ensamblados.<\/p>\n
La operaci\u00f3n 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\u00f3nicos reales, Lyceum utiliz\u00f3 borradores de correo electr\u00f3nico para la comunicaci\u00f3n entre su malware y los operadores a lo largo de 2022, como describimos en una entrada anterior.<\/p>\n
Workflow operativo
\nWhisper 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\u00f3n en el disco junto con \u00e9l (v\u00e9ase la secci\u00f3n Protocolo Whisper ). El archivo de configuraci\u00f3n, que se muestra en la Figura 2, est\u00e1 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\u00f3n – DelockItems – para decodificar en base64 las variables de configuraci\u00f3n.<\/p>\n
![\"Figure](\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/05-25\/bladedfeline\/figure-2.jpeg\")
<\/p>\n
La figura 3 muestra el workflow operativo de Whisper, que detallamos en los p\u00e1rrafos siguientes.<\/p>\n
![\"Image](\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/05-25\/bladedfeline\/figure-3.png\")
<\/p>\n
El workflow operativo de Whisper puede dividirse en siete pasos:<\/p>\n
En el paso 1, Whisper utiliza las credenciales del archivo de configuraci\u00f3n (l\u00ednea 15 de la figura 2) y la clase\u00a0ExchangeService\u00a0de\u00a0Microsoft Exchange Web Services<\/a>\u00a0para intentar iniciar sesi\u00f3n en las cuentas de correo web comprometidas. Una vez que Whisper inicia sesi\u00f3n con \u00e9xito en una cuenta, guarda las credenciales en la memoria y escribe lo siguiente en el archivo de registro\u00a0c:\\Windows\\Temp\\WindowsEventLogs.txt:<\/p>\n ———— ItemContext is set: user name [<user_name>] , use_defaultCred: [credentials>]<\/p>\n Si no hay credenciales v\u00e1lidas en el archivo de configuraci\u00f3n, Whisper registra los siguientes mensajes de error en el archivo de registro:<\/p>\n ———————————- there was No Way to access any Mailbox.<\/p>\n __________ Extraction function is called.<\/p>\n Si se detecta un error inesperado, Whisper escribe lo siguiente en el archivo de registro (n\u00f3tese el error ortogr\u00e1fico de la palabra\u00a0happened, indicativo de un hablante no nativo de ingl\u00e9s) y sale utilizando el m\u00e9todo\u00a0Environment.Exit(Int32)<\/a>. Extra\u00f1amente, el\u00a0exitCode\u00a0utilizado,\u00a00, indica que el proceso finaliz\u00f3 con \u00e9xito.<\/p>\n ———————————-__ an unknown Exception happend. program turned off<\/p>\n A continuaci\u00f3n, en el Paso 2, Whisper utiliza las credenciales del paso anterior para buscar reglas de bandeja\u00a0de<\/em>\u00a0entrada utilizando el m\u00e9todo\u00a0ExchangeService.GetInboxRules<\/a>\u00a0(que\u00a0[r]ecobra una colecci\u00f3n de reglas de bandeja de entrada que est\u00e1n asociadas con el usuario especificado<\/em>). Utilizando el valor de la l\u00ednea 13 del archivo de configuraci\u00f3n(key=\u00bbreceive_sign\u00bb, value=\u00bbPMO\u00bb), Whisper itera sobre las reglas de la bandeja de entrada buscando que ese valor se especifique en uno de estos tres lugares:\u00a0subject,\u00a0body, o\u00a0subjectorbody\u00a0y que los correos que coincidan con ese valor se env\u00eden a una ubicaci\u00f3n especificada(deleteditems\u00a0o\u00a0inbox, dependiendo de la versi\u00f3n 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\u00e1metros indicados:<\/p>\n En el Paso 3, Whisper inicia un loop interminable que env\u00eda un mensaje de correo electr\u00f3nico de confirmaci\u00f3n desde la cuenta de correo electr\u00f3nico comprometida en el Paso 1 a una direcci\u00f3n de correo electr\u00f3nico especificada en el archivo de configuraci\u00f3n (l\u00ednea 16,\u00a0key=\u00bbalive_mail\u00bb). El mensaje de check-in se env\u00eda cada 10 horas (l\u00ednea 10 del archivo de configuraci\u00f3n,\u00a0key=\u00a0\u00abal_time\u00bb; en minutos), el asunto (l\u00ednea 17,\u00a0key=\u00bbalive_msg_subj\u00bb) es\u00a0Content, y el cuerpo del mensaje contiene el string definida a continuaci\u00f3n:<\/p>\n \u00abContent ID: \u00bb\u00a0+ base64_encode(\u00abCOMPUTERNAME:USERDNSDOMAIN:USERNAME\u00bb)<\/p>\n A continuaci\u00f3n, 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\u00a0o\u00a0inbox, seg\u00fan la versi\u00f3n de Whisper) con archivos adjuntos cuyo asunto coincida con una cadena (suministrada en el archivo de configuraci\u00f3n;\u00a0PMO\u00a0en el \u00fanico archivo de configuraci\u00f3n que recopilamos). Para los correos electr\u00f3nicos con archivos adjuntos que coincidan, Whisper raspa el cuerpo del adjunto (que deber\u00eda contener comandos cifrados) y almacena la direcci\u00f3n de correo electr\u00f3nico del remitente para utilizarla posteriormente como servidor C&C al que se cargan los resultados de los comandos del operador.<\/p>\n 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\u00f3n, descifra el resultado utilizando la\u00a0clase .NET AES<\/a>\u00a0con un vector de inicializaci\u00f3n de 16 bytes y la clave de cifrado que se encuentra en el archivo de configuraci\u00f3n (l\u00ednea 18,\u00a0key=\u00bbenc_key\u00bb value=\u00bbcXdlcmFzZHp4Y3ZmZ2d0aGhsZGZvZ2g\/bHZtZ2xrZyE=\u00bb). Los comandos desencriptados tienen la forma\u00a0<id_comando>;<comando_a_ejecutar>.\u00a0El ID del comando, los comandos y la salida del comando se guardan en el siguiente formato:<\/p>\n base64-encoded(<command_id>: <cmd_id>cn<cmd_output>\\n)<\/p>\n A continuaci\u00f3n, en el paso 6, Whisper ejecuta los comandos backdoor y registra los resultados. Los posibles comandos incluyen:<\/p>\n Los datos escritos en el disco son<\/p>\n this is my file content<\/p>\n <filepath><\/p>\n <filename><\/p>\n <nbytes-to-write><\/p>\n Los bytes a escribir est\u00e1n codificados en base64 (y decodificados antes de escribir en disco). La ejecuci\u00f3n exitosa devuelve:<\/p>\n archifile received properly. wrote to: <filepath> <filename><\/p>\n Este comando lleva el prefijo\u00a0this is my required file path\u00a0seguido de\u00a0\\n<unknown_variable>\\n<filepath>\\<filename>.\u00a0Whisper lee el contenido del archivo en memoria, lo codifica en base64 y lo devuelve:<\/p>\n this is my required file <path>\\n<unknown_variable>\\n<filename>\\n<base64_encoded_file_contents>.<\/p>\n Este comando no tiene prefijo y en su lugar s\u00f3lo contiene un comando en texto plano que PowerShell es capaz de ejecutar, postfixed con una pipe despu\u00e9s de lo cual Whisper a\u00f1ade\u00a0Out-String. La salida se guarda de esta forma:<\/p>\n base64-encoded(<command_id>: <cmd_id>\\n<cmd_output>\\n)<\/p>\n Finalmente, en el Paso 7, Whisper env\u00eda la salida del comando en un mensaje de correo electr\u00f3nico a la bandeja de entrada del C&C encontrada en el Paso 4. El correo electr\u00f3nico tiene el siguiente formato<\/p>\n Los pasos del 4 al 7 contin\u00faan en un loop utilizando el mismo programa de comprobaci\u00f3n del paso 3 hasta que se cambien las credenciales codificadas en el archivo de configuraci\u00f3n.<\/p>\n El backdoor Shahmaran, llamado as\u00ed por una m\u00edtica criatura mitad serpiente, mitad mujer del\u00a0folclore iran\u00ed<\/a>, es un PE de 64 bits que se encontr\u00f3 en la carpeta de inicio como:<\/p>\n %ROAMINGAPPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\adobeupdater.exe<\/p>\n Al iniciar el sistema, Shahmaran crea un\u00a0objeto de evento de<\/a>\u00a0Windows,\u00a0SysPrep. Es posible que los desarrolladores de Shahmaran eligieran\u00a0SysPrep\u00a0como nombre del evento para mezclarse con el ruido de fondo, ya que\u00a0SysPrep<\/a>\u00a0forma parte del proceso de creaci\u00f3n de im\u00e1genes de Windows. Los administradores de Windows lo utilizan para crear una imagen est\u00e1ndar 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\u00a0SysPrep\u00a0en un sistema comprometido, visto por\u00a0WinObj de Sysinternals<\/a>.<\/p>\n El dominio del C&C est\u00e1 codificado,\u00a0olinpa[.]com, al igual que el puerto,\u00a080, y la cadena User-Agent, que son dos. La conexi\u00f3n inicial al C&C utiliza una cadena User-Agent incompleta (le falta el par\u00e9ntesis de cierre):<\/p>\n Mozilla\/4.0 (compatible; MSIE 6.0; Windows NT 5.0<\/p>\n La comunicaci\u00f3n posterior con el C&C utiliza la cadena User-Agent corregida:<\/p>\n Mozilla\/4.0 (compatible; MSIE 6.0; Windows NT 5.0)<\/p>\n Shahmaran no utiliza ning\u00fan tipo de compresi\u00f3n o cifrado para las comunicaciones de red. Y aunque el puerto est\u00e1 codificado(80), hay fragmentos de c\u00f3digo que comprueban el puerto en uso y actualizan las variables de comunicaci\u00f3n si se utiliza el puerto\u00a0443.<\/p>\n Despu\u00e9s 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.<\/p>\n Tabla 3. Comandos de operador y sus descripciones Comandos de operador y sus descripciones<\/em><\/p>\n <\/p>\n\n
\n
\n
\n
\n
\n
\n
Backdoor Shahmaran<\/h4>\n
![\"Figure](\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/05-25\/bladedfeline\/figure-4.jpeg\" "\\"Figure")
\n
![\"Figure](\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/05-25\/bladedfeline\/figure-5.jpeg\" "\\"Figure")
![\"Figure](\"https:\/\/web-assets.esetstatic.com\/wls\/2025\/05-25\/bladedfeline\/figure-6.png\" "\\"Figure")