O malware transmitido por SVG está a inundar as caixas de correio eletrónico. Eis o que realmente o bloqueia.

• Os ficheiros SVG não são dados de imagem binários, como os JPEG ou os PNG. São baseados em XML e podem conter scripts executáveis que o navegador executa imediatamente ao abri-los.
• Os anexos SVG maliciosos aumentaram cinquenta vezes em 2025, em comparação com 2024, e são agora o terceiro tipo de anexo de e-mail malicioso mais comum a nível mundial, de acordo com o Relatório de Tendências de Phishing de 2026 da Hoxhunt.
• Cada carga útil SVG é personalizada para o endereço de e-mail do destinatário. O destino do redirecionamento é dividido, encriptado em várias variáveis e só é montado no momento da execução, aparecendo como texto sem sentido para qualquer scanner que leia o ficheiro de forma estática.
• A deteção tradicional baseia-se no reconhecimento de padrões de ataque conhecidos, seja através de assinaturas, seja através de heurísticas.
• A tecnologia Deep CDR™ remove o conteúdo ativo dos ficheiros de imagem compatíveis antes de estes chegarem ao utilizador, independentemente de a ameaça já ter sido detetada anteriormente. Não é necessária qualquer assinatura nem exposição prévia.

A 2 de junho de 2026, Xavier Mertens, responsável pelo SANS Internet Storm Center, publicou uma análise de uma nova campanha de phishing que vinha a chegar à sua caixa de entrada há vários dias. O anexo em cada e-mail era um ficheiro SVG, o tipo de ficheiro que a maioria das pessoas associa a ícones, ilustrações e gráficos da Web. Nada nele sugeria uma ameaça.

Ao clicar duas vezes no ficheiro, o navegador predefinido abriu-se, o script incorporado foi executado silenciosamente e o navegador redirecionou para uma página destinada a recolher credenciais, personalizada de acordo com o endereço de e-mail do destinatário. Não houve qualquer indício de que algo tivesse acontecido até ser tarde demais.

O ataque não exigiu nenhum software especial, nenhum documento com macros ativadas nem qualquer autorização do utilizador para além do gesto instintivo de abrir um anexo. Todo o mecanismo assentava numa suposição comum: a de que um ficheiro de imagem apresenta, por natureza, um risco reduzido.

Essa suposição é compreensível. Os ficheiros JPEG e PNG são representados como dados de píxeis, o que limita a sua superfície de ataque ao nível do ficheiro.

O SVG é diferente. É escrito em XML (Extensible Markup Language), a mesma linguagem de marcação subjacente às páginas web, o que significa que um ficheiro SVG pode conter tags de script, elementos de âncora e outros conteúdos web ativos que um navegador processa da mesma forma que processaria qualquer página web.

É essa a vulnerabilidade que os atacantes estão a explorar. Os ficheiros da campanha analisada por Mertens não continham qualquer conteúdo gráfico. Eram puramente código: JavaScript ofuscado envolto num invólucro SVG o mais fino possível, em que o contentor SVG existia por uma única razão: chegar ao navegador da vítima, sendo ao mesmo tempo classificado como um anexo de imagem pelo gateway de e-mail.

O SVG como vetor de ataque não é novidade, mas a sua utilização em grande escala tem vindo a acelerar. Os investigadores têm vindo a registar anexos SVG maliciosos em e-mails desde cerca de 2017, o que levanta a questão óbvia de saber o que mudou para que isto se tenha tornado um problema que vale a pena discutir hoje em dia.

Houve, essencialmente, duas mudanças.

Em primeiro lugar, a escala sofreu uma mudança drástica. Os anexos SVG maliciosos aumentaram cinquenta vezes em 2025, em comparação com 2024 (Relatório de Tendências de Phishing da Hoxhunt de 2026), e numa única campanha em fevereiro de 2026, a Microsoft registou o envio de 1,2 milhões de mensagens de phishing baseadas em SVG para mais de 53 000 organizações em 23 países. A técnica não é nova, mas a sua adoção em grande escala é.

Em segundo lugar, o panorama da defesa sofreu alterações que tornaram o SVG mais apelativo. A Microsoft desativou as macros do Office por predefinição em 2022, as ameaças baseadas em PDF passaram a ser alvo de um escrutínio mais rigoroso e o SVG chegou a muitos gateways com um histórico de reputação relativamente limpo, o que fez com que os atacantes, seguindo o caminho de menor resistência, rapidamente considerassem o SVG muito apelativo.

