Cloudflare Client-Side Security Encontrou Oito Payloads Que Scanners Públicos Não Detectaram

Cloudflare Client-Side Security encontrou oito payloads maliciosos em quatro campanhas contra vitrines digitais, embora serviços públicos de análise tenham emitido pouco ou nenhum alerta. As páginas afetadas continuavam carregando, exibindo produtos e processando interações dos clientes. Sob essa experiência aparentemente normal, o JavaScript redirecionava créditos de afiliados, ocultava solicitações de rede, prejudicava a análise de dados e criava um canal para código remoto.

A Cloudflare divulgou as descobertas em 16 de setembro de 2026. Sua principal conclusão desafia uma suposição comum em segurança: uma análise limpa não significa que uma sessão no navegador esteja se comportando com segurança. Sete payloads não estavam presentes no VirusTotal quando a Cloudflare os analisou, enquanto o urlscan.io não emitiu nenhum veredito malicioso para nenhum dos oito.

A comparação é importante, mas exige contexto. VirusTotal e urlscan.io fornecem inteligência valiosa com base em arquivos, URLs, mecanismos e comportamentos observáveis enviados. A Cloudflare, por outro lado, encontrou esses scripts em tráfego real de sites e analisou sua estrutura interna. A divergência revela uma lacuna de cobertura entre verificar um artefato uma única vez e observar continuamente o código chegar a navegadores reais.

Quatro Campanhas Voltaram o Tráfego Normal de Vitrines Contra os Comerciantes

A descoberta da Cloudflare é relevante porque essas campanhas atacaram operações de receita sem necessariamente interromper o checkout ou tirar um site do ar.

As descobertas sobre quatro campanhas da empresa abrangem roubo de afiliados, manipulação de cliques, carregamento de código remoto, interferência em análises e rastreamento de visitantes. A Cloudflare afirma que seu sistema automatizado identificou os payloads antes da investigação por analistas humanos.

A primeira operação visava compradores em dispositivos móveis durante períodos selecionados. Ela esperava que elementos qualificados de produtos aparecessem, interceptava o clique do comprador e abria uma página escolhida pelo invasor em outra aba. Enquanto isso, a aba original passava por uma rota de rastreamento de afiliados antes de retornar à loja.

Esse desvio poderia atribuir o crédito a um afiliado que nunca indicou o cliente. O comerciante poderia então pagar uma comissão indevida ou negar crédito ao parceiro legítimo. O cliente poderia não perceber, pois a vitrine continuava funcionando.

A Cloudflare encontrou cinco versões relacionadas nessa operação. Duas estavam ativas quando foram capturadas, enquanto três estavam pausadas. As variantes ativas verificavam o tipo de dispositivo, o horário local, o estado do navegador, a disponibilidade do produto e execuções recentes antes de fazer qualquer coisa visível.

Versões posteriores armazenavam um período de espera de três dias no localStorage do navegador, uma área de armazenamento persistente disponível para scripts de sites. Depois de ativado, o malware permaneceria silencioso nesse dispositivo por dias. Assim, um scanner que repetisse a mesma visita poderia não observar nada incomum.

A segunda operação eliminava até mesmo a necessidade de um clique do comprador. Seu script emitia uma solicitação de afiliado por meio de um iframe fora da tela, uma página incorporada e ocultada fora do layout visível. Um link escondido poderia clicar em si mesmo quando o método principal falhasse.

O código primeiro contatava um serviço de geolocalização por IP, mas ignorava os dados geográficos retornados. Se essa solicitação falhasse, o malware era interrompido. A Cloudflare não conseguiu determinar se esse comportamento era uma evasão deliberada de sandbox ou lógica remanescente.

A terceira operação era mais ampla. Um script incorporado diretamente ao HTML de um comerciante continha módulos antigos de sequestro de buscas, além de telemetria ativa e funções de carregamento remoto. Ele podia solicitar novo JavaScript de servidores controlados pelos invasores após o carregamento da página.

Isso criava uma porta dos fundos na vitrine. O script inicial não precisava conter a ação final, pois um servidor remoto poderia alterar sua resposta. A Cloudflare não conseguiu determinar quais payloads de segundo estágio os invasores entregaram na prática.

