Uma campanha de phishing de dois meses disfarçou códigos JavaScript maliciosos como anexos inofensivos de mensagens de voz, rotulando erroneamente os arquivos como texto simples para contornar os verificadores de anexos. O INKY detectou e sinalizou todas as 26.589 mensagens.

Entre 1º de junho e 4 de agosto de 2026, o serviço “ INKY ” rastreou e detectou uma campanha contínua de phishing que utilizava um isco aparentemente simples — uma notificação de mensagem de voz não atendida — para distribuir código malicioso oculto dentro de um arquivo de imagem. A campanha atingiu 5.527 organizações e gerou 26.589 e-mails detectados.

Todos os e-mails foram interceptados e sinalizados como perigosos. A arma escolhida pelos invasores foi um formato de arquivo que a maioria das pessoas — e muitos filtros de e-mail — considera inofensivo: a imagem SVG.

Este blog explica o que são arquivos SVG, por que os invasores passaram a utilizá-los como mecanismo de distribuição de malware em 2026 e exatamente como essa campanha funcionou. Também analisamos o código JavaScript ofuscado oculto dentro do anexo, o artifício que os invasores utilizaram para disfarçar o arquivo como texto simples e como o INKY o detectou em todas as organizações afetadas.

O que é um arquivo SVG e por que os invasores adoram ele?

SVG (Scalable Vector Graphics) é um formato de imagem, mas, ao contrário do JPEG ou do PNG, não é composto por pixels. Um SVG é um arquivo de texto escrito em XML que descreve formas, linhas e texto matematicamente, de modo que a imagem pode ser redimensionada para qualquer tamanho sem perder qualidade. Logotipos, ícones e gráficos na web costumam ser em formato SVG.

Mas há uma diferença crucial entre um SVG e uma imagem comum: um SVG pode conter código. A especificação SVG permite que scripts, incluindo JavaScript, sejam incorporados diretamente no arquivo, de modo que os gráficos possam ser interativos. Quando um SVG é aberto em um navegador da web, esse JavaScript incorporado é executado. Um PNG nunca pode fazer isso. Um SVG pode.

É justamente essa característica que os invasores exploram. Para uma pessoa — e para muitas ferramentas de segurança —, um arquivo SVG parece uma imagem. Para um navegador, porém, ele pode ser um veículo de entrega de um programa. Essa discrepância entre a forma como o arquivo é percebido e o que ele realmente pode fazer constitui a base da técnica conhecida como “contrabando de SVG”.

Por que os SVGs conseguem passar pelas defesas Os gateways de segurança de e-mail passaram anos aprendendo a bloquear tipos de anexos perigosos, como arquivos executáveis, scripts, documentos com macros ativadas e arquivos compactados. Os SVG eram, historicamente, tratados como imagens inofensivas e, portanto, permitidos. Os invasores perceberam isso. Ao envolver seu JavaScript em um invólucro SVG, eles distribuem código ativo dentro de um tipo de arquivo que muitos filtros nunca foram configurados para examinar.

Uma ameaça crescente em 2026

Os ataques baseados em SVG não são novidade. Pesquisadores vêm documentando anexos SVG maliciosos desde aproximadamente 2017, mas seu uso disparou em 2026. Duas coisas mudaram: a escala das campanhas e o nível de sofisticação da ofuscação.

• Crescimento de cinquenta vezes. De acordo com o Relatório de Tendências de Phishing 2026 da Hoxhunt, os anexos SVG maliciosos aumentaram cinquenta vezes em 2025 em relação a 2024 e agora ocupam o terceiro lugar entre os tipos mais comuns de anexos maliciosos em e-mails, ficando atrás apenas do PDF e do HTML.
• Campanhas individuais em grande escala. Em uma campanha ocorrida em fevereiro de 2026 e monitorada pela Microsoft, cerca de 1,2 milhão de mensagens de phishing baseadas em SVG foram enviadas a mais de 53.000 organizações em 23 países. O SANS Internet Storm Center registrou o uso dessa mesma técnica, que inundou as caixas de entrada em junho de 2026.
• Cargas sem conteúdo. Ao analisar amostras recentes, os pesquisadores encontraram arquivos SVG que não continham absolutamente nenhum conteúdo gráfico. O arquivo existe exclusivamente para enviar código JavaScript ofuscado ao navegador da vítima, ao mesmo tempo em que é classificado como uma imagem pelo gateway de e-mail.
• Iscas na forma de mensagens de voz. Vários fornecedores, incluindo a Sublime Security e a ReversingLabs, documentaram anexos em formato SVG disfarçados como notificações de mensagens de voz ou de chamadas perdidas — exatamente a isca utilizada na campanha descrita aqui.