A técnica de evasão documentada por Mertens é subtil. O JavaScript incorporado no SVG é declarado utilizando o tipo «application/ecmascript» em vez do padrão «text/javascript» e, embora os navegadores tratem ambos de forma idêntica e executem scripts rotulados com qualquer um dos dois, a divergência entre o que os navegadores aceitam e o que as ferramentas de segurança verificam é precisamente onde o ataque ocorre.

Quando a RFC 9239 atualizou a norma em 2022, os fornecedores de soluções de segurança seguiram essa orientação e removeram o «application/ecmascript» das suas listas de verificação. Os navegadores, concebidos para garantir a compatibilidade com versões anteriores, continuaram a executá-lo na mesma. A norma indicava que o tipo tinha sido descontinuado. Os navegadores nunca receberam essa informação.

O resultado é uma lacuna persistente. «application/ecmascript» não é um identificador novo ou obscuro, mas tem uma história que remonta ao início dos anos 2000. Os atacantes não o inventaram. Perceberam que a transição da RFC criou uma assimetria entre os navegadores que mantêm o comportamento antigo e os scanners que impõem o novo padrão, e essa assimetria não se resolve por si só. Qualquer gateway que não tenha adicionado explicitamente os aliases MIME do ECMAScript obsoletos de volta às suas regras de inspeção permanece exposto, não por estar desatualizado, mas porque implementou um padrão que os navegadores não seguiram.

O endereço do destinatário é codificado em Base64 e incorporado diretamente no conteúdo do ficheiro SVG, o que significa que cada anexo desta campanha gera um URL de phishing único e personalizado, destinado a um destinatário específico, a um custo praticamente nulo.

Esse nível de personalização é importante porque contorna as heurísticas que detetam campanhas genéricas, uma vez que não há conteúdo repetido, nem URL de redirecionamento partilhado, nem qualquer padrão que se repita entre os destinatários, como acontece no phishing em massa.

O destino do redirecionamento é codificado em Base64 e, em seguida, encriptado utilizando uma chave formada a partir de duas variáveis distintas em tempo de execução. Não se trata de uma criptografia sofisticada, mas o que a torna eficaz contra scanners automatizados é precisamente o próprio processo de formação da chave.

Os sistemas de deteção que tentam reverter a ofuscação precisam de conhecer tanto o algoritmo como a chave, e a chave, neste caso, não existe como um valor único em nenhuma parte do ficheiro. Está dividida por duas variáveis e é concatenada apenas na altura da execução, o que significa que um scanner não consegue reconstruir o URL de destino sem primeiro resolver o assembly em tempo de execução, e isso requer a execução do script, em vez de apenas o ler. A análise estática produz poucos sinais úteis, e a carga útil só se torna legível num ambiente de navegador ativo, que é precisamente onde a maior parte da inspeção de gateway não ocorre.

Cada camada de evasão, por si só, pode ser detetada, mas, quando combinadas, um formato de anexo classificado como imagem, um tipo MIME obsoleto, uma carga útil encriptada e um domínio de destino num domínio de nível superior com um histórico limitado de abusos combinam-se para aumentar significativamente a probabilidade de chegar à caixa de entrada.

A segurança de e-mail baseada na deteção assenta numa questão fundamental: este ficheiro corresponde a uma ameaça conhecida ou reconhecível? A sua eficácia depende do conhecimento prévio, seja através de assinaturas ou de padrões comportamentais.

Essa dependência é a limitação estrutural que esta campanha revela. A acumulação de técnicas de ofuscação significa que há realmente pouco que um scanner possa detetar, e a classificação como SVG implica que o ficheiro pode não ser submetido ao mesmo nível de análise que um documento do Office ou um ficheiro executável. Se o seu gateway classificar o SVG como um formato de imagem e, consequentemente, aplicar uma inspeção menos rigorosa, é provável que esta campanha não tenha sido detetada ao nível do gateway. Trata-se de um caso em que o ataque opera fora do âmbito do que os sistemas de deteção conseguem avaliar.

