Ataques CSS em Webmail Expõem um Ponto Cego nas Defesas de E-mail com IA

O Google News destacou um ataque CSS em webmail identificado em mais de um milhão de mensagens de phishing desde abril de 2026. A campanha expõe um conflito fundamental na segurança de e-mail com IA. Pessoas e máquinas podem receber a mesma mensagem, mas interpretar conteúdos radicalmente diferentes.

A técnica relatada, chamada de text salting, usa Cascading Style Sheets para ocultar texto de preenchimento dentro de um e-mail HTML. Esse material oculto altera a forma como sistemas automatizados interpretam a mensagem sem modificar o que o destinatário vê.

Pesquisadores da Barracuda encontraram a técnica em campanhas de phishing com temática de varejo que prometiam recompensas, cartões-presente, pontos de fidelidade ou resgates urgentes. Os invasores usaram texto oculto para diluir linguagem suspeita e fazer e-mails maliciosos parecerem mais seguros para filtros automatizados.

Não se trata apenas de mais um truque para burlar filtros de spam. A mesma lacuna de visibilidade pode operar na direção oposta. Instruções ocultas podem atingir um assistente de IA que resume e-mails, redige respostas, pesquisa uma caixa de entrada ou aciona ferramentas conectadas.

Isso cria o principal trade-off de segurança. Ferramentas de e-mail com IA se tornam mais úteis à medida que leem mais contexto e recebem maior acesso. Essas mesmas capacidades ampliam as consequências quando conteúdo de e-mail não confiável influencia o modelo.

As defesas tradicionais pressupõem que a mensagem mostrada a uma pessoa seja, em linhas gerais, equivalente à mensagem inspecionada pelo software. O CSS rompe essa premissa ao criar versões separadas, uma visível para humanos e outra legível por máquinas, dentro de um único e-mail.

A pressão imediata recai sobre Google, Microsoft, fornecedores de segurança de e-mail e desenvolvedores que criam assistentes sobre dados de caixas de entrada. Eles precisam conciliar a análise da mensagem bruta com o conteúdo renderizado, preservando ao mesmo tempo a acessibilidade e a formatação legítima.

O Que o Relatório do Google News Revela Sobre o Text Salting

A mudança importante não é que os invasores descobriram o texto oculto. É que métodos antigos de evasão agora funcionam contra julgamentos baseados em IA.

O text salting adiciona palavras inofensivas ou contextualmente irrelevantes a uma mensagem maliciosa. O software de segurança analisa essas palavras, mas o CSS impede que o destinatário as veja.

A Barracuda informou ter detectado um milhão de ataques usando essas técnicas desde abril de 2026. As mensagens pertenciam a uma campanha com temática de varejo baseada em ofertas de recompensas e resgates.

Os invasores usaram diversas propriedades CSS comuns. clip-path: inset(100%) reduzia a área visível de um bloco de texto a nada. Regras de altura zero e altura de linha zero eliminavam espaços em branco suspeitos.

Outras regras deslocavam o texto para além do limite da tela. Um text-indent negativo muito grande o movia milhares de pixels para a esquerda, enquanto overflow: hidden suprimia uma barra de rolagem reveladora.

Os invasores também reduziam as fontes a zero. Nenhuma dessas propriedades é inerentemente maliciosa. Essa ambiguidade torna uma simples lista de bloqueio pouco confiável, pois modelos legítimos de e-mail podem usar técnicas de estilo relacionadas.

A campanha supostamente dependia de sites comprometidos ou domínios semelhantes. Alguns domínios usavam autenticação padrão de e-mail, incluindo DomainKeys Identified Mail, ou DKIM, que verifica se um domínio autorizado assinou uma mensagem.

O DKIM não determina se o conteúdo é honesto. Ele valida o tratamento e a integridade da mensagem no nível do domínio. Um operador malicioso que controla um domínio autenticado ainda pode distribuir phishing.

Essa distinção importa porque sistemas de IA costumam combinar muitos sinais. Autenticação, linguagem natural, reputação do remetente, links visíveis e estrutura da mensagem podem influenciar uma classificação.

