A cadeia induz usuários a executar uma ação manual no Windows, usa PowerShell em múltiplos estágios para contornar ETW e AMSI, carrega um loader em Lua e entrega um RAT em C++ com comunicação HTTPS na porta 443.
| Componente | Campanha ClickFix com entrega do trojan de acesso remoto MIMICRAT, também identificado como AstarionRAT, em sistemas Windows. |
| Vetor | Sites legítimos comprometidos exibem uma falsa verificação do Cloudflare e induzem a vítima a copiar e colar um comando operacional omitido na caixa Executar do Windows. |
| Impacto | O implante final oferece controle pós-comprometimento, incluindo manipulação de processos e arquivos, shell interativo, impersonação de tokens, injeção de shellcode e tunelamento SOCKS5. |
| Prioridade | Investigar acessos a páginas comprometidas, execução anômala de PowerShell iniciada por interação do usuário, sinais de bypass de ETW e AMSI, carregamento em memória e tráfego HTTPS na porta 443 com perfil semelhante a analytics. |
| Artefatos | Cadeia em múltiplos estágios com JavaScript injetado, script PHP externo, PowerShell de segundo estágio, loader em Lua e shellcode descriptografado em memória. |
| IoCs | O serviço legítimo comprometido citado é bincheck[.]io; não há lista ampla de infraestrutura C2 no material analisado. |
Uma campanha ClickFix foi observada usando sites legítimos comprometidos como infraestrutura de entrega para o MIMICRAT, um trojan de acesso remoto em C++ anteriormente não documentado e também chamado de AstarionRAT. O fluxo combina engenharia social no navegador, execução assistida pela própria vítima no Windows, PowerShell em múltiplos estágios, tentativa de reduzir visibilidade de telemetria e carregamento em memória. O ponto crítico para a defesa é que a infecção não depende apenas de uma exploração automática do navegador: o operador usa uma tela falsa de verificação para convencer o usuário a executar uma ação local que inicia a cadeia.
O caso se encaixa no padrão ClickFix porque a isca apresenta um suposto problema de verificação e orienta a vítima a copiar e colar uma instrução na caixa Executar do Windows. O conteúdo operacional dessa instrução deve ser tratado como payload e não deve ser reproduzido. O efeito defensivamente relevante é que ela dispara PowerShell, que busca um segundo estágio em servidor de comando e controle, altera componentes de visibilidade como ETW e AMSI e prepara a entrega de um loader em Lua. O MIMICRAT, por sua vez, estabelece comunicação HTTPS pela porta 443 e usa perfis HTTP que imitam tráfego legítimo de analytics, dificultando a separação por inspeção superficial de rede.
A atividade também apresenta sobreposição tática e de infraestrutura com outra campanha ClickFix associada ao loader Matanbuchus 3.0, que atua como caminho para o mesmo RAT. O objetivo final foi avaliado como possivelmente relacionado a ransomware ou exfiltração de dados, mas esse ponto permanece condicionado: o que está confirmado no fluxo descrito é a instalação de um implante com capacidades de pós-exploração amplas, capaz de ampliar controle do sistema comprometido e fornecer acesso operacional persistente ao operador enquanto a comunicação C2 estiver disponível.
O início observado envolve bincheck[.]io, um serviço legítimo de validação de Bank Identification Number que foi comprometido para receber JavaScript malicioso injetado. Esse código carrega um script PHP hospedado externamente, que apresenta a isca ClickFix em forma de página falsa de verificação do Cloudflare. A página não entrega apenas uma mensagem estática: ela cria uma narrativa de erro resolvível pela própria vítima e a direciona para a execução manual no Windows. Essa etapa é importante porque desloca parte da responsabilidade de execução para uma interação humana, contornando controles que dependem exclusivamente de bloqueio de download automático ou de navegação suspeita.
Depois da interação da vítima, PowerShell entra como componente de orquestração. O primeiro estágio contata um servidor C2 e recupera um segundo script PowerShell. Esse segundo estágio tenta interferir na visibilidade local ao aplicar bypass em ETW, usado para eventos do Windows, e em AMSI, usado por mecanismos de segurança para inspecionar conteúdo de scripts. Em seguida, a cadeia deposita um loader baseado em Lua. O uso de Lua nessa etapa adiciona uma camada intermediária antes do implante final, permitindo que o shellcode seja descriptografado e executado em memória sem depender de um binário final gravado de forma simples no disco.
No estágio final, o shellcode carrega o MIMICRAT. O RAT se comunica com a infraestrutura de comando e controle por HTTPS na porta 443, com perfis HTTP desenhados para parecer tráfego comum de serviços de analytics. Essa escolha reduz a eficácia de regras que classificam tráfego apenas por porta ou protocolo, pois HTTPS na porta 443 é esperado em praticamente qualquer ambiente corporativo. O implante aceita cerca de duas dezenas de comandos, cobrindo controle de processos e sistema de arquivos, shell interativo, manipulação de tokens, injeção adicional de shellcode e tunelamento SOCKS5. Essas capacidades tornam o implante útil para operação pós-comprometimento, pivoteamento lógico e preparação de etapas posteriores.
A campanha também localiza a isca em 17 idiomas, selecionando o conteúdo com base nas preferências de idioma do navegador. Isso amplia o alcance sem exigir páginas separadas para cada região e permite que usuários em diferentes geografias recebam uma mensagem plausível em seu idioma. Foram identificadas vítimas em múltiplas regiões, incluindo uma universidade nos Estados Unidos e usuários chineses mencionados em discussões públicas, o que indica direcionamento amplo e oportunista em vez de uma segmentação única claramente delimitada.
A superfície exposta começa em usuários Windows que acessam sites legítimos já comprometidos e confiam na falsa verificação apresentada no navegador. O risco aumenta quando políticas locais permitem execução de PowerShell iniciada por usuário, quando a caixa Executar do Windows não é monitorada, quando scripts baixados de origem externa não são bloqueados por controles de endpoint e quando inspeção de rede não diferencia perfis HTTP anômalos dentro de sessões HTTPS esperadas. Ambientes educacionais, estáções administrativas e máquinas com permissões amplas podem sofrer impacto maior porque o RAT possui funções voltadas a pós-exploração.
A presença de JavaScript injetado em um serviço legítimo também expande a superfície para organizações que confiam em reputação de domínio como principal critério de permissão. Como o domínio inicial pode parecer benigno, bloqueios baseados apenas em categorias estáticas podem falhar. A defesa precisa correlacionar a sequência completa: navegação para um serviço legítimo comprometido, carregamento externo de PHP, renderização de verificação falsa, interação manual do usuário, criação de processo PowerShell e tráfego subsequente para infraestrutura C2.
- Estáções Windows de usuários que interagem com páginas falsas de verificação e executam ações manuais sugeridas pelo navegador.
- Ambientes onde PowerShell pode buscar conteúdo remoto e executar estágios sem bloqueio por política de execução, controle de aplicativo ou EDR.
- Proxies e gateways que permitem HTTPS na porta 443 sem análise comportamental de perfis HTTP e sem correlação com eventos de endpoint.
- Sites legítimos comprometidos usados como infraestrutura de entrega, incluindo o domínio defangado bincheck[.]io citado no fluxo observado.
A investigação deve começar pela correlação entre histórico de navegação, criação de processos e conexões de rede. Em endpoint, procure eventos em que navegadores sejam seguidos por execução de PowerShell sem fluxo administrativo esperado, especialmente quando a origem for uma página de verificação, um domínio legítimo incomum para o usuário ou uma janela de suporte falso. A execução pela caixa Executar do Windows pode deixar artefatos em histórico de comandos, eventos de criação de processo, telemetry de EDR e registros de interface gráfica, dependendo da configuração local.
Em telemetria de script, sinais de interesse incluem PowerShell que recupera conteúdo remoto, scripts encadeados, chamadas associadas a alteração de visibilidade de ETW e AMSI, e carregamento de conteúdo que não resulta em um executável claro no disco. Como a cadeia usa loader em Lua e shellcode em memória, a ausência de arquivo final não deve encerrar a análise. Procure alocações de memória executável, injeção em processos, criação de shell interativo, anomalias de token e processos que passam a abrir conexões HTTPS persistentes para destinos raros após a interação do usuário.
Na rede, a porta 443 não é suficiente para classificar o tráfego como legítimo. O ponto de hunting é o perfil: hosts de usuário iniciando sessões HTTPS para infraestrutura nova logo após PowerShell, padrões HTTP parecidos com analytics fora do conjunto normal de provedores usados pela organização, volume ou periodicidade incompatíveis com navegação comum e destinos que não aparecem no histórico anterior do ativo. Como a campanha tenta se confundir com tráfego de analytics, a análise deve combinar JA3/JA4 quando disponível, SNI, frequência, reputação, idade do domínio e relação temporal com eventos de processo.
- Navegador seguido por PowerShell iniciado pelo usuário, sem tarefa administrativa aprovada no mesmo período.
- PowerShell com recuperação de segundo estágio, sinais de bypass de ETW ou AMSI e execução de conteúdo em memória.
- Presença de Lua ou artefatos compatíveis com loader intermediário antes do implante final.
- Conexões HTTPS na porta 443 para destinos raros com perfil semelhante a analytics após a cadeia de execução.
- Eventos de manipulação de token, shell interativo, controle de processos, acesso incomum ao sistema de arquivos ou tunelamento SOCKS5.
A resposta deve priorizar contenção do endpoint com sinais da cadeia, preservação de telemetria e bloqueio de comunicação C2. Máquinas suspeitas devem ser isoladas da rede antes de limpeza, porque o MIMICRAT possui recursos que podem dar ao operador controle interativo e capacidade de movimentar tráfego por SOCKS5. A análise forense precisa coletar histórico de navegação, eventos de criação de processo, registros de PowerShell, alertas de AMSI, eventos de ETW disponíveis, conexões recentes, memória de processos suspeitos e artefatos relacionados a Lua ou shellcode carregado em memória.
No controle preventivo, organizações devem restringir PowerShell para usuários que não necessitam dele, aplicar políticas de controle de aplicativo, bloquear execução de scripts não assinados quando viável, reforçar EDR contra bypass de AMSI e ETW, e detectar cadeias em que navegadores originam execução de interpretadores. Treinamento de usuário também deve ser específico: verificações legítimas de serviços web não exigem colar comandos no Windows. Essa mensagem reduz o sucesso do ClickFix sem depender de detalhes do payload.
Para sites próprios, a mitigação envolve monitorar integridade de páginas, revisar alterações em JavaScript, procurar inclusões externas inesperadas e tratar rapidamente qualquer injeção que transforme um domínio legítimo em ponto de distribuição. Para consumidores corporativos, proxies e DNS devem registrar acessos a domínios legítimos que carregam scripts de terceiros inesperados, porque a reputação do domínio inicial não basta. Depois da contenção, a validação deve confirmar que não restaram persistências, sessões C2, túneis SOCKS5, tokens abusados ou processos injetados.
- Isolar endpoints com execução suspeita de PowerShell e comunicação HTTPS anômala após interação com página de verificação.
- Bloquear ou investigar destinos C2 observados internamente, mantendo indicadores defangados em registros compartilhados.
- Aplicar controle de aplicativo, restrições de PowerShell e monitoramento de criação de processo a partir de navegadores.
- Revisar sites próprios para JavaScript injetado, chamadas externas PHP inesperadas e alterações não autorizadas em páginas públicas.
- Reinicializar credenciais e tokens afetados quando houver evidência de impersonação, shell interativo ou acesso não autorizado a recursos sensíveis.
0 Comentários