Isto não significa que a deteção não funcione. Funciona bem contra ameaças conhecidas e nenhuma arquitetura de segurança de e-mail é eficaz sem ela. A questão é o que acontece com ameaças totalmente novas, que os sistemas de deteção nunca viram antes.

Uma abordagem que privilegia a prevenção introduz uma resposta complementar a par da deteção: este ficheiro ainda contém conteúdo ativo?

A tecnologia Deep CDR™ não procura determinar se um ficheiro é malicioso. Em vez disso, desconstrói o ficheiro, remove quaisquer elementos potencialmente maliciosos ou que não cumpram as políticas e fornece uma versão limpa e utilizável. No caso de um ficheiro SVG que contenha um script ativo, isso significa que o utilizador recebe um ficheiro que é apresentado conforme pretendido, caso exista conteúdo gráfico legítimo, mas sem o script que permite o ataque.

Esta abordagem é comprovada pela primeira classificação de 100% de sempre no teste de neutralização e reconstrução de conteúdos da SE Labs, que reconheceu a tecnologia Deep CDR™ como a primeira solução de CDR de sempre a alcançar uma pontuação de 100% em proteção e precisão.

Nem todas as ameaças são neutralizadas apenas pela sanitização. As cargas úteis evasivas, ou seja, ficheiros concebidos para parecerem inofensivos numa análise estática e que só se ativam em tempo de execução, exigem uma inspeção comportamental que vai além do que a sanitização abrange. OMetaDefender preenche essa lacuna através da análise dinâmica em sandbox, expondo comportamentos maliciosos por meio de emulação e apresentando um único veredicto fiável. Com uma taxa de deteção de ataques «zero-day» de 99,9%, o Aether aborda a exposição residual que a sanitização e a análise múltipla, por si só, não foram concebidas para resolver.

O SVG é o exemplo atual e não será o último. O padrão vai além do SVG: qualquer formato de ficheiro que pareça legítimo, mas que oculte conteúdo executável, é passível de receber o mesmo tratamento.

Os anexos HTML contornam os gateways para introduzir cargas maliciosas. Os códigos QR incorporados em ficheiros PDF redirecionam para páginas destinadas a recolher credenciais. As cargas maliciosas esteganográficas escondem-se nos metadados das imagens. Em cada um destes casos, o ficheiro é exatamente o que afirma ser a nível estrutural, embora contenha conteúdo que a verificação de classificação superficial nunca foi concebida para detetar.

A lição a retirar não é que algum formato específico seja perigoso. É que a afirmação «este ficheiro parece inofensivo» já não constitui um fundamento defensável para as decisões de entrega. Quando um ficheiro passa em todas as verificações de deteção, deve ser entregue automaticamente ou deve ser purificado de qualquer forma?

Os atacantes atuam diariamente partindo do princípio de que a deteção é a última linha de defesa. Para nós, faz parte de uma abordagem em várias camadas que combina diferentes tecnologias para maximizar a segurança no perímetro dos nossos clientes. O MetaDefender™ Email Security aplica essa lógica em dois modelos de implementação:

• Email Gateway Security do MetaDefender™ Email Gateway Security é implementada no local como software ao nível do SMTP/MX. A tecnologia Deep CDR™, que abrange mais de 200 tipos de ficheiros, remove conteúdo ativo de todos os anexos e analisa recursivamente arquivos aninhados para uma higienização profunda; a tecnologia Metascan™ Multiscanning, que utiliza mais de 30 motores antivírus, executa a deteção em paralelo; a IA preditiva Alin fornece um veredicto em milésimos de segundo sobre se o anexo contém ameaças sem necessidade de execução, a tecnologia de sandbox MetaDefender abrange cargas úteis evasivas que requerem uma análise comportamental mais aprofundada e a tecnologia Proactive DLP™ previne fugas na origem em mais de 125 tipos de ficheiros.
• MetaDefender™ Cloud Email Security aplica a mesma abordagem de «prevenção em primeiro lugar» em ambientes Microsoft 365, sem alterações nos registos MX, sem hardware e sem interrupção do fluxo de e-mails. A tecnologia Deep CDR™, MetaDefender , o Metascan Multiscanning até 17 motores antivírus e a IA preditiva Alin inspecionam e higienizam todos os anexos dos e-mails recebidos e enviados, incluindo ficheiros encriptados, antes de estes chegarem ao utilizador.