A quarta operação visava visitantes móveis que chegavam por campanhas pagas. Ela tentava desativar nove ferramentas de análise ou monitoramento, suprimir interfaces de suporte ao cliente, substituir identidades publicitárias e transmitir telemetria.

O script verificava se a largura da viewport era inferior a 477 pixels. Também procurava tags de campanha selecionadas durante os dois primeiros carregamentos de página do visitante. Uma lista de 325 substrings de IP ajudava a evitar redes associadas a analistas ou infraestrutura automatizada.

Essas operações não compartilhavam um único domínio, assinatura ou estratégia de monetização. Sua característica comum era a execução seletiva. Cada script esperava por um estado do navegador que uma inspeção automatizada breve dificilmente reproduziria.

Por Que Uma Única Análise Limpa Nunca Foi Suficiente

O conflito central é a visibilidade contínua do navegador versus a análise pontual, e não machine learning versus todos os controles de segurança existentes.

Scanners tradicionais respondem a perguntas úteis, mas limitadas. Alguém já enviou este arquivo antes? Um mecanismo reconhece sua assinatura? Uma visita controlada dispara um comportamento observável? Essas perguntas tornam-se menos confiáveis quando o malware escolhe quais visitantes podem ver sua lógica real.

Um exemplo da Cloudflare teria permanecido indexado pelo urlscan.io sem classificação por quase dois anos e meio. Sua família de malware mais ampla já estava documentada, mas aquele payload específico não recebeu o mesmo rótulo acionável.

Um crawler estático pode carregar a página, inspecionar seus arquivos e registrar o tráfego de rede. No entanto, o resultado representa uma configuração de navegador em um único momento. Malware em vitrines pode testar horário, dispositivo, localização, referenciador, cookies, largura de tela e histórico de sessão antes de ser ativado.

O sequestrador de afiliados fora do horário comercial observava blocos de produtos criados após o carregamento inicial da página. Ele usava MutationObserver, uma interface do navegador que detecta alterações na estrutura do documento da página. Um crawler que capturasse apenas o HTML original poderia não identificar o elemento interceptado.

O ocultador voltado a campanhas pagas para dispositivos móveis foi além. Ele rejeitava redes corporativas, provedores de nuvem, instalações de hospedagem, VPNs, proxies, saídas Tor e várias localizações geográficas. Essas verificações excluem de forma desproporcional os ambientes usados com frequência por pesquisadores e scanners automatizados.

Isso produz uma inversão desconfortável. Um teste limpo em desktop, feito a partir de uma rede corporativa, pode se tornar evidência de que a lógica de evasão está funcionando. O comerciante vê análises normais porque a ramificação maliciosa nunca é executada para as pessoas que a investigam.

As campanhas também mostram por que a saúde operacional de um site pode ser enganosa. O monitoramento de disponibilidade confirma que as páginas respondem. Testes sintéticos de checkout confirmam que uma transação é concluída. Nenhuma dessas verificações necessariamente revela quem recebe a atribuição ou quais conexões de navegador ocorrem.

Os logs do lado do servidor apresentam outra visão parcial. Um script de terceiros é executado com acesso ao documento da página e ao contexto do navegador. Os riscos de scripts de terceiros da OWASP incluem perda de controle sobre alterações, execução arbitrária de código e divulgação de dados sensíveis.

As evidências da Cloudflare não tornam os scanners públicos obsoletos. Artefatos enviados, observações históricas, dados de reputação e indicadores compartilhados continuam essenciais para investigações. As descobertas mostram, em vez disso, que esses sistemas não podem rotular códigos que nunca recebem ou comportamentos que nunca disparam.

A posição defensiva mais robusta combina múltiplas perspectivas. Serviços de reputação podem identificar infraestrutura conhecida. A análise de código pode examinar a intenção. A telemetria do navegador pode revelar recursos carregados e conexões. Analistas humanos podem então determinar se um veredito automatizado corresponde ao contexto operacional.

Esse modelo em camadas pressiona equipes de segurança que ainda tratam uma análise única como aprovação definitiva. Ele também pressiona equipes de marketing e comércio, pois seus gerenciadores de tags frequentemente controlam códigos que as equipes de segurança raramente revisam continuamente.