O text salting manipula o sinal de linguagem. Ele fornece a um classificador um corpo maior de texto aparentemente benigno, mantendo a isca de phishing clara para o destinatário humano.

Um filtro que examine o HTML bruto pode encontrar parágrafos sobre atividade comercial não relacionada, atendimento ao cliente ou transações comuns de varejo. O destinatário pode ver apenas um aviso urgente sobre recompensa e um botão.

Isso cria uma versão semântica de entrada adversarial. O invasor não está necessariamente explorando uma falha de memória de software. Ele está moldando as evidências usadas por um sistema de decisão estatístico.

A IA generativa também reduz o custo de produzir diferentes textos de preenchimento. Os invasores podem criar passagens benignas distintas para cada mensagem, diminuindo o valor da correspondência exata de texto.

Assim, a manchete do Google News aponta para uma mudança mais ampla. O conteúdo de e-mail agora pode ser projetado para dois públicos, com uma narrativa para o usuário e outra para a máquina.

Por Que os Filtros de E-mail com IA Enfrentam um Problema de Renderização

Um modelo de IA não consegue avaliar um e-mail de forma confiável quando sua entrada não corresponde à mensagem exibida ao destinatário.

Muitos sistemas de segurança de e-mail inspecionam o conteúdo bruto da mensagem porque ele contém evidências valiosas. Ele expõe URLs, atributos HTML, metadados, seções codificadas e texto que a renderização pode ocultar.

Essa abordagem fazia sentido quando o texto oculto visava principalmente a pontuação de spam baseada em palavras-chave. Os defensores podiam procurar formatação suspeita e comparar palavras visíveis com a fonte subjacente.

Grandes modelos de linguagem complicam o processo. Eles podem inferir significado em passagens longas, mas essa capacidade também dá mais influência ao texto de preenchimento oculto sobre a classificação.

Um modelo pode ver uma mensagem dominada por linguagem comum de varejo. Sua solicitação visível de phishing pode ocupar apenas uma pequena parte da entrada total legível por máquina.

O ataque não exige que o modelo siga um comando direto. Ele pode funcionar ao alterar suficientemente o tema, o tom ou a intenção aparentes para produzir uma classificação benigna.

A análise renderizada apresenta seus próprios problemas. Clientes de e-mail diferem no suporte a HTML e CSS. Uma mensagem pode ser exibida de forma diferente no Gmail, Outlook, aplicativos móveis e softwares especializados de webmail.

Recursos de acessibilidade também podem expor texto que uma renderização visual padrão oculta. Leitores de tela, modos de alto contraste e visualizações simplificadas complicam qualquer alegação sobre uma apresentação definitiva.

Portanto, as ferramentas de segurança precisam de mais do que uma captura de tela. Elas precisam de uma comparação estruturada entre o conteúdo bruto, o layout calculado, a saída de acessibilidade e os elementos que um usuário típico consegue perceber.

A pergunta mais útil não é se uma propriedade parece suspeita isoladamente. É se o estilo cria uma diferença significativa entre a interpretação da máquina e a percepção humana.

Um parágrafo de tamanho zero contendo centenas de palavras não relacionadas é um sinal mais forte do que um único rótulo de formatação oculto. Grandes blocos fora da tela merecem escrutínio semelhante.

Os defensores também podem comparar o significado linguístico de regiões visíveis e ocultas. Uma mensagem sobre recompensas de fidelidade não deveria conter parágrafos ocultos sobre faturas não relacionadas, viagens ou atendimento ao cliente.

No entanto, os invasores podem se adaptar. Eles podem gerar texto de preenchimento que permaneça próximo ao tema visível, reduzindo a diferença semântica e ainda diluindo frases maliciosas.

Isso cria uma corrida armamentista entre a geração de conteúdo e a detecção orientada pela visibilidade. Um filtro precisa entender não apenas o que a mensagem diz, mas quais partes importam para a pessoa que a recebe.

