LeakNet adota ClickFix e carregador em memória baseado em Deno

LeakNet adota ClickFix e carregador em memória baseado em Deno

Operação de ransomware passou a usar sites comprometidos com falsas verificações CAPTCHA para acionar comandos locais e chegar a uma cadeia pós-exploração com carregamento em memória, movimentação lateral, exfiltração e criptografia.

ComponenteOperação de ransomware LeakNet, páginas legítimas comprometidas, fluxo ClickFix e carregador baseado no runtime JavaScript Deno.
VetorUsuários são induzidos por falsas verificações CAPTCHA em sites comprometidos a copiar e executar um comando local associado ao msiexec.exe; também foi observada uma tentativa separada usando phishing via Microsoft Teams para iniciar cadeia semelhante.
ImpactoA cadeia pós-comprometimento pode carregar JavaScript codificado em Base64 diretamente em memória, obter próximos estágios, executar DLL maliciosa por side-loading, mover-se lateralmente com PsExec, preparar exfiltração em buckets S3 e avançar para criptografia.
PrioridadeDetectar execução anômala de ferramentas legítimas a partir de interação web ou Teams, bloquear carregamento não autorizado do runtime Deno, revisar evidências de side-loading de DLL, uso inesperado de PsExec e tráfego S3 incomum.
ArtefatosFalsas verificações CAPTCHA, msiexec.exe, runtime Deno, JavaScript codificado em Base64, DLL maliciosa, PsExec, consulta a credenciais Kerberos por utilitário nativo do Windows e buckets S3 para staging e exfiltração.
Resumo técnico

A operação de ransomware LeakNet incorporou a tática ClickFix como caminho de acesso inicial, substituindo em parte a dependência de credenciais compradas ou obtidas por intermediários de acesso inicial. O fluxo usa sites legítimos previamente comprometidos para apresentar verificações CAPTCHA falsas, criando uma situação em que a própria vítima é induzida a copiar e acionar um comando local no Windows. O ponto central para defesa é que o domínio visitado pode parecer confiável, enquanto o comportamento host local deixa sinais mais úteis do que uma simples reputação de URL.

Além do acesso inicial por ClickFix, a cadeia usa um carregador baseado no runtime JavaScript Deno para executar código em memória. Esse carregador processa JavaScript codificado em Base64, faz fingerprinting do sistema comprometido, contata um servidor externo para obter estágios adicionais e mantém um ciclo de consulta para buscar e executar novo código. A escolha por um runtime trazido pelo próprio operador reduz dependências do ambiente da vítima e desloca parte da detecção para telemetria de execução, criação de processos, carregamento de módulos e comunicação de saída.

O LeakNet surgiu em novembro de 2024 e se apresenta publicamente como um grupo voltado a liberdade na internet e transparência, mas a atividade descrita corresponde a intrusão com ransomware. Há referência a alvos industriais, o que aumenta a importância de separar ambientes de TI e OT, revisar acessos remotos e observar sinais de movimentação lateral antes da etapa de criptografia. A campanha não está limitada a um setor específico; a entrega por sites comprometidos permite alcance amplo e reduz sinais óbvios associados a infraestrutura criada diretamente pelo atacante.

Fluxo técnico

O fluxo começa quando um usuário acessa um site legítimo que foi adulterado para servir uma falsa checagem CAPTCHA. Em vez de apenas validar presença humana, a página orienta o usuário a copiar um comando e executá-lo pela caixa de execução do Windows. O artefato citado no contexto envolve msiexec.exe, utilitário legítimo do sistema operacional, o que torna a ação visualmente menos suspeita para usuários habituados a corrigir erros de instalação ou autenticação. A defesa não deve tratar o abuso de ferramenta legítima como benigno apenas pela assinatura do binário; a correlação entre navegador, área de transferência, janela de execução e criação de processo é o sinal mais importante.

Depois do acionamento inicial, a cadeia converge para o mesmo padrão pós-exploração observado em outros acessos. O carregador baseado em Deno executa JavaScript codificado em Base64 diretamente em memória, reduzindo evidências gravadas em disco. O código coleta características do host, consulta um servidor externo e passa a buscar estágios adicionais em repetição. Esse comportamento cria uma oportunidade de bloqueio antes do ransomware: mesmo quando o acesso inicial muda, a presença de runtime incomum, execução de código dinâmico e comunicações sucessivas para obtenção de tarefas indicam uma fase intermediária detectável.

A sequência posterior envolve side-loading de DLL para iniciar uma biblioteca maliciosa entregue pelo carregador. Em seguida, a operação usa PsExec para movimentação lateral, consulta credenciais Kerberos ativas com ferramenta nativa do Windows para entender contas e serviços alcançáveis, prepara dados para exfiltração e avança para criptografia. O uso de buckets S3 como área de staging e saída explora a aparência de tráfego cloud normal, principalmente em organizações que já usam serviços de armazenamento em nuvem. Uma tentativa separada de intrusão por phishing no Microsoft Teams terminou em carregador Deno semelhante; essa sobreposição pode indicar expansão de vetores do LeakNet ou adoção da técnica por outro operador, portanto a atribuição deve permanecer condicionada.

Superfície afetada

A superfície mais exposta combina usuários finais com permissão para executar comandos locais, estáções Windows com acesso à internet, navegadores que chegam a sites comprometidos e ambientes onde ferramentas administrativas legítimas podem ser chamadas sem controle granular. O risco aumenta quando controles de execução permitem runtimes não aprovados, quando o monitoramento privilegia apenas hashes conhecidos e quando o tráfego para serviços cloud é tratado como automaticamente confiável.