Como Cloudflare Client-Side Security Analisa JavaScript Evasivo

Cloudflare Client-Side Security concentra-se primeiro na estrutura do código e, em seguida, usa modelos de linguagem e revisão humana para restringir descobertas incertas.

O classificador de linha de frente da Cloudflare é uma rede neural de grafos, ou GNN. Esse modelo de machine learning processa relações entre elementos conectados. Aqui, esses elementos vêm da árvore de sintaxe abstrata do JavaScript, que representa o código como operações estruturadas, em vez de texto bruto.

Essa distinção ajuda o modelo a ignorar alterações superficiais. Invasores podem renomear variáveis, minificar arquivos, alternar strings ou adicionar ramificações não utilizadas. Essas mudanças alteram o texto visível, mas podem preservar as relações entre chamadas, condições, eventos da página e solicitações de rede.

A Cloudflare afirma que sua GNN sinalizou todos os oito payloads no tráfego real. A empresa descreveu anteriormente a arquitetura de detecção mais ampla como uma cascata, e não como um único modelo tomando todas as decisões.

A GNN é ajustada para detectar estruturas suspeitas. Scripts considerados benignos deixam o pipeline mais cedo. Scripts potencialmente maliciosos recebem uma segunda avaliação de um modelo de linguagem menor executado por meio do Workers AI.

Essa segunda etapa aborda o problema de falsos positivos. Pacotes publicitários legítimos, desafios contra bots, scripts de rastreamento e frameworks compactados podem se assemelhar a código malicioso. Eles podem usar ofuscação, execução dinâmica, chamadas de rede incomuns ou outros padrões que parecem suspeitos sem contexto.

A Cloudflare informou em uma atualização anterior de produto que seus sistemas avaliam 3,5 bilhões de scripts diariamente. Também afirmou que uma zona empresarial média expõe cerca de 2.200 scripts únicos. Aproximadamente um terço pode mudar em um período de 30 dias, segundo a empresa.

Esses números vêm da Cloudflare e não foram auditados de forma independente para esta divulgação de campanha. Ainda assim, eles ilustram o desafio operacional. Mesmo uma baixa taxa de falsos positivos torna-se inadministrável quando aplicada a bilhões de avaliações.

Na investigação mais recente, a Cloudflare afirma que menos de 0,3% do tráfego analisado chegou à etapa de revisão do modelo de linguagem. Se esse modelo corroborasse a GNN, o sistema alertava o cliente.

Amostras mais complexas receberam outra camada de análise. A Cloudflare usou modelos de cerca de seis famílias como “professores” independentes. Cada um examinou o mesmo script em uma sessão nova e podia acessar um avaliador restrito de JavaScript.

Os modelos votaram entre quatro rótulos: benigno, captura de dados de pagamento, outro malware e cryptomining. A Cloudflare ponderou esses votos usando classificações externas de desempenho dos modelos. Revisores humanos examinaram scripts rotulados como maliciosos ou sem maioria de dois terços.

Isso não é um ciclo totalmente autônomo. A Cloudflare reconhece que o feedback para o treinamento da GNN continua parcialmente manual. A empresa também planeja adicionar o Cloudflare Sandbox para análises mais profundas em ambientes isolados.

A abordagem combina classificação estrutural, revisão semântica, discordância entre modelos e julgamento de analistas. Sua vantagem não é que um modelo de linguagem de alguma forma “entenda” todos os ataques. A vantagem é que cada etapa aborda um modo de falha diferente.

A GNN pode reconhecer semelhanças estruturais em alto volume. O modelo de linguagem pode filtrar JavaScript estranho, mas legítimo. Vários modelos professores podem expor incertezas. Analistas podem investigar o conjunto menor em que os sinais automatizados continuam preocupantes ou divididos.

O monitoramento contínuo fornece o contexto em torno desses julgamentos. A documentação de segurança da Cloudflare afirma que o serviço observa scripts, conexões e cookies carregados pelos visitantes. Recursos avançados acrescentam detecção de scripts maliciosos, alertas de alteração de código e regras de segurança de conteúdo.