A campanha INKY segue exatamente esse padrão e acrescenta uma camada extra de evasão ao classificar erroneamente o tipo de arquivo SVG como texto simples.

Visão geral da campanha

Todas as mensagens dessa campanha seguiam o mesmo modelo: um e-mail interno falsificado que alegava ser uma notificação de mensagem de voz, contendo um ou mais anexos SVG que, na verdade, eram código JavaScript ofuscado. As estatísticas abaixo foram extraídas diretamente da telemetria do INKY durante o período observado.

Métrico	Valor
Total de e-mails detectados	26,589
Organizações visadas	5,527
Período da campanha observado	1º de junho – 4 de agosto de 2026 (em andamento)
Resolução de ameaças	100% detectado
Tema “Lure”	Notificação de mensagem de voz perdida / chamada perdida
Carga útil	Anexo SVG contendo código JavaScript ofuscado
Sinal de evasão	Anexo SVG declarado como text/plain
Principais sinais de detecção	Conteúdo de phishing (100%), remetente interno falsificado (95%)
Personalização	99,5% dos assuntos continham o endereço de e-mail do próprio destinatário

Tabela 1: Resumo da campanha com base nos dados de telemetria do PhishFence da INKY , de 1º de junho a 4 de agosto de 2026.

Figura 1: Volume diário de e-mails detectados ao longo da campanha. A atividade ocorreu em ondas, atingindo seu pico em 3 de junho (2.432 e-mails em 1.149 organizações), com um ressurgimento acentuado no final de julho. As quedas ocorreram nos fins de semana, quando a campanha foi interrompida.

Pulverização ampla, não um ataque direcionado

A distribuição dos e-mails entre as organizações revela uma campanha ampla e oportunista, em vez de uma operação de precisão. Entre 5.527 organizações, a organização mediana recebeu apenas dois e-mails, e 32% receberam apenas um. As dez organizações mais afetadas, juntas, representam apenas 6% do volume total. Não há concentração em um pequeno conjunto de alvos de alto valor, o que é a marca registrada de uma campanha de dispersão criada para a coleta em larga escala de credenciais, em vez de um ataque de spear-phishing personalizado.

Figura 2: Distribuição de e-mails por organização. A esmagadora maioria das organizações recebeu apenas algumas mensagens, com uma pequena parcela de organizações mais fortemente afetadas, o que confirma que se tratou de um envio em massa, e não de uma entrega direcionada.

Ajustado à semana de trabalho

O ritmo de envio da campanha reforça a imagem de uma operação planejada para parecer plausível. O volume concentrou-se de segunda a quinta-feira e atingiu o pico na quarta-feira, com praticamente nenhum envio nos finais de semana. Isso é consistente com uma isca projetada para chegar enquanto os destinatários estão trabalhando ativamente e uma notificação de chamada perdida parece algo rotineiro.

Figura 3: Volume da campanha por dia da semana. O envio concentra-se de segunda a quinta-feira e praticamente cessa nos finais de semana.

Personalizado a partir do próprio endereço do destinatário

Em 99,5% das mensagens, o nome exibido no campo “assunto” era uma cópia exata da sequência de caracteres antes do símbolo @ no próprio endereço de e-mail do destinatário. Um destinatário com o endereço jsmith@… veria um assunto com o texto “mCaller deixou Jsmith, pré-visualização de 34s…”. Os invasores não precisaram de uma lista de contatos roubada. Eles geraram a personalização para cada destinatário automaticamente a partir do próprio endereço. O indício de que se trata de algo gerado por máquina, e não por humanos, é que as caixas de correio baseadas em funções eram endereçadas por seus nomes literais (por exemplo, “mCaller left Accountspayable”), algo que nenhum remetente real jamais escreveria.

Análise detalhada do e-mail de phishing

O e-mail em si é deliberadamente sucinto. Ele se apresenta como uma notificação automática de mensagem de voz, com pouco texto no corpo da mensagem, um assunto que faz referência a uma chamada perdida e um ou mais anexos com formato semelhante ao de um arquivo de mensagem de voz. Abaixo está um exemplo editado da campanha.

Figura 4: Um exemplo de e-mail da campanha com informações ocultadas. A mensagem se faz passar por uma notificação interna de mensagem de voz e contém dois anexos cujos nomes foram criados para se parecerem com o arquivo da mensagem de voz. Observe a extensão .svg…​.txt. Os identificadores do destinatário e do remetente foram ocultados.

