Texto invisível no email: como o ASCII smuggling engana os filtros

Os filtros de spam leem texto. As pessoas também leem texto — mas não o mesmo texto. Os atacantes começaram a explorar essa diferença, inserindo caracteres que os computadores processam mas que ninguém vê, e a Microsoft registou um salto acentuado nestas mensagens no início deste ano. Se a sua equipa lida com faturas, pedidos de pagamento ou propostas de financiamento por email, vale a pena dedicar dez minutos a este tema.

O que mudou, na prática

Segundo a Ars Technica, uma técnica conhecida como ASCII smuggling passou de ataques com IA para o spam vulgar. O mecanismo assenta num bloco de 128 caracteres Unicode de "tag" que espelham quase exatamente os caracteres ASCII normais. O ponto de código U+E0041 substitui o "A", o U+E0061 substitui o "a". As máquinas leem-nos sem problema. Por conceção, são praticamente invisíveis para quem olha para o ecrã.

A técnica chamou a atenção pela primeira vez há dois anos, como forma de esconder injeções de prompt — instruções maliciosas inseridas em conteúdo que um modelo de linguagem irá depois processar. O modelo vê as instruções; a pessoa que lê o mesmo email não vê nada de estranho.

Os spammers inverteram o objetivo mas mantiveram o método. Em vez de esconder instruções, escondem quebras dentro de palavras que os filtros procuram. Basta inserir um caractere invisível a meio de "funding" para que um filtro leia "fun" e "ding" como dois fragmentos inofensivos. O destinatário continua a ver "funding". A mesma abordagem pode ser usada em valores monetários e em palavras como "crédito" e "prazo", frequentes em campanhas em massa.

Os números da Microsoft mostram a dimensão do problema. As deteções de assinaturas de ASCII smuggling no Microsoft Defender for Office andavam à volta das 21.000 por dia, e depois dispararam para mais de 1,3 milhões num único dia, no início de fevereiro. Quatro dias depois, chegaram aos 2,5 milhões. A vaga continuou durante meses e caiu de forma acentuada em meados de maio.

Porque é que as defesas antigas têm dificuldade

Esconder palavras-gatilho não é novidade. Espaços de largura zero e espaços não separáveis são usados para o mesmo fim há décadas. Quebram a correspondência literal de strings e alteram a sequência de bytes que os filtros baseados em padrões procuram.

O que torna as tags Unicode interessantes é o efeito que têm sobre os filtros modernos. Modelos de aprendizagem automática e de linguagem natural fazem hoje grande parte do trabalho de classificação de spam e phishing. Esses sistemas normalmente dividem o texto em tokens ou fragmentos de subpalavra antes de raciocinar sobre ele. Uma palavra limpa como "funding" corresponde a um token conhecido. Insira um caractere invisível e o tokenizador pode produzir fragmentos, ou pedaços raros e desconhecidos, em vez disso. Se o sistema normalizar o texto primeiro, o caractere é simplesmente removido e a palavra sobrevive intacta — e é exatamente por isso que a normalização é importante. A Microsoft nota que, a menos que um sistema de filtragem renderize a mensagem como imagem e a submeta a OCR, este tipo de ataque pode passar despercebido.

Porque é que isto importa para uma pequena empresa

A maioria das pequenas empresas não gere a sua própria infraestrutura de correio. Depende do que o fornecedor filtrar. Isso é razoável, mas significa que a sua exposição muda quando a técnica do atacante muda, e a empresa só percebe tarde.

O risco prático não é o spam em si. É a mensagem que chega à caixa de entrada com ar legítimo porque o filtro a classificou como inofensiva. Um contabilista que recebe dezenas de faturas por semana tem poucas razões para desconfiar de mais uma. O texto parece normal no ecrã. Nada assinala visivelmente manipulação.

Há um segundo ângulo se tiver ligado um assistente de IA ao seu email, ao seu CRM ou ao fluxo de documentos. Os mesmos caracteres que enganam um filtro de spam podem transportar instruções que um modelo vai seguir. Qualquer ponto onde texto não fidedigno chegue a um modelo capaz de executar ações merece uma revisão.

O que fazer quanto a isto

• Confirme com o seu fornecedor de email ou contacto de TI que a filtragem de entrada normaliza Unicode — ou seja, que remove ou sinaliza caracteres de tag invisíveis antes da classificação. Faça a pergunta diretamente, em vez de presumir.
• Dê ao seu contabilista e a qualquer pessoa que lide com pagamentos uma regra que não dependa de filtros: dados bancários e valores de pagamento são verificados através de um segundo canal, por telefone ou com um contacto conhecido, antes de o dinheiro ser movimentado. Sem exceções por urgência.
• Diga à equipa que um email pode parecer perfeitamente limpo e ainda assim ter sido manipulado. Os conselhos antigos sobre erros ortográficos e formatação estranha não se aplicam aqui, porque a parte escondida é invisível.
• Reveja qualquer ferramenta de IA que leia emails, tickets ou documentos recebidos. Se puder enviar mensagens, atualizar registos ou desencadear ações por conta própria, adicione confirmação humana para tudo o que tenha consequências financeiras ou externas.
• Mantenha uma nota interna curta sobre onde reportar mensagens suspeitas, para que um funcionário hesitante tenha para onde as enviar em trinta segundos.

A lição de fundo não é sobre um bloco Unicode em particular. É que o texto que os seus sistemas processam e o texto que as suas pessoas leem são duas coisas diferentes, e os atacantes trabalham nessa diferença. Os filtros vão acabar por se atualizar; a Microsoft já publicou orientações para programadores sobre como lidar com isto. O seu processo de verificação de movimentos de dinheiro deve ser a camada que não depende dessa atualização.