Essa arquitetura atende diretamente ao principal desafio. Ferramentas pontuais inspecionam uma amostra ou sessão escolhida. Relatórios contínuos do navegador registram como os recursos aparecem em visitas reais, aumentando a chance de que malwares seletivos acabem se revelando.

O navegador tornou-se parte do sistema de receita

Esses ataques mostram que a segurança no lado do cliente agora protege atribuição, análises e acesso dos clientes, além dos dados de pagamento.

As duas primeiras campanhas visavam a economia de afiliados, e não números de cartões. Essa distinção importa porque muitos programas de segurança para lojas virtuais concentram seus controles mais rigorosos no checkout. A receita ainda pode vazar antes, na jornada do cliente.

Sistemas de afiliados determinam qual parceiro recebe crédito por uma compra. Os atacantes não precisam interromper a transação quando conseguem alterar essa decisão. Uma solicitação fraudulenta de atribuição pode transformar uma venda legítima em uma comissão indevida.

A manobra de duas abas da primeira campanha preservava o fluxo de compra do cliente. Uma aba mantinha o visitante engajado, enquanto a outra passava pela rota de rastreamento do atacante. O ataque se beneficiava de parecer um evento de navegação normal.

A variante sem clique era ainda mais silenciosa. Um iframe invisível podia emitir uma solicitação de afiliado sem interação relevante do cliente. A Cloudflare confirmou as solicitações automatizadas, mas não estabeleceu se elas resultaram em comissões pagas.

Essa limitação deve permanecer visível. O código pode comprovar intenção e capacidade sem demonstrar dano financeiro efetivamente realizado. Registros de atribuição do comerciante, dados de contas de afiliados e históricos de pagamentos seriam necessários para medir a perda real.

O cloaker de mídia paga mirava outro ativo empresarial: a observabilidade. Ele se concentrava no tráfego que os comerciantes já haviam comprado por meio de buscas pagas, campanhas de texto e outros canais marcados. Essas sessões eram valiosas justamente porque os gastos de aquisição as haviam levado à loja.

O malware tentava substituir identificadores de análise enquanto desativava ferramentas de monitoramento e suporte. Se obtivesse sucesso, poderia corromper relatórios de campanhas e fazer com que tráfego legítimo parecesse pertencer a outro lugar.

Ele também suprimia controles de chat e contato. Um comprador que percebesse algo incomum poderia perder o caminho mais fácil para relatá-lo. O comerciante então perderia tanto a telemetria quanto o feedback direto dos clientes.

Os testes em sandbox da Cloudflare confirmaram que um script de análise substituto foi carregado e disparou um beacon de rastreamento. No entanto, a empresa não comprovou que os atacantes capturaram telemetria utilizável ou desviaram receita publicitária.

A backdoor da loja virtual apresentava um risco diferente. Quando o script podia carregar JavaScript remoto arbitrário, as opções do atacante deixavam de se limitar aos módulos observados. Instruções futuras poderiam mudar sem outra edição no HTML do comerciante.

Essa flexibilidade complica a delimitação de incidentes. Remover um redirecionamento visível não comprova que o atacante não possuía outras capacidades. As equipes de resposta precisam identificar o caminho de inserção inicial, endpoints remotos, sessões afetadas e qualquer comprometimento administrativo.

A Cloudflare não conseguiu determinar como esse script entrou no HTML do comerciante. Ela identificou credenciais comprometidas, alterações não autorizadas em templates e temas ou plugins infectados como rotas plausíveis, não como causas confirmadas.

Essa incerteza importa para a remediação. Bloquear um domínio observado pode interromper uma rota de entrega, enquanto mantém aberta a via de acesso original. Uma resposta duradoura exige revisão de credenciais, verificações de integridade de templates, inventário de dependências e análise das permissões do gerenciador de tags.

O setor já reconhece o navegador como parte do perímetro de segurança de pagamentos. As orientações sobre páginas de pagamento do PCI Security Standards Council concentram-se em autorizar scripts, verificar integridade e monitorar páginas em busca de alterações não autorizadas.

As campanhas da Cloudflare ampliam a razão operacional para realizar esse trabalho. O navegador não apenas renderiza um formulário de checkout. Ele atribui crédito de marketing, registra comportamentos, carrega ferramentas de suporte e determina quais serviços externos recebem dados dos clientes.

