Quem usa o script de Real User Monitoring do DebugBear para acompanhar as Core Web Vitals do site precisa agir rápido. A empresa confirmou um incidente de segurança em sua infraestrutura e orientou todos os clientes a removerem imediatamente o código de monitoramento, numa comunicação feita em 29 de outubro.
Esse ataque hacker DebugBear chamou atenção porque não se trata de uma falha qualquer: os invasores conseguiram sequestrar os registros de DNS da empresa, abrindo caminho para distribuir JavaScript malicioso através de um script que, em teoria, deveria apenas medir performance do site. Ou seja, uma ferramenta de monitoramento virou porta de entrada para fraude.
O trecho de código que precisa ser removido segue este padrão, variando apenas o ID do script conforme o site:
<script async src=”https://cdn.debugbear.com/YOUR_SCRIPT_ID.js”></script>
Por isso, equipes de SEO devem repassar esse alerta imediatamente para os times de desenvolvimento e segurança, que precisam não só remover o script, mas também investigar se houve acesso não autorizado ou alterações indevidas enquanto o código estava ativo no site.
O que aconteceu no ataque hacker DebugBear
Em uma atualização posterior, o DebugBear explicou que os atacantes comprometeram seus registros de DNS por meio do registrador de domínio da empresa. A investigação inicial indicou que o ataque mirou o site de um único cliente, e não há indícios de que os sistemas internos do DebugBear tenham sido violados.
Ainda segundo esse comunicado, a empresa relatou que, no momento, não conseguia nem receber e-mails enviados ao seu próprio domínio — um reflexo direto do sequestro de DNS. As atualizações sobre o caso continuaram sendo divulgadas pelo X oficial da empresa.
A firma de cibersegurança Hudson Rock analisou o caso e encontrou o JavaScript malicioso hospedado justamente em uma URL de script do DebugBear usada pela Polymarket, em 29 de outubro. O código tentava acessar o cliente de negociação já disponível no navegador de usuários logados. No dia seguinte, 30 de outubro, a própria Polymarket publicou um relatório do incidente confirmando que o script chegou a vender posições e movimentar fundos das carteiras de alguns usuários — e o pior: sem precisar da senha de ninguém, apenas aproveitando o acesso que um visitante já logado possuía.
É exatamente esse ponto que acende o alerta para outros donos de sites: afinal, o que mais um código malicioso conseguiria fazer usando as permissões de alguém que já está autenticado?
O que fazer agora se você usa o DebugBear
Diante desse cenário, Plustag IA recomenda que times de desenvolvimento e segurança sigam estes passos sem demora:
- Remova o embed de Real User Monitoring do DebugBear imediatamente. Verifique templates, plugins e gerenciadores de tags, limpe páginas em cache e confirme que o script não está mais carregando.
- Invalide sessões expostas e redefina senhas. Comece pelos administradores e demais usuários privilegiados que acessaram páginas afetadas. Revogue também credenciais de API potencialmente expostas. Se não for possível identificar quais usuários foram expostos, amplie a redefinição para mais contas. Confirme que sessões antigas sejam rejeitadas, já que trocar a senha nem sempre invalida sessões já abertas.
- Procure por alterações não autorizadas e sinais de persistência. Revise criação de contas, mudanças de permissão, histórico do gerenciador de tags, templates, plugins e scripts injetados, comparando tudo com uma versão confiavelmente limpa. Investigue se os atacantes conseguiram acesso aos seus sistemas e deixaram algum backdoor para uso futuro — são verificações a fazer, não achados confirmados em outros clientes.
- Identifique contas afetadas e desfaça mudanças indevidas. Peça para as equipes de desenvolvimento e segurança revisarem logs em busca de logins incomuns, contas novas, arquivos alterados e transações inesperadas enquanto o script estava ativo. Use os indicadores de código malicioso levantados pela análise do The Layman Security como guia para essa busca. Depois, investigue qualquer atividade suspeita, revogue acessos indevidos e reverta mudanças maliciosas já confirmadas.
- Coloque um site comprometido em modo de manutenção. Caso a violação seja confirmada, isole o site afetado e exiba uma página estática de manutenção com resposta HTTP 503 — algo que pode ser feito pelo próprio administrador do site, se for o caso. Em seguida, a equipe de segurança deve limpar o site ou restaurar um backup confiavelmente limpo, só colocando tudo de volta no ar depois de garantir que código malicioso e backdoors foram eliminados.
Os riscos não param no DebugBear
O payload capturado nesse ataque mirava especificamente as contas de negociação da Polymarket — os invasores usaram o script comprometido do DebugBear como porta de entrada para esse alvo de alto valor e conseguiram desviar fundos. No entanto, é bem possível que outros sites de alto valor também tenham sido alvo da mesma estratégia, já que ainda não está claro se outros clientes do DebugBear também receberam código malicioso.
Vale reforçar: remover a tag de monitoramento impede novos carregamentos do código malicioso, mas não desfaz ações não autorizadas já realizadas nem remove algo que um invasor possa ter plantado anteriormente no sistema. Por isso, a varredura completa seguida das etapas de investigação é tão importante quanto a remoção do script em si.
Com informações de searchenginejournal.com.