O aprendizado de máquina não é inútil nesse caso. Ele continua valioso para identificar anomalias estruturais, padrões de remetentes, infraestrutura de campanhas e combinações incomuns de regras de estilo.

O problema é a excesso de confiança arquitetural. Um modelo de linguagem não pode compensar um pipeline de entrada que mistura instruções confiáveis, conteúdo não confiável e material invisível sem limites claros.

O Google descreveu uma defesa em camadas contra injeção indireta de prompt. Sua abordagem inclui classificadores de conteúdo, treinamento adversarial, red teaming e confirmação antes de ações sensíveis.

Esses controles ilustram a direção que as defesas de e-mail precisam seguir. Nenhum veredito de um único modelo deve decidir se uma mensagem é segura, especialmente quando o CSS altera o que diferentes observadores recebem.

Conteúdo Oculto Pode Mirar o Filtro ou o Assistente

A mesma lacuna de visibilidade do CSS sustenta dois ataques opostos: ocultar texto benigno das pessoas e ocultar instruções maliciosas delas.

O text salting tenta fazer um e-mail malicioso parecer benigno para um sistema de segurança. A injeção indireta de prompt tenta fazer um assistente de IA obedecer a instruções que o usuário nunca forneceu conscientemente.

A OWASP define injeção indireta de prompt como instruções maliciosas incorporadas a conteúdo externo que um sistema de IA processa posteriormente. O e-mail é um canal de entrega natural, pois qualquer pessoa pode enviar dados para muitas caixas de entrada.

Um invasor pode ocultar instruções com texto branco, fontes de tamanho zero, posicionamento fora da tela, caracteres codificados ou estruturas HTML omitidas pelo renderizador visual.

A vítima pode pedir a um assistente que resuma mensagens não lidas. Um fluxo de trabalho autônomo pode processar a caixa de entrada sem nenhuma solicitação direta. Em ambos os casos, o modelo pode encontrar instruções criadas pelo invasor.

Um ataque simples pode manipular um resumo. A IA poderia inventar um alerta de segurança, suprimir um indicador de phishing ou descrever uma mensagem maliciosa como aprovada.

Um ataque mais grave se torna possível quando o assistente pode pesquisar outras mensagens, ler documentos conectados, redigir e-mails de saída ou chamar ferramentas externas.

O e-mail malicioso passa então a agir como uma entrada de controle. Ele pode tentar redirecionar o assistente da tarefa do usuário para a recuperação de dados, a divulgação de informações ou uma ação não autorizada.

A Microsoft anunciou proteção contra injeção na caixa de entrada no Defender for Office 365 em julho de 2026. O recurso foi lançado em prévia pública para clientes elegíveis.

A Microsoft afirma que o sistema detecta instruções maliciosas de IA durante a inspeção do fluxo de e-mails. As mensagens detectadas recebem um veredito de phishing de alta confiança e podem ser isoladas antes de chegar aos usuários ou assistentes conectados.

Esse posicionamento é importante. Bloquear um ataque antes da entrega impede que ele entre em índices de pesquisa da caixa de entrada, sistemas de recuperação, resumos e contexto de agentes posteriores.

No entanto, a detecção no gateway não pode resolver todos os casos. Um invasor pode inserir instruções maliciosas em uma conta interna comprometida, uma lista de distribuição permitida, uma conversa encaminhada ou um anexo.

A distinção entre instruções e dados também continua difícil para modelos de linguagem. Ambos chegam como linguagem natural e ambos podem conter solicitações, comandos citados ou texto procedimental.

Um e-mail de um gerente pode dizer legitimamente: “Revise o arquivo anexado e envie sua resposta.” Uma injeção maliciosa pode usar linguagem quase idêntica ao se dirigir à IA, e não ao funcionário.

O assistente precisa inferir autoridade, procedência e intenção. A fluência em linguagem natural, por si só, não fornece essas propriedades de segurança.

É por isso que o ataque ao filtro e o ataque ao assistente pertencem à mesma discussão. Ambos exploram a ambiguidade entre conteúdo exibido, conteúdo processado e conteúdo autorizado.

