A Cloudflare revelou quatro operações maliciosas direcionadas a lojas virtuais, envolvendo oito scripts JavaScript capazes de manipular o comportamento da loja no navegador do visitante sem fazer o site parecer inoperante. Os impactos incluíram o roubo de comissões de indicação, a interceptação de cliques, a falsificação de dados de análise, a desativação de ferramentas de monitoramento e suporte e a abertura de um canal para carregar JavaScript adicional de servidores remotos.
Segundo a empresa, o modelo de aprendizado de máquina Client-Side Security da Page Shield detectou todas as oito cargas durante tráfego em tempo real. Quando as campanhas foram posteriormente examinadas com ferramentas de segurança públicas, sete cargas não apareceram no VirusTotal, enquanto a URLScan não emitiu um veredito malicioso em nenhum dos casos. A Cloudflare afirma que uma das versões da família Lnkr permaneceu indexada na URLScan por cerca de dois anos e meio sem classificação, incluindo uma análise direta em janeiro de 2024.
Ataques que evitam a análise rápida
As quatro operações não dependiam de uma assinatura unificada nem de uma única técnica de ofuscação. Alguns scripts aguardavam um dispositivo, país, horário ou estado específico do navegador, enquanto outros monitoravam elementos que apareciam dinamicamente após o carregamento da página, executavam solicitações de indicação dentro de um quadro invisível ou carregavam novas instruções de um servidor externo. Essas condições tornam insuficiente uma única visita automatizada à página para detectar o comportamento.
Na primeira operação, a carga interceptava cliques de usuários de celulares em produtos e abria uma página determinada pelo invasor em uma nova aba, enquanto encaminhava a aba original por um link de indicação com o objetivo de atribuir a compra a uma conta que não tinha direito à comissão. As versões ativas usavam períodos de inatividade de até três dias e monitoravam elementos adicionados posteriormente à página.
A segunda operação roubava comissões de indicação sem precisar de um clique, por meio de um quadro oculto ou de um link clicado programaticamente. A Cloudflare não conseguiu provar que as solicitações realmente resultaram na atribuição de vendas ou no pagamento de comissões, mas confirmou que o código executava solicitações de indicação automáticas e ocultas.
Da sabotagem da pesquisa a uma porta dos fundos
A terceira operação era uma versão reutilizada da família Lnkr, anteriormente associada à interceptação de resultados de pesquisa. Dentro de uma loja virtual, algumas de suas funções antigas permaneciam inativas, mas o script enviava dados sobre os visitantes e continha um mecanismo para carregar e executar JavaScript arbitrário de servidores remotos. A Cloudflare não determinou o que esses servidores realmente executaram na segunda etapa.
A quarta operação tinha como alvo visitantes de celulares provenientes de campanhas pagas. Depois de passar por uma série de condições relacionadas ao dispositivo, à campanha, à rede e à localização geográfica, tentou remover ou desativar nove ferramentas de monitoramento e análise, ocultar o chat e o formulário de contato e substituir identidades publicitárias e analíticas por outras controladas pelo invasor. A empresa confirmou o carregamento de um script analítico alternativo e o envio de um sinal de rastreamento, mas não comprovou o sucesso do roubo de dados de sessão ou do desvio de receitas.
O que muda na prática?
O mecanismo da Cloudflare baseia-se em um modelo de redes neurais gráficas que analisa a estrutura do JavaScript e as relações entre seus componentes, em vez de procurar um endereço ou uma impressão digital conhecida. Os scripts considerados suspeitos, que representam menos de 0,3% do tráfego analisado, são encaminhados a um pequeno modelo de linguagem para obter uma segunda opinião e reduzir falsos positivos. Em seguida, a empresa utiliza um conjunto de modelos avançados para classificar o código em categorias que incluem comportamento legítimo, roubo de pagamentos, outros tipos de malware e mineração oculta, com revisão humana dos casos maliciosos ou inconclusivos.
A principal conclusão para as equipes das lojas é que a cadeia de marketing e as tags externas passaram a fazer parte da superfície de ataque, mas o material não comprova a invasão do Google Tag Manager, da AWS ou das plataformas de marketing cujos domínios foram imitados; ele indica o uso de domínios semelhantes para enganar análises rápidas. Portanto, não basta examinar a página uma única vez ou esperar pela classificação de um arquivo conhecido: monitorar o comportamento em diferentes estados, dispositivos e horários e analisar o código carregado dinamicamente parecem ser dois eixos fundamentais para detectar esse tipo de ataque.