A ofuscação de JavaScript consiste em transformar um código JavaScript normal e legível por humanos em uma forma intencionalmente difícil de ler e compreender. A ofuscação é geralmente usada para ocultar o significado pretendido do código — e, como resultado, torna extremamente difícil acompanhar ou fazer engenharia reversa das funções do código. Ao contrário da criptografia de código, a ofuscação não exige um algoritmo ou chave privada para ser executada. A lógica e a funcionalidade do código permanecem exatamente as mesmas, mas o código é repleto de nomes de funções vagos e opacos, estruturas programáticas estranhas e strings codificadas.
Desenvolvedores às vezes utilizam ferramentas como ofuscadores de JavaScript para proteger seu código e propriedade intelectual, evitando que sejam roubados. Mas do ponto de vista de segurança, especialmente no contexto de scripts de terceiros, código ofuscado é um sinal de alerta enorme. Atacantes frequentemente usam essa ofuscação para esconder seu código malicioso — que pode ser qualquer coisa, desde malware, lógica de roubo de dados ou código de exploração — dentro do que parece ser uma mistura aleatória de texto. Isso por si só muitas vezes consegue contornar scanners de segurança simples e torna a análise manual de scripts muito mais difícil.
Por que Desofuscar JavaScript é Importante para a Segurança?
Quando se trata de segurança web, a visibilidade do payload — ou seja, a capacidade de ver e inspecionar o código que está sendo executado no seu site — é absolutamente crítica. Desofuscar JavaScript (reverter ou decodificar o código) fornece a um analista de segurança uma compreensão clara do script e do que ele está executando por baixo dos panos. Se você não consegue enxergar através dessa ofuscação, está efetivamente cego para o que aquele código pode estar fazendo.
Depender apenas de medidas de segurança superficiais não é suficiente para proteger seu site. Por exemplo, cabeçalhos de Content Security Policy podem restringir de onde os scripts têm permissão para carregar, mas não oferecem nenhuma visibilidade sobre o payload dos próprios scripts. Se um host de terceiros for comprometido e começar a servir malware ofuscado — como relatamos em 2024 com o ataque ao Polyfill —, um CSP não vai indicar que o conteúdo do script é malicioso. Como ele vem de uma fonte aprovada, será confiável e não sinalizará o conteúdo potencialmente malicioso sendo servido.
Outro motivo pelo qual a visibilidade do payload é crítica está relacionado à natureza dinâmica da maioria dos ataques do lado do cliente. Conforme abordado em nosso relatório de ataques client-side do segundo trimestre, a cside começou a observar cada vez mais ataques que injetam código ofuscado em sites que frequentemente se comunicam de volta com um servidor de comando e controle para receber instruções adicionais. Isso pode expor um site a ameaças como publicidade maliciosa e redirecionamentos, scripts de cryptojacking e kits de exploração de navegador, todos controlados dinamicamente por um terceiro.
Quais são os Principais Sinais de Alerta em JavaScript?
Código Ilegível ou Embaralhado
Um dos maiores sinais de alerta a observar é quando o código de um script é um emaranhado sem sentido de caracteres, longos arrays numéricos e funções estranhas que não se parecem com nenhum código legível por humanos. Atacantes frequentemente ocultam strings codificando-as usando hexadecimal, Base64 e escapes Unicode, dividindo-as em pedaços ilegíveis. Variáveis assim se parecem com _0x5e ou aa1122bbcc e raramente terão identificadores com significado. Bibliotecas legítimas podem minificar código que se assemelha a isso, mas normalmente não serão profundamente ofuscadas com dados inúteis.
Dados Codificados/Inúteis em Strings
Scripts maliciosos frequentemente ocultam strings críticas (como URLs, palavras-chave, payloads JavaScript) codificando-as e inserindo dados inúteis nelas. Por exemplo, podem ter uma URL ofuscada via codificação hexadecimal e espalhar múltiplas substrings inúteis constantes ao longo dela para dificultar a decodificação. Funções como atob(), unescape() e rotinas personalizadas que transformam strings são frequentemente indicadores claros de que o script está tentando ocultar algo. No passado, atacantes eram conhecidos por inserir texto aleatório ou usar múltiplas camadas de codificação para esconder variáveis como eval e document.cookie.
Geração Dinâmica de Funções (eval e similares)
Outro sinal de alerta em um script é o uso de funções como eval(), o construtor Function() ou setTimeout() e setInterval(). Isso frequentemente significa que o script está construindo código em tempo de execução, o que pode ser uma técnica favorita de malware para desempacotar o payload real. Scripts modernos e legítimos raramente usam eval() devido às implicações de segurança e desempenho, portanto sua presença em um script de terceiros deve levantar suspeitas. Da mesma forma, criar elementos de script no DOM dinamicamente usando document.createElement('script') é outra forma de injetar código malicioso. Se você identificar código que constrói uma tag <script> com uma URL externa suspeita, esse é um sinal de alerta importante de que seu site pode estar comprometido.
Conexões Externas Suspeitas
Qualquer script de terceiros que faça referência a domínios externos ou IPs não relacionados à função do site é um sinal claro de comportamento malicioso. Por exemplo, se um script ofuscado de repente faz uma requisição fetch() ou XHR para um domínio não relacionado ao site, isso é frequentemente um indicador de comportamento malicioso. Atacantes costumam usar seus próprios servidores para exfiltração ou endpoints de controle, e qualquer aparição desses domínios em código de terceiros é um sinal de alerta.
Truques de Manipulação de HTML e DOM
JavaScript malicioso ofuscado frequentemente manipula a página de formas furtivas. Isso é comumente observado pela criação de elementos invisíveis ou sobrepostos, definindo valores de z-index extremamente altos (para cobrir a página com uma entrada ou prompt fraudulento) e injetando formulários e event listeners. A cside relatou recentemente sobre um ataque que ocorreu no CoinMarketCap que usou um pop-up malicioso com um valor alto de z-index para enganar usuários a conectarem suas carteiras a um terceiro malicioso, drenando suas carteiras de qualquer criptomoeda contida nelas.
Ofuscação Polimórfica em Ataques JavaScript
Uma das técnicas mais avançadas e evasivas que atacantes podem usar para ocultar a verdadeira intenção de seu script é a ofuscação polimórfica. A ofuscação polimórfica é um código que muda sua estrutura cada vez que o payload é entregue, mesmo que o comportamento subjacente permaneça o mesmo. Essa técnica é emprestada do desenvolvimento tradicional de malware, onde binários polimórficos mutam sua aparência para escapar da detecção de antivírus. No ecossistema JavaScript baseado em navegador, atacantes alcançam essa evasão similar rotacionando nomes de variáveis, reestruturando funções, alterando o fluxo de controle e inserindo código inútil randomizado ao longo do script.
Isso significa que dois payloads com a mesma intenção — como capturar dados de um formulário de checkout em um site — podem parecer completamente diferentes no nível do código. Isso faz com que métodos de detecção como assinaturas baseadas em hash e filtros estáticos baseados em IOC sejam insuficientes, tornando a proteção contra eles incrivelmente difícil. Como o código é dinâmico e está sempre mudando, defesas de perímetro como Content Security Policy (CSP) e Subresource Integrity (SRI) não conseguem oferecer proteção suficiente para o seu site contra ataques polimórficos. Essas proteções são capazes de validar de onde o script vem e se ele foi alterado, mas não oferecem nenhuma visibilidade sobre o que o script realmente faz em tempo de execução.
Quais Ferramentas e Tecnologias Desofuscam JavaScript?
A desofuscação é essencialmente um exercício de engenharia reversa para transformar as strings e funções codificadas em algo legível por humanos. Muitas vezes é necessária uma combinação das técnicas abaixo para desofuscar completamente um script:
- Beautifiers ou Formatadores de Código: Ferramentas como JSBeautify, deobfuscate.io, JSnice e de4js podem pegar um script compactado ou minificado e re-indentar o código para adicionar quebras de linha, transformando-o em um trecho de código devidamente estruturado. Isso frequentemente não remove a ofuscação, mas torna o layout do código mais legível.
- Utilitários de Decodificação de Strings: Como código ofuscado frequentemente codifica dados usando hex, Base64, etc., usar ferramentas simples de decodificação pode recuperar as strings originais. Muitos analistas de segurança usam scripts Python ou sites como Dencode.com para decodificar formatos comuns.
- Refatoração e Substituição Manual: Às vezes, o caminho mais fácil é o mais manual — após usar um beautifier de código, ler o código e substituir estaticamente nomes de variáveis ou funções ofuscadas pelo seu significado real pode ajudar a entender a intenção por trás de algumas funções.
- Análise de AST: Para scripts muito complexos, pesquisadores de segurança frequentemente recorrem ao uso de scripts desenvolvidos sob medida para analisar e transformar o código. Usar um parser JavaScript para obter a Árvore de Sintaxe Abstrata (AST) de um script permite que um pesquisador navegue programaticamente pela estrutura e remova camadas de ofuscação. Essa abordagem pode ajudar a simplificar automaticamente coisas como achatamento de fluxo de controle ou codificação elaborada de funções, embora exija fortes habilidades de programação.
O JavaScript Ofuscado Pode Ser Analisado Automaticamente?
A análise automática e o sandboxing são indispensáveis para lidar com grandes volumes de JavaScript ofuscado e detectar ameaças em tempo real. Analisar manualmente cada script é frequentemente impraticável, então as organizações podem empregar uma combinação de sandboxing dinâmico, análise estática de código e inteligência de ameaças para entender o JavaScript em escala.
- Análise Dinâmica com Sandboxing: Uma abordagem para determinar o que um código suspeito faz é executá-lo em um ambiente controlado (usando um navegador que percorre o código passo a passo, por exemplo) e observar o que ele faz. Quando um script ofuscado é executado ali, o sandbox frequentemente consegue registrar comportamentos que parecem maliciosos. O script tenta modificar o formulário de checkout? Ele faz uma chamada AJAX para um domínio suspeito ou conhecido como malicioso? Ele cria iframes ocultos ou usa uma quantidade significativa de CPU? Como o sandbox observa as ações do script, ele pode sinalizar padrões mesmo que o código esteja ofuscado. Alguns sandboxes podem até mesmo se conectar ao motor JavaScript para despejar o código desofuscado assim que o script se desempacotar na memória. A abordagem dinâmica é ótima porque não requer compreensão do código e, em vez disso, observa diretamente os resultados maliciosos, mas pode ser detectada por malware avançado, que pode modificar seu comportamento caso isso ocorra.
- Análise Estática com Inteligência Artificial e Modelos de Linguagem de Grande Escala: No lado estático da análise, ferramentas de segurança frequentemente usam correspondência de padrões e inteligência artificial para examinar o texto e o comportamento dos scripts e decidir se são maliciosos, mesmo que ofuscados. O uso de modelos de linguagem de grande escala para obter uma linha de base de atividade do script tornou-se cada vez mais popular, pois permite que um analista de segurança distinga rapidamente o que pode ser um script minificado de um malicioso.
Na cside, nosso pipeline de análise automática avalia JavaScript tanto ofuscado quanto desofuscado, executando regras de detecção antes e depois da normalização do código para algo legível. Essa abordagem de dupla camada nos ajuda a detectar ameaças evasivas que podem aparecer apenas depois que o código é desempacotado. Ao contrário de muitos scanners tradicionais, a cside usa modelos de detecção baseados em atributos para ver como um script interage com a API do DOM e quais elementos ele pode criar, modificar e anexar. Esses atributos comportamentais nos permitem ver mudanças suspeitas mesmo que o script esteja fortemente ofuscado ou gerado em tempo de execução.
Quais são Alguns Exemplos Reais de Ataques com JavaScript Ofuscado Malicioso?
O JavaScript ofuscado esteve no centro de muitos ataques reais que a cside relatou, desde violações de alto perfil até campanhas cotidianas de malware.
- Skimmers de Cartão de Crédito Magecart: Magecart é um termo guarda-chuva para grupos que historicamente injetaram JavaScript malicioso em sites de e-commerce para roubar dados de cartões de pagamento. No ataque à British Airways em 2018, atacantes comprometeram scripts de terceiros e inseriram código de skimmer ofuscado. Esse código foi projetado para roubar informações de cartão de crédito nas páginas de checkout e enviá-las para servidores controlados pelos atacantes, tudo isso se misturando com scripts legítimos. Atacantes do Magecart comumente usam ofuscação de scripts para codificar funções e ocultar a verdadeira intenção da lógica do código. Para mais informações sobre o ataque à British Airways, a cside publicou um relatório especial sobre o ataque e (como acabamos ficando com o domínio usado no ataque!)
- Scripts de Cryptojacking: O surgimento de mineradores de criptomoeda no navegador também viu o uso de código ofuscado para implementar seus ataques. Em um ataque de cryptojacking, um atacante injeta um script que silenciosamente usa a CPU de um visitante para minerar criptomoeda. Para evitar detecção fácil (além do uso de CPU do usuário disparar), o código era frequentemente ofuscado ou servido a partir de um CDN de conteúdo comprometido. A cside publicou recentemente como os ataques de cryptojacking se tornaram mais proeminentes no último ano e mudaram bastante na forma como são executados.
- Injeção em Progressive Web Apps e Redirecionamentos: Em 2025, a cside relatou sobre um ataque que usou um Progressive Web App para redirecionar usuários móveis para um golpe de conteúdo adulto chinês. O payload desse ataque já havia sido visto antes, mas a entrega por meio de um Progressive Web App foi um vetor de ataque incrivelmente único. Embora os PWAs sejam frequentemente ignorados no espaço de segurança client-side, eles também são suscetíveis aos ataques do lado do navegador que a cside frequentemente observa.
Quais são as Melhores Práticas para Monitoramento e Defesa Contínuos de Segurança JavaScript?
Manter sua aplicação web segura contra código malicioso de terceiros não é um esforço único, mas exige monitoramento contínuo e boas práticas para minimizar o risco.
- O proxy da cside: O proxy da cside atua como intermediário entre seu site e scripts externos de terceiros, permitindo-nos interceptar, analisar e bloquear ataques JavaScript antes que sejam executados no navegador do usuário. Nosso proxy permite o monitoramento em tempo real do comportamento dos scripts em cada carregamento de página, sem modificar o código-fonte da aplicação ou ajustar os requisitos de Content Security Policy. Ao inspecionar scripts tanto em suas formas ofuscadas quanto normalizadas, o proxy pode aplicar regras e sinalizar anomalias — mesmo quando atacantes rotacionam camadas de ofuscação ou injetam payloads dinâmicos.
- Restringir e Validar Fontes de Scripts: Usar cabeçalhos de Content Security Policy (CSP) para controlar rigorosamente de onde os scripts podem ser carregados é outra forma fantástica de proteger seu site contra ataques indesejados. Usar uma regra CSP para colocar na lista de permissões apenas seus domínios e CDNs conhecidos, bloqueando todo o resto, é um ótimo primeiro passo para proteger o JavaScript que é executado no seu site. Combinar CSP com verificações de subresource integrity (SRI) — que podem detectar se um arquivo foi alterado e impedir sua execução — pode garantir que você esteja carregando apenas o que pretende carregar.
- Mantenha-se Informado e Treine sua Equipe: O cenário de ameaças evolui incrivelmente rápido, e novos truques de ofuscação e técnicas de ataque surgem o tempo todo. Invista no treinamento de suas equipes de segurança, junto com suas equipes de desenvolvimento, sobre essas tendências e melhores práticas para se proteger contra elas. Acompanhe relatórios de inteligência de ameaças e atualize seus próprios padrões de detecção de acordo. Certifique-se de ter um plano de resposta a incidentes especificamente para incidentes client-side — por exemplo, se você de repente detectar um skimmer ofuscado no seu site, quem você alerta? Preparar-se para esses cenários garante uma resposta que pode minimizar os danos se tratada adequadamente.
Considerações Finais
No ecossistema de navegadores atual, o JavaScript de terceiros é ao mesmo tempo uma necessidade e um risco para os sites. Técnicas de ofuscação podem servir a código legítimo, mas também são frequentemente usadas por atacantes para ocultar payloads prejudiciais — tornando cada vez mais difícil detectar, analisar e responder a ameaças potenciais. Ter a capacidade de desofuscar JavaScript e monitorar seu comportamento não é mais opcional. É absolutamente crítico.
Na cside, construímos nossa tecnologia para dar às equipes visibilidade sobre o que realmente está acontecendo dentro de scripts de terceiros. À medida que os ataques client-side continuam a evoluir, investir em visibilidade de payload e monitoramento em tempo real é a melhor defesa que você pode implementar hoje. Se você está pronto para assumir o controle do seu risco com JavaScript de terceiros, entre em contato conosco e explore mais do nosso blog de inteligência de ameaças para se manter atualizado sobre padrões de ataque.