Portanto, as equipes de segurança, marketing, comércio e análise compartilham a mesma superfície de ataque. Uma tag de marketing aprovada para medição pode se tornar uma rota de entrega. Um tema comprometido pode se tornar um canal de comando. Um mecanismo de atribuição pode se tornar alvo de roubo.

Essa sobreposição cria pressão organizacional. Equipes de segurança precisam de visibilidade sobre mudanças no lado do navegador, enquanto equipes de marketing precisam de um processo de revisão que não paralise todas as campanhas. O problema difícil é governar scripts que mudam rapidamente sem tornar inviáveis as operações normais da loja virtual.

As descobertas da Cloudflare ainda exigem uma leitura cuidadosa

As evidências das campanhas apoiam o monitoramento contínuo, mas não validam de forma independente todas as alegações de produto nem quantificam as perdas finais dos comerciantes.

A Cloudflare descobriu as amostras, operou o sistema de detecção e publicou a análise técnica. Isso dá à empresa acesso direto a telemetria valiosa. Também significa que a comparação central de desempenho vem do fornecedor que vende o serviço avançado de detecção.

A divulgação nomeia oito payloads e explica seu comportamento, mas omite as identidades dos comerciantes afetados. Essa decisão protege as vítimas e evita criar uma nova lista de alvos. Ela também limita a verificação independente das consequências financeiras e operacionais dos incidentes.

A Cloudflare não publicou um benchmark controlado comparando seu sistema com todos os scanners em condições idênticas. Suas evidências mostram que o VirusTotal não tinha sete payloads e que o urlscan.io não retornou vereditos maliciosos. Isso é mais limitado do que provar detecção superior em todo o mercado.

A ingestão também difere da classificação. Um serviço não pode rotular um arquivo que nunca recebeu. A Cloudflare observou os scripts porque o tráfego afetado passou por sua rede e seu fluxo de relatórios de navegador. Essa vantagem de acesso é distinta da precisão do modelo.

O único payload já conhecido pelo VirusTotal complica ainda mais uma narrativa simples de vencedores e perdedores. O histórico público não revelou quando o veredito malicioso apareceu. Portanto, o registro disponível não pode estabelecer qual sistema o identificou primeiro.

Falsos negativos merecem atenção, mas falsos positivos também. Um sistema que sinaliza JavaScript desconhecido de forma excessivamente agressiva pode sobrecarregar analistas ou bloquear comércio legítimo. A Cloudflare usa um modelo de linguagem adicional em parte porque código benigno frequentemente se parece estruturalmente com malware.

A Cloudflare relatou anteriormente reduções substanciais de falsos positivos após adicionar essa segunda etapa. Esses resultados foram avaliações internas, não uma análise independente revisada por pares. Os clientes devem avaliar a qualidade dos alertas em relação às próprias populações de scripts e aos resultados de incidentes.

O pipeline de modelos também contém escolhas humanas. Os limiares de decisão determinam quais scripts avançam. Os prompts moldam a análise do modelo de linguagem. Os pesos de classificação dos modelos influenciam os votos dos avaliadores. Analistas humanos resolvem casos selecionados e devolvem rótulos ao treinamento.

Essas escolhas não invalidam as descobertas. Elas mostram por que “a IA detectou” é uma explicação incompleta. A qualidade da detecção depende de telemetria, design de modelos, limiares, revisão de analistas e do processo de resposta após um alerta.

A Content Security Policy, ou CSP, continua sendo outra camada importante. A CSP informa aos navegadores quais recursos e conexões uma página deve permitir. Seu modo somente de relatório pode coletar violações antes da aplicação, como descrito na referência de relatórios de CSP.

No entanto, somente o relatório não bloqueia código malicioso. Uma lista de permissões excessivamente ampla pode permitir um fornecedor comprometido. Uma inserção direta a partir de uma origem já confiável também pode contornar restrições simples de domínio.

A aplicação rigorosa introduz seu próprio custo operacional. Lojas virtuais modernas carregam serviços de publicidade, experimentação, pagamentos, personalização, suporte e análises. Seus domínios e códigos podem mudar com frequência, tornando políticas restritas mais difíceis de manter.