Duas camadas de engano

Antes mesmo de uma única linha de código ser executada, a mensagem já se baseia em duas formas de engano no nível do envelope:

• Remetente interno falsificado. O e-mail afirma ter sido enviado a partir do próprio domínio do destinatário, mas, na verdade, foi enviado por uma fonte externa e o remetente nunca foi autenticado pelo servidor de e-mail da organização. Ele foi criado para se parecer com uma notificação interna do sistema.
• O anexo está identificado incorretamente. Embora os arquivos tenham a extensão .svg e contenham marcação SVG/XML, eles são declarados na mensagem com o tipo de conteúdo “text/plain”, em vez de “image/svg+xml”. Um verificador de anexos que se baseia no tipo declarado identifica um arquivo de texto inofensivo, e não um conteúdo ativo.

No anexo: O que o código realmente faz

Ao abrir o anexo em um editor de texto, em vez de um navegador, percebe-se que a “mensagem de voz” não é, na verdade, uma imagem. Trata-se de um documento XML que contém código JavaScript ofuscado. A captura de tela abaixo mostra o conteúdo bruto de um exemplo.

Figura 5: O conteúdo bruto do anexo SVG. Por baixo de uma fina camada SVG (um título e dois retângulos) encontra-se um código JavaScript ofuscado dentro de um `foreignObject` e de um bloco CDATA de script. O bloco que contém a URL de callback ativa foi ocultado.

A estrutura

Em sua forma mais básica, o arquivo tem três partes:

• Um shell SVG minimalista. Um <svg> raiz com um <title> e mais alguns <rect> elementos. Essa é a única parte que seria exibida como uma “imagem” e serve, essencialmente, como capa decorativa.
• Um atributo de dados oculto. O elemento raiz contém um atributo personalizado (por exemplo, data-strand-key-tk=”…”), que armazena um valor codificado que o script lê durante a execução. Dividir a configuração em atributos pouco evidentes mantém os valores maliciosos fora do caminho óbvio do código.
• Dois payloads de script. A <foreignObject> que contém um HTML <script type="application/json"> bloco, e um segundo

Como funciona a ofuscação

O código foi escrito para enganar tanto analistas humanos quanto scanners automatizados que procuram padrões maliciosos reconhecíveis. Várias técnicas são combinadas em camadas:

• Nomes de funções e variáveis sem sentido. Cada identificador é disfarçado com nomes sem sentido, de cunho pseudocientífico e com temática biológica, como intronGap91, riboUnit30, vectorArm37, codonBuf13Go e primerSet56. Esses nomes não têm nenhum significado e existem apenas para tornar o código ilegível e para variar entre as amostras, de modo que nenhum arquivo seja idêntico a outro.
• Construção de sequências de caracteres a partir de códigos. Sequências confidenciais nunca são gravadas em texto simples. Em vez disso, elas são montadas em tempo de execução a partir de códigos numéricos de caracteres, por meio do método `String.fromCharCode(…)`. Um scanner estático que lê o arquivo vê uma lista de números, e não as palavras que eles representam.
• Injeção de script em tempo de execução. Em vez de chamar funções perigosas diretamente, o código cria um novo elemento de script com document.createElementNS(…), atribui a ele uma fonte a partir de um valor gerado em tempo de execução e o anexa ao documento. Essa é uma forma comum de contornar a análise estática, já que o destino malicioso não existe como uma string literal no arquivo.
• Execução diferida. A execução é agendada por meio de requestIdleCallback / setTimeout, de modo que a carga útil é executada um pouco depois do carregamento, em vez de imediatamente, o que ajuda a contornar ferramentas que observam apenas o momento em que um arquivo é aberto.

O que ele está realmente fazendo

Uma vez decodificada, a ofuscação fica clara. As sequências de códigos de caracteres no exemplo correspondem a pequenas sequências de caracteres que o script usa para formar o nome do ponto de extremidade remoto com o qual ele se comunica. Um scanner estático que analisa o arquivo vê apenas a lista de números abaixo, nunca as palavras que eles formam:

String.fromCharCode(104,116,116,112,115) -> "https" String.fromCharCode(46,112,104,112) -> ".php" (os códigos numéricos montam o endpoint em tempo de execução)