O Google News trouxe à tona uma história sobre defesas de e-mail com IA, mas as implicações vão além da classificação de spam. Todo agente conectado a caixas de entrada herda esse problema ainda não resolvido de limites de entrada.

EchoLeak Mostrou o Que Acontece Quando o E-mail Chega às Ferramentas

Um e-mail oculto se torna substancialmente mais perigoso quando um assistente de IA consegue recuperar contexto privado e se comunicar além da caixa de entrada.

A divulgação do EchoLeak em 2025 trouxe um alerta concreto. Pesquisadores descreveram um ataque em múltiplas etapas envolvendo o Microsoft 365 Copilot e um e-mail cuidadosamente elaborado.

A Microsoft identifica o EchoLeak como CVE-2025-32711 e afirma que o problema foi corrigido. A empresa o descreve como uma técnica de injeção entre prompts que poderia expor dados limitados já disponíveis para uma vítima.

Segundo as orientações de segurança de IA da Microsoft, uma mensagem aparentemente inofensiva poderia contaminar o contexto processado pelo Copilot. A técnica poderia então causar uma divulgação não intencional em condições específicas.

O incidente foi relevante porque não dependia de roubar primeiro a senha do usuário. Ele visava o assistente por meio de dados que o assistente deveria ler.

O EchoLeak era mais complexo do que a campanha de text salting destacada pelo Google News. Envolvia várias etapas e condições, enquanto o text salting buscava principalmente evitar a classificação.

Ainda assim, ambos os casos desafiam a mesma premissa. O e-mail é tratado como conteúdo, embora partes desse conteúdo possam funcionar como instruções adversariais para sistemas de IA.

O risco cresce com a geração aumentada por recuperação, ou RAG. Esse projeto recupera informações privadas relevantes e as adiciona ao contexto de um modelo antes de gerar uma resposta.

O RAG ajuda um assistente de e-mail a responder perguntas sobre projetos, agendas, clientes e discussões anteriores. Também coloca informações valiosas próximas ao conteúdo de mensagens controlado por invasores.

O acesso a ferramentas acrescenta outra camada. Um assistente apenas de resumos pode induzir um usuário ao erro, mas um agente com ferramentas de mensagens ou arquivos pode criar consequências operacionais diretas.

Desenvolvedores frequentemente dependem de um prompt de sistema que instrui o modelo a ignorar instruções maliciosas. Essa medida ajuda, mas não cria uma fronteira de segurança rígida.

Um desafio de pesquisa em larga escala chamado LLMail-Inject reuniu 208.095 submissões de ataque de 839 participantes. Pesquisadores testaram várias defesas, modelos e configurações de recuperação em um cenário realista de agente de e-mail.

O volume de submissões importa porque invasores adaptativos não repetem uma frase óbvia. Eles testam transformações, enquadramento, codificação, contexto social e comportamento específico de cada modelo.

Defensores devem presumir que qualquer classificador ou proteção de prompts pode gerar falsos negativos. Ações sensíveis precisam de controles de autorização independentes, que não dependam da interpretação do modelo.

Um resumidor de e-mails não deve receber permissão para enviar mensagens apenas porque consegue lê-las. O acesso à pesquisa não deve implicar acesso a todas as pastas da caixa de correio ou a documentos conectados.

As chamadas de ferramentas devem usar o princípio do menor privilégio, que concede a cada componente apenas as permissões necessárias para sua tarefa atual. Ações de alto impacto devem exigir confirmação explícita do usuário.

As equipes de segurança também precisam de registros que mostrem qual mensagem influenciou uma saída ou ação. Sem proveniência, um responsável pela resposta a incidentes não consegue identificar facilmente a entrada contaminada.

Usuários que gerenciam materiais de origem para sistemas de IA enfrentam um desafio relacionado. Uma captura de informações clara e a separação das fontes podem ajudar a preservar o contexto, mas as permissões no nível da aplicação continuam essenciais.

A lição do EchoLeak não é que todos os assistentes de e-mail são inseguros. É que sua segurança deve acompanhar sua autoridade, e não sua aparência conversacional.