A campanha também pressiona controles de colaboração e identidade. O caso com Microsoft Teams mostra que a engenharia social pode migrar de páginas web comprometidas para canais corporativos de comunicação, ainda que a atribuição dessa tentativa não esteja confirmada. Em ambos os cenários, o problema operacional é semelhante: o operador tenta fazer a vítima iniciar a cadeia com uma ação aparentemente rotineira e, depois disso, usa ferramentas e componentes legítimos o suficiente para retardar a detecção.

  • Estáções Windows em que usuários conseguem iniciar processos por interfaces locais como a caixa Executar.
  • Ambientes que permitem execução de msiexec.exe, runtime Deno ou binários recém-introduzidos sem política de aplicação permitida.
  • Redes em que PsExec é usado legitimamente, mas sem baselining por origem, destino, conta e horário.
  • Organizações que usam S3 e não distinguem padrões normais de armazenamento de tráfego anômalo de staging ou exfiltração.
Hunting e telemetria

A investigação deve começar na transição entre navegador e execução local. Procure sessões em que visitas a páginas com comportamento de CAPTCHA sejam seguidas por alterações na área de transferência, abertura da caixa de execução do Windows ou criação de processos incomuns associados a instaladores e ferramentas do sistema. Como o domínio inicial pode ser legítimo e comprometido, a reputação de URL isolada tende a ser insuficiente. A correlação temporal entre evento web, processo filho e conexão de saída é mais confiável.

No endpoint, a presença de Deno em máquinas que não fazem desenvolvimento com esse runtime deve ser tratada como evento de alta prioridade. O mesmo vale para execução de JavaScript codificado ou carregado dinamicamente, processos que mantêm ciclos de consulta para servidores externos e cadeias em que o código não deixa arquivo persistente claro. A telemetria de EDR deve capturar linha de comando de forma segura para análise interna, mas a reportagem não reproduz comandos operacionais. O objetivo defensivo é identificar o efeito: execução de instalador acionada por engenharia social, carregamento em memória e busca recorrente de tarefas.

Na etapa pós-comprometimento, hunting deve cobrir side-loading de DLL, criação de serviços ou execução remota por PsExec, consultas a credenciais Kerberos por utilitários nativos, acesso incomum a compartilhamentos administrativos e tráfego S3 fora do padrão. Para S3, os sinais incluem volumes incompatíveis com o perfil do host, destinos nunca usados por aquela aplicação, transferência fora de janela operacional e contas que normalmente não fazem upload para armazenamento externo.

  • Processo associado a msiexec.exe iniciado logo após navegação para página com falsa verificação CAPTCHA.
  • Execução de Deno em estáções ou servidores sem justificativa de desenvolvimento ou automação aprovada.
  • JavaScript codificado em Base64 executado por runtime externo, especialmente com comunicação periódica para obter novos estágios.
  • Side-loading de DLL com binário legítimo carregando biblioteca inesperada em diretório incomum.
  • Uso de PsExec entre hosts que não fazem parte de rotinas administrativas documentadas.
  • Acesso a buckets S3 com padrão de upload, volume ou destino incompatível com o histórico do ativo.
Mitigação

A contenção deve priorizar a interrupção da cadeia antes da criptografia. Bloqueie execução não autorizada de runtimes trazidos pelo usuário ou pelo atacante, incluindo Deno quando não houver necessidade corporativa. Aplique controle de aplicação para impedir que instaladores e ferramentas administrativas sejam invocados fora de caminhos, assinaturas e contextos permitidos. Em estáções de usuário, reduza a capacidade de acionar comandos por engenharia social e monitore eventos em que instruções copiadas de páginas web resultem em criação de processos sensíveis.

Para reduzir o impacto do pós-comprometimento, restrinja PsExec a contas e hosts administrativos definidos, segmente a rede, remova privilégios locais desnecessários e monitore autenticação lateral. Revise buckets S3, políticas de acesso e chaves usadas por workloads internos; qualquer credencial exposta ou usada em transferência suspeita deve ser rotacionada. A resposta a um alerta desse tipo deve incluir preservação de memória quando possível, coleta de árvore de processos, artefatos de carregamento de DLL, histórico de conexões e validação de que não houve estágio de criptografia ou preparação de exfiltração.

A camada de conscientização deve ser específica, sem depender de alertas genéricos sobre phishing. Usuários precisam reconhecer que páginas web ou mensagens de colaboração que pedem para copiar comandos para corrigir erros, validar CAPTCHA ou resolver falhas de acesso são sinais de abuso. Para a equipe técnica, a prioridade é transformar essa regra em controle: bloquear padrões de execução, registrar eventos de processo completos, correlacionar canais de colaboração com criação de processos e tratar tráfego cloud incomum como possível exfiltração, mesmo quando o serviço de destino seja legítimo.

  • Aplicar política de controle de aplicação para bloquear runtimes e instaladores fora de uso aprovado.
  • Criar detecção para execução de ferramentas legítimas iniciadas por fluxo de navegador ou mensagem de colaboração.
  • Restringir PsExec, compartilhamentos administrativos e privilégios locais a escopos documentados.
  • Monitorar e revisar uploads para S3 por host, conta, volume, horário e destino.
  • Investigar side-loading de DLL e execução em memória antes de qualquer evidência de criptografia.
  • Rotacionar credenciais e chaves associadas a hosts que apresentem sinais de staging, exfiltração ou movimentação lateral.

Postar um comentário

0 Comentários