O código lê seu atributo de dados oculto, monta o nome do endpoint a partir desses códigos e, em seguida, usa window.fetch(…) para se conectar a um servidor controlado pelo invasor e recuperar a próxima etapa do ataque. O próprio SVG não contém a página de phishing; ele é um lançador que obtém sua carga útil de um servidor remoto em tempo de execução.

O que essa próxima etapa normalmente representa, com base no comportamento desse tipo de campanha, segue um padrão bem documentado.

O conteúdo obtido geralmente consiste em uma página destinada a roubar credenciais, que se faz passar por um serviço de login amplamente utilizado, como o Microsoft 365, o Google Workspace ou o Adobe. Em muitas campanhas, o próprio endereço de e-mail da vítima é transmitido e usado para preencher automaticamente o formulário de login falso, fazendo com que pareça personalizado e legítimo.

Cada vez mais, essas páginas não são simples clones, mas portais do tipo “adversário no meio” (AiTM): elas retransmitem o que a vítima digita para o serviço de login real em tempo real, capturam o token de sessão resultante e, assim, contornam a autenticação multifatorial. Essa técnica tem sido associada a kits de “phishing como serviço”, como o Tycoon2FA, o Mamba2FA e o Sneaky2FA. Hospedar a carga útil remotamente também permite que o invasor atualize ou troque a página de phishing a qualquer momento, sem precisar alterar o SVG que foi entregue.

A principal conclusão O SVG não é a carga útil. É o **contêiner de contrabando**. Sua única função é transportar código JavaScript executável através do gateway de e-mail dentro de um tipo de arquivo tratado como imagem (e, neste caso, erroneamente rotulado como texto) e, em seguida, entregar esse código ao navegador, que poderá executá-lo. O anexo que parece uma mensagem de voz é, na verdade, um pequeno programa cuja primeira ação é entrar em contato com o servidor de origem.

Por que essa campanha contorna as defesas convencionais

• Tipo de arquivo considerado confiável. Os arquivos SVG são amplamente tratados como imagens inofensivas. Historicamente, muitos gateways não os verificavam como conteúdo ativo.
• Rotulagem incorreta de MIME. Declarar o anexo como “text/plain” contorna os scanners que decidem se devem inspecioná-lo com base no tipo de conteúdo declarado.
• Não há assinatura estática. Identificadores irrelevantes, a construção de sequências de códigos de caracteres e a variação por amostra significam que não há uma sequência ou hash fixo para ser comparado ao longo da campanha. Cada arquivo tem uma aparência diferente.
• Carga útil executável apenas em tempo de execução. O destino malicioso é montado e obtido somente quando o arquivo é executado em um navegador. Ele não está presente como texto legível que possa ser detectado por um scanner estático.
• Identidade interna falsificada. A mensagem se faz passar por uma notificação interna, aproveitando-se da confiança que os usuários depositam em e-mails que parecem ter sido enviados pela própria organização.

Mapeamento do MITRE ATT&CK

As técnicas observadas nesta campanha correspondem às seguintes táticas e técnicas do MITRE ATT&CK.

Tática	Técnica (ID)	Como isso aparece nesta campanha
Acesso inicial	Phishing: Anexo de spearphishing (T1566.001)	Arquivo SVG malicioso enviado como anexo de e-mail disfarçado de arquivo de mensagem de voz
Execução	Execução pelo usuário: Arquivo malicioso (T1204.002)	O ataque depende de o destinatário abrir o arquivo SVG, que executa o JavaScript incorporado no navegador
Evasão de Defesa	Disfarce (T1036)	Anexo SVG identificado erroneamente como “text/plain” e disfarçado como uma notificação de mensagem de voz
Evasão de Defesa	Arquivos ou informações ofuscados (T1027)	Identificadores irrelevantes, a construção de sequências de códigos de caracteres e a variação por amostra ocultam a intenção
Evasão de Defesa	Desofuscar/Decodificar arquivos ou informações (T1140)	O script reconstrói as cadeias de caracteres e seu destino em tempo de execução por meio do método String.fromCharCode
Evasão de Defesa	Alerta de segurança falso / Falsificação de identidade (T1656)	A mensagem se faz passar por um remetente interno do sistema, pertencente ao próprio domínio do destinatário
Comando e Controle	Protocolo da camada de aplicação: Protocolos da Web (T1071.001)	O script incorporado utiliza uma chamada à Web para um endpoint controlado pelo invasor a fim de recuperar a próxima etapa
Acesso por credenciais	Captura de entrada (T1056)	A etapa posterior geralmente apresenta uma página destinada a roubar credenciais, que se faz passar por uma página de login conhecida