A Escolha Defensiva É Entre Visibilidade e Utilidade

Remover todos os elementos ocultos reduziria alguns ataques, mas também prejudicaria e-mails legítimos e deixaria falhas mais profundas de autorização sem solução.

Um sanitizador rigoroso poderia remover CSS, elementos ocultos, recursos remotos e HTML complexo antes que um sistema de IA lesse uma mensagem. Isso reduziria consideravelmente a superfície de ataque.

Também removeria estruturas que ajudam usuários e modelos a compreender e-mails legítimos. Tabelas, layouts responsivos, citações, assinaturas, rótulos de acessibilidade e formatação transacional podem transmitir significado útil.

Alguns conteúdos ocultos têm finalidades operacionais. O texto de pré-cabeçalho pode fornecer uma breve prévia na caixa de entrada, enquanto designs responsivos exibem elementos diferentes em telas de desktop e dispositivos móveis.

Produtos de segurança precisam distinguir esses casos de um grande bloco oculto projetado para manipular a classificação. A decisão não pode depender de uma única propriedade CSS.

Renderizar cada mensagem em um navegador controlado pode melhorar a análise de visibilidade. Isso também aumenta os custos computacionais e introduz um mecanismo de navegador no pipeline de segurança.

Uma visualização renderizada ainda pode não corresponder a todos os clientes. Largura de tela móvel, modo escuro, imagens bloqueadas, configurações de idioma e preferências de acessibilidade podem alterar o resultado.

A estratégia mais segura usa várias representações. Um sistema pode reter o conteúdo bruto para análise forense, calcular uma visualização normalizada e identificar separadamente regiões ocultas ou de baixa visibilidade.

O classificador de IA deve receber rótulos explícitos para essas regiões. O material oculto não deve entrar silenciosamente no mesmo fluxo de texto indiferenciado que o conteúdo visível.

Um assistente poderia tratar texto oculto como metadados não confiáveis. Ele poderia resumir esse conteúdo oculto apenas quando o usuário solicitasse uma análise de segurança.

Detectores de injeção de prompts oferecem outra camada. A implementação da Microsoft inspeciona assuntos, corpos de mensagens, HTML, estilização, conteúdo encaminhado e material codificado antes que um assistente os processe.

Ainda assim, a detecção de injeção de prompts é probabilística. E-mails legítimos podem conter discussões sobre prompts, testes de segurança, comandos de automação ou mensagens maliciosas citadas.

Uma equipe de pesquisa pode receber amostras genuínas de ataque por e-mail. Um filtro de segurança poderia colocar essas mensagens em quarentena mesmo quando o destinatário as espera.

Falsos positivos criam pressão para enfraquecer a aplicação das regras. Se e-mails importantes desaparecem com muita frequência, administradores adicionam exceções que invasores podem estudar e explorar.

A confirmação humana também é imperfeita. Usuários aprovam solicitações rotineiramente quando uma interface as apresenta como etapas normais, especialmente durante trabalhos repetitivos.

A confirmação deve, portanto, explicar a ação proposta, seu destino e os dados envolvidos. Um prompt vago perguntando se o usuário deseja “continuar” oferece pouca proteção.

O projeto mais robusto separa o raciocínio do modelo da aplicação de políticas. O modelo pode sugerir uma ação, enquanto um software determinístico verifica permissões, destinos, classificações de dados e requisitos de aprovação.

Essa abordagem limita os danos causados tanto por prompts ocultos quanto por erros comuns do modelo. Um assistente manipulado não pode ultrapassar os limites aplicados fora de seu contexto linguístico.

A contrapartida é menos conveniência. Usuários podem enfrentar mais prompts, integrações mais restritas e automação mais lenta para tarefas de alto risco.

Essa fricção se justifica quando um assistente pode enviar mensagens externas, recuperar documentos confidenciais, modificar registros ou iniciar fluxos de trabalho financeiros. Resumos de baixo risco podem manter controles mais leves.

As ferramentas de e-mail com IA devem, portanto, usar autoridade graduada. Ler uma mensagem selecionada, pesquisar uma pasta, redigir uma resposta e enviar essa resposta devem permanecer níveis de permissão separados.