A Subresource Integrity pode verificar se um arquivo carregado remotamente corresponde a um hash aprovado. Ela funciona melhor para recursos estáveis. Torna-se mais difícil quando um fornecedor altera intencionalmente scripts sem publicar arquivos fixos e versionados.

A conclusão prática não é que um controle substitui todos os outros. Observação contínua, inventário de scripts, verificações de integridade, CSP, inteligência de reputação e resposta a incidentes cobrem lacunas diferentes.

A evidência mais forte da Cloudflare diz respeito a malwares seletivos encontrados em sua própria telemetria. As áreas não comprovadas envolvem roubo de receita efetivamente realizado, atividade de segunda etapa, acesso inicial e desempenho em ataques não observados. Esses limites devem orientar qualquer decisão de compra ou implantação.

Três sinais mostrarão se a detecção contínua entrega resultados

O próximo teste é verificar se a Cloudflare consegue transformar essas descobertas em detecção repetível, evidências mais claras e resposta mais rápida dos comerciantes.

O primeiro sinal é uma validação técnica mais ampla. Pesquisadores de segurança podem usar os indicadores publicados para procurar infraestrutura e código relacionados em outros ambientes. Descobertas adicionais mostrariam se as quatro operações foram comprometimentos isolados ou partes de campanhas mais amplas.

Análises independentes também poderiam confirmar o comportamento de atribuição dos scripts, os caminhos de carregamento remoto e os filtros anti-análise. Se pesquisadores reproduzirem essas descobertas, a interpretação da Cloudflare se fortalece. Se encontrarem explicações benignas ou resultados diferentes, a confiança deve ser reduzida.

O segundo sinal é a qualidade da detecção após a Cloudflare expandir seu fluxo de trabalho de sandbox. A execução isolada no navegador poderia fornecer evidências mais fortes sobre o comportamento dos payloads, ao mesmo tempo que protege os sistemas de produção. Também poderia revelar quais suspeitas dos modelos falham durante os testes em tempo de execução.

Relatórios úteis incluiriam precisão dos alertas, ataques confirmados por analistas, substituições e casos não detectados. Os números agregados devem separar o tráfego analisado de scripts únicos, porque a execução repetida pode distorcer as medições de desempenho.

Os clientes devem observar a qualidade das explicações, não apenas os totais de alertas. Um aviso útil deve identificar o caminho de código acionador, a conexão observada, as páginas afetadas e o estado relevante do navegador. Um rótulo genérico de malicioso cria trabalho sem orientar a contenção.

O terceiro sinal é o tempo de resposta do comerciante. Um alerta tecnicamente correto tem valor limitado se permanecer sem ser visto, não tiver um responsável ou não puder acionar uma investigação coordenada. As equipes das lojas virtuais precisam de um caminho das evidências do navegador até a contenção.

Esse processo deve identificar quem pode desativar uma tag, revogar credenciais, restaurar um template, bloquear um endpoint e validar as análises posteriormente. Também deve preservar as evidências necessárias para determinar se comissões, dados de clientes ou medições de campanhas foram afetados.

O monitoramento contínuo torna-se mais persuasivo quando reduz o intervalo entre a primeira execução maliciosa e sua remoção bem-sucedida. Torna-se menos persuasivo se as equipes recebem alertas, mas não conseguem distinguir um comprometimento real de alterações rotineiras em scripts.

Os proprietários de lojas devem fazer uma pergunta direta: seus controles atuais conseguem explicar qual JavaScript chegou a um cliente real, o que esse código fez e a que lugar ele se conectou? Uma varredura limpa não consegue responder às três perguntas.

O Cloudflare Client-Side Security oferece uma abordagem para obter essa visibilidade, respaldada por uma divulgação tecnicamente detalhada do fornecedor. As evidências merecem atenção, mas os compradores ainda devem testar a qualidade dos alertas e a integração de resposta em suas próprias vitrines.

A ação imediata vai além da compra de um produto. Faça um inventário dos scripts no navegador, revise as permissões do gerenciador de tags, teste as políticas de relatórios e defina quem é responsável pelos alertas do lado do cliente. Em seguida, avalie se esses controles detectam comportamentos que as varreduras comuns de disponibilidade e vulnerabilidades não enxergam.