Tabela 3: Mapeamento do MITRE ATT&CK para a campanha de contrabando de mensagens de voz em SVG. O estágio de acesso a credenciais é inferido a partir da característica da carga útil subsequente obtida, típica dessa classe de campanha.

Como o “ INKY ” detectou isso

INKY não se baseia em suposições sobre tipos de arquivo nem em assinaturas estáticas. Ele avalia o contexto completo e o comportamento de cada mensagem. Em todos os 26.589 e-mails, o INKY detectou a campanha e sinalizou todas as mensagens com o veredicto “Perigo ”. A detecção baseou-se em um sinal universal, reforçado por um segundo:

• O conteúdo de phishing sinalizou 100% da campanha. Todas as mensagens foram classificadas como phishing com base em vários indicadores suspeitos, incluindo o fato de conterem um anexo com conteúdo suspeito e se parecerem com uma notificação falsa de mensagem de voz. Esse foi o sinal que detectou toda a campanha, em todas as organizações, sem exceção.
• A categoria “Remetente interno falsificado” detectou 95% da campanha. Como sinal adicional, a categoria “ INKY ” identificou que a mensagem alegava ter origem no próprio domínio do destinatário, mas chegou de uma fonte externa, com um remetente que não havia se autenticado no servidor de e-mail da organização. Essa categoria detectou 95% da campanha; as mensagens restantes, em organizações onde essa categoria específica não estava em vigor, ainda foram totalmente detectadas pela categoria “Conteúdo de phishing”.

O banner INKY exibido aos destinatários explicava exatamente por que a mensagem era perigosa:

Figura 6: O banner de aviso “ INKY ” exibido em uma mensagem de campanha, explicando ambas as categorias de ameaças em linguagem simples. O domínio do próprio destinatário foi ocultado.

Cada mensagem foi avaliada com base em toda a gama de categorias de ameaças do INKY . O conteúdo de phishing, por si só, já foi suficiente para sinalizar todas as mensagens da campanha como perigosas, com o “Remetente interno falsificado” acrescentando um segundo sinal corroborativo na maioria delas.

Categoria de ameaça	Cobertura	Papel na detecção
Conteúdo de phishing	100%	Sinal universal — captou todas as mensagens
Remetente interno falsificado	95%	Sinal de confirmação na maioria das mensagens

Tabela 2: Categorias de ameaças do INKY identificadas ao longo da campanha. O “Conteúdo de phishing” sinalizou todas as mensagens; o “Remetente interno falsificado” confirmou a maioria delas.

O que a filtragem nativa da Microsoft detectou

A diferença entre o veredicto do site INKYe a filtragem nativa de e-mails é gritante nesta campanha.

A Microsoft atribui a cada mensagem um Nível de Confiança de Spam (SCL), em que uma pontuação de 0 ou 1 significa que a mensagem foi considerada não spam e é entregue normalmente na caixa de entrada, enquanto uma pontuação de 5 a marca como spam. Ao longo desta campanha, 19.994 das 26.589 mensagens (75%) apresentaram um SCL da Microsoft igual a 0 ou 1, e apenas 4.777 (18%) receberam pontuação SCL 5.

Em outras palavras, o filtro de spam nativo da Microsoft classificou três em cada quatro dessas mensagens de phishing como não sendo spam, ou seja, e-mails destinados à caixa de entrada, enquanto o INKY sinalizou, de forma independente, todas elas como perigosas.

Figura 7: Pontuação de spam da Microsoft em comparação com o veredicto do INKY ao longo da campanha. A Microsoft classificou 75% das mensagens como não sendo spam (SCL 0 ou 1) e apenas 18% como spam (SCL 5), enquanto o INKY classificou todas as 26.589 mensagens como perigosas.

O que torna isso impressionante é que a campanha foi criada a partir de um único modelo. A mesma estrutura de mensagem, o mesmo isco e o mesmo anexo geraram reações totalmente diferentes, dependendo da caixa de entrada do destinatário: considerada legítima para a maioria, spam para alguns.

INKY, por outro lado, apresentou o mesmo veredicto de perigo em todas as 26.589 mensagens. Esse é o argumento central a favor da detecção baseada no comportamento: uma mensagem classificada como “limpa” em termos de spam ainda pode ser um ataque de phishing de credenciais, e somente uma abordagem que avalie todo o contexto de forma confiável consegue detectá-la.

Indicadores de comprometimento

Os indicadores a seguir estão associados a esta campanha. Como a carga útil varia de acordo com cada amostra, os indicadores comportamentais e de padrão são mais confiáveis do que qualquer hash de arquivo específico.