O Que as Equipes de Segurança Devem Observar a Seguir

A próxima fase será medida pela qualidade da detecção, pelo projeto de permissões e por evidências de abuso no mundo real, e não por mais um benchmark de modelo.

O primeiro sinal é a maior disponibilidade de inspeção de e-mails com consciência de visibilidade. A prévia pública da Microsoft mostra que a injeção de prompts está se tornando uma categoria distinta de segurança de e-mail.

As equipes de segurança devem observar como os fornecedores expõem essas detecções. Produtos úteis identificarão a região oculta, explicarão sua função e preservarão evidências para investigação.

Um veredito genérico de phishing não é suficiente. Analistas precisam saber se uma mensagem continha texto de preenchimento oculto por CSS, uma instrução codificada, diretivas de ferramentas suspeitas ou uma divergência incomum entre o conteúdo visível e o bruto.

O segundo sinal é como Google, Microsoft e desenvolvedores terceirizados limitam agentes conectados à caixa de correio. Atualizações de modelos importam menos do que limites aplicáveis em torno da recuperação e do uso de ferramentas.

Compradores devem perguntar se os assistentes distinguem mensagens externas de instruções internas. Também devem perguntar se o conteúdo recuperado preserva a identidade do remetente, a localização e o nível de confiança.

Administradores precisam de controles para ações específicas. Uma política deve permitir resumos sem permitir automaticamente e-mails de saída, acesso a arquivos, alterações de calendário ou chamadas a APIs de terceiros.

O terceiro sinal é evidência verificada de exploração. Os dados de text salting da Barracuda mostram implantação em larga escala contra filtros, mas não estabelecem que todas as mensagens tenham derrotado um produto baseado em LLM.

Os fornecedores devem publicar metodologia e denominadores sempre que possível. Apenas as contagens de detecção não revelam taxas de entrega, classificações bem-sucedidas, interação das vítimas ou comprometimento posterior.

A mesma cautela se aplica a demonstrações de injeção de prompts. Um ataque em laboratório prova que existe um caminho de segurança, mas os controles de produção podem mudar sua confiabilidade prática.

Por outro lado, a ausência de incidentes públicos não prova segurança. A manipulação de agentes de IA pode se parecer com atividade comum de usuários, dificultando a identificação de incidentes sem registros detalhados.

As organizações não precisam esperar por medições perfeitas. Elas podem começar mapeando cada fluxo de trabalho que permite à IA processar e-mails recebidos ou recuperar o contexto da caixa de correio.

As equipes devem documentar o que cada assistente pode ler, quais ferramentas pode chamar e quais ações exigem aprovação. Também devem testar mensagens que contenham conteúdo oculto e fora da tela.

Exercícios de segurança devem incluir ambas as direções de ataque. Um teste deve ocultar preenchimento benigno para evitar a classificação. Outro deve ocultar instruções maliciosas destinadas ao assistente.

Desenvolvedores devem avaliar se o sistema explica a incerteza. Um assistente que detecta instruções conflitantes ou ocultas deve interromper a ação e identificar a fonte suspeita.

Usuários devem permanecer céticos em relação a alertas gerados por IA dentro de resumos de e-mails. Um alerta bem elaborado pode ter origem em conteúdo controlado por invasores, mesmo quando a interface pertence a um fornecedor confiável.

Para fluxos de trabalho informativos, mantenha as fontes originais disponíveis e inspecione alegações relevantes antes de agir. Resumos de IA devem acelerar a revisão, não substituir a proveniência.

O Google News trouxe atenção renovada aos ataques CSS no webmail, mas a questão duradoura é maior do que uma única campanha. O e-mail agora transporta conteúdo para pessoas, classificadores, sistemas de recuperação e ferramentas autônomas.

Esses públicos não percebem a mesma mensagem. Enquanto os sistemas de segurança não modelarem essa diferença diretamente, invasores continuarão explorando a lacuna entre o que humanos veem e o que máquinas leem.