Indicador	Valor / Padrão	Notas
Tema “Lure”	Notificação de mensagem de voz perdida / chamada perdida	Pretexto de engenharia social
Padrão do assunto	mCaller left <name> - 34s Preview vHC- <date> <number>	<name> = recipient's email local-part
Nome do anexo	PLAY_Voice-….svg	Nome de arquivo SVG no estilo de mensagem de voz
Tipo MIME declarado	text/plain	SVG rotulado incorretamente para burlar os scanners
Comportamento da carga útil	SVG → JS ofuscado → chamada para um endpoint remoto	Injeção de script em tempo de execução / callback
Ofuscação	String.fromCharCode, identificadores inválidos	Contorna assinaturas estáticas

Tabela 4: Indicadores de comprometimento da campanha de contrabando de mensagens de voz via SVG.

Recomendações

Para equipes de segurança

1. Trate os arquivos SVG como conteúdo ativo. Configure os gateways de e-mail e da web para inspecionar anexos SVG como possíveis portadores de scripts, e não como imagens inofensivas, e não se baseie no tipo MIME declarado para decidir se deve ou não fazer a verificação.
2. Considere bloquear ou colocar em quarentena anexos SVG recebidos. E-mails comerciais legítimos raramente precisam enviar arquivos SVG diretamente aos usuários finais. Bloquear ou isolar em ambiente de teste os arquivos SVG recebidos elimina uma superfície de ataque cada vez maior, com o mínimo de interrupção.
3. Não confie em assinaturas baseadas em hashes de arquivos. A ofuscação por amostra faz com que os hashes mudem constantemente. Priorize a detecção comportamental e baseada em conteúdo, que avalia o que um arquivo faz, e não com o que ele corresponde.
4. Reforce os controles contra falsificação interna. Certifique-se de que sua segurança de e-mail seja capaz de detectar mensagens que afirmam ter origem no seu próprio domínio, mas que, na verdade, são enviadas de fora e não estão autenticadas — esse é o “truque do envelope” utilizado por essa campanha.
5. Informe os usuários sobre mensagens de voz e anexos de imagem inesperados. Reforce a ideia de que um e-mail sobre uma chamada perdida ou mensagem de voz com um anexo para “reproduzir” a mensagem é um pretexto comum de phishing, e que arquivos de imagem podem conter código.

Para os destinatários do e-mail

• Desconfie de notificações de mensagens de voz ou chamadas perdidas que chegam por e-mail com um anexo para abrir, especialmente se você não esperava recebê-las.
• Nunca abra um anexo .svg que você não esperava receber. Ao contrário das imagens comuns, os arquivos SVG podem executar código quando abertos em um navegador.
• Considere como não confiável qualquer página de login acessada ao abrir um anexo. Acesse os serviços diretamente, em vez de usar links ou arquivos contidos em e-mails.
• Lembre-se de que um e-mail que pareça ter sido enviado pela sua própria organização ainda pode ser falsificado. Uma notificação do “sistema” que pareça ter origem interna não é prova de legitimidade.

Conclusão

Essa campanha é um exemplo clássico de uma técnica que define as ameaças por e-mail em 2026: ocultar código executável dentro de um tipo de arquivo que o mundo considera uma imagem inofensiva. Ao envolver JavaScript ofuscado em um SVG, disfarçar esse SVG como texto simples, falsificar um remetente interno e apresentar tudo como uma mensagem de voz rotineira, os invasores criaram uma isca projetada para passar despercebida tanto pelos filtros automatizados quanto pelo julgamento humano, em uma escala de dezenas de milhares de mensagens em milhares de organizações.

Não funcionou. O INKY detectou e sinalizou todas as 26.589 mensagens, utilizando sinais comportamentais que avaliam o que uma mensagem é e o que ela faz, em vez de confiar no que ela alega ser. Essa distinção é importante: a filtragem nativa de spam classificou três quartos dessa campanha como e-mails legítimos, destinados à caixa de entrada. À medida que os invasores continuam a utilizar formatos de arquivo confiáveis como arma, uma abordagem que prioriza o comportamento — e não assinaturas nem suposições baseadas no tipo de arquivo — é o que distingue a detecção da entrega.

Tags: contrabando de SVG, phishing por SVG, anexo SVG malicioso, contrabando de JavaScript, phishing por correio de voz, evasão de tipo MIME, remetente interno falsificado, segurança de e-mail 2026, INKY PhishFence, inteligência contra ameaças